Wireless Sniffing in Windows 7 with Netmon 3.4

Just posted this article:

Wireless Sniffing in Windows 7 with Netmon 3.4

formatting link
Let me know if there are any suggestions or corrections. Also I would be interested in hearing whether anyone has an adapter / driver that appears to successfully sniff 802.11n frames using Netmon (unfortunately, the Intel

11n adapters do not.)

Cheers,

Aaron

Reply to
Aaron Leonard
Loading thread data ...

Aaron Leonard:

How do I tell from looking at the sniffed packets, that they really are 802.11n?

I'm using Netmon 3.4 (Monitor Mode) with an Apple Macbook, Early 2009 running Windows Vista. Chipset is Broadcom 43xx, the driver is probably an Apple Boot Camp driver - I'll check.

The AP is a Netgear WNHDE111 - well, actually a WNHDEB111, but I'm only using one of them as an AP - 5 GHz, 802.11 Mode is set to "802.11n only".

And security is disabled.

The Network Interface Configuration in NM 3.4 will not let me choose

802.11a channels, only 802.11n - and 802.11b/g. This setup is done before capture is started.

So the packets probably are 802.11n. However I'm not sure that they are 40 MHz packets. How to tell?

BTW, why are you using Wireshark when NM3.4 has easy to write filters?

Reply to
Axel Hammerschmidt

Good questions. If you sniff and get nothing, it's 802.11n. That's because the data from a spatial diversity "N" radio goes via two or more paths. Each path contains part of the data, each of which is slightly time shifted, which is then reassembled by the receiver. In order to sniff such multiple paths, the sniffer would need to hear all the various paths, (which can be at different rates), hope that there are no collisions or inter-symbol interference, and do quite a bit of guesswork in order to get usable data. I don't think this is going to happen.

Perhaps because Wireshark can decode wireless packets directly, while Netmon 3.4 relys on an external protocol decoder, err... parser?

(Note: I haven't tried this decoder/parser/whatever yet).

Reply to
Jeff Liebermann

Does 802.11n use beam forming?

Anyway, I have the computer connected to the AP right next to the computer doing the capture.

Here are two captures

formatting link
formatting link
The first is a capture from an 802.11b AP done November 23rd last year. I seem to remember using a Thinkpad, connected to the AP.

The second was captured yesterday, a Macbook Pro connected to the Netgear WHDE111, setup running 802.11n only.

Both captures were done on the same Macbook Early 2009 running NM3.4 in Monitor Mode under Vista.

The first thing one notices is that the second .cap file is much bigger

- almost 4x bigger - than the first, although both sessions connect to

formatting link
and perform two login attempts and then close the connection.

You'll also notice, that all frames are 802.11n, but i think that's because the wireless card in the sniffing computer is 802.11n.

There are malformed packets in both .cap files.

The login attempts can be found by using a filter - that looks for "POST".

But only the attempts in the first .cap can be found using NM3.4. I'm not sure why?

Using Wireshark 1.4.1 (Mac OS X 10.5.8 - X Window System) the login attempt can be found in both .cap files.

So I think Wireshark is capable of doing som reassembling that NM3.4 cannot do.

The username is: pladder, and the password is: balle. This is for demonstration only. I don't have an account at the site - that belongs to a Danish computer magasine.

Reply to
Axel Hammerschmidt

A reason for this could be that the Thinkpad - Windows XP - uses a HOSTS file from

formatting link
while the Mac Book Pro does not - it's running Mac OS X. Therefor the TP doesn't have to download from as many ad-servers as the MBP. Although this can't be confirmed by looking at captured packets.

Reply to
Axel Hammerschmidt

Optional. The committee threw in the kitchen sink with both beam forming and spatial diversity. Vendors can impliment either, or both.

Note the comments on SISO etc, which might be what you're receiving.

I'll look at the capture files when I have time. I'm rather over-subscribed for another week.

The problem with 802.11n is that with most setups the Data frames going in one direction will be missed. I don't know exactly why this is and I don't know all of the technical reasons behind it, but trust me, it happens. If you set your 802.11n capture to a standard channel (in my case today, a 20 MHz wide, 2.4 GHz channel 1) you'll almost always capture data going in one direction but not the other. You will usually get non-data frames going in both directions (identified by frequent acknowledgments without data preceding), but not all of the data.

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.