GS110TP - DHCP Issue - Obtaining IP not possible

[harry7922]

Hi everyone,

I have an issue with my GS110TP when trying to obtain an IP from DHCP.
This issue I already dicussed here, but as I noticed it was not already solved. It seems to be an issue of the firmware.

Original Post:

https://community.netgear.com/t5/Smart-Plus-and-Smart-Pro-Managed/GS110TPv3-incompatible-with-Ubiqui...

Again:

I have an AP from Ubiquiti which is connected to the GS110TP and is powered via PoE.

The GS110TP is connected vie Link aggregation trunk to an GS750E and in the GS750E the Ubiquity USG with DHCP server is plugged in.

When I try to obtain a IP with my smartphone, the process stucks at "Obtaining IP". This is because the ethernet packets for requesting an IP ist not forwarded from GS110TP to the trunk. This is what I saw when wiresharking the Ports.

This is only happening for untagged traffic.

I also have a tagged LAN. For the tagged LAN, the DHCP packets are forwarded without issues!

When I just reboot the GS110TP, the DHCP is also working for untagged network for some hours! But at a certain point in time it is still not working.

Last time I resetted the device and thought the issue was gone, but it was not!

Can anyone tell me, how to get support from Netgear professionals for fixing this issue?

Thanks in advance,

Harry

[harry7922]

Hi Everyone,

anyone any idea or support for this topic?

My brother owns a GS110TPPv3 and also a GS750E (connected without LAG). He has other AP fron Ubiquity.

His router with DHCP-Server is directly connected to the GS110TPP (different to my setup)

But he has same issue that at a certain point in time the GS110TPP doesn't forward DHCP requests to the other port(s)!

Can please anyone give me an advice how to proceed?

I proofed via wireshark that this is an issue in netgear firmware!

Thanks and BR

Harry

[schumaku]

The more efficiient way way might be top open a support ticket - reads to me like an odd bug on this device. @YeZ can you bring in somebody near to switch QA to this thread please?

[harry7922]

Thanks for your feedback!

I opened a support ticket for my issue and related to this post.

Thanks and BR

Harry

[Byronlin]

Hi Harry,

Tried to reproduce the behavior by using software packet generator to inject both untagged and tagged DHCP request packets form more than five hours but in vain, not sure if the time is long enough, do you know how long will the behavior presents after reset of reload? And if it is possible to provide untagged and tagged DHCP request packets for further test?
Furthermore, what is the behavior of the device regarding to DHCP offer packets? Will the device withdraw DHCP offer packets?

[Byronlin]

Hi Harry,

Sorry, there was a mistake in my previous post, it should be "DHCP Discover" packets, not "DHCP offer" packets.

In addition, would you please help to provide the information below as well for further analysis?
1. Configuration file of GS110TP.
2. Address-table when the issue presents.
3. MAC address(es) of the Ubiquiti device interface(s) that connected to GS110TP.
4. DHCP configuration of Ubiquiti device, especially pool and lease time.

Thanks for considering my request.

[harry7922]

Hi Byrolin,

thanks for your attention to my issue.

I try to answer your questions - if I forget something, please give me a hint.

Just another important information I detected while actually testing again:

When a new Client, which was not active for a longer time, connects the AP it will get an IP Address!

But on same time, a client which was connected and active to one of the other APs, the device stucks in the loop "Obtaining IP" ... " Disconnected" ... "Obtaining IP" ... "Diconnected" ...

And this is what I have seen in Wireshark, that the DHCP Discover of this device is not forwarded to the correct port from GS110TP.

After I changed (randomized) the MAC of the client which stucked in the loop, the client connects within the next second without any further issues.

So in my opinion, there seems to be something wrong with MAC-cache or something similar - without knowing much how the device is working!

Thanks in advance!

Harry

Following are the informations you requested:

[harry7922]

Dear Byron,

attached you will find all requested Screenshots.

The guest VLAN is tagged with 100 - but it is not often used. Maybe thats why the USG ( fc:ec:da:43:c2:7a ) is not in address list for VLAN100?

On Unifi USG I dont have to define PVID etc. I only define if and which VLAN should be used (tagged) for a "network".

Hopefully you will find the info you expect to get a clear view.

Because I dont know how to upload more than one file (??) except inline of text, please download the screenshots with following link:

http://koepfnet.de/GS110TP_details.zip 

Thanks in advance,

Harry

[Byronlin]

Hi Harry,

Thanks for the prompt response, got all the screenshots and looking on them now.

Will update to you if anything is figured out.

Best Regards

Byron

[Byronlin]

Hi Harry,

Two more questions need your help, what  is the LAG Type of LAG1? And what is Hash Mode of LAG1?

Please help to provid screenshot of page "Switching -> LAG -> Basic -> LAG Configuration".

Thanks for considering my request.

Best Regards

Byron

[harry7922]

Hi Byron,

of course. You will find details in attached screenshot.

LAG Type: LACP

Hashmode: 1 Src/Dest MAC

Because I also thought the LAG could be the reason, I already changed settings without any success.

Just another hint: My brother have similar configuration with an GS110TPP, an other Unifi AP model and the DHCP-Server (no Ubiquity - FritzBox) is directly connected to GS110TPP. And he have same issue!

Thats why I would come to the result, that LAG and Unifi USG will not be the reason for this issue.

Thanks for your help!

BR

Harry

[harry7922]

Just another information I forgot to post.

Because my devices normally are configured for DHCP, the obtaining IP indicates the issue.

Now you can suggest to set static IPs. This I already tested - but also with static IP there is no useful communication possible for affected MAC/client!

So please do not focus on the DHCP offer. Every communication with/from this device is affected!

Thanks and BR

Harry

[Byronlin]

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

[harry7922]

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

[harry7922]

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

[Byronlin]

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

[harry7922]

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

[Byronlin]

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

[Byronlin]

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

[harry7922]

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

[Byronlin]

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. 

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.

[harry7922]

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

[harry7922]

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

[Byronlin]

---

@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

[Byronlin]

---

@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