My next class:

Packet Challenge for the Hivemind: What's happening with this Ethernet header?

Published: 2013-11-13. Last Updated: 2013-11-14 17:02:04 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

Earlier this week, a user submitted one of those "odd packets" we all like. The packet was acquired with tcpdump, without the "-x" or "-X" option, but still, tcpdump decided to dump the entire packet in hexadecimal. I have seen tcpdump do things like this before, and usually attributed it to "packet overload". If I have tcpdump write the same traffic to disk (using the -w option) and later read it back with -r, I don't see this questionable traffic.

But I never bothered to really look into it. So today, returning from the dentist and under the influence of Novacaine after crown prep, I decided what better thing to do but to play a bit with packets.

Here is the setup:

I am running tcpdump on my firewall. I have it listen on all interfaces. The exact command line:

sudo tcpdump -i any -nn -xx  not ip and not ip6 and not arp

Now if I got this filter right, I should see no IPv4, no IPv6 and no ARP . At first, I got packets like this:

21:39:55.404619 Out 00:e0:4c:68:e0:7d ethertype Unknown (0x0003), length 344:
0x0000:  0004 0001 0006 00e0 4c68 e07d 0000 0003
0x0010:  4510 0148 0000 0000 8011 2e93 0a05 00fe
0x0020:  ffff ffff 0043 0044 0134 cb27 0201 0600
0x0030:  1223 3456 0000 8000 0000 0000 0a05 004a
0x0040:  0a05 00fe 0000 0000 000e f316 a4a6 0000
0x0050:  0000 0000 0000 0000 0000 0000 0000 0000
0x0060:  0000 0000 0000 0000 0000 0000 0000 0000
(removed remainder: all "0").

Interestingly, the packet has an "off" ethernet header that looks like it got an additional two bytes, followed by what looks like a normal IPv4 header.

On a second attempt, using the same filter, I even got some packets that got interpreted as IPv4, even though my filter should exclude them:

21:44:01.919690 IP 10.128.0.11.56559 > 10.5.1.12.80: Flags [.], ack 421172865, win 403, length 0
0x0000:  0000 0001 0006 8ab0 1e25 1fcb 0000 0800
0x0010:  4500 0028 b78a 4000 4006 6daa 0a80 000b
0x0020:  0a05 010c dcef 0050 69b5 295b 191a 9681
But again, note the extra long ethernet header. So what is happending? Wireshark doesn't help. Also, the MAC addresses are not right.
 
Please submit any ideas via the comment form or as a comment to this post.

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: ether type packets tcpdump
7 comment(s)
My next class:

Comments

One thing you have to consider in a situation like this: did you get a line transmission error at the physical layer? This could cause the nic to trigger thinking it saw the start of a packet, when in fact it was just random noise on the line that happened to look like the preamble.

Anonymous

Nov 14th 2013
1 decade ago

Any chance you're using VLAN tagging and the information (or half of the information) is getting added to the captured packets? Albeit if that were the case, there should be an additional 4 bytes rather than 2, which would contradict what you're seeing. Curious if we can rule out VLAN tag information completely (or some other related scenario) as the source of the additional bytes.

Also, any chance you could try something similar with tshark to see if the outcome is consistent?

Anonymous

Nov 14th 2013
1 decade ago

What do you mean with "The MAC addresses are not right"? 00:e0:4c is a valid prefix registered for Realtek, so it's most probably some cheap china device on your network. ;-)

I have recently had a similar problem on my home network, where I saw the network performance of my FritzBox degrade rather steeply. A packet capture gave me a whole flood of packets from a pseudo-MAC which, according to usual web ressources, is only used by Atheros cards while in firmware update mode. After spending a few hours checking the MACs and NIC vendors of all my known-attached hardware turned up no Atheros device, I assumed that either Wireshark was fooling me, or someone got into my Wifi without my Cisco AP reporting the link to his syslog. Only a day later I found out that the FritzBox itself has an Atheros Wifi chip (which I switched off in favor of my Cisco, and which seems to put the chip into this strange pseudo-upgrade mode), and apparently due to some bug, the card started talking to itself heavily, which for a yet unknown reason ended up on the wire instead of the air.

Anonymous

Nov 14th 2013
1 decade ago

what about half duplex / full duplex issues?

Anonymous

Nov 14th 2013
1 decade ago

No VLANs as far as I know. The IP addresses exist,and connections to them work fine. Some of them are connected to the network via an OpenVPN tunnel in "tap" mode, so maybe that causes some corrupt packets. Yes, some of the MAC addresses are real and assigned to this gateway, but not all.

e.g. first 16 bytes of the TCP packet (which is more "normal"):

0000 0001 0006 8ab0 1e25 1fcb 0000 0800

If you assume that 0800 is the IPv4 ethernet type (which does make sense here), then the MAC address would be 0000 0001 0006 or 8ab0 1e25 1fcb.

Anonymous

Nov 14th 2013
1 decade ago

This is a BOOTP/DHCP UDP datagram. The ethertype (0x0003) is actually defined in kernel source in if_ether.h under Non-DIX ethertypes.

Below is the relevant information from the hex dump given in the post:

Ethernet:
OUI
Destination: Lexmark 00:04:00
Source : RealtekS 00:E0:4C

Type/Length: 0x0003 -> Non-DIX ethertypes defined in if_ether.h with the warning: /* Every packet (be careful!!!) */

0x45 IPv4 and header length: 5 32bit words
TOS: 0001 0000

Precedence: 000 Routine
Low Delay 1
Normal Throuput 0
Normal Relibility 0

0148 : length 328 bytes
0x80 TTL 128
2e93 checksum

Protocol: 0x11 (17) -> UDP

Source ip address: 0a05 00fe (10.5.0.254)
Destination ip address: ffff ffff (255.255.255.255)

Source Port: 0x0043 (67)
Destinatin Port: 0x0044 (68)

Anonymous

Nov 14th 2013
1 decade ago

Do you have any ATM devices on your network? SNAP protocol says 0x0003 is MARS/NHRP, which looks like it prefixes 16 bytes onto the front of the typical SNAP header which looks like what you're getting...

http://tools.ietf.org/html/rfc2022#section-1.2

http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml

Anonymous

Nov 14th 2013
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives