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

Hi,

On 12/2/25 13:13, Andreas Fink wrote:
> You wrote:
> 
>      "That doesn't seem to be problem here though, since indeed the 
> INIT_ACK is announcing both 127.0.0.1 and 127.0.0.2"
> 
> Note: that this is in the REPLY. The question is whats in the original 
> REQUEST. The node which is sending an INIT should expect the answer to 
> come from any of these IP's.
> If he is only connecting to one, then he 
> might not recognize the connection and drop it.

The original REQUEST (INIT) contains AFAIU the local addresses of the 
client, which in all cases binds to only 1 IP address (127.0.01), so 
AFAIU not relevant here, this doesn't change in any of the scenarios. 
Since the client only binds to 1 local IP address, no "Address" SCTP 
param is included during INIT.


 > This kind of issue often > arises if one side has a single ip 
configure and the other has two
> configured due to a misconfiguration.

This indeed raises another question: Is the spec mentioning somewhere 
that one should use the exact same subset of IP addresses when 
configuring both client and server sides? I wasn't aware of this 
limitation, is this written somewhere? I was expecting server binding on 
A+B and client connecting to B would be fine enough, specially since 
AFAICT the remote addr list at the client is only used at connect time, 
afterwards it uses the addr list provided by the server.



> Then it depends on who hits first 
> if it works or not. Is this a client server (like in M3UA) or a peer to 
> peer setup (like in M2PA).

I'm talking about a client-server (connected socket) SCTP setup.


> 
> Its kind of a grey undefined zone here but I presume giving Sigtran 
> comes from redundant SS7 kind of setups, you tend to have the two IP's 
> on two totally different physical subnets and the reply which goes to 
> one of the IP is kind of expected to come back from that physical path. 
> Now this logic fails completely on local loop interfaces. We do this 
> normally by using two separate IP routing tables. So if the answer comes 
> from another IP, it would also go out on the other physical cable (which 
> is not automatically the case if you leave it to the kernel).

I am aware by doing all sort of interface/routing splitting this problem 
can be circumvented, but I'm surprised this kind of simple setup fails 
to work, specially using the same stack in client and server, and 
specially since some versions of the stack seem to work fine while 
others don't. So imho something's wrong somewhere in the linux sctp 
stack on some newish linux systems apparently.

> 
> The question which arrises here is also if there is any benefit of even 
> using two IP's on a loopback interface.  You clearly wont get any 
> failover/redundancy benefit on a lo interface.
> 
> Are you able to reproduce the issue on a ethernet interface as well?
> 

I agree, much benefit in principle, other than maybe being able to do IP 
address management/changes without tearing down existing connections, etc.

In this special case (which I think is also a valid one and even 
common), we make use of the loopback device to do a multihomed setup to 
easily test that a given program is indeed binding all of the IP 
addresses it was configured with when using the socket.

 > PS: can you send me the  pcap file or a source snipped to reproduce?

You can easily reproduce (if you are "lucky" and your kernel behaves 
like mine) by using the sctp_darn commands I shared in my initial post.

I'm also sharing here 2 pcaps for the "-c 127.0.0.2" and the "-c 
127.0.0.2 -c 127.0.0.1" cases, where it can be seen in both that 
INIT_ACK is discarded by the client:

http://pespin.espeweb.net/~pespin/tmp/osmocom/sctp_init_ack/sctp_darn_connect_to_127_0_0_2_fails.pcapng.gz
http://pespin.espeweb.net/~pespin/tmp/osmocom/sctp_init_ack/sctp_darn_connect_to_127_0_0_2_then_127_0_0_1.pcapng.gz


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