Capturing raw native 802.11 packets from filter driver

NTDEV
1

Okay, I’m really stuck here. There was a good thread on these forums a while back ( http://www.osronline.com/showThread.CFM?link=134437 ) that helped a lot to get me started.

I’m trying to write code that can capture raw native 802.11 packets to
essentially write a packet sniffer. I’m using Vista with 802.11
device which uses an NDIS 6.0 native 802.11 driver. The reason I need to do this is because I’m writing an amateur 802.11 hardware radio using an FPGA, so I’m trying to capture all packets from an 802.11 client, including the bad packets that fail CRC, so I can do debugging on the raw bits to verify encoding and to see if and how my transmitter is distorting the bits I’m sending. I know there is stuff for linux that already does this, but I decided to try writing some windows code after seeing NDIS documentation that claimed you could do this… It’s turning out to be more tricky than it originally seemed…

Perhaps I am going about this the wrong way (and please let me know if
there are better alternatives!) I’m trying to do this all through the
Windows SDK or Windows DDK for Vista and higher.

Doing some googling and reading the documentation, it seems like the
best way to do this is run a monitoring light weight filter using the
Windows DDK. I modified the ndislwf sample to be a monitoring filter
driver and attach to “wlan” media types. I seem to be able to put the
device into monitor mode and extensible station mode via
OID_DOT11_CURRENT_OPERATION_MODE. I can also confirm that ndislwf is
attaching successfully to the NdisMediumNtive802_11 type.

The problem is my calls to set OID_GEN_CURRENT_PACKET_FILTER with
{ NDIS_PACKET_TYPE_PROMISCUOUS |NDIS_PACKET_TYPE_802_11_RAW_DATA |
NDIS_PACKET_TYPE_802_11_PROMISCUOUS_MGMT |
NDIS_PACKET_TYPE_802_11_RAW_MGMT |
NDIS_PACKET_TYPE_802_11_PROMISCUOUS_CTRL }

(as described here: http://msdn.microsoft.com/en-us/library/bb648512.aspx)
Seem to never take effect even though they return successfully from
NdisFOidRequest. According to the documentation the
DOT11_EXTSTA_RECV_CONTEXT associated with the NET_BUFFER_LIST passed
to FilterReceiveNetBufferLists should indicate
DOT11_RECV_FLAG_RAW_PACKET if these filters are set in monitor mode, but this flag is never set.

There must be something I’m doing wrong here because the microsoft documentation clearly specifies that raw packets should be flagged in this situation. I’m using a bcm42xx chipset using a native 802.11 NDIS 6.0 driver. Anyone have any ideas on this one? How can I capture the raw packets and get this flag to be indicated? I’d be happy to post my code if I can get this working…

Thanks!

2

So NetMon 3.2 can do 802.11 packet capture and uses a LWF to accomplish
this.

So has this turned from trying to watch what your FPGA sends to duplicating
what other (totally free) packet sniffers do?

I am not sure about showing you frames with CRC-Errors however in any case.
I do not think that the hardware is under any obligation to indicate such
frames.

As for the Linux tools (and yes, there are fine Windows versions of free
tools that do this too) most of these either use a special driver on a
specific chip-set so that ‘extra’ facilities can be enabled to capture raw
frames.

As for your specific situation - is you LWF at an altitude higher or lower
than the Native WiFi LWF? I hope ‘lower’ (closer to the NIC).

Good Luck,
Dave Cattley

3

If you read:
http://msdn.microsoft.com/en-us/library/aa503359.aspx

Microsoft says that the 802.11 client is obligated to pass up all frames, even the bad ones, under conditions specified on that page. It makes it seem like it should be real easy. Yes, I’m bound below nativewifi… I’ve even played around with killing the nativewifi service with no luck.

Yeah, there are totally free ones that do the same thing, but there aren’t any open source windows packet sniffers that do this yet. WinPCAP still does 802.3 emulation as far as I can tell, netmon is closed source… Seemed like a good niche to fill for a new open source project.

4

Oh, believe me … I have read it!

You are not asking to get frames that failed to decrypt. You are asking for
frames that failed CRC. That is quite a different thing and all I am saying
is that a chipset is not obligated to pass a frame that otherwise looks
entirely like garbage up. It is one thing to pass a valid but
un-decryptable frame up. The frame itself will have a valid CRC and thus is
‘sensible’. The fact that the payload cannot be decrypted is really no
concern for the low level PHY and framer/deframer.

My point was simply to be sure that it is possible - I am not saying it is
impossible.

I will simply quote the very page you are telling me to read:


If the 802.11 station is able to receive MPDU packets with FCS errors, the
miniport driver must set the DOT11_RECV_FLAG_RAW_PACKET_FCS_FAILURE in the
uReceiveFlags member.

Note that the statement starts with “If …”

Not all stations are able and being unable is not a disqualifying condition.

Good Luck,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, December 14, 2009 12:20 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Capturing raw native 802.11 packets from filter driver

If you read:
http://msdn.microsoft.com/en-us/library/aa503359.aspx

Microsoft says that the 802.11 client is obligated to pass up all frames,
even the bad ones, under conditions specified on that page. It makes it seem
like it should be real easy. Yes, I’m bound below nativewifi… I’ve even
played around with killing the nativewifi service with no luck.

Yeah, there are totally free ones that do the same thing, but there aren’t
any open source windows packet sniffers that do this yet. WinPCAP still does
802.3 emulation as far as I can tell, netmon is closed source… Seemed
like a good niche to fill for a new open source project.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

wrote in message news:xxxxx@ntdev…
…
> Perhaps I am going about this the wrong way (and please let me know if
> there are better alternatives!) I’m trying to do this all through the
> Windows SDK or Windows DDK for Vista and higher.

IMHO you will be much better off with Linux and opensource drivers.
But there is no way to reach the actual bit patterns of the phy layer, as
all major wi-fi vendors release the firmware only in binary form.

–pa

6

I probably should have clarified better. The filter sets to indicate raw data MPDUs are being returned successfully–the card shouldn’t do that unless it has the capability to indicate raw MPDU packets, but that is a good thought to try another device with a different chipset. I’m sure I have an Atheros something or another laying around somewhere–I’ll dig that up and post if the results are different.

Yes, I’ve actually been using a linux sniffer to do my debugging. This Windows thing is just a new little side project of mine now. Even if it ends up being chipset dependent, it’d be great to come up with an open source solution for Windows that has the same sniffing capabilities to those in linux, without having to resort to one of those commercial tools.

Also, I noticed that all the MPDU packets seem to be passed up assembled already–according to MSDN it shouldn’t be doing that in monitor mode unless it’s also indicating all the MPDU’s individually. It makes me think I *must* be doing something wrong, or there is just something funky going on!