DHCP issue on Samsung Android Clients Roaming

salvatore.parisi · ‎12-28-2016

Hi guys,

here my configuration:

- WLC : Cisco 5520

- Software Version : 8.2.141.0

- Access Point : AIR-CAP3702

Tested Clients :

1) Samsung Android (Galaxy A3 2016 - Android 6.0.1) - DHCP ON

2) IPAD (IOS 9) - DHCP ON

3) One Plus One - DHCP ON

Only the Samsung device has the following problem:

When the device roams from an AP to another AP it losts the IP (10.56.229.65) address -> takes the IP 0.0.0.0 -> and after few millisecons takes again the previous ip address (10.56.229.65). This is a big problem because all the applications's connections are lost!

If, in the Samsung device, I set the DHCP to OFF when the device roams from an AP to another AP it never lost the IP! And works well!

Using other devices (IPAD and One Plus One), also setting the DHCP to ON, this don't happen. The other devices always works well!

It is possible that Samsung have this "bug" on their network system ?

Anyone has this problem in the Wi-Fi network ?

Thank you,

Salvo

Leo Laohoo · ‎12-28-2016

Only the Samsung device has the following problem

Contrary to popular "belief", the wireless clients have the final "decision" which AP to join and it NOT the responsibility of the wireless network.

If the problem is only observed on the Samsung client, then try upgrading the firmware of the client and see if there are any improvement(s).

If, in the Samsung device, I set the DHCP to OFF when the device roams from an AP to another AP it never lost the IP! And works well!

Of course static IP address works. One can configure the DHCP server to exclude a specific IP address if this helps things.

salvatore.parisi · ‎12-28-2016

Hi,

the strange thing is the long DHCP part in the Samsung log that i've attached.

The other clients doesn't have that DHCP part, around 40 rows of DHCP Socket Task :

*DHCP Socket Task: Dec 28 10:41:45.789: [PA] 2c:ae:2b:5a:87:ac DHCP received op BOOTREQUEST (1) (len 316,vlan 228, port 1, encap 0xec03, xid 0x732cd290)
*DHCP Socket Task: Dec 28 10:41:45.789: [PA] 2c:ae:2b:5a:87:ac DHCP (encap type 0xec03) mstype 0ff:ff:ff:ff:ff:ff
*DHCP Socket Task: Dec 28 10:41:45.789: [PA] 2c:ae:2b:5a:87:ac DHCP processing DHCP REQUEST (3)
*DHCP Socket Task: Dec 28 10:41:45.789: [PA] 2c:ae:2b:5a:87:ac DHCP   op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0

and more...

patoberli · ‎01-06-2017

Do you have "DHCP required" option turned on on that SSID? This can cause this problem.

Linux Clients (and Android) don't do a "DHCP renew" when roaming the AP, which is required when the option "DHCP required" is enabled. This causes the client (other might also be affected) to retry the connection, which is blocked by the AP/Controller (they are waiting for the DHCP packet), until it does a full DHCP.

I sadly don't find the cisco document where I have found this information. It might be, that this only affects configurations with several controllers.

salvatore.parisi · ‎01-10-2017

Here my WLAN Advanced Options.

I see :
- DHCP Addr. Assigment (<-maybe this?)

Thank you,

Salvo

patoberli · ‎01-10-2017

Yes it was this option. Was it disabled already or have you disabled it now?

Is it working now?

What is your DHCP Proxy setting under Controller - Advanced - DHCP?

If it is set to Proxy (default), have you configured the correct DHCP server unter each (via Radius assigned) virtual LAN interface under Controller - Interfaces that could be used for this SSID?

salvatore.parisi · ‎01-10-2017

The option "DHCP Addr. Assigment" was already disabled.

Here the configuration (Controller - Advanced - DHCP) :

It is wrong ?

patoberli · ‎01-10-2017

It's not wrong, but can cause issues.

Here is the manual for this option: http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-2/config-guide/b_cg82/b_cg82_chapter_0101000.html

It's fairly large, but a very important read. In some specific use cases it must be disabled (like on your controller), so you need to check if your environment requires it disabled.

If you know old lan technology somewhat, the DHCP proxy is similar to the old "ip helper" function on cisco routers.

Oh and here is the troubleshoot document (which I needed yesterday for a different DHCP problem ;) )

http://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/110865-dhcp-wlc.html

This second document is actually better to read and has a few images on how it's working.

salvatore.parisi · ‎01-10-2017

I don't know but seems that all DHCP Protocol Messages are duplicated (look the file 1.samsung_a3_2016_android_6.0.1.txt attached in the first post).

For instance:

*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP received op BOOTREPLY (2) (len 309,vlan 229, port 1, encap 0xec00, xid 0xdd634687)
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP processing DHCP ACK (5)
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP   xid: 0x874663dd (2269537245), secs: 0, flags: 0
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP   chaddr: 2c:ae:2b:5a:87:ac
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP   ciaddr: 0.0.0.0,  yiaddr: 10.56.229.65
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP   siaddr: 0.0.0.0,  giaddr: 10.56.229.252
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP   server id: 172.16.9.3  rcvd server id: 172.16.9.3
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP successfully bridged packet to STA
*DHCP Socket Task: Dec 28 10:41:51.144: [PA] 2c:ae:2b:5a:87:ac DHCP received op BOOTREPLY (2) (len 309,vlan 229, port 1, encap 0xec00, xid 0xdd634687)
*DHCP Socket Task: Dec 28 10:41:51.145: [PA] 2c:ae:2b:5a:87:ac DHCP processing DHCP ACK (5)
*DHCP Socket Task: Dec 28 10:41:51.145: [PA] 2c:ae:2b:5a:87:ac DHCP   op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0
*DHCP Socket Task: Dec 28 10:41:51.145: [PA] 2c:ae:2b:5a:87:ac DHCP   xid: 0x874663dd (2269537245), secs: 0, flags: 0
*DHCP Socket Task: Dec 28 10:41:51.145: [PA] 2c:ae:2b:5a:87:ac DHCP   chaddr: 2c:ae:2b:5a:87:ac
*DHCP Socket Task: Dec 28 10:41:51.145: [PA] 2c:ae:2b:5a:87:ac DHCP   ciaddr: 0.0.0.0,  yiaddr: 10.56.229.65
*DHCP Socket Task: Dec 28 10:41:51.145: [PA] 2c:ae:2b:5a:87:ac DHCP   siaddr: 0.0.0.0,  giaddr: 10.56.229.253
*DHCP Socket Task: Dec 28 10:41:51.145: [PA] 2c:ae:2b:5a:87:ac DHCP   server id: 172.16.9.3  rcvd server id: 172.16.9.3
*DHCP Socket Task: Dec 28 10:41:51.145: [PA] 2c:ae:2b:5a:87:ac DHCP successfully bridged packet to STA

It is a normal behavior ?

patoberli · ‎01-10-2017

I don't know.

What confuses me though, are those two lines:

[code]
*DHCP Socket Task: Dec 28 10:42:40.998: [PA] 2c:ae:2b:5a:87:ac DHCP received op BOOTREQUEST (1) (len 316,vlan 228, port 1, encap 0xec03, xid 0xe2b8def8)

*DHCP Socket Task: Dec 28 10:42:40.998: [PA] 2c:ae:2b:5a:87:ac DHCP Opt82 bridge mode insertion enabled, inserts opt82 if opt82 is enabled vlan=229, datalen =18, optlen=72

[/code]

First it's sending the DHCP on vlan 228, afterwards the same client sends it on vlan 229. I'm not sure if this is normal.

Sadly I'm out of knowledge here to help you any further.