sctp_getpaddrs() on a SHUTDOWN association
Hi there,
I've got a simple case: a multi-homed client connects to a server, then disconnects right away. On the server side we receive the SCTP_COMM_UP notification and try to get the client's addresses with sctp_getpaddrs(). But since the L3 connection has been SHUTDOWN properly the function fails with EINVAL.
Unfortunately accept(2) only returns the first address of the client.
I have a 3.13.0-37.64 generic kernel from Ubuntu, but the affected code path seems to be the same as in kernel 4.4.
Do you happen to have an idea how to work it around and obtain the client's addresses after the associtation has been SHUTDOWN? I've made the client wait a little before closing the connection, but I don't like it.
Thanks,
adam
Marcelo Ricardo Leitner
maintainerHi,
Quoted 15 lines · Adam Endrodi
Hi there,
I've got a simple case: a multi-homed client connects to a server, then disconnects right away. On the server side we receive the
SCTP_COMM_UPnotification and try to get the client's addresses withsctp_getpaddrs(). But since the L3 connection has been SHUTDOWN properly the function fails with EINVAL.Unfortunately accept(2) only returns the first address of the client.
I have a 3.13.0-37.64 generic kernel from Ubuntu, but the affected code path seems to be the same as in kernel 4.4.
Quoted 6 lines
Do you happen to have an idea how to work it around and obtain the client's addresses after the associtation has been SHUTDOWN? I've made the client wait a little before closing the connection, but I don't like it.
Thanks,
adam
Not to work around, as that seems just impossible.
But one idea to improve it would be to not schedule SCTP_CMD_DELETE_TCB right on sctp_sf_do_4_C() but when that event:
ev = sctp_ulpevent_make_assoc_change(asoc, 0, SCTP_SHUTDOWN_COMP,
0, 0, 0, NULL, GFP_ATOMIC);
is consumed by the application, or right away if the event allocation fails.
I didn't check for possible side-effects of this change, btw.
Marcelo