What's wrong with my Android discovery? [closed: nothing]

I’ve read everything I on here about performing discovery, but I’m still having trouble with it in Android. For reference, this bit of python code (shamelessly put together from examples found on this forum) successfully gets a reply from my bulbs: https://gist.github.com/anonymous/5615cca70511e1d9f7b6585f8723962f

Wireshark shows responses from five bulbs as a result:

However, when using this bit of code and executing it from my android device, I do not see any response from the bulbs: https://gist.github.com/anonymous/7f12343d4e7d87cc9f9991a87951ef9f

(as an aside, I don’t intend on using such hardcoded packets versus building them in code; but I’ve been struggling with this for a while, so I’m trying to strip it down to the most basic state).

Wireshark sees the packet, and it looks nearly identical to the packet sent via python. The only difference I’ve noted is Java sets a “Do not fragment” flag.

Here are the hex dumps for these two packets.

Python packet:
0000 ff ff ff ff ff ff e8 de 27 1d 3c ef 08 00 45 00
0010 00 40 67 b2 00 00 80 11 4e 36 c0 a8 01 75 c0 a8
0020 01 ff fb 24 dd 7c 00 2c 96 8f 24 00 00 34 66 6a
0030 7e 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 01 00 00 00 00 00 00 00 00 00 02 00 00 00

Java packet:
0000 ff ff ff ff ff ff 90 b6 86 c1 af c8 08 00 45 00
0010 00 40 80 e1 40 00 40 11 34 e8 c0 a8 01 94 c0 a8
0020 01 ff e8 5d dd 7c 00 2c a9 37 24 00 00 34 66 6a
0030 7e 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0040 01 00 00 00 00 00 00 00 00 00 02 00 00 00

Can anyone please help me figure out what it is I’m doing wrong?

For some more information, I am able to successfully change the bulbs colors using this code. Here’s a comparison of the two packet headers, first the discovery and secondly the color changing packet; I’ve also included the python packet in the third position. I really don’t know what I’m missing:

destination     source    ipv4 hlen ECN  len  id  foffset  TTL UDP cSum  src ip  dest ip  sPrt dPrt len  cSum
ffffffffffff 90b686c1afc8 0800  45  00  0040 464c  4000    40  11  6f7d c0a80194 c0a801ff e119 dd7c 002c b07b 
ffffffffffff 90b686c1afc8 0800  45  00  0055 5459  4000    40  11  615b c0a80194 c0a801ff 81e8 dd7c 0041 c5dd 
ffffffffffff e8de271d3cef 0800  45  00  0040 534c  0000    80  11  629c c0a80175 c0a801ff cd5e dd7c 002c c455

Here’s the discovery data:

And the color changing data, for reference:

You can see that the python packet and java packet have different fragment offset values and TTL. Otherwise, they only seem to differ on parts I would expect to see differences (source IP, check sum). The fragment offset of the java packets indicates the “don’t fragment” bit is set, though I’m not exactly sure why; even so, the offset itself is equal to zero, and the “more fragments” bit is set to zero.

I really just don’t understand what I am doing wrong :frowning:

And I’m pretty sure I’ve figured out the “problem”. I finally wrote the code to actually receive the responses. For whatever reason, I am not seeing that traffic in wireshark, but I do see the packets on the phone. They’ve probably been there the whole time. Sigh. At least it works.

1 Like

You won’t see the packets on your laptop on WireShark, unless you’ve joined the multicast group, on your laptop.

My understanding is I won’t see them unless my desktop has a wireless card that supports promiscuous mode (and of course it must be enabled). Because I could see the other packets (which were all broadcast), I originally thought I would be able to see the ones destined for my phone as well, but I understand now why that’s not the case.

To my knowledge, Lifx does not use multicast groups, only broadcast. I do wish there were a way to tell specific bulbs to join a multicast group, then multicast messages to those groups. But even if there were, it still wouldn’t make much sense for my application to join that group.