We have several of the PX750 handhelds running CE 5.x. When we connect them via the charging cradle with a wired USB ethernet NIC on our main office subnet, they obtain a DCHP lease and IP address and connect to our network. When we try to connect in one of our other locations they fail to get a DCHP lease.
We've checked the registry when they fail and the IP information from the main office is stored. We've manually deleted the registry entries but they still won't get an IP address in our other location. We've also tried using ipconfig /release /renew without any luck. We are using a single Windows DCHP server with dhcp relay information configured on our Procurve switches. DHCP snooping is turned off on the switches. Both subnets use the same subnet mask, 255.255.0.0 and are non-routable (10.1.0.0 and 10.3.0.0). We've used the packet capture software on the Psion and it indicates they receive incomplete DCHP packets for the offer missing the end option bytes at the end of the packet.
PCs connecting to the remote sight get DHCP addresses without issue as do our Mitel IP phones. We are using two vlans, one for data and one for the VOIP. The data vlan is untagged.
Has anyone seen this before? We can't seem to find anything different between the two locations nor can we see anything clearly misconfigured.
Thanks.
That's it. When the DHCP fails the packet ends right after our domain name with the final FF missing.
Just tested the clean start from Boost mode and no joy. Registry entries clear for the NIC but it still doesn't get an IP address from DCHP. I'm beginning to suspect our switches are not relaying the packets correctly and may bark up that tree.
Thanks to all for the various suggestions.
Sheetsb,
Thank you for the feedback. And sorry to hear that you are still having difficulties. If I may suggest again, have you tried using a Windows Server in your "remote" location(s) and have it run/ setup as a DHCP Relay Agent server? With it, we may be able to further isolate the problem.
Click here Relay agent configurations
Click here for Configure the DHCP Relay Agent
If problem persist, we may need to review/ inspect the network capture and NEO netlog .cap file(s).
Hope this helps
Thanks,
Luke - Technical Support/ Help Desk
Americas Help Desk
This posting is provided "AS IS". No Warranty. No Guarantee. Maybe updated or changed without notice at any time. You can use the information provided at your own risk.
We haven't tried using a Windows server for DHCP relay. The Procurve switches currently perform that function. DHCP works for all other devices except the Neos. We used the "Teklogix Error Handling Service" to do a Net Log capture. Each time the Neos failed to get a DHCP address, the packetes were one byte short missing the final "end option" hex FF.
At this point I have only two suspects left. We use Quest's QMOE for or MAN connection. The DHCP requests are going across that from our remote sites. There may be some issue there with packet truncation since at the remote site the DHCP packets reaching the Neos are always bad. The only other option is something different about the switch OS. I'm beginning to lean more toward QMOE since the Neos fail from other locations getting DHCP from across it.
sheetsb:
QMOE is a good start, but having the updated firmware for the 3500 swiches is a good start too.
I have not opened Procurve manuals on the DHCP-relay function, but there may be an option you need to turn on for legacy purposes. (Windows NT/2000 and Windows98 DHCP clients is coming to mind.)
Windows CE, unlike Windows 2000(SP4) and Windows XP do DHCP differently. Windows CE dhcp is closer to Windows 98/NT dhcp client behavior. (I could not see it in the below link, please don't turn on anything unecessarily. -sean)
From what I read above, you are using the 8000 series switch as a DCHP Server (Master) and the 3500-24-PEO is acting as a DHCP-Relay (Agent) and the NEO's are the DHCP Clients (Client)
But the NEO's work when they are within the 8000's series network correct? Is there a 3500-24-POE unit as well within the network (not over the MAN) that connects to the 8000 series? And does the NEO get DHCP over that? (If you can and it does then that points to QMOE being bad.)
1)If the NEO does not: For case [8000zl <----> 3500-24-poe <-----> NEO] Then it is the DHCP config within Procurve.
2)If the NEO only does not for case: [8000zl (Quest QMOE) <----> (Quest QMOE) 3500-24-poe <----> NEO] Then it is QMOE.
If you only have case 2) above, but can test for case 1) above, try that first and let us know.
Otherwise, this is going to be not fun.
Check the following: Saying you have no routing for 10.3.x.x, and 10.1.x.x I have to assume is for the separate VLANS 10.3.x.x for Mitel, and 10.1.x.x for Data (untagged default VLAN).
but what about the Remote Switch back to the Core over QMOE? -- Is QMOE just Bridging, or a Routed VPN?
cdn.procurve.com/.../3500-5400-6200-6600-8200-MRG-Mar10-K_14_52.pdf
(Check pp 5-129 -sean)
-sean
Sean M. Kennedy {Americas Help Desk Application Support}
We took the switch out of the equation and used a 2008 virtual machine as DHCP-relay with the same result. Did some capturing and the VM shows the same truncated packets on the problem network. We're still digging.
Hi Sheetsb,
Has the issue been resolved?
We've never found a solution to this. As a result, we had to manually assign IP addresses to the handhelds used at the one location. Other work has made this a low priority issue. Furthermore, my contract here ends next Friday so I won't be able to expend any further effort to resolve it. I'm afraid this will remain a mystery. Thanks to all for the suggestions and help.
You are welcome! If in case you need further help in the future, do not hesitate to contact us.
Cheers!