Kismet Wireless

Kismet Forums

 

Posted by:hernan
Subject:Kismet detection of clients of an AP
Date:14:17:41 04/09/2007

Hi!,

I realized about the forums after sending you an email and didn't expect you were going to answer me so quickly! :) so I went ahead and post my question here again, I apologize if I generated too much noise :). Thanks a lot for answering so quickly!.

You have much more experience than I do when it comes to analyzing network 802.11 traffic, I guess you have found that using just the SRC addr is better than using both the SRC addr and DST addr, is it the case? I'm trying to determine why; if you can share your experience that would be great, I want to come up with the best alternative (using the SRC alone or using both src and dst), the idea is to obtain as much data as possible from 802.11 traffic:

1-Couldn't someone flood your client table injecting packets with arbitrary SRC addresses as well? If someone wants to flood the client table, I guess it would be the same for the 'attacker' to craft packets either with arbitrary SRC addrs or with arbitrary DST addrs. I think the DoS attack can be accomplished either way. I don't know if not tracking DST addrs is the solution to prevent flooding of the client table, OR the best solution :).

2-When you talk about 'spurious' data, is it data that was generated intentionally in a spurious way? :) or is it regular 802.11 traffic? One thing I noticed, for example, is that when clients send packets to the AP itself, dst == bssid, so you end up like I did with a graph where bssids connect to themselves :), but specific cases like that can be taken into account.

3-Given all the 'hidden node' thing.., I think it is not unusual to be able to see only one side of the conversation, it is possible you'll never see the dst of a pkt actually sending data as the src. right?, Ok, you don't need the explanation but is more for me than for you :): I don't know, let's say you are close to a client, the client sends data to an AP, you are able to capture traffic from the client, but the signal of the AP only reaches the client and not you, because you are further away from the AP, but you do get to see packets sent by the client because you are closer to the client than to the AP. I guess one thing you can say, is that you are detecting 'active' clients only, that is clients that generate traffic and you can observe their traffic, because you are detecting clients that are 'around' you. That is a valid idea, but I think that
in that case it would be better to catalog clients as 'clients that are around', 'clients that are not around', perhaps? :) or 'reachable client' and 'unreachable client' :)


This is interesting, at least for me :), sorry :).

Thanks!,
Hernan




> > Hi,
> >
> > one question,
> > I am developing a wifi-related tool and I noticed Kismet when identifying clients of an AP records as client of an AP only the SRC addr of a packet (e.g.: of a 802.11 data packet), and NOT also the DST addr of a packet. Why is that?
> >
> > to reduce noise of pkts directed to non-existent dst addr? why? does it matter?
> > because it hopes to see responses from dst but this time as the src of a packet? why? I think it is not uncommon to see only one side of the conversation.
> >
> > or, Am I completely misunderstanding the meaning of the DST addr? :)
>
> (as I said over email to the same message, but since others might care... Generally, you only need to either post here or send me an email):
>
> Technically true, however if there is another client using that mac
> address we'll see it at some point when it responds. Tracking dst
> addresses would show up a lot of spurious data as well as open us up to
> a nice DoS from someone flooding the client table by spoofing
> destination addresses. Generally I've never seen a problem using a more
> affirmative detection of requiring them to actually transmit before
> cataloging them as a client.
>
> -m


Reply to this message