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

Is your listener calling sctp_bindx with the IP 127.0.0.2 ?

On 02.12.2025 14:22, Pau Espin Pedrol wrote:
> 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 
>
>
>