2015-03-04 23:02:38

by Marco

[permalink] [raw]
Subject: carl1970: monitor mode only displaying beacons/probs from APs?

carl1970: monitor mode only displaying beacons/probs from APs

Hello,

Quite a while back after doing an upgrade to the latest (back then)
compat-wireless, I noticed that I was only seeing beacon,prob requests, and
the occasional data packet when in monitor mode; which at the time I wrote
off. After switching to backports-3.18.1-1 recently, I still see the same
behavior(on x86 and arm). I'm sure I'm missing something, but I couldn't
find any references to this behavior in my search. I also tried "iw wlanX
set monitor control otherbss" to no avail. Switching to a different chipset
using ath9k-htc showed expected traffic.

Can anyone point me in the right direction?

Regards,

Marco Fonseca


2015-03-06 05:26:59

by Marco

[permalink] [raw]
Subject: Re: carl1970: monitor mode only displaying beacons/probs from APs?

On 03/05/15 06:10, Christian Lamparter wrote:
> Hello,
>
> On Wednesday, March 04, 2015 11:02:25 PM [email protected] wrote:
>> Quite a while back after doing an upgrade to the latest (back then)
>> compat-wireless, I noticed that I was only seeing beacon,prob requests, and
>> the occasional data packet when in monitor mode; which at the time I wrote
>> off. After switching to backports-3.18.1-1 recently, I still see the same
>> behavior(on x86 and arm). I'm sure I'm missing something, but I couldn't
>> find any references to this behavior in my search. I also tried "iw wlanX
>> set monitor control otherbss" to no avail. Switching to a different chipset
>> using ath9k-htc showed expected traffic.
>>
>> Can anyone point me in the right direction?
> maybe. Could it be that you are looking for 802.11n(MCS) data frames?

I'm trying to see any and all frames (ctrl/mgmt/data). I'm currently
doing my testing on 2.4ghz band, channel 11. Playing with HT didn't
seem to make a difference.


> Because by default, carl9170's monitor mode only catches the legacy
> 802.11a/b/g frames. If this is the case, then try setting the right
> channel mode (HT20/HT40+/HT40-) when selecting the channel. i.e.:
>
> # iw dev wlanX set channel Y HT20
> # iw dev wlanX set channel Y HT40+
>
> I hope this helps. Otherwise, you could try:
>
> # iw dev wlanX set monitor [...] fcsfail
>
> and see if you are picking up frames this way. This should work, but you
> will be picking up mostly damaged stuff, so some extra frame processing
> will be needed to filter out the noise.
>
> Regards,
> Christian
>

I've previously (and once again for good measure) tried fcsfail to no
avail as well.

I'm surprised no one else is seeing this/reported this, I've tried on
3 separate linux boxes now with no luck.

Regards,
Marco

2015-03-06 09:34:47

by Wim Torfs

[permalink] [raw]
Subject: Re: carl1970: monitor mode only displaying beacons/probs from APs?

Hi,

On 03/06/2015 06:20 AM, Marco wrote:
> On 03/05/15 06:10, Christian Lamparter wrote:
>> Hello,
>>
>> On Wednesday, March 04, 2015 11:02:25 PM [email protected] wrote:
>>> Quite a while back after doing an upgrade to the latest (back then)
>>> compat-wireless, I noticed that I was only seeing beacon,prob requests, and
>>> the occasional data packet when in monitor mode; which at the time I wrote
>>> off. After switching to backports-3.18.1-1 recently, I still see the same
>>> behavior(on x86 and arm). I'm sure I'm missing something, but I couldn't
>>> find any references to this behavior in my search. I also tried "iw wlanX
>>> set monitor control otherbss" to no avail. Switching to a different chipset
>>> using ath9k-htc showed expected traffic.
>>>
>>> Can anyone point me in the right direction?
>> maybe. Could it be that you are looking for 802.11n(MCS) data frames?
>
> I'm trying to see any and all frames (ctrl/mgmt/data). I'm currently
> doing my testing on 2.4ghz band, channel 11. Playing with HT didn't
> seem to make a difference.
>
>
>> Because by default, carl9170's monitor mode only catches the legacy
>> 802.11a/b/g frames. If this is the case, then try setting the right
>> channel mode (HT20/HT40+/HT40-) when selecting the channel. i.e.:
>>
>> # iw dev wlanX set channel Y HT20
>> # iw dev wlanX set channel Y HT40+
>>
>> I hope this helps. Otherwise, you could try:
>>
>> # iw dev wlanX set monitor [...] fcsfail
>>
>> and see if you are picking up frames this way. This should work, but you
>> will be picking up mostly damaged stuff, so some extra frame processing
>> will be needed to filter out the noise.
>>
>> Regards,
>> Christian
>>
>
> I've previously (and once again for good measure) tried fcsfail to no
> avail as well.
>
> I'm surprised no one else is seeing this/reported this, I've tried on
> 3 separate linux boxes now with no luck.
>

Perhaps a silly question, and I'm sure you already covered this, but I
need to ask, just to be sure. Did you enable promiscuous mode to capture
the data packets?

Could you elaborate on the employed method for capturing the data, it is
difficult to make any suggestions without having knowledge about the
used procedure.

Best Regards,
Wim.




> Regards,
> Marco
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2015-03-05 11:11:10

by Christian Lamparter

[permalink] [raw]
Subject: Re: carl1970: monitor mode only displaying beacons/probs from APs?

Hello,

On Wednesday, March 04, 2015 11:02:25 PM [email protected] wrote:
> Quite a while back after doing an upgrade to the latest (back then)
> compat-wireless, I noticed that I was only seeing beacon,prob requests, and
> the occasional data packet when in monitor mode; which at the time I wrote
> off. After switching to backports-3.18.1-1 recently, I still see the same
> behavior(on x86 and arm). I'm sure I'm missing something, but I couldn't
> find any references to this behavior in my search. I also tried "iw wlanX
> set monitor control otherbss" to no avail. Switching to a different chipset
> using ath9k-htc showed expected traffic.
>
> Can anyone point me in the right direction?
maybe. Could it be that you are looking for 802.11n(MCS) data frames?
Because by default, carl9170's monitor mode only catches the legacy
802.11a/b/g frames. If this is the case, then try setting the right
channel mode (HT20/HT40+/HT40-) when selecting the channel. i.e.:

# iw dev wlanX set channel Y HT20
# iw dev wlanX set channel Y HT40+

I hope this helps. Otherwise, you could try:

# iw dev wlanX set monitor [...] fcsfail

and see if you are picking up frames this way. This should work, but you
will be picking up mostly damaged stuff, so some extra frame processing
will be needed to filter out the noise.

Regards,
Christian

2015-03-06 16:13:00

by Marco

[permalink] [raw]
Subject: Re: carl1970: monitor mode only displaying beacons/probs from APs?

On Fri, Mar 06, 2015 at 10:34:42AM +0100, wim torfs wrote:
> Hi,
>
> Perhaps a silly question, and I'm sure you already covered this, but I need
> to ask, just to be sure. Did you enable promiscuous mode to capture the data
> packets?
>
> Could you elaborate on the employed method for capturing the data, it is
> difficult to make any suggestions without having knowledge about the used
> procedure.
>
> Best Regards,
> Wim.
>
>
Hello Wim,

Honestly, I've never seen promiscuous mode get me anything when doing
wireless sniffing; probably because I'm not associated with an AP.
That being said, I have tried that without any noticeable difference.

I use both wireshark and tcpdump for my testing. I'm just looking for
wireless packets that one normally sees when doing wireless sniffing
(there is a lot of sta's / AP's around me) acks, CTS/RTS, various
management frames, etc. The missing traffic is pretty obvious when
comparing to another working wifi stick (in my case 9khtc).

I guess if this is not an obvious problem, I can go bisect until I
find where the problem was introduced. This was working fine in the
past.


Example: carl9170
It seem like all the traffic I see is from AP's, no STA. The three
types are all I ever see (1 data frame, and two mgmt frames, no
ctrl).

... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5...
... -81dB signal antenna 5 Beacon (...) [11.0* 11.0* 6....
... -57dB signal antenna 5 Beacon (...) [1.0* 2.0* 5.5* 11.0* ...
... -76dB signal antenna 5 Beacon (...) [1.0* 2.0* 5...
... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5...
... -82dB signal antenna 5 Probe Request () [1.0* 2.0* 5.5* 11.0...
... -57dB signal antenna 5 Beacon (...) [1.0* 2.0* 5.5* 11.0* ...
... -76dB signal antenna 5 Beacon (...) [1.0* 2.0* 5...
... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5...
... -83dB signal antenna 5 Beacon (...) [11.0* 11.0* 6....
... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5....
... -57dB signal antenna 5 Beacon (...) [1.0* 2.0* 5.5* 11.0* ...
... -76dB signal antenna 5 Beacon (...) [1.0* 2.0* 5...
... -83dB signal antenna 5 Beacon (...) [11.0* 11.0* 6....
... -74dB signal antenna 5 Data IV: c0 Pad 20 KeyID 1
... -74dB signal antenna 5 Beacon (...) [1.0* 2.0* 5.5* 11.0* ...
... -77dB signal antenna 5 Beacon (...) [1.0* 2.0* 5...
... -83dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5...
... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5....


Example: 9k-htc
I see plenty of other frames (lots more in a larger sample)

... -75dB signal antenna 0 Unknown Ctrl Subtype
... -74dB signal antenna 0 Beacon (...) [1.0* 2.0* 5
... -74dB signal antenna 0 Beacon (...) [11.0* 11.
... -74dB signal antenna 0 Beacon (...) [1.0* 2.0*
... -76dB signal antenna 0 Beacon (...) [1.0* 2.0* 5.5*
... -76dB signal antenna 0 Beacon (...) [1.0* 2.0* 2
... -77dB signal antenna 0 Beacon (...) [1.0*
... -72dB signal antenna 0 Beacon (...) [1.0* 2.
... -73dB signal antenna 0 [|802.11]
... -73dB signal antenna 0 Unknown Ctrl Subtype
... -73dB signal antenna 0 Power Save-Poll AID
... -72dB signal antenna 0 Beacon (...) [1.0* 2.0* 5
... -72dB signal antenna 0 Beacon (...) [1.0* 2.
... -73dB signal antenna 0 Beacon (...) [1.0* 2.0*
... -75dB signal antenna 0 Beacon (...) ESS[|802.11]
... -76dB signal antenna 0 Beacon (...) [1.0* 2.0* 2
... -77dB signal antenna 0 CF Ack/Poll+QoS
... -78dB signal antenna 0 Data IV:363bbb Pad 20 KeyID 2
... -78dB signal antenna 0 Beacon (...) [1.0*
... -73dB signal antenna 0 Beacon (...) [1.0* 2.
... -74dB signal antenna 0 Beacon (...) [1.0* 2.0* 2.
... -75dB signal antenna 0 Unknown Ctrl Subtype
... -75dB signal antenna 0 Unknown Ctrl Subtype


Regards,
Marco

2015-03-06 18:45:58

by Wim Torfs

[permalink] [raw]
Subject: Re: carl1970: monitor mode only displaying beacons/probs from APs?



On 03/06/2015 05:12 PM, marco wrote:
> On Fri, Mar 06, 2015 at 10:34:42AM +0100, wim torfs wrote:
>> Hi,
>>
>> Perhaps a silly question, and I'm sure you already covered this, but I need
>> to ask, just to be sure. Did you enable promiscuous mode to capture the data
>> packets?
>>
>> Could you elaborate on the employed method for capturing the data, it is
>> difficult to make any suggestions without having knowledge about the used
>> procedure.
>>
>> Best Regards,
>> Wim.
>>
>>
> Hello Wim,
>
> Honestly, I've never seen promiscuous mode get me anything when doing
> wireless sniffing; probably because I'm not associated with an AP.
> That being said, I have tried that without any noticeable difference.
>

This is exactly the reason why you should use promiscuous mode. When
capturing data packets on a monitor interface, while not being in
promiscuous mode, then you will only see packets destined to you or sent
by you. The hardware/driver filters packets not destined for you. That
being said, tcpdump operates default in promiscuous mode. You can notice
this if you check your kernel messages (dmesg), then you will notice a
message something like: placing wireless interface wlan0 in promiscuous
mode.

Unfortunately, I have no experience with carl9170, however, I should
point out that all packets (perhaps except the data packet) are
broadcast packets. So perhaps it would be a good idea double checking
the promiscuous mode setting. Perhaps the carl9170 does not support
this, I don't know, just guessing here.


> I use both wireshark and tcpdump for my testing. I'm just looking for
> wireless packets that one normally sees when doing wireless sniffing
> (there is a lot of sta's / AP's around me) acks, CTS/RTS, various
> management frames, etc. The missing traffic is pretty obvious when
> comparing to another working wifi stick (in my case 9khtc).
>
> I guess if this is not an obvious problem, I can go bisect until I
> find where the problem was introduced. This was working fine in the
> past.
>
>
> Example: carl9170
> It seem like all the traffic I see is from AP's, no STA. The three
> types are all I ever see (1 data frame, and two mgmt frames, no
> ctrl).
>
> ... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5...
> ... -81dB signal antenna 5 Beacon (...) [11.0* 11.0* 6....
> ... -57dB signal antenna 5 Beacon (...) [1.0* 2.0* 5.5* 11.0* ...
> ... -76dB signal antenna 5 Beacon (...) [1.0* 2.0* 5...
> ... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5...
> ... -82dB signal antenna 5 Probe Request () [1.0* 2.0* 5.5* 11.0...
> ... -57dB signal antenna 5 Beacon (...) [1.0* 2.0* 5.5* 11.0* ...
> ... -76dB signal antenna 5 Beacon (...) [1.0* 2.0* 5...
> ... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5...
> ... -83dB signal antenna 5 Beacon (...) [11.0* 11.0* 6....
> ... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5....
> ... -57dB signal antenna 5 Beacon (...) [1.0* 2.0* 5.5* 11.0* ...
> ... -76dB signal antenna 5 Beacon (...) [1.0* 2.0* 5...
> ... -83dB signal antenna 5 Beacon (...) [11.0* 11.0* 6....
> ... -74dB signal antenna 5 Data IV: c0 Pad 20 KeyID 1
> ... -74dB signal antenna 5 Beacon (...) [1.0* 2.0* 5.5* 11.0* ...
> ... -77dB signal antenna 5 Beacon (...) [1.0* 2.0* 5...
> ... -83dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5...
> ... -82dB signal antenna 5 Beacon (...) [1.0* 2.0* 2.0* 5....
>
>
> Example: 9k-htc
> I see plenty of other frames (lots more in a larger sample)
>
> ... -75dB signal antenna 0 Unknown Ctrl Subtype
> ... -74dB signal antenna 0 Beacon (...) [1.0* 2.0* 5
> ... -74dB signal antenna 0 Beacon (...) [11.0* 11.
> ... -74dB signal antenna 0 Beacon (...) [1.0* 2.0*
> ... -76dB signal antenna 0 Beacon (...) [1.0* 2.0* 5.5*
> ... -76dB signal antenna 0 Beacon (...) [1.0* 2.0* 2
> ... -77dB signal antenna 0 Beacon (...) [1.0*
> ... -72dB signal antenna 0 Beacon (...) [1.0* 2.
> ... -73dB signal antenna 0 [|802.11]
> ... -73dB signal antenna 0 Unknown Ctrl Subtype
> ... -73dB signal antenna 0 Power Save-Poll AID
> ... -72dB signal antenna 0 Beacon (...) [1.0* 2.0* 5
> ... -72dB signal antenna 0 Beacon (...) [1.0* 2.
> ... -73dB signal antenna 0 Beacon (...) [1.0* 2.0*
> ... -75dB signal antenna 0 Beacon (...) ESS[|802.11]
> ... -76dB signal antenna 0 Beacon (...) [1.0* 2.0* 2
> ... -77dB signal antenna 0 CF Ack/Poll+QoS
> ... -78dB signal antenna 0 Data IV:363bbb Pad 20 KeyID 2
> ... -78dB signal antenna 0 Beacon (...) [1.0*
> ... -73dB signal antenna 0 Beacon (...) [1.0* 2.
> ... -74dB signal antenna 0 Beacon (...) [1.0* 2.0* 2.
> ... -75dB signal antenna 0 Unknown Ctrl Subtype
> ... -75dB signal antenna 0 Unknown Ctrl Subtype
>
>
> Regards,
> Marco