Android devices don't get the proper IP after logging in on the CWP.

  • 1
  • Question
  • Updated 3 years ago
I'm having a problem with android devices and the CWP on AP230s.  My personal phone, Droid Maxx, Android version 4.4.4, will connect quickly and notify me to log on in my browser.  The portal page comes up quickly and the Accept button brings up the Success page fine too.  However, it takes a full minute or more for the wifi connection to switch from the portal IP, 1.1.x.x, to the regular network IP, 192.168.x.x.  Once it does it is fine.
I seem to be having  issues only with Android devices.  Some older Android tablets(ver 4.1 or later) give a Web Server Internal Error initially but if you go back in the browser the portal page comes up and lets you log in.
IOS devices and laptops don't seem to have any of these issues. They connect, accept, and put you on the network quickly.
Any Ideas where to start with this one?
Photo of Mark Sundbom

Mark Sundbom

  • 12 Posts
  • 2 Reply Likes

Posted 3 years ago

  • 1
Photo of Terence Fleming ThinkWireless

Terence Fleming ThinkWireless, Champ

  • 79 Posts
  • 27 Reply Likes
If you select an Android device in the "Monitor Clients" screen (after it has connected) you will be able to use the "Client Monitor" tool to follow the progress of the authentication process next time it connects. 

You probably want to filter out probe requests from the Client Monitor output, but this will give you a good indication as to where the problems are arising.  

Given that the issue may be IP address related look particularly for DHCP offers/accepts
Photo of Mark Sundbom

Mark Sundbom

  • 12 Posts
  • 2 Reply Likes
Thanks for the suggestion.  I can see the "what" better although I am still looking for the "why" and the "What to do about it".
You can see the portal IP being assigned and then the Authentication finishing. You can also see the next DHCP session start and complete.  However, when you check the phone it still has the portal IP.  Then about 1:45 minutes later another DHCP session starts and finishes like the first. Execept that, now, the phone agrees and works fine after that.  Please, take a look, I hope I am just missing something simple.
    
     
Photo of BJ

BJ, Champ

  • 374 Posts
  • 45 Reply Likes
The next step would be to get a packet capture. You can use the AP as a remote interface in wireshark to see exactly what is happening on both layers two and three. Once you get some info, you can then move the trace closer to the dhcp server to get another view.

Best,
BJ  
Photo of Mark Sundbom

Mark Sundbom

  • 12 Posts
  • 2 Reply Likes
I did the packet capture. It took a bit of looking but the problem seems to be with the way this Android device verifies its connection.  It sends out a whole pile of DNS queries to what looks to be the "gateway" for the CWP.  Once it gets tired of that silliness it tries the DNS that is provided in the DHCP server settings. Once it gets a reply from that it accepts the IP address assigned to it 2 minutes ago and WOO-HOO! we have internet.
I did a packet capture on my iPhone(which is working fine) for comparison sake.  Generally speaking it looks the same except for one thing.  The iPhone tries the DNS provided by DHCP first and gets to the party 2 minutes faster.
This seems to be manufacturer specific.  The Android device I have been using is a Motorola Droid Maxx.  I have tried a couple of Samsung Androids(but no packet capture yet) and they don't seem to have the problem.
If anybody has any further ideas let me know. I really appreciate the suggestions so far. I have a much better feel for what is going on now than when I started.
Photo of Mark Sundbom

Mark Sundbom

  • 12 Posts
  • 2 Reply Likes
I've now done a packet capture on multiple Android devices and only my Maxx and some very old or off-brand devices seem to have any issues.  The other main brand devices such as Samsung, HTC, or Kindle go straight to the provided DNS and accept their address without a hitch.  Not sure why the other devices have the problem but I don't have time to run down glitches on individual devices.  The majority seem to work.  I just got "lucky" and discovered several of the oddities at the same time so it seemed more of a problem than it was.
Thanks for the help and pointing me in the right direction for troubleshooting.
Photo of Mark Sundbom

Mark Sundbom

  • 12 Posts
  • 2 Reply Likes
Just in case this might help somebody else I believe I have discovered the problem in this case.
Under Optional Advanced Configuration in the Captive Web Portals settings you will find DHCP and DNS Settings.  Your two main options are "Use external DHCP and DNS servers on the network" or "Use internal DHCP and DNS servers on the Aerohive device".
 
I did not understand these settings initially.  Simply put, the external setting allows your device to get its IP address from the regular DHCP server and then redirects you to the Captive Web Portal Page so you can log in to stop blocking the internet traffic.  The internal setting gives your device an initial IP address(1.1.X.X) to allow you to get to the CWP page and then after you log in on the CWP has your device request a second IP address from the regular DHCP server.

The internal setting doesn't actually block any traffic but puts your device on a separate network until you log in.  This switching IP addresses without changing WiFi connections is what I think causes problems for some android devices.  If I turn off the WiFi on my phone and immediately turn it back on again the AP still sees the device as authenticated but the phone sees it as a new WiFi connection and happily takes the second IP and goes about its business. This does not happen on every android device and I have not seen it at all on other devices such as iPhones.

My fix, so far, is to choose the external setting (which is the default) so the devices do not have to deal changing IP addresses after the initial assignment.

The one problem I have discovered is that if you choose "Guest Access" when you set up your SSID there will be firewall policies put in place that will block any traffic from the Captive Web Portal Page(1.1.X.1) to anything with a private IPv4 IP address(for example 192.168.1.5).  This is there to prevent any inter-client traffic, perhaps to make it more difficult for someone to hack your phone from the same network.  It also effectively blocks the Portal page from displaying on any device with a private address.  If you are using a private IP address scheme on your WiFi network this is a problem for the CWP.  I put a firewall rule in to allow traffic from 1.1.0.1/255.255.0.255.  Hopefully, this will work.