From owner-freebsd-net@FreeBSD.ORG Sat Apr 12 04:19:25 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A270D37B404; Sat, 12 Apr 2003 04:19:25 -0700 (PDT) Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7768343FB1; Sat, 12 Apr 2003 04:19:24 -0700 (PDT) (envelope-from BelletJr@aol.com) Received: from BelletJr@aol.com by imo-d04.mx.aol.com (mail_out_v34.21.) id d.134.1e1ff9dc (18555); Sat, 12 Apr 2003 07:19:17 -0400 (EDT) From: BelletJr@aol.com Message-ID: <134.1e1ff9dc.2bc95035@aol.com> Date: Sat, 12 Apr 2003 07:19:17 EDT To: tlambert2@mindspring.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: AOL 5.0 for Windows sub 116 cc: current@freebsd.org cc: net@freebsd.org Subject: Re: connect(2) behavior with unreacheable hosts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2003 11:19:26 -0000 >Dans un e-mail dat=E9 du 11/04/03 23:21:55 Paris, Madrid (Heure d'=E9t=E9),= =20 tlambert2@mindspring.com a =E9crit : > >> >Because it can't detect an infinite routing loop. >>=20 >> Then why can't it detect an infinite routing loop? :) It does not impleme= nt >> the classic three-way handshake of a TCP connection establishment?? > >It sends SYN and waits for SYN/ACK before sending an ACK. The wait >is indenfinite, unless the machine receives an ICMP "host unreachable" >or similar connection reject packet. > >Most likely, ICMP is disabled somewhere between you and the >other end. Probably at your firewall. You should look at a >tcpdump of the traffic between the two endpoints which occurs >during the connection request, to find out for sure. If you >don't like raw tcpdump (or can't read it easily), then use >"ethereal" from ports. > >As to why it can't detect it without the ICMP, it's because it's >not possible to compute transitive closure over the graph of your >local routing table, and all the routing tables between you and >the other end, because the memory isn't local. 8-) 8-). > > >> If this is the case, I think the man page is not precise enough. It state= s >> "If the socket is of type SOCK_STREAM, this call attempts to make a >> connection to another socket" and later on "The connect() function return= s >> the value 0 if successful". > >You're mixing up two different usages of connect(). > > >> BTW we can imagine that the majority of programs aren't crafted to handle >> this case. > >Probably not... the majority of programs probably assume that >your network is set up correctly. 8-). > >> Have a look for example to the simple "daytime.c" program from the >> developper handbook. It just doesn't do anything if time.nist.gov is >> unreachable because of an infinite routing loop. > >I still don't know what you mean by "infinite routing loop"; there's >really no such thing. If you try to insert one on a single host, >the insertion attempt that would cause the loop will be rejected by >the "route add". It's a radix tree; being hierarchical, it can't >loop, since the idea of a loop is not supported by the data structure. > >The only purpose of the routing code is selection of "next hop", and >that dictates "interface to use". And that's all it does. > >It's up to intermediate hosts to indicate route failures via ICMP >messages (Internet Control Message Protocol). > >If you disable ICMP, be ready to have your foot shot off. > >-- Terry Thank you Terry for your instructive explanation (though Barney has found it= =20 seems to be a real bug ;-). The infinite loop that seems to exist when tracerouting happens while I try=20 to access an Internet host from my provider network without having=20 authenticate before. Not a usual set up, but it was just a test... In this case, after a few hops, traceroute seems to show packets exchanged=20 indefinitely between 2 interfaces. >You're mixing up two different usages of connect(). Honestly, I don't think so. The RETURN VALUES section relates to all socket=20 types that can be used, I hope :)