Jump to content

Mk4 - Poor Rx And "corrupted Radiotap Headers"


DrBen
 Share

Recommended Posts

Hi guys,

Got a fresh MK4 in the mail this week and mucking around with it since, but Im stuck..

Running airodump on the MK4 showed only a fraction of the networks that my other monitors pick up.

To verify that, I set up three devices a few centimeters apart: one AP in standard mode, just broadcasting beacons, another AP running airdump, and the MK4 also running airdump.

Both airdumps locked onto the channel where AP1 is broadcasting.

The result: The MK4 is picking up less than 10% of the beacon frames than the other AP.

I have to assume that signal strength or interference dont play much of a role, since the devices are sitting right next to each other on the shelf. Switching channels: same result.

So I installed kismet onto the MK4. The dump results arent much better, and kismet is spamming the command line with the following message:

"ERROR: pcap radiotap converter got corrupted Radiotap header length"

Googling that message doesnt help much. The only hint I got was dragorn saying that this is due to an outdated kernel, which is obviously not the case here.

Here is some additional info on my MK4 setup:

Pineapple Hardware Version: Mark IV

Pineapple Software Version: 1.1.1

All the tools/options that are running on the pineapple when the issue happened: default 1.1.1 firmware + kismet-server (via opkg from trunk)

Ping results from computer to pineapple: consistenly below 1ms

Is the problem repeatable (Yes/No): Yes. I reflashed to be safe: same result.

Steps taken which created the problem: install firmware, install kismet, configure kismet, run kismet

Kismet config: nsource=wlan0, rest of the config remains stock

Error Messages: "ERROR: pcap radiotap converter got corrupted Radiotap header length"

Any pointers how I can further investigate this issue are highly appreciated!

Link to comment
Share on other sites

After reading that thread, I reseated the connector on the board, and replaced the antenna with a 5db patch antenna pointed directly at the Tx.

I did a test run, and the MK4 now picks up the same number of beacons as the control device. Might have been a loose connector, although it looked good before.

But that only increased the number of "corrupted Radiotap" errors when running kismet.

The control device does not produce a single of these errors.

Both devices run the same kismet version and drivers.

Are these errors something to be concerned about?

Could someone start kismet_server on a 1.1.1 MK4 and check if he gets these messager?

Link to comment
Share on other sites

After reading that thread, I reseated the connector on the board, and replaced the antenna with a 5db patch antenna pointed directly at the Tx.

I did a test run, and the MK4 now picks up the same number of beacons as the control device. Might have been a loose connector, although it looked good before.

But that only increased the number of "corrupted Radiotap" errors when running kismet.

The control device does not produce a single of these errors.

Both devices run the same kismet version and drivers.

Are these errors something to be concerned about?

Could someone start kismet_server on a 1.1.1 MK4 and check if he gets these messager?

loose connector issue is on the pcb I believe? you have to open it up

Link to comment
Share on other sites

Could someone start kismet_server on a 1.1.1 MK4 and check if he gets these messager?

I started kismet_client and used wlan0 as source.

I captures SSID's for a short while and then i get the following errors in the kismet console:

pcap radiotap converter got corrupted Radiotap header length
pcap radiotap converter got corrupted Radiotap bitmap length

When i clicked the window option in the kismet menu the device froze and rebooted itself :mellow:

Link to comment
Share on other sites

loose connector issue is on the pcb I believe? you have to open it up

thats what I did. pcb connector is good.

Im currently assuming a software issue.

That Kismet is producing these errors, while the same Kismet version is running fine on a similar platform points to some issues in lower levels.

All other tools that rely on good capturing might suffer from this problem, but are not able to report it.

Will be interesting to see what happens when the next firmware is released based on the 3.2 kernel.

Good stuff!

Worth holding my breath? You got an ETA for us?

Edited by DrBen
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...