Update Warnung

      danXde schrieb:

      @Schueli86 Wenn du im Router drin bist, kannst Du die iptables selbst korrigieren.
      1. DHCP-Server deaktivieren
      2. telnet in den Router
      3. iptables --list-rules | grep 169.0.0.0 -> wenn er was findet, die Regel löschen und gegen eine Regel mit 169.254.0.0/16 ersetzen.
      4. iptables -t nat --list-rules | grep 169.0.0.0 -> wenn er was findet, die Regel löschen und gegen eine Regel mit 169.254.0.0/16 ersetzen.
      5. iptables -t mangle --list-rules | grep 169.0.0.0 -> wenn er was findet, die Regel löschen und gegen eine Regel mit 169.254.0.0/16 ersetzen.
      Das sollte es gewesen sein.


      Alles, was ich bei mir im init script habe ist:

      Quellcode

      1. ip route add 169.254.0.0/16 dev br0
      2. ip route del 169.0.0.0/8 dev br0

      Damit kann ich alle 169.x.x.x IPs pingen.

      eMKay77 schrieb:

      @doridian: es ist also eigentlich eine Route und keine Regel?
      Frage nur aus Neugier - habe meinen DHCP an und nutze kein WhatsApp.

      mfg, emkay


      Das ganz eigentliche Problem ist, das das br0:sonstwas sub-interface als IP "169.x.x.x" mit Subnet-Mask "255.0.0.0" kriegt, was diese Route einfuegt (logischerweise).
      Man koennte also einfach die Subnet-Mask vom Interface anpassen. Aber ich bevorzuge es, einfach nur die Routen manuell zu fixen.
      Warum genau das Sub-Interface nur dann auftaucht, wenn DHCP aus ist, weiss ich nicht. Weil das Interface hat, wenn der DHCP-Server laeuft, nicht nur ne andere IP, es ist vollkommen deaktiviert (dann gibt es nur noch br0).

      P.S.: Ich brauche es nicht fuer WhatsApp, aber bei mir auf Arbeit haben wir Server in dem IP-Space bekommen... Und mit Home-Office und so geht das sonst nicht gut.

      Das Interface wird (vermute ich) nur aktiviert wenn DHCP deaktiviert ist, damit jemand der DHCP deaktiviert trotzdem noch mit dem Router kommunizieren kann, bzw. evtl. sogar in's Internet kommt (vorausgesetzt der pc nutz die zeroconf ip bereiche). Auch wenn es in meinen Augen cleverer wäre das nicht zu tun, da jemand der DHCP absichtlich deaktiviert, vermutlich weiß was er tut und seine IP Adressen manuell vergibt (oder bereits einen besseren dhcp Server betreibt).

      Vermutlich wird hier halt nur versucht, dem nicht so technisch versierten die Möglichkeit zu geben, dennoch irgendwie an den router zu kommen.

      Getestet hab ich das aber nicht, da ich die Informationen momentan noch nur über das Forum bekomme, da mein Anschluss erst am 29.06 geschaltet wird (hab noch Vertragslaufzeit beim alten Provider) :)

      kubax schrieb:

      Das Interface wird (vermute ich) nur aktiviert wenn DHCP deaktiviert ist, damit jemand der DHCP deaktiviert trotzdem noch mit dem Router kommunizieren kann, bzw. evtl. sogar in's Internet kommt (vorausgesetzt der pc nutz die zeroconf ip bereiche). Auch wenn es in meinen Augen cleverer wäre das nicht zu tun, da jemand der DHCP absichtlich deaktiviert, vermutlich weiß was er tut und seine IP Adressen manuell vergibt (oder bereits einen besseren dhcp Server betreibt).

      Vermutlich wird hier halt nur versucht, dem nicht so technisch versierten die Möglichkeit zu geben, dennoch irgendwie an den router zu kommen.

      Getestet hab ich das aber nicht, da ich die Informationen momentan noch nur über das Forum bekomme, da mein Anschluss erst am 29.06 geschaltet wird (hab noch Vertragslaufzeit beim alten Provider) :)


      Dann stellt sich nur die Frage, welcher Volldepp dachte, Zeroconf waere 169.0.0.0/8 und nicht 169.254.0.0/16 (ist uebrigends beim SP W724V, also dem "nicht-LTE"-Modell des Hybrid genau das gleiche)...

      doridian schrieb:


      Dann stellt sich nur die Frage, welcher Volldepp dachte, Zeroconf waere 169.0.0.0/8 und nicht 169.254.0.0/16 (ist uebrigends beim SP W724V, also dem "nicht-LTE"-Modell des Hybrid genau das gleiche)...


      Vermutlich der gleiche Depp, der es für eine gute Idee gehalten hat, das Interface einzurichten.. just 2b sure...
      Es scheint ja vllt. Nichtmals ne doofe Idee zu sein. Aber dann sollte man jedem die Möglichkeit geben, das auch wieder zu deaktivieren, falls jemand genau dieses verhalten eben nicht möchte :)

      Oder zumindest das Problem zeitnah zu löse. So schwer ist es ja nicht das zu Patchen ^^

      Schätze, die Idee war: wenn DHCP=an, dann Zeroconf per DHCP (damit ZeroC und DHCP sich nich ins Gehege kommen) - sonst normales ZeroConf.

      Lustig ist, wenn man das FileSystem per 'grep' durchsucht - findet man kein 169.0.0.0, nur ein paar Befehle um die richtige 169.254.0.0 als IPTables-Regel zu setzen. Wer die 169.0.0.0 setzt, konnte ich nich finden...
      EDIT: sorry, das Subinterface hatt ich überlesen... ;)

      EDIT2: eine Idee hab' ich noch - und hat sogar ne gewisse Logik :D
      der SPH ist ja ein 'Nachfahre' eines Huawei-HiLink-LTE-Sticks und diese funktionieren ohne Konfiguration als USB-Netzwerk-Link + Router...
      Defektes ZeroConf könnte also ein Überbleibsel davon sein.

      mfg, emkay

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „eMKay77“ ()

      Nein, das Interface wird ja irgendwie konfiguriert und aktiviert.
      Und beim konfigurieren wird dann vermutlich eine falsche Netzmaske angegeben. Beim konfigurieren legt Linux üblicherweise ein paar Routen an, damit das Interface auch erreichbar ist. Und da wird dann vermutlich der Fehler stecken.

      Wie gesagt, ich kann da auf keinem gerät was nachschauen, weil ich noch keinen Hybrid Router habe. Aber das was doridian schreibt, klingt für mich mehr als logisch.

      Ne Schnelle Suche ergab:

      Quellcode

      1. # busybox-mips grep -rnia '169\.254\.0\.0' .
      2. ./bin/cms:212430:iptables -D INPUT_SERVICE %s br0 -s 169.254.0.0/16 -j DROP 2>/dev/null
      3. ./bin/cms:212432:iptables -D FWD_SERVICE %s br0 -s 169.254.0.0/16 -j DROP 2>/dev/null
      4. ./bin/cms:212455:iptables -A INPUT_SERVICE %s br0 -s 169.254.0.0/16 -j DROP 2>/dev/null
      5. ./bin/cms:212457:iptables -A FWD_SERVICE %s br0 -s 169.254.0.0/16 -j DROP 2>/dev/null
      6. ./bin/cms:212548:iptables -A FWD_SERVICE -i br0 -d 169.254.0.0/16 -j DROP 2>/dev/null
      7. #
      8. #
      9. # busybox-mips grep -rnia 'ip route add' .
      10. ./bin/cms:210112:ip route add %s/%d dev %s src %s table %d 2>/dev/null
      11. ./bin/cms:214394:ip route add default dev %s t %d
      12. ./bin/cms:214398:ip route add default via %s dev %s t %d
      13. ./bin/cms:214892:ip route add default dev %s via %s table %d
      14. ./bin/cms:218946:ip route add %s/%d dev %s proto kernel scope link src %s table %d 2>/dev/null
      15. ./bin/cms:218950:ip route add 0/0 dev %s table %d 2>/dev/null
      16. ./bin/cms:218953:ip route add 0/0 table %d 2>/dev/null
      17. ./bin/cms:218955:ip route add 0/0 via %s dev %s table %d 2>/dev/null
      18. ./bin/cms:218959:ip route add 0/0 via %s table %d 2>/dev/null
      19. ./bin/cms:218997:ip route add %s dev %s src %s table %d 2>/dev/null
      20. ./bin/cms:219086:ip route add %s/%d table %d metric %d
      21. ./bin/web:40727:ip route add %s/%d table %d metric 1 via %s dev %s 2>/dev/null
      22. ./bin/web:40729:ip route add %s/%d table %d metric 1 dev %s 2>/dev/null
      23. ./bin/dhcpc:8373:ip route add %s/%s metric 1 via %s dev %s table %d
      24. ./bin/hybrid:22997:ip route add %s/32 via %s dev %s
      25. ./bin/hybrid:23017:ip route add default dev %s t %d

      leider nich so aufschlußreich, weil die Routen nich hardcoded sind...

      Naja, hauptsache der Workaround funktioniert ;)

      mfg, emkay

      Hmm.. ok, schade.

      Also den String 255.0.0.0 müsste er eigentlich schon finden. In deinem Quellcode beispiel wäre das z.b. dann das 2. %s also das hinter dem /

      Was aber sein kann, ist das nicht 255.0.0.0 genutzt wiurd, sondern /8 also das slash notation pendant der 255.0.0.0 jetzt müsste man ggf. nach 8 greppen, aber ich glaub da würde man ne ganze menge finden xD

      @doridian: ok, nur nach 169 hab' ich nich gesucht...
      das könnt man per Hex-Editor oder sogar SED im Binärmodus patchen ;)

      mfg, emkay

      EDIT: wollt' nochmal sichergehen:

      Quellcode

      1. # busybox-mips grep -rnia '169\.254\.' .
      2. ./bin/cms:212430:iptables -D INPUT_SERVICE %s br0 -s 169.254.0.0/16 -j DROP 2>/dev/null
      3. ./bin/cms:212432:iptables -D FWD_SERVICE %s br0 -s 169.254.0.0/16 -j DROP 2>/dev/null
      4. ./bin/cms:212455:iptables -A INPUT_SERVICE %s br0 -s 169.254.0.0/16 -j DROP 2>/dev/null
      5. ./bin/cms:212457:iptables -A FWD_SERVICE %s br0 -s 169.254.0.0/16 -j DROP 2>/dev/null
      6. ./bin/cms:212548:iptables -A FWD_SERVICE -i br0 -d 169.254.0.0/16 -j DROP 2>/dev/null
      7. ./bin/mic:7884:ifconfig br0:9 169.254.100.156 netmask 255.0.0.0 2> /dev/null
      8. ./bin/upnp:14622:ifconfig br0:9 169.254.100.156 netmask 255.0.0.0 2> /dev/null
      9. ./bin/upnp:14627:169.254.100.156
      10. ./bin/dhcpc:7715:ifconfig %s 169.254.%d.%d

      Man müsst' also wohl /bin/mic & /bin/upnp patchen - wenigstens bei Fehlern sind sie konsequent ;)
      EDIT: SHIT... jetzt fällt mir auf, daß es gar nich so leicht ist, aus 'ner einzelnen '0' eine '255' zu patchen...

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „eMKay77“ ()