Author Topic: DHCP issue, probably related to STP loop detection.  (Read 2280 times)

EvilGenius

  • Newbie
  • *
  • Posts: 38
Re: DHCP issue, probably related to STP loop detection.
« Reply #15 on: June 16, 2017, 02:18:23 AM »
Is this supposed to be fixed yet? Seemed to start working with V28, now with the app update received overnight, not working again.  Or was it working previously just a fluke?

jboxtel

  • Administrator
  • Full Member
  • *****
  • Posts: 141
Re: DHCP issue, probably related to STP loop detection.
« Reply #16 on: June 19, 2017, 11:59:49 AM »
It should be working, also with the updated app. Are you on iOS or android?

EvilGenius

  • Newbie
  • *
  • Posts: 38
Re: DHCP issue, probably related to STP loop detection.
« Reply #17 on: June 20, 2017, 03:10:46 PM »
Android, 6.0 on an LG G3.  I'll post up more solid details/screenshots when I get back to work tomorrow.  I haven't tried the beta v29 yet either. 

EvilGenius

  • Newbie
  • *
  • Posts: 38
Re: DHCP issue, probably related to STP loop detection.
« Reply #18 on: June 21, 2017, 07:14:28 AM »
Ok so I've played around with this some more. 


If I plug a cable in and select all the tests and let it run, DHCP fails. 

If after it fails I retry DHCP, it automatically retests link, then DHCP and fails. 

If I unselect all tests and select DHCP only, it then picks up an address and gets details correctly, after which I can then reselect all other tests.


So either something funky is going on, or perhaps the order tests are run in needs to be altered so DHCP is run first?


App says it was updated 14 June, firmware version is v28. 

primoke

  • Newbie
  • *
  • Posts: 1
Re: DHCP issue, probably related to STP loop detection.
« Reply #19 on: November 06, 2017, 11:08:17 AM »
Evilgenius, this workaround is working but...

even at version 29 the issue isn't solved. I just wasted 1 hour because I trusted this device...

please fix this !!!


JP

  • Newbie
  • *
  • Posts: 23
Re: DHCP issue, probably related to STP loop detection.
« Reply #20 on: November 08, 2017, 06:14:01 AM »
In the app, under tools > settings > there is an option for DHCP timeout - have you tried 60sec instead of 10sec?

On Cisco switches where portfast is not enabled (and that's the default unless you change it) it's entirely normal that it takes longer for DHCP to be obtained, as there is a delay before the link even comes up.  This is by design as the switch is checking for listening, learning, forwarding, and possibly network loop detection before enabling the link.  Link is required first, before data can be passed.  DHCP requires data to be passed.

I have noticed a different kind of error in my tests, if Pockethernet asks for a DHCP lease, the DHCP server may not hand it an IP again if another request is made "too soon" - this is common when I go around to different jacks and continually make a DHCP request, the DHCP server already knows the MAC of my Pockethernet and is probably like WTF, why are you requesting an IP again so soon...  I have yet to test more fully if this is a bug, like DHCPRelease message not being sent, or DHCPInform not being supported.  I will get around to it soon.  For more info see: https://technet.microsoft.com/en-us/library/cc958940.aspx

colinskuse

  • Newbie
  • *
  • Posts: 3
Re: DHCP issue, probably related to STP loop detection.
« Reply #21 on: November 22, 2017, 12:52:46 PM »
is there any update on this?

JP

  • Newbie
  • *
  • Posts: 23
Re: DHCP issue, probably related to STP loop detection.
« Reply #22 on: November 27, 2017, 01:35:57 AM »
In working on a completely separate issue I may have discovered a reason/fix why some networks have this problem and others don't...

It seems that some firewalls block ICMP (ping) to either themselves (the default gateway/DHCP server) or to other things on the network (DHCP server, perhaps behind Windows firewall?).  I admit to doing this myself, as disabling ping can be seen as a (albeit not that strong) security measure to prevent certain kinds of attacks/increased CPU on routers/firewalls.

I had a firewall, which also acted as the DHCP server, and was blocking ICMP to itself, what I witnessed is after a device requests a DHCP lease it tries to ping the IP of the server that leased it (the firewall) and when the ping was blocked, the device would not sucesfully get the IP assigned to it.  However, after enabling ICMP inbound to itself, DHCP worked perfectly every time.

In this instance I was working with Belkin Wemo devices and a Zywall USG series firewall, but the problem may be the same in other infrastructure.  I tested my Pockethernet on this network several times and got inconsistent results with subsequent DHCP requests, but after applying the below changes DHCP works every time...

  GUI firewall rule...
If LAN1 to Zywall ALLOW
  CLI (via SSH) commands to add...
enable
configure terminal
no ip dhcp arp_check
write

Perhaps this applies to the problem being discussed in this thread, it solved the issue for me: Wemo devices that would not get an IP after reboot.  (initial DHCP request worked, subsequent ones were hit or miss)