It is supposed to acquire responses from all devices on the local network , i get nothing returned . Im using wireshark and packetsender to see all UDP packets incoming/out-going to see if anything gets returned.
in the DatagramPacket p object the getBroadcastAddress, is the IP address of router so it can broadcast to everyone on the lan .
Only thing that could possbily be wrong is my packet
One thing to remember: the first two bytes of the packet need to indicate the length of the packet in bytes.
A Light::Get packet won’t be the same length as the Light::SetColor packet in @daniel_hall’s example, because Light::Get doesn’t carry a payload - it’s just a header. If I paste the packets below, you can see that they are different lengths:
So you will need to adjust the first two bytes of your packet to reflect the actual length of the message. I think a Light::Get packet should actually contain 36 bytes of data. So if you convert 36 to hex and byteswap it, the first two bytes of your packet should be 24 00, instead of 31 00.
There might be other problems with the packet too, but as a first step you could check and see if this helps.
@SaidAbs when you say ‘address of the router’, what do you mean? Do you have some other process on the router that will perform the broadcast when it receives the packet? Otherwise, you’re just sending a unicast packet to the router device, whatever that is, and it will just drop it or return ICMP port unreachable. You need to actually broadcast the packet.
I’ve underlined a couple of clues - the “6b” is the message type (107 in decimal, which is the code for a Light::State message), and the “ff 7f ff ff ff ff” are the hue, saturation and brightness that you set with your previous message.
I don’t know why there’s a bunch of stuff before the start of the message, though… Is that a Wireshark thing? I’ve never used Wireshark so I don’t know how it works/what it does.
Those STUN packets are exactly what you should expect to see. Wireshark doesn’t understand the LIFX protocol and miscategorises them as STUN. You may want to set the source header field to a non zero value so that the packets come directly back to you instead of being broadcast, but you should be able to parse these for now.
The data before the start of the packet in Wireshark is the Ethernet and the IP headers for the packet. Wireshark captures traffic that passes directly from the network interface. This means it captures every single byte. Thats why Wireshark is one of the best tools for debugging network applications.
That would be the LIFX frame, the frame address and the protocol header. You can read about all of them in the protocol documentation. Also the first post in this thread covers how the whole packet fits together.