3

I have spent the last two hours trying to capture an Ethernet collision using wireshark and a few other tools in vain.

I have hooked up 7 computers to a hub and

  1. Am transferring a large video file from PC1 -> PC7
  2. PC2...PC6 are pinginig PC7

The "Collision" LED on the hub keeps flickering, but not a single packet with collisions are captured. I am expecting to see some corrupted packets - am I expecting too much? Are these discarded by the chip?

How would a collision look in HEX?

1
5

Ethernet started out as a protocol for coaxial shared medium networks. In the event of a collision the voltage levels on the cable would be wrong and the transceivers would detect this and tell the MACs. Any data received at this point would be garbage.

The receiving MAC would ignore any data coming in, and possibly increment a collision counter. The MAC has no reason to pass the garbage coming in from the PHY up to the host computer. The sending MACs would also see the collision, they would keep transmitting for the minimum frame time to ensure the collision was seen throughout the network. They would then wait for a random backoff before trying to send the frame again, hopefully the random backoff times used by the two sending MACs would be sufficiently different that one of them would succesfully send it's frame while the other would detect the line as busy and wait it's turn.

Now enter repeaters (aka hubs). A repeater has a number of PHYs but no MACs. When a repeater detects a collision it outputs a "Jam signal". This ensures that the collision is seen across the whole network.

So what about twisted pair? All common variants of twisted pair Ethernet are full duplex at the physical layer but for backwards compatibility and to support the use of hubs most of them have a "half duplex" mode. In half duplex mode simultaneous activation of transmitter and receiver is treated as a collision.

Putting that all together lets imagine you had a device plugged in to one of the spare ports on your hub that could capture and analyse low level Ethernet signals, what would it see?

You would see the start of a frame as normal. Then when the collision happened you would see a Jam signal from the hub. Once the Jam signal was over you would then see a period of idle line until one of the sender's random back-off timers expires and a retransmission begins.

2

The collision is handled by the Network Interface Card (NIC) in its hardware / firmware. The NIC will only pass to the operating system the valid frames.

Wireshark will capture traffic sent by the NIC to the operating system, so only after collision has been handled. As such it doesn't see the collisions.

As for what it looks like, my guess is a frame with some part being garbage (random).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.