Alexander Pevzner wrote:
Hi Alexander -
This approach requires not so minor change in WiFi driver:
- normally, in the infrastructure network, multicasts are transmitted
via Access Point. Client transmit its multicast datagram as an unicast,
directed to AP, and then AP retransmits is as a multicast to everybody
Yes, it seems to be the case.
- To change this normal behavior, driver changes are required. I'm not
even sure that all existing 802.11 chipsets can in principle support
this mode. The decision how to transmit broadcast packet may be
implemented in the MAC firmware, not in the driver.
Yes, I am finding there is variation in how much control is exposed to
the PC. For example on the zd1211 there is a bit send with the TX
request to define if ACKs are to be expected. For ipw3945 there is a
big struct sent to the device before the payload, containing all kinds
of detailed information, yet the hardware is more picky about which MAC
addresses it will accept to send packets for.
- 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.
- 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.
I am already sending Penumbra packets at 54Mbps on both zd1211rw and
ipw3945 without multicast.
- 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.
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
- 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.
-Andy
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
