Lan Protocol: What's going on with these ADwin messages my bulbs are broadcasting?

I’ve reworked @dotMorten’s LifxNet (
I’ve created unit tests that test all of the messages in the API. I’m seeing problems with high speed traffic, Although I’m abiding by the 20 messages per second speed limit, I’m seeing that I cannot count on receiving responses in high traffic situations… Although I’m requesting a response, I’m not always getting them. HOWEVER, in the situation where I’m not receiving responses, in Wireshark I can see that the bulbs are BROADCASTING responses. Many of them of the same response type that I’m expecting. > : Source=000000B4, Sequence=B4 : LifxNet.LightSetColorPacket > : Source=000000C0, Sequence=C0 : LifxNet.LightSetColorPacket > : Source=000000BA, Sequence=BA : LifxNet.LightSetColorPacket > : Source=000000BB, Sequence=BB : LifxNet.LightSetColorPacket < : ***Source=CABD6E86, Sequence=BA : LifxNet.LightStateResponse***MacAddress=D0:73:D5:11:43:82 > Source=000000BE, Sequence=BE : LifxNet.LightSetColorPacket > : Source=000000BD, Sequence=BD : LifxNet.LightSetColorPacket > Source=000000BF, Sequence=BF : LifxNet.LightSetColorPacket > : Source=000000C1, Sequence=C1 : LifxNet.LightSetColorPacket

What’s going on here?
Thanks in advance,

Oh, I can get you some Wireshark captures if you need them.

Hi @emorrison1962
Do you mind logging an issue in the github repo so we can attack it there (preferably with a repro sample)?

Btw would love to see a pull request with your unit tests :slight_smile:

I’ve made significant changes to the code, and I’m certain it’s not a code issue.
You can find my latest changes here:
Disregard the Mvc stuff and focus on the services and the unit tests.
This code will definitely break yours, although I’ve made changes that I’m sure you’d find beneficial.
Refactoring the packets and responses to derive from base classes.
Implemented any remaining packet and response types not implemented in LifxNet.
Encapsulated packet and response serialization to their respective classes.
Encapsulated the ResponseRequired and AcknowledgeRequired toggle-ability.
Automatic updation of the Sequence field.
Decoupled packets/responses from the Udp service. (Although I haven’t implemented an IUdpService interface yet.)
Unit tests test all packet types.

Lemme know what you think, and if you’d like to collaborate on this.
Thanks in advance,

Oh, and by the way, all I have to do is run the unit tests to see the problem in my environment.

Occasionally the bulb might miss a packet because it is busy responding to a packet from another source such as another device or the LIFX Cloud. If its receive buffer is full when the packet arrives it has no choice but to drop it. This is why we have responses, acknowledgments and sequence numbers. If you don’t see a response with a matching sequence number and source in the time you expect you can retransmit your packet.

Those broadcast packets are responses to messages that we sent from the LIFX Cloud. Responses to queries from the LIFX Cloud are broadcast for backwards compatibility reasons (though we are planning the deprecation of this).

How do I disconnect from the cloud? I want to try and verify that these ADWIN packets are the problem.

This statement concerns me.

Also, what’s an ADwin message?

LOL. Well I’m fairly certain that it’s not in my code.
I had to refactor LifxNet because it’s a PCL, and won’t work with .Net 4.6 applications. Specifically, it relies on the Windows.Networking classes.

ADWIN protocol:

Can you perform a limited test using the original lib? And what happens if you reduce the number of packets to something like 10/sec?

Oh right, that’ll just be Wireshark mis-classifying packets. I recall there was a LIFX protocol for Wireshark somewhere, but it hadn’t been updated since before the 2.0 firmware/docs last time I checked.

In the LIFX application choose the bulb you want to disconnect, go into the ‘Edit’ dialog (by clicking the cog in the upper right) then hit ‘Delete’. This will disconnect the bulb from the cloud, and erase its information from the cloud. The bulb will stay connected to the Wifi and can be reclaimed at any time.

Ah, sorry I forgot to clarify this, The bulbs do not send ADWin packets, but as there is no Wireshark dissector installed you may occasionally see them miscategorised as other packet types. I’ve seen Wireshark call them STUN or ADWin packets before.