DHCP relay problem
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
DHCP relay problem
Region : Australia
Model : TL-WA5210G
Hardware Version : V1
Firmware Version : 4.4.5 Build 111209 Rel.40972n
ISP : Ourselves
Hi all.
I am having a problem getting DHCP information to clients connected behind a TL-WA5210G (also the TL-WA5110G).
I work at a small ISP on a small island who offers pre-paid internet to visiting tourists.
They connect to the island wide network which gives them a DHCP number from our server, which gives them access to our login page, and after logging in with the pre-paid access card, they have full internet access.
This system has been running very well for 10 years now, and contains a vast mix of radios as radios have been added or replaced over the life time.
Basic info,
* running a dhcp server on a CentOS server in the office.
* Picostation2 HP radio on the roof transmitting a signal NIDS (doesn't matter what this radio is, I have tried with a TL-WA5210G as well, same results)
* Have many client radio's set up as bridges and/or WDS links to spread the signal around the island.
* All radios apart from the TP-Link ones TL-WA5210G and TL-WA5110G are getting the DHCP information to the connected clients just fine.
* All other radios (vast mix, Dlink 900+'s, Sputnik's, Asus 520GL's, other ubiquiti/pico radios, Engenius 1650's and 3220's) get the DHCP information through to the client in about 1 or 2 seconds.
* Any client connecting via TP-Link is taking around 45 seconds to get the DHCP information from our server. It does not matter whether the TPLink is set as a wireless client and the PC is cabled into the LAN side, or the TP-Link is set as a universal repeater and the client connects wirelessly, or the TP-Link is a WDS link and the client connects wirelessly.
* The fact it is taking so long has become a real problem particular for Apple users. I have noticed that Windows computers will continue to try and get the DHCP number, and it succeeds after around 45 seconds. However the Apple products only seem to allow a very short window, perhaps 4 seconds, to get the DHCP request. Since the TP-Link radio's are taking far longer, the Apple computers are not connecting. They do connect fine through every other radio type we have in use.
Some work better with pictures, so heres an attempt:
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- TL-WA5210G ---(wireless or ethernet)--- Client taking 45 seconds to get DHCP information. Client times out. If windows, keeps trying and eventually gets the DHCP number. If Apple, gives up and fails to get DHCP.
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- TL-WA5110G ---(wireless or ethernet)--- Client taking 45 seconds to get DHCP information. Client times out. If windows, keeps trying and eventually gets the DHCP number. If Apple, gives up and fails to get DHCP.
I have even gone to far as to try:
[CentOS DHCP server] ---(ethernet)--- TL-WA5210G ---(wireless)--- Client taking 45 seconds to get DHCP information. Client times out. If windows, keeps trying and eventually gets the DHCP number. If Apple, gives up and fails to get DHCP.
However I get these results using any other brand of radio that we have in use:
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- EOC-1650 ---(wireless or ethernet)--- Client takes about 2 seconds to get DHCP information, works fine
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- Dlink 900AP+ ---(wireless or ethernet)--- Client takes about 2 seconds to get DHCP information, works fine
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- Asus 520GL ---(wireless or ethernet)--- Client takes about 2 seconds to get DHCP information, works fine
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- Sputnik ---(wireless or ethernet)--- Client takes about 2 seconds to get DHCP information, works fine.
I suspect it is something in the firmware of the radio myself, I wonder if installing DD-WRT or similar might help this problem, but yeah it's becoming a real problem and would like to try other possible solutions before taking it that far.
Long and the short is WA5210G and WA5110G are taking far to long to relay DHCP information from back end server to connected clients.
Any help much appreciated, this problem has been driving me nuts.
As long as the connection behind the TP-link DOESN'T need a DHCP number from our backend server, they work perfectly. Unfortunately we require that they DO get the DHCP information from our backend server.
Model : TL-WA5210G
Hardware Version : V1
Firmware Version : 4.4.5 Build 111209 Rel.40972n
ISP : Ourselves
Hi all.
I am having a problem getting DHCP information to clients connected behind a TL-WA5210G (also the TL-WA5110G).
I work at a small ISP on a small island who offers pre-paid internet to visiting tourists.
They connect to the island wide network which gives them a DHCP number from our server, which gives them access to our login page, and after logging in with the pre-paid access card, they have full internet access.
This system has been running very well for 10 years now, and contains a vast mix of radios as radios have been added or replaced over the life time.
Basic info,
* running a dhcp server on a CentOS server in the office.
* Picostation2 HP radio on the roof transmitting a signal NIDS (doesn't matter what this radio is, I have tried with a TL-WA5210G as well, same results)
* Have many client radio's set up as bridges and/or WDS links to spread the signal around the island.
* All radios apart from the TP-Link ones TL-WA5210G and TL-WA5110G are getting the DHCP information to the connected clients just fine.
* All other radios (vast mix, Dlink 900+'s, Sputnik's, Asus 520GL's, other ubiquiti/pico radios, Engenius 1650's and 3220's) get the DHCP information through to the client in about 1 or 2 seconds.
* Any client connecting via TP-Link is taking around 45 seconds to get the DHCP information from our server. It does not matter whether the TPLink is set as a wireless client and the PC is cabled into the LAN side, or the TP-Link is set as a universal repeater and the client connects wirelessly, or the TP-Link is a WDS link and the client connects wirelessly.
* The fact it is taking so long has become a real problem particular for Apple users. I have noticed that Windows computers will continue to try and get the DHCP number, and it succeeds after around 45 seconds. However the Apple products only seem to allow a very short window, perhaps 4 seconds, to get the DHCP request. Since the TP-Link radio's are taking far longer, the Apple computers are not connecting. They do connect fine through every other radio type we have in use.
Some work better with pictures, so heres an attempt:
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- TL-WA5210G ---(wireless or ethernet)--- Client taking 45 seconds to get DHCP information. Client times out. If windows, keeps trying and eventually gets the DHCP number. If Apple, gives up and fails to get DHCP.
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- TL-WA5110G ---(wireless or ethernet)--- Client taking 45 seconds to get DHCP information. Client times out. If windows, keeps trying and eventually gets the DHCP number. If Apple, gives up and fails to get DHCP.
I have even gone to far as to try:
[CentOS DHCP server] ---(ethernet)--- TL-WA5210G ---(wireless)--- Client taking 45 seconds to get DHCP information. Client times out. If windows, keeps trying and eventually gets the DHCP number. If Apple, gives up and fails to get DHCP.
However I get these results using any other brand of radio that we have in use:
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- EOC-1650 ---(wireless or ethernet)--- Client takes about 2 seconds to get DHCP information, works fine
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- Dlink 900AP+ ---(wireless or ethernet)--- Client takes about 2 seconds to get DHCP information, works fine
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- Asus 520GL ---(wireless or ethernet)--- Client takes about 2 seconds to get DHCP information, works fine
[CentOS DHCP server] ---(ethernet)--- Pico2HP ---(wireless)--- Sputnik ---(wireless or ethernet)--- Client takes about 2 seconds to get DHCP information, works fine.
I suspect it is something in the firmware of the radio myself, I wonder if installing DD-WRT or similar might help this problem, but yeah it's becoming a real problem and would like to try other possible solutions before taking it that far.
Long and the short is WA5210G and WA5110G are taking far to long to relay DHCP information from back end server to connected clients.
Any help much appreciated, this problem has been driving me nuts.
As long as the connection behind the TP-link DOESN'T need a DHCP number from our backend server, they work perfectly. Unfortunately we require that they DO get the DHCP information from our backend server.