Skip site navigation (1)Skip section navigation (2)
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>