Modify

Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#9979 closed defect (fixed)

ath9k passes bad packets in monitor mode on DIR-825 rev. B1

Reported by: Ellingson Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: base system Version: Trunk
Keywords: ath9k, monitor mode, bad packets, airodump Cc:

Description

Putting ath9k-driven interfaces in monitor mode on DIR-825 B1 and listening to traffic results in lots of bad packets being passed to software. This problem has been present since at least 10.03.1-rc4, and is confirmed in current/trunk.

The problem is easily reproduced, eg. as follows:

  • install appropriate software, like aircrack-ng or horst
  • set interface in monitor mode ('airmon-ng wlan0 start' or 'ifconfig wlan0 down;iwconfig wlan0 mode monitor;ifconfig wlan0 up')
  • run software on monitoring device ('airodump-ng mon0', 'horst -i mon0', or substitute 'wlan0' for 'mon0' if you didn't use airmon-ng)
  • watch as lots of non-existent clients and APs pop up and fill the screen

I have done serveral tests to ensure this indeed a case of bad packets being passed and not just noise in the air.

1) There are no other wireless networks nearby, nor any other clients
2) The bad/illusory APs and clients do not show up on a laptop running the same software, same version, in monitor mode (as a side note, the laptop is also using ath9k, on debian)
3) The MAC-adresses that show up are 'bad', they do not correspond to any known vendor fields, eg. DD:EE:0F:0F:FF:02
4) Quite a few of the bad-packet MAC-addresses are minor permutations of the real, existent MAC-addresses of my AP and laptop client, where the last two or three bits are swapped for something else.

It's quite clear to me that the ath9k drivers are passing bad packets here. While I haven't had problems with the wireless otherwise, it gives cause for concern that the drivers will happpily pass along corrupt data.

Attachments (0)

Change History (4)

comment:1 Changed 6 years ago by trashbox@…

From original ticket poster:

I should add that this is also not:

1) An antenna problem. I've performed the tests with the antennas detached.

2) Faulty hardware. Two different devices from different batches/stores were tested, also with antennas detached/attached, with the same results.

comment:2 Changed 6 years ago by nbd

yes, the driver passes bad packets to monitor interfaces, but it should also mark them as such in the radiotap header. so this problem may actually just be the user space app ignoring that flag and thus not filtering out the bad stuff.

comment:3 Changed 6 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fixed in trunk r28392

comment:4 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.