Hello,
Going through the change_mtu() code in the kernel, I came across the default
function supplied when calling ether_setup().
I could see that eth_change_mtu() (drivers/net/net_init.c) does the
following:
if( (new_mtu < 68) || (new_mtu > 1500) )
return -EINVAL;
Looking in include/linux/if_ether.h I found the following constants:
#define ETH_ALEN 6 /* Octets in one ethernet addr */
#define ETH_HLAN 14 /* Total octets in header. */
#define ETH_ZLEN 60 /* Min. octets in frame sans FCS */
#define ETH_DATA_LEN 1500 /* Max. octets in payload */
#define ETH_FRAME_LEN 1514 /* Max. octets in frame sans FCS */
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.
Doesn't mtu means only the payload size ?
Where did the 68 come from ?
Thanks,
Shmulik Hen
Software Engineer
Linux Advanced Networking Services
Network Communications Group, Israel (NCGj)
> 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
But Ethernet is not only for IP, what about other protocols ?
-----Original Message-----
From: Alan Cox [mailto:[email protected]]
Sent: Tuesday, April 17, 2001 3:41 PM
To: [email protected]
Cc: [email protected]; [email protected]
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
> 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
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: [email protected]