From owner-freebsd-net@FreeBSD.ORG Sun May 1 14:33:48 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 54825106566B for ; Sun, 1 May 2011 14:33:48 +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 E2DC58FC0A for ; Sun, 1 May 2011 14:33:46 +0000 (UTC) Received: from [192.168.1.192] (p508FA5B3.dip.t-dialin.net [80.143.165.179]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 8F5061C0C0BCC; Sun, 1 May 2011 16:33:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <20110501131048.22413db5jyxywss8@webmail.tuwien.ac.at> Date: Sun, 1 May 2011 16:33:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13E5D4BB-5B2C-42B3-A43E-0F260317DE6B@lurchi.franken.de> References: <20110430091148.31393q3py4j4bg38@webmail.tuwien.ac.at> <20110430121518.25761cpmtrp0jtpy@webmail.tuwien.ac.at> <20110501131048.22413db5jyxywss8@webmail.tuwien.ac.at> To: Schoch Christian X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: [SCTP] ICMP unreachable message reenables data transmit 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: Sun, 01 May 2011 14:33:48 -0000 On May 1, 2011, at 1:10 PM, Schoch Christian wrote: >> On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote: >>>=20 >>>> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote: >>>>=20 >>>>> During a measurement with CMT-SCTP and PF i figured out, that = sometimes a ICMP Destination unreachable message triggers a message = transmission on an inactive data path that has been primary before. >>>>>=20 >>>>> It looks as the ICMP message is reseting the inactive state back = to active without reseting RTO. >>>>>=20 >>>>> This behavior is triggered by a returning heartbeat message when = no ICMP unreachable by data is sent quite before. >>>>>=20 >>>>> Test system are two multi-homed hosts with FreeBSD8.1 and a WANem = host between. >>>>>=20 >>>>> A wireshark log can be provided on demand (quite large). >>>> Hi Christian, >>>>=20 >>>> any chance to upgrade the FreeBSD machines to head or to use newer >>>> SCTP sources, which I could provide? It would require a = recompilation >>>> of the kernel... >>>=20 >>> It is possible, but the results could be provided not until next = week >>> if a reboot is necessary. >>> I can use any sources you could provide me since nothing else is = done at this systems. >> OK, but maybe I can try to understand what is going on. >>=20 >> How many paths do you have? One is inactive, but was primary, so it >> is confirmed. On another one, you get an ICMP (which one? Port = unreachable, >> host unreachable, ...). Do you have more than two paths? >=20 > Setup looks like this: >=20 > -------- ----cut--- > Host A WANem Host B > -------- ---------- >=20 > Transfer is running on both path from A to B till the primary link is = cut between WANem and the receiver and the whole transfer switches to = the second path. The ICMP message (Host not reachable with a Heartbeat = as attachment) is received on the primary interface from WANem host. OK, understood. >=20 > As I tested this morning, the primary path is switching to unreachable = due to the ICMP message but should be in this state quite before by = exceeding path.max_retrans. > So this ICMP message does two things: > - Set the primary path to unreachable > - Triggers something to retry data transfer on the primary path. After looking at the tracefile, I somewhat agree. * Do you see something like ICMP (thresh ??/??) takes interface ?? down on the console? This would be printed if the ICMP takes the path to unreachable? (It should also be in /var/log/messages) * If the path is already unreachable, nothing should happen in response to the ICMP message. So the question is: Is the path unreachable before the ICMP message is received? Is your application monitoring the SCTP notification? What about the above printout from the kernel? Best regards Michael >=20 >> The ICMP message would not reset the RTO, since you need an ACKed TSN >> or a HB-ACK to to that. Since it is inactive, it is missing these. >>=20 >> Sending on an inactive path is OK, as soon as you enter the dormant >> state, which means all your paths are inactive. >>=20 > Transfer is still running on second link which is active. That sounds good. >=20 >> Are you using the PF support for CMT? >=20 > Yes, but without NR-SACK and DAC. OK. >=20 > I uploaded the pcap file to: > http://37116.vs.webtropia.com/cmt_2.pcap That was helpful! >=20 > Best regards, > Christian >=20 >>=20 >> Best regards >> Michael >>>=20 >>>>=20 >>>> Are you using IPv4 or IPv6? >>>>=20 >>>=20 >>> IPv4 >>>=20 >>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> Regards, >>>>> Schoch Christian >>>>> _______________________________________________ >>>>> 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 >>>> _______________________________________________ >>>> 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 >=20 >=20