UPnP Intermittent Failure

[Shonk]

3 Days uptime on my router, and it still shows up in that browser.

odd its been broken for me since day one
after roughly 5mins uptime

maybe its some small difference that exposes the problem
im using straight dhcp with option flags maybe your using pppoe for example
or im using duel stack native v4/v6 etc..

when im bored i will factory reset the router
and see if it disapears after a few mins (without even logging into the router)

 

[RMerlin]

odd its been broken for me since day one
after roughly 5mins uptime

maybe its some small difference that exposes the problem
im using straight dhcp with option flags maybe your using pppoe for example
or im using duel stack native v4/v6 etc..

I know that some of the reported bridge multicast issues are related to the use of IPv6 (I don't use IPv6 here). People were unable to ping an IPv6 until they disabled multicast snooping.

Someone would probably have to browse through past kernel commits on the bridge code, could be something that was fixed upstream by the kernel devs. The MIPS kernel had a ton of backports from the wl500g/Tomato community, but the ARM kernel is pretty vanilla. I doubt Broadcom put as much efforts into backporting fixes than the community did on the 2.6.22.19 kernel. Personally, I've only backported very few things to 2.6.36.

 

[RMerlin]

I don't dare disabling multicast_snooping because anything that messes with multicast can potentially break things with IPTV, which is something I have no way of testing either. I would be open however to adding an option on the unsupported tweaks section to disable it in the future, and making it disabled by default. That way if IPTV users report new problems, they could revert back to the previous behaviour.

 

[Shonk]

I don't dare disabling multicast_snooping because anything that messes with multicast can potentially break things with IPTV, which is something I have no way of testing either. I would be open however to adding an option on the unsupported tweaks section to disable it in the future, and making it disabled by default. That way if IPTV users report new problems, they could revert back to the previous behaviour.

i think thats the best thing for now until the root cause is found

 

[kvic]

Have you tried letting upnpc run a query against it every 30 seconds or so for 20 or 30 minutes? For me it easily stopped responding in any 30 minute span of time and it lasted for a number of minutes before it starts working again. If I re-enable IGMP snooping it will happen quite quickly.

Interesting..I played with your idea in a quite different setup:

miniupnpd (router, Edgerouter X) <--> AP (br0, RT-AC56U) <--> miniupnpc (client PC)

Query over a period of 30 minutes. Consistently gets response from miniupnpd. On br0 (RT-AC56U), I do have multi-cast snooping:

$ cat /sys/class/net/br0/bridge/multicast_snooping
1

Through the process I realise another advantage of MediaTek SoC. Thanks for the fun.

 

[sfx2000]

Through the process I realise another advantage of MediaTek SoC. Thanks for the fun.

It's more code, not chipset related

Different versions of upstream code - I've seen issues with pfSense and x86 here... which kinda rules out OS and Chips...

 

[kvic]

There's been some issues with miniupnpd - mem leaks, doesn't just affect AsusWRT (or other platforms)... it's pretty much an upstream problem

I think it's kernel issue, perhaps in the software bridge. I just realised the low-cost/cheap MediaTek MT7621 doesn't have to use software bridge! Broadcom seems cheating with software bridge to save cost. How can Broadcom stay competitive with such premium products...

@ryzhov_al, one more item to add on the merits of MT7621. lol

 

[sfx2000]

I know that some of the reported bridge multicast issues are related to the use of IPv6 (I don't use IPv6 here). People were unable to ping an IPv6 until they disabled multicast snooping.

Interesting that ipv6 doesn't have multicast...

Could be some odd stuff there perhaps with the stack, wouldn't be the first time...

 

[sfx2000]

I think it's kernel issue

I respectfully disagree - since this issue crosses BSD and Linux, and also x86/ARM/MIPS, it's likely their code... not anything in the kernel...

 

[sfx2000]

I don't dare disabling multicast_snooping because anything that messes with multicast can potentially break things with IPTV, which is something I have no way of testing either. I would be open however to adding an option on the unsupported tweaks section to disable it in the future, and making it disabled by default. That way if IPTV users report new problems, they could revert back to the previous behaviour.

Don't disable multicast_snooping - in BRCM - this is a flag in the switch element - has nothing to do with uPnP directly...

 

[Hyper_Eye]

I enabled multicast snooping and ran upnpc every 30 seconds in a loop:

for i in {1..60}; do echo "Issuing UPnP IGD Discovery #$i"; upnpc -s; sleep 30; done > upnpc.out

It failed 13 minutes in. It continued to fail for 3 minutes. It isn't enough to just check whether UPnP is working from time to time or after the router has been up for a while. You have to catch it during a window where the multicast queries are failing. During the window where it is failing if I disable multicast snooping it immediately begins working again.

 

[Shonk]

what i dont understand is i have multicast routing + multicast snooping disabled
in the web interface, so why is it enabled on the bridge

upnp is next to useless on the rt-ac88u for my setup without this being turned off
consoles quite simply dont see it after the 5min boot window (in any reliable manner)

e.g. xbox 360 network connection test is the process for looking for an igd device to forward a port
it can take 15+ network connection tests until it actually manages to see it and forward a port after the first 5 min window

windows devices you can sit on network and refresh, it comes back for a bit
so you can add a port forward for other devices manually

since running
echo 0 > /sys/class/net/br0/bridge/multicast_snooping
every device has been 100% just like my old rt-ac66u used to be
and is seen constantly by all devices

PS4 = Fine
Ps3 = Fine
Xbox one = Fine
Xbox 360 = Fine

 

[Jack Yaz]

Just wanted to chime in on my AC-87U i've been having this problem. Have run the echo command, and will post back with the outcome.

Prior to change, UPNP devices would stop seeing each other after 10-15, and while restarting UPNP service on the AC87U brought them back, it was only temporary.

 

[Jack Yaz]

I've got the script in init-start, and checked it is working (using touch to make a tmp dir), but something is changing it back to 1. Any ideas?

 

[Hyper_Eye]

The script should be a file named init-start in the /jffs/scripts path. It needs to have the executable bit set:

chmod a+rx /jffs/scripts/init-start

If that isn't working look in the WebUI at Administration->System for "Enable JFFS custom scripts and configs". Make sure that is enabled.

 

[Jack Yaz]

As I said, script is running, as I add a touch line which creates a dir in temp. The echo 0 doesn't seem to be sticking however, so I wonder if something further downstream from init is setting differently.

 

[Shonk]

I've got the script in init-start, and checked it is working (using touch to make a tmp dir), but something is changing it back to 1. Any ideas?

its staying at 0 for me

ASUSWRT-Merlin RT-AC88U 380.66-0 Thu Apr 27 10:04:31 UTC 2017
admin@aurora:/tmp/home/root# cat /sys/class/net/br0/bridge/multicast_snooping
0

 

[Jack Yaz]

Wonder if the 87U behaves differently to 88. Also I noticed this on boot as the VPN client for one of the devices came up. This device is set to use VPN client via policy routing for 0.0.0.0 (i think this wont affect local traffic between the 87U and the device?)

kernel: DROP IN=vlan1 OUT= MAC= SRC=10.14.16.22 DST=10.14.16.1 LEN=412 TOS=0x00 PREC=0x00 TTL=64 ID=41727 DF PROTO=UDP SPT=34889 DPT=1900 LEN=392

 

[Hyper_Eye]

Sorry about that. I misinterpreted. The option sticks for me. There are a few features that use multicast. IPTV can be affected by multicast snooping in particular. WPS utilizes UPnP. wps_monitor actually turned out to be the process holding the second multicast 1900 socket that I mentioned in my original post. Media sharing uses minidlna which is also a UPnP service. I don't think enabling these features should cause the multicast snooping setting to change but these are features that I currently have disabled.

 

[Jack Yaz]

How do I check which services are hogging 1900? I don't use IPTV or anything like that, just trying to use Kodi on Win10 to access Kodi server via Upnp (no NAS as of yet, else I'd be using smb shares)