[Click] Inflated packets

[luca.capisani at virgilio.it]

Hi all,
          it seems to be a ethernet problem. If you send  50 bytes at level
two (header ehternet + payload of 36 bytes), the minimum lenght that can
be transmitted in a ethernet link is 64 bytes overhead inclusive.
If total length is 50 bytes, ethernet protocol adds a padding bytes (zeros)
at the end of packet. With Ethereal, (also Print()) you can see the packet
structure (in particular, last 10 bytes).
You should explain more of the structure of the packet sent, in order to
understand better.

Networking Lab, University of Pavia (Italy)
Luca M. Capisani.





>-- Messaggio originale --
>Date: Tue, 20 Jul 2004 07:37:12 -0700
>From: <kevin_mitchell at agilent.com>
>To: <click at amsterdam.lcs.mit.edu>
>Subject: [Click] Inflated packets
>
>
>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