Do Evil with ESP8266: Slow Down the WiFi
yoursunny.com
yoursunny.com
Back around 1990 we had a college lab full of PC XT clones on an early Novell network on 'thinnet' (shared coax cable instead of star topology twisted pair to a switch). Some of the games floating around relied on the original PC's 4.77 MHz clock and ran too quickly on our 'turbo' 10 MHz machines so there was a slowdown utility that generated regular interrupts looping over a NOP to allow the games to run.
I thought it would be a great prank to put this slowdown utility on the boot floppies and AUTOEXEC.BAT of half the machines in the room and watch my classmates scratch their heads over some slow computers. Instead, it messed with the CSMA/CD (collision handling) on the network cards and essentially brought that portion of the network down. I showed up to a very angry network admin who had spent hours troubleshooting network cards and cable before finally finding one of the affected boot floppies. Fortunately (for me) he blamed another group and I escaped the full brunt of his wrath.
Shared medium, wired or wireless, always offers some extra fun.
pranks that waste somebody's time, not ok.
I never want my time wasted, and I know that I can be fooled, there is no real challenge to wasting my time.
but my personal peeve is actually a little different: regardless of whether I'm part of a unique group or it works this way for everybody, the different parts of my brain remember the prank differently and at different rates of speed, so even after the prank is revealed/resolved, the part of my brain that flinches keeps remembering the lie, not the truth. Like, my gf recently April fools' pranked me that my favorite restaurant was going to close soon. Now, every time I pass the place or think of it it, I immediately think "and I've got to go there soon before it closes" even though immediately after that I think "oh, no, that was a prank" I still have the surge of emotion. In terms of the prank, I get it, my reaction was funny. But in terms of time wasted, it's worse because it's Attention Deficit time, and I know I continue to find it sooo irritating well beyond the momentary pleasure she got out of it.
I've got a cheap Chinese 2.4GHz analog video transmitter in a box somewhere which is _way_ overpowered (600mW from memory, instead of the legal max of 25mW) it completely knocks out all my 2.4GHz wifi when I switch it on (and I strongly suspect all my neighbour's wifi as well). I've got much a less overpowered 5GHz which my 5GHz wifi doesn't seem to care about.
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.)
> 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!
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.
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.
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.
The reason is that TCP connections increase their speed linearly (aka the the first derivative of packet transfer is increasing) until they experience packet loss. If many packets are lost, or if the network is congested, the speed will not increase
Say you live in a wood framed apartment building and your neighbor to the left has a 2.4 GHz wifi AP running a 20 MHz channel on channel 1, your neighbor to the right has another similarly configured AP on channel 6, and your neighbor directly below you has an AP on channel 11. The other neighbors diagonally to you are on channels 3 and 7. The 2.4 GHz spectrum in your apartment is totally shit because you're seeing everyone else's AP at -68 or thereabouts, because it's a wood framed building and they're so close to you, the spectrum is totally crapped up and noisy but it's not "jamming". This script has the same effect on real world data transfer speeds as the effect in a totally normal major urban area "2.4 GHz is shit here because I live in a 65 unit building and every single suite has their own wifi AP".
What this small script is doing has basically the same effect on a particular section of 20/40 MHz wide radio spectrum as if you were to install any ordinary $70 wifi AP in WPA2-PSK mode, put it on your choice of channel, and leave a pair of laptops associated to it running bidirectional iperf tests on a 1-minute cron job continually between each other. Totally legit. It's just making the channel in question "noisy" RF-wise, because wifi radios are a "listen before transmit" (CSMA) half duplex medium.
Where it gets into a grey area is stuff like this:
http://www.cnn.com/2014/10/03/travel/marriott-fcc-wi-fi-fine...
http://money.cnn.com/2015/01/27/technology/fcc-wifi-hotel/
operating a noisy 2.4 or 5.8 GHz shitty thing on your own AP is totally legal. Connecting to other peoples' networks or gear at a layer 2 ethernet level and issuing deauth frames is not, and the FCC can come down on you for it. The difference is that the first (being noisy) is at basically OSI layer 1, you're shitting on the radio spectrum the same way as if you had a non-ethernet-speaking RF noisy baby monitor, but not talking to anybody else's devices by their MAC address, the second is actually an active form of layer 2 ethernet fabric attack (that happens to be conducted via 802.11abgn(ac))
Presumably, if you set up a pile of 2.4GHz baby monitors because you wanted to take out your neighbor's WiFi, that'd be illegal. So too would the device in the article. (IANAL, and I certainly haven't tried to read all the code & regulations).
That really looks to be essentially "don't be a jerk", codified. If you want to use the spectrum to communicate [within all the limits set by the rules], go ahead. When a bunch of people all want to, it may not work as well. But if you want to use the spectrum to stop others from communicating—stop being a jerk. (You may, of course, substitute stronger words for "jerk").
[1]: https://apps.fcc.gov/edocs_public/attachmatch/DA-14-1444A1.p...
I think a big part of it is the corporate entity involved and money involved - they were jamming peoples' HSPA+/LTE-to-wifi hotspots because they wanted to sell $600/day internet service for trade shows and conferences...
It's not that the FCC delineated between layer 1 and 2 in their decree, it's the difference that they intentionally messed with wifi at the wifi-protocol level by issuing deauths, not by being noisy... for example if the hotel had a hundred wifi security cameras, baby monitors and other random part 15 devices in use in their facility, effectively preventing anyone from using wifi because the spectrum was too full of shit, that wouldn't be "jamming", even though it would have the same effect.
I wonder if there's a similar law for the unlicensed bands.
Federal law prohibits the operation, marketing, or sale of any type
of jamming equipment, including devices that interfere with cellular
and Personal Communication Services (PCS), police radar, Global
Positioning Systems (GPS), and wireless networking services (Wi-Fi).
https://www.google.com/search?client=ubuntu&channel=fs&q=cis...
It certainly can be. "Willful or malicious interference," 47 USC 333. If you're going to split hairs, at least know what the fuck you're talking about.
Emitting noise for the purpose of crapping up the wifi band is still malicious. If 2000 moms bring baby monitors to a conference is one thing, but entirely different than thinking you've found a sneaky legal hack by stuffing 2000 baby monitors into your suitcase.
What is willful? e.g. in the case of 2000 moms at a conference or a hotel/building with excessive wifi/etc. Would some of those fall under "willful interference"? Especially as willful and malicious is combined exclusively ("or") in writing.
They aren't making any comments about the legality of the source of the interference.
Still not cool though...
Commonly used wifi doesn't frequency hop in the conventional sense.