Date: Sat, 12 Apr 2003 07:19:17 EDT From: BelletJr@aol.com To: tlambert2@mindspring.com Cc: net@freebsd.org Subject: Re: connect(2) behavior with unreacheable hosts Message-ID: <134.1e1ff9dc.2bc95035@aol.com>
next in thread | raw e-mail | index | archive | help
>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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?134.1e1ff9dc.2bc95035>