3 ms·
> 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 al
by vardump 10y ago
> 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!
- blobbers 10y agoThese 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.
- vardump 10y ago> 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.