Comment by daveloyall | Hacker News Reader

Comment by daveloyall | Hacker News Reader

I completely believe the author's test results.

However...

> One class of network packets is broadcast packet [...] a major difference from regular unicast packets [...] the access point is no longer able to choose a speed according to the channel quality between the access point and the single recipient

What's that last part? Why not?

WiFi standards mandate the access point to transmit the broadcast packet at the lowest speed

Oh, I see. Wait, no I don't. The author implies that 802.11 is IP aware. Dubious to me, but ok, I'll google that... Aaaand, sorry, none of the titles of the top hits convinced me.

I think that 802.11 is analogous to ethernet. That is, it's link-level and TCP just happens to work over it. I don't think the AP changes transmit speed to all connected clients just because somebody sends UDP packets to 255.255.255.255... Especially since not every client has to have an IP address to be connected to the wifi!

If the author had some C code which contained 'FF:FF:FF:FF:FF:FF', I would have accepted the whole thing without a second thought. :)

> Since each channel refers to a single wireless frequency, this would affect all WiFi networks on the same channel, even if the stations are connected to other access points.

Probably the author meant "have some performance impact" instead of "affect" there. Affect makes it sound like the same broadcast-related phenomenon (still dubious to me) is occurring between other APs.

In short, I believe that the author has caused the little device to slow down "the wifi", but I'm gonna have to see some packet dumps to believe the explanation of 'why'.

(Probably that tight loop generates X packets per second, enough to saturate the channel, and the slowdown is just due to an ordinary flood.)

> I think that 802.11 is analogous to ethernet. That is, it's link-level and TCP just happens to work over it. I don't think the AP changes transmit speed to all connected clients just because somebody sends UDP packets to 255.255.255.255... Especially since not every client has to have an IP address to be connected to the wifi!

> If the author had some C code which contained 'FF:FF:FF:FF:FF:FF', I would have accepted the whole thing without a second thought. :)

Guess what any IP stack does (with broadcast enabled), when you send UDP packets to 255.255.255.255 (or all subnet address bits set to 1)?

It sets destination MAC address to FF:FF:FF:FF:FF:FF of course!

These packets won't be retransmitted or decoded by anyone for any purpose. They're on the incorrect BSSID. Think of a BSSID like a VLAN on an ethernet segment.

All this script will do is broadcast packets that jam the medium forcing folks to back off when they see the medium busy.

There are nastier ways to be nasty.

If you configure yourself to listen promiscuously, keep a list of all BSSIDs, you can send broadcast deauths with source MAC and BSSID on each.

If you see a data frame, you spoof the AP and send a deauth to the client, and spoof the client and send a deauth + disassoc to the AP.

Windows laptops are quite persistent - they'll reassociate and try to continue within about 30-50ms.

Apple OSX clients are pretty easy to kill. They'll get the !))) wifi sign if you're deauthing them every 100ms or so, and then they'll give up.

Depending on how fast your channel change code is, you can keep track of multiple channels and effectively perform 'shoot down' across multiple spectrum channels.

Some people might call this evil, but if an enterprise/retail deployment has someone deploying 'fake guest' wifi to steal user credentials or credit cards it is pretty important to shoot down the rogue access point.

> These packets won't be retransmitted or decoded by anyone for any purpose. They're on the incorrect BSSID. Think of a BSSID like a VLAN on an ethernet segment.

Sure. I was just saying sending packets to IP broadcast will cause IP stack to set ethernet frame dest MAC to broadcast address.

The end result of that broadcast spamming is simple shared medium flood.

Google for "802.11 basic rate"

The basic rate is the rate used when one station (any device with a TX/RX) broadcasts a frame (we call them frames at layer 1 (PHY) and 2 (MAC)). The transmit rate is the rate used when a station transmits a frame to another specific station. BTW, this has nothing to do with IP, in fact, this is true even if IP is not in use. The low bit of the 1st octet of a MAC address determines whether a frame is multicast or not (technically the basic rate is used for multicast frames, not just broadcast ones).

Why is the "transmit" rate so much higher than the "basic" rate? It all has to do with negotiation. If it turns out that when you decide to send a frame, someone else was using the medium, you'll only know this if the other side has sent you an ACK. This means you can do your backoff and try again after a short interval (usually measured in microseconds). It becomes infeasible to expect an ACK from all of the recipients for a broadcast frame however. So instead we simply send broadcasts at a much lower rate.

Also note that the transmit rate is constantly changing, based on how well ACKs have been received. This is adaptive rate control.

Another thing to note is that when you are using infrastructure mode, stations (like your phone, PC, etc) send multicast frames to the AP and then the AP turns around and blasts it out broadcast style. So in this case, the frame is initially sent quickly as unicast to the AP via the transmit rate, but then the AP sends the same frame out broadcast at the basic rate.

Just by having stations continually send multicast frames you can lower the channel to the basic rate for everyone on the same channel. Nothing really sneaky here either. You don't even need to be on the same BSSID since this is a PHY issue.

Thanks to vardump and flaub I learned that the author of the article was actually correct or approximately correct. Nice.

Reply on news.ycombinator.com