From owner-freebsd-net@FreeBSD.ORG Wed Jan 19 22:02:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85267106564A for ; Wed, 19 Jan 2011 22:02:14 +0000 (UTC) (envelope-from e0326715@student.tuwien.ac.at) Received: from mr.tuwien.ac.at (mr1-n.kom.tuwien.ac.at [128.130.2.109]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8EE8FC0A for ; Wed, 19 Jan 2011 22:02:13 +0000 (UTC) Received: from webmail1.zserv.tuwien.ac.at (webmail1.zserv.tuwien.ac.at [128.130.35.11]) by mr.tuwien.ac.at (8.13.7/8.13.7) with ESMTP id p0JM2BVu013447; Wed, 19 Jan 2011 23:02:11 +0100 (MET) Received: from webmail1.zserv.tuwien.ac.at (localhost.localdomain [127.0.0.1]) by webmail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id p0JM2Box013080; Wed, 19 Jan 2011 23:02:11 +0100 Received: (from apache@localhost) by webmail1.zserv.tuwien.ac.at (8.13.8/8.13.8/Submit) id p0JM2B9Y013079; Wed, 19 Jan 2011 23:02:11 +0100 X-Authentication-Warning: webmail1.zserv.tuwien.ac.at: apache set sender to e0326715@student.tuwien.ac.at using -f Received: from vie-lim-ge-1-2.onenet.at (vie-lim-ge-1-2.onenet.at [194.24.158.1]) by webmail.tuwien.ac.at (Horde Framework) with HTTP; Wed, 19 Jan 2011 23:02:10 +0100 Message-ID: <20110119230210.17544v1efjwjjtk2@webmail.tuwien.ac.at> Date: Wed, 19 Jan 2011 23:02:10 +0100 From: Schoch Christian To: Michael =?iso-8859-1?b?VPx4ZW4=?= References: <20110117081122.65833sa4wsdugdqy@webmail.tuwien.ac.at> <67A34C76-01BD-4C5D-B0C9-B2942744B5DD@lurchi.franken.de> In-Reply-To: <67A34C76-01BD-4C5D-B0C9-B2942744B5DD@lurchi.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Wed, 19 Jan 2011 22:20:08 +0000 Cc: freebsd-net@freebsd.org Subject: Re: [SCTP] transport address unconfirmed instead of inactive X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:02:14 -0000 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" >> > >