[Gllug] Anyone having broadband (probably PlusNet) problems today?

[Russell Howe]

On Wed, Mar 23, 2005 at 02:54:11PM +0000, Richard Jones wrote:
>   $ ping -M do -s 1432 www.bbc.co.uk
>   PING www.bbc.net.uk (212.58.224.116) 1432(1460) bytes of data.
>   1440 bytes from www16.thdo.bbc.co.uk (212.58.224.116): icmp_seq=1 ttl=249 time=87.8 ms

Looks good

> For packet sizes >= 1433, <= 1472:
> 
>   rich at arctor:~$ ping -M do -s 1472 www.bbc.co.uk
>   PING www.bbc.net.uk (212.58.224.123) 1472(1500) bytes of data.
>   ^C
>   --- www.bbc.net.uk ping statistics ---
>   3 packets transmitted, 0 received, 100% packet loss, time 1999ms

OK, this is wrong. The packets are being dropped by some device
somewhere which is *NOT* sending an ICMP fragmentation-needed response
(or it is, and the response is being filtered - some people 

> 
> For package sizes >= 1473:
> 
>   rich at arctor:~$ ping -M do -s 1473 www.bbc.co.uk
>   PING www.bbc.net.uk (212.58.224.123) 1473(1501) bytes of data.
>   From arctor.home.annexia.org (10.0.0.249) icmp_seq=1 Frag needed and DF set (mtu = 1500)

I assume the ping packets are going over an ethernet link before they
hit your ISP. 1500 is the MTU of ethernet, so these are probably being
rejected by your PC itself, saying "I can't do that, Dave^WRich"

> So it's a large packet / MTU problem, as suspected.

Yes, the next thing is to discover where. You can use a version of
traceroute which can send arbitrarily-sized messages and which sets the
DF flag.

I just discovered a tool called “tracepath”, available in Debian as the
“iputils-tracepath”

 1:  xiao.siksai.co.uk (82.133.8.12)                        0.699ms pmtu 1500
 1:  doufu.siksai.co.uk (82.133.8.9)                        0.542ms
 2:  192.168.254.1 (192.168.254.1)                          3.980ms
 3:  192.168.254.1 (192.168.254.1)                        asymm  2 5.612ms pmtu 1492
 4:  lon1-10.nildram.net (213.208.106.195)                 72.551ms
 5:  rt-lonap-a.thdo.bbc.co.uk (193.203.5.90)             asymm  4 66.461ms
 6:  212.58.238.153 (212.58.238.153)                      asymm  5 74.797ms
 7:  www26.thdo.bbc.co.uk (212.58.224.126)                asymm  6 67.136ms reached
     Resume: pmtu 1492 hops 7 back 6

Note that the PMTU (path MTU) was detected as dropping once it hit
192.168.254.1, which is my downstairs DSL router, running PPPoE (PPPoE
MTU would appear to be 1492).

You want to run this both ways - from your machine, and from another
machine somewhere on the Internet. This is where having a shell account
on someone else's machine (or your own machine, located elsewhere) is
handy. Also, you want to be fairly certain the remote host you are using
to test has not MTU issues of its own!

Once you have the figures for the minimum MTU between you and
$remotehost (this is the path MTU, the maximum size IP datagram which
can pass unfragmented along the entire path) then you can start to check
that for all datagrams sent between these hosts (in both directions)
result in an ICMP fragmentation-needed packet being sent from whichever
host along the path cannot handle the packet in question.

See if the results tally with what you see from ping, and you should
have some idea of where the problem lies.

I'm betting you're on DSL and the problem is at one end of the DSL link
(the DSL link itself won't show up as a hop in the traceroute, as
everything's tunneled, sorta, I think)

-- 
Russell Howe       | Why be just another cog in the machine,
rhowe at siksai.co.uk | when you can be the spanner in the works?
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug