Ja, aber zunächst warte ich ab, was konkret gebaut wird. Mit oder ohne Gf-Dose. Und dann schaue ich mir das Prozedere an.
Beiträge von mbo77
-
-
Sobald der Anschluss einigermaßen läuft, werde ich das Spiel sicherlich mal starten.
Aber das ist aktuell nicht die wesentliche Baustelle. Erstmal sollen die überhaupt was liefern.
-
Es gibt einen Default-Wert, der aber nicht genauer beschrieben ist. Dann beträgt die Dauer 24 Stunden. Ob die pauschal gesetzt ist oder vom APN kommt, keine Idee.
Aber damit kann ich ja nichts mitloggen, außer ich stelle mir einen Wecker. Da war das so schon zielführend.
-
Da kann ich ja eigentlich froh sein, dass Weser Connect in dem Stadtteil in Minden nicht ausbaut, sondern GFNW. Gestern wurde der HÜP gesetzt und letztes Jahr im wurden die Leerrohre in allen Straßen des Stadtteils gelegt.
Ja, da würde ich sofort tauschen.
-
Das war die von mir verkürzte Dauer, um den Renewal zu provozieren.
-
Super Hinweis, das scheint die Lösung zu sein. Hier ein Renewal:
Code
Alles anzeigen16:15:16.509058 82:62:a4:e2:85:c0 > 78:c5:7d:49:d2:98, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 959, offset 0, flags [DF], proto UDP (17), length 328) 10.143.196.88.68 > 10.143.196.89.67: [bad udp cksum 0x9f15 -> 0x5f44!] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0xc469a705, Flags [none] (0x0000) Client-IP 10.143.196.88 Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request MSZ (57), length 2: 576 Parameter-Request (55), length 8: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12) Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121) Hostname (12), length 4: "bpi4" Vendor-Class (60), length 12: "udhcp 1.36.1" 16:15:16.562334 78:c5:7d:49:d2:98 > 82:62:a4:e2:85:c0, ethertype IPv4 (0x0800), length 360: (tos 0xc0, ttl 64, id 48450, offset 0, flags [none], proto UDP (17), length 346) 10.143.196.89.67 > 10.143.196.88.68: [udp sum ok] BOOTP/DHCP, Reply, length 318, xid 0xc469a705, Flags [none] (0x0000) Client-IP 10.143.196.88 Your-IP 10.143.196.88 Server-IP 10.143.196.89 Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK Server-ID (54), length 4: 10.143.196.89 Lease-Time (51), length 4: 120 RN (58), length 4: 54 RB (59), length 4: 99 Subnet-Mask (1), length 4: 255.255.255.240 BR (28), length 4: 10.143.196.95 Domain-Name (15), length 14: "home" Hostname (12), length 4: "bpi4" Domain-Name-Server (6), length 8: 10.74.210.210,10.74.210.211 Default-Gateway (3), length 4: 10.143.196.89Was ist da der genaue Hintergrund?
-
Das fortlaufende Chaos habe ich hier ja dokumentiert. Es wundert mich also gar nichts.
Und das Gebahren mit dem ONT ergänzt das Bild in traurige Art und Weise. Ich suche ja immer noch nach einem aktiven Teilnehmer, damit man mal die Qualität des Netzes beurteilen kann.
Ewiger Optimist, der ich nun mal bin, hoffe ich auf Anschluss in den nächsten vier Wochen. Technik ist hier wohl ok, die Hausanschlüsse werden nur noch über die KVz realisiert. Vor ein paar Wochen war noch reges Treiben am PoP. Ich tippe darauf, dass die KVz samt Splitter an ihr Ports gespleist wurden. Daher können die Hausanschlüsse nun ohne Arbeit am PoP in Betrieb gehen.
-
In Schlüsselburg sind die Tiefbauarbeiten noch nicht abgeschlossen.
Das beträfe dann deinen eigenen Anschluss oder bist du schon angeschlossen?
Laut Aussage des Technikers sollen im Ortsgebiet Petershagen rund 100 Anschlüsse im Betrieb sein. Glaube ich erst, wenn ich via Layer 3 auch eine Verbindung sehe.
-
Du solltest noch erwähnen, das Deutsche Glasfaser der Provider ist...
Mal so nebenbei: Woran hast du das festgemacht?
-
Was mich daran ohnehin am meisten nervt: Das Subnetz auf der ungetaggted Bridge brauche ich überhaupt nicht. Für die Administration nutze ich das VLAN 2. Initial kommt man immer für 30 Minuten über WLAN auf das System.
Die DHCP-Funktion muss eigentlich erst dann aktiviert werden, wenn im WAN eine Verbindung besteht.
Ich werde jetzt vermutlich auf einen langen Lease wechseln (mindesten 24h) und mittels watchcat das Interface im OpenWRT überwachen und neustarten, wenn was in die Hose geht.
-
Soweit richtig analysiert, danke für die Bestätigung meiner Vermutung.
Somit ergeben sich zwei Zielkonflikte in der aktuell realisierten Konfiguration: Um von der Adresse der lokalen Bridge (192.168.1.0/24) weg zu kommen, braucht es einen kurzen Lease, meinetwegen 2-5 Minuten. Damit kann ich nach Reboot leben.
Schwerwiegender ist die verkorkste DHCP-Proxy/Relay Funktion. Dafür möchte ich eigentlich einen möglichst langen Lease haben. Aber auch da gilt, dass ein langer Lease stören kann, wenn der APN eine neue Adresse vergibt. Dann müsste zumindest der Zyxel die Verbindung kurz unterbrechen, um einen Reconnect zu erzwingen.
Ich habe das mal in der Zyxel Community als Frage platziert, erwarte da aber nicht allzu viel.
-
Mit der Adressvergabe hat das nichts zu tun. Bei uns haben noch einige (wenige) Kunden eine PPPoE Einwahl und haben trotzdem danach CGNAT. Ich meine Purtel/DGN machen das auch so.
Leasetime bei EON Highspeed sind afaik 3600s bzw 1800s bei IPv6.Hehe, ich hatte diese Spitzfindigkeit fast schon erwartet und habe überlegt, wie ich es präzise formuliere.
-
Frustrierenderweise sieht es auf dem administrativen Netz besser aus:
Code
Alles anzeigentcpdump: listening on br-lan.2, link-type EN10MB (Ethernet), snapshot length 262144 bytes 09:15:45.888986 82:62:a4:e2:85:c0 > 78:c5:7d:49:d2:98, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 32690, offset 0, flags [DF], proto UDP (17), length 328) 192.168.2.140.68 > 192.168.2.1.67: [bad udp cksum 0x8723 -> 0xa775!] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0x5804163, Flags [none] (0x0000) Client-IP 192.168.2.140 Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request MSZ (57), length 2: 576 Parameter-Request (55), length 8: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12) Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121) Hostname (12), length 4: "bpi4" Vendor-Class (60), length 12: "udhcp 1.36.1" 09:15:45.951071 78:c5:7d:49:d2:98 > 82:62:a4:e2:85:c0, ethertype IPv4 (0x0800), length 346: (tos 0xc0, ttl 64, id 39775, offset 0, flags [none], proto UDP (17), length 332) 192.168.2.1.67 > 192.168.2.140.68: [udp sum ok] BOOTP/DHCP, Reply, length 304, xid 0x5804163, Flags [none] (0x0000) Client-IP 192.168.2.140 Your-IP 192.168.2.140 Server-IP 192.168.2.1 Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK Server-ID (54), length 4: 192.168.2.1 Lease-Time (51), length 4: 120 RN (58), length 4: 55 RB (59), length 4: 100 Subnet-Mask (1), length 4: 255.255.255.0 BR (28), length 4: 192.168.2.255 Default-Gateway (3), length 4: 192.168.2.1 Domain-Name (15), length 4: "home" Hostname (12), length 4: "bpi4" Domain-Name-Server (6), length 4: 192.168.2.1Hier wird der Renewal offenbar sauber bestätigt. Die Frage ist, weshalb das im Passthrough nicht funktioniert.
Das würde mich ja nicht sonderlich stören, wenn das ganze Setup ohnehin nicht merkwürdig wäre.
Solange noch kein Login zum APN erfolgt ist (nach Reboot), bekommt das Interface erstmal einen Lease vom definierten Subnetz auf der Bridge. Die DHCP-Option muss aktiviert sein, sonst bedient der auch nicht den Passthrough.
Stelle ich den Lease also zu hoch (z.B. stündlich), dann habe ich zunächst erstmal nur eine IP vom Zyxel oder muss das Interface manuell neu starten.
Stelle ich den Lease auf 2 Minuten, ist das natürlich auch nach Reboot ok, kommt dann aber zum beschriebenen Schluckauf, da der Renewal fehlschlägt.
Die Anbindung ist eigentlich stabil, sodass ich auch mit einem Lease über einen Tag gut arbeiten könnte. Kommt es aber doch mal zum Relogin zum APN oder der triggert eine neue IP, dann hängt die Verbindung bis zu einem halben Tag.
Ich werde das Verhalten mal im Zyxel-Forum anfragen. Aber wie ich in meinem Erfahrungsbericht schon schrieb: Software und Support sind eher schlecht. Liegt vielleicht auch daran, dass Zyxel die HW eigentlich nur an Provider herausgibt.
-
So, Verdacht bestätigt.
Code
Alles anzeigentcpdump: listening on br-lan.57, link-type EN10MB (Ethernet), snapshot length 262144 bytes 09:01:58.498998 82:62:a4:e2:85:c0 > 78:c5:7d:49:d2:98, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 41947, offset 0, flags [DF], proto UDP (17), length 328) 10.132.0.189.68 > 10.132.0.190.67: [bad udp cksum 0x17c8 -> 0x55f5!] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0xa2551d5d, Flags [none] (0x0000) Client-IP 10.132.0.189 Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request MSZ (57), length 2: 576 Parameter-Request (55), length 8: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12) Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121) Hostname (12), length 4: "bpi4" Vendor-Class (60), length 12: "udhcp 1.36.1" 09:01:58.501860 78:c5:7d:49:d2:98 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0xc0, ttl 64, id 47510, offset 0, flags [none], proto UDP (17), length 328) 192.168.1.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xa2551d5d, Flags [Broadcast] (0x8000) Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: NACK Server-ID (54), length 4: 10.132.0.190 MSG (56), length 15: "lease not found" 09:02:01.720781 82:62:a4:e2:85:c0 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0x45f45508, Flags [none] (0x0000) Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover MSZ (57), length 2: 576 Parameter-Request (55), length 8: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12) Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121) Hostname (12), length 4: "bpi4" Vendor-Class (60), length 12: "udhcp 1.36.1" 09:02:01.731156 78:c5:7d:49:d2:98 > 82:62:a4:e2:85:c0, ethertype IPv4 (0x0800), length 344: (tos 0xc0, ttl 64, id 4398, offset 0, flags [none], proto UDP (17), length 330) 192.168.1.1.67 > 10.132.0.189.68: [udp sum ok] BOOTP/DHCP, Reply, length 302, xid 0x45f45508, Flags [none] (0x0000) Your-IP 10.132.0.189 Server-IP 10.132.0.190 Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer Server-ID (54), length 4: 10.132.0.190 Lease-Time (51), length 4: 120 RN (58), length 4: 60 RB (59), length 4: 105 Subnet-Mask (1), length 4: 255.255.255.252 BR (28), length 4: 10.132.0.191 Domain-Name (15), length 4: "home" Domain-Name-Server (6), length 8: 10.74.210.210,10.74.210.211 Default-Gateway (3), length 4: 10.132.0.190 09:02:01.820762 82:62:a4:e2:85:c0 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0x45f45508, Flags [none] (0x0000) Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request Requested-IP (50), length 4: 10.132.0.189 Server-ID (54), length 4: 10.132.0.190 MSZ (57), length 2: 576 Parameter-Request (55), length 8: Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12) Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121) Hostname (12), length 4: "bpi4" Vendor-Class (60), length 12: "udhcp 1.36.1" 09:02:01.867567 78:c5:7d:49:d2:98 > 82:62:a4:e2:85:c0, ethertype IPv4 (0x0800), length 350: (tos 0xc0, ttl 64, id 4408, offset 0, flags [none], proto UDP (17), length 336) 192.168.1.1.67 > 10.132.0.189.68: [udp sum ok] BOOTP/DHCP, Reply, length 308, xid 0x45f45508, Flags [none] (0x0000) Your-IP 10.132.0.189 Server-IP 10.132.0.190 Client-Ethernet-Address 82:62:a4:e2:85:c0 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK Server-ID (54), length 4: 10.132.0.190 Lease-Time (51), length 4: 120 RN (58), length 4: 60 RB (59), length 4: 105 Subnet-Mask (1), length 4: 255.255.255.252 BR (28), length 4: 10.132.0.191 Domain-Name (15), length 4: "home" Hostname (12), length 4: "bpi4" Domain-Name-Server (6), length 8: 10.74.210.210,10.74.210.211 Default-Gateway (3), length 4: 10.132.0.190Das erste Paket scheint mir der Renewal-Request zu sein. Das wird allerdings mit einem NACK/Lease not found gekontert und danach geht das Interface down und ein neuer Request wird gestartet.
So weit, so schade.
-
Evtl. ist die Frage, wie der Zyxel-IP Passthrough Mode im Detail arbeitet. Denkbar wäre ja, dass der Zyxel DHCP-Renews/Rebinds oder deren Replies von der Gegenstelle nicht weiterleitet (warum auch immer), so dass der OpenWRT regelmäßig in Lease-Timeouts liefe (bei DG alle 3600s sowohl für IPv4, als auch für IPv6). Es käme dann jeweils zu Netzunterbrechungen, solange, bis in einem neuen DHCPv4/DHCPv6-Exchange (der offenbar mit IP Passthrough funktioniert) wieder IP- bzw IPv6-Adressen zur Verfügung stehen (hoffentlich dieselben wie zuvor).
Nur so ein Gedanke, der die Beobachtungen erklären könnte.
Ich habe jetzt mal einen genaueren Blick darauf geworfen und das scheint deine Vermutung zu stützen. Ich denke, dass der DHCP-Renewal nicht implementiert ist. Ich habe mal den Lease auf 120 Sekunden gesenkt.
Code
Alles anzeigen64 bytes from 8.8.8.8: seq=50 ttl=112 time=17.671 ms ping: sendto: Network unreachable <= Interface geht verloren, ping scheitert PING 8.8.8.8 (8.8.8.8): 56 data bytes ping: sendto: Network unreachable <= Noch down nach sleep 1 PING 8.8.8.8 (8.8.8.8): 56 data bytes ping: sendto: Network unreachable <= Noch down nach sleep 1 PING 8.8.8.8 (8.8.8.8): 56 data bytes ping: sendto: Network unreachable <= Noch down nach sleep 1 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=112 time=20.373 ms <= Interface wieder da 64 bytes from 8.8.8.8: seq=1 ttl=112 time=17.535 ms 64 bytes from 8.8.8.8: seq=10 ttl=112 time=16.651 ms <= 9 Pakete (=9 Sekunden) gehen verlorenDas Interface in OpenWRT geht down und ich habe in der Schleife einen Sleep von 1 Sekunde zwischen dem erneuten Aufruf des Pings gesetzt. Das Interface ist nach 3 Sekunden wieder da. In Summe mit den verlorenen Paketen sind es gut 12 Sekunden. Ich teste mal eine TCP-Verbindung währenddessen.
Und gleich noch einen tcpdump währenddessen.
-
Heute nicht mehr, vielleicht morgen.
-
Das ist ja auch, was mich irritiert. Daher wollte ich mal aus der Praxis abgleichen.
-
Der Renew sollte ja eigentlich nur die bestehende Adresse erneuern. Kommt es da zu spürbaren Unterbrechungen oder Verzögerungen auf bestehenden (TCP-) Verbindungen?
Der Hintergrund meiner Frage ist, dass ich das im Zusammenspiel OpenWRT und Zyxel Nr7302 (IP-Passthrough mittels DHCP) durchaus wahrnehme.
-
Hier sind ja einige bei Providern unterwegs, die mit CGNAT arbeiten. Ich nehme gerade etwas naiv an, dass diese immer mit DHCP statt PPPoE arbeiten.
Wie sieht es da typischerweise mit der Lease-Time aus? Minuten, Stunden, Tage? Wie sind da eure Erfahrungen? Habt ihr da kurzfristige Unterbrechungen beim Renewal erfahren?
-
Internetzugang fuer 5 Euro/Monat, das erscheint mir ausnehmend guenstig, ich hoffe Du hast das Angebot angenommen...
SCNR
Um das Dilemma in der aktuellen Situation darzulegen: Tatsächlich zahle ich für Internet 700/100 aktuell lediglich 5 €/Monat. Das sind die Kosten der Multi-SIM.
Vorausgesetzt ich betrachte den Mobilfunkvertrag unter "Ehda"-Kosten.
