LIFX Developer Zone

LIFX Bulb Not Pulling an IP Address from Router

#1

Hello fam,

I’m trying to onboard my new LIFX Gen 3 bulbs but I’m stuck at the discovery step.

I’m using a Ubiquiti UAC-AC-PRO Wireless Access Point connected to a Linksys LRT214 business router/gateway. I can see from my WAP that one of my LIFX bulbs is connected to it but it does not have an IP address so when the App tries to discover it, it obviously cannot. I’m not sure why none of my bulbs are able to pull a DHCP address from my router. I’ve tried resetting them, tweaking with my WAP, nothing seems to work here. I’ve even tried binding the LIFX Bulb’s MAC to a Static IP in the router with no resolution. I have a pretty vanilla 192.168.1.1/255.255.255.0 network here, nothing crazy. I’ve seen other people post here who use the same WAP as me so I know that it’s possible to get LIFX working with it. LIFX is making me question my validity as a Systems Administrator and my sanity as a human being. :slight_frown:

I should also note that all of my bulbs are on the latest firmware. (checked with beta desktop firmware updater).

Do you guys have any idea what would cause my issue here? I’ve invested too much time and humanity to turn back now.
-Jackson

EDIT: I’ve run a Wireshark packet capture to see what’s going on with DHCP. I can see that the LIFX bulb is sending a Broadcast DHCP Discover & Request but my DHCP server does not respond or “offer” an address to this request from what I can see so far. I can also see that it’s requesting the static IP address that I entered in the router which means the client (LIFX bulb) is communicating to the DHCP server but is not receiving the requested IP address. I’m going to re-run the check from the router level to verify I’m not missing any transactions or NAK’s from the DHCP server regarding my issue.

#2

I have seen this exact problem as well. I setup and ISC DHCPd server as a 2nd DHCP server on my LAN which the BULBs seem to like. It’s notable that some bulbs worked with the UniFi DHCP and some did not. e.g. the orig LIFX bulbs, the 1000s worked, the +'s and the strips required ISC DHCP (or some other working version) to obtain an address, so there are clearly multiple implementations of DHCP on the bulbs themselves. Also notable able, FWIW, IPv6 DHCP, nor SLAAC seem to be supported and this would be very nice.

#3

We are investigating an issue effecting some models of router where LIFX and LIFX+ lights running the 2.14 firmware aren’t getting assigned an IP address by the DHCP server. We’ll let you know once we have a workaround or complete fix for this problem.

#4

I believe I too am having this problem, occurred as soon as i updated the bulbs which is a big problem since I can’t do anything with them now :confused:

#5

I’m having the same issue with two of my LIFX+ bulbs after installing the Ubiquiti Security Gateway (UniFi USG). All of my LIFX Color 1000, LIFX White 800 and LIFX Z Strips seem to work fine, but not the LIFX+ bulbs. If I physically bypass the gateway, I can connect these bulbs. The LIFX+ bulbs receive an IP address from the gateway, but a ping test shows long response times and dropped packets.

#6

Hi Mark,

Is this issue fixed? I am having regular issues with all of my LIFX Z strips, and now with my brand new Lifx 1000 that you sent as a replacement for an old one.

#7

I recently bought a couple of LIFX 100mm Downlights and haven’t had much success getting them connected to the network. They connect to the Wi-Fi but don’t get an IP address.

I have run the update in the android app as well as the 0.4 macOS LifxFirmwareUpdater and 0.6 macOS LifxBetaFirmwareUpdater and as of this post the lights are all up to date

My network consists of multiple UniFi AP-AC Lite wireless access points connected to a switch which connects to a router provided by our ISP. The router provides dhcp for the network (10.0.0.0/24)

In the UniFi console, I can see the lights connect to the network but they don’t get assigned an IP address.

I observed the DHCP handshake between the lights and the router by inserting a hub between the router and switch and running Wireshark on a PC connected to the hub.

The lights send a discover and the router responds with a offer but there is no request sent from the lights to the router. They just keep spamming discover for a while then stop.

Also, if this DHCP issue isn’t fixed soon, is it possible to set the lights to a static IP address?

The mobile app can sometimes find the lights with their self assigned IP addresses (e.g. 169.254.244.150) but it’s slow and the lights often just disappear in the app then maybe come back a few minutes/hours later. I’m not sure if the poor connection to the lights is due to them having self assigned IPs but the app is pretty much unusable at this stage. Google home is also unable to find the lights at all even when they are visible in the LIFX app which I suspect is due to the self assigned IP addresses.

I checked if connecting the phone and lights to the same access point was any better than having the phone and lights on separate access points but observed no noticeable difference.

Here’s a couple of packets captured from Wireshark of the DHCP handshake:

Frame 199478: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: LifiLabs_27:c7:68 (d0:73:d5:27:c7:68), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 328
    Identification: 0x000b (11)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x799b [validation disabled]
    [Header checksum status: Unverified]
    Source: 0.0.0.0
    Destination: 255.255.255.255
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 68, Dst Port: 67
    Source Port: 68
    Destination Port: 67
    Length: 308
    Checksum: 0xf02c [unverified]
    [Checksum Status: Unverified]
    [Stream index: 36]
Bootstrap Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xa8fa9451
    Seconds elapsed: 4
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: LifiLabs_27:c7:68 (d0:73:d5:27:c7:68)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
        Length: 1
        DHCP: Discover (1)
    Option: (57) Maximum DHCP Message Size
        Length: 2
        Maximum DHCP Message Size: 1500
    Option: (55) Parameter Request List
        Length: 5
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (2) Time Offset
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (69) SMTP Server
    Option: (60) Vendor class identifier
        Length: 5
        Vendor class identifier: EMLAB
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: LifiLabs_27:c7:68 (d0:73:d5:27:c7:68)
    Option: (255) End
        Option End: 255
    Padding: 000000000000000000000000000000000000000000000000...

ffffffffffffd073d527c768080045000148000b00004011799b00000000ffffffff004400430134f02c01010600a8fa94510004000000000000000000000000000000000000d073d527c7680000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000063825363350101390205dc370501020306453c05454d4c41423d0701d073d527c768ff0000000000000000000000000000000000000000000000000000000000



Frame 199479: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Netgear_a0:bc:94 (00:24:b2:a0:bc:94), Dst: LifiLabs_27:c7:68 (d0:73:d5:27:c7:68)
Internet Protocol Version 4, Src: 10.0.0.1, Dst: 10.0.0.191
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 328
    Identification: 0xdead (57005)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0x4638 [validation disabled]
    [Header checksum status: Unverified]
    Source: 10.0.0.1
    Destination: 10.0.0.191
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 67, Dst Port: 68
    Source Port: 67
    Destination Port: 68
    Length: 308
    Checksum: 0xdf56 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 38]
Bootstrap Protocol (Offer)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xa8fa9451
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 0.0.0.0
    Your (client) IP address: 10.0.0.191
    Next server IP address: 10.0.0.1
    Relay agent IP address: 0.0.0.0
    Client MAC address: LifiLabs_27:c7:68 (d0:73:d5:27:c7:68)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Offer)
        Length: 1
        DHCP: Offer (2)
    Option: (1) Subnet Mask
        Length: 4
        Subnet Mask: 255.255.255.0
    Option: (2) Time Offset
        Length: 4
        Time Offset: (0s) 0 seconds
    Option: (3) Router
        Length: 4
        Router: 10.0.0.1
    Option: (23) Default IP Time-to-Live
        Length: 1
        Default IP Time-to-Live: 64
    Option: (51) IP Address Lease Time
        Length: 4
        IP Address Lease Time: (3600s) 1 hour
    Option: (54) DHCP Server Identifier
        Length: 4
        DHCP Server Identifier: 10.0.0.1
    Option: (6) Domain Name Server
        Length: 8
        Domain Name Server: 198.142.152.164
        Domain Name Server: 198.142.152.165
    Option: (255) End
        Option End: 255
    Padding: 00000000000000000000000000

d073d527c7680024b2a0bc94080045000148dead0000801146380a0000010a0000bf004300440134df5602010600a8fa945100000000000000000a0000bf0a00000100000000d073d527c76800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000638253633501020104ffffff0002040000000003040a000001170140330400000e1036040a0000010608c68e98a4c68e98a5ff00000000000000000000000000
#8

Had the same issue with 2 out of 3 lamps when they came out of the box (with my 700-USD-Access Point). Solved it with a hardware reset of the lamps.

#9

It is a HUGE headache to get my LIFX bulbs to reconnect to any router I’ve used in the last few years. If I change routers, the LIFX bulbs will refuse to connect properly to the new router. I have used Netgear R8500, R9000, and now a really nice commercial class MikroTik Router. I am sick of these stupid bulbs refusing to connect. If the dumb LIFX app would let me manually specify an IP address, Subnet and Gateway, this would be so much more simple.

#10

I have a similar issue. Most of my bulbs/strip go in fine (once the restricted channel list was understood), but my new LIFx Minis have been a nightmare. Constantly dropping out, firmware updates requiring many retries, and trying to get the light on the network in the first place is very problematic. Being able to hardwire the settings as a fallback would be at least something.

#11

Just an update to this issue:

I have switched my Linksys LRT router to a Ubiquiti USG, but I’m still using Unifi-AC-AP Pro wireless access points.
I’ve encountered zero issues after switching to the router but I’m not certain if it was switching the router or a firmware update that fixed the problem as I had returned all my lights when I was having issues and re-purchased 15 of them recently.

I’ve noticed way less delay when triggering my lights with these recent firmware updates so big thumbs up to LIFX devs for that.