CODEWITHSUNDEEP
wirelesswireshark
hektor
hektor

Reputation: 1025

Malformed radiotap header in wireshark

I have set up an experiment to measure Wireless communication parameters using two laptops. I am injecting custom packets into the network on a monitor interface using one laptop programmed as a transmitter(Macbook Pro using Broadcom BCM 4331 interface card) and another laptop ( Dell Latitude E6410 using the Intel Corporation Centrino Ultimate-N 6300 interface card) programmed as a receiver sniffs the network for the custom injected packets and reports parameters such as Received signal strength, propagation delay etc... The transmission is working fine and i am able to get the injected packets on the receiving side.

However , When i use Wireshark to analyze the incoming packets using the monitor interface created using airmon-ng, the radio tap header seems to be malformed. This is the same for all packets .

Also why is the Noise parameter now shown in the radio tap details?

Could anyone help me out with this?

malformed radio-tap header in wireshark

Upvotes: 1

Views: 1939

Answers (1)

user862787
user862787

Reputation:

The header might well be malformed, due to, for example, a driver bug. (I.e., a bug in the Linux driver for the Centrino adapter on your laptop.)

Unfortunately, Wireshark didn't put in any indication of what was malformed, so it's hard to diagnose this problem.

I just checked into the Wireshark trunk a change to add expert info for malformed radiotap headers; if you could try building the current SVN trunk head and see what it reports, that might indicate what's wrong with the header.

What's wrong is probably that the length field in the radiotap header is wrong.

If when you said "Also why is the Noise parameter now shown in the radio tap details?" you meant "Also why is the Noise parameter not shown in the radio tap details?", the length field being too short would explain that - the presence bitmap says that the noise parameter is present, but the header field specifies a length not large enough to include the noise parameter, so when Wireshark tries to fetch that field, it discovers that it's run past the end of the radiotap header, and reports a problem.

In addition, that would also explain why the 802.2 LLC header on several of those frames look bogus - if Wiretap skips past the length specified in the radiotap header to find the 802.11 header, and that puts it in the middle of, for example, the Noise parameter, and it tries to dissect that as if it were an 802.11 header, and tries to dissect what's after the 802.11 header as an 802.2 header, both of them could be bogus.

Upvotes: 1

Related Questions