| Author |
Message |
Arnold Nipper
Guest
|
 Posted:
Thu Jun 02, 2005 11:09 pm Post subject:
CRC/trailer calculation/uniqueness |
|
|
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
--
Arnold Nipper, AN45 |
|
| Back to top |
|
 |
Walter Roberson
Guest
|
| Posted:
Thu Jun 02, 2005 11:27 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
In article <d7ni0r$lsg$1@nntp.ilk.net>,
Arnold Nipper <arnold-200505@nipper.de> 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.
--
Are we *there* yet?? |
|
| Back to top |
|
|
News Me
Guest
|
| Posted:
Fri Jun 03, 2005 5:52 am Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
Arnold Nipper wrote:
| Quote: | 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)
|
What Ethereal is calling "Trailer" is actually padding within the
Ethernet frame, not the trailer/CRC. I just pulled up a capture file
and length of the frame up to the end of the ARP is only 42 octets. The
"Trailer" is 18 octets of filler. On the system I captured on, these 18
octets are all 0x00.
NM
--
convert UPPERCASE NUMBER to a numeral to reply |
|
| Back to top |
|
|
News Me
Guest
|
| Posted:
Fri Jun 03, 2005 7:23 am Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
Arnold Nipper wrote:
| Quote: | 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?
|
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
--
convert UPPERCASE NUMBER to a numeral to reply |
|
| Back to top |
|
|
Arnold Nipper
Guest
|
| Posted:
Fri Jun 03, 2005 8:20 am Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
On 03.06.2005 02:52 News Me wrote
| Quote: | 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?
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)
What Ethereal is calling "Trailer" is actually padding within the
Ethernet frame, not the trailer/CRC. I just pulled up a capture file
and length of the frame up to the end of the ARP is only 42 octets. The
"Trailer" is 18 octets of filler. On the system I captured on, these 18
octets are all 0x00.
|
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
--
Arnold Nipper, AN45 |
|
| Back to top |
|
|
Patrick Schaaf
Guest
|
| Posted:
Fri Jun 03, 2005 8:20 am Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
Arnold Nipper <arnold-200505@nipper.de> writes:
| Quote: | 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.
|
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 |
|
| Back to top |
|
|
Arnold Nipper
Guest
|
| Posted:
Fri Jun 03, 2005 4:20 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
On 03.06.2005 07:48 Patrick Schaaf wrote
| Quote: | Arnold Nipper <arnold-200505@nipper.de> writes:
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.
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.
|
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
--
Arnold Nipper, AN45 |
|
| Back to top |
|
|
Walter Roberson
Guest
|
| Posted:
Fri Jun 03, 2005 4:20 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
In article <d7pq15$fts$1@nntp.ilk.net>,
Arnold Nipper <arnold-200505@nipper.de> 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.
--
Warning: potentially contains traces of nuts. |
|
| Back to top |
|
|
Arnold Nipper
Guest
|
| Posted:
Fri Jun 03, 2005 9:26 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
On 03.06.2005 17:31 Walter Roberson wrote
| Quote: | In article <d7pq15$fts$1@nntp.ilk.net>,
Arnold Nipper <arnold-200505@nipper.de> 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.
|
But what dod you do if you only have recorded frames from tethereal?
Arnold
--
Arnold Nipper, AN45 |
|
| Back to top |
|
|
Walter Roberson
Guest
|
| Posted:
Fri Jun 03, 2005 9:39 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
In article <d7q0cd$qoo$1@nntp.ilk.net>,
Arnold Nipper <arnold-200505@nipper.de> wrote:
| Quote: | On 03.06.2005 17:31 Walter Roberson wrote
|
:> In article <d7pq15$fts$1@nntp.ilk.net>,
:> Arnold Nipper <arnold-200505@nipper.de> 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.
--
'The short version of what Walter said is "You have asked a question
which has no useful answer, please reconsider the nature of the
problem you wish to solve".' -- Tony Mantler |
|
| Back to top |
|
|
Arnold Nipper
Guest
|
| Posted:
Fri Jun 03, 2005 9:44 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
On 03.06.2005 18:39 Walter Roberson wrote
| Quote: | In article <d7q0cd$qoo$1@nntp.ilk.net>,
Arnold Nipper <arnold-200505@nipper.de> wrote:
On 03.06.2005 17:31 Walter Roberson wrote
:> In article <d7pq15$fts$1@nntp.ilk.net>,
:> Arnold Nipper <arnold-200505@nipper.de> 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 ? ;-)
|
not really :-)
| Quote: | 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.
|
Well ... the monitor station is just sniffing. Hence I only see
broadcasts and floodings ... so???
| Quote: | 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.
|
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
--
Arnold Nipper, AN45 |
|
| Back to top |
|
|
Walter Roberson
Guest
|
| Posted:
Fri Jun 03, 2005 11:03 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
In article <d7q1e0$sn2$1@nntp.ilk.net>,
Arnold Nipper <arnold-200505@nipper.de> 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.
--
Would you buy a used bit from this man?? |
|
| Back to top |
|
|
Arnold Nipper
Guest
|
| Posted:
Fri Jun 03, 2005 11:29 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
On 03.06.2005 20:03 Walter Roberson wrote
| Quote: | In article <d7q1e0$sn2$1@nntp.ilk.net>,
Arnold Nipper <arnold-200505@nipper.de> 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.
|
Sorry, I didn't read carefully. You wrote
| Quote: | ... ARP ... have built-in timers
|
ARP is the only protocol mentioned I get.
Thanks, Arnold
--
Arnold Nipper, AN45 |
|
| Back to top |
|
|
stephen
Guest
|
| Posted:
Sat Jun 04, 2005 4:20 pm Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
"Arnold Nipper" <arnold-200505@nipper.de> wrote in message
news:d7pq15$fts$1@nntp.ilk.net...
| Quote: | On 03.06.2005 07:48 Patrick Schaaf wrote
Arnold Nipper <arnold-200505@nipper.de> writes:
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.
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.
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?
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.
| Quote: |
Arnold
--
Arnold Nipper, AN45
-- |
Regards
Stephen Hope - return address needs fewer xxs |
|
| Back to top |
|
|
Hansang Bae
Guest
|
| Posted:
Wed Jun 08, 2005 6:15 am Post subject:
Re: CRC/trailer calculation/uniqueness |
|
|
Arnold Nipper wrote:
| Quote: | 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.
|
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"
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************************************************** |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in