GS110TP - DHCP Issue - Obtaining IP not possible

Hi Harry,

Roger that! And please allow me to make sure I did not misunderstand you.

According to all your description, thota hqi e current situation is that:

All the BROADCAST PACKETS of UNTAGGED default VLAN 1 from PoE DEVICE powered by GS110TP that applied your configuration, will not be flooded to all untagged default VLAN 1 member interfaces, no matter it is ordinary interface or LAG, after working for some uncertain hours, and the behavior does NOT present on broadcast packets of All THE OTHER VLANs.

Do I understand your description correctly? Please help to provide your comments and correct me if something wrong with my description. 

I will try to reproduce the behavior first based on the scenario I described above, and please help to have some tests below if possible:
* Check if the behavior is still there with default settings.
* Check if the behavior is still there with non-PoE devices.
* Check if the behavior is still there when Ubiquiti AP is powered by power adapter.

Thanks for considering my request.

Best Regards
Byron

Hi Byron,

honestly I can't answer your question clearly.

Since my finding yesterday, that the everything works fine after manipulationg the MAC of the end-user device I don't know if this will not happen to VLAN tagged network. The VLAN tagged network is my guest network and this I normally don't use.

So maybe when my device is connected on another AP which in connected to another switch (not GS110TP*) with the VLAN and the devcice changes his location to the AP which is plugged in to the GS110TP* then I think the situation can also happen to the VLAN tagged network.

Hopefully you understand what I tried to say.

So if your sentence would be like this: 

All the BROADCAST PACKETS (and also other Packets - in case of static IP) of UNTAGGED default VLAN 1 from End-User DEVICE (MAC)  which connects to the AccessPoint and this AccessPoint is plugged in and powered via PoE from GS110TP*, will not be flooded to all untagged default VLAN 1 member interfaces, no matter it is ordinary interface or LAG. , after working for some uncertain hours, and the behavior does NOT present on broadcast packets of All THE OTHER VLANs.

So I think it is important to say again: In my opinion it seems to only happen when a device was quite active on another AP/switch which is not plugged to the GS110TP*. 

So as example, when my end-user device was connected to AP1 and I was working there, and now changing my location to AP2 then I cannot connect because getting no IP from DHCP and with static IP "normal networking" also not working:

AP1 <-> GS705E <==> GS110TP <-> AP2

In attachment you will find the details of network topology. When changing location between the two APs which connected to the GS750E no issue! Only when canging location to the AP connected to the GS110TP I get the issue.

When a end-user device is "new" to the network (tested with an outdated device) and directly connects to the AP on GS110TP everything works fine.

So I strongly suspect some kind of MAC cache or something similar withing the GS110TP.

I'm no networking expert, that's why it can be that I'm not naming the things like you would do.

THANKS

Harry

Sorry, forgot your last points:

* Check if the behavior is still there with default settings.

-> What do you mean with default settings. If need to configure the switch for VLAN etc. Compared to factory settings, I think I was not changing a lot.
* Check if the behavior is still there with non-PoE devices.

-> This I can't actually test, because the AP is mounted outside my house and is really hard to access

* Check if the behavior is still there when Ubiquiti AP is powered by power adapter.

-> Earlier days I also powered the AP with an PoE Injector and not via GS110TP* (was under firmware V7.0.48) and the issue was still there

BR

Harry

Hi Harry,

Thanks for your comments, it's really helpful.

To put it briefly, in the topology as below, end devices connect to AP2 will fail to get IP after roaming to AP1, but the issue will not present if end devices connect to AP directly to AP1, no matter what VLAN the devices located, right?

AP1 -- GS110TP --- Switch2 --- AP2

Now I realized the issue is related wireless roaming. I used wired devices to try to reproduce the behavior, I believe this the reason I cannot reproduce it, I will adjust my test  enviroment with AP roaming involved now.

Best Regards

Byron

Hi Byron,

"end devices connect to AP2 will fail to get IP after roaming to AP1, but the issue will not present if end devices connect to AP directly to AP1, no matter what VLAN the devices located, right?"

-> Yes that's right!

Thanks for further support!

BR

Harry

Hi Harry,

Two more things need your help.

First, in the example you mentioned:

when my end-user device was connected to AP1 and I was working there, and now changing my location to AP2 then I cannot connect because getting no IP from DHCP and with static IP "normal networking" also not working:

AP1 <-> GS705E <==> GS110TP <-> AP2

Will the issue present if the situation is opposite? 

Second, you mentioned your brother encountered the same issue with only single GS110TP, which means the isseu presents in the topology below after devices roaming between AP1 and AP2 as well, right?

AP1 -- GS110TP -- AP2

Thanks for considring my request.

Best Regards

Byron

Hi Harry,

I have tried to reproduce your issue in my place since my last post by setting up a similar environment as below:

Orbi Router -- 0/5 -- GS310TP -- 0/8 --LAN -- 0/1 -- GS110TP -- 0/5 Orbi Satellite

I tried to use Notebook and mobile phones to perform roaming between Orbi router and satellite, and everything was just working fine.
I will keep trying if the behavior can be produced and let you know the result if there is something new.

In the other hand, I was wondering if it is possible that you have another unit of AP or switch of other brands to perform a cross test?

Thanks for considering my request.

Best Regards
Byron

Dear Byron,

thanks for your time, trying to reproduce my issue.

Also a L3 engeneer of Netgear is having a look on it.

First i got this issue I thought this must be the AP. But as I saw that the switch is not forwarding an DHCP discover packet to the other port(s) and the packet look quite fine, I am not sure if the AP is responsible for this.

As I told, when only changing (randomizing) the MAC of the same client which was not able to join the network just a second ago, with the new MAC everything went fine and will have no issues.

This issue seems to come up when the switch is active for more than 1-2 days (a reboot of switch will also fix the issue for this period).

In difference to my brother which will have same issue but just rather (this is nothing I can prove because of slightly different network topology) - I will power down the AP over the night via PoE of switch (with SNMP MIB Power ove Ethernet).

I don't know if this could "speed up" the issue.

I will test if this affects the issue and I will connect the AP to an external PoE Injector instead of using power supply form switch during the weekend.

This test earlier days I already did, but I'm not sure if I restarted the switch - maybe I only changed power supply and saw that the issue was not gone.

Thanks again, I will keep you informed.

BR

Harry

Hi Harry,

Thanks for the update. 

My test environment has been setup for more than a week (setup on 1/27), I will keep trying to check if I can reproduce the issue since I am really curious about the root cause. :smileywink:

By the way, I was wondering if you can check that when the issue presents, Does address table of GS110TP can learn the MAC address of the client which fail to get IP address?  I think this can help to identify if GS110TP received DHCP packets from the client, but did not forward packets to proper interface, or, GS110TP did not even receive packets from the AP, and therefore GS110TP cannot do anything.

Anyway, it's good to hear that somebody is tackling with the issue already, hope the issue can be identify and solve sonn.

Best Regards

Byron.

Hi Byron,

do you mean with:

---

Byronlin wrote:

Does address table of GS110TP can learn the MAC address of the client which fail to get IP address? 

---

That I should check if the MAC of my smartphone (client) is listed in the "switching - address table" when issue occurs, right?

Thanks and BR

Harry

HI Byron,

yesterday I changed power supply of ma AP from PoE of switch to an independent PoE Injector. The PoE of AP-Port  (Port5 in my case) was activated (searching...) during this test.

The AP was working fine. BUT then I powered off the AP for some time (1-2 hours) and after I powered on the switch again (with external PoE injector), I'm actually not able to get an IP!

The MAC of my device is actually already in address table but "learned" on Port l1 (LAG). But AP with which I try to receive an IP is plugged in on Port5.

As I regularly power down the AP over night via PoE MIB of switch, I think the issue is strongly correlated with swiching off and on the AP.

I hope this could help to reproduce the issue.

Thanks again!

Harry

---

harry7922 wrote:

Hi Byron,

 

do you mean with:

---

Byronlin wrote:

Does address table of GS110TP can learn the MAC address of the client which fail to get IP address? 

---

That I should check if the MAC of my smartphone (client) is listed in the "switching - address table" when issue occurs, right?

Thanks and BR

Harry

 

 

---

Hi Harry, 

Yes, that's exactly what I mean.

Best Regards

Byron

---

harry7922 wrote:

HI Byron,

yesterday I changed power supply of ma AP from PoE of switch to an independent PoE Injector. The PoE of AP-Port  (Port5 in my case) was activated (searching...) during this test.

The AP was working fine. BUT then I powered off the AP for some time (1-2 hours) and after I powered on the switch again (with external PoE injector), I'm actually not able to get an IP!

 

As I regularly power down the AP over night via PoE MIB of switch, I think the issue is strongly correlated with swiching off and on the AP.

 

I hope this could help to reproduce the issue.

 

Thanks again!

Harry

---

Hi Harry,

Thanks for the information.

To make sure I do not misunderstand you, do you mean keep turn off/on AP can boost the chances of reproduce the behavior?

If yes, I will try that in my place as well.

---

harry7922 wrote:

 

The MAC of my device is actually already in address table but "learned" on Port l1 (LAG). But AP with which I try to receive an IP is plugged in on Port5.

 

Thanks again!

Harry

---

This is just the root casue of the behavior I guessed.

Since AP did not actually send out packets sent by the roamed device, which means GS110TP did not receive DHCP offer packets from the device, otherwise GS110TP will update the MAC address table, move MAC of the devcei from LAG1 (AP at the other side) to Port 5 ( AP at local), and I think maybe there was something with the AP when it performed wireless connection(authenticaion, association and 4-way handshaking) with the roamed device.

So just like what I mentioned in my last post, you should check MAC address table of GS110TP when the behavior presents again to make sure if my assumption is corrcet.

Thanks for considering my request.

Best Regards

Byron

Hi Byron,

Byronlin wrote:

---

To make sure I do not misunderstand you, do you mean keep turn off/on AP can boost the chances of reproduce the behavior?

Yes, I turned off the AP for round about 2 hours (don't know if the time is relevant) and turned on again. Only after this, the issue occured.

---

Byronlin wrote:

This is just the root casue of the behavior I guessed.

 

Since AP did not actually send out packets sent by the roamed device, which means GS110TP did not receive DHCP offer packets from the device, otherwise GS110TP will update the MAC address table, move MAC of the devcei from LAG1 (AP at the other side) to Port 5 ( AP at local), and I think maybe there was something with the AP when it performed wireless connection(authenticaion, association and 4-way handshaking) with the roamed device.

 

So just like what I mentioned in my last post, you should check MAC address table of GS110TP when the behavior presents again to make sure if my assumption is corrcet.

 

Thanks for considering my request.

 

---

This, I already checked and posted in my last answer, right? Or do I have to check more?

When I get the issue on my device (Loop while trying to obtain an IP), in address table the MAC of the device relates to Port l1 (LAG).

When everything went fine and the issue is not present, in address table the MAC of device is switched to Port 5 (AP at local) after the device successully obtained an IP.

So I think you assumption is right - if I understood you correctly.

BR

Harry

---

harry7922 wrote:

---

This, I already checked and posted in my last answer, right? Or do I have to check more?

When I get the issue on my device (Loop while trying to obtain an IP), in address table the MAC of the device relates to Port l1 (LAG).

 

When everything went fine and the issue is not present, in address table the MAC of device is switched to Port 5 (AP at local) after the device successully obtained an IP.

 

So I think you assumption is right - if I understood you correctly.

 

BR

Harry

 

 

 

---

Hi Harry,

Sorry for my ambiguous words, and you are right.

What I wanted to say in my last post was:

If it is possible, please help to check MAC address table every time the issue presents, if the behavior roamed device fails to get IP happens, will always cause GA110TP failed to learn MAC address of the roamed device simultaneously, then the possibility will be very high that my assumption may be right.

Hope the explanation above can help you to understand my last post.

Best Regards

Byron

Hi everyone,

just few minutes ago I got good news from Netgear Experts. They told that they found the issue and can reproduce it.

They will work on a new firmware release.

So check out for new firmware if you also having trouble.

Thanks again for your support.

BR

Harry

Hi Harry,

Great to hear that!

May I know the detail about the root casue and solution of the issue?

Thank you.

Best Regards

Byron

Dear Byron,

I'm still waiting for release of new firmware - Hopefully netgear will release them shortly.

I asked the Level3 Engeneer about the root cause of this issue - but he also didn't know the reason. So it seems he only managed the communication and some other technical guys (maybe in different location) found and fixed the issue.
If you have Tipps how to get the information from Netgear, please let me know.

Thanks + BR

Harry

Dear Byron, Harry,

I have a   GS110TP with exactly the same issue.  I already have had created support cases and was working extensively with Netgear L2 on this without success.

After a few days of operation, some wireless clients cannot obtain IP addresses via DHCP anymore. 

I tracked the traffic with wireshark and the switch stops forwarding particular DHCP packets. 

After a swtich reboot, everything starts working fine.

I replaced the GS110TP with an Netgear  GS108Ev3 which does not have this issue.

In the meanwhile I have tried two   GS110TP and both show the exact same behaviour. 

I have scheduled an automated reboot via SSH script and the problem is bypassed for now, but the root cause it not solved.

The big difference to the setup from Harry is that I do not power off my WLAN AP's - they are online 24x7..

I severely hope that Netgear will get this fixed and release a new Firmware soon. 
I'm more than happy to test a beta version. 

Best regards

Just for the interested reader and attempting to avoid confusion in the future - you also talk about switches like GS108Tv3 / GS110TPv3 / GS110TPP all operating the same 7.0.6.2 Firmware Version?

I have the issue with the GS110TPP model up to  7.0.6.2.

The issue does not occur with my   GS108Tv2 running on  5.4.2.33.

Hi Harry,

any news about the new firmware?

Best regards

Patrick

harry7922 / P4TR1CK / Byronlin,

Just sharing that Firmware v7.0.6.3 has been released for the GS108Tv3 / GS110TPv3 / GS110TPP switches.  One of the bug fixes included is it fixes an issue where a client device can fail to get a DHCP IP address when there is another network device connected between the switch and the client device.  You can download and to learn more about the other bug fixes, security fixes, warnings and firmware update instructions, please click here.  

Regards,

DaneA

NETGEAR Community Team

Hi,

the new Firmware seem to resolve the DHCP issues I had. 

FInally everything is working as expected.

Thank you!