Commit 0ef46e28 authored by Vlad Yasevich's avatar Vlad Yasevich Committed by David S. Miller

sctp: do not enable peer features if we can't do them.

Do not enable peer features like addip and auth, if they
are administratively disabled localy.  If the peer resports
that he supports something that we don't, neither end can
use it so enabling it is pointless.  This solves a problem
when talking to a peer that has auth and addip enabled while
we do not.  Found by Andrei Pelinescu-Onciul <andrei@iptel.org>.
Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent a3028b8e
......@@ -1886,11 +1886,13 @@ static void sctp_process_ext_param(struct sctp_association *asoc,
/* if the peer reports AUTH, assume that he
* supports AUTH.
*/
asoc->peer.auth_capable = 1;
if (sctp_auth_enable)
asoc->peer.auth_capable = 1;
break;
case SCTP_CID_ASCONF:
case SCTP_CID_ASCONF_ACK:
asoc->peer.asconf_capable = 1;
if (sctp_addip_enable)
asoc->peer.asconf_capable = 1;
break;
default:
break;
......@@ -2460,6 +2462,9 @@ do_addr_param:
break;
case SCTP_PARAM_SET_PRIMARY:
if (!sctp_addip_enable)
goto fall_through;
addr_param = param.v + sizeof(sctp_addip_param_t);
af = sctp_get_af_specific(param_type2af(param.p->type));
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment