Web server internal error on CWP

  • 1
  • Question
  • Updated 2 years ago
Dear all,

Since 6 months ago, our wireless clients on mobile devices receive a "Web server internal error" everytime they log in into the CWP.
Initially the portal shows up normally, but when you log in (either on auth or guest) the redirect to success/fail web fails.

I've also tried with the Aerohive's default CWP with same results.

This only happens on mobile devices (newest versions of iOS and Android). Logging from laptops or PC works perfectly, though.

Can anyone help me??

Bests,

Carles.
Photo of ICN2

ICN2

  • 5 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 1
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
What version(s) of HiveOS, what model(s) of access points? 
Photo of ICN2

ICN2

  • 5 Posts
  • 0 Reply Likes
Thank you for your reply,

All ap121 with HiveOS 6.5r4 Honolulu.-128121. This happened suddenly 6 months ago without upgrading any version nor configuration, so I'm assuming browser protocols update for mobile devices (since it works on PC)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
If the error occurs after trying to log in, it may be to do with the redirection to the original URL requested. In the logs on the AP, are you seeing an error indicating that a URL was requested by the client that was >1024 characters. I have seen it where the client makes a request for a web page with a very long URL (this could be because some background application is periodically doing HTTP requests for long URLs and if this happens to be sent while the CWP is being served). Do you see the same problem if the CWP is configured to redirect on successful login to a specific page rather than the original requested page. The redirect to original page is fairly useless these days as most OS's now have a mechanism to detect a CWP rather than relying on the user manually opening a browser.

The only other time I've had a similar problem is with a particular device (it was a cheap Chinese-knock-off Android phone) which was not honouring the DHCP lease time for the temporary (1.1.x.x) network dished out by the AP prior to authentication (i.e. if "use internal DHCP/DNS" is configure in the CWP settings). Because the client didn't renew the lease, the APs internal IP/MAC tables get flushed and an internal server error occurs along with a log entry on the AP saying it couldn't map the client's MAC address to an IP (sorry, can't remember the exact error). A packet capture showed that the client did not renew the DHCP lease when it should have done (if left, the client would eventually try to renew the lease after several minutes, but with a lease time of 10 seconds, it should have done so every 5 seconds). This is a bug in the client, and there wasn't anything we could do to work around it without causing problems for other clients. I've not seen this with iOS or any other Android device however - just that one phone.
Photo of ICN2

ICN2

  • 5 Posts
  • 0 Reply Likes
Hi Roberto,

Thank you for your kind reply.

As you seed, reviewen que AP logs I observed the first issue you mention:

2016-06-22 08:58:18 err     kernel: [fe]: invalid internal_ip 1.1.2.73, can't xlate to client-ip (dev_ip 1.1.2.1)
2016-06-22 08:58:18 info    ah_auth: detect station(b474:9fXX:XXXX) os(Windows 7/Vista) via DHCP fingerprint
2016-06-22 08:58:18 warn    ah_capture: Web server just supports 1024 bytes URL length (Server: 1.1.2.1, Client: 1.1.2.73).

So obviously it may be a 1024 char issue. Now at least have something to start investigating.

Web that fails has the following URL:

<i>http://X.X.X.X/reg.php?ah_goal=auth-reg.html&ah_login=true&url=E2B8F3578D88E9E36CD7BB15C0C60</i>
E8AC72C51875E2499F18EA88DCA5D3FDA92FFB8EF0AC5C2A1FC2A92F84BC89649A7CE24189E5869D2E29392CCD04
E3FDAB6B88EBF618492F1EA06DEAD62D7B212CEE10F48B5746593D3D6B4DC95796BA6B0BDFEC412869FF1E707D4A
11ED7B110C0E70A47CF7217E7A5A2C4ACE17D6AD5B5CC8EBF62F197879177A5A766DFB162CAE3724DB10E60E4D3DE
CEDC910512D0B0CFFEB3168F9E83E77AD0AC63DCB213C191724DB4751096A4A3C4ACE17D11D1B1B2F4C265F191F7E
A76DFA761DFB260C8940F3AB6726294D4D1B5DC940810A5CABDFBB513F2E5F3E576D0A41EDCB618B991083AB3046D
96A0A0C1A8E40810A5B0B38AC2648596F19476A3A661AB


I started by removing the login successful page and the redirection web, but nothing changed. Still works on PC and Android (4.0) devices.

Any other ideas?

Thank you so much for your help.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Hi Carles,

Actually, what you are seeing is exactly what I was seeing with the second issue I mentioned.

In particular, this error:

kernel: [fe]: invalid internal_ip 1.1.2.73, can't xlate to client-ip (dev_ip 1.1.2.1)

The above error is what I get in our AP logs for the client that doesn't seem to renew its DHCP lease. You could confirm by doing a packet capture (remote sniffer) on the wireless interface and filtering for bootp/dhcp traffic. For the one device where I have seen this problem, it appears as if the device simply does not renew the DHCP lease when it should.

It may be that the second error about >1024 URL length is misleading (as in your case, the actual URL requested doesn't seem to be >1024 characters, though possibly the whole HTTP header exceeds that length) and is actually triggered by the first error. From the logs I took, I also saw the >1024 URL error after the invalid IP error (though not every time).

There is another possibility that the client IS renewing the DHCP lease but we're not actually seeing it in the capture for some reason (i.e. the packet is in the air, but isn't being received by the AP's NIC driver or is being discarded by it, and therefore not making it into the capture). This does seem a bit unlikely, but we did have issues in 6.5r3 (and other releases) with DHCP packets (though that issue was in the reverse direction - the client did not receive the DHCP offer). This issue was resolved in 6.5r4. You could confirm this potentially by using something other than the AP to capture the traffic in the air.

If I turn off the "use internal DHCP server", so clients get a "real" IP address from the beginning, I had no problem. Also, if I increase the DHCP lease time for the internal DHCP addresses in the CWP page (e.g. to 5 minutes) then I don't see a problem, but obviously this can cause other issues with clients that don't honour the DHCP NAK mechanism to trigger a rediscovery after logon.

As I say, the only device this has been reported on so far (across multiple customers) was one particular model of Android phone from a non-mainstream vendor. So far I've not seen this behaviour with any other device.

This is looking like something that will need escalating with Aerohive.

Regards,
Roberto
Photo of ICN2

ICN2

  • 5 Posts
  • 0 Reply Likes
Hi Roberto,

Finally I've bypassed the error by increasing the internal DHCP lease time to 1 minute. Now I've been able to access correctly to the CWP and login into it.

I owe you! Thank you so much!!!
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
OK. Just be aware that devices might take a bit longer to transition from the 1.1.x.x address to a "real" address if the lease time is longer, if they don't understand the pre-emptive NAK that the AP sends after logon. If you start having users report that they don't seem to get actual network access for some time after successfully logging in to the CWP, that's the most likely reason why.