[kismac] Re: What results in <no-ssid> in scan output?
- From: "Kevin Bringard" <comandercool@xxxxxxxxx>
- To: kismac@xxxxxxxxxxxxx
- Date: Wed, 9 Aug 2006 16:56:01 -0700
Yah... essentially that is what hiding your SSID does. It causes it
to be stripped from the beacon frames, hence the different data
structure. Any data packets sent *to* the AP by a valid client will
contain the name of the network. The reason you'd want to de-auth
flood is to pick up a decrypted packed that contains the SSID, which
you can get from the association request frame.
Another thing to think about, is that sometimes clients alreay
connected to the network will send a probe request, causing the AP to
reply with the SSID. In this case just listening for long enough
could get you the name... but if you can successtfully de-auth a
client, they'll usually try to reconnect immediately, which will give
you the name.
Anyway, hope this makes sense, I have a tendency to ramble :-p
-- Kevin
On 8/9/06, Paul Jacoby <pej@xxxxxxxx> wrote:
> I don't think you need to use a de-auth flood to determine this...but
> I could be wrong. Sniff the traffic going to this wap's channel and
> tell kismac to save it to a pcap file. Open the pcap in ethereal and
> see if you can see the ssid there. Don't remember the ethereal filter
> exactly right now...just got back from Defcon and I'm a little
> fuzzy ;-)
Defcon fuzz....ah the memories ;-)
The interesting thing about the pcap is that the structure of the
Beacon packets is different, such that there is NO ssid value or data
structure at all. I'm guessing the Malcolm is assuming there will
always be an SSID structure, maybe by a specific byte offset, and is
picking up junk off the tail end of the buffer when one is not
actually there.
I'll have to consider if a deauth flood from the Walmart parking lot
is a good idea or not...might need to go inside and buy some cheap
sunglasses first ;-)
Other related posts:
