TL;DR: during the RENEWING state of DHCP, openspot fails to use correct UDP source port of 68 [*] for the DHCPREQUEST, causing eventual loss of the lease and starting over from scratch again with a new address.

The long version:

I normally run my openspot in my vehicle, with a lease time of 8 hours and the mac address mapped to a consistent IP address in the router (commonly known as dhcp reservation mode for windows admins, or manual allocation in RFC2131), so I didn't run into this problem until recently.

Since Wednesday of last week, I've been working on writing some software using the HTTP/JSON API at my desk at work, and I have been increasingly frustrated with the constantly changing IP address of the openspot. The work network has a DHCP lease time of 1 hour due to the rapid turnover in client devices. The firewall is a Cisco ASA5505, so setting a reservation or manual allocation isn't possible. We've been using Cisco ASA equipment for over a decade, and are very comfortable with it working "correctly", so I immediately suspected the problem must be with the openspot, since ALL other clients successfully renew their leases within the hour timeframe, and don't change IP addresses constantly throughout the day.

I hooked up a network hub and fired up wireshark and started packet capturing all DHCP traffic for the openspot's mac address on udp ports 67 and 68, the BOOTP/DHCP ports. [capture filter: ether host fe:28:65:xx:xx:xx and (port 67 or port 68)]

I observed the initial correct DHCPDISCOVER from the openspot to broadcast, followed by a DHCPOFFER from the ASA to the openspot, then the correct DHCPREQUEST from the openspot to the ASA, then the DHCPACK from the ASA to the openspot. So far, so good. This completes the SELECTING state in DHCP parlance.

About 30 minutes later (the renewal time), the DHCP RENEWING state begins. The openspot initiates a DHCPREQUEST with the same xid (transaction ID) to the ASA via unicast. The ASA ignores the request (typical cisco behavior when something is considered out of spec). This repeats 5 more times following the recommended retry process in the RFC.

Having failed the RENEWING state, next comes the REBINDING state, and the openspot falls back to a DHCPREQUEST with the same xid to the broadcast address. After about 450 seconds, the process has failed. The openspot does what it should having not been allowed to keep it's IP address, and starts the process over again with a DHCPDISCOVER with a new xid, receiving a DHCPOFFER, doing a DHCPREQUEST, and receiving a DHCPACK for the new IP address.

At first glance, it appeared the openspot was doing everything according to spec, and the ASA was ignoring the renewal request for some unfathomable reason.

So, I grabbed another IP device (Apple TV for the record) and started a packet capture for its MAC address and udp ports 67 and 68. I saw the DHCPDISCOVER/DHCPOFFER/DHCPREQUEST/DHCPACK process succeed, then about 30 minutes later, it initiated a DHCPREQUEST to the ASA and immediately received a DHCPACK from the ASA.

So, I have been focusing in on the differences between those two DHCPREQUESTs. I've only noticed one thing which could be the cause of this issue: All client DHCP/BOOTP messages are supposed to come FROM udp port 68 to udp port 67 [*]. The failing DHCPREQUEST that is ignored by the ASA comes from udp port 0 to udp port 67. All server DHCP/BOOTP messages are supposed to be from udp port 67 to udp port 68.

There's a lot more details available, and I have the packet captures for both the working client and the non-working client available should you need them to see for yourself.

Jim

[*] I've read through these RFC's until I'm cross-eyed, and haven't found the relevant part that requires the use of UDP port 68 for the source port, but it's the only significant difference between the device that gets its renewal and the one that doesn't.