Dial-on-Demand problem
From: Charles Lindsey (chl_at_clerew.man.ac.uk)
Date: 06/17/03
- Next message: Joe Halpin: "Re: What computers does data pass through?"
- Previous message: Dr. David Kirkby: "Re: What computers does data pass through?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 17 Jun 2003 16:05:58 GMT
uname -a
SunOS clerew 5.7 Generic_106541-05 sun4m sparc SUNW,SPARCstation-5
I am using SUNWisdn in dial-on-demand mode to connect to the internet.
The situation is as follows, at the moment in question:
It knows all the DNS entries it needs from its nscd cache.
The interface is plumbed and UP.
The connection has timed out (so there is no IP address on DHCP lease).
There is a default route set to the (dummy) IP address of the gateway.
e.g.
ifconfig ifppp1
ifppp1: flags=28d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,UNNUMBERED> mtu 1500
inet 127.0.0.1 --> 5.5.5.5 netmask ff000000
chl% netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
5.5.5.5 127.0.0.1 UH 2 0 ifppp1
224.0.0.0 127.0.0.1 U 0 0 lo0
default 5.5.5.5 UG 0 5
127.0.0.1 127.0.0.1 UH 07406755 lo0
All very peaceful ...
Now I run a program which needs an internet connection (it was fetchmail,
actually). Here is the relevant bit of the truss, after is has created the
socket:
22916: so_socket(2, 2, 0, "", 1) = 5
22916: connect(5, 0xEFFFCB04, 16, 1) (sleeping...)
22916: connect(5, 0xEFFFCB04, 16, 1) Err#145 ETIMEDOUT
22916: close(5) = 0
So it calls connect, and sleeps until it is connected (for several
minutes, in fact). What has happened it that it has sent a packet as from
'localhost' (because that is the only identity it knows for itself, in the
absence of a DHCP lease). Here is the snoop of that first packet:
localhost -> white.gradwell.net TCP D=366 S=51565 Syn Seq=3642195262 Len=0 Win=8760 Options=<mss 1460>
But even if that packet reaches white.gradwell.net, there is no way that
an Ack can ever come back. However, sending that packet is sufficient to
trigger an automatic dialin, I am now connected to the internet, and am
given a DHCP lease of an IP address (81.144.72.176 in this occasion) and I
am also told the address of the gateway to replace that dummy 5.5.5.5.
Meanwhile, the 'connect' function notices that is has had no response and
tries again (but as far as fetchmail is concerned it is still sleeping).
Now one would have thought that, having now a decent IP address, it would
send the next packet as from that address, but no. Here is the next bunch
of snoops:
localhost -> white.gradwell.net TCP D=366 S=51565 Syn Seq=3642195262 Len=0 Win=8760 Options=<mss 1460>
localhost -> white.gradwell.net TCP D=366 S=51565 Syn Seq=3642195262 Len=0 Win=8760 Options=<mss 1460>
localhost -> white.gradwell.net TCP D=366 S=51565 Syn Seq=3642195262 Len=0 Win=8760 Options=<mss 1460>
localhost -> white.gradwell.net TCP D=366 S=51565 Syn Seq=3642195262 Len=0 Win=8760 Options=<mss 1460>
host81-144-72-176.midband.mdip.bt.net -> m1.cs.man.ac.uk ICMP Echo request
m1.cs.man.ac.uk -> host81-144-72-176.midband.mdip.bt.net ICMP Echo reply
host81-144-72-176.midband.mdip.bt.net -> ns0.cs.man.ac.uk DNS C 176.72.144.81.in-addr.arpa. Internet PTR ?
ns0.cs.man.ac.uk -> host81-144-72-176.midband.mdip.bt.net DNS R 176.72.144.81.in-addr.arpa. Internet PTR host81-144-72-176.midband.mdip.bt.net.
host81-144-72-176.midband.mdip.bt.net -> ns0.cs.man.ac.uk DNS C host81-144-72-176.midband.mdip.bt.net. Internet Addr ?
ns0.cs.man.ac.uk -> host81-144-72-176.midband.mdip.bt.net DNS R host81-144-72-176.midband.mdip.bt.net. Internet Addr 81.144.72.176
localhost -> white.gradwell.net TCP D=366 S=51565 Syn Seq=3642195262 Len=0 Win=8760 Options=<mss 1460>
localhost -> white.gradwell.net TCP D=366 S=51565 Syn Seq=3642195262 Len=0 Win=8760 Options=<mss 1460>
You will see that I did a 'ping' of an unrelated machine in the middle,
just to demonstrate that it knew perfectly well how to send packets to the
internet.
And, at the end of all those attempts from 'localhost', the connect call
timed out.
So, is this a bug/feature of 'connect'?
Or is it a bug/feature of SUNWisdn?
Or is there a workaround that fetchmail ought to have been using?
And it isn't just fetchmail. I suspect that netscape and opera are having
just the same problem. But note that attempte to do DNS lookups do not
have this problem (I think because, when it has noticed failure on
the initial packet, it tries again with a different DNS server, by which
time it knows how to do it properly).
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
- Next message: Joe Halpin: "Re: What computers does data pass through?"
- Previous message: Dr. David Kirkby: "Re: What computers does data pass through?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
