Odd tracepath and ping behavior when using a 9000 byte MTU
John Stewart
Summary:
I've recently switched my network to gigabit. All the hardware is 9k
jumbo frame clean. I can switch all the machines to a 9000 MTU and
everything works great. But, if I run tracepath on my linux machine
it decides the path MTU should be 1492. However if I set the MTU to
8996 or any MTU where size= 8x+4 then tracepath works fine.
Details:
MTU is set to 9000 via:
ifconfig eth0 mtu 9000
I run ttcp to send a few 32768 byte buffers and check the size of the
on wire packets on the receiving end with ethereal. They're 9014
bytes just like they're supposed to be.
now I run tracepath and get the following output:
tracepath 192.168.1.100
1: 192.168.1.103 (192.168.1.103) 0.099ms pmtu 9000
1: 192.168.1.103 (192.168.1.103) 0.018ms pmtu 8166
1: 192.168.1.103 (192.168.1.103) 0.015ms pmtu 4352
1: 192.168.1.103 (192.168.1.103) 0.016ms pmtu 2002
1: 192.168.1.103 (192.168.1.103) 0.013ms pmtu 1492
1: 192.168.1.100 (192.168.1.100) 0.347ms reached
Resume: pmtu 1492 hops 1 back 1
For some reason the sending machine seems to have decided it has to
fragment the packets. And from the output it appears that it is doing
it before it reaches the wire. From this point on the ttcp+ethereal
test shows the on wire packet size as 1506. This behavior persists
until I change the MTU. I.e. I think that it is remembering the
"discovered" MTU for that route and using it for all subsequent
connections.
But if I set the MTU to 8996. Or for that matter to any size between
say 2k and 9k that is of the form size=8*x+4 (8996=8*1124+4) then
tracepath works fine. example:
ifconfig eth0 MTU 8996
tracepath 192.168.1.100
1: 192.168.1.103 (192.168.1.103) 0.114ms pmtu 8996
1: 192.168.1.100 (192.168.1.100) 0.778ms reached
Resume: pmtu 8996 hops 1 back 1
Both before and after running tracepath the ttcp+ethereal test shows
the on wire received packet size to be: 9010
Some info on the machines in question:
sending machine:
motherboard: Tyan Tiger motherboard
processors: dual Opteron 240
NIC: Onboard intel gigabit
Running: Gentoo Linux with kernel 2.6.4-r1 for AMD64
Using the e1000 driver that came with the kernel with default
settings.
receiving machine:
motherboard: MSI Pro266-TD Master-LR
processors: Dual Intel tualatin PIIIs at 1.26 gHz
NIC: Intel pro/1000 MT desktop adapter
Running: Windows 2000
Using the 6.01.03 drivers from Intel.
switch: SMC 8508T
And here's the results of additional testing using ping with the don't
fragment flag set:
immediately after setting an MTU of 9000 I do the following:
ping -c 4 -M do -s 8968 192.168.1.100
which succeeds:
8976 bytes from 192.168.1.100: icmp_seq=1 ttl=128 time=1.09 ms
and then this:
ping -c -4 -M do -s 8970 192.168.1.100
which fails:
From 192.168.1.103 icmp_seq=1 Frag needed and DF set (mtu = 8166)
At this point the ttcp+ethereal test shows an on wire packet size of
8180 bytes.
try again with the MTU at 8996:
ping -c 4 -M do -s 8968 192.168.1.100
success:
8976 bytes from 192.168.1.100: icmp_seq=1 ttl=128 time=1.12 ms
ping -c 4 -M do -s 8970 192.168.1.100
fails:
From 192.168.1.103 icmp_seq=1 Frag needed and DF set (mtu = 8996)
But notice it hasn't changed the MTU.
Since the problem occurs with both ping and tracepath I'd guess it's
not happening at the application level which leaves the network stack
and the NIC driver.
Does anyone have any ideas?
Can anyone reproduce this?
Thanks,
John Stewart
P Gentry
> Summary:
> I've recently switched my network to gigabit. All the hardware is 9k
> jumbo frame clean. I can switch all the machines to a 9000 MTU and
> everything works great. But, if I run tracepath on my linux machine
> it decides the path MTU should be 1492. However if I set the MTU to
> 8996 or any MTU where size= 8x+4 then tracepath works fine.
See links below re: network stack and application gotchas.
> Details:
> MTU is set to 9000 via:
> ifconfig eth0 mtu 9000
>
> I run ttcp to send a few 32768 byte buffers and check the size of the
> on wire packets on the receiving end with ethereal. They're 9014
> bytes just like they're supposed to be.
>
> now I run tracepath and get the following output:
> tracepath 192.168.1.100
> 1: 192.168.1.103 (192.168.1.103) 0.099ms pmtu 9000
> 1: 192.168.1.103 (192.168.1.103) 0.018ms pmtu 8166
> 1: 192.168.1.103 (192.168.1.103) 0.015ms pmtu 4352
> 1: 192.168.1.103 (192.168.1.103) 0.016ms pmtu 2002
> 1: 192.168.1.103 (192.168.1.103) 0.013ms pmtu 1492
> 1: 192.168.1.100 (192.168.1.100) 0.347ms reached
> Resume: pmtu 1492 hops 1 back 1
>
> For some reason the sending machine seems to have decided it has to
> fragment the packets. And from the output it appears that it is doing
> it before it reaches the wire. ...
Could very well relate to tracepath implementation. ping -R ? arping?
> ... From this point on the ttcp+ethereal
> test shows the on wire packet size as 1506. This behavior persists
> until I change the MTU. I.e. I think that it is remembering the
> "discovered" MTU for that route and using it for all subsequent
> connections.
I agree with your resoning here -- makes sense. Also route -C will
show the route cache where the path MTU is stored.
Haven't kept up recently with GigaE issues on Linux at the desktop and
up. Googling this:
linux mtu gigabit ethernet intel
revealed some interesting hits I've not read in a while. Intel was in
the search because I thought I remembered there were "issues" with the
intel nics/drivers, so you might adjust search as needed for your
other hardware.
The "jumbo frame clean" claim is, I think, something along the lines
of premature hyping by the ad men -- though it's much better now than
a couple of years ago. The fact is, there are still a number
hardware/software gotchas to account for.
Anyway, the interesting links from the search:
http://jes.home.cern.ch/jes/gige/acenic.html -> background (bit dated)
http://www.fefe.de/linuxeth/#inteldriver -> hardware/feature cf.
http://www.linuxmafia.com/pipermail/conspire/2003-February/000108.html
-> good links
A good refernece re: Linux stack (espcially IP) and iproute2 utils:
http://linux-ip.net/html/
Didn't check for any nuggetts in the Adv. Routing HowTo from lartc so
you might check that.
Actually, your observed behavior seems "typical" and your reasoning
sound. I'm not sure what your question really is, but I assume you
are concerned with performance and reliability issues.
You may have to check that all software/drivers are up to date and
properly configured for your environement, but it seems you're doing
reasonably good "as is".
Have you checked cpu usage when moving data between different
platforms -- cpu interrupt handling at GigaE sizes/speed can cripple a
link. Jumbo frame clean usually suggests good nic support to avoid
this, but with different platforms and hardware you may be wise to
monitor cpu usage to get an eyeball estimate. Netstat can help in
this too, but I forget the best options for this.
hth,
prg
email above disabled
John Stewart
>> I.e. I think that it is remembering the
>> "discovered" MTU for that route and using it for all subsequent
>> connections.
>
>I agree with your resoning here -- makes sense. Also route -C will
>show the route cache where the path MTU is stored.
Neat, route -Cee does show the MSS for each route but
it doesn't seem to change after doing the tracepath thing. I couldn't
find a way to get it to display the pmtu. Also you can get the same
output from netstat -rCee.
>Haven't kept up recently with GigaE issues on Linux at the desktop and
>up. Googling this:
Yeah I did a lot of searching didn't find my exact issue.
Though I'm still kinda new to Linux so I probably don't know the
best places to look. I was mainly searching on things like: ifconfig
linux tracepath mtu and such.
>The "jumbo frame clean" claim is, I think, something along the lines
>of premature hyping by the ad men -- though it's much better now than
>a couple of years ago. The fact is, there are still a number
>hardware/software gotchas to account for.
Well using ping with don't fragment the switch successfully
passes packets up to around 9200 bytes or so both ways. So I think at
least the hardware is working :)
>Anyway, the interesting links from the search:
>http://jes.home.cern.ch/jes/gige/acenic.html -> background (bit dated)
>http://www.fefe.de/linuxeth/#inteldriver -> hardware/feature cf.
>http://www.linuxmafia.com/pipermail/conspire/2003-February/000108.html
>-> good links
Thanks I had actually stumbled onto some but not all of these.
>A good refernece re: Linux stack (espcially IP) and iproute2 utils:
>http://linux-ip.net/html/
>
>Didn't check for any nuggetts in the Adv. Routing HowTo from lartc so
>you might check that.
>
>Actually, your observed behavior seems "typical" and your reasoning
>sound. I'm not sure what your question really is, but I assume you
>are concerned with performance and reliability issues.
Mainly I just want to see if there is a fix and also if there
isn't a fix then I want to bring this "problem" to the attention of
someone who might be able and willing to find and fix it. Though it's
not a huge problem since:
1. It only seems to be triggered if you explicitely cause pmtu
detection by using ping or tracepath.
2. It can mostly be worked around by using an MTU of 8996.
>You may have to check that all software/drivers are up to date and
>properly configured for your environement, but it seems you're doing
>reasonably good "as is".
>Have you checked cpu usage when moving data between different
Well before I managed to "break" the windows end I did a bit of
benchmarking. By break I mean installing the latest windows drivers
from the Intel web site. This caused a PC that was both sending and
receiving at 85000KB/sec to become a PC that still receives at
85000KB/sec but now can only send at 30-45000KB/sec. And reverting to
the older drivers doesn't fix it. Joy. But I digress.
Basically at an MTU of 1500 I was getting around 75000KB/sec and with
an MTU of 9000 it jumps to 85000KB/sec. CPU usage on the linux
box(the dual Opteron 240) was always pretty low(<5%) though it was
higher when receiving. It decreased slightly with the larger MTU. On
the windows box sending was CPU efficient(10ish %) but receiving ate
around 50% CPU time(this was on an Athlon 3200+ since I had already
installed the broken drivers on the other windows box I was using
yestarday). Switching from 1500 to 9000 MTU actually made CPU
utilization slightly worse on the Windows box at least for receiving.
More data on the pmtu detection problem. I can also trigger similar
behavior with MTUs below 1500.
mtu 1500:
1: 192.168.1.103 (192.168.1.103) 0.191ms pmtu 1500
1: 192.168.1.100 (192.168.1.100) 0.434ms reached
Resume: pmtu 1500 hops 1 back 1
mtu 1498, 1496 and 1494 all result something like:
1: 192.168.1.103 (192.168.1.103) 0.160ms pmtu 1494
1: 192.168.1.103 (192.168.1.103) 0.015ms pmtu 1492
1: 192.168.1.100 (192.168.1.100) 0.212ms reached
Resume: pmtu 1492 hops 1 back 1
1492 succeeds
1490, 1488, 1486 all go into an infinite loop:
1: 192.168.1.103 (192.168.1.103) 0.155ms pmtu 1490
1: 192.168.1.103 (192.168.1.103) 0.014ms pmtu 576
1: 192.168.1.103 (192.168.1.103) 0.013ms pmtu 552
1: 192.168.1.103 (192.168.1.103) 0.011ms pmtu 552
This last line repeats over and over again.
1484 succeeds
1484, 1492, and 1500 all fit the previously discovered 8x+4 pattern.
Being that they are equal to 185, 186, and 187 * 8 + 4.
Can anyone replicate this new test?
I'm going to be putting another Linux server (back) together again
sometime in the near future. I was going to put another 1000 MT card
in it but I may try another card first so I can check and see if this
behavior is specific to the 1000 MT drivers.
John Stewart
P Gentry
> >> I.e. I think that it is remembering the
> >> "discovered" MTU for that route and using it for all subsequent
> >> connections.
> >
> >I agree with your resoning here -- makes sense. Also route -C will
> >show the route cache where the path MTU is stored.
>
> Neat, route -Cee does show the MSS for each route but
> it doesn't seem to change after doing the tracepath thing. I couldn't
> find a way to get it to display the pmtu. Also you can get the same
> output from netstat -rCee.
Oops, should have said $ /sbin/ip route show table cache . But note
that this thing typically clears quick, so you need to run it right
after some activity -- my recent experience anyway.
From ip-cref (the "authority" for covered topics) re: route --
mtu MTU or mtu lock MTU
-- the MTU along the path to destination. If modifier lock is not
used, MTU may be updated by the kernel due to Path MTU Discovery. If
the modifier lock is used, no path MTU discovery will be tried, all
the packets will be sent without DF bit in IPv4 case or fragmented to
MTU for IPv6.
advmss NUMBER
-- [2.3.15+ only]MSS (``Maximal Segment Size'') to advertise to these
destinations when establishing TCP connections. If it is not given,
Linux use default value calculated from first hop device MTU.
Linux IP conforms closely to RFCs re: IPv6 AFAIK, so you may want to
have a handy reference. I use these two:
http://www.networksorcery.com/enp/default0601.htm -> good quicky ref
http://www.faqs.org/rfcs/ -> good for full docs/searches
>Haven't kept up recently with GigaE issues on Linux at the desktop
and
> >up. Googling this:
>
> Yeah I did a lot of searching didn't find my exact issue.
> Though I'm still kinda new to Linux so I probably don't know the
> best places to look. I was mainly searching on things like: ifconfig
> linux tracepath mtu and such.
>
> >The "jumbo frame clean" claim is, I think, something along the lines
> >of premature hyping by the ad men -- though it's much better now than
> >a couple of years ago. The fact is, there are still a number
> >hardware/software gotchas to account for.
>
> Well using ping with don't fragment the switch successfully
> passes packets up to around 9200 bytes or so both ways. So I think at
> least the hardware is working :)
I think you would have to set DF bit with things like ping and
traceroute as they don't "need" such a large packet -- nor the extra
work of handling such large packets. This is where "apps" must also
be programmed to _use_ the larger frames/packets.
> >Anyway, the interesting links from the search:
> >http://jes.home.cern.ch/jes/gige/acenic.html -> background (bit dated)
> >http://www.fefe.de/linuxeth/#inteldriver -> hardware/feature cf.
> >http://www.linuxmafia.com/pipermail/conspire/2003-February/000108.html
> >-> good links
>
> Thanks I had actually stumbled onto some but not all of these.
>
> >A good refernece re: Linux stack (espcially IP) and iproute2 utils:
> >http://linux-ip.net/html/
> >
> >Didn't check for any nuggetts in the Adv. Routing HowTo from lartc so
> >you might check that.
> >
> >Actually, your observed behavior seems "typical" and your reasoning
> >sound. I'm not sure what your question really is, but I assume you
> >are concerned with performance and reliability issues.
>
> Mainly I just want to see if there is a fix and also if there
> isn't a fix then I want to bring this "problem" to the attention of
> someone who might be able and willing to find and fix it. Though it's
> not a huge problem since:
> 1. It only seems to be triggered if you explicitely cause pmtu
> detection by using ping or tracepath.
I _think_ this is due to cached info mapped to a particular route --
the next use will conform to these cached params.
> 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".
> >You may have to check that all software/drivers are up to date and
> >properly configured for your environement, but it seems you're doing
> >reasonably good "as is".
>
> >Have you checked cpu usage when moving data between different
>
> Well before I managed to "break" the windows end I did a bit of
> benchmarking. By break I mean installing the latest windows drivers
> from the Intel web site. This caused a PC that was both sending and
> receiving at 85000KB/sec to become a PC that still receives at
> 85000KB/sec but now can only send at 30-45000KB/sec. And reverting to
> the older drivers doesn't fix it. Joy. But I digress.
>
> Basically at an MTU of 1500 I was getting around 75000KB/sec and with
> an MTU of 9000 it jumps to 85000KB/sec. CPU usage on the linux
> box(the dual Opteron 240) was always pretty low(<5%) though it was
> higher when receiving. It decreased slightly with the larger MTU. On
> the windows box sending was CPU efficient(10ish %) but receiving ate
> around 50% CPU time(this was on an Athlon 3200+ since I had already
> installed the broken drivers on the other windows box I was using
> yestarday). Switching from 1500 to 9000 MTU actually made CPU
> utilization slightly worse on the Windows box at least for receiving.
This is one of those "gotchas" -- receiving is where you would expect
interrupt processing to be the "worst" as with little/no
hardware/driver help _each_ frame/packet will have to be "prepared"
for the trip up the stack. With good hardware/drivers this "interrupt
overhead" is greatly reduced. Sounds like Windows OS or driver not up
to the task -- no surprise to hardcore Linux kernel freaks who wince
at Windows stack performance (at least from what I can gather). I
would suspect a better stack implementation in their high end server
OSes. At the desktop Win is more than willing to grab as much CPU as
it wants -- cf. Win modems and printers that replace ASICs with driver
code.
> More data on the pmtu detection problem. I can also trigger similar
> behavior with MTUs below 1500.
>
> mtu 1500:
> 1: 192.168.1.103 (192.168.1.103) 0.191ms pmtu 1500
> 1: 192.168.1.100 (192.168.1.100) 0.434ms reached
> Resume: pmtu 1500 hops 1 back 1
>
> mtu 1498, 1496 and 1494 all result something like:
> 1: 192.168.1.103 (192.168.1.103) 0.160ms pmtu 1494
> 1: 192.168.1.103 (192.168.1.103) 0.015ms pmtu 1492
> 1: 192.168.1.100 (192.168.1.100) 0.212ms reached
> Resume: pmtu 1492 hops 1 back 1
>
> 1492 succeeds
>
> 1490, 1488, 1486 all go into an infinite loop:
> 1: 192.168.1.103 (192.168.1.103) 0.155ms pmtu 1490
> 1: 192.168.1.103 (192.168.1.103) 0.014ms pmtu 576
> 1: 192.168.1.103 (192.168.1.103) 0.013ms pmtu 552
> 1: 192.168.1.103 (192.168.1.103) 0.011ms pmtu 552
> This last line repeats over and over again.
>
> 1484 succeeds
>
> 1484, 1492, and 1500 all fit the previously discovered 8x+4 pattern.
> Being that they are equal to 185, 186, and 187 * 8 + 4.
>
> Can anyone replicate this new test?
The _exact_ #s may differ but the same thing should be observable with
similar hardware/driver combos -- in fact you will see something like
this with just(?) about any combo. And with several (unknown?)
devices in the path, MTU can be tricky to get "right". This
frequently shows up with xDSL connections using PPPoE. It has to do
with "pre-sized" headers/fields used in differing encapsulation
methods and the software used at different layers in the stack. It's
also why getting just the right combinations on GigaE can be hard as
the speed/size/amount is so much greater and more easily "tickles" any
implementation inconsistencies along the path.
> I'm going to be putting another Linux server (back) together again
> sometime in the near future. I was going to put another 1000 MT card
> in it but I may try another card first so I can check and see if this
> behavior is specific to the 1000 MT drivers.
You may want to find/subscribe to a good mailing list where these
issues are being activily and remorselessly discussed. I've seen
quite a bit of traffic along these lines in both HA and beowolfe
cluster lists -- the latter seem particularly eager to get GigaE
working consistently and well behaved (as you can imagine).
>
> John Stewart
This pretty much exhausts my "vast" knowledge and experience in this
area. At work -- a school district with ~4000 computers -- they
forked up the money to go straight Cisco and fiber optic along the
shared net paths and backbones (whoopee, server farms!). It sure
reveals marginally bad copper UTP (which runs to the desktops and
print servers) _really_ quick. When we were first trying this out
several years ago, UTP cabling proved an issue at these speeds even in
a small classroom lab.
Good luck getting this to run smoothly -- you'll love it if it's
predictible and reliable in it's behavior, it's the unpredictible
stuff that will make you want to scream.
P Gentry
> john.s...@noyb.com.invalid (John Stewart) wrote in message news:<4069faf5...@news-server.woh.rr.com>...
[snip]
Oops, keeping up with NG posting via Google requires the occasional
follow ups to one's own postings.
Missed it earlier when I thought I had seen it before -- maybe this
will be of more direct help on occassion.
From: Adv-Routing-HOWTO.html#LARTC.COOKBOOK.MTU-DISCOVERY :
/proc/sys/net/ipv4/ip_no_pmtu_disc
Set this if you want to disable Path MTU discovery - a technique to
determine the
largest Maximum Transfer Unit possible on your path. See also the
section on Path
MTU discovery in the Cookbook chapter.
...
Beware. There lies danger. Not sure what kind of mischievous
gremlins might be let loose when combined with setting the MTU to an
"awkward" size.
John Stewart
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
Clifford Kite
If the sending machine is using PMTU Discovery as described in RFC 1191
then the receiving machine likely advertised a MSS of 8996, corresponding
to an MTU of 9014. The receiving machine starts with it's own 9000 MTU
and then tries, in descending order, the "plateaus" for the various
types of physical networks listed in that RFC which have MTUs less than
9000 and 9014, starting with 8166 (RFC 1042). When it finds one that
is an integral multiple of 8996
> switch: SMC 8508T
> Thanks,
> John Stewart
--
Clifford Kite Email: "echo xvgr_yv...@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Bluffing in a poker game can win big; bluffing in a newsgroup
only attracts sharks. */
Clifford Kite
Sorry, forget this. I was trying to learn while composing a reply and
accidentally posted it before it was ready. In reality, it's likely
that it wouldn't have ever been completed and so been discarded.
P Gentry
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