sctp_getpaddrs() on a SHUTDOWN association

sctp_getpaddrs() on a SHUTDOWN association

[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_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

Re: sctp_getpaddrs() on a SHUTDOWN association

[Marcelo Ricardo Leitner]

Hi,

On Fri, May 13, 2016 at 12:35:33PM +0200, Adam Endrodi wrote:
> 
> 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

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