From owner-freebsd-net@FreeBSD.ORG Wed Jan 19 22:08:46 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 4A8BA1065670 for ; Wed, 19 Jan 2011 22:08:46 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id A6E1E8FC16 for ; Wed, 19 Jan 2011 22:08:45 +0000 (UTC) Received: from [192.168.1.113] (p508F9B30.dip.t-dialin.net [80.143.155.48]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 8DF7D1C0C0BD6; Wed, 19 Jan 2011 23:08:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110119230210.17544v1efjwjjtk2@webmail.tuwien.ac.at> Date: Wed, 19 Jan 2011 23:08:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110117081122.65833sa4wsdugdqy@webmail.tuwien.ac.at> <67A34C76-01BD-4C5D-B0C9-B2942744B5DD@lurchi.franken.de> <20110119230210.17544v1efjwjjtk2@webmail.tuwien.ac.at> To: Schoch Christian X-Mailer: Apple Mail (2.1082) 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:08:46 -0000 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