|
-- Veröffentlicht durch nik am 1:22 pm am Sep. 27, 2004
Hi Forum,
ich habe Cablecom und den wireless Router wgt624 von Netgear im Einsatz. Der Router ist als DHCP Server fürs eigene Netz aktiviert. Nun ist es so, dass im LAN alles ok läuft. Heisst die Leases werden vergeben und die angeschlossenen Rechner und Printserver funzen mit einander.
Das Problem liegt in der WAN Verbindung. Und zwar wird der Lease von Cablecom nach Ablauf (1h) nicht mehr erneuert. Den Router kann man so konfigurieren, dass er eine konstante Verbindung aufbaut oder nur wenn WAN Traffic auftaucht. In beiden Fällen bekommt das Gerät eine Erneuerung des Lease nich hin. Habe die Firmware abgedatet und die verschiedenen Konfigurationen durchprobiert - immer das gleiche Ergebnis. Interessant ist auch, dass wenn der Lease abgelaufen ist, der "Refresh" des Lease per Httpsite des Routers nicht funktioniert. Ich muss immer erst den Lease freigeben und dann einen neu anfordern (beides per httpsite router)- dann gehts.
Jmd ähnliche Erfahrung evt. mit Lösungsansätzen?
thx alot
Nik
-- Veröffentlicht durch hotting am 8:46 am am Sep. 30, 2004
Nein. Eine Lösung habe ich keine. Allerdings ein sehr ähnliches Problem, wegen dem ich nun schon seit einiger Zeit mit dem Hispeed-support im Kontakt bin (ohne dass die mir bisher helfen konnten).
Ich verwende eine Zywall 10, welcher es nicht mehr gelingt, den Lease zu verlängern. Der Lease läuft aus, und ca. 7 Sekunden später kann sich die Zywall wieder einen neuen Lease besorgen. Allerdings sind in diesen 7 Sekunden natürlich sämtliche offenen Connections (bei mir primär SSH und IMAP, KEINERLEI P2P) zusammengebrochen...
Zudem konnte ich verifizieren, dass meine Zywall 10 versucht, ordnungsgemäss die DHCP-Lease zu verlängern, was ihr problemlos gelingt, wenn ich ein anderes (mit DHCP versehenes) Netz an deren WAN-Seite anschliesse. Zudem habe ich meine Zywall-Konfiguration mit dem Support von Studerus kontrolliert, der diese für i.O. und hispeed-konform erklärt hat. Auch die aktuellste Firmware ist drauf.
Interessanterweise kann ich folgenden Zusammenhang feststellen:
Die Zywall hat während mehreren Jahren nun weitestgehend problemlos funktioniert, wobei sie in monatelang dieselbe Adresse im 80.218.-Netzbereich zugewiesen erhielt und anscheinend auch die Leases unterbruchsfrei verlängern konnte. Nach einem Unterbruch der Cablecom-Verbindung wegen Wartungsarbeiten am Netz erhielt die Zywall Ende Juli eine IP im 217.162er-Netz und genau ab diesem Zeitpunkt waren die Probleme mit den nicht verlängerten und somit jeweils auslaufenden Leases da. Mitte August bekam meine Zywall wieder eine IP im 80.218-Netz zugewiesen und - ZACK - die Probleme waren schlagartig verschwunden. Anfang September bekam die Zywall neu eine IP-Adresse im 84.72-er Netz und - ZACK - die Probleme waren wieder da (und sind es noch...)
Für mich deutet das auf ein Problem mit dem DHCP-Server hin, zumal meine Zywall ja in anderen Netzen problemlos und ordnungsgemäss funktioniert...
-- Veröffentlicht durch mahony am 10:13 pm am Sep. 30, 2004
hi nic
Ich habe den gleichen Netgear WGT624v2:
Account Name WGT624
Hardware Version V2
Firmware Version V4.1.11_1.0.1
Die läuft bei mir ohne Probleme. Ich bin im 80.218er Bereich. Ich hatte zwei Jahre lang ein Zyxel Router im 217.162er Bereich. Diese lief auch ohne Probleme.
Was hast du für eine Firmware drauf und im welchem Bereich hast du eine IP?
Gruss
Mahony
-- Veröffentlicht durch domino2 am 3:34 pm am Okt. 11, 2004
Zitat von hotting am 8:46 am am Sep. 30, 2004
Nein. Eine Lösung habe ich keine. Allerdings ein sehr ähnliches Problem, wegen dem ich nun schon seit einiger Zeit mit dem Hispeed-support im Kontakt bin (ohne dass die mir bisher helfen konnten).
Ich verwende eine Zywall 10, welcher es nicht mehr gelingt, den Lease zu verlängern. Der Lease läuft aus, und ca. 7 Sekunden später kann sich die Zywall wieder einen neuen Lease besorgen. Allerdings sind in diesen 7 Sekunden natürlich sämtliche offenen Connections (bei mir primär SSH und IMAP, KEINERLEI P2P) zusammengebrochen...
Zudem konnte ich verifizieren, dass meine Zywall 10 versucht, ordnungsgemäss die DHCP-Lease zu verlängern, was ihr problemlos gelingt, wenn ich ein anderes (mit DHCP versehenes) Netz an deren WAN-Seite anschliesse. Zudem habe ich meine Zywall-Konfiguration mit dem Support von Studerus kontrolliert, der diese für i.O. und hispeed-konform erklärt hat. Auch die aktuellste Firmware ist drauf.
Interessanterweise kann ich folgenden Zusammenhang feststellen:
Die Zywall hat während mehreren Jahren nun weitestgehend problemlos funktioniert, wobei sie in monatelang dieselbe Adresse im 80.218.-Netzbereich zugewiesen erhielt und anscheinend auch die Leases unterbruchsfrei verlängern konnte. Nach einem Unterbruch der Cablecom-Verbindung wegen Wartungsarbeiten am Netz erhielt die Zywall Ende Juli eine IP im 217.162er-Netz und genau ab diesem Zeitpunkt waren die Probleme mit den nicht verlängerten und somit jeweils auslaufenden Leases da. Mitte August bekam meine Zywall wieder eine IP im 80.218-Netz zugewiesen und - ZACK - die Probleme waren schlagartig verschwunden. Anfang September bekam die Zywall neu eine IP-Adresse im 84.72-er Netz und - ZACK - die Probleme waren wieder da (und sind es noch...)
Für mich deutet das auf ein Problem mit dem DHCP-Server hin, zumal meine Zywall ja in anderen Netzen problemlos und ordnungsgemäss funktioniert...
habe genau das gleiche problem mit zywall 2...hilfeeeeee
guck hier-> http://www.cablemodem.ch/cgi-bin/ikonboard/topic.cgi?forum=2&topic=445
mein post...
habe das problem genau seit ich 84.er ip zugewiesen bekam!!
(Geändert von domino2 um 3:35 pm am Okt. 11, 2004)
-- Veröffentlicht durch MAC Ferrari am 12:15 am am Okt. 12, 2004
@Domino2
Zitat von domino2 am 00:12 am am Okt. 12, 2004¨
Die Zywall hat während mehreren Jahren nun weitestgehend problemlos funktioniert, wobei sie in monatelang dieselbe Adresse im 80.218.-Netzbereich zugewiesen erhielt und anscheinend auch die Leases unterbruchsfrei verlängern konnte. Nach einem Unterbruch Mitte August bekam meine Zywall wieder eine IP im 80.218-Netz zugewiesen und - ZACK - die Probleme waren schlagartig verschwunden. Anfang September bekam die Zywall neu eine IP-Adresse im 84.72-er Netz und - ZACK - die Probleme waren wieder da (und sind es noch...)
Genau dieses Problem hab ich hier in Winterthur seit dem Wechsel auf den IP Range 84.72.xxx.xxx auch, zudem hat der HE von 10.196.96.1 auf 10.182.64.1 gewechselt. Beim streaming radio unterbricht die Verbindung alle 40min. Dann muss ich im Router Setup Die Verbindung manuell reseten dann läufts wieder. Zum Glück wurde dieses Posting geschrieben, sonst hätt ich mir glatt einen neuen Router gekauft, weil ich dem Router die Schuld für die Unterbrüche gab. Na ja dafür sind die Pingzeiten der absolute Hammer hier und der DL läuft auch super.......;-)
Greetz MAC_Ferrari
(Geändert von MAC Ferrari um 12:15 am am Okt. 12, 2004)
-- Veröffentlicht durch domino2 am 6:20 pm am Okt. 14, 2004
jo hab auch pings mit switch.ch von 7-10ms..downstream überragend und upstream perfekt, aber eben jede h auf die minute genau disconnects..
Und was wollen wir unternehmen?
Wie ich schon erwähnte: Studerus konnte mir nur sagen, dass es CC schuld sei, weil ich ja meine 68,69 udp frei hab.
Und CC Hotline haben manche zu wenig Ahnung und anderen ist "dieses Problem unbekannt".
Ich meine, ich bin wirklich sonst sehr zufrieden, aber mit h disconnects..aarrg..ftp, irc, etc. alles tot.
mein post darüber:
hilfe hab so ein problem..
habe zywall 2
System Name :
--------------------------------------------------------------------------------
Model Name : ZyWALL 2
ZyNOS Firmware Version: V3.62(WK.6) | 06/16/2004
Routing Protocols : IP
--------------------------------------------------------------------------------
WAN Port :
--------------------------------------------------------------------------------
IP Address : 84.72... DHCP : Client
IP Subnet Mask : 255.255.240.0
--------------------------------------------------------------------------------
LAN Port :
--------------------------------------------------------------------------------
IP Address : 192.168.1.1 DHCP : Server
IP Subnet Mask : 255.255.255.0
hatte dieses problem schon einmal und nur, wenn ich die firewall dran hab..defaultmässig sind in der firewall unter firewall,wan to wan schon boottp_client udp: 68 drin..hab noch 67 eingefügt und trotzdem habe stündlich auf die minute genau ca. 5s eine tote leitung.
mirc meint:
[10:16pm] * Disconnected
[11:16pm] * Disconnected
[12:16pm] * Disconnected
etc.
quit msgs sind ping timeout..
das nervt vorallem bei offenen ftp- und irc-verbindungen.
studerus, ch vertreiber von zyxel produkten habe ich kontaktiert. Der meinte, dass nur die standard-roule wan to wan udp 68 drin sein müsse und es sollte dann funktionieren. Er habe schon mit ca. 5 kunden mit dem selben problem telefoniert, welche ebenfalls bei cablecom sind und ebenfalls eine 84er ip beziehen.
Nach Ausbau der Headendprobleme hatte ich keinerlei Probleme, bis mir eine 84er Ip zugewiesen wurde. downstream ohne Firewall ist ca. 15KB/s, mit Firewall 0.2-0.5KB/s.
Was kann ich tun?
Helpdesk von Hispeed konnte mir nicht helfen, sagte, dass ich port 67 und 68 frei haben müsse, was ich ja auch habe.
Jemand von der Technik von Cablecom, konnte mir leider auch nicht weiterhelfen, da der Fehler unbekannt ist. Leute vom "Front"-Office, "Back"-Office kann ich kein erreichen.
Weiss jemand mehr? Vielleicht "Cablecom THH" ?
Freundliche Grüsse
domino2
-- Veröffentlicht durch Rene am 10:39 pm am Okt. 14, 2004
Ich hatte mal mit einer Zywall 10 zu tun, die nahm mir konfigurationsänderungen einfach nicht mehr an. Das heisst die Änderungen wurden sehr wohl registiert und auch immer korrekt angezeigt, nach Reset wie auch einem PowerCycle, aber wirksam waren die Einstellung trotzdem nicht.
Als ich, nach einigem Fehlersuchen warum es trotz korrekter Einstellung nicht ging, dann sah dass die ZyWall die Pakete gar nicht so durchleitete wie sie es hätte tun sollen, habe ich kurzen Prozess gemacht. Ich habe alle Settings aufgeschrieben und das Ding factory geresettet und neu auf der grünen Wiese begonnen. Danach ging es sofort mit denselben Einstellungen.
Naja seither habe ich ein bisschen ein ungutes Gefühl wann immer ich so ein Teil sehe, aber vielleicht hatte ich auch nur ein (halb-?) defektes Gerät vor mir.
Anyway, vielleicht hilft das ja bei Dir auch ? Ein Versuch wäre es wohl mal wert.
-- Veröffentlicht durch MAC Ferrari am 10:28 am am Okt. 15, 2004
@Rene
@domino2
hm ich glaube nicht, dass es an den Routern liegt. Ich denke es ist ein Problem seitens CC. Ich werde heute mal das Modem direkt an den PC anschliessen und austesten. Ich habe bei meinem Planet Router die Firewall mal abgeschalten und es hat sich nichts verändert. ;-)
Während den 217.xxx. und 80.xxx Zeiten, hatte ich nie "disconnects" oder andere Aufhänger und Unterbrüche, mal abgesehen von den speedproblemen. Seit CC Techniker die Node Bereiche verkleinert haben, resp. den Wechsel in den 84.xxx. range tritt eben dieses Problem auf. Vielleicht spielt ja auch Digitalphone eine Rolle?
Na ich werd's posten, wenn ich das Modem mal direkt angeschlossen habe. ;-)
Greetz MAC_Ferrari
(Geändert von MAC Ferrari um 10:29 am am Okt. 15, 2004)
-- Veröffentlicht durch Mephi am 4:26 pm am Okt. 15, 2004
In den hier und in anderen Foren des Boards geschilderten Fällen gehe ich auch von einer malfunction auf Seiten der Cablecom aus. Unterschiedliche Router haben dieses Problem und es tritt nur im IP-Adressenbereich 84.x.x.x auf, natürlich nicht der Zahlen wegen, sondern weil da mutmasslich anderes Equipment zum Einatz kommt.
@Rene, (Zywall 10, Einstellungen) Hast du die Einstellungen übers WEB-IF vorgenommen? Da war mal von einem Bug die Rede, ist allerdings ziemlich lange her. Neu soll gem. Berichten im Board von DSL-Webseiten.de dieser bei der ZyAIR B 2000 ii angelangt sein mit einem zusätzlichen issue, ich muss es einfach zitieren:
"Dann noch eine weitere Info zu der Firmware: In den Firewall Settings ist m.W. auch ein Fehler. Ein Haekchen bei "Enable Firewall" bewirkt genau das Gegenteil, sprich die Firewall ist aus. Wenn kein Haekchen gesetzt ist ist die Firewall an."
(http://www.dsl-webseiten.de/forum/showthread.php?s=18fad77b2699a0ea1a0df674f048703d&threadid=15617)
Der dies schrieb hat nichts gegen Zyxel, er betreibt den zyxel-onlineshop.de
@ MAC Ferrari. Ich will den Thread nicht entführen, dennoch würden mich deine Erfahrungen mit dem Planet Router interessieren.
Gruss Philipp
-- Veröffentlicht durch domino2 am 12:16 pm am Okt. 16, 2004
btw ohne zywall2..also direkt mit cablemodem am netz.dann macht es keine probleme.aber das problem ist seit ich 84er ip beziehe mit zywall..ich werde wohl auch mal kurzen prozess machen :) aber ich glaube ich werde mal versuchen nicht mehr die settings zu restoren, lieber mal von 0 wieder anfangen.
-- Veröffentlicht durch Mephi am 12:32 pm am Okt. 16, 2004
aha ... ich nehme an, dass das Errorlog nicht viel hergibt. Aber da die Aussetzer stundenexakt auftreten, wäre es vielleicht sinnvoll den DHCP-Status kurz vor und kurz nach der Störung auszulesen. Im command interpreter mode: ip dhcp enif1 status eingeben.
-- Veröffentlicht durch hotting am 2:04 pm am Okt. 16, 2004
Sali zäme
Die Beobachtung von domino2 "also direkt mit cablemodem am netz.dann macht es keine probleme.aber das problem ist seit ich 84er ip beziehe mit zywall" kann ich 100%ig bestätigen. ist bei mir absolut identisch. Ein Notebook, dass ich testhalber mal "aussen" eingebunden habe, hatte keinerlei Probleme die Lease zu verlängern.
Betreffend errorlog der Zywall: (letzte Ziffern der
aktuellen IP jeweils ausgeblendet)
ausgeblendet
51 Sat Oct 16 08:41:30 2004 PP0d INFO DHCP client IP expired
52 Sat Oct 16 08:41:37 2004 PP0d INFO DHCP client gets 0x54485...
53 Sat Oct 16 09:41:45 2004 PP0d INFO DHCP client IP expired
54 Sat Oct 16 09:41:52 2004 PP0d INFO DHCP client gets 0x54485...
55 Sat Oct 16 10:41:55 2004 PP0d INFO DHCP client IP expired
56 Sat Oct 16 10:42:02 2004 PP0d INFO DHCP client gets 0x54485...
57 Sat Oct 16 11:42:09 2004 PP0d INFO DHCP client IP expired
58 Sat Oct 16 11:42:16 2004 PP0d INFO DHCP client gets 0x54485...
59 Sat Oct 16 12:42:21 2004 PP0d INFO DHCP client IP expired
60 Sat Oct 16 12:42:28 2004 PP0d INFO DHCP client gets 0x54485...
und dies seit tagen, genauer gesagt, seit dem Tag, seitdem die IP-Adresse mit 84. beginnt..., vorhin lief es mehrere Jahre absolut problemlos, mit Ausnahme einer kurzen Zeitperiode, während der meine Zywall ebenfalls in einem anderen Subnetz landete...
"ip dhcp enif status" sagt im Moment:
DHCP on iface enif1 is client
Hostname : hydra.
Domain Name :
Server IP address: 62.2.28.41
Client IP address: 84.72.80.xx/21
DNS server : 62.2.24.162, 62.2.17.61, 62.2.24.158
Default gateway: 84.72.80.1
Lease time : 3577 seconds
Renewal time: 1784 seconds
Rebind time : 3125 seconds
Client State = 3, retry = 0
periodtimer = 290590, timer = 686
flags = 2
Status:
Packet InCount: 12753, OutCount: 2483, DiscardCount: 12591
Der nächste Unterbruch ist wohl in etwa 45 min zu erwarten. Ich versuche dann, mal mitzuschauen...
Grüsse aus Winterthur
Michael (hier im Forum als "newbie" bezeichnet, aber beruflich im IT-Support tätig)
-- Veröffentlicht durch hotting am 3:02 pm am Okt. 16, 2004
Nach 45 min Beobachtung des Outputs von "ip dhcp enif1 status"
lässt sich nun folgendes aussagen:
Während der ersten halben Stunde der Leasedauer gilt folgendes
Bild:
DHCP on iface enif1 is client
Hostname : hydra.
Domain Name :
Server IP address: 62.2.28.41
Client IP address: 84.72.80.xx/21
DNS server : 62.2.24.162, 62.2.17.61, 62.2.24.158
Default gateway: 84.72.80.1
Lease time : 3577 seconds
Renewal time: 1784 seconds
Rebind time : 3125 seconds
Client State = 3, retry = 0
periodtimer = 291130, timer = 146
flags = 2
Status:
Packet InCount: 12777, OutCount: 2483, DiscardCount: 12615
Der Wert bei Timer zählt sekündlich runter. Bei 0 angekommen,
beginnt - nach meiner Interpretation - die Zywall mit minütlichen
Versuchen, die Lease zu verlängern, die allerdings fehlschlagen:
Client State = 3, retry = 1
periodtimer = 291279, timer = 58
flags = 2
Der Timer beginnt immer wieder bei 60, zählt runter bis 0,
dann geht retry eins höher und der Timer beginnt wieder bei 60.
Dann wechselt plötzlich der Client State auf 4. Dies dürfte zeitlich
mit dem Ablaufen der "Rebind Time" zusammenfallen. Die retries
beginnen wieder bei Null und dasselbe Spiel alle 60 Sekunden
beginnt.
Dann wechselt der Client State auf 5, die Retries wieder auf 0.
Ein letztes Mal zählt der Timer runter. Dann kommt der Zeitpunkt
x des Unterbruchs. Die oberen Zeilen des Outputs bleiben immer
identisch, nur die unteren Zeilen ändern sich. Hier die Outputs,
praktisch jede Sekunde, was am periodtimer ersichtlich ist:
Client State = 5, retry = 0
periodtimer = 293097, timer = 1
flags = 2
Client State = 5, retry = 0
periodtimer = 293098, timer = 0
flags = 2
Client State = 1, retry = 2
periodtimer = 293100, timer = 2
flags = 6
Client State = 1, retry = 2
periodtimer = 293101, timer = 1
flags = 6
Client State = 1, retry = 2
periodtimer = 293102, timer = 0
flags = 6
Client State = 2, retry = 2
periodtimer = 293103, timer = 2
flags = 42
Client State = 2, retry = 2
periodtimer = 293105, timer = 0
flags = 42
Client State = 3, retry = 0
periodtimer = 293106, timer = 1784
flags = 2
Nun sind wir wieder im stabilen Zustand angelangt. Die Verbindung
ist wieder da und dürfte es auch die nächste Stunde bleiben...
Tja... wer weiss weiter?
Gruss, Michael
-- Veröffentlicht durch domino2 am 3:20 pm am Okt. 16, 2004
factory defaults gemacht..alles was ich geändert hab ist port 139 auf mich umgeleitet wegen ircidentd server und sonst alles gelassen.
fazit.
h unterbrüche.
und eben ohne firewall 0 probleme..
kanns ja wohl nicht sein?!
-- Veröffentlicht durch hotting am 3:28 pm am Okt. 16, 2004
Hallo Domino2
Besten Dank für Deinen Kurzbericht über den Factory-Reset. Da dies bei Dir nichts gebracht hat, lass ich das bei mir mal vorläufig bleiben.
Nee... ohne Firewall ans Hispeed-Netz, das kommt wirklich nicht in Frage!
Doch, was nun?
Gruss, Michael (Leidensgenosse)
-- Veröffentlicht durch Mephi am 3:45 pm am Okt. 16, 2004
hotting> ich interpretiere es wie du, also den DHCP Status meine ich.
domino> siehts bei dir der DHCP-Status ähnlich aus wie bei hotting?
Sollte es das selbe Problem sein, wie von Timberwolf in diesem Thread beschrieben, also eine DHCP relaying malfunktion:
http://www.cablemodem.ch/cgi-bin/ikonboard/topic.cgi?forum=2&topic=1025&start=0
so appelliere ich ans THH Team, dies zu kommunzieren, z.B. auf den Netzstatusseiten.
Gruss Philipp
-- Veröffentlicht durch Rene am 11:00 pm am Okt. 16, 2004
Kann einer von euch mal parallel zur Zywall einen Laptop oder anderen PC anschliessen und via Ethereal mal den DHCP Verkehr während ca 2 Stunden aufzeichnen?
Also schematisch gesehen
Kabelmodem --- Hub ---- Zywall
\---- Laptop/PC mit Sniffer
Die relevante Zeile für den "Capture Filter" wäre
"udp and port 68 or port 69"
Danach die Aufzeichnung in eine Datei speichern und mir mailen ? Ohne nähere Angaben kann ich auch nicht wirklich genaueres dazu sagen, einzig dass es sehr suspekt ist dass es mit Firewall nicht geht aber ohne schon.
Der Rechner mit Ethereal braucht übrigens nicht unbedingt eine IP Adresse, falls es nur ein Abo mit einer einzigen IP Adresse ist, er sieht den Datenverkehr auch so.
-- Veröffentlicht durch MAC Ferrari am 4:21 am am Okt. 17, 2004
[quote]Zitat von Mephi am 4:26 pm am Okt. 15, 2004
I
@ MAC Ferrari. Ich will den Thread nicht entführen, dennoch würden mich deine Erfahrungen mit dem Planet Router interessieren.
--------------------
hm na ja als Router für zwei PC's gehts ganz gut. Falls jedoch alle vier ports benutzt , sprich zwei neue PC angehängt werden, muss ich das Teil immer zuerst reseten weil dann kein PC mehr ins Netz kommt. Ich habs nie geschaft, einen FTP server via Router sauber zum laufen zu bringen und manchmal stürzt das Ding einfach so ab. Na ja und eben diese Unterbrüche seit dem IP range Wechsel. Zudem ist das log file sehr oberflächlich, nicht so detailiert wie bei der Zywall2.
hier ein Ausschnitt aus dem log file:
10/17/2004 04:23:30 DHCP Client: Receive Ack from 62.2.28.41,Lease time=3600
10/17/2004 04:23:29 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 04:23:29 DHCP Client: Receive Offer from 62.2.28.41
10/17/2004 04:23:29 DHCP Client: Send Discover
10/17/2004 04:23:19 DHCP Client: Send Release
10/17/2004 04:23:16 DHCP Client: Receive Ack from 62.2.28.41,Lease time=3877
10/17/2004 04:23:16 DHCP Client: Send Request,Request IP=84.72..xx.xx
10/17/2004 04:23:16 DHCP Client: Receive Offer from 62.2.28.41
10/17/2004 04:23:16 DHCP Client: Send Discover
10/17/2004 04:23:06 **Smurf** 0.0.0.0->> 213.202.32.2, Type:5, Code:1 (from WAN Outbound)
10/17/2004 04:23:05 192.168.0.100 login success
10/17/2004 04:22:46 **Smurf** 0.0.0.0->> 213.202.32.2, Type:5, Code:1 (from WAN Outbound)
10/17/2004 04:22:38 **Smurf** 0.0.0.0->> 205.188.12.92, Type:5, Code:1 (from WAN Outbound)
10/17/2004 04:22:37 **Smurf** 0.0.0.0->> 213.202.32.2, Type:5, Code:1 (from WAN Outbound)
10/17/2004 04:22:32 **Smurf** 0.0.0.0->> 213.202.32.2, Type:5, Code:1 (from WAN Outbound)
10/17/2004 04:22:29 **Smurf** 0.0.0.0->> 213.202.32.2, Type:5, Code:1 (from WAN Outbound)
10/17/2004 04:22:18 **Smurf** 0.0.0.0->> 10.182.64.1, Type:5, Code:1 (from WAN Outbound)
10/17/2004 04:22:18 DHCP Client: Send Discover
10/17/2004 04:15:12 192.168.0.100 login success
10/17/2004 04:01:37 192.168.0.100 login success
10/17/2004 03:58:44 DHCP Client: Could not find DHCP daemon to get information
10/17/2004 03:58:34 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 03:58:24 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 03:58:14 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 03:58:04 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 0386.92:57:54 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 03:33:13 NTP Date/Time updated
10/17/2004 03:32:42 Begin to query NTP
10/17/2004 03:25:21 DHCP Client: Receive Ack from 62.2.28.41,Lease time=3875
10/17/2004 03:25:21 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 03:25:21 DHCP Client: Receive Offer from 62.2.28.41
10/17/2004 03:25:21 DHCP Client: Send Discover
10/17/2004 03:24:20 **Smurf** 0.0.0.0->> 10.182.64.1, Type:5, Code:1 (from WAN Outbound)
10/17/2004 03:24:20 DHCP Client: Send Discover
10/17/2004 03:10:28 **IP Spoofing** 127.0.0.1, 80->> 84.72.xx.xx, 1664 (from WAN Inbound)
10/17/2004 03:01:11 **IP Spoofing** 127.0.0.1, 80->> 84.72.xx.xx, 1491 (from WAN Inbound)
10/17/2004 03:00:53 DHCP Client: Could not find DHCP daemon to get information
10/17/2004 03:00:36 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 03:00:26 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 03:00:16 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 03:00:06 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 02:59:56 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 02:47:46 **IP Spoofing** 127.0.0.1, 80->> 84.72.xx.xx, 1920 (from WAN Inbound)
10/17/2004 02:30:35 **IP Spoofing** 127.0.0.1, 80->> 84.72.xx.xx, 1591 (from WAN Inbound)
10/17/2004 02:26:23 DHCP Client: Receive Ack from 62.2.28.41,Lease time=3936
10/17/2004 02:26:23 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/17/2004 02:26:23 DHCP Client: Receive Offer from 62.2.28.41
10/17/2004 02:26:23 DHCP Client: Send Discover
10/17/2004 02:20:20 **IP Spoofing** 127.0.0.1, 80->> 84.72.xx.xx, 1250 (from WAN Inbound)
10/17/2004 02:17:11 **IP Spoofing** 127.0.0.1, 80->> 84.72.xx.xx, 1020 (from WAN Inbound)
10/17/2004 02:02:53 DHCP Client: Could not find DHCP daemon to get information
Da stimmt doch was nicht mit den Lease timings, zum "smurf"??
Greetz MAC_Ferrari
(Geändert von MAC Ferrari um 4:31 am am Okt. 17, 2004)
(Geändert von MAC Ferrari um 4:35 am am Okt. 17, 2004)
-- Veröffentlicht durch knoebi am 6:12 pm am Okt. 19, 2004
Vielen Dank für diesen Thread.
Ich habe exakt dieselben Probleme mit meinem WGT624.
Bin auf ende September von St. Gallen nach Winterthur gezügelt und hatte mit meinem alten Cablemodem diese Probleme auch ohne Router. Jetzt habe ich ein VCM02 und da treten die Probleme nur mit dem WGT 624 auf. Bin auch im 80.72.x.x Netz, was hier ja keinen mehr überrascht.
Ich habe bereits Ticket bei der Cablecom, mal schauen was der Second Level Supporter meint. Werde hier berichten, falls er anruft.
Än Gruäs
Philipp
(Geändert von knoebi um 6:15 pm am Okt. 19, 2004)
-- Veröffentlicht durch domino2 am 12:34 am am Okt. 20, 2004
Zitat von knoebi am 6:12 pm am Okt. 19, 2004
Werde hier berichten, falls er anruft.
(Geändert von knoebi um 6:15 pm am Okt. 19, 2004)
falls :)
-- Veröffentlicht durch Mephi am 1:00 am am Okt. 20, 2004
domino2, hotting et al.> es wäre jetzt schon gut, wenn einer von euch die Zusammenfassung einer Aufzeichnung (wie von Rene dargelegt) eines Sniffers posten könnte.
Philipp
-- Veröffentlicht durch hotting am 3:39 pm am Okt. 21, 2004
Hoi zäme
habe mir nun leihweise Notebook (da ich meine produktiven Geräte nicht ausserhalb der Firewall anhängen möchte) besorgt, das ich mal über das Wochenende zwischen Zywall und Modem einhängen werde, um den DHCP-Verkehr mitzusniffen...
Sobald ich Erkenntnisse habe, werde ich diese umgehend hier posten.
Gruss, Michael
-- Veröffentlicht durch domino2 am 5:55 pm am Okt. 21, 2004
Zitat von Mephi am 1:00 am am Okt. 20, 2004
domino2, hotting et al.> es wäre jetzt schon gut, wenn einer von euch die Zusammenfassung einer Aufzeichnung (wie von Rene dargelegt) eines Sniffers posten könnte.
mit was soll ich sniffen und wie? sorry habe damit keine erfahrungen
Philipp
-- Veröffentlicht durch Rene am 1:07 pm am Okt. 22, 2004
Wenn Du die technischen Bedingungen erfüllen kannst (Du hast einen *Hub*, keinen Switch, den Du zwischen Zywall und Kabelmodem hängen kannst und genügend Kabel (braucht 2 mehr) um noch parallel ein Notebook oder PC anzuhängen), dann erkläre ich Dir gerne das Vorgehen Schritt für Schritt.
Allerdings würde das noch ein paar Tage dauern, ich bin momentan gerade genügend ausgelastet und sollte auch noch schnell mal zügeln.
-- Veröffentlicht durch MAC_Ferrari am 3:24 pm am Okt. 22, 2004
@Rene
ja das würde mich auch interessieren. ;-)
@alle die dieses problem haben;
ich habe mal das Log meines Routers genauer analisiert und folgende unklare Punkte gefunden....
"begin logfile"-->
10/22/2004 15:07:39 **Smurf** 0.0.0.0->> 160.79.128.37, Type:5, Code:1 (from WAN Outbound)
10/22/2004 15:07:22 **Smurf** 0.0.0.0->> 160.79.128.37, Type:5, Code:1 (from WAN Outbound)
10/22/2004 15:07:14 **Smurf** 0.0.0.0->> 160.79.128.37, Type:5, Code:1 (from WAN Outbound)
10/22/2004 15:07:10 **Smurf** 0.0.0.0->> 160.79.128.37, Type:5, Code:1 (from WAN Outbound)
10/22/2004 15:07:08 **Smurf** 0.0.0.0->> 160.79.128.37, Type:5, Code:1 (from WAN Outbound)
10/22/2004 15:07:07 **Smurf** 0.0.0.0->> 10.182.64.1, Type:5, Code:1 (from WAN Outbound)
--> break logfile"
Hier verliert der Router die Verbindung zum CC DHCP Server, streaming wird unterbrochen! Was ist überhaupt ein "Smurf"??
--> "continuos logfile"
10/22/2004 15:07:57 DHCP Client: Receive Ack from 62.2.28.41,Lease time=3885
10/22/2004 15:07:57 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/22/2004 15:07:57 DHCP Client: Receive Offer from 62.2.28.41
10/22/2004 15:07:57 DHCP Client: Send Discover
10/22/2004 15:07:49 192.168.0.100 login success
10/22/2004 15:07:48 User from 192.168.0.100 timed out
-->"break logfile"
Ähh, komischer Parameter für die Leasetime?? Hier habe ich die Verbindung manuell über "release" und "renew" wieder hergestellt. Das müsste doch auch automatisch gehen? Kennt jemand ein Modell das dies kann?
"continuos logfile" -->
10/22/2004 15:18:44 192.168.0.100 login success
10/22/2004 15:08:08 DHCP Client: Receive Ack from 62.2.28.41,Lease time=3600
10/22/2004 15:08:08 DHCP Client: Send Request,Request IP=84.72.xx.xx
10/22/2004 15:08:08 DHCP Client: Receive Offer from 62.2.28.41
10/22/2004 15:08:08 DHCP Client: Send Discover
--> "end logfile"
Hm na, jetzt geht alles wieder wie gehabt, bis zum nächsten Ausfall. Hm ich habe noch alte PC Komponenten, ich werd die mal zusammenbauen und ethereal aufspielen. Vielleicht finden wir dann was heraus.......;-) :-)
Greetz MAC_Ferrari
-- Veröffentlicht durch hotting am 7:12 pm am Okt. 23, 2004
Hallo zusammen
Wie im letzten Posting versprochen, habe ich heute nachmittag den Ethereal
angeworfen und mal tüchtig zwischen Zywall und Cablemodem mitgesnifft.
Aus irgendwelchen mir nicht bekannten Gründen gelten die Leases seit
gestern(?) jeweils 90 Minuten und nicht nur 60.
Und die Ergebnisse sind deutlich, sehr deutlich sogar. Für mich ist der
Fall -fast- klar:
Hier der DHCP-Verkehr, der die Zywall betrifft, wobei ich die Endziffern
der IP ausge-x-t habe. Der Logauszug beginnt mit einem kompletten DHCP-
Adressbezug, der natürlich mit einem Unterbruch der Verbindungen, die
über die Zywall liefen, verbunden war.
No. Time Source Destination Protocol Info
4 77.000930 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xcd6
5 77.127756 10.182.64.1 84.72.xxx.xxx DHCP DHCP Offer - Transaction ID 0xcd6
8 80.999933 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x1c75
9 81.127705 10.182.64.1 84.72.xxx.xxx DHCP DHCP ACK - Transaction ID 0x1c75
Soweit so gut, die Zywall hat ihre Lease erhalten und werkelt drauf los.
Ca. 2700 Sekunden später, d.h. nach der halben Lease-Dauer, ist die Zywall
der Meinung, die Lease müsste nun verlängert werden, und versucht den
DHCP-Server per UniCast zu kontaktieren.
Doch eine Antwort erhält sie nie, so versucht sie dies alle 60 Sekunden
weiter, wie ich dies schon in einem früheren Posting beschrieben habe.
190 2779.086352 84.72.xxx.xxx 62.2.28.41 DHCP DHCP Request - Transaction ID 0x47ae
191 2840.085025 84.72.xxx.xxx 62.2.28.41 DHCP DHCP Request - Transaction ID 0x35f7
192 2901.085106 84.72.xxx.xxx 62.2.28.41 DHCP DHCP Request - Transaction ID 0x2440
197 2962.085249 84.72.xxx.xxx 62.2.28.41 DHCP DHCP Request - Transaction ID 0x1289
... usw. usw. usw. usw. knapp 40 Einträge lang ...
387 5384.089742 84.72.xxx.xxx 62.2.28.41 DHCP DHCP Request - Transaction ID 0x79e
391 5445.089831 84.72.xxx.xxx 62.2.28.41 DHCP DHCP Request - Transaction ID 0xf5e6
396 5525.090783 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x2e69
397 5525.217962 10.182.64.1 84.72.xxx.xxx DHCP DHCP Offer - Transaction ID 0x2e69
398 5529.089833 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x3e08
399 5529.218816 10.182.64.1 84.72.xxx.xxx DHCP DHCP ACK - Transaction ID 0x3e08
583 8228.176485 84.72.xxx.xxx 62.2.28.41 DHCP DHCP Request - Transaction ID 0x6d29
Wie man sieht schliesst sich dem letzten vergeblichen Versuch (Paket 391)
wieder ein DHCP-Discover, Offer, Request und ACK an, das natürlich wiederum
mit dem Zusammenbruch aller Connections verbunden ist. Vergleicht man die
vergebliche Ladung DHCP-Requests mit den beiden erfolreichen Paketen 8
und 398 sieht man, dass diese jeweils nicht als Unicast an den DHCP-Server
62.2.28.41 geschickt, sondern gebroadcastet werden.
Fazit:
Mephi hat uns in einem seiner Posting einen Link auf einen anderen
Thread geliefert, in welchem der THH folgende Begründung auf das
damals behandelte Problem lieferte:
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Der DHCP-Server hatte während der ganzen Zeit einwandfrei
funktioniert. Der Grund für die Probleme bei der Verlängerung lag an
der Nicht-Weiterleitung der unicast DHCP- ACK-Pakete durch den
zwischen Kunden-DHCP-Client und DHCP-Server liegenden "BOOTP Relay
Agenten". Dadurch lief die IP-Lease des Kunden aus, sodass der PC
gezwungen wurde, kurzzeitig die Netzwerkaktivitäten für ganz kurze
Zeit einzustellen und wieder mit einem DHCP-Discover eine neue IP-
Adresse anzufordern (gemäss letztem Abschnitt aus RFC 2131) und die
Netzwerkaktivitäten nach Erhalt der IP-Adresse wieder aufzunehmen.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Ich bin sicher, dass dies wieder genau dieses Problem ist, bzw.
die mögliche Variante davon, dass der BOOTP-Relay-Agent die
unicast DHCP-Requests nicht weiterleitet. Aber das kommt ja
auf dasselbe Ergebnis raus.
Hallo Cablecom: Aufwachen und BOOTP-Relay-Agenten flicken!
Nun habe ich mich aber noch gefragt, weshalb es nur mit der Zywall
Aerger gibt, das Notebook hingegen problemlos die Lease verlängern
kann. Hier der entsprechende Log-Auszug, mit der ausge-y-ten IP-
Adresse. Es beginnt mit einem gebroadcasteten DHCP-Request,
der wie wir ja inzwischen wissen, funktioniert:
No. Time Source Destination Protocol Info
143 1806.328769 84.72.yyy.yyy 255.255.255.255 DHCP DHCP Request - Transaction ID 0x2d942c7
144 1806.455514 10.182.64.1 84.72.yyy.yyy DHCP DHCP ACK - Transaction ID 0x2d942c7
145 1806.477712 10.182.64.1 84.72.yyy.yyy DHCP DHCP ACK - Transaction ID 0x2d942c7
Weshalb hier gleich zwei ACKs zurückkommen, habe ich noch
nicht rausgefunden, aber es geht ja... Auch hier vergeht
eine schöne Zeit, bis das Notebook die Lease verlängern
will, auch per Unicast. Windows versucht hier jeweils
dreimal hintereinander, die Lease zu verlängern und
wartet dann einen Moment, wobei dieser immer kürzer
wird.
258 3715.525487 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x212c16e4
259 3718.526163 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x212c16e4
260 3725.526174 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x212c16e4
315 4443.530870 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x9538c976
316 4448.536202 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x9538c976
321 4457.018649 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x9538c976
352 4810.027248 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x75c79b6
353 4815.033258 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x75c79b6
354 4822.033014 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0x75c79b6
364 4992.038946 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xc093a788
365 4995.041812 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xc093a788
366 5003.043322 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xc093a788
371 5082.048673 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xa59e143b
372 5087.054575 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xa59e143b
373 5095.055655 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xa59e143b
376 5128.064967 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xfccb49af
377 5132.069058 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xfccb49af
378 5140.070454 84.72.yyy.yyy 62.2.28.41 DHCP DHCP Request - Transaction ID 0xfccb49af
388 5390.582156 84.72.yyy.yyy 255.255.255.255 DHCP DHCP Request - Transaction ID 0x718a0615
389 5390.714126 10.182.64.1 84.72.yyy.yyy DHCP DHCP ACK - Transaction ID 0x718a0615
390 5390.742489 10.182.64.1 84.72.yyy.yyy DHCP DHCP ACK - Transaction ID 0x718a0615
Und oha... irgendwann wechselt das Windows-Notebook vom Versuch via
Unicast zum Broadcast, der wie wir ja wissen, funktioniert. Und
schon wird die Lease verlängert und die Connections laufen unter-
bruchsfrei weiter. Weshalb hier auch wieder zwei Acks zurückkommen
ist mir immer noch schleierhaft.
Hier liegt also die Ursache für das unterschiedliche Verhalten von
Windows-Notebook und Zywall begraben. Windows versucht es irgendwann
per Broadcast, die Zywall hingegen nicht. Weshalb dies so ist,
weiss ich nicht.
Fest steht jedenfalls, dass es funktionieren würde, wenn der
Relay-Agent alle Pakete richtig weiterleiten würde. Da es
ja pro Subnetz einen separaten Agent braucht, sind wir
wieder bei der ursprünglichen Beobachtung angelangt,
dass es in einigen Subnetzen klappt und in anderen nicht. Es
gibt Relay-Agents, die richtig tun, und leider auch andere.
Dies mal mein "Wort zum Sonntag".
Gruss, Michael Hottinger
PS: Mit diesen Beobachtungen werde ich nun mal gleich
den Hispeed-Helpdesk einheizen.
-- Veröffentlicht durch Nuttenpreller am 10:04 am am Okt. 25, 2004
Jawohl das Windows macht alles richtig, im Gegensatz zur Zywall, die sich nicht an RFC hält.
Gemaess RFC muss der DHCP-Client nach Ablauf von 7/8 (87.5%) von Leasetime ein Broadcast machen, wenn er bis dahin kein ACK auf den Unicast erhalten hatte. Dies um einen andern DHCP-Server zu finden, der die Lease doch noch verlängert.
Da liegt ein Proplem bei Zywall.
Aber das ursprungliche Prob liegt natürlich bei Cablecom. Die Leaseverlängerung sollte nach der Hälfte der Leasetime korreckt stattfinden.
Das ist ein bekanntes Problem bei Cablecom, das schon mehrmals seit Jahren auftritt. und die Lösung kann ein Zeit dauern.
Das DHCP-System der CC ist ja nicht ein Router aus Mediamarkt, der ein paar Rechnern eine IP-Adresse verteilt, sondern ein hochkomplexes schweizweit verbundeltes System, bei dem es nur ganz wenige Spezialisten gibt die drauskommen.
Ich erinnere mich vor ein paar Jahren gab es einen in der gesamten Schweiz kompletten Ausfall drei Tage lang, und es mussten um das zu reparieren Spezialisten aus USA eingeflogen werden. lol
-- Veröffentlicht durch MAC Ferrari am 4:22 pm am Okt. 25, 2004
hm............
gemäss den Aussagen von hotting ist das Problem jetzt erkannt. Nur wo ist die Abhilfe/ Lösung des Problems? Falls CC das Problem ja kaum schon gestern gelöst hat, ;-) :-) :-) bleiben die ewigen Unterbrüche bei bestimmten Routern somit bestehen.
Das würde wohl auf die Schnelle heissen, den Router durch einen Internet Gateway auf Linux Basis zu ersetzen?
So als Linux Neuling, kann ich mit einer einfachen Linux Distribution, z.B. Suse etc. einen Gateway einrichten, oder brauch ich gar einen Apache Webserver? Ich denke mal so ein Proggy sollte auf Linux statt Windows laufen, die Gründe kennen wir alle! ;-) :-) :-) Also um Ratschläge und sonstige Infos über das Thema wäre ich sehr dankbar.
Greetz MAC_Ferrari
(Geändert von MAC Ferrari um 4:23 pm am Okt. 25, 2004)
-- Veröffentlicht durch timberwolf am 9:55 pm am Okt. 25, 2004
Genau, diese Probleme kommen immer wieder. Komisch nur dass CC nicht sofort drauf kommt, dass dies schon mehrmals geschehen ist. Nehme an, es kümmern sich immer wieder andere Leute darum und sie haben keine gescheite Datenbank für sie Helpdesk. Leider lässt sich auch das THH Team hier kaum mehr blicken.
Bei mir war das Problem vor ca.einem Jahr und ich musste sie mehrmals darauf hinweisen, dass es gleiche Vorkommnisse schon früher mehrmals gab. Geklappt hat es, nachdem ich dem CC THH Team eine E-mail geschickt habe.
Viel Glück
PS:(habe immer noch den gleichen Router und keine Probleme) :-)
-- Veröffentlicht durch Mephi am 3:02 am am Okt. 26, 2004
Ich denke, es wäre angebracht, dass die Betroffenen (IP-Adr. 84. .., Raum Winterthur?) sich unter Hinweis auf diesen Thread, besonders auf den Mitschnitt von Hotting, bei der Hotline melden sollten. Falls dies nichts fruchtet, befürchte ich Schlimmes, was das Personal-Portofolio der Cablecom betrifft.
Richtig ist natürlich die Feststellung in einem vorstehenden Beitrag, dass die Zywall sich defizient verhält. Nach der Zyxeldoktrin sollte für den Fall, dass der unicast request scheitert, nach Ablauf der rebind time eine broadcast Anforderung ausgelöst wird, offensichtlich erfolgt dies aber nicht. Dieses Verfahren ist auch nach RFC nicht für den ordentlichen Betrieb vorgesehen. Es ist hinzunehmen falls die DHCP-Server im Netz ungewiss sind, z.B. weil ganze IP-Adressbereiche umportiert werden. In der vorliegenden Situation ist das mutmasslich geschehen, jetzt aber abgeschlossen, und unicast requests müssten wieder verarbeitet werden können.
Gruss Philipp
(Geändert von Mephi um 3:10 am am Okt. 26, 2004)
-- Veröffentlicht durch hotting am 9:33 am am Okt. 26, 2004
Die betroffene Region Winterthur kann ich bestätigen. Auch mein Cablemodem steht in Winterthur, sogar in der Stadt Winterthur selber.
Betreffend des nicht RFC-konformen Verhaltens der ZyWall bin ich inzwischen mit dem Support von Studerus, dem Importeur der ZyWalls in Kontakt. Ich habe gestern eine neue Firmware erhalten, die das Problem leider nicht beseitigt und warte jetzt auf den weiteren Bescheid.
Wenigstens ist der Studerus-Support aktiv und man erhält nicht nur die lapidare Antwort, dass man die Informationen erhalten hätte und der Fall in Bearbeitung (-> Lagerung?) sei...
-- Veröffentlicht durch MAC Ferrari am 2:13 pm am Okt. 26, 2004
Yep, auch mein Modem steht in der Stadt Winterthur, genauer gesagt in 8406 Winterthur Töss.
Na ja Support kann ich bei meinem "Billig Router" der Marke Planet und dessen Verkäufer PC-Hai wohl kaum erwarten. ;-) :-)
Also bleibt folgendes: CC behebt die Störung ihres DHCP Servers, oder aber es gibt von Zyxel für den Zywall 2 eine Lösung. Hotting kannst Du in diesem Thread posten, falls es eine positive Lösung für den Zywall gibt? Ich werd mir dann so ein Teil besorgen.
Danke im vorraus.....;-) :-)
Greetz MAC_Ferrari
-- Veröffentlicht durch hotting am 7:13 pm am Okt. 26, 2004
Aaaaaaarrrghh... ich fasse es nicht.
Folgende Antwort habe ich von diesen Hispeed-Chaoten erhalten, nachdem ich nun die ganzen Ausführungen, die ich in diesem Thread gepostet habe, auch unter meiner Bearbeitungsnummer an den Cablecom-Support gemailt habe:
Sehr geehrter Herr Hottinger
Sie haben uns ein Problem gemeldet mit Ihrem Kabelanschluss. Bitte beantworten Sie die folgenden Fragen:
Ist an Ihrem Kabelmodem ein Router angeschlossen.
Wie ist die Konfiguration hinter dem Kabelmodem?
Tritt das Problem mit den kurzen Unterbrüchen auch dann auf, wenn Sie den PC direkt am Kabelmodem angeschlossen haben?
Ich bin fassungslos...
Hallo Winterthurer: Wenn Ihr vorhin einen Aufschrei quer durch die Stadt gehört habt, dann war das wohl ich...
Grüsse an die Mitleser und Mitleidenden.
@Mac Ferrari: Ja. Selbstverständlich werde ich Euch auf dem Laufenden halten und allfällige Lösungen/Ergebnisse posten. Ich verschwinde sicher nicht in der Versenkung, nur weil es bei mir läuft. Schliesslich haben die Leute hier im Forum viel zur Eingrenzung/Lösung des Problems beigetragen.
-- Veröffentlicht durch Mephi am 10:28 pm am Okt. 26, 2004
Michael> Du hast mein Mitgefühl auf sicher. Gut die Mail-Antwort mag automatisch generiert worden sein. Die Aufforderung "... wenn Sie den PC direkt am Kabelmodem angeschlossen haben? " ist ne schlichte Katastrophe. Seit sich das THH, den Schritt kann ich begreifen, von diesem Board zurückgezogen hat, gibts keine Möglichkeit mehr für qualifizierte Supportanfragen. Herr Kümmerle möchte sich doch dafür einsetzen.
http://www.cablecom.ch/040506_mm_customercare.pdf
Bis dahin sollen sich die Betroffenen doch auch an die CC wenden, damit es nicht so aussieht, als wärs bei Hotting ein Einzelfall.
Gruss Philipp
-- Veröffentlicht durch kla am 5:21 pm am Okt. 27, 2004
Hallo
Meistens braucht es mehrere Fehler damit etwas nicht mehr funktioniert. Dies ist auch hier der Fall. Ein Fehler lag bei Cablecom, der andere bei den DHCP-Clients.
Das Problem Cablecomseitig ist behoben.
Das Problem der Clients ist (zumindest bei dem von mir überprüften Zyxel), dass sie keinen DHCP-Rebind machen sondern den Lease ablaufen lassen und dann einen neuen DHCP-Discover machen, was einen Unterbruch zur Folge hat. Das Clientseitige Problem spielt jetzt keine Rolle mehr, da das CC-Problem behoben ist.
Gruss
-- Veröffentlicht durch hotting am 8:01 pm am Okt. 27, 2004
Hallo zusammen
@kla: Finde ich sehr interessant, dass Du um 17:21 Uhr aussagen kannst, dass das Problem "Cablecomseitig behoben ist". Denn meine ZyWall verzeichnete um 16:40 Uhr, also weniger als eine Lease-Dauer früher, einen Unterbruch. Arbeitest Du für die Cablecom? Wenn ja, kannst Du uns hier bestätigen, dass wir mit unserer Diagnose, wo der Fehler lag, richtig lagen? Und kriege ich von der Cablecom noch ein offizielles Feedback auf meine Bearbeitungsnummer?
@all:
Auf jeden Fall kann ich im Moment die Aussage von kla bestätigen. Meine Zywall hat gerade vor einigen Sekunden erfolgreich die Lease verlängert. Das Problem scheint tatsächlich hier im 84.72er-Netz beseitigt zu sein. Hat also mein Wutausbruch gestern abend an der Cablecom-Hotline doch was bewirkt. So weit, so (hoffentlich) gut.
Wie siehts bei den anderen Betroffenen aus?
Heute nachmittag hatte ich nochmals Kontakt mit dem Studerus-Support. Auch hier scheint der Wille vorhanden zu sein, das Problem mit den nicht RFC-konformen Zywalls an die Hand zu nehmen und Abhilfe zu schaffen, dass die ZyWalls auch dann noch funktionieren, wenn es bei der Cablecom (oder einem anderen Provider) (wieder) klemmen sollte. Ich werde Euch hier auf dem Laufenden halten, wenn ich neues erfahre.
Inzwischen herzlichste Grüsse
Michael Hottinger
-- Veröffentlicht durch domino2 am 9:28 pm am Okt. 27, 2004
sorry hab momentan keine zeit für sniffing..habe 84.72er ip auch..aber in 8965 Berikon..nähe Bremgarten..studerus konnte mir leider nicht helfen
-- Veröffentlicht durch kla am 10:22 pm am Okt. 27, 2004
Hallo zusammen
Ich versuch mich kurz zu halten und werde daher gewisse Sachen nicht so ausführlich erklären.
Es hatte weder mit den Relay-Agents etwas zu tun (denn als diese involviert waren - bei broadcasts - hats ja funktioniert) noch mit den DHCP-Servern (sonst hätten sehr viele Kunden ein Problem gehabt). Das Problem lag beim Routing, die Server konnten die Clients nicht direkt erreichen, sondern nur via Relay-Agents. Die Angaben des Relay-Agents sind aber nur in DHCPdiscover und DHCPrebind (beide broadcast) enthalten. Wie schon korrekterweise von jemandem geschrieben, sollte der Client nach 7/8 der Leasetime ein Rebind machen um auch andere Server zu erreichen (im Falle eines Ausfalles eines DHCP-Servers, darum ist der Rebind auch ein Broadcast). Da einzelne Clients (z.B. ZyWall) auf dies verzichten und lieber einen neuen DHCP-Prozess mit einem DHCPdiscover starten, gehen natürlich die Verbindungen verloren. Alle Clients, welche einen Rebind gemacht haben (und dieses Mal gehört Windows zu den guten, auch wenn der DHCP-Client sonst nicht viel taugt), hatten keinen Unterbruch.
Zu den seltsamen Lease-Zeiten:
Macht man ein manuellen Renew kann es sein, dass sich die Leasetime ändert, nicht aber der absolute Zeitpunkt wann der Lease abläuft. Dies ist ein Performance-Feature.
Die erste Lease kann kürzer sein als die folgenden. Dies ist ein Feature und hat mit dem Failover-Protokoll zu tun.
Die Aussagen von Nuttenpreller, dass das ganze System sehr komplex ist, kann wohl jeder mit etwas Knowhow in diesem Bereich nachvollziehen. Aber die Aussage, dass es ein bekanntes Problem sei, stimmt nicht. Denn auch wenn die Auswirkungen dieselben sind, müssen die Ursachen nicht identisch sein. Und die sogenannten Spezialisten beim Totalausfall kannten nicht mal die Leistungsgrenzen ihres System.
Gruss
einer mit guten Connections
-- Veröffentlicht durch hotting am 10:51 pm am Okt. 27, 2004
Hallo kla
besten Dank für Deine Erläuterungen.
Aber weshalb schrieb denn THH im zitierten früheren Posting, dass "der Grund für die Probleme bei der Verlängerung an der Nicht-Weiterleitung der unicast DHCP- ACK-Pakete durch den zwischen Kunden-DHCP-Client und DHCP-Server liegenden "BOOTP Relay
Agenten lag", wenns für Unicast-Pakete diesen gar nicht braucht?
Naja, egal... Hauptsache, dass es nun wieder so funktioniert, wie man es sich wünscht. Endlich wieder stabile Verbindungen, die nicht stündlich in sich zusammenfallen.
Herzlichen Dank an den Techniker, der die Ursache gefunden und gefixt hat. Vielleicht kannst Du"mit den guten Connections" dies dem betreffenden weiterleiten.
Gruss, Michael
-- Veröffentlicht durch Nuttenpreller am 11:31 am am Okt. 28, 2004
@domino2
wie kla sagt, kann das Problem verschiedene Ursachen haben, auch wenn gleiche Auswirkungen sind vorhanden. Es muss bei dir nicht gleich sein wie bei hotting. Deshalb wurde ich auch ein Sniffer auf Rechner der paarallell mit Hub zu Router angeschlossen ist laufen lassen, wie von Renè gesagt. Wichtig ist Hub und nicht Switch, musst irgendwo ein auftreiben, es werden heute nur Switches verkauft in Läden.
Solange das nicht machst und Ergebnisse an CC Support geschickt hast kannst lange warten bis Proplem behoben.
@all
find interresant, dass bei 84.72er IP-Range die Subnetmask 255.255.240.0 ist. Das bedeutet, dass gegen 4000 Rechner (16*256) zu einem Subnetz geschlossen sind oder sein könnten. Verstehe zu wenig, aber vielleicht liegt da die Ursache von Problemen. Vieleicht ist ganzes Subnetz an Grenze der Belastung., ka. Der Arptraffic muss jedenfalls gigantisch sein.
Cablecom müsst mehr Headens fur mehr Kunden einrichten. lol
Erinnere mich selber an Anfang meiner Cable-Zeit. Hatte eine Subnetmask zuerst von 255.255.254.0 und hatte wenig bis gar kein Probleme. Später 255.255.248.0 und regelmassige Ausfall und Storungen beginnten. Vielleicht Zufall, weiss nicht.
Jedenfalls hat mir ausgehängt unf hab gekundet ;-)
-- Veröffentlicht durch Mephi am 2:43 pm am Okt. 28, 2004
"find interresant, dass bei 84.72er IP-Range die Subnetmask 255.255.240.0 ist."
nö, die Zywall von Hotting gibt ein /21-er Subnetz an. Bei mir wars zu Beginn auch /23-er und über ein /22-er bin ich jetzt auch in einem /21-er Subnetz. Ich konnte keine Unterschiede feststellen und könnte sie mir theoretisch auch schlecht vorstellen.
Philipp
-- Veröffentlicht durch MAC Ferrari am 2:47 pm am Okt. 28, 2004
@Nuttenpreller
das mit den verkleinerten Subnetzen 255.255.240.0 scheint die neue Strategie der CC zu sein. Dies hat mir jedenfalls ein Techniker erläutert, als in userem Viertel alle die Modems abschalten mussten, da sie den Node/HE Bereich verkleinerten. Das Ziel ist, dass dann pro ?(HE)/ Node? etwa 1000 Modems angeschlossen werden. Das finde ich gar nicht mal so schlecht, denn je mehr "unabhängige" (HE's) es gibt, desto unempfilimpflicher ist dann das gesamte CC Netz, falls in einem HE Bereich ein Fehler/ Störung auftritt.
Greetz MAC_Ferrari
-- Veröffentlicht durch Rene am 12:21 am am Okt. 30, 2004
hotting>Etwas spät meine Antwort, aber ich war bis jetzt genügend mit zügeln beschäftigt. Das Du damit beim first-level support kaum auf eine Lösung kommen wirst hätte ich Dir gleich sagen können. Das Problem ist ja jetzt gelöst aber in Zukunft schreibe sowas direkt an die Mail Adresse vom THH (nachschaubar im Profil), da wäre es schneller an die richtige Stelle gekommen.
-- Veröffentlicht durch mart01 am 11:12 am am Nov. 14, 2004
Zitat von hotting am 10:51 pm am Okt. 27, 2004[br
Naja, egal... Hauptsache, dass es nun wieder so funktioniert, wie man es sich wünscht. Endlich wieder stabile Verbindungen, die nicht stündlich in sich zusammenfallen.
Hallo,
Leider besteht bei mir das Problem noch. Ich habe ein Zyxel P324 ML mit Firmware 3.61 JF.0 und regelmässig jede Stunde unterbricht das Internet für kurze Zeit.
Die Cablecom-Hotline nahm den Fall auf, konnte mir aber betr. einer Lösung nichts versprechen. (Mein Router erhält 80.218er IPs.)
Bei Zyxel warte ich seit fast einer Woche auf eine weitere Antwort.
Leider lässt sich auf die P324 ML-Version keine "normale" Firmware laden, denn bei der intern. Version 3.61 JA.5 scheint dieses Problem nicht zu bestehen (zumindest bei einem Freund von mir).
Was kann ich tun? Irgendwie fühle ich mich als Kunde zwischen Cablecom und Zyxel eingeklemmt.
Gruss
Martin
(Geändert von mart01 um 11:13 am am Nov. 14, 2004)
-- Veröffentlicht durch domino2 am 4:14 pm am Nov. 14, 2004
leute..hab seit 4 tagen keinen unterbruch gehabt..mit zywall2 dran!! scheint jetzt zu klappen..was auch immer sie gemacht haben..geil mann :)
|