Bug 457149 - iwl4965 only captures management frames in monitor mode
iwl4965 only captures management frames in monitor mode
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
i386 Linux
low Severity low
: rc
: ---
Assigned To: Stanislaw Gruszka
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-29 17:22 EDT by Bruce Keats
Modified: 2010-03-16 03:27 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-16 03:27:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruce Keats 2008-07-29 17:22:40 EDT
Description of problem:
When the IWL4965 driver is running in monitor mode, it appears to collect only
management frames.  I do not see any data frames even though ATHEROS based
wireless card in the same laptop is able to capture data frames.

Version-Release number of selected component (if applicable):
Kernel is 2.6.18-92.1.6.el5PAE
iwl4965 firmware is iwlwifi-4965-ucode-228.57.1.21

How reproducible:


Steps to Reproduce:
1. load the firmware.
2. reboot the laptop
3. ifconfig wlan0 down
4. iwconfig wlan0 mode monitor
5. iwconfif wlan0 channel 9
6. tcpdump -i wlan0
   - you should see lots of frames, but you data frames.
  
Actual results:


Expected results:


Additional info:
Comment 1 Stanislaw Gruszka 2010-03-15 08:57:36 EDT
Tried on new kernel, it works for me:

>[root@dhcp-lab-109 ~]# tcpdump -i wlan0 | grep Data
>tcpdump: WARNING: wlan0: no IPv4 address assigned
>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus BSD radio information header), capture size 96 bytes
>13:55:53.740678 1.0 Mb/s 2412 MHz (0x00a0) -75dB signal -127dB noise antenna 3 [0x0000000e] Data IV:120000 Pad 7 KeyID 1
>13:55:53.954948 1.0 Mb/s 2412 MHz (0x00a0) -32dB signal -127dB noise antenna 3 [0x0000000e] Data IV:2ea Pad 20 KeyID 2
>13:55:54.283427 1.0 Mb/s 2412 MHz (0x00a0) -68dB signal -127dB noise antenna 3 [0x0000000e] Data IV:120000 Pad 7 KeyID 1
>13:55:54.286197 1.0 Mb/s 2412 MHz (0x00a0) -65dB signal -127dB noise antenna 3 [0x0000000e] Data IV:120000 Pad 7 KeyID 1
>13:55:54.426893 1.0 Mb/s 2412 MHz (0x00a0) -68dB signal -127dB noise antenna 3 [0x0000000e] Data IV:120000 Pad 7 KeyID 1
>13:55:54.429398 1.0 Mb/s 2412 MHz (0x00a0) -67dB signal -127dB noise antenna 3 [0x0000000e] Data IV:120000 Pad 7 KeyID 1
>13:55:54.433851 1.0 Mb/s 2412 MHz (0x00a0) -67dB signal -127dB noise antenna 3 [0x0000000e] Data IV:120000 Pad 7 KeyID 1
>13:55:54.963836 1.0 Mb/s 2412 MHz (0x00a0) -72dB signal -127dB noise antenna 3 [0x0000000e] Data IV:120000 Pad 7 KeyID 1
>13:55:55.065000 1.0 Mb/s 2412 MHz (0x00a0) -32dB signal -127dB noise antenna 3 [0x0000000e] Data IV:2eb Pad 20 KeyID 2
>13:55:55.474534 1.0 Mb/s 2412 MHz (0x00a0) -76dB signal -127dB noise antenna 3 [0x0000000e] Data IV:120000 Pad 7 KeyID 1
>157 packets captured
>158 packets received by filter
>0 packets dropped by kernel


Bruce, 

Do you still have this problem on newest kernel from http://people.redhat.com/jwilson/el5/ ?
Comment 2 Bruce Keats 2010-03-15 11:30:18 EDT
The problem has been fixed for awhile now (probably RHEL 5.3 or 5.4)  I was corresponding directly with John Linville back when I discovered the problem.
Comment 3 Stanislaw Gruszka 2010-03-16 03:27:16 EDT
Great. I'm closing bug :)

Note You need to log in before you can comment on or make changes to this bug.