Date: Wed, 19 Jan 2011 23:02:10 +0100 From: Schoch Christian <e0326715@student.tuwien.ac.at> To: Michael =?iso-8859-1?b?VPx4ZW4=?= <Michael.Tuexen@lurchi.franken.de> Cc: freebsd-net@freebsd.org Subject: Re: [SCTP] transport address unconfirmed instead of inactive Message-ID: <20110119230210.17544v1efjwjjtk2@webmail.tuwien.ac.at> In-Reply-To: <67A34C76-01BD-4C5D-B0C9-B2942744B5DD@lurchi.franken.de> References: <20110117081122.65833sa4wsdugdqy@webmail.tuwien.ac.at> <67A34C76-01BD-4C5D-B0C9-B2942744B5DD@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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-unsubscribe@freebsd.org" >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110119230210.17544v1efjwjjtk2>