LIFX Developer Zone

Latest firmware not playing nice with Cisco DHCP


#1

While I have raised a support request for this issue, I am posting here to understand if any of you have had any trouble onboarding GEN3 bulbs (or GEN2 with latest firmware) lately.

I just received a batch of GEN3 bulbs and I can’t onboard them. I use a Cisco router (1800 series) and the bulbs can’t get a DHCP address assigned to them. So I have enabled DHCP debugging on the router and found out that the latest firmware seems to mix up client identifier and hardware address during the DHCP session and this confuses the router, which thinks the requests come from two different clients.
See below for transcript and especially the parts in bold font. This makes impossible for me to onboard these bulbs on my network…
If anybody else is using Cisco routers please chime in… thank you.

Rick

*Nov 25 20:01:23.957: DHCPD: No option 125
*Nov 25 20:01:23.957: DHCPD: Sending notification of DISCOVER:
*Nov 25 20:01:23.957: DHCPD: htype 1 chaddr d073.d520.41b6
*Nov 25 20:01:23.957: DHCPD: remote id 020a0000c0a8a6fe00000000
*Nov 25 20:01:23.957: DHCPD: circuit id 00000000
*Nov 25 20:01:23.957: DHCPD: DHCPDISCOVER received from client d073.d520.41b6 on interface FastEthernet1.
*Nov 25 20:01:23.957: DHCPD: Seeing if there is an internally specified pool class:
*Nov 25 20:01:23.957: DHCPD: htype 1 chaddr d073.d520.41b6
*Nov 25 20:01:23.957: DHCPD: remote id 020a0000c0a8a6fe00000000
*Nov 25 20:01:23.957: DHCPD: circuit id 00000000
*Nov 25 20:01:23.957: DHCPD: Found Manual/Static binding
*Nov 25 20:01:23.957: DHCPD: Sending DHCPOFFER to client d073.d520.41b6 (192.168.166.221).
*Nov 25 20:01:23.957: DHCPD: no option 125
*Nov 25 20:01:23.957: DHCPD: creating ARP entry (192.168.166.221, d073.d520.41b6, vrf default).
*Nov 25 20:01:23.957: DHCPD: unicasting BOOTREPLY to client d073.d520.41b6 (192.168.166.221).
*Nov 25 20:01:23.961: DHCPD: client’s VPN is .
*Nov 25 20:01:23.961: DHCPD: No option 125
*Nov 25 20:01:23.961: DHCPD: DHCPREQUEST received from client 01d0.73d5.2041.b6.
*Nov 25 20:01:23.961: DHCPD: requested address 192.168.166.221 belongs to some other client.
*Nov 25 20:01:23.961: DHCPD: Sending notification of ASSIGNMENT FAILURE:
*Nov 25 20:01:23.961: DHCPD: htype 1 chaddr d073.d520.41b6
*Nov 25 20:01:23.961: DHCPD: remote id 020a0000c0a8a6fe00000000
*Nov 25 20:01:23.961: DHCPD: circuit id 00000000
*Nov 25 20:01:23.961: DHCPD: Sending notification of ASSIGNMENT_FAILURE:
*Nov 25 20:01:23.961: DHCPD: due to: Reason with no text explanation
*Nov 25 20:01:23.961: DHCPD: htype 1 chaddr d073.d520.41b6
*Nov 25 20:01:23.961: DHCPD: remote id 020a0000c0a8a6fe00000000
*Nov 25 20:01:23.961: DHCPD: circuit id 00000000
*Nov 25 20:01:23.961: DHCPD: Sending DHCPNAK to client 01d0.73d5.2041.b6.
*Nov 25 20:01:23.961: DHCPD: no option 125
*Nov 25 20:01:23.961: DHCPD: broadcasting BOOTREPLY to client d073.d520.41b6.


#2

I just picked up two gen 3 bulbs from best buy and am having a similar issue. I have an SG300 switch in layer 3 mode. My IoT things are on a separate VLAN, the switch is providing DHCP. Using wireshark I see DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPNAK. This is followed by repeated request/nak conversations. The bulb eventually gives up and I get the standard failure to onboard error in the iOS app. I’m just learning this switch, so I don’t know how to debug DHCP, but the NAK packet itself doesn’t give any reason for the failure. I can see in the address bindings on the switch that the offered IP address does appear briefly, then gets removed when the bulb gives up.


#3

I guess you are hitting the same bug.
In the meantime I have moved the DHCP server from the Cisco to my main AP and the problem doesn’t show up there, my guess is that Cisco DHCP server is more “strict” than the other.
This is nonetheless a serious problem and hope to see it fixed soon.
It affects GEN2 with latest firmware as well (as the bug is in the firmware not in the hardware).

Rick


#4

So this was really annoying me. I was staring at the wireshark capture for way too long, I didn’t notice the client ID changing between discover and request, so that didn’t seem to be be quite the same issue. Then I decided to just fake it and added static host bindings to the dchp server on the switch. Suddenly everything worked perfectly, my two lights are working with the iOS app and with the echo. Really annoying, and certainly not what I would expect my parents to try and figure out. Of course, they just have a single AP/router/modem from comcast, so they’d probably never see this problem.


#5

So Just a small update on this. I’ve brought my cisco play around equipment in from home for us to set up for a short period in the office. (3650-cg and a cisco 3502) and will be borrowing another piece from a friend later this week. Once we have these up and running we will try and replicate and resolve this bug.

Sorry for the trouble we hope to have an answer for you soon.


#6

Hi Kevin, I am now using my main AP DHCP server instead of router’s, so it’s not bugging me anymore, but yes please check into the issue as it will probably affect many other users.


#7

Cool, thanks. I can send you the pcap file if you need it. Just let me know.

Michael


#8

How did you configure the static host bindings? I’m seeing a request for d073.d520.7113 then another for 01d0.73d5.2071.13. Ordinarily I configure static bindings like this:

ip dhcp pool LIFX
host 10.1.1.75 255.255.255.0
client-identifier d073.d520.7113

With the above configured, I see this in my debug:

330603: Dec 3 00:18:19.267: DHCPD: Sending notification of DISCOVER:
330604: Dec 3 00:18:19.267: DHCPD: htype 1 chaddr d073.d520.7113
330605: Dec 3 00:18:19.267: DHCPD: interface = Vlan1
330606: Dec 3 00:18:19.267: DHCPD: out_vlan_id 0
330607: Dec 3 00:18:19.267: DHCPD: DHCPDISCOVER received from client d073.d520.7113 on interface Vlan1.
330608: Dec 3 00:18:19.267: DHCPD: using received relay info.
330609: Dec 3 00:18:19.267: DHCPD: Sending notification of DISCOVER:
330610: Dec 3 00:18:19.267: DHCPD: htype 1 chaddr d073.d520.7113
330611: Dec 3 00:18:19.267: DHCPD: interface = Vlan1
330612: Dec 3 00:18:19.267: DHCPD: out_vlan_id 0
330613: Dec 3 00:18:19.267: DHCPD: DHCPOFFER notify setup address 10.1.1.75 mask 255.255.255.0
330614: Dec 3 00:18:19.267: DHCPD: Sending DHCPOFFER to client d073.d520.7113 (10.1.1.75).
330615: Dec 3 00:18:19.267: DHCPD: no option 125
330616: Dec 3 00:18:19.267: DHCPD: creating ARP entry (10.1.1.75, d073.d520.7113).
330617: Dec 3 00:18:19.267: DHCPD: unicasting BOOTREPLY to client d073.d520.7113 (10.1.1.75).
330618: Dec 3 00:18:19.275: DHCPD: Reload workspace interface Vlan1 tableid 0.
330619: Dec 3 00:18:19.275: DHCPD: tableid for 10.1.1.225 on Vlan1 is 0
330620: Dec 3 00:18:19.275: DHCPD: client’s VPN is .
330621: Dec 3 00:18:19.275: DHCPD: DHCPREQUEST received from client 01d0.73d5.2071.13.
330622: Dec 3 00:18:19.275: DHCPD: requested address 10.1.1.75 belongs to some other client.
330623: Dec 3 00:18:19.275: DHCPD: Sending notification of ASSIGNMENT FAILURE:
330624: Dec 3 00:18:19.275: DHCPD: htype 1 chaddr d073.d520.7113
330625: Dec 3 00:18:19.275: DHCPD: remote id 020a00000a0101e101000000
330626: Dec 3 00:18:19.275: DHCPD: interface = Vlan1
330627: Dec 3 00:18:19.275: DHCPD: class id 454d4c4142
330628: Dec 3 00:18:19.275: DHCPD: out_vlan_id 0
330629: Dec 3 00:18:19.275: DHCPD: Sending notification of ASSIGNMENT_FAILURE:


#9

I used the MAC address, not the client identifier. I don’t even see a client identifier in any of my DHCP packets, so I don’t know where that came from. My symptoms were the same as yours though, request then NAK.


#10

I tried setting it this way:

ip dhcp pool LIFX
host 10.1.1.75 255.255.255.0
hardware-address d073.d520.7113

but I have the same issue. The DHCPDISCOVER ID comes in as d073.d520.7113 but the DHCPREQUEST comes in as 01d0.73d5.2071.13. The switch complains that the requested address belongs to another client.


#11

I’m having the same issue. I’ve tried both hardware-address and client-identifier with static bindings and neither is successful. AP shows it is associated, but no IP address associated with that MAC and similar DHCP assignment failure errors. Willing to help provide additional logs or pcaps if needed.


#12

I used the GUI on the sg-300 switch, haven’t even learned the CLI yet.
Is your DHCP server on the router?


#13

Hmm, OK. My DHCP is on a Catalyst 3750. I don’t have the option of using the GUI. I believe LIFX will have to update there product for me to get it to work.


#14

I make no claims to being a network engineer, but looking through some cisco docs, what would this do?
hardware-address d073.d520.7113 ethernet
or
hardware-address d073.d520.7113 ieee802

Just wondering,

Michael


#15

I am not sure what the difference is there. The Cisco command reference doesn’t really explain it other then to say “If no type is specified, the default protocol is Ethernet.” I can try ieee802 tonight to see if that helps.


#16

I tried ieee802 and it made no difference. The problem is that the LIFX bulb is switching between hardware-address (MAC) and client-identifier formats mid-request so Cisco’s IOS DHCP server sees these as two different clients. The RFC states that the same parameters should be used throughout the transaction and the LIFX bulb is changing the parameters used.


#17

Correct, this is exactly the problem. Using less picky DHCPD servers will work (I switched to the AP’s as a workaround)


#18

I switched to windows DHCP (which took forever because of all the DHCP reservations I have) and that did fix the issue.


#19

Has there been any update on this issue? I’m having the same problem. I have a bunch of Gen 1 and Gen 2 lights that work great, but the latest BR30 versions won’t get an address from my ASA5505.


#20

Just a small update to this. We are working on putting together a bug report with the details of this issue.

If you can assist by sending us a packet capture of the dhcp transaction that would be appreciated.

thanks