Wireshark sees Ethernet LLC, but packet is probably Ethernet raw

asked 2019-05-09 01:06:21 +0000

taosecurity
11 ●1 ●1 ●3

updated 2019-05-09 01:13:09 +0000

Hello,

I'm working with some packet traces that appear to have 802.3 raw Ethernet. In other words, after the destination and source MAC addresses, instead of an Ethertype like 0x0800, I see a length field, and then content, e.g.

Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Encapsulation type: Ethernet (1)
Arrival Time: May  7, 2019 18:19:10.073296000 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1557253150.073296000 seconds
[Time delta from previous captured frame: 0.000003000 seconds]
[Time delta from previous displayed frame: 0.000003000 seconds]
[Time since reference or first frame: 0.000024000 seconds]
Frame Number: 3
Frame Length: 66 bytes (528 bits)
Capture Length: 66 bytes (528 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:llc:data]

IEEE 802.3 Ethernet
Destination: fc:ec:da:49:e0:10
    Address: fc:ec:da:49:e0:10
    .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: 38:ba:f8:12:7d:bb
    Address: 38:ba:f8:12:7d:bb
    .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Length: 56
    [Expert Info (Error/Malformed): Length field value goes past the end of the payload]
        [Length field value goes past the end of the payload]
        [Severity level: Error]
        [Group: Malformed]

Logical-Link Control
DSAP: Unknown (0x45)
    0100 010. = SAP: Unknown
    .... ...1 = IG Bit: Group
SSAP: LLC Sub-Layer Management (0x02)
    0000 001. = SAP: LLC Sub-Layer Management
    .... ...0 = CR Bit: Command
Control field: U, func=Unknown (0x0B)
    000. 10.. = Command: Unknown (0x02)
    .... ..11 = Frame type: Unnumbered frame (0x3)

Data (49 bytes)
Data: 84d98d86b5400649eec0a80460341512db97ac0d0be3422a...
[Length: 49]

`0000  fc ec da 49 e0 10 38 ba f8 12 7d bb 00 38 45 02   ...I..8...}..8E.
0010  0b 84 d9 8d 86 b5 40 06 49 ee c0 a8 04 60 34 15   [email protected]....`4.
0020  12 db 97 ac 0d 0b e3 42 2a 57 83 49 c2 ea c8 ec   .......B*W.I....
0030  01 28 17 6f 00 00 01 01 08 0a 01 8f f1 de ed 7f   .(.o............
0040  a5 4a                                             .J
`

You can see Tshark (and Wireshark) decode this as Ethernet with a LLC header. I need it to decode this as Ethernet with a raw header. I'm trying to troubleshoot why this traffic exists, as it is unexpected. It could be an issue with Linux on VirtualBox on Linux.

I'm familiar with "decode as" but I don't see how to apply it in this situation, or if Wireshark can help with this format.

Thank you,

RIchard

edit retag flag offensive close merge delete

Comments

What do you mean by "a raw header"?

Guy Harris ( 2019-05-09 01:16:21 +0000 )edit

Hi Guy,

I'm referring to the second format in the figure in this post:

https://networkengineering.stackexcha...

So the header in the frame I shared appears to be:

DST MAC / SRC MAC / Length / Data

instead of

DST MAC / SRC MAC / Length / DSAP / SSAP / Control / Data

which is how Wireshark and Tshark are decoding it.

Richard

taosecurity ( 2019-05-09 01:51:06 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2019-05-09 05:31:54 +0000

SYN-bit

18344 ●9 ●301 ●255 https://SYN-b.it

updated 2019-05-09 06:23:28 +0000

Hi Richard,

From epan/dissectors/packet-eth.c:

  /*
   * If the type/length field is <= the maximum 802.3 length,
   * and is not zero, this is an 802.3 frame, and it's a length
   * field; it might be an Novell "raw 802.3" frame, with no
   * 802.2 LLC header, or it might be a frame with an 802.2 LLC
   * header.
   *
   * If the type/length field is >= the minimum Ethernet II length,
   * this is an Ethernet II frame, and it's a type field.
   *
   * If the type/length field is > maximum 802.3 length and < minimum
   * Ethernet II length, then this is an invalid packet.
   *
   * If the type/length field is zero (ETHERTYPE_UNK), this is
   * a frame used internally by the Cisco MDS switch to contain
   * Fibre Channel ("Vegas").  We treat that as an Ethernet II
   * frame; the dissector for those frames registers itself with
   * an ethernet type of ETHERTYPE_UNK.
   */

Indeed your hex data is showing two extra bytes between the the eth src/dst and the IP header. It appears to be the length of the frame, but as it is 0x0038 (56) it is smaller than the minimum length of a frame and therefor Wireshark will not decode it as "802.3 RAW". Maybe the frame was captured on a box before padding took place?

One way to decode this is to use editcap to change the Link-Layer type to user0:

editcap -T user0 in.pcap out.pcap

And then rightclick on "DLT" in Wireshark to set the protocol preferences. Add a new entry with:

DLT: User 0
Payload protocol: ip
Header size: 14

This will skip the first 14 bytes and decode the rest as (raw) IP.

edit flag offensive delete link

Comments

Thank you to everyone who answered this. I did some sleuthing and wrote a blog post.

https://taosecurity.blogspot.com/2019...

The tl;dr is that there's enough unexpectedly correct header values to think these are frames that are being captured in a corrupted format, but it's hard to know for sure. I did learn a bit more about Wireshark though!

taosecurity ( 2019-05-09 14:32:36 +0000 )edit

Nice writeup @taosecurity ! And thank you for the honorable mention :-) Weird frames indeed...

SYN-bit ( 2019-05-09 15:11:18 +0000 )edit

add a comment

answered 2019-05-09 05:06:44 +0000

Guy Harris
19890 ●3 ●633 ●207

The "802.3 raw" format is not part of any version of IEEE 802.3. It was a hack by Novell; to quote Don Provan's explanation of the different Ethernet encapsulations for NetWare packets:

Ethernet_802.3 came from Novell. At some point in the development of 802.3, someone at Novell got a copy of the 802.3 specification. I wasn't around at the time, so I don't know for sure what happened, but apparently it didn't occur to anyone that a legitimate datalink protocol would simply have to carry a network layer protocol identification. (Without a protocol ID, the datalink protocol could only be used for a single protocol, which isn't very practical.)

Anyway, to make a long story short, some Novell engineer implemented 802.3, but without the required 802.2 header. (Novell apologists claim that at some point in the early days of 802.3, the 802.2 header wasn't required. I'll believe that the requirement for 802.2 might not have been clearly spelled out at some point, but I cannot believe that anyone on the 802.3 committee thought 802.3 didn't need a protocol descriminator, so I'm sure the intention was always for 802.2 to be required.) Instead of an 802.2 header, in the Ethernet_802.3 frame IPX simply sits right in the 802.3 packet as the only possible protocol.

Now normally you might think that having two protocols, IPX and 802.2, both riding in the same place in the same type of frames would cause a problem. Indeed, there have been isolated cases over the years of nodes expecting 802.2 being confused by arriving IPX packets and vice versa. But by a remarkable stroke of serendipity, IPX packets, which until just recently always started with two bytes of all ones, look ridiculous to properly implemented 802.2 code. (And, on the other hand, 802.2 packets never start with two bytes of all ones, which makes them invalid as IPX packets transmitted in Ethernet_802.3 frames.) This has made the number of problems quite limited, and such bugs in the packet handling code were generally fixed posthaste.

So whoever's sending those frames is doing something they really really really really really really really really really really really really shouldn't be doing. As Don notes, there's nothing in that format to indicate what the payload's protocol is. In this case, it looks as if it might be IPv4, given the 0x45 as the first octet.

Wireshark has no mechanisms to support that. It does attempt to handle Novell protocols running atop "raw 802.3", but, to quote a comment in the code:

Ethernet802.3: A raw 802.3 packet. IPX/SPX can be the only payload.
           There's no 802.2 hdr in this.

Note "IPX/SPX can be the only payload"; for packets where the type/length field has a length value, it specifically checks ... (more)

edit flag offensive delete link

Comments

Thank you Guy -- I did end up doing a manual dissection and comparison with a similar known good packet from the trace, and blogged about the results.

https://taosecurity.blogspot.com/2019...

Sincerely,

Richard

taosecurity ( 2019-05-09 14:33:31 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Wireshark sees Ethernet LLC, but packet is probably Ethernet raw

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Wireshark sees Ethernet LLC, but packet is probably Ethernet raw edit

Comments

2 Answers

Comments

Comments

Your Answer

Question Tools

Stats

Related questions

Wireshark sees Ethernet LLC, but packet is probably Ethernet raw