Hi this is my first post to the forum. I recently bought a Cisco WAP371 to use as an 802.11ac packet capture device. I have it set up to operate on the 5GHz radio only with channel 48 as the primary channel and have selected 80 MHz channel width. There are no wireless clients associated with the WAP and I use my laptop connected to it via Ethernet to turn packet capture on and off. I have been experimenting with capturing packets between my desktop computer which has a Netgear A6210 802.11ac client adapter and my home wireless router which is a Netgear R7000 running Asuswrt-Merlin firmware (also set up for channel 48 @80MHz channel width). I download the captured trace files to my computer to examine with Wireshark (I have the latest version installed). For the most part it works well and as expected but I do have a few observations/questions that I would like to ask.
Thanks in advance for any guidance or insights anyone can give me. Regards Mike asked 21 Jul '16, 09:58  GromitD90 |
3 Answers:
Ah Hi Mike, looks like we're trying to do the same thing :) Please see https://www.wireshark.org/lists/wireshark-users/201505/msg00002.html and https://supportforums.cisco.com/discussion/12490711/wap371-firmware-v1123-packet-capture-missing-packets-and-2-other-bugs and https://supportforums.cisco.com/discussion/13080401/wap371-packet-capture-questions Unfortunately after pursuing with Cisco they ultimately declared that it's only supposed to be used for sampling and not a full capture and that it was down to hardware limitations. I have a WAP571 now and am receiving the same error as you, so either a subsequent firmware update has totally bricked the Wireshark interoperability.. or a new Wireshark has. answered 17 Aug '16, 12:15  matthew1471 edited 17 Aug '16, 12:46 Matthew thanks so much for responding here. I've been pulling my hair out trying to figure this out. My issue has not been packet loss. I bought the WAP371 specifically to do 802.11ac packet capture so I'm a little disappointed that Cisco are now saying that it's not up to the task. I have been using the procedure where packets are captured locally on the WAP and then transferred the pcap file for later analysis by Wireshark. I have also used a different analysis program and that also showed up the same issues - so in my case this is not a Wireshark issue at all. Seems to be a failure of the packet capture feature of the WAP to correctly interpret the radiotap information. Is this what is happening with the 571 too? Mike (17 Aug '16, 15:23) GromitD90 |
I am not familiar with this particular Cisco device, but other devices they have include similar functionality. Looking at the user guide, you have to select the correct interface to capture on - and since this is both a 2.4/5GHz device, it has two radios. Which one did you choose, and did you try the other one?
From the document,
I think you want to capture on Radio 1. Radio 2 is 2.4GHz. If you have selected and accepted capture on Radio 1, try Radio 2. If the issue continues, provide a short capture with some captured beacons from each radio setting. The HT and VHT info IEs in the beacons indicate which channels are in use (base and extension channels, if any). It will be interesting to see how that matches up with what might be indicated in the radiotap header, as it relates to your configuration of the AP device. Your points 1 & 2 are consistent with not capturing on 5GHz, as just described. Try changing the config and see what happens. I am not sure about point 3 with wrong FCS - I have no idea what the Cisco will do with FCS. Attach a short capture if you want us to take a look - also check the 802.11 preferences for an assume/validate FCS options. Toggling these may change the behavior and may make the 'view' more palatable. For point 4, if you are capturing on 2.4GHz but transferring test data on 5GHz, there is absolutely no relationship between the packet capture and the physical environment. The rates you are seeing are representative of something, but it's unknown and not your test. Are you sure your test traffic is 5GHz? Verification is possible by matching MAC addresses and BSSIDs in the trace, and those frames are the ones that you want to evaluate for rates and other performance parameters. answered 23 Jul '16, 10:29  Bob Jones |
OK, good, radiotap is capable of 1) reporting the 5 GHz channel, 2) reporting 11ac information, 3) indicating whether the FCS is present. Therefore:
Either you're not capturing on a 2.4 GHz channel or Cisco's not properly filling in the radiotap header. Check out Bob Jones' answer first and, if you're certain you're capturing on the 5 GHz channel, report this to Cisco as a bug.
Either it's not an 11ac frame or Cisco's not providing a VHT field in the radiotap header. If you're certain that the frames in question are 11ac frames, report this to Cisco as a bug. (Beacons, obviously, won't be 11ac frames - they're typically 11b frames, so all machines can see them.)
If the frames include an FCS at the end, and the WAP371 doesn't set the "FCS at end" flag, report that to Cisco as a bug.
Presumably by "Tx rate" you mean the data rate. A radiotap header can include a data rate. It might not, in which case, if the frame is an HT frame (11n), Wireshark will calculate it based on the MCS, channel width, and guard interval length - for other frames, including VHT frames (11ac), Wireshark currently won't calculate the data rate. Do the frames with the lower data rates have a data rate field in the radiotap header? If so, and if it's lower than it should be, report that to Cisco as a bug. Otherwise, has Wireshark calculated the data rate (if it has, the entry in the radiotap header will be in square brackets, e.g. "[Data rate: 106 Mb/s]"). answered 23 Jul '16, 17:44  Guy Harris ♦♦ @Guy, My version of Wireshark calculates and 802.11ac datarate properly (2.0.4-GTK / Linux):
(24 Jul '16, 01:00) Bob Jones Thanks again for the feedback. I can definitely confirm that my AP and client are both operating in the 5GHz part of the spectrum, the wireshark trace even lists the Channel Frequency as 5210 [A 42] on the captured packets. However the Radiotap header does not have the VHT info on any captured packets. I'll have to go back to the drawing board and play around with some other settings on the WAP371 (24 Jul '16, 05:31) GromitD90 I spent some more time on this and am convinced it is a Cisco issue. If I do A live Wireshark Capture on the Primary 802.11ac channel using an airpcap adapter I see all the VHT info and it says it is operating on 5G so my AP is sending out the right info. Of course I cannot see the data packets. So I tried setting up to do a remote capture from the WAP371 to Wireshark to see if that worked. I can configure Wireshark to see the remote interfaces so there is communication between the devices but whenever select an interface and hit start I get an error message saying Error reading from pipe. This operation returned because the timeout period expired (error 1460). What timeout is that? Can I increase it? (24 Jul '16, 13:59) GromitD90
This is not consistent with what I thought your issue is. Where do you see the VHT info now? You can't see VHT info in a radiotap header with an AirPcap (assuming the NX, since it supports 2.4 & 5, while the AirPcap only support 2.4GHz). You should see some VHT info in the beacons as IEs, but not in the radiotap header. To actually prove you have 802.11ac frames, you need to see something like I have shown in the radiotap header. Only data frames will be at ac rates; CTS/RTS, probes, beacons, Block ACKs, etc., will be at much lower 802.11a rates. So in the Cisco case, you seem to be looking in the radiotap header and don't see what you need. Sometimes you see 2.4GHz, sometimes 5GHz, maybe. Example
compared to
Frankly, I have no idea what you are or are not seeing. There might be Cisco bugs here, but I am not convinced. (24 Jul '16, 14:21) Bob Jones
I'm pretty much convinced there is at least one Cisco bug:
There might, or might not, be more. (24 Jul '16, 14:38) Guy Harris ♦♦ |
1) If you read the capture into Wireshark, and open up the capture file properties window (Statistics -> Capture File Properties in the Qt version, Statistics -> Summary in the GTK+ version), there will be a list of interfaces, which should have one entry - what does it say in the "Link type" column?
2) What version of Wireshark are you running?
Guy - thanks for responding.
Mike
Guy - sorry I was looking at a different pcap file. The ones captured from the WAP371 show a link type of IEEE 802.11 plus radiotap header. Which makes more sense.