tcpdump mailing list archives
Re: hardware loop and frame length increase
From: Fulko Hew <fulko.hew () gmail com>
Date: Mon, 6 Jun 2011 18:22:34 -0400
On Mon, Jun 6, 2011 at 6:02 PM, Martin T <m4rtntns () gmail com> wrote:
I made a RJ45 hardware loopback connector(connected Tx- with Rx+ and Tx+ with Rx-), connected this to my eth2 port, configured 192.168.88.0/24 to eth2 and executed: "ping -i0.1 -c3 192.168.88.88" ..while running tcpdump like this:
... snip ...
As you can see, every second I sent and received one frame. The question is, why is the frame, which I receive, 18 bytes longer than the one I sent? I mean what are those 144 0-bits at the end of the each frame back from the hardware loop?
You are capturing the 'outgoing' information that is being given to the driver, which is a 'short' packet. The hardware padded it to the minimum length that a packet is allowed to be, and then sent it on the wire. The hardware is receiving that incoming padded packet That would be on 'full duplex' interface. (If your hardware is half-duplex, the padding must have been accomplished with a different technique.) See: http://wiki.wireshark.org/Ethernet - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- hardware loop and frame length increase Martin T (Jun 06)
- Re: hardware loop and frame length increase Guy Harris (Jun 06)
- Re: hardware loop and frame length increase Martin T (Jun 09)
- Re: hardware loop and frame length increase Fulko Hew (Jun 06)
- Re: hardware loop and frame length increase Guy Harris (Jun 06)