TL-WPA4220KIT and wifi extension problems: wrong ip-range
Region : Sweden
Model : TL-WPA4220
Hardware Version : V1
Firmware Version :
ISP : Telenor
I'm having problems using the TL-WPA4220KIT to extend my existing wifi network. I've tried both the "wi-fi clone" and manual setup way without success. My setup is as follows:
4G Modem/Router (D-link DWR-923) - [Cat6 lan cable] - TL-PA4010 - [electrical wire] - TL-WPA4220
The router is providing IP-addresses to the network (DHCP) in the range 192.168.1.(2 - 155), subnet 255.255.255.0
I've assigned a static IP to the TL-WPA4220 via the DHCP reserve ip functionality (MAC address - IP link) and set it to use the same SSID and encryption method + password as the main router.
If I connect a laptop via cable to the TL-WPA4220 everything works fine; I get internet access and good speeds. But when I try to connect on the wifi-network when I'm in the zone extended by the TL-WPA4220 I do not get internet access ... my iPad and iPhone just shows a spinning "connecting to network" circle and after a while when checking the network details I see that an IP-address in the 169.x.x.x, subnet 255.255.0.0 has been assigned.
It seems like the TL-WPA4220 is not re-distributing the main router's IP-addresses provided by DHCP, but instead picks them from "its own range". How do I fix this (the TL-WPA4220 should be a slave device to the router in all ways [SSID, encryption, DHCP, etc])?
[Bump] Do anyone have any input on this?
Last edited by TomFrost; 02-28-2014 at 11:05.
I've the same problem.
It's weird because there's no DHCP settings on the wpa4220, so it shouldn't be assigning any weird ips right?
Has anyone figure it out?
Maybe you can give a try to set a new SSID for your WPA4220.
May be different from you, but I have two pieces of WPA4220 and among other problems, noticed that they give themselves their own IP even when there is a DHCP server on the LAN.
This results in them giving themselves IPs which were already assigned to other devices on the LAN.
I resorted to giving the two WPA4220 their own static IPs.
It appears that they do not play nice with DHCP servers.
I described this issue with my local TPLINK distributor (asiaradio2000) and while they could not precisely explain how this works, they told me that it is by design. So called "smart DHCP" feature.
WPA4220 will obtain IP address from the DHCP server in the LAN.
The problem that "WPA4220 giving themselves IPs which were already assigned to other devices on the LAN" must be an accident, not a universal problem.
You can just reboot your WPA4220 to try to solve this problem.
Vincent, are you from TPLink?
Can you explain how the Smart DHCP behavior is supposed to function?
Not RFC compliant?
Not according to a tshark located directly between the unit and everything else, specifically looking for port67/68 traffic.
Originally Posted by Vincent
The unit sends a Duplicate Address Detection ARP out, which is normally done *after* compliant devices solicit an IP from a server. This device makes no attempt to solicit an IP and may not be compliant with RFC 2131.
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
0.000018 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Who has 10.2.4.34? Tell 192.168.1.1
0.003049 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Who has 10.2.4.34? Tell 192.168.1.1
0.003061 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Who has 10.2.4.34? Tell 192.168.1.1
0.090070 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 10.2.4.34(Request)
0.090080 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 10.2.4.34(Request)
1.989788 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 10.2.4.34(Request)
1.989800 c0:4a:00:1e:86:04 -> ff:ff:ff:ff:ff:ff ARP Gratuitous ARP for 10.2.4.34(Request)
That's the whole conversation.
Will these devices be brought into line with RFCs via a firmware update?
I've got exactly the same issues with this kit. Tried two of them, in two different networks.
After some weird behaviour during setup, I configured the 4220 as a second AP in my network.
Setup runs fine for less than a day, after that clients connection through wifi stop receiving IP adresses. With a fixed IP or when connecting with a cable everything works as it should
latest firmware is installed. Now in contact with TP-link support to resolve the issue.
Last edited by Vanwegen; 08-15-2014 at 19:44.
I am also having problems with the WPA4220 assigning an IP address like 169.x.x.x to newly connected devices which makes them unable to connect to the internet.
Please post your interaction with TP-Link support.
In the meantime, has anyone tried any 3rd party firmware to see if that would help?
The 169.x.y.z addresses aren't from any range the WPA4220 may have -- Check RFC 5735. It's for link-local auto-config, and it's specifically used when a node CANNOT get an IP of its own (none configured, none offered).
So when you see a 169, it means the node wasn't able to reach a DHCP server.
I may have found a solution to the problem. My DHCP range is 192.168.1.60-192.168.1.253; the first time I set up the WPA4220, I changed the IP to 192.168.1.169. This time I entered the SSID and security settings manually. I left the default IP of 192.168.1.1 on the WPA4220. I also downloaded inSSIDer and looked for the least congested wireless channels. I placed my WPA4220 on channel 1 and my main router on channel 11. It appears to be working, but I'm going to leave it for a few days and see.
Can anyone confirm this? Ensuring the IP of your WPA4220 is outside your main router's DHCP range?
There may be something in this. I moved the IP address of the WPA4220 out of the router's DHCP range and haven't seen the problem recur. I'm leaving it for a few days longer to see if it continues to work, but it's very encouraging.
Update: no - sadly this hasn't helped. A couple of hours after posting the above I started seeing the same problem again. A DHCP lease renewed to a 169.x.x.x address and corresponding lack of connectivity until I assigned a static IP. Good suggestion but it doesn't resolve the issue.
I remember reading something to the tune of "DHCP is disabled by default so you must change the IP of the WPA4220. " So maybe it turns on DHCP behind the scenes if you change the IP, and the DHCP conflicts with your main router's DHCP. Thus maybe it truly only works if you keep the IP at 192.168.1.1. Not sure if anyone can confirm any of this.
Originally Posted by Garwoofoo
A couple of hours after posting the above I started seeing the same problem again
Tags for this Thread