RestComm / jdiameter

RestComm Diameter Stack and Services
http://www.restcomm.com/
GNU Affero General Public License v3.0
111 stars 152 forks source link

SCTP-multihoming server, INIT ACK does not contain IPv4 addresses #130

Open killdashnine opened 6 years ago

killdashnine commented 6 years ago

When running jdiameter as a server with two address:

<LocalPeer>
                ...
                <IPAddresses>
                        <IPAddress value="1.2.3.4" />
                        <IPAddress value="5.6.7.8" /> 
                </IPAddresses>
                ....
</LocalPeer>

Peer (2.3.4.5/6.7.8.9) sends INIT to 1.2.3.4 with: IPv4 address parameter 2.3.4.5. IPv4 address parameter 6.7.8.9

Server (jdiameter 1.2.3.4/5.6.7.8) responds with INIT ACK with NO IPv4 address parameters, although:

 ENDPT     SOCK   STY SST HBKT LPORT   UID INODE LADDRS
ffff8800d8bbd900 ffff8800da973800 2   10  63   3868      0 51257 2.3.4.5 
ffff8800d8936200 ffff8800da8c2b40 2   10  63   3868      0 51254 6.7.8.9

When checking the logs jdiameter is running two separate server sockets for those IPs as matches above, instead of adding the 6.7.8.9 as a secondary address....

When running freeDiameter: ffff88011a3ab000 ffff8800d9e3d080 2 1 3 36 4 0 0 0 12811 3868 49128 1.2.3.4 5.6.7.8 <-> *2.3.4.5 6.7.8.9 1500 8 8 4 0 0 21 1 0 212992 212992 So JDiameter is not binding the address to the same socket to give true multi-homing

gsaslis commented 6 years ago

Hi @killdashnine,

Thanks for raising the issue. It seems related to #25 .

It sounds like you have a good understanding of the issue - would you like to have a go at contributing this as a feature?

Please let me know so I can put you in touch with someone from the JDiameter maintainers. ;)

killdashnine commented 1 year ago

Hi, would you still accept a pull request for this? Just fixed the SCTP client part, still need to fix the network guard type.

So with my current patches I am able to create a connection to say a DRA with INIT containing multiple IPs and HB REQ/ACK work between primary and secondary IPs as expected.

I am expecting the network guard type (so for server sockets) to be a similar patch as the client, once that is covered too #25 will be fixed too completely.