| Summary: | Can't monitor 802.11n IP traffic for RT3070 devices in monitor mode | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin <martind1111> |
| Component: | kernel | Assignee: | John W. Linville <linville> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-03-29 17:07:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Martin
2011-03-23 17:09:47 UTC
The iwconfig tool is old and ignorant of 802.11n. I would advise the following sequence: ifconfig wlan1 down iw dev wlan1 set monitor none iw dev wlan1 set channel 1 HT20 ifcofnig wlan1 up tcpdump -i wlan1 I'm not sure that the ip filter is appropriate for tcpdump for a wireless device in monitor mode, but YMMV... Does this give you output from tcpdump? It is possible that the driver needs something more as well. With the "iw dev" commands listed in the previous comment, I am now able to get 802.11n traffic with a RT3070 device. Note that with an Intel IWP4965 device and a number of other devices (Atheros 9170, RT2870), it is possible to capture 802.11n traffic in monitor mode using the iwconfig commands. I am not sure why the same commands do not work for the RT3070 chipset, but it is good to know there is a workaround. I'm glad it's working for you. But, it isn't a workaround -- it is how things work. In fact, if you use the older tools (e.g. iwconfig) then the command that comes to the driver to change the channel actually specifies _not_ to do HT (i.e. 802.11n). So, you could argue that if it works for the other devices you cite then it is a bug in _those_ drivers. But, more likely it is just an artifact of how that other hardware works. I think we'll let it slide... :-) Anyway, it seems that your issue is resolved. Closing on the basis of comment 2. |