interesting ...

BUT... DHCP is a standard ;) so it should work with all kind of routers.

anyway ... at least we got some information

@aceos: i am looking forward to your updates!!!

Having the same issue. Its so frekin annoying ...

On top of that, my latency is all over the place. Take for instance the last few minutes ... there were also quite a few 1000+ms entries (not shown below)

Really pretty disappointed in the product.

64 bytes from 192.168.1.1: icmp_seq=1615 ttl=64 time=24.452 ms
64 bytes from 192.168.1.1: icmp_seq=1616 ttl=64 time=209.959 ms
64 bytes from 192.168.1.1: icmp_seq=1617 ttl=64 time=9.616 ms
64 bytes from 192.168.1.1: icmp_seq=1618 ttl=64 time=6.827 ms
64 bytes from 192.168.1.1: icmp_seq=1619 ttl=64 time=156.734 ms
64 bytes from 192.168.1.1: icmp_seq=1620 ttl=64 time=6.791 ms
64 bytes from 192.168.1.1: icmp_seq=1621 ttl=64 time=9.373 ms
64 bytes from 192.168.1.1: icmp_seq=1622 ttl=64 time=27.192 ms
64 bytes from 192.168.1.1: icmp_seq=1623 ttl=64 time=203.042 ms
64 bytes from 192.168.1.1: icmp_seq=1624 ttl=64 time=219.817 ms
64 bytes from 192.168.1.1: icmp_seq=1625 ttl=64 time=209.831 ms
64 bytes from 192.168.1.1: icmp_seq=1626 ttl=64 time=204.043 ms
64 bytes from 192.168.1.1: icmp_seq=1627 ttl=64 time=20.337 ms
64 bytes from 192.168.1.1: icmp_seq=1628 ttl=64 time=4.947 ms
64 bytes from 192.168.1.1: icmp_seq=1629 ttl=64 time=183.438 ms
64 bytes from 192.168.1.1: icmp_seq=1630 ttl=64 time=17.655 ms
64 bytes from 192.168.1.1: icmp_seq=1631 ttl=64 time=183.886 ms
64 bytes from 192.168.1.1: icmp_seq=1632 ttl=64 time=136.463 ms
64 bytes from 192.168.1.1: icmp_seq=1633 ttl=64 time=215.075 ms

HiI was reading this thread and wanted to join the debate. I'm having the same problem with my wpa4220 WIFI. We have a Hp Switch and a windows 2008 R2 as gateway and DHCP and after a while the devices lose the lease and cannot use the Wifi internet. I'm using the latest firmware TL-WPA4220(EU)_V1_140401.I will be following this discussion and I hope to see a solution from TP-Link support. Sadly at the moment, the device is useless.TP-Link, please address this issue!

Summary of facts:
- the WPA4220 is a simple access point; it does not act as a DHCP server
- the WPA4220 uses a non-standard technique to assign itself an IP address; it seems likely this assignment might conflict with an IP address assigned via DHCP to some other device on the local network
- I maintain a network for an apartment building using a main router as a DHCP server, one TL-PA4010, and as many as 5 TL-WPA4220 devices as access points. It has worked well for over about a year.
The WPA4220's are configured with IP addresses which are ouside the range assigned by the DHCP server
- The WPA4220's are hobbled by an inability to access IP endpoints not on the local subnet; they can not be remotely accessed with a browser. Quite a nuisance.
- For the many posters who report problems after a device has apparently attempted to renew a DHCP lease, consider an alternative explanation:
perhaps the WPA4220 has assigned itself an IP address which the DHCP server is attempting to allocate

I am willing to attempt to reproduce the problem, if other posters can provide more details on how they produce consistent failures.

I have a similar issue.
I have a DHCP/DNS server upstairs with my router downstairs.
When using WiFi downstairs, after a period of time I lose internet access due to DNS resolution issues. The only solution is to reboot the TP-Link.

Very frustrating.
I am going to alter the lease time of the DHCP server to see if the problems follows at the new renewal interval.

Update. The WPA4220 has a non standard method of assigning itself an IP address.
Here is my guess as to how it works.
First it monitors the network to which it is connected to determine a possible IP address it might self-assign.
If the "static IP" included as part of its configuration is within range, it starts with that value.
Otherwise it picks some other value (ip address).
In then sends out an ARP request to see if that value is in use:
0.000000 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Who has 10.2.4.34? Tell 192.168.1.1
If it gets no response, it assumes that its selected IP address is available, and uses it.
It then notifies other devices that it is using that IP address:
0.090070 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 10.2.4.34(Request)

What is not clear to me is the following. What happens if at some later point in time,
another device also starts using the WPA4220's IP address?
I assume this might happen if a DHCP server hands out the IP address to a client.
That conflict could explain some of the problems reported in this thread.

My testing has shown that the "static ip" which can be configured on the WPA4220 is not really static;
it is just the starting value in the series of candidate IP addresses the device attempts to self-assign.

This is bloody outrageous TP-Link. What a pathetic company. The thread's been up for more than a year and no fix. This thing cost me more than 100 dollars, I need to reset it every god damn day. It's to do with apple devices i think. My iPhone can't connect but windows laptops can.
Looks like i'm gonna get a refund tomorrow.

I've just purchased a WPA4220 triple kit to "upgrade" from a D-Link double setup. Now of course, my kit at the wrong end of the TP-link equipment don't get IP addresses via DHCP like they used to. So this still appears to be a problem even now. I've looked at the website for firmware upgrades, but they're at the latest level. I wish I'd found this before I bought them. Oh well.

The TL-WPA4220 occasionally starts a DHCP server issuing leases with the TL-WPA4220 as the default route. CLients getting leases from the TL-WPA4220 will no longer route correctly to the internet. There is no clear way to disable this errant service