Hallo Axel, hallo Leute, Am Dienstag, 2. August 2005 18:22 schrieb Dr. Axel Krebs:
danke für Deine Kommentare. Habe "lsmod" ausprbiert: vor und nach dem Starten von YAST2: keine erkennbarenUnterschiede.
Ein nicht geladenes Modul scheidet also schonmal aus. Bliebe theoretisch noch ein nicht gestarteter Daemon, was mich aber eher wundern würde. Vergleiche dazu mal die Ausgabe von ps ax vor und nach dem YaST-Lauf (abweichende Werte in der Spalte TIME kannst Du ignorieren, die in STAT in der Regel auch).
Wenn ich den Tail-Befehl starte, bekomme ich das Folgende: ...
... "tail -f /var/log/messages" liefert:
vorweg: SFW2-INext-DROP-DEFLT heißt, dass das jeweilige Paket geblockt wurde. Sehen wir uns die Pakete mal etwas genauer an:
Aug 2 18:05:46 linux kernel: SFW2-INext-DROP-DEFLT IN=ppp0 OUT= MAC= SRC=84.163.216.87 DST=84.163.231.78 LEN=48 TOS=0x00 PREC=0x00 TTL=127
Ein Datenpaket von 84.163.216.87 (SRC) an 84.163.231.78 (DST) wurde abgelehnt.
ID=22466 DF PROTO=TCP SPT=4219 DPT=135 WINDOW=64800 RES=0x00 SYN
Zielport (DPT) war 135 (laut /etc/services "DCE end point resolution" - sagt mir spontan nichts, frag einfach mal Google ;-)
URGP=0 OPT (020405A001010402) Aug 2 18:06:04 linux kernel: SFW2-INext-DROP-DEFLT IN=ppp0 OUT= MAC= SRC=84.163.239.210 DST=84.163.231.78 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=721 DF PROTO=TCP SPT=3654 DPT=139 WINDOW=32767 RES=0x00 SYN URGP=0 OPT (020405AC0103030001010402)
Zielport 139 heißt, dass es das übliche Hintergrundrauschen der Windows-Dateifreigabe oder Samba ist. Kannst Du ignorieren.
Aug 2 18:06:06 linux kernel: SFW2-INext-DROP-DEFLT IN=ppp0 OUT= MAC= SRC=84.163.70.45 DST=84.163.231.78 LEN=64 TOS=0x00 PREC=0x00 TTL=44 ID=23167 DF PROTO=TCP SPT=3968 DPT=445 WINDOW=53760 RES=0x00 SYN URGP=0 OPT (020405A0010303030101080A000000000000000001010402)
Zielport 445 gehört auch irgendwie[tm] zur Windows-Dateifreigabe. Was mich dabei erstmal wundert: anscheinend hast Du eine IP - ansonsten könnten diese Pakete nicht bei Dir ankommen.
Aug 2 18:06:26 linux su: (to root) drak on /dev/pts/2 Aug 2 18:06:26 linux su: pam_unix2: session started for user root, service su Aug 2 18:06:30 linux kernel: SFW2-INext-DROP-DEFLT IN=ppp0 OUT= MAC= SRC=84.163.69.205 DST=84.163.231.78 LEN=52 TOS=0x00 PREC=0x00 TTL=124 ID=39113 DF PROTO=TCP SPT=3492 DPT=135 WINDOW=32767 RES=0x00 SYN URGP=0 OPT (020405AC0103030001010402)
Wieder (diesmal mehrfach [weggekürzt]) Zielport 135 - siehe oben.
"tail -f /var/log/messages" liefert NACH YAST-Aufruf: ... linux:/home/krebsaxel # tail -f /var/log/messages Aug 2 18:12:58 linux kernel: SFW2-INext-ACC-HiTCP IN=ppp0 OUT= MAC= SRC=217.72.192.134 DST=84.163.231.78 LEN=153 TOS=0x00 PREC=0x00 TTL=60 ID=55737 DF PROTO=TCP SPT=110 DPT=1492 WINDOW=5792 RES=0x00 ACK PSH URGP=0 OPT (0101080A29825A4F001F70BC)
Diesmal wurde ein Paket akzeptiert - SPT 110 ist pop3 (Mailabruf). (Allerdings wundert micht, dass SPT 110 verwendet ist - typisch ist _DPT_ 110.) Ansonsten (weggekürzt) wieder das Windows-Hintergrundrauschen.
Aug 2 18:13:06 linux dhcpcd[8344]: timed out waiting for a valid DHCP server response
Aug 2 18:13:46 linux kernel: SFW2-INext-ACC-HiUDP IN=ppp0 OUT= MAC= SRC=70.86.48.186 DST=84.163.231.78 LEN=513 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=32994 DPT=1026 LEN=493
Ein akzeptiertes UDP-Paket, das ich allerdings nicht zuordnen kann.
Aug 2 18:13:46 linux kernel: SFW2-INext-DROP-DEFLT IN=ppp0 OUT= MAC= SRC=70.86.48.186 DST=84.163.231.78 LEN=513 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=32994 DPT=1026 LEN=493
Ein ähnliches UDP-Paket wurde kurz darauf abgelehnt.
Aug 2 18:13:58 linux kernel: SFW2-INext-ACC-HiTCP IN=ppp0 OUT= MAC= SRC=217.72.192.134 DST=84.163.231.78 LEN=52 TOS=0x00 PREC=0x00 TTL=60 ID=55738 DF PROTO=TCP SPT=110 DPT=1492 WINDOW=5792 RES=0x00 ACK FIN URGP=0 OPT (0101080A298271BF001F7114)
Wieder SPT 110 (pop3)
Aug 2 18:14:10 linux dhcpcd[8471]: broadcasting DHCP_DISCOVER
Nächster Versuch, per DHCP eine IP zu bekommen. Ergebnis: "nur" Windows-Hintergrundrauschen. (oder Du hast zu viel weggekürzt ;-)
Aug 2 18:14:20 linux dhcpcd[8471]: timed out waiting for a valid DHCP server response
So, es kam also wieder keine Antwort per DHCP.
An den mit ">>" markierten beiden Zeilen scheint das System auf dhcpcd[8344] oder dhcpcd[8471] zu warten.
Kann das der Grund für die Verzögerungen sein?
Gut möglich. Die Frage ist nur, ob keine Antwort kommt oder ob sie "nur" irgendwo geblockt wird. _Zum Testen_ kannst Du ja mal kurzfristig die Firewall abschalten - funktioniert es dann? Was noch interessant wäre: Was ist bei Dir netzwerktechnisch vorhanden (Anzahl Netzwerkkarten im Rechner? Internes Netz? Ausgabe von ifconfig?) und wie ist die Firewall konfiguriert? grep "^[^#]" /etc/sysconfig/SuSEfirewall2
Am Di, den 02.08.2005 schrieb Christian Boltz um 1:48:
Am Montag, 1. August 2005 16:33 schrieb Dr. Axel Krebs:
TOFU entsorgt - bitte http://learn.to/quote Gruß Christian Boltz, keine Zufallssig. -- A: Weil es die Lesbarkeit des Textes verschlechtert. F: Warum ist TOFU so schlimm? A: TOFU F: Was ist eins der groesste Aergernisse im Usenet?