hört sich ja gut an…. dann sollten wir ja bald load balancing bekommen

Zitat von BlackSpy

Übersetze ich mir das korrekt: Es wird nur intern getestet und es gibt wohl vorher keine Beta ?

hätte jetzt auch so gelesen dass da nicht mehr viel zeit verläuft und gleich die official version folgen soll von 2.5

Zitat von franzbertbua

dann sollten wir ja bald load balancing bekommen

Aber noch nicht mit der neuen FW 1.12.30, ich hab es gerade drauf gemacht.

Automatischer Restart der UDM-Pro, aber WLAN und Netzwerk waren die ganze Zeit da.

Updatedauer 5 Minuten.

Ich kann jetzt nicht so die großen Änderungen sehen, schaut aus wie vorher

Ansonsten, ja läuft - mehr kann ich dzt noch nicht sagen:

Außer das meine Uptime jetzt von 110 Tagen zurückgesprungen ist auf 15 Minuten, bedingt durch den autom. Restart der UDM-Pro

Zitat von Kurt-oe1kyw

Aber noch nicht mit der neuen FW 1.12.30, ich hab es gerade drauf gemacht.

Automatischer Restart der UDM-Pro, aber WLAN und Netzwerk waren die ganze Zeit da.

Updatedauer 5 Minuten.

Ich kann jetzt nicht so die großen Änderungen sehen, schaut aus wie vorher

Ansonsten, ja läuft - mehr kann ich dzt noch nicht sagen.

Außer das meine Uptime jetzt von 110 Tagen zurückgesprungen ist auf 15 Minuten, bedingt durch den autom. Restart der UDM-Pro

Alles anzeigen

ja load balancing kommt ja auch erst mit 2.5

aber steht ja dort dass die migration schon sehr weit fortgeschritten ist.

somit seh ich aktuell den schritt auf 1.12.30 als vorbereitung für 2.5

kurzer Zwischenbericht, auf meiner UDM-P läuft die FW 1.12.30 bisher völlig problemlos und einwandfrei.

Wie schon erwähnt, echtes load balancing geht noch nicht, aber failover funktioniert nach wie vor einwandfrei.

Simulierter WAN1 Ausfall > Umschaltung innerhalb von 3-4 Sekunden auf WAN 2 > WAN1 wieder angesteckt > abermals Zurückschalten von WAN2 auf WAN1 automatisch innerhalb von 3-4 Sekunden. Alles ok, bisher

Hallo

Macht das Update auf 1.12.30 das Bootscript unbrauchbar?

Erstellte Dateien bzw. Verzeichnise sind noch vorhanden, allerdings funktioniert bei erster Durchsicht das IP Masquerading nicht mehr.

Besten Dank!

hmm, seit gestern (Update?) läuft bei der DMpro aber der Lüfter durchweg. Gibt es da irgendwo eine Option die Kiste wieder ruhig zu stellen? Stand da was im Change Log zu, dass das Verhalten geändert wird?

edith sagt; ein Neustart hat das Problem behoben sehr mysteriös.

Zitat von BlackSpy

Spätestens beim Update auf OS2 brauchst du ne neue Idee, womöglich geht dann direkt alles per config.gateway.json

Habe kein Bootscript laufen, daher kann ich es nicht bestätigen

Nö Werde ja nicht müde da zu Wiedersprechen.

Die config.gateway.json ist bis heute nur dazu gut einem router die Config unterzuschieben

der auf EDGE OS / Vyatta basiert. Was in der UNFI Welt quasi nur USG3p und USG-Pro ist.

Schon die UxG fällt raus. Die ganzen UDM / DR Kisten machen das aber alle OHNE die EDGE OS mittelelschicht

direkt am Betriebssystem.

Zitat von BlackSpy

Habe eben gesehen das es auch Bootscript für die SE gibt, sollte daher auch bei einem Wechsel auf OS2 laufe

Jupp, nett wenn man einen haufen starten will aber es hindert dich erstmal nichts daran einfach ganz normale

Start Units anzulegen wie bei einem Systemd system üblich. Das Zeugs überlebt die Neustarts denn kein Container

Wie es nach einem FW update aussieht, wird sich für mich dann noch Zeigen. Bisher wurden wohl noch keine „eignen“

dinge weggelöscht wie eigne CRON Tabellen oder halt Start Units.

Zitat von BlackSpy

Habe eben gesehen das es auch Bootscript für die SE gibt, sollte daher auch bei einem Wechsel auf OS2 laufen

d.h. 1.12.30 geht das noch nicht, weil noch nicht 2.x?

besten Dank!

Nö, das heißt erstmal nur das Boot Script auch in der 2.x gehen werden. Jedenfalls wenn es das gleiche wird wie auf der SE/DR

Zitat von Amokd0c

allerdings funktioniert bei erster Durchsicht das IP Masquerading nicht mehr.

Das ist ein wenig unklar ausgedrückt. "IP Masquerading“ also (p)NAT ist eine elementare Funktion von allen UNIFI Routern die offiziell

nicht dafür vorgesehen ist ausgeschaltet zu werden. Menschen mit Router hinter ihren Unifi Routern möchten das trotzdem

weil sie, aus „Gründen^TM", kein doppelte NAT haben wollen.

Nun wenns nicht geht, dann war es Absicht und alles ist gut oder ?

Gut ich denke mir.. doof ausgedrückt er meint bestimmt das es nicht mehr abgeschaltet ist.

Da aber völlig unklar ist welches Bootscrit und welches „Mach mein NAT“ aus script du verwendest

ist es schwer hier zu helfen.

Aber Die typischen Steps sollten sein:

Läuft sein Boot Script wirklich noch ? da könnte man sich einfach ein Scriopt erstellen

das z.,b einfach nur „echo $(date)  >> /mnt/data/test.txt“ enthält

um zu schauen ob in der Datei nach dem Booten das aktuelle Datum drinsteht...

Wenn das noch funktioniert weiter zum anti NAT Script.

Üblicherweise werden entweder regeln in IPtables hinzugefügt um vor

den UNIFI Kram die Pakete durchzulassen um das NAT zu verhindern,

oder er wird Periodisch die UNFI Tabelle bereinigt die das Masquerading enthält.

evt. werden die Filter nun öfters überprüft und neugeschrieben.

iptables -L -t nat

gibt Aufschluss darüber. Interessant ist die

Chain POSTROUTING

in der steht meist nur ein Jump zur UBIOS_POSTROUTING_JUMP

Wenn dann steht ganz oben noch ein accept damit „unifi“ überspringen wird damit

effektiver (p)NAT ausgeschaltet wird.

Chain UBIOS_POSTROUTING_JUMP

in der steht meist nur ein Jump zu

Chain UBIOS_POSTROUTING_USER_HOOK

hier ist dann die Magie, entweder steht die

MASQUERADE Rolle noch drinnen oder nicht.

Vielleicht hilft es ein wenig... Sonst Warten Angesagt, dein Script Hersteller

wird wenn er noch aktive ist bestimmt was dazu sagen können...

Wirklich interessant! Danke für deine Erläuterungen!

Die Regel steht aber noch drinnen und wird m.E. akzeptiert!

So und nu?

Thema

Kommunikation Subnet x - Subnet y / Xiaomi Roborock - Iobroker

Servus zusammen!
Ich bin neu hier, und möchte mich kurz vorstellen.
Mein Name ist Johannes, bin 43 Jahre alt, meine Hobbies sind KNX Unifi, Technik die mir Lebenszeit spart!
2019 habe ich mein Netzwerk mit Unifi Komponenten aufgebaut. UDM-pro (vorher USG) US-48 Switch / US-24 Switch PoE 150W, 5 Unifi G3 Bullet Cams, 3 AP LR, 2 AP Mesh

Alles läuft bis dato tadellos, nur hänge ich aktuell an einem Problem, welches ich im Titel schon beschrieben habe.

Problem:
Xiaomi Roborock S7+ -> IoT Subnet…

Amokd0c

24. Juni 2022

Hier steht worum es geht.

Zitat von gierig

gibt Aufschluss darüber. Interessant ist die

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

UBIOS_POSTROUTING_JUMP all -- anywhere anywhere

MASQUERADE udp -- ubuntuiobroker roborock-vacuum-a15 masq ports: 54321

Da soll ich also nun lesen worum es geht, was es genau los ist anstatt du das in zwei Sätzen

beschreibst was du gemacht hast. Aber gut...ich bin ja nicht so...

Also spezielle NAT regeln für den inneren Verkehr und die funktionierte bis zum Update:

iptables -t nat -A POSTROUTING -s IPAdresseIOBroker/32 -d IPAdresseRoborock/32 -p UDP -j MASQUERADE --to-ports 54321

Dein Print zeigt aber das die Regel NIEMALS greifen wird.

„UBIOS_POSTROUTING_JUMP all“ lässt das Paket in diese Chain springen

und danach noch in eine andere. Da wird da system (p)NAT gemacht und fertig ist die Laube.

Bearbeitung beendet.

Dein Script startet also später als der UNIF kram (das soll er eigentlich auch).

Und das wahr vorher scheinbar „anders“ (wie auch immer geartet)

Ändere mal bitte dein Script in:

iptables -t nat -I POSTROUTING 1 -s IPAdresseIOBroker/32 -d IPAdresseRoborock/32 -p UDP -j MASQUERADE --to-ports 54321

Das ist die gleiche Regel. Das „-I“ (großes „i“) macht ein Insert und die „1" nach POSTROUTING sorgt dafür das die Regeln an erster

stelle steht, in der Kette. Damit sollte es VOR den UNIF Regeln kommen und dann greifen wenn es passt.

Abermals dickes Danke!

Allerdings keine Wirkung ...

Ich kenn mich da viel zu wenig aus.

Es muss nur was mit Update zu tun haben, da ich alles andere ausschließen kann.

Hänge ich den Roborock übers WLAN ins gleiche Subnet wie der IO Broker funktioniert das.

Das war ja vorher auch schon so. Nur hätte ich das gerne getrennt.

Steht denn die Regel auch nun aperster stelle ?

also:

# iptables -L POSTROUTING -t nat 

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE udp -- ubuntuiobroker roborock-vacuum-a15 masq ports: 54321
UBIOS_POSTROUTING_JUMP  all  --  anywhere             anywhere