On 07/18/2014 11:59 PM, Vlad Yasevich wrote:
On 07/18/2014 03:17 PM, Daniel Borkmann wrote:
On 07/18/2014 04:38 PM, Vlad Yasevich wrote:
...
Why is the original value of asoc->peer.auth_capable = 0?
In case of collision, asoc is the old association that
existed on the system. That association was created as part of
sending the INIT. If it is processing a duplicate COOKIE-ECHO
as you say, then it has already processed the INIT-ACK and
should have determined that the peer is auth capable.
Thus the capability of the new and the old associations should
be same if we are in fact processing case B (collision).
If not, then something else if wrong and my guess is that all
other capabilities would be wrong too.
I agree that they might likely also be flawed.
Ok, let me dig further.
So I think I know why case D ends up not authenticating the COOKIE-ACK.
Most likely the reason is the following statement:
repl = sctp_make_cookie_ack(new_asoc, chunk);
That in fact lets COOKIE-ACK be AUTH'ed which weren't before,
so we should add that into the set. What happens though is
that subsequent AUTH+HBs from both sides remain unanswered,
so no AUTH+HB_ACK. This issue is independant of s/new_asoc/asoc/
though; disabling auth_enabled at both sides makes HB+HB_ACKs
work.
Note that we use new_asoc, instead of current asoc.
Not sure why case B is dumping core yet.
-vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
