Opensuse 11.2 und UMTSMON (Mobiles Internet von O2) nach Anmelden im Internet zuerst langsam

Hallo,

an meinem PC nutze ich Opensuse 11.2 und UMTSMON (Mobiles Internet von O2). Da ich in einem Tal des schlechten Internetzuganges wohne, versuche ich so ein vertretbares Maß an Preis-Leistung zu erhalten. Mit EDGE erziele ich keine hohe Downloadgeschwindigkeit. Deshalb ist es umso wichtiger, dass alles reibungslos läuft. Seit einiger Zeit ist mir aufgefallen, dass nach meiner Internetanmeldung (UMTSMON) der Onlineverkehr schleppend startet. Umtsmon zeigt Downloads und Uploads, obwohl ich noch keinen Browser aktiv habe. Sollte ich einen Browser starten, so ist eine Schnecke schnell. Der Seitenaufbau ist dann extrem langsam. Nach einigen Minuten normalisiert sich das Browserverhalten.
Kurios ist, dass das leistungsgeminderte Startverhalten nicht bei jedem Anmelden auftritt.

Was ist das ?
Wie schalte ich Opensuse 11.2-Systemaktualisierungen zuverlässig aus?
Genügt es in YAST → Einrichtung der Onlineaktualisierung alle Haken zu entfernen?
Wie erhalte ich zuverlässige Informationen, was hier geschieht?
Wie kontrolliere ich den Datenverkehr?
Wie ermittle ich möglichst einfach den Verursacher des Datenverkehrs?
Gibt es Linux-Viren?

Mit freundlichen Grüßen

Basti1

Hallo zusammen,

um den “Übeltäter” zu identifizieren, gib bitte in einem Terminal


netstat -apneeA inet

ein, wenn der Effekt auftritt und poste das Ergebnis hier. Mit netstat kannst Du Dir die aktiven Verbindungen anschauen. Zu den Parametern siehe man netstat.

Liebe Grüße

Erik

Könnte aber auch ein Problem in Deinem Wohnbereich sein. Eventuell hat sich da was vom Signal her verschlechtert. Ist das mit einem Laptop woanders ähnlich?

Guten Morgen !

Es ist wie mit einer Maus. Wenn man darauf wartet kommt der Plagegeist nicht. Das lästige schlechte Dowloadverhalten trat nicht mehr auf. Vielleicht ist die Verzögerung nur eine Überlastung des Datenverkehrs bei den Providerprogrammen. Ich werde es weiter beobachten.

Meine netstat Ausgabe im normalen Internetlogin lautet:

netstat -apneeA inet

Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 15179 3283/rpcbind
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 15835 3467/cupsd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 0 17490 3970/master
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 25850 3921/dhcpcd
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 25827 1922/dhcpcd
udp 0 0 0.0.0.0:5353 0.0.0.0:* 105 15524 3404/avahi-daemon:
udp 0 0 0.0.0.0:111 0.0.0.0:* 0 15174 3283/rpcbind
udp 0 0 0.0.0.0:631 0.0.0.0:* 0 15838 3467/cupsd
udp 0 0 0.0.0.0:33161 0.0.0.0:* 105 15525 3404/avahi-daemon:
udp 0 0 0.0.0.0:912 0.0.0.0:* 0 15178 3283/rpcbind

Ich melde mich noch mal, wenn ich ein netstat-Ausgabe bei der Download-Verzögerung einfangen kann.

Danke für die Hilfe!

Mit freundlichen Grüßen

Basti1

Hallo zusammen,

tja, so ist das mit den Fehlern. Wenn man sie analysieren will, sind sie weg. :wink: Wir warten.

Liebe Grüße

Erik

Ich vermute hier nach wie vor ein Providerproblem. Von sowas bin ich mit meinen UMTS Stick auch nicht verschont :slight_smile:

Hallo,

endlich habe ich eine netstat-Ausgabe bei der Verzögerung eingefangen:

netstat -apneeA inet
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name
tcp 0 0 0.0.0.0:52386 0.0.0.0:* LISTEN 0 9209 2113/rpc.statd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 9067 2077/rpcbind
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 9775 2259/cupsd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 0 11644 2803/master
tcp 0 0 10.171.68.37:42525 195.135.221.143:80 TIME_WAIT 0 0 -
tcp 0 0 10.171.68.37:35897 130.57.4.24:80 TIME_WAIT 0 0 -
tcp 0 0 10.171.68.37:41176 209.85.135.139:80 TIME_WAIT 0 0 -
tcp 0 0 10.171.68.37:55021 209.85.135.113:80 TIME_WAIT 0 0 -
udp 0 0 0.0.0.0:58011 0.0.0.0:* 0 9206 2113/rpc.statd
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 22284 2779/dhcpcd
udp 0 0 0.0.0.0:980 0.0.0.0:* 0 9066 2077/rpcbind
udp 0 0 0.0.0.0:5353 0.0.0.0:* 103 9617 2234/avahi-daemon:
udp 0 0 0.0.0.0:111 0.0.0.0:* 0 9062 2077/rpcbind
udp 0 0 0.0.0.0:631 0.0.0.0:* 0 9778 2259/cupsd
udp 0 0 0.0.0.0:1017 0.0.0.0:* 0 9199 2113/rpc.statd
udp 0 0 0.0.0.0:37888 0.0.0.0:* 103 9618 2234/avahi-daemon:

Desweiteren habe ich folgendes festgestellt:

Die Internetverbindung ist besonders am Notebook oft gestört. Dies ist mit Sicherheit kein Opensuse-spezifisches Problem.
Jetzt habe ich sehr oft folgenden Fehler am Notebook: Ich kann von meiner 4-stelligen PIN (Mobiles Internet) nur 3 Ziffern eingeben. Die vierte Ziffer wird nicht angenommen. Die Folge: Ich komme nicht ins Internet. Dies geschieht unter Opensuse, Ubuntu und Vista. Dieser Fehler trat in den vielen Monaten der O2-Mobiles-Internetnutzung noch nie auf. Doch jetzt habe ich ihn öfter. Gehe ich am PC ins Internet (O2-USB-Leitung von Notebook an den Desktop gesteckt ), habe ich die Probleme nicht. War dies Zufall? Testweise habe ich nun unter Suse an einem Notebooksystem WLAN deaktiviert. WLAN benötige ich ja momentan zu Hause nicht. Aussagen zu diesem no-WLAN-Opensuse-System kann ich noch nicht machen. Das nächste Mal kann ich vielleicht mehr zu den Problemen sagen.

Vielen Dank für jeden Rat.

Mit freundlichen Grüßen

Basti1

Hallo zusammen,

Nur so nebenbei. Ist das Absicht, dass Dein ssh, Dein cups und Dein rpc so in die Welt horchen? Dann kann ich ja die Antworten direkt auf Deinem Drucker ausgeben. :wink:

Das ist Suse bzw. Novell

Und das ist Google. Beides ist aber kein Grund, warum die Verbindung sehr langsam ist.

Bei dem Fehlerbild tippe ich dann doch erstmal auf ein Hardwareproblem. Tritt der Fehler auch auf, wenn das Teil am Stromnetz hängt?

Liebe Grüße

Erik

Hallo !

Dieses netstat stammt tatsächlich aus meinem ersten erfolgreichen ssh-Versuchs-system auf dem Notebook. Hier habe ich einmal über overcross-Kabel Notebook und Desktop erfolgreich per SSH verbunden. Zum Aufbau dieses Testsystems benötigte ich natürlich auch Informationen aus dem Internet. Doch SSH ist hier vernachlässigbar.

Am Notebook arbeite ich fast ausnahmslos ohne Batterieteil. Das schont das Batterieteil, so habe ich es gehört und im Internet gelesen. Meine erwachsene Tochter ist anderer Meinung:“Das Batterieteil kann ständig schadlos im Notebook bleiben. Viele Leute würden das so machen und das wäre richtig”.

An ein Notebook-Hardwareproblem habe ich auch schon gedacht. Aber ich kann mir keinen Reim darauf machen. Als der “Internetverbindungsfehler” auftrat, habe ich auch schon mal zusätzlich das am Vortag aufgeladene Batterieteil zusätzlich eingebaut. Doch der Fehler blieb, wie zu erwarten. Wechsel der USB-Buchse für Internet ohne Ergebnisverbesserung.
Meiner Meinung nach ist die Ursache für den “Download-Daten-Stau” eine Überlastung auf dem Datenweg zum und vom Provider, für die der Provider verantwortlich ist. Zu Spitzenzeiten komme ich zur Zeit nur nach vielen Versuchen in das Internet. Das war schon mal besser.

Nun noch ein paar netstat-Ausgaben aus meinem No-WLAN-Opensuse-System ( Notebook ) :

Verzögerung nach Anmelden (Firefox läuft)

netstat -apneeA inet
(Es konnten nicht alle Prozesse identifiziert werden; Informationen über
nicht-eigene Processe werden nicht angezeigt; Root kann sie anzeigen.)
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 13633 -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 14211 -
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 0 15307 -
tcp 0 1 10.140.71.194:36657 141.51.12.72:80 FIN_WAIT1 0 0 -
tcp 0 0 10.140.71.194:40472 195.135.221.143:443 VERBUNDEN 1000 27257 6925/firefox
tcp 0 0 10.140.71.194:52496 130.57.4.24:443 VERBUNDEN 1000 27255 6925/firefox
tcp 0 0 10.140.71.194:41499 130.57.4.12:443 VERBUNDEN 1000 27204 6925/firefox
tcp 0 1 10.140.71.194:46826 134.76.12.3:80 FIN_WAIT1 0 0 -
tcp 0 0 10.140.71.194:41490 130.57.4.12:443 VERBUNDEN 1000 27172 6925/firefox
tcp 0 0 10.140.71.194:41491 130.57.4.12:443 VERBUNDEN 1000 27173 6925/firefox
tcp 1 1 10.140.71.194:46183 195.135.221.134:80 LAST_ACK 0 0 -
tcp 0 1 10.140.71.194:58452 139.18.25.35:80 SYN_SENT 0 27607 -
tcp 0 0 10.140.71.194:41489 130.57.4.12:443 VERBUNDEN 1000 27171 6925/firefox
tcp 0 0 10.140.71.194:41488 130.57.4.12:443 VERBUNDEN 1000 27170 6925/firefox
tcp 0 1 10.140.71.194:52233 62.146.92.202:80 SYN_SENT 0 27605 -
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 27663 -
udp 0 0 0.0.0.0:725 0.0.0.0:* 0 13632 -
udp 0 0 0.0.0.0:5353 0.0.0.0:* 105 13951 -
udp 0 0 0.0.0.0:111 0.0.0.0:* 0 13627 -
udp 0 0 0.0.0.0:631 0.0.0.0:* 0 14214 -
udp 0 0 0.0.0.0:59270 0.0.0.0:* 105 13952 -

Durch Trennen und Verbinden wird Geschwindigkeitserhöhung manchmal erreicht.
Hier geht nach Trennen und Verbinden nichts mehr ( Überlastung der Verbindung beim Provider ??? )

netstat -apneeA inet
(Es konnten nicht alle Prozesse identifiziert werden; Informationen über
nicht-eigene Processe werden nicht angezeigt; Root kann sie anzeigen.)
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 13633 -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 14211 -
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 0 15307 -
tcp 0 0 10.140.71.194:40472 195.135.221.143:443 VERBUNDEN 1000 27257 6925/firefox
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 30044 -
udp 0 0 0.0.0.0:725 0.0.0.0:* 0 13632 -
udp 0 0 0.0.0.0:5353 0.0.0.0:* 105 13951 -
udp 0 0 0.0.0.0:111 0.0.0.0:* 0 13627 -
udp 0 0 0.0.0.0:631 0.0.0.0:* 0 14214 -
udp 0 0 0.0.0.0:59270 0.0.0.0:* 105 13952 -
sig@linux-9ypc:~>

Sicher kann ein Experte hier mehr erkennen.
Woher kommt das Wait ? - Ursache: schlechte Verbindung, Verbindungsüberlastung zu Spitzenzeiten ?

War es richtig, das nicht gebrauchte WLAN zu deaktivieren?

Vielen Dank für die Aufmerksamkeit und die Hilfe.

Mit freundlichen Grüßen

Basti1

Hallo zusammen,

WAIT bzw. FIN_WAIT sind normal. WAIT heißt, dass auf eine Antwort gewartet wird, und FIN_WAIT, dass auf die Rückantwort für den Verbindungsabbau gewartet wird. Alles völlig normale Vorgänge einer TCP-Verbindung.

Das WLAN abzuschalten, wenn es nicht gebraucht wird, ist sicherlich kein Fehler.

Liebe Grüße

Erik