Re: Odd tracepath and ping behavior when using a 9000 byte MTU

On 31 Mar 2004 11:30:36 -0800, rdgentry1@cablelynx.com (P Gentry)
wrote:

>> 2. It can mostly be worked around by using an MTU of 8996.
>
>Actually, from what I can tell from the "reference" docs above --
>especially ip-cref -- you can set/force some of these params to be
>used in the routing table all(?) the time.
>
>The sizes you noted being adjusted relate to "efficiency" concerns in
>the memory processing, I believe -- ie., sizes used are the ones most
>"efficient" to use, eg., powers of 2 + known # of bytes for reserved
>field size, etc. Thus 8996 is most "efficient".

Yeah it'd make sense that it might try for a more efficient
size. However dropping from 9000 all the way to 1492 is probably not
going to be maximially efficient. :)

I've done some additional testing.

OS: Knoppix kernel 2.4.22(not sure on the 3rd digit).
Nic driver: Intel e1000


Tracepath goes right through with a 9000 MTU:

root@ttyp0[home2]# ./tracepath 192.168.1.110
1?: [LOCALHOST] pmtu 9000
1: 192.168.1.110 (192.168.1.110) 0.652ms reached
Resume: pmtu 9000 hops 1 back 1

ping with don't fragment works as I'd expect without reducing the MTU:

root@ttyp0[home2]# ./ping -c 2 -M do -s 8970 192.168.1.110
PING 192.168.1.110 (192.168.1.110) 8970(8998) bytes of data.
8978 bytes from 192.168.1.110: icmp_seq=1 ttl=64 time=0.969 ms
8978 bytes from 192.168.1.110: icmp_seq=2 ttl=64 time=1.34 ms

--- 192.168.1.110 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.969/1.158/1.348/0.192 ms
root@ttyp0[home2]# ./ping -c 2 -M do -s 8972 192.168.1.110
PING 192.168.1.110 (192.168.1.110) 8972(9000) bytes of data.
8980 bytes from 192.168.1.110: icmp_seq=1 ttl=64 time=0.975 ms
8980 bytes from 192.168.1.110: icmp_seq=2 ttl=64 time=1.11 ms

--- 192.168.1.110 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1006ms
rtt min/avg/max/mdev = 0.975/1.045/1.116/0.077 ms
root@ttyp0[home2]# ./ping -c 2 -M do -s 8974 192.168.1.110
PING 192.168.1.110 (192.168.1.110) 8974(9002) bytes of data.
ping: local error: Message too long, mtu=9000
ping: local error: Message too long, mtu=9000

Those ping and traceroute binaries are the exact same binaries
that show odd behavior under a gentoo 2.6.4 kernel.


I have also tested a 2.6.4 kernel on an x86 box(initial post showed
results from an amd64 box) and it has the same odd behavior. So now
I'm thinking whatever is causing this problem has probably been
introduced since the 2.4 kernels.

John Stewart

john.stewart@noyb.com.invalid (John Stewart) wrote in message news:<40787851.4103515@news-server.woh.rr.com>...
> On 31 Mar 2004 11:30:36 -0800, rdgentry1@cablelynx.com (P Gentry)
> wrote:
[snip]

> I've done some additional testing.
>
> OS: Knoppix kernel 2.4.22(not sure on the 3rd digit).
> Nic driver: Intel e1000
>
> Tracepath goes right through with a 9000 MTU:
>
> root@ttyp0[home2]# ./tracepath 192.168.1.110
> 1?: [LOCALHOST] pmtu 9000
> 1: 192.168.1.110 (192.168.1.110) 0.652ms reached
> Resume: pmtu 9000 hops 1 back 1
>
> ping with don't fragment works as I'd expect without reducing the MTU:
>
> root@ttyp0[home2]# ./ping -c 2 -M do -s 8970 192.168.1.110
> PING 192.168.1.110 (192.168.1.110) 8970(8998) bytes of data.
> 8978 bytes from 192.168.1.110: icmp_seq=1 ttl=64 time=0.969 ms
> 8978 bytes from 192.168.1.110: icmp_seq=2 ttl=64 time=1.34 ms
>
> --- 192.168.1.110 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 0.969/1.158/1.348/0.192 ms
> root@ttyp0[home2]# ./ping -c 2 -M do -s 8972 192.168.1.110
> PING 192.168.1.110 (192.168.1.110) 8972(9000) bytes of data.
> 8980 bytes from 192.168.1.110: icmp_seq=1 ttl=64 time=0.975 ms
> 8980 bytes from 192.168.1.110: icmp_seq=2 ttl=64 time=1.11 ms
>
> --- 192.168.1.110 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1006ms
> rtt min/avg/max/mdev = 0.975/1.045/1.116/0.077 ms
> root@ttyp0[home2]# ./ping -c 2 -M do -s 8974 192.168.1.110
> PING 192.168.1.110 (192.168.1.110) 8974(9002) bytes of data.
> ping: local error: Message too long, mtu=9000
> ping: local error: Message too long, mtu=9000

From Googliing the err message, this seems to be coming from ping6.c
(?) error processing from data at the local socket (only 6-8 hits):
ftp.jkt.elga.net.id/download/ unix/linux/iputils/ping6.c

> Those ping and traceroute binaries are the exact same binaries
> that show odd behavior under a gentoo 2.6.4 kernel.
>
> I have also tested a 2.6.4 kernel on an x86 box(initial post showed
> results from an amd64 box) and it has the same odd behavior. So now
> I'm thinking whatever is causing this problem has probably been
> introduced since the 2.4 kernels.
>
> John Stewart

You may have a point here about kernel code behavior -- can't imagine
a distro mucking around in this code or even getting too close to it.
You might want to keep as much info filed as possible as you play with
this -- especially how to reproduce the errors/behavior as that is the
most insistent cry for help from the coders.

Even if it's something about the ping or tracepath code that is not
properly handling or clashing with 2.6 changes, I'm sure they would
want to know it and forward it to appropriate folks. After all, these
are part of the networking tool box.

Wish I could be of more help, but next month has me doing family
rounds across half the country. Quite frankly, I've never looked at
this part of the code anyway -- or very much of any other part.

I'll keep an eye out when I'm near a connected compupter.

Good luck,
prg
email above disabled