CRC/trailer calculation/uniqueness

In article , Arnold Nipper wrote: :Is there a chance to look at the trailer/CRC of an Ethernet frame to see :whether two frames which where caught by tethereal are distinct or the :same due to L2 looping?

Interesting; it sounds plausible, to the extent that duplicate packets are unlikely in the protocol (e.g., tcp has sequence numbers but other protocols do not necessarily have unique information.)

:Example: I've a set of ~ 9200 frames, where station X.X.X.X is broadcast :arping for IP Y.Y.Y.Y. When looking at the trailer like in

:Frame 316560 (60 bytes on wire, 60 bytes captured)

: Packet Length: 60 bytes

: Type: ARP (0x0806) : Trailer: 0000020100020100430500D89EBC6C30...

The normal ethernet trailer is only 4 bytes long . RFC 893 suggests a protocol for much much larger trailers, but then the capture length would have been much higher.

This leads me to suggest that what is being shown as Trailer: is not what is usually referred to as "trailer" in ethernet packets.

The CRC gets eaten by the NIC. An Ethernet MTU is 64 octets, yet Ethereal shows a length of 60. The difference is the 4-byte CRC which is lost.

NM

Is there a chance to look at the trailer/CRC of an Ethernet frame to see whether two frames which where caught by tethereal are distinct or the same due to L2 looping?

Example: I've a set of ~ 9200 frames, where station X.X.X.X is broadcast arping for IP Y.Y.Y.Y. When looking at the trailer like in

Frame 316560 (60 bytes on wire, 60 bytes captured) Arrival Time: May 26, 2005 21:15:44.694770000 Time delta from previous packet: 0.000141000 seconds Time since reference or first frame: 43.566940000 seconds Frame Number: 316560 Packet Length: 60 bytes Capture Length: 60 bytes Ethernet II, Src: xx:xx:xx:xx:xx, Dst: ff:ff:ff:ff:ff:ff Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) Source: xx:xx:xx:xx:xx (xx:xx:xx:xx:xx) Type: ARP (0x0806) Trailer: 0000020100020100430500D89EBC6C30... Address Resolution Protocol (request) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (0x0001) Sender MAC address: xx:xx:xx:xx:xx (xx:xx:xx:xx:xx) Sender IP address: X.X.X.X (X.X.X.X) Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00) Target IP address: Y.Y.Y.Y (Y.Y.Y.Y)

I only count 34 different trailers with frequency from 1 to rozghly 5900.

Regards, Arnold

Yes, it would be looking too much into the crystal ball. It's completely up to the OS how it fills the padding. And chances are the random bitpattern you think you see, is some unsuspected kernel memory dump you'd rather not want to see on your network if you're paraoid... And Longhorn may put its security updates into that place, just in case another system could make good use of them.

best regards Patrick

On 03.06.2005 02:52 News Me wrote

Thanks for investigating! Hence would it be looking too much into the crystal ball to assume that either the "Trailer" is always the same "e.g. 0x00) or filled with a random bit pattern.

IIRC the minimum frame size on GE ist either 460 or 520 hence a lot of space left in ARP frames for padding.

Regards, Arnold

In article , Arnold Nipper wrote: :Well ... let me put another question? How do you know that you saw two :different frames which by chance look identical or saw the frame the 2nd :time because you have an L2 loop?

With difficulty ;-)

Where L2 loops are suspected, the easiest approach might be to synthesize a frame between the source and destination, and see how many times it is recorded by the sniffer.

On 03.06.2005 07:48 Patrick Schaaf wrote

Well ... let me put another question? How do you know that you saw two different frames which by chance look identical or saw the frame the 2nd time because you have an L2 loop?

Arnold

:> In article , :> Arnold Nipper wrote: :> :How do you know that you saw two :> :different frames which by chance look identical or saw the frame the 2nd :> :time because you have an L2 loop?

:> the easiest approach might be to :> synthesize a frame between the source and destination

:But what dod you do if you only have recorded frames from tethereal?

Worry ? ;-)

First I would look for TCP frames; the sequence numbers can be used to identify those. If you see multiple copies, look at the time difference between them: if it isn't approaching the standard retransmission times (e.g., about 1/5 to 1/2 seconds for the Delayed Ack algorithm) then you have an issue.

Similarily, ARP and DHCP and NETBIOS and RIP and DNS and some other protocols have built-in timers; if you are seeing duplicate copies of packets within miliseconds for those protocols, then you are getting L2 duplication.

If you have a L2 loop then spanning tree -should- be pruning it... unless you have problems about Per-VLAN Spanning Tree, or you have some unidirectional links.

In article , Arnold Nipper wrote: :On 03.06.2005 18:39 Walter Roberson wrote

:> Similarily, ARP and DHCP and NETBIOS and RIP and DNS and some other :> protocols have built-in timers; if you are seeing duplicate copies of :> packets within miliseconds for those protocols, then you are getting :> L2 duplication.

:Well ... the monitor station is just sniffing. Hence I only see :broadcasts and floodings ... so???

ARP, RIP, DHCP are all broadcast, as are NETBIOS service announcements.

On 03.06.2005 17:31 Walter Roberson wrote

But what dod you do if you only have recorded frames from tethereal?

Arnold

On 03.06.2005 18:39 Walter Roberson wrote

not really :-)

Well ... the monitor station is just sniffing. Hence I only see broadcasts and floodings ... so???

Well, I know that I don't have a loop now. Also from switch logs it is not quite clear whether there was a loop or not. Hence I thought that it might be possible to get this information from the traffic sniffed (ARP und ICMPv6)

Arnold

On 03.06.2005 20:03 Walter Roberson wrote

Sorry, I didn't read carefully. You wrote

ARP is the only protocol mentioned I get.

Thanks, Arnold

some protocols seem to send identical packets

arp maybe?

spanning tree? i think that so long as the root bridge etc doesnt change, sequential packets are identical.

This is just like the jam bits used in 10Base-T hub networks.

The jam bits were always 01010...01 or 101010..10. But I remember reading in the standards doc that it could be "anything"