Wireless Access

I tried to answer this question for a few weeks already. Unfortunately, several tests gave me results that even confuse me more.

 

For example, I put a phone connected, screen-off, and logged its wifi scan activities at the client side overnight. For each scan, it did have quite a lot (20~50) scan results. I was assuming that each result means a corresponding ap (either on the connected channel or a different channel) is active and replies (probe response).

 

However, when I checked out snr report history at Aruba side, over the period there are only 3 ap's that were continuously reporting the client's snr. What about others that can be seen in the client scan log?

 

Even confusing, they reported at a pretty high rate (roughly every 5 minutes), but actually over the period my client scans at every half-an-hour on average. 

 

Please help me out. Thanks

An AP only reports client SNRs for clients that are associated to them, in general.  There are other applications like RTLS where access points can report on the signal strength of unassociated clients.

Thank you, but this is apparently not the case here. Let us see a trace:

 

                                          ap1                          ap2                 ap3              ap4

2015-08-15 03:02:55                                                                                    11

2015-08-15 03:02:56         23     

2015-08-15 03:04:03                                         53

2015-08-15 03:06:27         24                     

2015-08-15 03:06:52                                         51

2015-08-15 03:07:19                                         53

2015-08-15 03:08:44         22                                                                 

2015-08-15 03:09:23                                                                 13

2015-08-15 03:11:01                                         51

..... 

 

I am assuming my client was associated with ap2, then what to do with ap1, ap3 and ap4?

Thank you, but this is not the case here. Consider the following trace:

 

                                           ap1       ap2      ap3      ap4

2015-08-15 03:02:17          21

2015-08-15 03:03:07                       52

2015-08-15 03:03:41                       51

2015-08-15 03:04:55                                    12

2015-08-15 03:06:22          23

2015-08-15 03:07:10                       52

2015-08-15 03:08:35                                                8

2015-08-15 03:11:06          22

 

I am assuming my client was associated with ap2, then what to do with ap1, ap3 and ap4?

Thank you.

What are you using to get that information?

Is there any document to talk about this? I need a clear and thorough answer to the question "when an ap would update a client (either associated ones or others) 's snr"

 

Thank you

There is no document about this. The only reliable way to get a client's SNR is on the access point it is connected to. What command are you using to poll the controller?

Periodically poll the controller.

---

@nzhang27 wrote:

Periodically poll the controller.

---

what exactly are you polling ? please show us the exact source of the values, then we can tell you where they come from.

 

There are at least 2 different ways that SNR is collected, one of them is from direct connection, the other is through the general air-monitor function that every AP has. If a client becomes a "monitored client" then those APs will start to track SNR and populate the wlsxMonStationInfoTable with it's view of the client SNR (termed RSSI in MIB however).

 

The update frequency depends on whether you are using CLI commands or SNMP to find these values, hence the question about where exactly you are getting the values from

 

regards

-jeff

Thank you for your reply. 

 

There are at least 2 different ways that SNR is collected, one of them is from direct connection, the other is through the general air-monitor function that every AP has. If a client becomes a "monitored client" then those APs will start to track SNR and populate the wlsxMonStationInfoTable with it's view of the client SNR (termed RSSI in MIB however).

 

I really care about how/why/when NON-associated APs report a client's snr. Two derived questions: 1) when does an  ap start/resume doing "air-monitoring" job? and 2) when does a client become a "monitored client"?

what exactly are you polling ? please show us the exact source of the values, then we can tell you where they come from.

 

The update frequency depends on whether you are using CLI commands or SNMP to find these values, hence the question about where exactly you are getting the values from

 

I use perl script that has following SNMP logic every 3 seconds. 

                my @snmpW=();
 
                &SNMP::addMibDirs("/usr/share/snmp/mibs/" );
                &SNMP::loadModules('WLSX-MON-MIB');

                &SNMP::initMib();
 
                my %snmpparms;
                $snmpparms{Community} = $communityString;
                $snmpparms{DestHost} = inet_ntoa(inet_aton($controller));
                $snmpparms{Version} = $sver;
                $snmpparms{UseSprintValue} = '1';
                $sess = new SNMP::Session(%snmpparms);

                $vb = new SNMP::Varbind([$rssiMibString]); 

The table I showed in earlier replies is something after few script processing. 

 

 

 

 

 

 

 

 

 

 

 

I use perl script that has following SNMP logic every 3 seconds. 

                <snip>

                $vb = new SNMP::Varbind([$rssiMibString]); 

 

May I confirm it is .1.3.6.1.4.1.14823.2.2.1.6.7.2.1.1.5 (aka WLSX-MON-MIB::monStaInfoRSSI)  that you are collecting specifically ?

 

---

I really care about how/why/when NON-associated APs report a client's snr. Two derived questions: 1) when does an  ap start/resume doing "air-monitoring" job? and 2) when does a client become a "monitored client"?

1) AP is always doing the AM job - with some caveats and exceptions. If the AP is not able to scan, due to something like rogue containment, active VOIP etc., then it will reduce it's ability to find off channel clients (and indeed APs, as reported in wlsxMonAPInfoTable in the same MIB). So this can mean that an AP that is on the same channel as the client (whom is associated to some other AP) is more likely to hear that AP, see next point.

 

2) A client has to first transit the potential client-list.. Any frames heard by the AM will add a client to the potential-client list (see it at show ap monitor pot-client-list ap-name <>). After some time, if more frames are heard (i.e. busy enough and on channel enough) then the client is promoted to the "client-list", which can be viewed as "show ap monitor client-list ap-name <>"

 

The output of 'client-list' has info such as whether its valid (i.e. known to this controller) or interferering (i.e. associated to some other controller). Channel that the client is on. SNR and RSSI (derived relative to noisefloor) are present. And there are some housekeeping columsn used for ageout/purging the table as the clients move out of range.

 

dt—Detected time: the number of timer ticks since the client was last detected.
mt—Monitor time; the number of elapsed timer ticks since the AP first recognized the monitored client.

 

ut—Unseen time: the number elapsed timer ticks the monitored client was not seen when scanning a channel of the device.
it—AP idle time, the number of timer ticks since the AP last saw any frames from the monitored client.

 

eventually this information is fed from the AP AM to the controller WMS and aggregated, and it is the WMS module which then populates the MIB. This happens around once per 60 seconds and is not real time.

 

You could probably modifiy your script to collect more of the wlsxMonStationInfoTable so that you can determine which one is the current connected AP and which are just AM results.

 

regards

-jeff

 

 

 

 

 

eventually this information is fed from the AP AM to the controller WMS and aggregated, and it is the WMS module which then populates the MIB. This happens around once per 60 seconds and is not real time.

How often do you think one should issue a new SNMP query and obtain fresh result for an AP? Is this update interval different for different APs?

Also, upon receiving a SNMP query, is it possible for the MIB to provide us with outdated cached snr reports? By the way, any document to describe these time parameters? Thank you so much.

 

 

 

How often do you think one should issue a new SNMP query and obtain fresh result for an AP?

I think that more depends on what it is that you are trying to achieve and whether or not there is a better more real time source that can be used. Example, if your working on lab gear and dont care about slamming the CLI, then this issue is far better obtained via the CLi. If you're talking about an inservice system, then minimising SNMP for large result sets is always a good thing.

Is this update interval different for different APs?

yes, the APs just have a timer and they send based on that, they do not all arrive at the same time.

Also, upon receiving a SNMP query, is it possible for the MIB to provide us with outdated cached snr reports?

No, there is no history, but there are more suitable things for collecting RSSI continually to avoid a requirement for historical retrieval, such as as RTLS.

By the way, any document to describe these time parameters? Thank you so much.

 

they are documented in the CLI guide, under the "ids general-profile" hierarcy, in profile "default". I recommend you don't change these values on a live system, especially with a view to speed things up. There are implications for IDS, WIPS and ARM.

 

 

(HKWLC7210) # show ids general-profile default

IDS General Profile "default"
-----------------------------
Parameter                                Value
---------                                -----
Adhoc AP Max Unseen Timeout              180 sec
Adhoc (IBSS) AP Inactivity Timeout       5 sec
AP Inactivity Timeout                    20 sec
AP Max Unseen Timeout                    600 sec
Client Detection Mode                    normal
Frame Types for RSSI calculation         ba pr dlow dnull mgmt ctrl
IDS Event Generation on AP               none
Max Monitored Devices                    1024
Max Unassociated Stations                512
Min Potential AP Beacon Rate             25 %
Min Potential AP Monitor Time            2 sec
Mobility Manager RTLS                    false
Monitored Device Stats Update Interval   0 sec
Packet SNR Threshold                     0
Send Adhoc Info to Controller            true
Signature Quiet Time                     900 sec
STA Inactivity Timeout                   60 sec
STA Max Unseen Timeout                   600 sec
Stats Update Interval                    60 sec
Wired Containment                        false
Wired Containment of AP's Adj MACs       false
Wired Containment of Suspected L3 Rogue  false
Wireless Containment                     deauth-only
Debug Wireless Containment               false
WMS Client Monitoring                    all

(HKWLC7210) #

 

I found when a client is roaming, or when there are a lot of traffic around it, the number of snr reports (for the client) I can see from the controller side evidently increases. Could you pls explain this? Thank you.

---

@nzhang27 wrote:

I found when a client is roaming, or when there are a lot of traffic around it, the number of snr reports (for the client) I can see from the controller side evidently increases. Could you pls explain this? Thank you.

---

SNR reports from where ? AMON ? SNMP queries ? traps ?  please show me exactly what data you are referring ?

 

regards

-jeff

---

@jgoff wrote:

---

@nzhang27 wrote:

I found when a client is roaming, or when there are a lot of traffic around it, the number of snr reports (for the client) I can see from the controller side evidently increases. Could you pls explain this? Thank you.

---

SNR reports from where ? AMON ? SNMP queries ? traps ?  please show me exactly what data you are referring ?

 

regards

-jeff

---

From SNMP queries, 1.3.6.1.4.1.14823.2.2.1.6.7.2.1.1.5

my presumption is that this due to the fact that at roaming time the client is probing a lot, hence it's not the AP coming to the clients channel and hoping to see a packet within the 100ms dwell time, rather the client is appearing on the APs channel, sending a probe, maybe getting a probe response and then moving to the next channel. i.e. now we dont have to wait for AP to scan (once per ten seconds) rather the client is strafing every channel looking for an AP.

Thanks, I also had the same guess. But this does not explain following observations

 

A smartphone was connected and associated with an AP over night (around 10 hours, quietly, screen-off). I then pulled out its scan history over the period, there were 32 scans. Here I have an assumption: all smartphone scans are ACTIVE scan (this assumption are validated by many web posts / kernel code / academia readings, even though I did not check what 32 scans did). Then I dumped all snmp queries over the same period. Based on the above assumption, I hope to see that, at each client scan time, there should have been an significantly increasing number of APs started to report the client's snr values (and of course, after the scan, they can disappear). I think this is a reasonable test to empirically prove our guess.

 

However, this is not the case. Nearby APs were not reporting anything. Did they go to bed?

 

---

@nzhang27 wrote:

Thanks, I also had the same guess. But this does not explain following observations

 

A smartphone was connected and associated with an AP over night (around 10 hours, quietly, screen-off). I then pulled out its scan history over the period, there were 32 scans. Here I have an assumption: all smartphone scans are ACTIVE scan (this assumption are validated by many web posts / kernel code / academia readings, even though I did not check what 32 scans did).

there will be a mix of directed + bcast probes and their periodicity etc will be heavily device/os dependant. For a good read on this, please search for the following document on the internet WLAN_Pros_Finding_cell_edge_012815.pdf (kudos to the author Jerome Henry) - it has some very good lab observations of probing behaviours of and s5 versus iphone 5 vs ios8 on some unknown device.

 

I think your observations can be explained given that smart phones probe very very rarely when idle, but do change their behaviour (i.e. frequency and type) as SNR fluctuates or when the screen is active - then finally they start to more agressively probe once various roaming thresholds are hit.

 

If we take the iphone5 observations in that PDF, the author notes "When connected to a network and not working on the screen (idle), no large variation of the AP signal (static position,
good signal), Iphone5 does not scan (except broadcast every 30 minutes). "  [ page 30 ]

 

if SNR starts to get quite low, then: "When AP SNR drops below 15 dB, IPhone 5 also turns to panic probe:" [ ref 35 ], where the implication is that the interval between probes is greatly reduced.

 

Now recall in a previous post I mentioned that devices must transit the pot-client-list before they enter the client-list, and what I suspect is happening is that the low frequency "idle" probing is not enough to graduate the client from potential to actual client. A single packet probe once per 30 mins is not likely to graduate the device - I say not likely because I haven't tested it (and I dont have an iphone5 to test with)

 

One way I can think of to test this assumption may be to use a script to monitor the output of every single APs pot-client-list and cross check that against the probe log from the device vs. the MIB output. We have a CLI scripting tool called AirRecorder that can automate that with a single line of 'command' input, let me know if you're interested (it also has the very handy ability to output to ZMQ hence making it easy to act as a feeder from CLI to some sort of back end script/tool)

 

regards

jeff

 

Sorry I did not find WLAN_Pros_Finding_cell_edge_012815. Could you pls copy paste the link here? Thanks!

hmm, since I cannot find the PDF itself online, I will post this instead - go here

 

https://vimeo.com/keithrparsons/videos/page:4/sort:date

 

and view presentation #110, it's the same presentation - the material I am talking about starts at about 11m in

I just finished two tests. Results make me even more confused.

 

Test #1: keep doing client-scanning (the phone starts a new scan once it receives scan results, so I am assuming it is frequent enough to promote from a potential client to a client); at the same time, I keep querying *snmpwalk -v2c -c mytest 10.172.2.250:161 1.3.6.1.4.1.14823.2.2.1.6.7.2.1.1.5*

 

The client phone is showing YouTube at a fixed place for 5 minutes - over the period, only the associated AP reported snr values.

 

Test #2: Slow walk in the building while YouTube was being played. The laptop fixed in my lab kept querying *snmpwalk -v2c -c mytest 10.172.2.250:161 1.3.6.1.4.1.14823.2.2.1.6.7.2.1.1.5*. Output:

 

First query:
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.32.122.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.148.1.240.37.183.61.14.134 = INTEGER: 35
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.38.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.153.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.216.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.241.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.171.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.170.210.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.171.60.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.152.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.169.2.240.37.183.61.14.134 = INTEGER: 0

Second query:
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.32.122.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.148.1.240.37.183.61.14.134 = INTEGER: 35
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.38.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.153.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.216.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.241.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.171.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.170.210.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.171.60.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.152.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.169.2.240.37.183.61.14.134 = INTEGER: 0

3rd query:
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.32.122.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.148.1.240.37.183.61.14.134 = INTEGER: 35
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.38.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.153.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.216.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.241.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.4.1.240.37.183.61.14.134 = INTEGER: 21
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.171.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.170.210.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.171.60.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.152.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.169.2.240.37.183.61.14.134 = INTEGER: 0

4th query:
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.32.122.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.148.1.240.37.183.61.14.134 = INTEGER: 35
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.38.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.153.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.216.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.241.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.4.1.240.37.183.61.14.134 = INTEGER: 21
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.171.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.170.210.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.171.60.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.152.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.169.2.240.37.183.61.14.134 = INTEGER: 0

5th query:
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.32.122.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.16.2.240.37.183.61.14.134 = INTEGER: 27
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.148.1.240.37.183.61.14.134 = INTEGER: 35
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.38.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.153.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.216.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.241.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.4.1.240.37.183.61.14.134 = INTEGER: 21
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.171.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.170.210.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.171.60.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.152.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.169.2.240.37.183.61.14.134 = INTEGER: 0

6th query:
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.32.122.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.16.2.240.37.183.61.14.134 = INTEGER: 27
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.148.1.240.37.183.61.14.134 = INTEGER: 35
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.38.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.153.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.216.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.241.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.4.1.240.37.183.61.14.134 = INTEGER: 21
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.171.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.170.210.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.171.60.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.152.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.169.2.240.37.183.61.14.134 = INTEGER: 0

7th query:
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.32.122.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.16.2.240.37.183.61.14.134 = INTEGER: 27
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.33.148.1.240.37.183.61.14.134 = INTEGER: 35
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.38.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.153.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.216.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.34.241.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.4.1.240.37.183.61.14.134 = INTEGER: 21
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.0.36.108.195.35.171.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.170.210.1.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.36.222.198.197.171.60.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.152.2.240.37.183.61.14.134 = INTEGER: 0
SNMPv2-SMI::enterprises.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.200.169.2.240.37.183.61.14.134 = INTEGER: 16

....

Two observations:

1) reading too frequent --> give me outdated numbers

2) even roaming over the network --> seems only the associated AP reports.

for your test 1, you need to monitor the pot client lists and also capture the traffic - different clients do different things, your client may only be sending a few probes out despite the fact you're calling scan. It may get more agressive when SNR is low (thats the point being made in that presentation i added the link for just now). Does the scanning API you are calling send bcast or directed, does it try to send directed probe to every saved network, do you have enough saved networks ? try monitoring the pot client list of a near by ap and assess the behavior (and try to sniff it if you can)

 

Not sure this is part of test 1 or something else, but:

"The client phone is showing YouTube at a fixed place for 5 minutes - over the period, only the associated AP reported snr values."

 

do you know it's even scanning in this case ?  as noted in those slides if it's an iphone5 it wont scan at all. If its android then again it might not be as frequent as you think, i.e.

 

"When connected to a network, with data traffic and good signal (not mobile and/or mobile within good AP signal range), S5 probes with a 313, 1813 and 1430 second cycle "
 

 

for test2, outdated numbers maybe due update lag and/or pot-client-list -> client-list transition. But, no matter whether the others update or not, the only valid data point is from the associated AP; the others serve no useful purpose except for coarse grained location detection

 

The MIB is not a practical way even for a single client to extract SNR in semi real time, you need the CLI for that, and even that is not so practical, you need to do something like this:

 

mac="64:76:ba:ae:2f:7e"
do {
  show ap association client-mac $mac                                                                  # find the AP
  show ap debug client-table ap-name $ap | include "---,MAC,$mac"                     # current SNR etc.
  show ap remote debug mgmt-frames ap-name $ap | include "Tr,Ti,---,$mac"      # assoc frames
  sleep 5
}

the above is easily automated with our AirRecorder tool - if you want to know more let me know, in fact you could collect the pot-client-list, client-list and the SNR info as shown above, with just 4 lines of code.

 

regards

-jeff

Not sure this is part of test 1 or something else, but:

"The client phone is showing YouTube at a fixed place for 5 minutes - over the period, only the associated AP reported snr values."

 

do you know it's even scanning in this case ?  as noted in those slides if it's an iphone5 it wont scan at all. If its android then again it might not be as frequent as you think, i.e.

All above was for test #1. My background android app does back-to-back scans, always, even while YouTube was played. I also did have scan results from each scan. Is it possible the associated AP tells other APs that this client has good connections, keeps receiving beacons, snr values are strong... so you APs do not have to report anything about this client?

 

I also need to go sniff probe requests sent by the phone and detect real scans.

 

 

for test2, outdated numbers maybe due update lag and/or pot-client-list -> client-list transition. But, no matter whether the others update or not, the only valid data point is from the associated AP; the others serve no useful purpose except for coarse grained location detection

 

I also notice different life time for entries over continuous SNMP queries. For example, this entry:

 

iso.3.6.1.4.1.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.199.35.2.240.37.183.61.14.134 = INTEGER: 15

It appears in the query made at 21:08:37, and goes disappear in the query made at 21:14:02. In between there are 10+ queries and the entry appears in them. The life time for this entry is around 5 minutes. Another entry (randomly chosen) has life time around 10 minutes.  What decides these time parameters?

 

 

Also, in the entry, there is a '2' (or '1') between lan_mac (216.199.200.202.199.35) and client_mac (240.37.183.61.14.134), what does it mean?

 

Thank you.

 

 

 

 

asdasd

 

---

All above was for test #1. My background android app does back-to-back scans, always, even while YouTube was played. I also did have scan results from each scan. Is it possible the associated AP tells other APs that this client has good connections, keeps receiving beacons, snr values are strong... so you APs do not have to report anything about this client?

no, that is not the way it works. But I just realised I have misspoken, in the case of youtube, even if near by aps dont hear the scanning by the client, if the client is doing continuous traffic, it should quickly be detected by neighbor aps when they are scanning (i.e. visiting the channel where the client is). You are going to have to get CLI access to determine  whats going on with that.

 

 

---

I also notice different life time for entries over continuous SNMP queries. For example, this entry:

 

iso.3.6.1.4.1.14823.2.2.1.6.7.2.1.1.5.216.199.200.202.199.35.2.240.37.183.61.14.134 = INTEGER: 15

It appears in the query made at 21:08:37, and goes disappear in the query made at 21:14:02. In between there are 10+ queries and the entry appears in them. The life time for this entry is around 5 minutes. Another entry (randomly chosen) has life time around 10 minutes.  What decides these time parameters?

 

as noted in previous post, there are timeouts involved here based on last-time-seen by the scanning AP. since the AP will be on channel around 80ms, it has to hear a packet in order to refresh the entry.

 

---

Also, in the entry, there is a '2' (or '1') between lan_mac (216.199.200.202.199.35) and client_mac (240.37.183.61.14.134), what does it mean?

 

please use the following params when doing SNMP queries, it will make things much clearer. Get the relevant Aruba mibs (within a major version is ok), unzip to some directory, go there and use snmpwalk/get/table as shown:

 

snmpwalk -v2c -c whatever -M. -mALL -O0X 1.2.3.4 wlsxMonStationInfoTable

 

now you will get proper decodes of the OIDs which should clear up ambiguity. [1] and [2] below refer to radio (i.e. 5ghz and 2.4ghz respectively)

 

WLSX-MON-MIB::monStaInfoRSSI[STRING: ac:a3:1e:c3:7d:f2][1][STRING: 6c:f3:7f:d6:4a:71] = INTEGER: 19
WLSX-MON-MIB::monStaInfoRSSI[STRING: ac:a3:1e:c3:7d:f2][1][STRING: e8:50:8b:0d:68:0d] = INTEGER: 55
WLSX-MON-MIB::monStaInfoRSSI[STRING: ac:a3:1e:c3:7d:f2][2][STRING: 00:26:c7:53:9e:7a] = INTEGER: 9
WLSX-MON-MIB::monStaInfoRSSI[STRING: ac:a3:1e:c3:7d:f2][2][STRING: 00:e0:4c:81:89:14] = INTEGER: 0
WLSX-MON-MIB::monStaInfoRSSI[STRING: ac:a3:1e:c3:7d:f2][2][STRING: 04:4b:ff:07:a7:68] = INTEGER: 0

 

 

by the way, for your SNMP queries, you can add -mALL -M. -O0X   to the snmpwalk command, the output will be much clearer (assumes aruba mibs are in the cwd)

 

Hello Jeff,

 

I do like to try your script. Unfortunately, I do not have permission to access the controller using commands

 

show ap association / monitor ...

I am a university researcher and Aruba (actually local admin people) only opens WLSX-MON-MIB for us to query. I am not ignoring your script, but as my understanding, I may not be able to do that.

noted.. maybe you can ask them if they will let you either a> have a read only account for the CLI , or b> let you have read only access via the webUI CGI interface (also can be scripted using curl)?