[p2p-hackers] Re: Penumbra Wifi Network

Alexander Pevzner pzz at pzz.msk.ru
Wed Jan 17 20:58:23 EST 2007

Andy Green wrote:

>>   - By default, if encryption is enabled, non-encrypted packets will be
>> dropped on reception. Changing this behavior requires driver patch, and,
>> even worse, it opens station to the unwanted unencrypted traffic.
> Yes there are driver changes needed to get Penumbra working.  However
> after selecting promiscuous rx in the driver, it is simple enough to
> filter by host MAC and the Penumbra "magic MAC" in the rx code, to
> remove this "even worse" part: that's basically what the hardware was
> doing before.

Windows drivers normally don't support sniffer mode. I'm more concerned
about Windows, because:
  1) If it will not work on Windows, people will not use it
  2) There is no big problem to modify Linux drivers

>>   - Usually multicasts are transmitted at very low transmit rate (so
>> everybody will have chance to receive them). I'm not sure that for every
>> chipset this is possible to change it in the driver.
> Every tx action is a "broadcast".  A transmission fallback plan with the
> same external effect for remote Penumbra stations is to simply transmit
> the packet to the AP as normal, but with the Penumbra "magic MAC" in one
> of the iee802.11 MAC addresses.  You lose a small piece of anonymity if
> forced into that, since that packet has your AP MAC in it, but it will
> work without using an explicit "multicast".  And of course the MAC
> addresses don't propogate.

Technically, if station transmits datagrams, looking that multicasts
sent by AP (FROM_DS=1, TO_DS=0, ADDR1=multicast, ADDR2=BSSID,
ADDR3=sender's MAC), other stations can receive them. This is a proved
fact. The only problem is the encryption.

The only problem, you can't send datagrams to different BSSID.

>>   - All participating stations must disable 802.11 powersaving. 802.11
>> power saving depends on multicast queuing implemented by Access Point.
> Not so if the packets do not claim to be multicast.  Every transmission
> is a "broadcast", it just requires that the wifi card not retry.

In PS mode, stations depend on frame queuing at AP. You must disable PS,
if you want to receive unsolicited frames.

>> The requirement to patch the driver may make this technology very
>> difficult to implement on MS Windows, where driver sources are generally
>> hard to obtain.
>> If there is interest, I can propose changes to the approach, which will
>> allow Windows stations with unpatched drivers at least to receive
>> traffic from such a network (transmission and feedback will not be
>> possible without driver modifications).
> Yes please do describe this method.  My only plans for Windows are

I'm sorry. After some thinking, I understood that my initial proposal
will not work between networks with different BSSID :-(

>  - some vague "put it in the 80211 stack more"
>  - some magic hazy NDIS filter driver magic between the driver and the
> stack
> Yet since there are so many Windows boxes it is clear that support there
> will make or break the whole deal.

On Windows XP there is no such a thing as "Windows 802.11 stack".
Actually, most of work is done by driver. Windows only sets some network
parameters, like SSID, and performs encryption key management. All other
things look like on Ethernet. In particular, Ethernet, not 802.11 frames
are exchanged between OS and driver.

With Native 802.11 more decisions are taken outside of the driver, but
Native 802.11 is not widely used outside of WinCE world.

More information about the p2p-hackers mailing list