This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Looking for help analyzing a pcap file with odd wifi traffic

0

The traffic in the pcap (linked below) is filtered from data I was capturing (to & from my own PC) whilst connected to a public wifi. It looks like a beacon of some sort and wireshark doesn't seem to know what it is, and it's like nothing I've seen before... there are 62 packets in the pcap and I was wondering if anyone could help me figure out what it is since it's clearly not what Wireshark thinks it is. http://ziweb.co.uk/odd.pcap

asked 25 Apr '14, 09:21

jimbojetset's gravatar image

jimbojetset
11113
accept rate: 0%

edited 27 Apr '14, 12:05

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237

Can't really tell, the used ethertype (eth.type) is always 0x3600, which is not officially registered according to http://standards.ieee.org/develop/regauth/ethertype/eth.txt. And the packets only contain two different Ethernet-payloads, where only 4-bytes differ, which are as follows:

aa:aa:03:00:00:00:00:06:00:00:f5:81:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
aa:aa:03:00:00:00:00:06:00:01:af:81:01:02:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

Not sure if that helps you any further, but I haven't yet seen this in the wild, neither did a quick google-search return a result for the ethertype 0x3600..

Cheers

(25 Apr '14, 12:51) pfuender

2 Answers:

0

What software/hardware/drivers/settings did you use to capture the data? Is the other data in the packet capture ok? Can the issue be replicated?

We see the source and destination. ARP requests, 802.11 management and data frames all have a broadcast destination. You could eliminate management and data frames if the adapter was not in monitor mode.

answered 25 Apr '14, 13:52

Roland's gravatar image

Roland
7642415
accept rate: 13%

@Roland Windows 8.1 Dell Laptop using built-in wifi The other data in the capture was fine. The 'issue' is ongoing as I continue to see these odd packets. The adapter was not in monitor mode.

I have since seen several of the source addresses from that capture ARPing for odd addresses for example who is at 10.11.250.5 tell 0.0.0.0 (why tell 0.0.0.0???)

It's really odd behavior.

(25 Apr '14, 14:11) jimbojetset
1

Duplicate address detection uses "tell 0.0.0.0"

(25 Apr '14, 14:23) Roland

0

There are several possible reasons for this traffic.

  • A broken device sends arbitrary frames that just look like regular broadcasts to Wireshark. This is possible and I have seen similar things. Test: check if the MAC addresses in the capture file are really on your network. If that's the case you should see other (valid) traffic with those MAC addresses. Strange: The vendor codes of the MAC addresses indicate that it's all mobile devices (Motorola, Samsung, HTC, SoniyMobile, Apple). Any idea why this would be the case?
  • If the MAC address are really on your network and do belong to mobile devices, then there could be some kind of software (malware) installed on those devices, doing strange things. However Due to the broad range of devices (Apple, HTC, Samsung), this could be some kind of Mobile Device Management software sending out those frames, for whatever reason.
  • Somebody on your network is playing tricks and is probably trying to flood your network and/or switches for whatever reason (playing with hacker tools, etc.)

So, the key to answer your question is: Are those MAC addresses really on your network and do they belong to equipment you own.

If yes: You should check the software installed on those devices.
If no: There is either a broken device sending bogus frames, or somebody on your network is playing tricks. In both cases you can try to pinpoint the switch port where the frames come in, by searching some of the MAC addresses in the CAM table of your switch(es).

Regards
Kurt

answered 26 Apr '14, 11:49

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Kurt... Although I appreciate you taking the time to respond, did you even read the thread?

"Test: check if the MAC addresses in the capture file are really on your network." -- I already stated that I'd seen several of these MAC addresses ARPing but the return IP was 0.0.0.0!!!

"So, the key to answer your question is: Are those MAC addresses really on your network and do they belong to equipment you own." -- I already stated that the network was a public WiFi therefore how could they belong to me!!!

"In both cases you can try to pinpoint the switch port where the frames come in, by searching some of the MAC addresses in the CAM table of your switch(es)." -- I refer you to my statement above... PUBLIC WIFI... I don't own the network!!!

(27 Apr '14, 08:59) jimbojetset

Apparently I did not read your question thoroughly enough. Never mind.

BTW: if it's a public wifi, you won't be able to figure out what's really going on, without access to the attached devices. There could be a broken device or somebody playing tricks (in this case kind of stupid tricks), or any other reason. You'll never know. The traffic you have posted does not make very much sense in a 'regular' network.

BTW2: Are you sure it's not your capture equipment (wifi card in your laptop) that generates those bogus frames due to a firmware bug or something? Did you try to use a different capture device and then compare the results?

At least that's what I would have done.

(27 Apr '14, 11:32) Kurt Knochner ♦