From owner-freebsd-net@FreeBSD.ORG Sun May 1 11:10:52 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 28AD61065670 for ; Sun, 1 May 2011 11:10:52 +0000 (UTC) (envelope-from e0326715@student.tuwien.ac.at) Received: from mr.tuwien.ac.at (mr2-n.kom.tuwien.ac.at [128.130.2.110]) by mx1.freebsd.org (Postfix) with ESMTP id BF4548FC18 for ; Sun, 1 May 2011 11:10:51 +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 p41BAmCk024566; Sun, 1 May 2011 13:10:49 +0200 (MEST) 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 p41BAmiY017785; Sun, 1 May 2011 13:10:48 +0200 Received: (from apache@localhost) by webmail1.zserv.tuwien.ac.at (8.13.8/8.13.8/Submit) id p41BAmFM017784; Sun, 1 May 2011 13:10:48 +0200 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; Sun, 01 May 2011 13:10:48 +0200 Message-ID: <20110501131048.22413db5jyxywss8@webmail.tuwien.ac.at> Date: Sun, 01 May 2011 13:10:48 +0200 From: Schoch Christian To: Michael =?iso-8859-1?b?VPx4ZW4=?= References: <20110430091148.31393q3py4j4bg38@webmail.tuwien.ac.at> <20110430121518.25761cpmtrp0jtpy@webmail.tuwien.ac.at> In-Reply-To: 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 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 11:10:52 -0000 > On Apr 30, 2011, at 12:15 PM, Schoch Christian wrote: >> >>> On Apr 30, 2011, at 9:11 AM, Schoch Christian wrote: >>> >>>> 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. >>>> >>>> It looks as the ICMP message is reseting the inactive state back >>>> to active without reseting RTO. >>>> >>>> This behavior is triggered by a returning heartbeat message when >>>> no ICMP unreachable by data is sent quite before. >>>> >>>> Test system are two multi-homed hosts with FreeBSD8.1 and a WANem >>>> host between. >>>> >>>> A wireshark log can be provided on demand (quite large). >>> Hi Christian, >>> >>> 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... >> >> 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. > > 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? Setup looks like this: -------- ----cut--- Host A WANem Host B -------- ---------- 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. 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. > 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. > > Sending on an inactive path is OK, as soon as you enter the dormant > state, which means all your paths are inactive. > Transfer is still running on second link which is active. > Are you using the PF support for CMT? Yes, but without NR-SACK and DAC. I uploaded the pcap file to: http://37116.vs.webtropia.com/cmt_2.pcap Best regards, Christian > > Best regards > Michael >> >>> >>> Are you using IPv4 or IPv6? >>> >> >> IPv4 >> >> >>> Best regards >>> Michael >>>> >>>> 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" >>>> >>> >>> _______________________________________________ >>> 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" >>> >> >> > >