Re: SCTP client discarding INIT_ACK sent with different remote IP address from multihomed SCTP server
Pau Espin Pedrol <[email protected]>
| Newsgroups | org.kernel.vger.linux-sctp |
|---|---|
| Message-ID | <[email protected]> |
Hi, On 12/2/25 16:27, Andreas Fink wrote: > that sounds correct but how about the client? how is that one calling ? > is it having -h 127.0.0.1 -b 127.0.0.1 ? > I'm not sure I'm following you Andreas, since I think I already mentioned the working vs non-working scenario in the initial email, and shared a pcap file for the non-working one afterwards, so I'm not sure what information is missing or was not clear from my side. By the way, I think you probably don't mean "-b", which is a --bindx-rem "remove" param. working case: "sctp_darn -H 127.0.0.1 -P 8000 -c 127.0.0.1 -p 2905 -s" non-working case: "sctp_darn -H 127.0.0.1 -P 8000 -c 127.0.0.2 -p 2905 -s" I don't really think it's possible to make an even simpler scenario. Server listens on addresses A and B, and client connects (tx INIT) to B, while server decides to answer (INIT_ACK) using address A. AFAICT, if my sctp linux stack client receives an INIT_ACK with a src addr != INIT dst addr it seems to drop it. So IMHO either client or server sctp stack (or both) needs fixing/improving, since the stack in my system doesn't seem to be able to interopt with itself in a simple setup on the loopback interface anymore (it seems it did/does on other versions, we currently run fine the same setup in jenkins). -- - 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