ich hab darauf gewartet dass messenger sich abmeldet. und in dem moment in dem er die verbingung kappte musste ich nur schnell enter drücken aber, das ergebniss hat zwei bis drei sekunden auf sich warten lassen. ich glaube er hat nach dem wiederaufbau gelesen. muss ich noch was vor die achter schreiben? hat irgendwie nicht gefunzt ???

also ich habe den router vorhin neu gestartet und der status der lan-verbindung zeigt mir an dass, die verbindung seit dem ununterbrochen da wahr. aber msn reconnected trotzdem noch und emule verliert weiterhin denn server an den er gerade drann ist und der seitenaufbau ist immernoch so chaotisch, das ich manche seiten nicht mal aufrufen kann

ich hatte auch schon derartige Effekte
schau mal im Protokoll nach ob er die Synchronisation verliert.
Dies passiert auch wenn im Kabel neben dir ein anderer relativ schneller DSL liegt - eventuell eine Störung melden - du hast ja das Protokoll als Beweis

 

schau mal im Protokoll nach ob er die Synchronisation verliert.

wie mach ich sowas?

Sieh Dir in Ruhe alle Menüs und Untermenüs in der Routerkonfiguration an.
Auch der RP614 wird ein Protokoll über seine Arbeit und Funktion erstellen.

Zum Beispiel aus einem bei Telekom gebräuchlichen Router -
da ist das Protokoll unter "Status-Details / System-Meldungen" zu finden.

Das Protokoll auf jeden Fall nicht löschen - nur markieren und kopieren in eine Textdatei.
(Vielleicht wird die Kopierfunktion in der Ebene auch angeboten.)
Danach alle Einträge einzeln ansehen und bewerten.
 

wie kann es gegen 13.26 verbinden wenn der pc die ganze nacht über gelaufen ist?
also ich sehe da nur bahnhof, blick garnicht mehr durch ???

System initializing...
WAN Connected
Wednesday,03 Feb 2010 13:26:44 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 13:33:39 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 13:33:39 [HOST Attack: TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 15:07:25 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:11:23 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:16:48 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:16:48 [HOST Attack: TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:16:52 [HOST Attack: TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:16:52 [TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:16:53 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:52:17 [HOST Attack: TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:52:17 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 16:52:32 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 17:05:49 [HOST Attack: TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 17:10:06 [TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 17:10:07 [TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 17:10:07 [HOST Attack: TCP SYN Flood][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 17:11:20 [TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Wednesday,03 Feb 2010 17:16:46 [HOST Attack: TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 01:27:45 [TCP SYN Flood][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 01:27:45 [TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 02:35:21 [TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 02:52:58 [TCP SYN Flood][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 02:53:28 [TCP SYN Flood][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 03:15:34 [TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 03:15:34 [HOST Attack: TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 03:15:34 [HOST Attack: TCP Stealth FIN Port Scan][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 04:13:09 [HOST Attack: TCP SYN Flood][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 04:13:09 [TCP SYN Flood][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 04:13:12 [TCP SYN Flood][Deny access policy matched, dropping packet]
Thursday,04 Feb 2010 04:30:27 Authentication successful for admin from 192.168.1.3
 

 

TCP SYN Flood

hab das bei wiki gefunden--- Betroffene Ressourcen [Bearbeiten]

Zu den Ressourcen, die betroffen sein können, gehören vor allem die Tabelle, in der die TCP-Verbindungen gespeichert werden, sowie – durch sekundäre Effekte – der Hauptspeicher des Servers. Die sogenannte Backlog queue des TCP-Stacks, die im Falle von zu vielen gleichzeitig aktiven Verbindungen als Warteschlange einspringt, benötigt ebenfalls Speicher. Wenn dem angegriffenen Server der Speicher ausgeht, stürzt er in vielen Fällen ganz oder teilweise ab.

hier der link falls jemand alles lesen will
http://de.wikipedia.org/wiki/SYN-Flood

endlich wieder ein schritt richtung ziel

Beim Provider des DSL-Anschlusses hast Du schon Erkundigungen eingezogen, ob in dem Territorium wo Dein Heimnetz betrieben wird zusätzlicher Ausbau erfolgte.
Die Überlegung bezieht sich sich auf solche Sache http://www.deutschetelecom.com/dtag/cms/content/dt/de/540428
Dabei kommt auch DPBO-Technik (DownStreamPowerBackOff) zum Einsatz.
Hat Dein Modem vielleicht Probleme mit solcher Technik, wenn sie in der Umgebung überhaupt eingebaut wurde?
 

suche in deinem Router nach einen Punkt in etwa
Ping vom WAN blocken! oder so ähnlich

vllt. mal ein Firmwareupdate durchführen!