  |
|
|
|
|
|
|
|
|
MAC Ferrari
Advanced Member
|
      
@Reneja 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
-----
Some men see things as they are and say why, I dream things that never work and say why not?
|
Beiträge gesamt: 778 | Mitglied seit: Feb. 2004 | Erstellt: 3:24 pm am Okt. 22, 2004 | IP
|
|
hotting
Newbie
|
Hallo zusammenWie 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.
|
Beiträge gesamt: 11 | Mitglied seit: Sep. 2004 | Erstellt: 7:12 pm am Okt. 23, 2004 | IP
|
|
Nuttenpreller
Newbie
|
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
-----
Aus dem Lehrbuch für Telekommunikation:
Koaxkabel ist sehr gut geeignet für analoges Fernsehen,
für alles übrige empfiehlt sich guter alter Kupferdraht...
|
Beiträge gesamt: 40 | Mitglied seit: Sep. 2004 | Erstellt: 10:04 am am Okt. 25, 2004 | IP
|
|
|
|
timberwolf
Advanced Member
|
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) :-)
|
Beiträge gesamt: 602 | Mitglied seit: Mai 2002 | Erstellt: 9:55 pm am Okt. 25, 2004 | IP
|
|
Mephi
Advanced Member
|
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)
|
Beiträge gesamt: 987 | Mitglied seit: Dez. 2001 | Erstellt: 3:02 am am Okt. 26, 2004 | IP
|
|
| |
|
cablemodem.ch - Forum
Lease wird nicht erneuert
