Packet Challenge for the Hivemind: What's happening with this Ethernet header?
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
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
Anonymous
Nov 14th 2013
1 decade ago
Also, any chance you could try something similar with tshark to see if the outcome is consistent?
Anonymous
Nov 14th 2013
1 decade ago
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
Anonymous
Nov 14th 2013
1 decade ago
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
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
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