hmmja, vorausgeschickt: man soll sich seine eigenen daten genau anschauen, bevor man schlußfolgerungen zieht. dann sieht man auch (was man hier wegen cut&paste nicht mehr sieht), daß das RST mit einer RTT von 2.0ms kommt, oder mit anderen worten, lokal und nicht am anderen ende der DSL-leitung generiert wird.
jutta hat geschrieben:@cm: dass du die ziel-ip verschleierst, kann ich verstehen, aber die ip des boesen telekom-routers, der deine packerl nicht durchlaesst zu verschleiern, halte ich fuer wenig hilfreich. wie soll man da draufkommen, welches geraet schuld ist und wieso es sich fehlverhaelt?
das RST-paket mu8 ja die absenderadresse des zielhosts haben (die wird vom resettenden device "gefälscht"), um seinen zweck zu erfüllen... und praktischerweise hat der verdächtige hop #3 bei traceroute und funktionierenden "hping -T"-runs auch nur "* * *" von sich gegeben.
jutta hat geschrieben:ich wuerde zunaechst einmal in erfahrung bringen, welche hardware mit welchen einstellungen an beiden enden werkelt.
das war wohl mein fehler, ich bin's end-to-end angegangen. was am drüberen ende (=server) läuft, war ab dem moment wurscht, an dem ich unter linux eine erfolgreiche rdesktop-connection bekommen hab und gesehen habe, daß das RST von hop #3 kommt, während der server über 10 hops weg war und das auch mit den TTLs der entsprechenden pakete konsistent ist -- der server (oder seine firewall) können das nie im leben verursachen.
die lokale seite hätt ich halt nicht komplett ignorieren dürfen, und daß ich mich bislang erfolgreich vom telekom-ADSL ferngehalten hab und die 10.0.0.138 nur vage zuordnen konnte, hat sicher auch seinen teil dazu beigetragen; ich bin davon ausgegangen, daß hop #3 jedenfalls der telekom-PPTP-konzentrator (oder wie auch immer das kastl heißt) ist. hätt halt auf die RTTs schauen müssen, dann wär das klar gewesen.
und dann hab ich mich auch noch davon ablenken lassen, wieso zwei XPs auf demselben SP- und patchstand unterschiedliche TCP-options in ihren SYN-paketen schicken. das kommt davon, wenn man netten leuten zuliebe von seiner "windows? was ist bitte windows?"-lebensphilosophie abgeht.
mobilkarte wurde übrigens probiert, das war ja der anfang der ganzen geschichte, "am DSL gehts ned, aber mit der datenkarte schon".
wicked_one hat geschrieben:Mit verlaub, worauf ich hinaus will ist, ohne Kenntnis von der Gegenseite zu haben, würd ich mich nie so weit rauslehnen und eine solche Diagnose stellen...
Wie gesagt, wenn dur wirklcih ein Gerät im Telekom Netz in verdacht hast, welches deine RDP Verbindung abwürgt, mach eine wirkliche RDP Session vom betroffenen System aus, lass wireshark/tcpdump mitrennen, bzw siehst du auch in Netstat gleich mal, ob wirklcih ein RST kommt, oder nur das Modem welches die Verbindung ausgehend transportiert mit dem hPing nichts anzufangen weiss
die gegenseite spielt, wie oben dargestellt, keine rolle. wireshark ist auch hinreichend zum einsatz gekommen, ich wollt hier aber nur die wesentlichen fakten bringen und euch nicht mit einer abendfüllenden debug-session langweilen: auf der betroffenen windows-kiste, auf meinem linux-notebook, ich hab die windows-kiste über ethernet ans linux gehängt und darüber gebridget, um am linux schnüffeln zu können und auszuschließen, daß eine windows-firewall verrückt spielt; die SYN-pakete der funktionierenden und nicht-funktionierenden connections verglichen, versucht, dem einen windows beizubringen, sich so zu verhalten wie das andere, und schlußendlich festgestellt, daß der trigger für das seltsame verhalten der sourceport im SYN-paket ist.
verhaut hab ich mich halt damit,
wo die böse kiste steht, und das zipft mich an, ich könnt das inzwischen gelernt haben, nicht allzu vorschnell schlußzufolgern.
cm.
, ein halbwegs kompetenter so 
