I am wondering about the future of the multicast routing daemons in base on
OpenBSD -- is the future in mrouted(8), or dvmrpd(8), or something else? I
am aware that dvmrpd(8) is the newer codebase -- but when I have tried to
use it in practice I have had consistent problems with the daemon crashing
under normal scenarios.
In my most recent dvmrpd test scenario, I set net.inet.ip.mforwarding to 1,
created the following dvmrpd.conf configuration file, ran the daemon in
debug mode and then started the Windows version of the Sonos Controller
application on, in this scenario, VLAN 3 (which immediately makes dvmrpd
crash):
# cat dvmrpd.conf
group {
interface vlan3
interface vlan5
}
# dvmrpd -dvf /etc/dvmrpd.conf
startup
kmr_init: interface vlan5
kmr_init: interface vlan3
fsm_if: event 'UP' resulted in action 'START' and changing state for
interface vlan5 from 'DOWN' to 'QUERIER'
fsm_if: event 'UP' resulted in action 'START' and changing state for
interface vlan3 from 'DOWN' to 'QUERIER'
rt_insert: inserting route 10.82.5.0/24
rt_insert: inserting route 10.82.3.0/24
send_igmp_query: interface vlan5
send_igmp_query: interface vlan3
[... START SONOS CONTROLLER ON VLAN 3 ...]
mfc_start_expire_timer: group 239.255.255.250
mfc_start_prune_timer: group 239.255.255.250
fatal in dvmrpe: unknown neighbor to send prune
mrt_add_mfc: interface 13, group 239.255.255.250
fatal in rde: pipe closed
fatal in parent: pipe closed
Initially, the daemon _appears_ to be running fine, until I start the Sonos
Controller application at the point indicated above, when the daemon
immediately outputs the errors shown above and exits. The culprit packet
that appears to cause dvmrpd to crash is a SSDP discovery packet sent by
the Sonos Controller application to 239.255.255.250 (see below):
tcpdump: listening on vlan3, link-type EN10MB
17:45:10.417081 10.82.3.1 > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id
23931, len 28)
17:45:10.417103 10.82.3.1 > 224.0.0.4: igmp dvmrp Probe
genid 2257873240 [tos 0xc0] [ttl 1] (id 35152, len 32)
17:45:19.248851 10.82.3.100 > 239.255.255.250: igmp nreport 239.255.255.250
[ttl 1] (id 31513, len 32, optlen=4 IPOPT-148{4})
17:45:20.426728 10.82.3.1 > 224.0.0.4: igmp dvmrp Probe
genid 2257873240 [tos 0xc0] [ttl 1] (id 41676, len 32)
[... START SONOS CONTROLLER ON VLAN 3 ...]
17:45:25.376993 10.82.3.100.1901 > 239.255.255.250.1900: udp 230 (ttl 4, id
31514, len 258)
I have had relatively more success with mrouted(8). It seems to work in
most of the scenarios I have used it in, although in one case I have not
been able to get it to work on one particular piece of hardware for no
discernible reason -- no errors, no warnings found anywhere, it just fails
to route multicast packets. mrouted(8) has a significant limitation though
-- it only supports 32 VIFs on the entire system. If you have more than 32
virtual interfaces it will ignore the 33rd interface and beyond (the system
decides the ordering of the interfaces).
I can't use igmpproxy from ports because I require multiple "upstream"
interfaces.
I have been thinking about jumping into the code to try to address these
issues, but I'm not sure where to direct my efforts. I am inclined to focus
on the crash in dvmrpd -- but it's not clear from anything I have read that
dvmrpd is the future of multicast routing in OpenBSD. I have briefly looked
into the feasibility of increasing the number of VIFs supported by mrouted,
and it looks like that may be non-trivial, and it seems even less likely
that mrouted is the future of multicast routing on OpenBSD. I am also
troubled by the no error, no warning failure of mrouted on the system I
described above -- wouldn't even know where to start with that one.
Thanks in advance for any advice on this subject...
Joe Crivello
