@Sunshine 

 

Hi all,

Since I first reported this, I’ve done a bit more investigation. It looks like the issue is with the WiFi side of the WPA4220 – I think the android devices struggle with this more than the other devices, but the issue is not restricted to Android, as I’d first thought.

My setup is pretty conventional. A single WPA4220 connects to a PA4010, in turn connected to a Virgin SuperHub 3 router. The SuperHub also supports a TP-Link WA801 Access Point. The WPA4220 is fixed to channel 1, the SuperHub to channel 6, and the WA801 to channel 11.

The powerline devices are plugged directly into wall sockets. tpPLC reports the link between the WPA4220 and its hub as running at 219 Mbps

I have a Windows PC physically connected to the WPA4220. This PC shows an Ookla speed test data rate of around 70Mb/s, so all the physical infrastructure is working normally.

I have turned the DHCP server off on the WPA4220 as I don’t understand why it is required in my configuration – surely the SuperHub should be the sole responder to DHCP requests?

The current symptoms are as follows. After I powercycle the WPA4220, wireless connection attempts work fine. After a few minutes, connection attempts start to fail – Android reports “failed to obtain IP address”, Windows connects but reports “Connected, no internet”. I can disconnect a normally working device, and it will immediately fail to reconnect with these symptoms.

Ping times over WiFi between a Windows PC and the WPA4220 show times of 1-2ms over 50 pings, with no packet loss. However, if I run a speed test under these circumstances, rates are down to 10 Mbs.

These issues do appear to be DHCP-related, and only appeared after the upgrade to release 36351. Was this the release which introduced a DHCP server to the WPA4220? However, enabling the DHCP server on the WPA4220 doesn’t resolve these issues.

Sorry about the length of this. I’ve tried to keep it as short as possible.

Any ideas for what I try next?

  @Sunshine

 

Hi. Thank you so much for all your help with this issue. To answer your questions first:

I took a spare WPA4220 which had previously worked reliably, and upgraded it from Rel 43406 to Rel 36351. I reset it to factory settings, and changed just the SSID and password. It showed the same intermittent symptoms as the other WPA4220 – android devices failed to get an IP address, Windows devices showed “Connected, no internet”. I then reverted it back to Rel 43406 and it worked fine.

When my Windows PC is “Connected, no internet” then it will not successfully ping the router – but it does have an IP address, unlike the Android devices.

The lights are always on and green on both the hub and AP. As I said previously, there are several PCs hard-wired to the WPA4220 – these show no issues with connectivity or performance. They show up to 75 Mbs on an internet speed test, and support 80GB of network backup every night. I only see the issues with wireless.

I have had a more detailed look at this issue with wireshark + AWUS036NHA. Here are two decrypted 802.11 level dumps of my motorola phone associating with the AP, and requesting an IP address. The first succeeds, whilst in the second the DHCP Discover fails to receive an DHCP Offer so the DHCP Discover is repeated, but without success, and so eventually times out.

 

I wanted to see whether the DHCP messages get through to the Virgin router, and whether they are properly responded to, so I put an ethernet hub between the Powerline hub and the router and had a look. The following images show a successful DHCP registration, followed by a failure. You can see in the second image, the Virgin router is receiving repeat DHCP Discover requests to which it is responding correctly with DHCP Offers, but these appear not to be passed through to the requesting client.

 

 

I'm not a network engineer, so am not qualified to do any more detailed analysis. But it looks like this issue is software related, has been introduced in release 36351, and is related to the way in which the WPA4220 handles DHCP requests. I'd be surprised if it's not been reported elsewhere. Is it time to pass it back up to TP-Link internally?

 

Thanks again for your help...

 

First of all, please make sure the DHCP server function in the WPA4220 is disabled, such that the main router has control over everybody's IPv4 addresses. (Do not set this to "Auto" ... this means it will disable when the main router's DHCP server is detected - but if the router is gone for a moment, this will reenable and henceforth screw everything up.)

  @PeterM. 

 

From my first post, "After the upgrade I turned Smart DHCP off." But yes, you are quite right that leaving Smart DHCP enabled wouldn't be helping resolve this issue.

 

But even so, Smart DHCP doesn't really explain these symptoms - that the extender passes a DHCP Discover through to my main router, but doesn't return the response to the client.

 

Still expecting that TP-Link will respond...