Hallo, habe hier UMTS-Internet-Zugang über ein Handy, Handy ist am Laptop über Bluetooth. Wenn die Internet-Verbindung abreisst (trotz gutem Empfang, tags passiert das ständig, nachts nie, typisch eplus-"Spielnetz") dann muss der Laptop meistens gebootet werden, weil der Laptop kein masquerading mehr macht oder sonst irgendein Fehler zuschlägt, der wie ein MASQ-Stop auswirkt. Auf dem Laptop selbst nach Wiederherstellung der UMTS-Internetverbindung kann noch gesurft werden, nur eben die anderen Clients im LAN meistens nicht mehr (aber nicht immer). iptables -L ist immer gleich, im funktionierenden oder "defekten" Zustand, SuSE-Firewall ist an, schalte ich die im "defekten" Zustand ab, wird dennoch kein masquerading gemacht. MASQUERADE rufe ich natürlich mehrfach auf. Trotzdem: meistens ein reboot des Laptop notwendig. Natürlich ist IP-Forwarding eingestellt, ein echo /proc/sys/net/ipv4/ip_forward liefert immer eine 1. Auch im "defekten" Zustand. Ein ssh oder ping von den Clients auf den Laptop funktioniert jederzeit einwandfrei. Ein ping ins Internet wird im "defekten" Zustand nicht mehr beantwortet. Das routing ist auch immer unverändert. Hat jmd eine Idee wo ich noch nachsehen könnte? So wähle ich mich ein: wvdial , dann iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE Gruss Ekkard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo. * Freitag, 05. Oktober 2007 um 13:58 (+0200) schrieb Ekkard Gerlach:
[ Kein Maquerading nach Verbindungsabbruch ]
iptables -L ist immer gleich, im funktionierenden oder "defekten" Zustand, SuSE-Firewall ist an, schalte ich die im "defekten" Zustand ab, wird dennoch kein masquerading gemacht. MASQUERADE rufe ich natürlich mehrfach auf. Trotzdem: meistens ein reboot des Laptop notwendig.
Natürlich ist IP-Forwarding eingestellt, ein echo /proc/sys/net/ipv4/ip_forward liefert immer eine 1. Auch im "defekten" Zustand.
Ein ssh oder ping von den Clients auf den Laptop funktioniert jederzeit einwandfrei. Ein ping ins Internet wird im "defekten" Zustand nicht mehr beantwortet.
Das routing ist auch immer unverändert.
Hat jmd eine Idee wo ich noch nachsehen könnte?
So wähle ich mich ein: wvdial , dann iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Das kann verschiedene Gründe haben. Die einfachste Ursache wäre IMHO, dass der 'pppd' sich beim Verbindungsabbruch nicht ordentlich beendet und ein erneuter Verbindungsaufbau dann das Device "ppp1" benutzt. Aktiviere das Masquerading doch probehalber mit 'iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE' Gruß Andreas -- XMMS spielt gerade nichts... GPG-ID/Fingerprint: 6F28CF96/0B3B C287 30CE 21DF F37A AF63 A46C D899 6F28 CF96 GPG-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Andreas Koenecke schrieb: [...]
So wähle ich mich ein: wvdial , dann iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Das kann verschiedene Gründe haben. Die einfachste Ursache wäre IMHO, dass der 'pppd' sich beim Verbindungsabbruch nicht ordentlich beendet und ein erneuter Verbindungsaufbau dann das Device "ppp1" benutzt. Aktiviere das Masquerading doch probehalber mit 'iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE'
versucht. Leider kein Erfolg. Es ist tatsächlich auch ppp0, es ist sonst auch kein anderes Device aufgesetzt, sichtbar unter ifconfig -a Sonst noch eine Idee? Hier übrigens ein tcpdump im Erfolgsfall, also wenn's noch geht, ein ping aiai.de wurde ausgeführt: tcpdump -i eth0: ================= 14:23:11.690360 arp who-has fli4l tell amilo2.standard92 14:23:11.690474 arp reply fli4l is-at 00:60:97:b8:9e:1e 14:23:18.179216 IP fli4l > dd1036.kasserver.com: icmp 64: echo request seq 1 14:23:19.188580 IP fli4l > dd1036.kasserver.com: icmp 64: echo request seq 2 14:23:19.302726 IP ns01sn1.eplus.de.domain > fli4l.1024: 20818 ServFail[|domain] 14:23:19.303043 IP fli4l.1024 > ns02sn1.eplus.de.domain: 20818+ [b2&3=0x182][|domain] 14:23:19.303122 IP fli4l.1024 > ns01sn1.eplus.de.domain: 20818+ [b2&3=0x182][|domain] 14:23:19.305667 IP ns01sn1.eplus.de.domain > fli4l.1024: 22123 ServFail[|domain] 14:23:19.305957 IP fli4l.1024 > ns02sn1.eplus.de.domain: 22123+ [b2&3=0x182][|domain] 14:23:19.306038 IP fli4l.1024 > ns01sn1.eplus.de.domain: 22123+ [b2&3=0x182][|domain] 14:23:19.347701 IP dd1036.kasserver.com > fli4l: icmp 64: echo reply seq 1 14:23:19.398740 IP dd1036.kasserver.com > fli4l: icmp 64: echo reply seq 2 14:23:20.188727 IP fli4l > dd1036.kasserver.com: icmp 64: echo request seq 3 14:23:20.405739 IP dd1036.kasserver.com > fli4l: icmp 64: echo reply seq 3 14:23:21.188658 IP fli4l > dd1036.kasserver.com: icmp 64: echo request seq 4 14:23:21.435742 IP dd1036.kasserver.com > fli4l: icmp 64: echo reply seq 4 14:23:22.188682 IP fli4l > dd1036.kasserver.com: icmp 64: echo request seq 5 14:23:22.406754 IP dd1036.kasserver.com > fli4l: icmp 64: echo reply seq 5 Fehlerfall: =========== amilo2:~ # tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 20:56:04.787398 IP fli4l.1024 > ns01sn1.eplus.de.domain: 25076+ AAAA? img.web.de. (28) 20:56:05.046009 IP fli4l.1024 > ns02sn1.eplus.de.domain: 25076+ AAAA? img.web.de. (28) 20:56:09.786682 IP fli4l.1024 > ns01sn1.eplus.de.domain: 25076+ AAAA? img.web.de. (28) 20:56:09.786760 IP fli4l.1024 > ns02sn1.eplus.de.domain: 25076+ AAAA? img.web.de. (28) 20:56:14.786919 IP fli4l.1024 > ns01sn1.eplus.de.domain: 9398+ AAAA? img.web.de. (28) 20:56:14.786997 IP fli4l.1024 > ns02sn1.eplus.de.domain: 9398+ AAAA? img.web.de. (28) 20:56:19.786961 IP fli4l.1024 > ns01sn1.eplus.de.domain: 9398+ AAAA? img.web.de. (28) 20:56:19.787038 IP fli4l.1024 > ns02sn1.eplus.de.domain: 9398+ AAAA? img.web.de. (28) 20:56:24.787218 IP fli4l.1024 > ns01sn1.eplus.de.domain: 39065+ A? img.web.de. (28) 20:56:24.787294 IP fli4l.1024 > ns02sn1.eplus.de.domain: 39065+ A? img.web.de. (28) 20:56:29.787246 IP fli4l.1024 > ns01sn1.eplus.de.domain: 39065+ A? img.web.de. (28) 20:56:29.787324 IP fli4l.1024 > ns02sn1.eplus.de.domain: 39065+ A? img.web.de. (28) 20:56:29.976824 IP fli4l.1024 > ns01sn1.eplus.de.domain: 2712+ A? aiai.de. (25) 20:56:29.976899 IP fli4l.1024 > ns02sn1.eplus.de.domain: 2712+ A? aiai.de. (25) 20:56:34.787461 IP fli4l.1024 > ns01sn1.eplus.de.domain: 63307+ A? img.web.de. (28) 20:56:34.787543 IP fli4l.1024 > ns02sn1.eplus.de.domain: 63307+ A? img.web.de. (28) 20:56:34.975366 IP fli4l.1024 > ns01sn1.eplus.de.domain: 2712+ A? aiai.de. (25) 20:56:34.975439 IP fli4l.1024 > ns02sn1.eplus.de.domain: 2712+ A? aiai.de. (25) Gruss Ekkard -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
* Montag, 08. Oktober 2007 um 19:33 (+0200) schrieb Ekkard Gerlach:
* Andreas Koenecke schrieb:
Aktiviere das Masquerading doch probehalber mit 'iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE'
versucht. Leider kein Erfolg. Es ist tatsächlich auch ppp0, es ist sonst auch kein anderes Device aufgesetzt, sichtbar unter ifconfig -a
Sonst noch eine Idee?
[ ... ]
Fehlerfall: ===========
amilo2:~ # tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 20:56:04.787398 IP fli4l.1024 > ns01sn1.eplus.de.domain: 25076+ AAAA? img.web.de. (28) 20:56:05.046009 IP fli4l.1024 > ns02sn1.eplus.de.domain: 25076+ AAAA? img.web.de. (28) 20:56:09.786682 IP fli4l.1024 > ns01sn1.eplus.de.domain: 25076+ AAAA? img.web.de. (28) 20:56:09.786760 IP fli4l.1024 > ns02sn1.eplus.de.domain: 25076+ AAAA? img.web.de. (28) 20:56:14.786919 IP fli4l.1024 > ns01sn1.eplus.de.domain: 9398+ AAAA? img.web.de. (28) 20:56:14.786997 IP fli4l.1024 > ns02sn1.eplus.de.domain: 9398+ AAAA? img.web.de. (28) 20:56:19.786961 IP fli4l.1024 > ns01sn1.eplus.de.domain: 9398+ AAAA? img.web.de. (28) 20:56:19.787038 IP fli4l.1024 > ns02sn1.eplus.de.domain: 9398+ AAAA? img.web.de. (28) 20:56:24.787218 IP fli4l.1024 > ns01sn1.eplus.de.domain: 39065+ A? img.web.de. (28) 20:56:24.787294 IP fli4l.1024 > ns02sn1.eplus.de.domain: 39065+ A? img.web.de. (28) [ ... ]
Ich kann hier auch nur erkennen, dass der Client versucht, den Name-Server abzufragen und keine Antworten bekommt... Hast du schon mal versucht, vom Client eine IP-Nr. zu erreichen (z.B. 193.99.144.85), um Problem bei der Namensauflösung auzuschließen? Falls das auch nicht funktioniert, hilft vermutlich nur "das volle Programm": - Setze in "/etc/ppp/options" die Optionen "debug" und "dump" (jeweils in einer Zeile). - Poste im Fehlerfall: + die Ausgaben des 'pppd' aus v/l/m (Verbindungsabbau der "guten" Verbindung und _vollständiger_ Verbindungsaufbau der "schlechten" Verbindung), + Ausgabe von 'ifconfig -a', + Ausgabe von 'route -n', + Ausgabe von 'iptables -t nat -L -nv' und + Ausgabe von 'iptables -L FORWARD -nv'. Gruß Andreas -- XMMS spielt gerade nichts... GPG-ID/Fingerprint: 6F28CF96/0B3B C287 30CE 21DF F37A AF63 A46C D899 6F28 CF96 GPG-Key on request or on public keyservers -- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (2)
-
Andreas Koenecke
-
Ekkard Gerlach