This reminds me of an old practical joke gone wrong.
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.
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.
Welcome to unlicensed frequencies. You can also buy any number of legitimate narrowband continuous transmitters (e.g. an analog video transmitter) and effectively destroy one of the available channels.
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.
> 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.
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.
> [T]he impact of adding a second evil ESP8266 is much greater than the first one. One possible cause is the exponentially increased probability of having the channel jammed due to simultaneous transmissions on the same channel.
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
Not really, they are using the 2.4GHZ ISM band. It may be legal (INAL) as long as you are not interfering with any licensed use of the band and are not violating FCC Part 15 Rules. (http://www.afar.net/tutorials/fcc-rules)
It's more of a grey area than that, FCC Part 15 devices must accept all forms of interference. There is no real recourse. Provided that the device is transmitting within 2.4 or 5.8 GHz band channel size limits and EIRP, it's not illegal to crap up the half duplex medium of Part 15 wifi bands.
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:
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))
Where did you come up with layer 1 v. layer two mattering at all? If you look at the FCC consent decree[1], e.g., §II "Background", ℙ2—"No person shall willfully or
maliciously interfere with or cause interference…". There isn't anything about the particular method used mattering.
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").
> 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").
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.
In the HAM bands FCC still has some provisions for intent. I.E. if you don't follow a local coordinating band plan the FCC can fine you. Even though they don't have an explicit law for band plans.
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).
If you use the device in this story to jam Wi-Fi you're a felon and the FCC will seize your equipment, bury you in fines and/or put you in prison. The "accepting interference" requirement does not immunize anyone from prosecution for jamming. Unlicensed != unregulated, and the FCC is perfectly capable of distinguishing between legitimate Part 15 operation and jamming.
What the hotel used was not a RF-shitting noise source/jammer of any sort, it was other properly certified/permitted Part 15 legal 802.11 wifi equipment equipped with "rogue access point containment" software features that perform deauth attacks in the 802.11 air protocol. Example:
it's not illegal to crap up the half duplex medium of Part 15 wifi bands
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.
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.