Mailinglist Archive: opensuse-de (2118 mails)
| < Previous | Next > |
Re: SuSe 9.1 - DSL - Einwahlprobleme
- From: Christian Boltz <suse@xxxxxxxxx>
- Date: Tue, 2 Aug 2005 23:19:51 +0200
- Message-id: <200508022319.51535@xxxxxxxxxxxxxxx>
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?
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?
| < Previous | Next > |