On Jan 19, 2011, at 11:02 PM, Schoch Christian wrote: > Dear Michael, > > as I could figure out, the problem with UNCONFIRMED is solved. My test tools > is based on lksctp-tools and written for linux testing. Now the problem here > is that there is a inconsistency between linux and FreeBSD of the return > value of spinfo_state. Perhaps these return values could be standardized in > the sctp socket-api. Leaving a note on the linux dev mailing list on this > topic. Hi Christian,
the actual values are not standardized, only the names of the constants. If you use the names and recompile the code when moving from Linux to FreeBSD, it should work. > > The other problem may depend on the fact, that i did the test with vmware and > a remote machine using only one network interface with 2 different Addresses > assigned. Furthermore, both addresses had a netmask of 255.255.0.0 so both > addresses were located in the same subnet. Did the same test with 2 Vmware > machines and other addresses which was successful. Yes, that mask may result in problems. Thanks for reporting. Best regards Michael > > Regards, > Christian > >> On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote: >> >>> I did some test with multihoming and failover. My problem is that if one >>> transport failes it never comes back to active (no heartbeats are sent any >>> more). >>> >>> My setup: >>> >>> FreeBSD 8.1 Linux 2.6.36 >>> 172.16.1.4 --------- 172.16.1.3 >>> 172.17.1.4 --------- 172.17.1.3 >>> >>> Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped. >>> >>> The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected. >> Which side is the client, which one is the server? Which side is sending user >> data? >>> If the transfer on this transport failes, it is switching to 17.1.4 & >>> 17.1.3 as expected. >> How do you fail the connection? Disconnecting the cable? Configuring >> dummynet? >>> 172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE >> So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For which >> address? 172.16.1.3? >>> Now, if the first connection is available again, the first transport >>> address of FreeBSD stays at unconfirmed with no HB sent to 16.1.3 >>> Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from 17.1.4 to >>> 16.1.3 (which is dropped). >>> >>> So why are HBs sent from new primary instead of received address ? As >>> specified in RFC it should sent back from address, it receives the HB >>> packet. >> Correct. Somethings seems strange. Please answer the above and I will try to >> reproduce >> the problem. >> >> Thanks for the report. >> Best regards >> Michael >>> >>> Regards, >>> Christian >>> >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >> >> > > > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
