After digging source code for more than a week I feel I need help :)

We’re creating SCTP server side, when client sends INIT to our primary IP things are fine.

But when client sends INIT to our secondary IP… Linux 4.18.0 is sending INIT_ACK from our primary IP, which clients MUST understand...
https://datatracker.ietf.org/doc/html/rfc4960#section-5.1.2
> D) An INIT or INIT ACK chunk MUST be treated as belonging to an
> already established association (or one in the process of being
> established) if the use of any of the valid address parameters
> contained within the chunk would identify an existing TCB.

…yet our SCTP client (didn’t read that part of RFC) does not understand this INIT_ACK and fails to establish association :(

Client is some outdated soft/hardware that nobody knows how to configure properly, if that is at all possible.

So far I’ve found 20+ years old question without good answer
https://sourceforge.net/p/lksctp/mailman/lksctp-developers/thread/3E5A330C.E292CFDF%40us.ibm.com/#msg5265341

Maybe situation has changed and it became possible to influence the Kernel decision… so the source IP address of INIT_ACK IP packet be equal to destination IP address of INIT IP packet?

Attached a diagram and dump.
In this example we’d like frame 2 to have source address of 10.25.94.114

Alexander Petrossian