in ka9q/discovery.py, _create_status_listener_socket() binds the listener to 0.0.0.0:5006 (wildcard) rather than to the requested multicast_addr, then joins that group via IP_ADD_MEMBERSHIP. On Linux, that membership call only affects IGMP/interface-level reception — it doesn't scope socket delivery. A wildcard-bound socket on port 5006 receives traffic for any multicast group joined by any socket on the host sharing that port, and recvfrom() never exposes the packet's destination address, so the read loop can't tell which group a STATUS packet actually arrived on.
Live repro (three simultaneous radiod instances, distinct static addresses):
239.192.1.10 -> {10000: '239.192.64.10', 144390: '239.192.64.20'} # WWV query also returns APRS!
239.192.1.20 -> {144390: '239.192.64.20', 10000: '239.192.64.10'}
239.192.1.30 -> {144650: '239.192.64.30', 10000: '239.192.64.10'}
Suggested fix: bind to multicast_addr itself instead of 0.0.0.0 (the standard way to scope a multicast listener when more than one group may be active on a host), or use IP_PKTINFO to recover and filter on the actual destination address per packet.
Our workaround: filter the returned channels by an independently-known expected data address downstream, since the library's own output can't be trusted to already be scoped correctly.
in ka9q/discovery.py, _create_status_listener_socket() binds the listener to 0.0.0.0:5006 (wildcard) rather than to the requested multicast_addr, then joins that group via IP_ADD_MEMBERSHIP. On Linux, that membership call only affects IGMP/interface-level reception — it doesn't scope socket delivery. A wildcard-bound socket on port 5006 receives traffic for any multicast group joined by any socket on the host sharing that port, and recvfrom() never exposes the packet's destination address, so the read loop can't tell which group a STATUS packet actually arrived on.
Live repro (three simultaneous radiod instances, distinct static addresses):
239.192.1.10 -> {10000: '239.192.64.10', 144390: '239.192.64.20'} # WWV query also returns APRS!
239.192.1.20 -> {144390: '239.192.64.20', 10000: '239.192.64.10'}
239.192.1.30 -> {144650: '239.192.64.30', 10000: '239.192.64.10'}
Suggested fix: bind to multicast_addr itself instead of 0.0.0.0 (the standard way to scope a multicast listener when more than one group may be active on a host), or use IP_PKTINFO to recover and filter on the actual destination address per packet.
Our workaround: filter the returned channels by an independently-known expected data address downstream, since the library's own output can't be trusted to already be scoped correctly.