asuswrt-merlin

[privacyguy123]

Is is possible to get this running on an ASUS router? I've ran into the issue of not being able to control multicast stuff while tunnelling into my ASUS RT-AX58U and wasn't aware it was a full blown limitation.

[geekman]

Yes you can. I wrote this specifically to be run on my Linksys WRT54G, and have been running it on my ASUS routers after that. If you're using merlin then maybe someone has already compiled a package for it that you can easily install, otherwise you will need to compile it yourself.

[privacyguy123]

I think my router is arm7 ... does that complicate things any?

Do you know if this will allow mDNS communcation between devices outside of my network connecting in via in built VNP Server WireGuard tunnel? I've read a lot of other stuff about SMCRoutes or something and I don't really understand what I'm doing.

[geekman]

I think my router is arm7 ... does that complicate things any?

I don't think so, as long as a compiler is available, which in most cases it is.

Do you know if this will allow mDNS communcation between devices outside of my network connecting in via in built VNP Server WireGuard tunnel? I've read a lot of other stuff about SMCRoutes or something and I don't really understand what I'm doing.

I don't have any experience routing mDNS across VPNs, but I assume it would work.

[privacyguy123]

Time to search for the compiler then :S

Does this conflict with the built in avahi reflector settings or asuswrt igmpproxy/multicast settings? I've tried everything else to get this to work, even people online who say previously mentioned settings work for them.

[privacyguy123]

Just getting this with make, tried multiple toolchains. Trying to compile for ASUS RT-AX58U which is arm7 as far as I can see.

make: *** [<builtin>: mdns-repeater.o] Error 126

Nevermind, just built it on the router itself lol.

[privacyguy123]

I just don't know man. I've tried at least 6 solutions online to get multicast devices to appear in VPN tunnel and I can't get my head around it.

[kennylevinsen]

The only detail you have provided thus far is part of an error output when building mdns-repeater.

For anyone to be able to help you'd need to at least share:

1. Your mdns-repeater instantiation
2. The current network configuration
3. The expected behavior ("mDNS record from client on network A makes it to client in network B")
4. The (full) output from running mdns-repeater in the foreground while an mDNS packet is received that should have been forwarded

I would also recommend using tcpdump to search for where along the link the mDNS packet is lost - it could be something as silly as a firewall dropping it somewhere.

[privacyguy123]

Ok mdns repeater built on the router itself, makes finding compilers irrelevant. Derp.

Here we see some traffic successfully repeated:

mdns-repeater -f wgs1 br0
mdns-repeater: dev wgs1 addr 10.6.0.1 mask 255.255.255.255 net 10.6.0.1
mdns-repeater: dev br0 addr 192.168.50.1 mask 255.255.255.0 net 192.168.50.0
data from=192.168.50.3 size=43
repeating data to wgs1

Devices still not showing up on my Android connected in from outside using built in Wireguard Tunnel inside the router. The last "fix" I read about online suggests using something called VXLAN but I have no idea how to set that up. I know this is the wrong place but any guidance would be much appreciated.

Coincidentally the avahi-daemon --debug output on the router complains about "another stack" running. Is this normal?

[kennylevinsen]

Start out by testing with a Wireguard client you can run tcpdump or wireshark on so you can see if the repeated packet is received. Not showing up in Chromecast device lists can be because of other reasons, such as a firewall blocking connection attempts in the other direction, routing issues making it impossible to connect, wireguard AllowedIPs blocking things, ...

You will need to get comfortable using these tools and following packets along your network in order to debug network issues - and if you want more complex network setups you will need to be able to understand where the packets are supposed to go and how to debug when they don't.

I cannot think of any scenario where you would need VXLAN though.

Coincidentally the avahi-daemon --debug output on the router complains about "another stack" running. Is this normal?

No idea.

[privacyguy123]

Start out by testing with a Wireguard client you can run tcpdump or wireshark on so you can see if the repeated packet is received. Not showing up in Chromecast device lists can be because of other reasons, such as a firewall blocking connection attempts in the other direction, routing issues making it impossible to connect, wireguard AllowedIPs blocking things, ...

Honestly I wouldn't know what I'm looking for. I think it's best to run with Firewall off until I can get this into a working state at all. AllowedIPs are definitely set right.

I cannot think of any scenario where you would need VXLAN though.

Multiple sites online state this traffic will never reach/route through a Wireguard tunnel because it's L3 and these devices require L2 to communicate. Apparently VXLAN would fix this but I don't know how to set it up.

[kennylevinsen]

Apparently VXLAN would fix this but I don't know how to set it up.

VXLAN is for virtualized networks in datacenters - there is no sensible way to use that from a regular end-user device like an Android phone.

The way to debug your problem is to use tools like tcpdump or wireshark to see where your packets are being lost or mangled and ultimately diagnose the issue, not blindly trying things and hoping that will somehow fix things.

Closing as no mdns-repeater issue is described.

[privacyguy123]

Android phones can't bind their tun interface to transmit multicast packets - nothing I did was going to fix this.