3 ms·
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
by blobbers 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.
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.