search

Hundemeier / sacn

A simple ANSI E1.31 (aka sACN) module for python.
MIT License
48 stars 21 forks source link

Multicast packets sent to the broadcast group aren't received #49

Closed andrewyager closed 5 months ago

andrewyager commented 6 months ago

I can't comment if this is in spec, but we've been working with a BStation2, which is broadcasting sACN packets on a universe configured on it.

Looking in sACNView we can see the BStation sACN transmission, but the library doesn't receive the packets.

Looking at the multicast group membership, we can see that the BStation has joined 239.255.255.255; which appears to be a "broadcast" sACN group.

As indicated, these packets aren't received by the receive thread, and so aren't processed.

In an ideal world, I'd love to be able to optionally (or always?) catch these packets; just like we can do with sACNView.

Hundemeier commented 6 months ago

I've looked into the spec on page 24 and this behavior is mentioned as "shall not do" explicitly. To quote the spec:

The top 256 IPv4 multicast addresses, 239.255.255.0 through 239.255.255.255, are reserved by IANA for scope relative addressing; therefore E1.31 devices shall not transmit on these top 256 addresses. If the corresponding reserved universes are used in the future, they must be transmitted unicast. Additionally, E1.31 devices shall not use universe number 0 as it is reserved for future use. Universe numbers between 64000 and 65535, excluding universe 64214 (which is used for E1.31 Universe Discovery), are reserved for future use and shall not be used by E1.31 devices except as specified in future standards designed to coexist with E1.31 when use of these universes is called for specifically.

I don't know if there are any "future standards designed to coexist with E1.31" that might be relevant here. Since the spec is rather detailed about this, I added a check for this from the beginning: https://github.com/Hundemeier/sacn/blob/1bc53abc677c97ba4f8a40e13b341de49ffd18c4/sacn/messages/data_packet.py#L71-L72

I realise that adhering to the spec and supporting other implementations are opposite to another in this case. I think adhering to the spec is of lower priority. Could you (and test with you setup) change the following code sections accordingly from 64000 to 65535? You can run the test suite with pytest --run-integration-tests.

https://github.com/Hundemeier/sacn/blob/1bc53abc677c97ba4f8a40e13b341de49ffd18c4/sacn/messages/data_packet.py#L71-L72 https://github.com/Hundemeier/sacn/blob/1bc53abc677c97ba4f8a40e13b341de49ffd18c4/sacn/messages/data_packet.py#L83-L84 https://github.com/Hundemeier/sacn/blob/1bc53abc677c97ba4f8a40e13b341de49ffd18c4/sacn/messages/sync_packet.py#L30-L31 https://github.com/Hundemeier/sacn/blob/1bc53abc677c97ba4f8a40e13b341de49ffd18c4/sacn/messages/universe_discovery_test.py#L83

These might also be relevant if you want to send out this out-of-spec data:

https://github.com/Hundemeier/sacn/blob/1bc53abc677c97ba4f8a40e13b341de49ffd18c4/sacn/sender_test.py#L290-L293 https://github.com/Hundemeier/sacn/blob/1bc53abc677c97ba4f8a40e13b341de49ffd18c4/sacn/sender.py#L162-L163

andrewyager commented 5 months ago

I'm still investigating what is going on here. This didn't appear to solve the problem that existed here; but I believe the issue may not be what it initially presents as. I'll do some more testing later this month.