Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Sorry Guest, you are banned from posting and sending personal messages on this forum.

This ban is not set to expire.

[cmw]

Hello all,

I am having trouble capturing data frames on 40 & 80 Mhz wide channels.  My situation and efforts are described below.

WLAN cards used: Alfa AWUS036ACH, Alfa AWUS051NH (everything below was done with the AWUS051NH)

OS:  Kali 2017.1, updated as of 9/5/17

Characteristics of the test WLAN:
- Apple 802.11n Time Capsule ( version 7.6.8 )
- Primary channel: 36
- Channel width: 20 & 40 MHz supported
   wlan.ht.capabilities.short20 == 1
   wlan.ht.capabilities.short40 == 1
- Secondary channel is above the primary channel
   wlan.ht.info.secchanoffset == 0x1
- Non-greenfield STAs are present on the network
   wlan.ht.info.greenfield == 1

When I connect the system to the WLAN as a regular client (Alfa AWUS051NH) it connects without issue and utilizes the 40Mhz channel.  The output of iw dev when connected as a client is:

Code: [Select]

# iw dev
phy#0
Interface wlan0
ifindex 3
wdev 0x1
addr 00:c0:ca:32:be:73
type managed
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm

On a fresh reboot I place the adapter in monitor mode and capture packets using airodump-ng. I am able to capture to capture control frames (RTS, CTS, Block Ack) and management frames (Probe Request, Response, etc.) and I capture EAPOL frames (4-way handshake) without issue.  I can also capture some data frames.  When decrypted they include ARP, QoS Nulls, IPv6 Neighbor Solicitations, MDNS, and IPv6 Multicast Listener Reports.  What I am missing are all the data frames.  The unencrypted capture contains mostly RTS, CTS and Block ACKs (my explanation of why is explained below).

In an effort to capture data frames on the 40MHz channel I have done the following steps:

Code: [Select]

airmon-ng check kill
airmon-ng start wlan0
airodump-ng --bssid 5C:96:9D:68:12:34 --channel 36 wlan0mon -w testcap

When I run iw dev after these steps I get:

Code: [Select]

# iw dev
phy#0
Interface wlan0mon
ifindex 4
wdev 0x2
addr 00:c0:ca:32:be:73
type monitor
channel 36 (5180 MHz), width: 20 MHz (no HT), center1: 5180 MHz
txpower 20.00 dBm

So I tried to manually set the channel on both the device and the interface:

Code: [Select]

ifconfig wlan0mon down
iw wlan0mon set channel 36 HT40+
iw phy phy0 set channel 36 HT40+
ifconfig wlan0mon up

# iw dev
phy#0
Interface wlan0mon
ifindex 4
wdev 0x2
addr 00:c0:ca:32:be:73
type monitor
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm

# iw wlan0mon info
Interface wlan0mon
ifindex 4
wdev 0x2
addr 00:c0:ca:32:be:73
type monitor
wiphy 0
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm

After doing that I restart the capture:

Code: [Select]

airodump-ng --bssid 5C:96:9D:68:12:34 --channel 36 -w testcap wlan0mon

And, to my disappointment, everything is back to 20Mhz widths:

Code: [Select]

#iw wlan0mon info
Interface wlan0mon
ifindex 4
wdev 0x2
addr 00:c0:ca:32:be:73
type monitor
wiphy 0
channel 36 (5180 MHz), width: 20 MHz (no HT), center1: 5180 MHz
txpower 20.00 dBm

# iw dev
phy#0
Interface wlan0mon
ifindex 4
wdev 0x2
addr 00:c0:ca:32:be:73
type monitor
channel 36 (5180 MHz), width: 20 MHz (no HT), center1: 5180 MHz
txpower 20.00 dBm

I believe I know why I am getting the results I am getting:  all of the captured frames are transmitted on the 20Mhz primary channel.  When the transmitting node is sending data packets (HTTP, SMB, etc.) it is using the 40MHz channel and, with protection enabled, it is using RTS/CTS to do so.  Airodump-ng is not seeing the data being transmitted because it is only monitoring the 20Mhz primary channel (and not the 40Mhz). 

Neither the adapter nor the driver appear to be an issue as I can connect to and make use of the 40Mhz channel as a regular client.  It is only when capturing in monitor mode that I run into an issue.  So, I'm here, feeling a bit defeated, asking for some guidance.  I searched through the aircrack-ng and Kali forums but didn't find an answer.  I also Googled for a long while but came up equally empty-handed.  If my Google skills are weak, please flame me and provide me a link.

Two questions: 
1.  Why am I unable to capture on the 40Mhz channel?
2.  Is there anything I can do to get my adapter to capture on the 40Mhz channel rather then just the 20Mhz?  I would like to be able to capture the data frames.

Side note: I am able to capture just fine (as expected) when channels are only 20Mhz wide.  80Mhz-wide 802.11ac channels exhibit the same problems as above when capturing with either of the Alfa adapters.

[robertkjonesjr]

As a script, I use the following to setup one of my adapters for 802.11ac/80MHz, channel 149 as primary channel:

ifconfig wlan149 down
iwconfig wlan149 mode monitor
ifconfig wlan149 up
iw wlan149 set freq 5745 80 5775
iw dev wlan149 set monitor fcsfail control

See also (and others):

https://ask.wireshark.org/questions/54074/capture-5ghz-wifi-traffic-for-a-40mhz-width-channel

Can you just use Wireshark/dumpcap/tcpdump to capture the packets?  If it is airodump that is changing the configuration, use a different tool to capture that does not change the configuration.

[cmw]

Taking robertkjonesjr's suggestion I removed aircrack-ng from the equation.

After a fresh reboot:

Code: [Select]

iw phy phy0 interface add mon0 type monitor
iw dev wlan0 del
ifconfig mon0 up
iw dev mon0 set freq 5180 HT40+
tcpdump -i mon0 -n -w testcap.cap
wireshark testcap.cap

Note:  Channel 36 (which my AP is on) only supports HT40+ (not HT40-).  For extra checking I also tried channel 40 with HT40- (iw dev mon0 set freq 5200 HT40-).  Same result.
While the capture is running I see what iw has to say about things:

Code: [Select]

# iw mon0 info
Interface mon0
ifindex 4
wdev 0x2
addr 00:c0:ca:32:12:34
type monitor
wiphy 0
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm

# iw dev
phy#0
Interface mon0
ifindex 4
wdev 0x2
addr 00:c0:ca:32:12:34
type monitor
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm

Sweet.  If the command output is telling the truth channels are 40 Mhz.  But... still no data frames are being captured.  I'm getting smarter but my problem isn't going away.

This suggests that airodump-ng is off the hook as my problem (even though it insists on setting the dev and phy back to 20MHz when invoked). 

If airodump-ng isn't the problem I may have just lost my audience.  As an optimist I'm hoping there is a crazy-smart person out there laughing at how obvious the solution is (that I'm missing).  If you're that person, please drop knowledge upon me.

Thanks.

 

[robertkjonesjr]

This isn't obvious - wireless packet capture is quite difficult.

I think the channel width is only one of your problems.  There are likely others - the modulation capabilities must match, and these include:

0. Does the capture interface support monitor and promiscuous mode?
1. Band capability (2.4 vs 5GHz)
2. Specific channel (maybe DFS support or not, extra 2.4 channels in Japan with a US adapter, etc)
3. Channel bandwidth (20/40/80MHz, etc)
4. Guard interval (short or long)
5. Encoding (not many devices do LDPC)
6. Spatial streams (2x2 vs 802.11ac Wave2, which can do 4x4, etc)
7. 802.11n vs 802.11ac support, or no HT/VHT support at all
8. A-MSDU frame size (if bigger than capture system can support it cannot be captured)
9. And others...

I suspect (5) in your case, but I am just guessing. 

[cmw]

Interesting.  Thank you for your continued input.  My current issues aside I'm both intrigued and concerned for the capacity to do legitimate 40/80/160MHz 802.11 captures for troubleshooting purposes.  The diversity of feature sets offered by both APs and clients does not bode well for deeper analysis of WLAN traffic.  Now if I could only find a WLAN adapter that can do it all...

As for my specific situation:

0.  Yes, my adapter supports monitor and promiscuous mode
1.  My adapter is dual band
2.  Channel 36 isn't in U-NII2e so I don't think DFS is an issue here (but ...point taken)
3.  Channel width ...where I am now....
4.  Guard Interval support is consistent across the clients (per AP Beacon and iw phy0 info | grep GI on client adapters)
5.  LDPC ...don't see any mention of it for adapters or clients so I currently don't know on this one.  I'll have to research some more to figure this one out.
6.  Both client and capturing node are using similar adapters but I'll try matching model numbers to make sure spatial stream support is consistent.
7.  Support seems to match on clients and AP
8.  I'll have to check on A-MSDU size support.  But I wonder if the legit client was using an MSDU that was bigger than the sniffing adapter supported would he see nothing or would he register a malformed 'something'.
9.  Beamforming isn't supported by the AP I am using but I can see where it might be a problem, too...

Next steps:
1.  I'm going to take 3 idendical adapters (Alfa AWUS051NH) and configure one as the AP, one as the client and then capture with the third.  My first thought is that this will level the playing field on device feature support.  That should help eliminate some of these list items as potential culprits.  Agreed?

It make take me a few days to find time to do it but I'll report back when I do.  If nothing else, others may benefit from this thread in the future.

Thanks again, robertkjonesjr.