Closed F5OEO closed 1 year ago
I'm not sure what you mean. dvb-gse
already binds to a UDP port and receives UDP frames containing BBFRAME fragments such as those that longmynd sends out. How is this different from what you propose? Is the problem that SO_REUSEADDR
is not used on the socket, preventing several applications from sharing the same UDP port?
./longmynd -p h -M 192.168.2.1 1883 -i 230.0.0.1 1234 1250000 333 and receiving it with dvb-gse --listen 230.0.0.1:1234 --tun tun0 is not working. You need to send an IGMP request , surely with something like join_multicast_v4
Oh, I see. That makes sense. I'll see how best to implement this, since currently the UDP port is IPv4/IPv6 agnostic.
Maybe obsolete article, but if any help (ipv4/ipv6 multicast) : https://bluejekyll.github.io/blog/posts/multicasting-in-rust/
I have submitted #8 with the required changes. I haven't tested this with Longmynd, but I've seen that the IGMPv3 / ICMPv6 packets to join/leave the multicast group are sent when the application starts/terminates.
Can you test if this PR works for you before it gets merged?
Fixed ! (not tested on IPV6): thanks !
When using receive multicast, it is convenient to use a socket with SO_REUSEADDR in order to allow multiple clients to join and receive the stream. (Ehancement).
To allow easy debugging, it could be helpful that dvb-gse could receive udp/multicast bbframes from longmynd. Thus we could inspect input bbframe and result on tun at same time. (ehancement).