[igmpproxy] op debian instellen met sonos en unifi

[siepeltjuh]

Sinds een tijd gebruik ik unifi appratuur, meestal ben ik er heel blij mee, nu even niet. Het blijkt dat de dreammachine die ik gebruik geen igmpproxy ondersteund zoals andere apparaten van Unifi dat wel doen.

Nu heb ik daarvoor een post gemaakt op het forum van Unifi:
https://community.ui.com/...f4-4ac5-a89e-0b780290ea68

En de conclusie is dat ik zelf een igmpproxy moet gaan draaien. Nu ben ik daar mee gestart. Maar ik krijg het nog niet aan de praat. Hopelijk is hier iemand met kennis van igmpproxy die kan helpen.

Via https://manned.org/igmpproxy.conf.5 heb ik de volgende config gemaakt:

code:

quickleave

phyint enp3s0.2 upstream  ratelimit 0  threshold 1
        altnet 0.0.0.0/0

phyint enp3s0.3 downstream  ratelimit 0  threshold 1
        altnet 0.0.0.0/0

phyint enp3s0 disabled

enp3s0.2 = VLAN 2 heeft de SONOS controller
enp3s0.3 = VLAN 3 heeft de SONOS speakers

De IGMP proxy draait op een host die dus met beide VLAN's verbonden is, maar het is niet de router/gateway want dat is de dreammachine.

Kan igmpproxy uberhaupt werken op een server die niet ook de router is van beide VLAN's?
Kan ik ook op een of andere manier controleren of de igmp-proxy werkt? Kan best zijn dat SONOS niet werkt, maar dat de proxy zelf wel functioneerd natuurlijk?

[webfreakz.nl]

siepeltjuh schreef op zondag 17 mei 2020 @ 22:04:
De IGMP proxy draait op een host die dus met beide VLAN's verbonden is, maar het is niet de router/gateway want dat is de dreammachine.

Kan igmpproxy uberhaupt werken op een server die niet ook de router is van beide VLAN's?

Lijkt me wel, sterker nog, het wordt een *extra* router om tussen die VLANs te routeren.

Kan ik ook op een of andere manier controleren of de igmp-proxy werkt? Kan best zijn dat SONOS niet werkt, maar dat de proxy zelf wel functioneerd natuurlijk?

Heb je de mogelijkheid om een "tcpdump" te starten? Dan kan je precies zien welke berichten er verstuurd worden en of ze verstuurd worden.

[siepeltjuh]

Als ik de SONOS controller start zie ik op de VLAN 2 interface van de igmpproxy (zelfde vlan/subnet als controller) zit dit terug:

code:

sudo tcpdump -i enp3s0.2 -nevvv -s 0 '(udp port 1900) or (tcp port 2869)'

code:

tcpdump: listening on enp3s0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
20:34:30.520144 e0:d5:5e:41:bc:67 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 356: (tos 0x0, ttl 4, id 6345, offset 0, flags [none], proto UDP (17), length 342)
    10.0.2.2.59982 > 239.255.255.250.1900: [udp sum ok] UDP, length 314
20:34:30.520197 e0:d5:5e:41:bc:67 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 356: (tos 0x0, ttl 128, id 60760, offset 0, flags [none], proto UDP (17), length 342)
    10.0.2.2.59982 > 255.255.255.255.1900: [udp sum ok] UDP, length 314
20:34:30.574543 e0:d5:5e:41:bc:67 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 356: (tos 0x0, ttl 4, id 6346, offset 0, flags [none], proto UDP (17), length 342)
    10.0.2.2.59982 > 239.255.255.250.1900: [udp sum ok] UDP, length 314
20:34:30.574598 e0:d5:5e:41:bc:67 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 356: (tos 0x0, ttl 128, id 60761, offset 0, flags [none], proto UDP (17), length 342)
    10.0.2.2.59982 > 255.255.255.255.1900: [udp sum ok] UDP, length 314
20:34:45.681330 e0:d5:5e:41:bc:67 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 4, id 6347, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 239.255.255.250.1900: [udp sum ok] UDP, length 315
20:34:45.681391 e0:d5:5e:41:bc:67 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 128, id 60762, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 255.255.255.255.1900: [udp sum ok] UDP, length 315
20:34:46.671114 e0:d5:5e:41:bc:67 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 4, id 6348, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 239.255.255.250.1900: [udp sum ok] UDP, length 315
20:34:46.671173 e0:d5:5e:41:bc:67 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 128, id 60765, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 255.255.255.255.1900: [udp sum ok] UDP, length 315
20:34:47.672115 e0:d5:5e:41:bc:67 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 4, id 6349, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 239.255.255.250.1900: [udp sum ok] UDP, length 315
20:34:47.672173 e0:d5:5e:41:bc:67 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 128, id 60766, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 255.255.255.255.1900: [udp sum ok] UDP, length 315
20:34:48.669790 e0:d5:5e:41:bc:67 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 4, id 6350, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 239.255.255.250.1900: [udp sum ok] UDP, length 315
20:34:48.669850 e0:d5:5e:41:bc:67 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 128, id 60767, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 255.255.255.255.1900: [udp sum ok] UDP, length 315
20:34:49.674884 e0:d5:5e:41:bc:67 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 4, id 6352, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 239.255.255.250.1900: [udp sum ok] UDP, length 315
20:34:49.674926 e0:d5:5e:41:bc:67 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 128, id 60768, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 255.255.255.255.1900: [udp sum ok] UDP, length 315
20:34:50.670203 e0:d5:5e:41:bc:67 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 4, id 6353, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 239.255.255.250.1900: [udp sum ok] UDP, length 315
20:34:50.670260 e0:d5:5e:41:bc:67 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: (tos 0x0, ttl 128, id 60769, offset 0, flags [none], proto UDP (17), length 343)
    10.0.2.2.59982 > 255.255.255.255.1900: [udp sum ok] UDP, length 315

Zelfde maar dan op de VLAN:3 interface blijft het stil. En ik heb gechecked of igmpproxy draait.

code:

nuc@lplxvi:~$ sudo tcpdump -i enp3s0.3 -nevvv -s 0 '(udp port 1900) or (tcp port 2869)'
tcpdump: listening on enp3s0.3, link-type EN10MB (Ethernet), capture size 262144 bytes

Mijn conclusie is dus nog gelijk aan eerdere: de manier waarop ik de igmpproxy nu heb ingesteld zorgt er voor dat er geen broadcast van het ene op het andere vlan gezet word.

[webfreakz.nl]

Ok je ontvangt in ieder geval SSDP / UPnP berichten. Wat zit er in de berichten als payload? Je kan met tcpdump en "-w $filename" doorgaans een PCAP file bouwen, als je die inlaadt in Wireshark (GUI app) kan je vrij makkelijk die PCAP inlezen.

Een oplossing heb ik niet zomaar voor je, kan je alleen een paar hints geven voor troubleshooting Misschien kan je in je igmproxy.conf je "altnet" vervangen door 10.0.2.0/24 ipv 0.0.0.0/0? Even om zeker te zijn dat die 0/0 geen roet in het eten gooit.. Anders moet je denk ik veel creatievere oplossingen gaan proberen te maken met dit soort tools waarmee je packets kan craften:

https://github.com/dannyb...UPnP/scripts/how-to-socat
http://linux-igd.sourceforge.net/documentation.php

[webfreakz.nl]

Daarnaast zie ik zojuist dat je packets niet allemaal dezelfde lengte hebben (314 vs 315 bytes UDP payload).

[jvthert]

Je haalt broad- en multicast een beetje door elkaar. Om sonos over twee subnetten te laten werken heb je een paar dingen nodig. Ik heb dit werkend met pfsense dus ik kan je enkel met wat algemeenheden helpen

- Multicast proxy -> igmp proxy dus
- Een udp reflector voor broadcast pakketjes
- Een avahi proxy (Voor airplay en spotify connect enz)

Zonder de laatste twee werkt sonos met de eigen app wel maar niet altijd even vlot.

Voor igmpproxy werkt het bij mij met de volgende instellingen:

code:

quickleave
phyint 3s0.3 downstream ratelimit 0 threshold 1
altnet 239.255.255.250/32
altnet 224.0.0.251/32
altnet <ip range van dit vlan>

phyint 3s0.2 upstream ratelimit 0 threshold 1
altnet 239.255.255.250/32
altnet 224.0.0.251/32
altnet <ip range van dit vlan>

224.0.0.251 is trouwens multicast dns. Vooral apple spul leunt daar sterk op. Als je geen airplay en/ of homekit spul gebruikt kan je deze allicht achterwege laten.

Voor avahi moet je zelf maar even kijken. Mijn ervaring is dat reflection ellende veroorzaakt dus ik draai een servertje met avahi-d en heb speciaal voor sonos wat services gedefinieerd. Je kunt even kijken naar wat sonos nu met een avahi browser en dat kopiëren.

Broadcast pakketjes doorsturen doe ik met mijn switch. Cisco smb spul ondersteunt dat en het scheelt een zelf geknutseld stukje go op mijn firewall.

[ Voor 26% gewijzigd door jvthert op 20-05-2020 12:59 . Reden: toelichting 224.0.0.251 ]

[jvthert]

Voor direct control en snellere discovery moet je broadcast verkeer (255.255.255.255) op udp poort 1900 doorzetten naar al je vlans.

Voor avahi heb je zoiets nodig (aanpassen naar smaak en elke speaker is een losse service). Zie verder https://linux.die.net/man/5/avahi.service

XML: /etc/avahi/services/sonos-speaker.service

<?xml version="1.0" standalone="no"?>
<!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
    <name replace-wildcards="no">sonosFFFFFFFFFFFF</name> <!-- Hier ipv FFF... mac address van de speaker/ connect -->
    <service protocol="ipv4">
        <type>_spotify-connect._tcp</type>
        <domain-name>local</domain-name> <!-- Dit niet aanpassen! -->
        <host-name>sonos.jouw.resolvable.domein</host-name> <!-- Dit ook aanpassen -->
                <port>1400</port>
                <txt-record>VERSION=1.0</txt-record>
                <txt-record>CPath=/spotifyzc</txt-record>
    </service>
</service-group>

[siepeltjuh]

Klopt dat ik het e.e.a. door elkaar haal, want eigenlijk weet ik er niet zo heel veel van. Maar gaandeweg leer ik :-)

igmpproxy ingesteld zoals je aangeeft en als ik je goed begrijp dan zou de controller dan al moeten werken. Helaas, de tcpdump geeft op vlan 3 nog steeds geen pakketjes wel op vlan 2.

De reflector of AVAHI kan ik later naar kijken. Eerste stap is die igmpproxy. lijkt wel alsof het ding niks doet.

Zojuist vond ik een python script dat ongeveer hetzelfde doet als igmpproxy en die werkt wel: https://github.com/alsmith/multicast-relay

Nu lees ik daar dezelfde adressen e.d. als in het voorbeeld staan, dus de config van igmpproxy lijkt goed. Maar toch werkt het niet. Nu zou je zeggen. man wees blij met de python script, je functionele vraag is opgelost. Ja dat klopt. Maar ik zou liever igmp proxy gebruiken dan het python script en bovendien wil ik graag weten waarom het niet werkt met igmpproxy.

Nog een suggestie dat ik zou kunnen testen of uitproberen?

[ro3lie]

Andere suggestie. Als je één van je speakers bekabeld aansluit creërt die zijn eigen SonosNet en gaat die niet over je apparatuur communiceren.
De fysieke uplink wordt gebruikt voor communicatie en updates naar buiten.
Zou dat niet het eea voor jou oplossen?

[siepeltjuh]

ro3lie schreef op donderdag 21 mei 2020 @ 12:58:
Andere suggestie. Als je één van je speakers bekabeld aansluit creërt die zijn eigen SonosNet en gaat die niet over je apparatuur communiceren.
De fysieke uplink wordt gebruikt voor communicatie en updates naar buiten.
Zou dat niet het eea voor jou oplossen?

Dank voor het meedenken. Of ze nu los in het netwerk hangen (wifi of bekabeld) of via 1 kabel, dat maakt op zich niet uit voor dit VLAN probleem. Er zijn meer opties; geen gescheiden VLAN's, Sonos opnemen in zelfde vlan als controller, andere router kopen (bijvoorbeeld USG), pfSense box aanschaffen en zo is er vast nog meer te bedenken.

Met het python script werkt het allemaal prima, dus functioneel is er een oplossing.

Maar ik ben vooral benieuwd waarom anderen het wel aan de praat krijgen met igmpproxy en ik niet. Wat mankeert er aan mijn setup?

[Laagheim]

Mijn eigen ervaring: Je hebt niets anders nodig dan de instellingen in de unifi controller gui. De Spotify app (android en ios) werkt gewoon ook al zitten je speakers en de app in een andere vlan. De Sonos app werkt ook maar voor zover ik het kan testen alleen op Android, en niet op ios.

[webfreakz.nl]

siepeltjuh schreef op donderdag 21 mei 2020 @ 13:26:
[...]
Maar ik ben vooral benieuwd waarom anderen het wel aan de praat krijgen met igmpproxy en ik niet. Wat mankeert er aan mijn setup?

Schoot me eigenlijk nu pas te binnen, maar in je tcpdump is ook geen IGMP verkeer. Ik ken igmpproxy verder niet, maar als die alleen doet wat de naam suggereert (IGMP proxy) ipv een generieke multicast proxy / replicator dan wordt het lastig forwarden als je geen IGMP ontvangt

Edit:
Lijkt er inderdaad wel op volgens de manpage van igmpproxy.. hier had ik eerder aan moeten denken..

https://manned.org/igmpproxy.8

Since igmpproxy only uses IGMP signalling, the daemon is only suited
for situations where multicast traffic comes from only one neighbouring
network. In more advanced cases, 'mrouted' or 'pimd' is probably more
suited.

Met "advanced cases" bedoelen ze dan waarschijnlijk multicast routing in ISP netwerken waar je PIM nodig hebt .

[ Voor 33% gewijzigd door webfreakz.nl op 21-05-2020 17:23 ]

[siepeltjuh]

Laagheim schreef op donderdag 21 mei 2020 @ 17:12:
Mijn eigen ervaring: Je hebt niets anders nodig dan de instellingen in de unifi controller gui. De Spotify app (android en ios) werkt gewoon ook al zitten je speakers en de app in een andere vlan. De Sonos app werkt ook maar voor zover ik het kan testen alleen op Android, en niet op ios.

Het gaat hier niet om de spotify app, maar om de Sonos controller. In de OP niet vermeld, maar ik heb geen android, de controller app draait op een windows 10 pc en op een iPhone.
In het aangehaalde topic in de OP is ook terug te lezen dat dit niet via de GUI kan werken. Alleen met (oudere) Unifi apparatuur kan je via een json config instellingen doorvoeren. Dat werkt echter niet voor de UDM.

@webfreakz.nl en @jvthert Dank voor jullie tijd. Denk dat ik mijn 'verlies' maar moet nemen en het python script voorlopig gebruik tot Unifi met een degelijke oplossing komt.

[Laagheim]

@siepeltjuh Ik heb al jaren Sonos speakers en vlans en ik ken het verhaal. Vorig jaar heb ik een Android tablet gekocht (altijd ipads gehad) en merkte ik dat de Sonos controller gewoon werkt ook al zit mijn tablet op een andere vlan. Toevallig een paar weken geleden een cheapo ander tabletje gekocht op Ali (ook Android) en daar werkt het ook.

Dingen veranderen en howtos op internet zijn niet altijd up to date. 😉

[siepeltjuh]

Laagheim schreef op vrijdag 22 mei 2020 @ 12:11:
@siepeltjuh Ik heb al jaren Sonos speakers en vlans en ik ken het verhaal. Vorig jaar heb ik een Android tablet gekocht (altijd ipads gehad) en merkte ik dat de Sonos controller gewoon werkt ook al zit mijn tablet op een andere vlan. Toevallig een paar weken geleden een cheapo ander tabletje gekocht op Ali (ook Android) en daar werkt het ook.

Dingen veranderen en howtos op internet zijn niet altijd up to date. 😉

Dat geloof ik allemaal direct. Echter is jouw situatie niet vergelijkbaar. Je hebt het over spotify en android, software dat ik niet gebruik. Ook bestaat de Unifi DreamMachine nog maar enkele maanden, informatie daarover is dan ook uptodate.

Voor de zekerheid net even met de werktelefoon van mijn vrouw geprobeerd (dat is wel android) en daar werkt het ook niet mee.

[Laagheim]

@siepeltjuh Maak verbinding met het WiFi netwerk waar je sonossen op zitten, start de Sonos app en wacht tot je verbinding. Sluit de app. Maak verbinding met je gewone wifi verbinding/vlan start de app en je hebt verbinding. Als het op een simpele teclast tablet werkt dan zal het ook wel werken op de telefoon van je vrouw. (andere tablet is een MediaPad 5, werkt al een jaar)

Spotify is gewoon een work around. In principe heb je de Sonos app niet nodig om muziek af te spelen, dat kan prima met de Spotify app.