Re: SCTP client discarding INIT_ACK sent with different remote IP address from multihomed SCTP server

Hi Andreas,

Please, re-read my first email in the thread again, in there I mention 
there that I'm also testing with connectx(B,A) and in that case it also 
fails (see the pcap file I attached where the first INIT_ACK is ignored 
and then the client stack retries INIT with dst IP addr A).

client                server
                       bindx(A,B)
bindx(C) /* doesn't matter here */
connectx(B,A)
------------INIT----->B
<----------INIT_ACK---A
[client ignores INIT_ACK and tries with dst A]
-----------INIT------>A
<----------INIT_ACK---A
[client accepts the INIT_ACK this time]

In the scenario above, imho it makes no sense that the INIT_ACK is 
dropped. And if it makes sense, then it's server fault imho which 
shouldn't be doing that.

And as mentioned this seems to be working fine on some linux stacks (eg. 
debian13) while it doesn't on others (eg. Archlinux kernel latest and 
LTS packages).

The connectx(B) to a server with bindx(A,B) is just a simplification of 
the problem as a showcase of something being wrong at client, server or 
both.


On 12/2/25 17:25, Andreas Fink wrote:
> It seems its missing the paramter to specify multiple IPs for connectx. 
> So you can not reproduce the issue with it.

I *am* reproducing the issue with sctp_darn, with the mentioned commands 
I already shared. So easy to reproduce, at least on Archlinux, but not 
on debian13.

> 
> 
> Whats happening here is your client connects  to 127.0.0.1 only (first 
> case) or  127.0.0.2 only (second case). you are not establishing a 
> multihomed connection to both ips as the server side is expecting.
> 
> Thats where your mismatch comes from.


Is that specified somewhere? I am not aware it's specified anywhere that 
one needs to connect() on the exact same set of IP addresses where the 
server binds() to. Again, as mentioned that doesn't make sense to me, 
specially since that set is mostly used during initial handshake time.
A
lso, what I read from the specs seem to state that at least for the 
connectx(B,A) case it should work, which doesn't currently work on my 
kernel 6.17.9-arch1-1, tested easy with sctp_darn.


(forwarding the full response since it was not replied to the list:)

On 12/2/25 17:25, Andreas Fink wrote:
 > sorry I read the man page wrong for sctp_darn.
 >
 > It seems its missing the paramter to specify multiple IPs for connectx.
 > So you can not reproduce the issue with it.
 >
 >
 > Whats happening here is your client connects  to 127.0.0.1 only (first
 > case) or  127.0.0.2 only (second case). you are not establishing a
 > multihomed connection to both ips as the server side is expecting.
 >
 > Thats where your mismatch comes from.
 >
 >
 > So the server listens to 127.0.0.1  and 127.0.0.2 and feels free to
 > reply on either while the client only expects  the ip it originally
 > connected to to send it a reply. so you get a 50/50 chance of working.
 >
 > if the server does bindx(A,B) then the client MUST connect with
 > connectx(A,B) but sctp_darn seems to do connectx(A) or connectx(B) as
 > you can not specify both and then gets a reply from the other IP and the
 > kernel drops it because it doesnt match the initial connection request
 > which only wanted A or B so it doesnt find a matching sctp association
 > opeened by sctp_darn.
 >

-- 
- Pau Espin Pedrol <[email protected]>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte