Re: dialup dns delay

As Tony Moore wrote on 14 Sep 2007:

Recently, my dialup connection, using Hermes/MPro/Netsurf/wget/RO6.06,
has been subject to a delay, and I should be grateful if someone could
suggest its cause.

[snip]

... as of a few weeks ago, launching a URL via browser, or download
via wget, results in a delay of up to 60 seconds, while the DNS
resolves the IP address of the URL. This happens at the _start_ of
each_and_every dialup session but, after the first URL has been
resolved, launching a second URL proceeds normally, without delay.

To demonstrate this, if I ping the DNS, immediately after connecting:

PING 194.151.228.18 (194.151.228.18): 56 data bytes
64 bytes from 194.151.228.18: icmp_seq=50 ttl=246 time=320 ms
64 bytes from 194.151.228.18: icmp_seq=51 ttl=246 time=300 ms
64 bytes from 194.151.228.18: icmp_seq=53 ttl=246 time=260 ms
--- 194.151.228.18 ping statistics ---
54 packets transmitted, 3 packets received, 94% packet loss
round-trip min/avg/max = 260.000/293.333/320.000 ms

The high packet loss is evidenced by a long delay.

Not merely of a long delay. It is evidence of packets being lost. Your
ICMP packets do not arrive at 194.151.228.18, or the replies do not make
it back to your machine.

However, pinging the DNS a second time (or a different address), shows
expected behaviour:

PING 194.151.228.18 (194.151.228.18): 56 data bytes
64 bytes from 194.151.228.18: icmp_seq=0 ttl=246 time=290 ms
64 bytes from 194.151.228.18: icmp_seq=1 ttl=246 time=340 ms
64 bytes from 194.151.228.18: icmp_seq=2 ttl=246 time=320 ms
--- 194.151.228.18 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 290.000/316.666/340.000 ms

Note that the two commands above do *not* cause an address resolution by
the DNS. Both pings are done directly to the IP address (which
presumably is of the ISP's primary DNS machine). Something is happening
on the IP level, probably somewhere in the dialup (SLIP) connection.

The initial delay, above, might suggest that the ISP's DNS is broken
but, if my account is configured to use a _public_ DNS (known to work
correctly with a different ISP), similar results are obtained.

This supports the notion that there is no problem in the IPS's DNS. It
is a problem with the address resolution (ARP).

My guess is that you are given a dynamic IP address when you dail in,
and it takes a while before packets sent to your (newly established) IP
address actually start arriving at your machine.

--
Erik G http://www.xs4all.nl/~erikgrnh
== 'From:' address is a spam trap. Do not use
== See web site for email address
.

Relevant Pages

  • Re: Ping response times - same after upgrade of bandwidth
    ... The ping response times to the ... - Processing delay (how long from the time a request is received until ... of pings with short packets and with long packets (as long as they are ... the same response time and all the long packets have about the same ...
    (comp.dcom.sys.cisco)
  • dialup dns delay
    ... via wget, results in a delay of up to 60 seconds, while the DNS resolves ... To demonstrate this, if I ping the DNS, immediately after connecting: ... 54 packets transmitted, 3 packets received, 94% packet loss ... The high packet loss is evidenced by a long delay. ...
    (comp.sys.acorn.networking)
  • Re: SUMMARY: Odd Solaris 10 DNS issue
    ... resolver routines reference ipnodesand then DNS, ... packets transmitted, 1 packets received, 0% packet loss ... shortcut the lookup and simply return "adminbox" on the ping. ...
    (SunManagers)
  • Re: dialup dns delay
    ... Not merely of a long delay. ... It is evidence of packets being lost. ... the ISP's primary DNS machine). ...
    (comp.sys.acorn.networking)
  • Dummynet and fragments
    ... I want to set the delay, bandwidth, etc. limit in BSD4, using something like ... if I 'ping' between these two machines, everything is fine, but if I 'ping' with a packet size of, ie, 2000, no packets arrive at the receiver. ... Does it have to do with fragmented packets? ...
    (freebsd-net)