Hallo miteinander,
ich habe das Problem, dass ich auf meinem mit Suse 9.1 laufenden System etliche Seiten nicht oder nur teiweise laden kann. So wird z.B. Die Seite des Spiegels (www.spiegel.de) zwar gerufen aber nur unvollständig geladen und nix angezeigt. Opera meldet in seiner Statuszeile irgendwas von z.B. 7 von 9 Bilder geladen und bleibt dann hängen. Bei Mozilla/Firefox vom Prinzip das selbe.
Ich habe den Verdacht, dass eine Problem mit der Namesauflösung zumindest Teilursache sein könnte, denn eine ganze Reihe von Seitenamen lassen sich nicht über den Seitennamen anpingen – wobei meist anpingen der IP-Adresse geht. Lustig hierbei ist, dass es für bestimmte Seiten mal geht und mal nicht. So funktionierte gestern am frühen Abend z.B. http://www.linux-community gar nicht, d.h. Weder Ping auf „www.linux-community.de“ noch auf die IP-Adresse antwortete, einige Stunden später tat es (wenn auch träge):
PING http://www.linux-community.de (62.245.157.218) 56(84) bytes of data.
64 bytes from http://www.linux (62.245.157.218): icmp_seq=1 ttl=54 time=270 ms
64 bytes from http://www.linux (62.245.157.218): icmp_seq=2 ttl=54 time=230 ms
Dies Verhalten habe ich auch bei anderen Seiten. Oder bei http://www.einsundeins.de (ich bin bei 1&1) wurde zwar die Hauptseite geladen, aber Unterseiten wie z.B. Der Kundenlogin gingen nicht.
In den Netzwerkeinstellungen ist DHCP aktiv (Automatische Adressvergabe (mit DHCP) und automatische DNS Vergabe ist eingeschaltet). Ich habe aber auch mal spaßeshalber ein paar Namensserver angegeben – was zu keiner Änderung führte.
ifconfig -a sagt:
eth1 Protokoll:Ethernet Hardware Adresse 00:0C:76:5A:87:21
inet Adresse:192.168.178.21 Bcast:192.168.178.255 Maske:255.255.255.0
inet6 Adresse: fe80::20c:76ff:fe5a:8721/64 Gültigkeitsbereich:Verbindung
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:380 errors:0 dropped:0 overruns:0 frame:0
TX packets:422 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:367243 (358.6 Kb) TX bytes:89136 (87.0 Kb)
Interrupt:23 Basisadresse:0xd400
Inhalt von /etc/sysconfig/network # cat ifcfg-eth-id-00:0c:76:5a:87:21
BOOTPROTO=’dhcp’
BROADCAST=’192.168.178.255′
IPADDR=’192.168.178.2′
MTU=’1492′
NETMASK=’255.255.255.0′
NETWORK=’192.168.178.0′
REMOTE_IPADDR=”
Interessant hieran, dass ifconfig -a für die MTU 1500 ausgibt, obwohl der hier mit 1492 angeben ist. Ich konnte MTU dann zwar von der Kommandozeile mit ifconfig so setzen, dass der auch von ifconfig -a mit 1492 angezeigt wurde – das änderte aber am Problem nichts. Nach Reboot zeigt ifconfig -a wieder 1500 an. In dem Zusammenhang könnten auch noch folgende Einträge im /var/log/messages interessant sein, die auftraten, als ich versuchte die MTU über Yast zu ändern (war 1500):
Aug 29 20:12:30 athlon dhcpcd[7725]: broadcasting DHCP_DISCOVER
Aug 29 20:12:40 athlon dhcpcd[7725]: timed out waiting for a valid DHCP server response
Aug 29 20:13:12 athlon ipppd[4764]: Terminating on signal 15.
Aug 29 20:13:12 athlon ipppd[4764]: closing fd 6 from unit 0
Aug 29 20:13:12 athlon ipppd[4764]: link 0 closed , linkunit: 0
Aug 29 20:13:12 athlon ipppd[4764]: closing fd 7 from unit 1
Aug 29 20:13:12 athlon ipppd[4764]: link 1 closed , linkunit: 1
Aug 29 20:13:12 athlon ipppd[4764]: Exit.
Aug 29 20:13:12 athlon dhcpcd[4511]: terminating on signal 15
Aug 29 20:13:15 athlon pppd[8396]: Plugin rp-pppoe.so loaded.
Aug 29 20:13:15 athlon pppd[8396]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2
Aug 29 20:13:15 athlon pppd[8396]: Plugin passwordfd.so loaded.
Aug 29 20:13:15 athlon pppd[8396]: pppd 2.4.2 started by root, uid 0
Aug 29 20:13:15 athlon pppd[8396]: PPP session is 8803
Aug 29 20:13:15 athlon pppd[8396]: Using interface ppp0
Aug 29 20:13:15 athlon pppd[8396]: Connect: ppp0 eth1
Aug 29 20:13:15 athlon pppd[8396]: Couldn’t increase MTU to 1500
Aug 29 20:13:15 athlon pppd[8396]: Couldn’t increase MRU to 1500
Aug 29 20:13:15 athlon ipppd[8481]: Found 2 devices: ,
Aug 29 20:13:15 athlon ipppd[8482]: ipppd i2.2.12 (isdn4linux version of pppd by MH) started
Aug 29 20:13:15 athlon ipppd[8482]: init_unit: 0
Aug 29 20:13:15 athlon ipppd[8482]: Connect[0]: /dev/ippp0, fd: 11
Aug 29 20:13:15 athlon ipppd[8482]: init_unit: 1
Aug 29 20:13:15 athlon ipppd[8482]: Connect[1]: /dev/ippp1, fd: 14
Aug 29 20:13:35 athlon pppd[8396]: PAP authentication failed
Aug 29 20:13:35 athlon pppd[8396]: Couldn’t increase MTU to 1500
Aug 29 20:13:35 athlon pppd[8396]: Couldn’t increase MRU to 1500
Aug 29 20:13:35 athlon pppd[8396]: Connection terminated.
Aug 29 20:13:35 athlon pppd[8396]: Exit.
Am frühen Abend hatte ich den Effekt, dass von einer anderen Seite die Namensauflösung zwar grundsätzlich funktionierte, d.h. Ping gab eine IP-Adresse zurück – aber keine Antwort vom angepingten Server. Ping auf die zurückgegebene IP-Adresse gab jedoch eine Serverantwort zurück. Hierauf traceroute:
traceroute to http://www.roadstervision.info (79.103.255.127), 30 hops max, 40 byte packets
1 fritz.box (192.168.178.1) 0.364 ms 0.276 ms 0.332 ms
2 217.0.116.30 51.457 ms 58.938 ms 59.665 ms
3 217.0.66.50 62.587 ms 66.196 ms 69.979 ms
4 f-sa3.F.DE.net.DTAG.DE (62.154.17.133) 73.189 ms 76.665 ms 80.094 ms
5 f-gw13.F.net.DTAG.DE (62.154.18.46)(H!) 84.209 ms * *
Der Versuch diese Webseite im Konqueror zu laden, gab folgende Fehlermeldung:
Zeitüberschreitung auf dem Server
Verbindung bestand zu http://www.roadstervision.info an Port 80
nslookup auf http://www.spiegel.de sagt:
nslookup http://www.spiegel.de
Note: nslookup is deprecated and may be removed from future releases.
Consider using the `dig’ or `host’ programs instead. Run nslookup with
the `-sil[ent]’ option to prevent this message from appearing.
Server: 192.168.178.1
Address: 192.168.178.1#53
Non-authoritative answer:
Name: http://www.spiegel.de
Address: 195.71.11.67
Und jetzt bin ich mit meinem Latein am Ende… Hat von euch noch jemand ne Idee, woran das liegen könnte?
Grüße und ne sonnige Woche,
Thomas
Hallo Thomas,
ich habe zwar keine 9.1 mehr hier laufen, aber im Verzeichnis /etc/ppp/ findest Du die Datei options, in der Du einen Wert für die MTU setzen kannst. Darüberhinaus legt Yast für ein Device normalerweise noch einmal eine eigene options an, also zum Beispiel eine options.ippp0.
Zudem kannst Du im gleichen Verzeichnis die Datei ip-up.local anlegen, soweit nicht vorhanden und in dieser die folgende Zeile aufnehmen:
/sbin/ifconfig ppp0 mtu 1450
Ich habe bei manchen Kunden die Erfahrung gemacht, daß ein Wert von 1492 nicht ausreichend ist und daher setze ich hier die MTU 1450.
Außerdem hat sich bei mir SuSE auch an der Kombination von DHCP und dem Vorhandensein einer IP-Adresse in der Konfigurationsdatei gestört. An Deiner Stelle würde ich die Karte über Yast löschen, die Datei löschen und dann die Karte noch einmal mit Yast für DHCP einrichten.
Viel Erfolg,
Stefan
—
********************************************
in-put GbR – Das Linux-Systemhaus
Stefan-Michael Guenther
Moltkestrasse 49 D-76133 Karlsruhe
Tel./Fax : +49 (0)721 / 83044 – 98/93
http://www.in-put.de
********************************************
Schulungen Installationen
Beratung Support
********************************************
Hallo Thomas!
Am frühen Abend hatte ich den Effekt, dass von einer anderen Seite die Namensauflösung zwar grundsätzlich funktionierte, d.h. Ping gab eine IP-Adresse zurück – aber keine Antwort vom angepingten Server. Ping auf die zurückgegebene IP-Adresse gab jedoch eine Serverantwort zurück. Hierauf traceroute: traceroute to http://www.roadstervision.info (79.103.255.127), 30 hops max, 40 byte packets 1 fritz.box (192.168.178.1) 0.364 ms 0.276 ms 0.332 ms …
Leider hast Du ja wenig darüber geschrieben, auf welchem Weg Du ins Internet gehst. Der Traceroute verrät aber einiges: Du verwendest eine FRITZ!Box im Router Mode, nicht als Modem. Sprich die Zugangsdaten Deines 1&1 Accounts sind auf der FRITZ!Box konfiguriert und die Box baut die PPPoE Verbindung über die DSL Leitung auf.
Das heisst, Du brauchst weder den ‘pppd’ noch den ‘ipppd’, deren Meldungen im Logfile augtauchen. Deaktiviere diese Dienste (geht bei Suse wohl mit Yast). [Nebenbei bemerkt heisst das auch, dass der Großteil von Stefans Antwort für Dich uninteressant ist. Durch Deine Beschreibung hast Du ihn in die Irre geleitet.]
Zurück zum Traceroute: traceroute to http://www.roadstervision.info (79.103.255.127), 30 hops max, 40 byte packets 1 fritz.box (192.168.178.1) 0.364 ms 0.276 ms 0.332 ms 2 217.0.116.30 51.457 ms 58.938 ms 59.665 ms 3 217.0.66.50 62.587 ms 66.196 ms 69.979 ms 4 f-sa3.F.DE.net.DTAG.DE (62.154.17.133) 73.189 ms 76.665 ms 80.094 ms 5 f-gw13.F.net.DTAG.DE (62.154.18.46)(H!) 84.209 ms * *
Vom Telekom-Router, der 5 Hops entfernt ist, erhältst Du auf drei gesendete Pakete zweimal keine Antwort und einmal “Host unreachable” (in der Ausgabe von traceroute als (H!) geschrieben). Es liegt in diesem Fall also kein Problem mit Deiner Konfiguration vor. http://www.roadstervision.info ist inzwischen auch auf die IP-Adresse 81.169.145.86 umgezogen. nslookup http://www.spiegel.de … Server: 192.168.178.1 Address: 192.168.178.1#53 Non-authoritative answer: Name: http://www.spiegel.de Address: 195.71.11.67
Das heisst zum Einen, dass Du Deine FRITZ!Box (192.168.178.1) als DNS Server verwendest, und sieht zum anderen völlig normal aus.
Interessant hieran, dass ifconfig -a für die MTU 1500 ausgibt, obwohl der hier mit 1492 angeben ist. Ich konnte MTU dann zwar von der Kommandozeile mit ifconfig so setzen, dass der auch von ifconfig -a mit 1492 angezeigt wurde – das änderte aber am Problem nichts.
Lass die MTU des Interfaces einfach auf 1500. Die FRITZ!Box macht von selbst ein MSS-Clamping auf 1452 (ist zumindest bei meiner FRITZ!Box Fon so), um die üblichen Path-MTU-Discovery Probleme zu verhindern.
Harald
