IGMP SSDP packet mangling mit fli4l

[K. Dreier]

Hallo,

(4-testing aktuell)

Ich versuche weiterhin mein Problem mit IoT-GerÀten im IoT-VLAN zu
lösen. Es gibt scheinbar ein Problem mit multicast was dazu fÌhrt,
daß gewisse GerÀte das GefÃŒhl haben, sie seien offline.
Ich lese, daß eine Lösung im zusammenhang mit SSDP Paketen liegen
könnte mit dem Problem, daß diese teilweise mit einem TTL von 1 statt
4 geschickt werden, was scheinbar beim Routing zu Problemen fÃŒhrt.
Manche schlagen vor, die folgende Regel in der Firewall einzupflegen, um
den TTL auf 4 "anzuheben":

iptables -A PREROUTING -t mangle -i eth1 -d 239.255.255.250 -j TTL
--ttl-set 4

Wie immer habe ich das Problem, daß ich diese Regeln in die
fli4l-Firewall-Logik ÃŒbersetzen muß. Kann mir da jemand helfen? Mein
fli4l sitzt im eth1 und mein IoT-Vlan wÀre eth1.30 (= NET_5 im fli4l).

Die nÀchste Frage in diesem Zusammenhang: muß ich zwingend den
igmp-proxy aktivieren oder kann ich multicast zwischen (V)LANs auch
anderweitig herbeifÃŒhren?

Danke fÃŒr euer Input,

Gruß
Klaus

[Sebastian Klein]

Post by K. Dreier
Hallo,
(4-testing aktuell)
Ich versuche weiterhin mein Problem mit IoT-GerÀten im IoT-VLAN zu
lösen. Es gibt scheinbar ein Problem mit multicast was dazu fÌhrt,
daß gewisse GerÀte das GefÃŒhl haben, sie seien offline.
Ich lese, daß eine Lösung im zusammenhang mit SSDP Paketen liegen
könnte mit dem Problem, daß diese teilweise mit einem TTL von 1 statt
4 geschickt werden, was scheinbar beim Routing zu Problemen fÃŒhrt.
Manche schlagen vor, die folgende Regel in der Firewall einzupflegen, um
iptables -A PREROUTING -t mangle -i eth1 -d 239.255.255.250 -j TTL
--ttl-set 4
Wie immer habe ich das Problem, daß ich diese Regeln in die
fli4l-Firewall-Logik ÃŒbersetzen muß. Kann mir da jemand helfen? Mein
fli4l sitzt im eth1 und mein IoT-Vlan wÀre eth1.30 (= NET_5 im fli4l).

Das kann man leider mit der normalen fli4l-config nicht erschlagen, aber
da wÀre dein Ansprechpartner OPT_USRCMD da kannst du dann die obige
Regel einfach eintragen:

USERCMD_BOOT_1='iptables -A PREROUTING -t mangle -i eth1.30 -d
239.255.255.250 -j TTL --ttl-set 4'

Post by K. Dreier
Die nÀchste Frage in diesem Zusammenhang: muß ich zwingend den
igmp-proxy aktivieren oder kann ich multicast zwischen (V)LANs auch
anderweitig herbeifÃŒhren?

da bin ich leider auch ÃŒberfragt...

--
Sebastian
[fli4l-Team]

[K. Dreier]

Hallo,

Post by Sebastian Klein
Das kann man leider mit der normalen fli4l-config nicht erschlagen, aber
da wÀre dein Ansprechpartner OPT_USRCMD da kannst du dann die obige
USERCMD_BOOT_1='iptables -A PREROUTING -t mangle -i eth1.30 -d
239.255.255.250 -j TTL --ttl-set 4'

Oh, auf die Idee wÀre ich jetzt aber nie gekommen! Ich kann also im
Prinzip jeden CLI Befehl einfach dort so eintragen und das wird (als
root) ausgefÃŒhrt? Sehr gut zu wissen! Spart das Anlegen und managen von
Skripten.

Post by Sebastian Klein

Post by K. Dreier
Die nÀchste Frage in diesem Zusammenhang: muß ich zwingend den
igmp-proxy aktivieren oder kann ich multicast zwischen (V)LANs auch
anderweitig herbeifÃŒhren?

da bin ich leider auch ÃŒberfragt...

Es ist schon interessant, daß es scheinbar bei den fli4l Usern
niemanden gibt, der mit IoT-GerÀten zusammen mit VLANs unterwegs ist
und somit die ÃŒblichen Problem hat wie zig andere User bei anderen
Routern/Firewalls, z.B. mit Sonos usw. Bei mir geht es schon damit los,
daß z.B. mein AVR-App den AVR im anderen LAN nicht sieht und das obwohl
ich explizite Forward-Regeln gesetzt habe, die das erlauben mÃŒssten.
Aber scheinbar schiesst da das multicast-Problem quer. Interessant
einfach, daß niemand sonst das Problem hier hat, denn sonst gÀbe es ja
entweder andere Anfragen oder zumindest mal Hilfestellung von denen, die
es zum Laufen gebracht haben. Habe das Problem seit Jahren... (und
entsprechend schon vor langer Zeit hier dazu gefragt, ohne Ergebnis
natÃŒrlich)

Gruß
Klaus

[Peter Schauder]

Moin,
doch, es gibt auch andere mit diesen Problemen. Bei mir: Bose Soundbar
ist in einem anderen VLAN wie die Handys...dann finden sie sich halt
nicht. Da ich aber größere Probleme habe, sind sie jetzt halt in ein
eigens VLAN gesperrt. Ich hatte nicht wirklich Lust und Zeit, die
mechanismen, die BOSE benutzt auseinanderzuhäkeln. Die Doku dazu ist
ja eher rudimentär, wenn überhaupt vorhanden.

Aber du kannst versichert sein, ich lese interessiert mit, lerne und
wenn ich Ideen habe, steuere ich sie zu.

Gruß
Peter

Es ist schon interessant, daß es scheinbar bei den fli4l Usern
niemanden gibt, der mit IoT-Geräten zusammen mit VLANs unterwegs ist
und somit die üblichen Problem hat wie zig andere User bei anderen
Routern/Firewalls, z.B. mit Sonos usw. Bei mir geht es schon damit los,
daß z.B. mein AVR-App den AVR im anderen LAN nicht sieht und das obwohl
ich explizite Forward-Regeln gesetzt habe, die das erlauben müssten.
Aber scheinbar schiesst da das multicast-Problem quer. Interessant
einfach, daß niemand sonst das Problem hier hat, denn sonst gäbe es ja
entweder andere Anfragen oder zumindest mal Hilfestellung von denen, die
es zum Laufen gebracht haben. Habe das Problem seit Jahren... (und
entsprechend schon vor langer Zeit hier dazu gefragt, ohne Ergebnis
natürlich)
Gruß
Klaus

[K. Dreier]

"You're not alone..." :d

Danke fÌrs Feedback. Sollte ich je eine Lösung finden, die wirklich
was taugt, werde ich das hier melden!

[Kay Martinen]

Die nächste Frage in diesem Zusammenhang: muß ich zwingend
den
igmp-proxy aktivieren oder kann ich multicast zwischen (V)LANs auch
anderweitig herbeiführen?

Routing/Forwarding vielleicht?

Es ist schon interessant, daß es scheinbar bei den fli4l Usern
niemanden gibt, der mit IoT-Geräten zusammen mit VLANs unterwegs ist

Nicht jeder braucht diese IdiotOfThings Gadgets, weißt du!?

und somit die üblichen Problem hat wie zig andere User bei anderen
Routern/Firewalls, z.B. mit Sonos usw. Bei mir geht es schon damit los,

Ich verwende derzeit keinen FLI (mehr) sondern OPNsense. Da kann man
auch einen igmpproxy nachinstallieren. Und AFAIR auch etwas für multicast...

daß z.B. mein AVR-App den AVR im anderen LAN nicht sieht und das obwohl
ich explizite Forward-Regeln gesetzt habe, die das erlauben müssten.
Aber scheinbar schiesst da das multicast-Problem quer.

Bist du sicher das du ein IGMP Problem hast, oder evtl. einfach nur ein
Multicast-Problem. Ich denke das mcast prinzipiell in dem Netz bleibt in
dem es auftritt und IGMP ist nur zur Koordinierung von mcast-gruppen
erforderlich. Wenn du also IGMP für die beteiligten Netze aktivierst
dann musst du evtl. auch noch multicast-adressen oder bereiche
forwarden. Sonst kommt evtl. der traffic vom einen netz nicht ins
andere. DANN könnte man mcast-sender und empfänger aber auch einfacher
in ein einzelnes netz einsperren.

Ist nur meine Vermutung nach überfliegen der Wikipedia-artikel zu IGMP
und Multicast.


Kay

[Michael Wieser]

Post by Kay Martinen

Post by K. Dreier
Routern/Firewalls, z.B. mit Sonos usw. Bei mir geht es schon damit los,

Ich verwende derzeit keinen FLI (mehr) sondern OPNsense. Da kann man
auch einen igmpproxy nachinstallieren. Und AFAIR auch etwas für multicast...

was war Dein Grund nach Opensense zu migrieren?

Danke für eine kurze Erläuterung

-
Michael Wieser
--

[Kay Martinen]

Post by Michael Wieser

Post by Kay Martinen

Post by K. Dreier
Routern/Firewalls, z.B. mit Sonos usw. Bei mir geht es schon damit los,

Ich verwende derzeit keinen FLI (mehr) sondern OPNsense. Da kann man
auch einen igmpproxy nachinstallieren. Und AFAIR auch etwas für multicast...

was war Dein Grund nach Opensense zu migrieren?

Ein neuer Internet-anschluß mit IPv6, Interne VLANs und der Wunsch das
alles flexibler konfigurieren zu können - ohne durch Reboots
unterbrochene Trial & Error sessions. Eben mit einer WebGUI die nicht
nur anzeigt sondern auch alles konfigurierbar macht. Dazu MultiWAN
(CARP) Fähig und High-availability Features gibt es auch. Z.b. einen
Echten OPN und eine VM zu verbinden und wenn der Echte ausfällt könnte
die VM sofort übernehmen.

Post by Michael Wieser
Danke für eine kurze Erläuterung

FLI kann m.W. nicht vollständig IPv6 und Präfixdelegation IMHO auch
nicht. Eben das nun nutzen und konfigurieren zu können war der Hauptgrund.

Leider stellte sich inzwischen raus das der Zwangsläufig vorgeschaltete
Router nur ein einzelnes /64 (aus einem zugeteilten /56) nach innen raus
rückt. Und das kann man wohl nicht sinnvoll unterteilen wenn diverse
IPv6 Sachen nicht auf die Nase fallen sollen. PD, oder ein radvd und
dhcpd6 sind damit also nicht zum laufen zu kriegen - wie ich eigentlich
hoffte.

Bevor einer Fragt, nein: Einen Anderen Router gibt es nicht (für DSL+LTE
Hybrid) und der ist hier damit die einzige Möglichkeit!

Kay

[K. Dreier]

Hallo,

zunÀchst danke.

Nicht jeder braucht diese IdiotOfThings Gadgets, weißt du!?

Habe ich auch nirgendwo geschrieben oder verlangt. Es gibt aber
definitiv genug Leute, die das _haben_ und gerade auch dort - primÀr
weil es oftmals (noch) relativ sinnlose Spielerei ist - genug Leute, die
sich sehr gut mit Netzwerken usw. auskennen, also insofern auch
komplexere Setups fahren. Gerade auch im Kontext von fli4l, der ja nun
weiss Gott keine maintream-Software ist.

Ich verwende derzeit keinen FLI (mehr) sondern OPNsense.

Ich bin zugegebenermassen auch etwas skeptisch, ob ich noch lange bei
fli4l bleiben werde. Ich habe einfach ÃŒber die sehr lange Zeit
mittlerweile ein Setup, das - Spielereien außen vorgelassen -
hervorragend funktioniert und mir alles liefert, was ich brauche. Es
graut mich also etwas davor, hier einen Wechsel des Tools/der Software
vorzunehmen. Wie war das, never touch a running system... Aber
vielleicht setze ich demnÀchst einfach mal eine Test-Box mit einem
OPNsense auf. Kann ja nichts schaden.

Bist du sicher das du ein IGMP Problem hast, oder evtl. einfach nur
ein Multicast-Problem.

Überhaupt nicht sicher, ist ja letztlich genau das, was ich versuche
herauszufinden. Da ich aber kein Netzwerk-Profi bin, ist mein
VerstÀndnis dessen, was ich Ìberhaupt (wie!) tun kann, leider sehr
beschrÀnkt.

Ich denke das mcast prinzipiell in dem Netz bleibt in
dem es auftritt

So verstehe ich das auch.

und IGMP ist nur zur Koordinierung von mcast-gruppen
erforderlich.

Was wÀre denn eine mcast-_Gruppe_?

Wenn du also IGMP fÃŒr die beteiligten Netze aktivierst
dann musst du evtl. auch noch multicast-adressen oder bereiche
forwarden.

Was ja unnötig komplex wÀre, wenn man das Thema schon alleine mit
einem forwarden erreichen könnte. Ich werde da mal weiter basteln. Denn
letztlich ist das ein Thema, das ja nicht mit fli4l per se
zusammenhÀngt und bei z.B. OPNsense genauso wÀre. Da gibt es
allerdings ein entsprechendes plugin, das das wohl ganz einfach
einrichtet, wie ich gerade gesehen habe.

Gruß
Klaus