Bug 104301

Summary: Connect failure on sctp socket under debug
Product: Networking Reporter: Riccardo Manfrin (riccardomanfrin)
Component: OtherAssignee: Stephen Hemminger (stephen)
Status: NEW ---    
Severity: normal CC: nhorman, szg00000, vyasevich
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.13.0-63-generic Subsystem:
Regression: No Bisected commit-id:

Description Riccardo Manfrin 2015-09-09 13:57:38 UTC 
When starting an sctp client with gdb, I experience a connect failure (-1 is returned), with errno 106 (Transport endpoint is already connected).

If I then cat /proc/net/sctp/assocs, I see the connection and I see the successful handshake on wireshark.

If I ignore the connect failure, and pretend I'm actually connected, I can send and receive packets without any trouble.

The same client application, run not-under-gdb, does not exhibits the issue and the connect returns 0.
Comment 1 Neil Horman 2015-09-09 15:15:39 UTC 
Does the application in question have any signal handlers that are registered with SA_RESTART set?  My first thought would be that a call to sctp_connect might be aborted due to EINTR after the association has been set, but the syscall layer restarts the connect without the application knowing, leading to an EISCONN error even though is managed to connect.

If thats the case, not sure what the solution would be yet, but I image we have to catch or block EINTR somewhere in sctp_primitive_ASSOCIATE, or deeper in the state machine.
Comment 2 Riccardo Manfrin 2015-09-09 15:53:37 UTC 
I could not find any registered signal handlers by the application (I also smelled that signals could be involved, but did not find any evidence).
Comment 3 Neil Horman 2015-09-09 17:51:09 UTC 
can you attach a stap script to sctp_connect in the kernel, and see if its getting called multiple times?
Comment 4 Vlad Yasevich 2015-09-15 17:23:36 UTC 
Or you could try:

echo -n "module sctp func sctp_connect +p" > /sys/kernel/debug/dynamic_debug/control

and try the gdb app.

There should be an entry in the log for ever attempt call sctp_connect.