von dfx » Fr 18 Feb, 2005 19:15
also im libpcap format wär das um einiges sinnvoller, aber ich versuchs mal so...
gut... der ursprung des disconnects ist frame 217. da schickst du anscheinend irgendeinen befehl an den irc-server. dieses paket wird vom irc-server aber nicht bestätigt (so wie es zb bei frames 198 und 199 passiert), wodurch der tcp-stack von einem verlorengegangenen paket ausgeht und somit das paket erneut schickt (frames 218, 219 und noch weitere, mit ansteigenden intervallen). keins davon kommt scheinbar an, bis das paket schliesslich in frame 244 wieder mal erneut verschickt wird. zu diesem zeitpunkt gibt es aber diese connection aus sicht des irc-servers nicht mehr, daher antwortet dieser jetzt mit einem RST (frame 245), was ein connection reset ist und die erwähnte fehlermeldung auslöst.
die frage ist jetzt, warum dieses paket nicht bestätigt werden konnte. entweder es ist tatsächlich nicht angekommen, oder das bestätigungspaket ist auf dem retourweg irgendwo verlorengegangen (wobei die bestätigung auch huckepack auf einem paket mit daten verschickt werden kann).
da hier ein linksys-router im spiel ist (hast du bisher übrigens nicht erwähnt), könnte der grund leicht bei dem liegen... möglw hat er die ge-nat-ete connection einfach "vergessen", oder er hat das retourpaket verworfen und nicht zugestellt. interessant wäre, welchen befehl zu in frame 217 abgesetzt hast... könnte das einer gewesen sein, der größeren output vom irc-server erzeugt (LIST oder WHO zb)? dann würde ich drauf tippen, daß der irc-server daraufhin ein großes paket mit daten generiert hat, die bestätigung da drauf gepackt hat, dieses paket mit dont-fragment versehen war, von der mtu her dann zu groß war, path mtu discovery auch versagt hat und so das paket unzustellbar im nirvana gelandet ist. das wäre zumindest mal eine vermutung von mir...
xDSL unlimited 2.320 kbit/s