Unable to get past 15 seconds of stream about udm-telus

[peacey]

Hi @zorq,

Your settings seem to be fine. I also have the SFP port set to WAN1 and use eth9, so that's not an issue.

I also already installed the auto start script, so I can't run ./igmpproxy -nd ./igmpproxy.conf as it will say the following:
MC-Router API already in use; Errno(98): Address already in use

For debugging purposes, you can run killall -9 igmpproxy to stop the background process, then you should be able to run it in the foreground like that. If you're not getting any errors, you can just run it in the background.

Have you tried to enable Flow Control on your switch? I had to enable that to make IPTV work seamlessly, or else it would not work sometimes. Also make sure you're not doing any storm control on the switches. And you don't have any other firewall rules?

If it doesn't work, let's do some testing to see what's happening to the IGMP packets. Make sure the igmpproxy is running for the following tests.

1. First, let's see that your STB is generating the IGMP report packets on your LAN. Run the following tcpdump on your UDMP, and then switch to a channel on your STB.

   tcpdump -ni br33 igmp and host 192.168.33.55

   Replace 192.168.33.55 with your STB's IP. After you switch a channel and 15 seconds passes, you should immediately see an IGMP report packet like this:

   15:03:46.475485 IP 192.168.33.55 > 232.9.4.55: igmp v2 report 232.9.4.55

   The multicast group it's reporting to join (232.9.4.55) might be different for you. It might also report to 239.255.255.250 but we don't care about that. Just note what IP it's reporting for this channel.

2. Once you confirm the IGMP packets are being generated by the STB and the UDM can see them, let's see if they are being forwarded to your WAN. Run the following tcpdump and then switch to the same channel.

   tcpdump -ni eth9 igmp

   You might see many IGMP reports to irrelevant IPs. But after you switch the channel and wait 15 seconds, look for the IGMP report packet to the same IP you saw in step 1 above.

3. If the IGMP report is travelling out your WAN, then TELUS should be sending you the multicast stream to that IP. You can run the following tcpdumps to see that the multicast stream is arriving on your WAN and being forwarded to your VLAN network (15 seconds after switching channels).

   tcpdump -ni eth9 host 232.9.4.55
   tcpdump -ni br33 host 232.9.4.55

   Replace 232.9.4.55 with the report IP you found for this channel in Step 1. If it's working on the WAN side, you should see a constant stream of UDP packets from a TELUS IP to the multicast IP (232.9.4.55). You should also see those same packets on the br33 interface in the second tcpdump.

Let's trace the traffic and see what's happening.

[zorq]

I enabled flow control on the USW-Flex-Mini and that didn't work, I confirmed igmpproxy is running in the background. Storm control is disabled as well. I tried to get a tcpdump and that didn't work either. Interestingly ipv4 disappeared from unifi gui after a few restarts? (supposedly a known issue for udmp) anyhow, I set a fixed IP address on the STB so i know the ip address i'm tcpdump is correct. I even tried removing the usw-flex-mini and only connect the us-24-g1, enabled flow control on the us-24-g1 switch and its still not working.

I only have 2 custom firewall rules, 1 is for the IPTV as per the guide and the other is a simple port forward rule.

Thank you...

[peacey]

Hi @zorq,

Regardless of igmpproxy running or the proper configuration, the STB should still be generating the IGMP packets and you should see them on your LAN interface tcpdump (br33).

Are you able to ping the STB from the UDM?

How many clients do you have on the VLAN 33 network? Can you just run this tcpdump without any IP?

tcpdump -ni br33 igmp

Then change channels and after 15 seconds you should see a IGMP report message in this tcpdump... If you don't, then something is blocking the IGMP packets at the switch level, or something is wrong with the STB... Maybe try to restart it?

[zorq]

I was able to get some igmp packets by tcpdump br33:

ping seems to be funcitonal as well from UDMP

Only 1 on IPTV VLAN 33.

Running a tcpdump on eth9 shows no packets are making it to the port

[peacey]

Hi @zorq,

I think 10.114.0.1 is the IP of your UDM. From your settings, I can see that 10.114.0.1 is assigned as the IP of your UDM gateway. So then, the tcpdump isn't showing you any packets from the STB...

That's really odd, the STB should be giving out IGMP report packets. Can you please figure out the IP of the STB and try to ping it from the UDM?

[zorq]

The issue appears to be IGMP snooping. I have IGMP snooping enabled in 2 of the VLANs and somehow the igmp packets gets pruned hence why we don't see any igmp packets from the STB and only igmp packets from WAN. After disabling the IGMP snooping on the two networks everything is working well!

I've been trying to figure out an issue with getting Sonos to play well within my network. One of the recommendation is to enable IGMP snooping. I'm, however, still experiencing issues where Sonos intermittently drops dead silent.

It is a win for today and I guess I'll have to worry about the Sonos issue another day. Thanks so much for all your help!

Now I need to use this setup with the other network where I use wireless uplink and to get the STB working...

[peacey]

Hi @zorq,

Glad to see you got it working! Ubiquiti's IGMP snooping is a bit flakey and sometimes misses packets, so it doesn't work well all the time. Hopefully you can get the WiFi STB working this time!

I've been trying to figure out an issue with getting Sonos to play well within my network.

Sonos uses SSDP multicast which the mDNS repeater on the UDM does not cover. That's why Sonos doesn't work well on the UDM. However, since it is just multicast traffic, you can use igmpproxy for it as well. You just need to set the Sonos VLAN as downstream and the control VLAN as upstream.

For example, if you're controlling the Sonos from default lan (br0) and the Sonos speakers are on VLAN 9 (br9), then you can use an igmpproxy configuration like this:

quickleave

phyint br0 upstream ratelimit 0 threshold 1
        altnet 0.0.0.0/0;

phyint br9 downstream ratelimit 0 threshold 1
        altnet 0.0.0.0/0;

You can just save that file as igmpproxy2.conf in the same folder as before. Then just kill the IPTV igmpproxy (killall -9 igmpproxy) and run igmpproxy with this configuration instead in the foreground. Then test your Sonos.

/mnt/data/igmpproxy/igmpproxy -nd /mnt/data/igmpproxy/igmpproxy2.conf

If it works out, I believe we can combine the IPTV and the Sonos igmpproxy configurations into one. But I would try it like this first to make sure it's working when set up alone.

[zorq]

Thank you so much for going out of scope and helping!

The Sonos issue on hand is actually one of my retail stores that utilizes soundtrackyourbrand(commercially licensed spotify essentially) integrated into Sonos app. Randomly during the day, the speakers that are grouped together will suddenly stop playing music. If the speakers are grouped by selecting A as the main speaker and then grouping B C and D, ungrouping and using speaker B will allow music play back for C and D after grouping. During these time, speaker A will be inoperable, incontrollable in the app and it will always show up as an error and then about 10-15 minutes later, it goes offline and comes back online automatically and at that point we can group A into the rest of the speakers again.

The devices operating the Sonos App are all connected on VLAN 10 as are the speakers. Otherwise we can't even see the speakers on the Sonos App.

On research, they recommend using STP and setting priorities for the layers of switches. Enabling IGMP snooping. And then some recommends disable STP per port connected to the Sonos (but doesn't that goes against the first recommendation setting STP, and if it's disabled per port why mess with the rest of the network and not just keep RSTP?).

However, I tried switching to STP but that actually causes some of the other devices on the network to not function normally, so I can't even try to see if that solves my problem.

At this point, I'm not sure if IGMP Snooping on VLAN 10 should even be enabled given that you mentioned it is flakey. RSTP is configured and prioritized. I kept the per port stp enabled for all the sonos devices connected. They are all hardwired.

[jniemin]

Hey @peacey,

I got wired connection working with these instructions. There was a minor change in newer version of UDM for location of firewall rules, so I created PR to change that.

However even though it works perfectly on wired connection I have troubles getting past 15 second when I'm connected to wireless. Both wireless and ports on wired connection are configured to use same VLAN and no other VLANs (expect default) exist. As far as I tell everything seems to be in order. I checked tcpdump and all of the above you were saying was fine and I did see broadcast going out to WAN and stream of UDP packages coming in.

Any thoughts what else to check?

Here is screen shot of my wifi configuration: