asuswrt-merlin compatibility

[privacyguy123]

As far as I can see these firmware routers run mcpd whether or not IGMP Proxy is on or off which makes smcroute complain API is already in use.

smcrouted -n
smcroute[8890]: SMCRoute v2.5.6
smcroute[8890]: IPv4 multicast routing API already in use: Address already in use

If I killall mcpd the inbuilt WireGuard Server function of the router firmware fails to connect which defeats the purpose of routing the packets inside the WG Server tunnel ...

Is there a way to make this stuff coexist?

[troglobit]

Converting to Discussion since this is not a bug or feature request in the SMCRoute project but more of a general question.

[troglobit]

Yes, there is a way, but it's not simple.

As mentioned in the documentation, SMCRoute has support for multiple multicast routing tables (-t ID). This, however, requires that the kernel has CONFIG_IP_MROUTE_MULTIPLE_TABLES enabled. See the kernel and SMCRoute documentation for details.

[privacyguy123]

Perhaps I'm in luck then.

zcat /proc/config.gz | grep CONFIG_IP_MROUTE_MULTIPLE_TABLES
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y

EDIT: sorry I see it now. Back to the lab to see if I can get this thing working.

[privacyguy123]

Able to get this far yet still no devices appear on Android device. Is it possible this just will never work due to some Android limitation? My phone is rooted ...

smcroute[6302]: New multicast data from 192.168.50.5 to group 239.255.255.250 on br0
smcroute[6302]: Add 192.168.50.5 -> 239.255.255.250 from VIF 11
smcroute[6302]: New multicast data from 192.168.50.6 to group 239.255.255.250 on br0
smcroute[6302]: Add 192.168.50.6 -> 239.255.255.250 from VIF 11
smcroute[6302]: New multicast data from 192.168.50.5 to group 239.255.255.250 on br0
smcroute[6302]: Add 192.168.50.5 -> 239.255.255.250 from VIF 11

[troglobit]

You are trying to route SSDP? SSDP consists of multiple parts, simplified: announcements and probes over the multicast address 239.255.255.250 and then fetching an XML file over UDP from a unicast address. So, if a TV announces itself on 239.255.255.250, that message contains an address to, e.g., http://192.168.50.5:1900/data.xml which any client (for example a Chrome browser) will try to retrieve. If either of these things don't work, the client will not show any information about this.