LAN protocol doesn't seem to match the documentation

[cmoore]

I’ve started playing around with the LAN protocol, and I’m seeing some things that don’t seem to agree with the documentation.

I start by sending out a GetService broadcast, and I get a response:

29 00 00 54 ee 60 70 00 d0 73 d5 10 6c 53 00 00
4c 49 46 58 56 32 00 00 3c 88 e3 15 55 5e 84 14
03 00 00 00 01 7c dd 00 00

The first problem I see is that the documentation says that the target field is supposed to be the MAC address of the target. But it doesn’t match the MAC address on my system.

The second is, the first 8 bytes of the protocol header are reserved, which I assume would mean they’d be zeroes - but they’re not.

And finally, I’m getting two StateService replies. One has a payload of 01 7c dd 00 00, the other is 05 7c dd 00 00. The documentation says the first byte is “service”, and the only defined value is 1 for UDP. What’s the 05?

This is all just with discovery - I’ve seen issues with other packets too, like undocumented types (111, 406).

All this has me wondering - is there a newer version of the documentation than that which is on the web? Or is there maybe something wrong with my firmware version?

[cmoore]

OK, after doing some more digging I think I’ve found the answer to my own question. It looks like the documentation is intentionally incomplete - there are some behaviors that aren’t documented.

Maybe Lifx could add something to that effect to the web page? It would save people like me a lot of time trying to figure out why the behavior isn’t as expected, and it would probably save the Lifx people a lot of time answering the same questions over and over.

[ppelleti]

@cmoore

The first problem I see is that the documentation says that the target field is supposed to be the MAC address of the target. But it doesn’t match the MAC address on my system.

The “target” is always the bulb, no matter which direction the messages are going in. I’m betting that d0:73:d5:10:6c:53 is the MAC address of your bulb.

@cmoore

The second is, the first 8 bytes of the protocol header are reserved, which I assume would mean they’d be zeroes - but they’re not.

No, “reserved” just means that LIFX doesn’t want to document what it means.

@cmoore

And finally, I’m getting two StateService replies. One has a payload of 01 7c dd 00 00, the other is 05 7c dd 00 00. The documentation says the first byte is “service”, and the only defined value is 1 for UDP. What’s the 05?

The 5 is something mysterious which, again, LIFX doesn’t want to document. You’re supposed to just ignore anything which isn’t 1.

@cmoore

This is all just with discovery - I’ve seen issues with other packets too, like undocumented types (111, 406).

There are lots of undocumented messages. However, I’m a little surprised the bulb would be sending them to your application. If you’ve only sent documented requests, then it really shouldn’t be sending you undocumented replies. Can you figure out which requests these messages claim to be in response to?

[agentkt]

I see a lot of 111 and 406 types being sent to my python code as well.

RECV: Message
Size: 38
Origin: 1
Tagged: 0
Protocol: 1024
Source ID: 1380667970
Target MAC Address: d0:73:d5:10:a8:0b
Ack Requested: 0
Response Requested: 0
Seq Num: 0
Message Type: 111
Payload:

Bytes:
[‘0x26’, ‘0x0’, ‘0x0’, ‘0x54’, ‘0x42’, ‘0x52’, ‘0x4b’, ‘0x52’, ‘0xd0’, ‘0x73’, ‘0xd5’, ‘0x10’, ‘0xa8’, ‘0xb’, ‘0x0’, ‘0x0’, ‘0x4c’, ‘0x49’, ‘0x46’, ‘0x58’, ‘0x56’, ‘0x32’, ‘0x0’, ‘0x0’, ‘0x88’, ‘0x13’, ‘0x2d’, ‘0xc5’, ‘0x88’, ‘0x57’, ‘0x8c’, ‘0x14’, ‘0x6f’, ‘0x0’, ‘0x0’, ‘0x0’, ‘0x0’, ‘0x0’]

SourceID matches that of my appliance/server, but I assure you that the only command that I am sending are related to either discovery 101 or modifying the state of the bulb with 117 102.

While this is a big problem, it does annoy me because of excess traffic across the network. There is also the unknown issue if these message contribute to the overall rate limit we should be enforcing within our appliance.

It would be nice to know, if these can be safely ignored.

[florian]

@agentkt while I agree with you that these broadcasts are not nice (in fact I am pushing for a firmware change to avoid them in a future firmware release), for the time being it is safe to ignore them.

[frawau]

Florian, while you are at it, I think it would also be nice to get the light to volunteer StateService messages after they boot. Right now the protocol says you should broadcast a GetService message and get StateService in return, you can then proceed and ask other info from the lamp (or send commands). My Original do broadcast StateLight, Wifi, Firmware… packets 15 secs after being turned on, iIMO it would make more sense to send a StateService and then let the server/app request whatever it needs.

Just my 2 cents

Regards,
François