Date: Wed, 19 Jan 2011 23:08:43 +0100 From: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de> To: Schoch Christian <e0326715@student.tuwien.ac.at> Cc: freebsd-net@freebsd.org Subject: Re: [SCTP] transport address unconfirmed instead of inactive Message-ID: <ED446017-12A6-4632-8108-EEF704550ECC@lurchi.franken.de> In-Reply-To: <20110119230210.17544v1efjwjjtk2@webmail.tuwien.ac.at> References: <20110117081122.65833sa4wsdugdqy@webmail.tuwien.ac.at> <67A34C76-01BD-4C5D-B0C9-B2942744B5DD@lurchi.franken.de> <20110119230210.17544v1efjwjjtk2@webmail.tuwien.ac.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 19, 2011, at 11:02 PM, Schoch Christian wrote: > Dear Michael, >=20 > 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. >=20 > 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 >=20 > Regards, > Christian >=20 >> On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote: >>=20 >>> 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). >>>=20 >>> My setup: >>>=20 >>> FreeBSD 8.1 Linux 2.6.36 >>> 172.16.1.4 --------- 172.16.1.3 >>> 172.17.1.4 --------- 172.17.1.3 >>>=20 >>> Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped. >>>=20 >>> 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). >>>=20 >>> 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. >>=20 >> Thanks for the report. >> Best regards >> Michael >>>=20 >>> Regards, >>> Christian >>>=20 >>>=20 >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>>=20 >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>>=20 >>=20 >>=20 >=20 >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ED446017-12A6-4632-8108-EEF704550ECC>