Id do frame captures to see

salvatore.parisi · ‎06-14-2016

Hello to everybody,

we would like to share with you some problems we have raised in our wifi infrastructure. The subject is the client roaming from an AP to another. We wish you can have some suggestions to solve the roaming issues described below.

Infrastructure Data:

- WLC Cisco 5520

- Software Version 8.1.102.0

- Access Point : AIR-CAP3702

Mobile phone witch we have to use in our company:

- Cisco CP-7925

- Samsung Galaxy S3 (GT-I9300) with Jabber

- Samsung Galaxy S4 (GT-I9505) with Jabber [CCXv4]

- Samsung Galaxy A3_2016 (SM-A310F) with Jabber [CCXv4]

- Samsung J5 with Jabber (SM-J500F) [CCXv4]

For the Mobile Phone Service we have made a WLAN ad hoc ("WIFI-VOICE"). The main parameters are the following:

- General: Radio policy: 802.11 b/g only

- Security: Layer 2 security: none

- Security: Mac filtering enabled

- Security: Fast transition enabled

- Security: Fast Transition over the DS enabled

- Security: Fast Transition Reassociation timeout 20 seconds

- QOS: Platinum (voice)

- AVC profile: Jabber

- Advanced: 11K Neighbor list enabled

- Broadcast SSID : NO.

ISSUES:

The mobile phones have all the same roaming problem: the roaming is not transparent and they loses the connections when the device passes from an AP to another. It’ s important to notice that the CISCO IP Phone CP-7925 roams correctly in the same scenario.

We made a debug session (from CLI, debug client <MAC addr> ) and we noticed that, in the log of the CP-7925 we find:

Reassociation received from mobile on BSSID 80:e0:1d:fd:d2:0b AP Office-P2-Ap142 when the client roams from an AP to the following.

In the case of Mobile Smartphone (we caught the log of Samsung A3_2016 and Samsung J5) we find only a series of Association phases: when the client roams, it makes just a disassociation from the old AP and a new Association to the new AP.

This condition causes different problems like the phone Applications (e.g Jabber) disconnection and, generally, the breaking of all TCP connections.

Here we are some logs (an Samsung Galaxy A3_2016 that passes from AP Office-P2-Ap140 to Office-P2-Ap138) :

*apfMsConnTask_7: Jun 14 13:10:21.070: [PA] 2c:ae:2b:5a:87:ac Association received from mobile on BSSID 80:e0:1d:fd:cf:44 AP Office-P2-Ap140

*apfMsConnTask_7: Jun 14 13:11:22.069: [PA] 2c:ae:2b:5a:87:ac Association received from mobile on BSSID 80:e0:1d:f8:5a:94 AP Office-P2-Ap138

In attachment you will find the logs we caught during the debug session.

Do you have some suggestions to solve this problem?

The roaming behavior of the Cisco IP phone 7925 is perfect; with the same configuration the roaming of the other mobile phones is intolerable.

Thanks a lot.

Leo Laohoo · ‎06-14-2016

- Software Version 8.1.102.0

My eyes stopped there. Upgrade to 8.1.131.0 or 8.2.100.0. There are reasons why Cisco no longer allows anyone to download the version currently being used.

- General: Radio policy: 802.11 b/g only

Uhhhh .. what??

- QOS: Platinum (voice)

And what is the 802.1p value set to?

salvatore.parisi · ‎06-15-2016

Ok Leo, thanks a lot.

Now we will proceed with the version upgrade and after i'll let you know.

In the meanwhile we set up the general radio policy on "All"?

The Wired QOS protocol is set on 802.1p and the 802.1p tag has the value 5.

Salvatore

Leo Laohoo · ‎06-16-2016

In the meanwhile we set up the general radio policy on "All"?

Remote into the phone using a browser, go to Network Profiles > Profile.

Look under "802.11 Mode" and choose "Auto, 802.11a preferred over 802.11b/g".

What Data Rates are configured?

George Stefanick · ‎06-17-2016

Id do frame captures to see what is going on. Also take off security and see if roaming improves.

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

salvatore.parisi · ‎09-26-2016

Hi Leo, Hi All,

after the upgrade to the 8.2.110 my clients roams well.

I have a problem with clients with android 5 or later. These clients roams well only if the DHCP (client side) is off.

A device with android 4 roams well in all scenarios (DHCP off and DHCP on).

For Android 5 I see :

- If the DHCP in on (client side) I see that when the client roam (to another AP) the client IP address for a little while (1 second) take a 0.0.0.0 as IP address! After that interval he return to the correct IP address.

- If the DHCP is off (client side) when the client roam (to another AP) the client IP address is alwasy correct.

I have took the logs (attached) :

- dhcp_on_android_v4.txt : Roaming test with Android 4 and DHCP ON (roams ok)

- dhcp_off_android_v5.txt : Roaming test with Android 5 and DHCP OFF - static IP (roams ok)

- dhcp_on_android_v5.txt : Roaming test with Android 5 and DHCP ON - (roams bad)

Thank you for your support.

Salvo

gaasr gecer · ‎10-12-2017

The problem is that when DHCP is enable, the roaming process need to wait the DHCP Server answer regardless the IP address will change or not. The enable value is recomended to avoid "DHCP man and middle attack" for example, in the guest networks.

For real time applications, the DHCP Server answer delay, in many time is not acceptable, and the a phone call drop and the middle of roaming process.

You will need to pay a special attetion in roaming cases because in the real time applications some good features for common cases, they are not recommend, like wait for DHCP Server answer and AP Load Balance based on stick on connect AP as a collateral effect.

Claudio Rosa

ramsharma2354 · ‎06-07-2019

i also have same problem with my wifi

Rasika Nayanajith · ‎06-16-2016

I do not think below settings are correct. Most of them are against the voice deployment best practices as well.

http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cuipph/7925g/7_0/english/deployment/guide/7925dply.pdf

- If you enable 802.11r, it has to be either WPA2 with PSK or WPA2 with 802.1X

- Voice is always to deploy on 5GHz

- not sure MAC filtering is recommended setting for this

- Hidden SSID is not good

- General: Radio policy: 802.11 b/g only
- Security: Layer 2 security: none
- Security: Mac filtering enabled
- Security: Fast transition enabled
- Security: Fast Transition over the DS enabled
- Security: Fast Transition Reassociation timeout 20 seconds
- QOS: Platinum (voice)
- AVC profile: Jabber
- Advanced: 11K Neighbor list enabled
- Broadcast SSID : NO.

Refer this post for basic understanding of 802.11 roam

https://mrncciew.com/2014/09/02/cwsp-802-11-roaming-basics/

Here is how Fast transition (11r) works if you enable it. Note that once you enable this certain clients if they not support 11r may have trouble connecting to this SSID

https://mrncciew.com/2014/09/05/cwsp-802-11r-key-hierarchy/

https://mrncciew.com/2014/09/07/cwsp-802-11r-over-the-air-ft/

https://mrncciew.com/2014/09/08/cwsp-802-11r-over-the-ds-ft/

NB: As Leo suggested upgrade to a supported code, but do not expect your configuration issues will go away with that upgrade.

HTH

Rasika

*** Pls rate all useful responses ***

salvatore.parisi · ‎06-16-2016

Hello Rasika,

in order to better identify the problem inside our infrastructure, we did today another test with two different devices.

We used :

- an Android Samsung Galaxy A3_2016 (SM-A310F)

- an Apple IPAD Air.

We noticed that the Android Device has the same behavior : bad roaming.

Instead, the Apple IPAD roams correctly as you can see inside the log in attachment.

For Apple Device (IPAD) we get :

*apfMsConnTask_4: Jun 16 17:45:51.790: [PA] 60:d9:c7:b0:ee:13 Processing assoc-req station:60:d9:c7:b0:ee:13 AP:80:e0:1d:fd:d4:30-01 thread:9d8b5b0

*apfMsConnTask_4: Jun 16 17:45:51.790: [PA] 60:d9:c7:b0:ee:13 Reassociation received from mobile on BSSID 80:e0:1d:fd:d4:5b AP Office-P2-Ap139

for Android we still get:

*apfMsConnTask_7: Jun 16 18:00:54.226: [PA] 2c:ae:2b:5a:87:ac Processing assoc-req station:2c:ae:2b:5a:87:ac AP:80:e0:1d:f8:5a:b0-00 thread:9d8c840

*apfMsConnTask_7: Jun 16 18:00:54.226: [PA] 2c:ae:2b:5a:87:ac Association received from mobile on BSSID 80:e0:1d:f8:5a:94 AP Office-P2-Ap138

With the same configuration, with IPAD we have a transparent seamless roaming!

The Apple device do the Reassociation procedure when it roams from an AP to the following, the Android device didn’t (Android devices starts a new assosiation).

We also did two tests: the first one at 5 GHZ (802.11a only) and the second one at 2.4 GHz (802.11g only). The results are :

- The Apple device roams correctly in both cases.

- The Samung A3_2016 device, which works at only 2.4Ghz, as reported before, doesn’t roam correctly.

I read the article about Roaming basics, over ther air and over the ds. They are very interesting. But I saw that you had used, in your tests, an Iphone5. Have you ever tried an Android/Samsung Device?

Because also with my WLC configuration Apple devices and the Cisco CP-7925 works fine.

Thank you,

Salvo

Rasika Nayanajith · ‎06-16-2016

I would suggest below

1. Remove 802.11r & simply have your WLAN security configured with WPA2/PSK & test these two device. Even though it is not a fast roam, you should be able to see clients will use rassociation request/response when roam. They will do full auth as no fast roaming configured.

2. Once you confirm both working as expected, enable 11r on the WLAN & test it again.

Refer this site for client capabilities

http://clients.mikealbano.com/

HTH

Rasika

*** Pls rate all useful responses ***

salvatore.parisi · ‎06-17-2016

Hello Rasika,

we made the tests as you suggested.

The radio policy was setted to 802.11g only.

First Test

- 802.11r : FT disabled

- L2 Security : WPA+WPA2

- Authentication Key Management : PSK

Results:

- IPAD Air : roams correctlty. (We saw the Reassosiation responses) [log_ipad_noft_20161706.txt]

- Samsung Galaxy A3_2016 : not roams correctly (We saw only the Assosiation respones) [log_a32016_noft_20161706.txt]

Second Test

- 802.11r : FT enabled

- Security : WPA+WPA2

- Authentication Key Management : FT PSK

Results:

- IPAD Air : roams correctlty. (We saw the Reassosiation responses) [log_ipad_ft_20161706.txt]

- Samsung Galaxy A3_2016 : not roams correctly (We saw only the Assosiation respones) [log_a32016_ft_20161706.txt]

In atteched the logs.

In your roaming experiments, have you ever tried an Android/Samsung Device?

Thank you,
Salvo

salvatore.parisi · ‎06-24-2016

Hello Rasika,

today we did the WLC upgrade to the 8.2.110.0 version.

And now also with the Samsung Galaxy A3_2016 we, finally, get the Reassosiation responses!

*apfMsConnTask_0: Jun 24 15:02:09.813: [PA] 2c:ae:2b:5a:87:ac Processing assoc-req station:2c:ae:2b:5a:87:ac AP:80:e0:1d:f0:9d:f0-00 thread:18d805b8
*apfMsConnTask_0: Jun 24 15:02:09.813: [PA] 2c:ae:2b:5a:87:ac Station: 2C:AE:2B:5A:87:AC trying to join WLAN with RSSI 204. Checking for XOR roam conditions on AP: 80:E0:1D:F0:9D:F0 Slot: 0
*apfMsConnTask_0: Jun 24 15:02:09.813: [PA] 2c:ae:2b:5a:87:ac Station: 2C:AE:2B:5A:87:AC is associating to AP 80:E0:1D:F0:9D:F0 which is not XOR roam capable
*apfMsConnTask_0: Jun 24 15:02:09.813: [PA] 2c:ae:2b:5a:87:ac Reassociation received from mobile on BSSID 80:e0:1d:f0:9d:d4 AP Office-P2-Ap136
*apfMsConnTask_0: Jun 24 15:02:09.813: [PA] 2c:ae:2b:5a:87:ac Station: 2C:AE:2B:5A:87:AC trying to join WLAN with RSSI 204. Checking for XOR roam conditions on AP: 80:E0:1D:F0:9D:F0 Slot: 0
*apfMsConnTask_0: Jun 24 15:02:09.813: [PA] 2c:ae:2b:5a:87:ac Station: 2C:AE:2B:5A:87:AC is associating to AP 80:E0:1D:F0:9D:F0 which is not XOR roam capable
*apfMsConnTask_0: Jun 24 15:02:09.814: [PA] 2c:ae:2b:5a:87:ac Rf profile 200 Clients are allowed to AP radio

Is a little step. Now the phone doesn't lose the wifi signal but at every ap change it continues to break all tcp connections.

Thank you for your support! Do you have any suggestion for us ?

BR

Salvo

Andrew MacTaggart · ‎06-24-2016

DHCP has a high elapsed time: 92s

Maybe you are running DHCP on a switch or something other than a dedicated server.

salvatore.parisi · ‎06-25-2016

Hi Andrew,

thank you for your answer.

Can you show me where you see that ?

Thank you,
Salvo

Wifi roaming issue on Android Client