RE: change_mtu boundary checking error

RE: change_mtu boundary checking error

[Hen, Shmulik]

But Ethernet is not only for IP, what about other protocols ?

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Tuesday, April 17, 2001 3:41 PM
To: shmulik.hen@intel.com
Cc: linux-net@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: change_mtu boundary checking error


> Now, the high boundary seemed reasonable (ETH_FRAME_LEN - ETH_HLEN =
> ETH_DATA_LEN) which gives 1500, but why is the low boundary set to 68 ?
> According to my calculations, it should have been ETH_ZLEN - ETH_HLEN
which
> gives 46.

The IPv4 minimum MTU is 68 bytes. Below that not all frames can be delivered

Re: change_mtu boundary checking error

[Alan Cox]

> But Ethernet is not only for IP, what about other protocols ?

For 2.4 the checks were moved into the protocol layers. Any remaining check
in the driver layer for 68 would be a bug. For 2.2 its not going to change

interesting problem with raw sockets

[Christopher Friesen]

I have a piece of code that is trying to use sendmsg() on a raw socket to inject
a UDP packet onto an ethernet link.  The destination IP address is set to
another machine on the same subnet, and the packet arrives at its destination.
Thus far all is well.

However, inspection of the ethernet headers using tcpdump shows that rather than
being addressed directly to the MAC address of the destination, the packet is
instead being sent to the gateway, which then appears to forward it on to the
destination.  It almost appears as though the kernel doesn't realize that the IP
address is on the same subnet.

Here's where it gets interesting.  I grabbed what I thought was all the socket
setup and sending code from the misbehaving application and stuck them into a
tiny program that builds and sends empty packets with arbitrary source and
destination addresses.  Tcpdump shows this program behaving as expected--ie the
destination MAC address in the ethernet header is set to the MAC address of the
destination, not the MAC address of the gateway.

Does anyone have any clue what might be going on?  I'm almost ready to try
strace and kernel debugging....

Thanks,

Chris



-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com