[Click] Inflated packets

[Michael Neufeld]

As I recall, 60 bytes is the minimum packet size that ethernet adapters 
will send on the network, so packets will get padded up to that length. 
I've actually gotten burned by this in the past in Click -- I was 
generating ARP packets smaller than this and wasn't padding the skbuff 
up to it. Those packets would get quietly dropped on the floor without 
ever hitting the network. I believe what you're seeing is that the 
(length of the packet skbuff) == (length of packet on the wire), which 
is the ethernet minimum of 60 bytes. Generally the only assumption I 
make about the packet length is that it should be at least as big as the 
data I've put into it. For calculating specific lengths I rely on 
whatever internal packet headers are there.

-Mike

kevin_mitchell at agilent.com wrote:

> I have a user-level click script running on machine A that sends a packet 50 bytes long to machine B.  Inserting a Print element immediately prior to sending the packet confirms it has this length.  On machine B I'm running a kernel-level click script.  If I insert a Print element immediately after receiving the packet, using FromDevice, it says the packet is now 60 bytes long.  If I know the payload contains an IP packet then I can insert a CheckIPHeader element, and this, as a side-effect, truncates the packet back down to the expected 50 bytes, by using the IP length in the header.  But I might not always have an IP header in the payload, so this won't always work.  Is this difference between the expected packet length, and the reported length, to be expected?
>  
> Kevin
>  
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click