From: Jeff Dike <jdike@ka...> - 2001-06-12 23:29:46
> MTU is 1500 on all three devices (host eth0, host tap0, and uml eth0)
> - I'm using the uml-net from CVS that doesn't mess with the MTU - it
> sets it to 1500, as far as I can see. I had the same behaviour using
> the old uml_net that sets the MTU to 1484.
> Any ideas what I should do next to help debug this? Set the MTU
> higher than 1500 on the tap0<->eth0 link?
The MTU situation with the tap device, as I understand it, is this:
UML cannot run a packet of greater than 1500 bytes through ethertap - this
includes the ethernet header
However, tap will send UML packets up to 1516 bytes (1500 bytes data, 16
bytes ethernet header)
So, the eth mtu inside UML is 1484 so that when the packet gets a header, it
will be no longer than 1500 bytes.
However, UML is willing to read up to 1516 bytes from tap.
If you've looked at the strange skbuff twiddling in the ethertap backend read
and write routines, making sure that the space is available is what they're
From: Jeff Dike <jdike@ka...> - 2001-06-12 23:44:32
One more thing here - tcpdump is invaluable at tracking down problems like
this. If there are malformed, it will tell you. If one side is sending lots
of traffic, and the other side is ignoring them, it will tell you as well.
It won't solve anything for you, but it will give you an idea what you should
be poking at.
My typical usage is something like:
tcpdump -l -n -i tap1
Get latest updates about Open Source Projects, Conferences and News.