DHCP issue, probably related to STP loop detection.

[EvilGenius]

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]

It should be working, also with the updated app. Are you on iOS or android?

[EvilGenius]

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]

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]

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]

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]

is there any update on this?

[JP]

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)

[kd5snu]

I can also attest to the DHCP issue with a Cisco switch and Firmware 29. Nice to have found a workaround, but still a little frustrating. I'm not too surprised, given that even plugging a normal device into this Cisco switch takes quite awhile to come up.

[JRBlood]

I did some packet-sniffing on my Pockethernet and I've found the cause of the issue.

The tl;dr: With Outgoing VLAN Tag selected, the Pockethernet inserts a request on VLAN1, which some routers and/or switches won't accept and will drop the packet.

Brand-new device, running HW v6 FW v29, App version 2.8a

If you select just Link and DHCP, you get an IP.
If you select just Link, Outgoing VLAN Tag, and DHCP, you don't get an IP.

I captured this with a SonicWALL using the built-in Packet Monitor. This first one is when we were able to get an IP:
Ethernet Header
 Ether Type: IP(0x800), Src=[28:fd:80:xx:xx:xx], Dst=[ff:ff:ff:ff:ff:ff]
IP Packet Header
 IP Type: UDP(0x11), Src=[0.0.0.0], Dst=[255.255.255.255]
UDP Packet Header
 Src=[68], Dst=[67], Checksum=0xcf, Message Length=316 bytes
Application Header
 BOOTP:
Value:[0]
Received 0:4294967

Now this time I selected "Outgoing VLAN Tag". Notice the VLAN ID added to the header, and the SonicWALL adding why it was dropped:

Ethernet Header
 Ether Type: VLAN ID = 1, Priority = 0
 Ether Type: IP(0x800), Src=[28:fd:80:xx:xx:xx], Dst=[ff:ff:ff:ff:ff:ff]
IP Packet Header
 IP Type: UDP(0x11), Src=[0.0.0.0], Dst=[255.255.255.255]
UDP Packet Header
 Src=[68], Dst=[67], Checksum=0xca9e, Message Length=316 bytes
Application Header
 BOOTP:
Value:[0]
DROPPED, Drop Code: 3(Packet on invalid vlan), Module Id: 16(fwCore), (Ref.Id: _1704_kprwvJqqm) 0:0)


I'll post more as I discover things.

[Hotcooler]

Preliminary results seem to indicate that DHCP have been fixed on Cisco with HW v5  FW v30 and 3.0a. I assume it'll also be fine on Dlink loop detect and all the other switches we have. Will report back in a week or so.

Hooray. In only took ~1.5 years lol.

In any case appreciate the work. Despite occasional shortcomings and glitches (like I pretty much never used actual TDR since it would fail more often then not (in actual in the wild Russian networks that are crammed into 50 year old buildings that were designed at best with the fact that there will be one telephone pair per apartment ) and just learned to read the graphs very precisely) it is still probably one of the best tools to have.