LIFX Bulb Not Pulling an IP Address from Router

Using LIFX
#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.

1 Like
#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.

#12

I continue to have serious DHCP problems with LIFX vs Ubiquiti. It would not be so serious if LIFX would retry after failing DHCP. The RFC says that the device should keep retrying after getting a 169 address.

When will this serious bug get fixed?

1 Like
#13

Still broken BTW… Please fix this bug

#14

I’m not sure what’s going on with your setup (and I’m sure you’re having an issue). I’d just like to note that I have a full Unifi setup and my LIFX bulbs (all 55 of them) all happily retry and retrieve DHCP addresses, even when I completely change network configuration.

So no doubt something is going on, but I’m not entirely sure it’s all the LIFX bulbs at fault. I’ll also note that I’m running the older stable firmware (4.0.80) because all the test/RC firmwares for the Unifi UAPs have caused connectivity issues. I haven’t updated to the latest stable yet.

If you’re having issues, I’d be really curious to know if downgrading your APs to 4.0.80 helps/resolves the issue.

#15

All of my Gen 3 lights were losing their connection after 2-3 weeks. A power cycle was required to obtain a new IP address. After trying all the other recommendations, I almost gave up on my bulbs. Recently, I moved my LIFX bulbs to their own UniFi VLAN and also enabled mDNS on my controller. All of my lights are renewing their IP addresses now and they’ve been doing that for about a month now.

1 Like
#16

I am also now having this issue, I’ve been trying to find a solution for weeks now. Interestingly it doesn’t seem to be occurring on my Color1000 bulbs, only my A19 and A19+ bulbs.

I use a Unifi USG and a Unifi AP-AC-LR access point.

I have 40 wireless devices connected to the access point, all devices except the LIFX bulbs have a WiFi experience of 95+ and will grab a DHCP address without issue. I have 13 bulbs that are currently having this issue.

I am looking at a list of all my devices and it’s only the LIFX bulbs that are failing to get an address and instead have a 169.254.x.x address.

The firmware on all of my lights is up to date, I have already tried placing the lights into their own vlan, it did not fix my issue.

If anyone has any insight into getting this fixed I would greatly appreciate it.

#17

I have just created a new ssid for my Lifx bulbs and attached that new ssid to a vlan separated from my other IOT devices. (containing only lifx devices)

I’ve also limited the new ssid to only 2.4ghz and I’m reserving the addresses for all of my lifx bulbs.

I have 4 bulbs so far working with this new setup, assuming this stays working i’ll do the same for my remaining bulbs.

It’s kind of ridiculous that I need to baby these devices so much but I’m in so deep now I have no other choice.

#18

Also, there is currently a bug where my android phone is restarting every time I add a new Lifx bulb, as if this process wasn’t already really frustrating.