funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
 ·Verizon Online DSL
 ·Skype
 ·Comcast
edit:
August 20th, @11:09AM
|  reply to funchords
How to test how many connections are being reset by RST pack
Here is a quick-and-dirty way to determine whether, and how much, you are being affected by the P2P management that I described at the top of this thread.
1. Start your P2P application, wait about 15 minutes for full connectivity to be established.
2. In a Console window (Start, Run, CMD.EXE), type
netstat -s | find "Reset Connections"
and write down the number that you get in response.
3. Exactly one hour later, repeat Step 2. Subtract the first number from this latest number. The result is how many connections were terminated by a "RST" in the past hour.
If you have a VPN, or an access to a non-Comcast line, repeat the above process (as much as you can, try to match the conditions -- same applications, same uploads and downloads).
Now compare the two numbers. If you are being affected, the "Comcast" number will be an order of magnitude higher than the "non-Comcast" number.
The above result should be enough to show the effect, if it is there, as the difference is huge and undeniable. However, you can be more accurate by using the above process, but using this command and this math at the end of each test, instead:
netstat -s
Look for this output:
TCP Statistics for IPv4
Active Opens = 253461
Passive Opens = 131313
Failed Connection Attempts = 188271
Reset Connections = 12271
These numbers always accumulate (they don't go up and down). Record this output, and at the end of the test, subtract the numbers from the beginning of the test to get the number that applies to the duration of your test.
Now add "Active Opens" and "Passive Opens" and subtract "Failed Connection Attempts." The result will be the number of Successfully Established Connections.
Take the "Reset Connections" and divide that by the number of "Successfully Established Connections," and the result is the ratio of connections that were torn down by Resets.
If you don't have a non-Comcast account to use for comparison, you can use this result to compare with other users of your P2P application (to a degree), since it divides by the number of successful connections instead of by time.
If you know how to use a batch file, here is a batch file that simplifies this testing -- call it CheckRST.BAT:
The above file was written and tested using Windows XP SP2. Use CMD.EXE (which is installed by default in Windows XP), not COMMAND.COM, to run this batch file. |
|
macguy
join:2007-08-18
Bloomfield, NJ | Anyway I could test this in the os X terminal? I tried, but entering netstat -s find "rest connections" didn't give me any data that said anything about active opens or passive opens or anything else that your post said to look for. |
|
funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
·Verizon Online DSL
·Skype
·Comcast
| said by macguy  :Anyway I could test this in the os X terminal? I tried, but entering netstat -s find "rest connections" didn't give me any data that said anything about active opens or passive opens or anything else that your post said to look for. Try netstat -s | grep "connection resets received"
If that doesn't work, it's because I got the string "connection resets received" wrong. Just do a netstat -s and look for something like:
Tcp:
79600 active connections openings
35524 passive connection openings
12573 failed connection attempts
5257 connection resets received
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report. |
|
NormanS
Premium,MVM
join:2001-02-14
San Jose, CA
·Pacific Bell - SBC
| Two torrents running. AT&T is not (AFAIK) running Sandvine (or Ellacoya):
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
·Verizon Online DSL
·Skype
·Comcast
| Those are some really, really, really strange numbers. 
You've had 1,737,538 successful connections.
3% Incoming, 97% Outgoing
95% were terminated by the RST flag (instead of FIN).
What the heck are you doing that makes 1.7 million outgoing connection attempts? How many years since the last reboot? 
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report. |
|
NormanS
Premium,MVM
join:2001-02-14
San Jose, CA
·Pacific Bell - SBC
edit:
August 25th, @02:08AM
| Anime fansub "H2" has been running for the last 38 hrs., 10 mins. Only 67.3% complete. Connected to 22 peers, 4 seeds. Running at 23KBps down.
Anime fansub "Zombie Loan" is complete, but share ratio is at .886. Took 1 hr., 13 mins. to download 171.49 MBytes. Currently connected to 33 peers.
In that same 38 hour period I have downloaded probably 6, or 7 other shows at ~171MBytes each. Two, or three completed in under 20 minutes.
The box was rebooted some time before I started downloading "H2", which is a 41 episode series; 9,488.64 MBytes for the whole shebang.
The combined upload is roughly 43KBps; which, I think, is about right for a 512kbps DSL upload (512*.85/8?) The SpeedStream 4100 reportedly has a built-in QoS priority for outbound ACK packets, so saturating the upload has minimal impact on download.
I have no idea why so many resets.
Not counting stuff happening on the LAN, of course. A mail server running on another computer, with twice daily access from this one. Web surfing. Email testing to off-site servers for helping poster in Usenet groups. Downloading Usenet headers...
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
johnmwilson
join:2007-08-30
Washington, DC
| reply to funchords
FunChords,
Your script was passed on to me by a friend and I learned a lot from it.
Anyway, here is Version 3, it tracks current reset percent, average reset percent and displays a histogram. The histogram shows where the majority of your reset activity is occurring.
Perhaps it is overkill, but I had fun testing it.
Thanks,
John M. Wilson
------CUT HERE ------
@ECHO OFF
REM
REM Title: NetStat Check Reset V3
REM
REM Description: Extract summary data from Netstat and display percentage of current, average and a histogram of connection resets.
REM
REM CURRENT percentages are the difference between the previous (20 seconds ago) and current Netstat results.
REM AVERAGE percentages are the running total of the current percentages.
REM HISTOGRAM is a ranking of the number of current percentages that occurred. This shows the distribution of resets from 1-99 percent.
REM
REM So while the Average percentage may be 35%, the Histogram may show the majority of Current percentages are in the 20% range
REM with some spikes in the 40% or 50% range. This would indicate normal reset activity to be in the 20% range and the focus would be
REM in resolving the spikes.
REM
SETLOCAL
TITLE NetStat Check Reset V3
CLS
ECHO NetStat Check Reset Batch V3 [Ctrl-c quit]
REM Initialize variables
:init
REM Histogram values
SET HST00=0
SET HST10=0
SET HST20=0
SET HST30=0
SET HST40=0
SET HST50=0
SET HST60=0
SET HST70=0
SET HST80=0
SET HST90=0
REM Histogram print strings
SET PST00=___
SET PST10=___
SET PST20=___
SET PST30=___
SET PST40=___
SET PST50=___
SET PST60=___
SET PST70=___
SET PST80=___
SET PST90=___
REM Loop counter for header print
SET /A TESTCYCLE=-1
REM run Netstat summary page, find line and save 2nd field value
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Active Opens"`) DO SET /A PRVACTI=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Passive Opens"`) DO SET /A PRVPASS=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Failed Connection Attempts"`) DO SET /A PRVFAIL=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Reset Connections"`) DO SET /A PRVRESE=%%i
REM Begin loop section
:begin
REM Increment test cycles
SET /A TESTCYCLE=%TESTCYCLE%+1
IF %TESTCYCLE% GEQ 10 SET /A TESTCYCLE=0
REM Ping to nul used as timer
REM Each ping approximately 1 second delay
REM Value of 20 used as minimum wait time for connection activity.
REM
ping -n 20 localhost >nul
REM run Netstat summary page, find line and save 2nd field value
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Active Opens"`) DO SET /A NXTACTI=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Passive Opens"`) DO SET /A NXTPASS=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Failed Connection Attempts"`) DO SET /A NXTFAIL=%%i
FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Reset Connections"`) DO SET /A NXTRESE=%%i
REM Subtract Previous from Next to get Current
SET /A CURACTI=%NXTACTI%-%PRVACTI%
SET /A CURPASS=%NXTPASS%-%PRVPASS%
SET /A CURFAIL=%NXTFAIL%-%PRVFAIL%
SET /A CURRESE=%NXTRESE%-%PRVRESE%
REM Accumulate the totals for averaging
SET /A CUMACTI=%CUMACTI%+%CURACTI%
SET /A CUMPASS=%CUMPASS%+%CURPASS%
SET /A CUMFAIL=%CUMFAIL%+%CURFAIL%
SET /A CUMRESE=%CUMRESE%+%CURRESE%
REM Add Active and Passive connections then subtract Failed connections
REM Calculate Percentage of Resets
SET /A CURESTA=(%CURACTI%+%CURPASS%)-%CURFAIL%
REM Bypass divide by zero errors
SET /A CURPRCT=0
IF %CURESTA% NEQ 0 SET /A CURPRCT=(%CURRESE%*100)/%CURESTA%
REM Accumulate current results for session average
SET /A CUMESTA=(%CUMACTI%+%CUMPASS%)-%CUMFAIL%
REM Bypass divide by zero errors
SET /A CUMPRCT=0
IF %CUMESTA% NEQ 0 SET /A CUMPRCT=(%CUMRESE%*100)/%CUMESTA%
REM Load histogram with current percentages in the range of 1-99%
IF %CURPRCT% LEQ 0 GOTO display
:break00
IF %CURPRCT% GEQ 10 GOTO break10
SET /A HST00=%HST00%+1
SET PST00=%HST00%
IF %HST00% LSS 10 SET PST00=_%PST00%
IF %HST00% LSS 100 SET PST00=_%PST00%
GOTO display
:break10
IF %CURPRCT% GEQ 20 GOTO break20
SET /A HST10=%HST10%+1
SET PST10=%HST10%
IF %HST10% LSS 10 SET PST10=_%PST10%
IF %HST10% LSS 100 SET PST10=_%PST10%
GOTO display
:break20
IF %CURPRCT% GEQ 30 GOTO break30
SET /A HST20=%HST20%+1
SET PST20=%HST20%
IF %HST20% LSS 10 SET PST20=_%PST20%
IF %HST20% LSS 100 SET PST20=_%PST20%
GOTO display
:break30
IF %CURPRCT% GEQ 40 GOTO break40
SET /A HST30=%HST30%+1
SET PST30=%HST30%
IF %HST30% LSS 10 SET PST30=_%PST30%
IF %HST30% LSS 100 SET PST30=_%PST30%
GOTO display
:break40
IF %CURPRCT% GEQ 50 GOTO break50
SET /A HST40=%HST40%+1
SET PST40=%HST40%
IF %HST40% LSS 10 SET PST40=_%PST40%
IF %HST40% LSS 100 SET PST40=_%PST40%
GOTO display
:break50
IF %CURPRCT% GEQ 60 GOTO break60
SET /A HST50=%HST50%+1
SET PST50=%HST50%
IF %HST50% LSS 10 SET PST50=_%PST50%
IF %HST50% LSS 100 SET PST50=_%PST50%
GOTO display
:break60
IF %CURPRCT% GEQ 70 GOTO break70
SET /A HST60=%HST60%+1
SET PST60=%HST60%
IF %HST60% LSS 10 SET PST60=_%PST60%
IF %HST60% LSS 100 SET PST60=_%PST60%
GOTO display
:break70
IF %CURPRCT% GEQ 80 GOTO break80
SET /A HST70=%HST70%+1
SET PST70=%HST70%
IF %HST70% LSS 10 SET PST70=_%PST70%
IF %HST70% LSS 100 SET PST70=_%PST70%
GOTO display
:break80
IF %CURPRCT% GEQ 90 GOTO break90
SET /A HST80=%HST80%+1
SET PST80=%HST80%
IF %HST80% LSS 10 SET PST80=_%PST80%
IF %HST80% LSS 100 SET PST80=_%PST80%
GOTO display
:break90
IF %CURPRCT% GEQ 100 GOTO break100
SET /A HST90=%HST90%+1
SET PST90=%HST90%
IF %HST90% LSS 10 SET PST90=_%PST90%
IF %HST90% LSS 100 SET PST90=_%PST90%
GOTO display
:break100
REM Final formatting and print
:display
REM Assign values to print strings
SET PCUMESTA=%CUMESTA%
SET PCUMRESE=%CUMRESE%
SET PCUMPRCT=%CUMPRCT%
SET PCURESTA=%CURESTA%
SET PCURRESE=%CURRESE%
SET PCURPRCT=%CURPRCT%
REM Skip leading zero for negative numbers
IF %CUMESTA% LSS 0 GOTO dbreak1
IF %CUMESTA% LSS 10 SET PCUMESTA=0%CUMESTA%
:dbreak1
IF %CUMRESE% LSS 0 GOTO dbreak2
IF %CUMRESE% LSS 10 SET PCUMRESE=0%CUMRESE%
:dbreak2
IF %CURESTA% LSS 0 GOTO dbreak3
IF %CURESTA% LSS 10 SET PCURESTA=0%CURESTA%
:dbreak3
IF %CURRESE% LSS 0 GOTO dbreak4
IF %CURRESE% LSS 10 SET PCURRESE=0%CURRESE%
:dbreak4
REM Print line break and header every 10 cycles
IF %TESTCYCLE% EQU 0 ECHO .
IF %TESTCYCLE% EQU 0 ECHO %TIME% - CURRENT AVERAGE I 00%% I 10%% I 20%% I 30%% I 40%% I 50%% I 60%% I 70%% I 80%% I 90%% I
REM Print Current percentage, Average Percentage and Histogram
ECHO %TIME% - %PCURPRCT%%% (%PCURRESE%/%PCURESTA%) %PCUMPRCT%%% (%PCUMRESE%/%PCUMESTA%) I %PST00% I %PST10% I %PST20% I %PST30% I %PST40% I %PST50% I %PST60% I %PST70% I %PST80% I %PST90% I
REM Save values into Previous
SET /A PRVACTI=%NXTACTI%
SET /A PRVPASS=%NXTPASS%
SET /A PRVFAIL=%NXTFAIL%
SET /A PRVRESE=%NXTRESE%
REM Loop again
GOTO begin
------CUT HERE ------ |
|
Movieman420
join:2007-08-28
united state
·Comcast
| Since script JW. I went from being unable to seed at all a week ago...set up a vpn but couldn't get Az or uT to use it..lol. As of 2 days ago I'm seeding like normal (see above post).
Just used the script above...after 5 cycles (sets) my rst rate is almost exactly 20%.
Q to JW...does this script count all rst's or just the forged sandvine rsts??
Dunno wat I did to regain seeding ability (except a rather heated one sided convo with a CC tech bout traffic shaping..rofl) but I'm glad to be 'back'. |
|
funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
·Verizon Online DSL
·Skype
·Comcast
| said by Movieman420 :Q to JW...does this script count all rst's or just the forged sandvine rsts?? The script counts them all, but on a "clean" (non-Sandvine) line, there should be very, very few (0% to 1%?). The RST is designed to close improperly half-open TCP connections. They generally only occur when one side or the other has closed the connection without going through the "FIN" final handshake. (This usually only happens when one side or the other spontaneously reboots).
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report. |
|
johnmwilson
join:2007-08-30
Washington, DC
| reply to funchords
FunChords,
My next step will be to install WireShark and view the traffic to see what I can see. I am used to using Ethereal on my Linux box, but I can run WireShark on Windows. Other than the standard filtering options, any tips on sourcing the resets with this tool?
Sincerely,
John M. Wilson |
|
funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
·Verizon Online DSL
·Skype
·Comcast
| said by johnmwilson :Other than the standard filtering options, any tips on sourcing the resets with this tool? RST's with a sequence number seq=0 are probably not injected. Everything else is a "maybe" so you have to look at what was happening in the conversation and decide. RST's right on the tail of a bunch of data that was not problematic are very suspicious.
My last interesting discovery is that the injected RSTs had a TTL (in the IP header) of 123. The norm TTL from my computer was 128, and my peer was often in the 110s or 100s TTL. If my peer was coming in TTL=109 but the RSTs were TTL=123, that is surely injected. HOWEVER, someone on the east coast sent me his capture file, and his RSTs that were seemingly injected all had the right TTL for his peer.  I don't have enough data -- so look out for that for me.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report. |
|
johnmwilson
join:2007-08-30
Washington, DC
edit:
August 31st, @09:51PM
| reply to funchords
FunChords,
Pardon my obvious question. I got WireShark installed and running. However, I could not figure out how to build a filter string for the RSET commands. I want to see all resets, so the filter should be simple.
By the way, cool website, I like the view from your house.
P.S. I found your other post detailing how to view the resets, so I am good.
»Comcast is using Sandvine to manage P2P Connections
Sincerely,
John M. Wilson |
|
johnmwilson
join:2007-08-30
Washington, DC
edit:
September 1st, @09:10AM
| reply to funchords
FunChords,
Using the following filter string
"(ip.src != your.ip.addr.ess) and (tcp.flags.reset == 1)"
I was able to get a steady display of incoming resets. Of course most would be normal. However looking at the list, which ones should I consider to be suspect?
Sincerely,
John M. Wilson |
|
funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR | The ones where Seq>1 and Ack>1 in the display (generally this means that data has already passed both ways, even if it was just a handshake). |
|
johnmwilson
join:2007-08-30
Washington, DC
edit:
September 1st, @09:08AM
| reply to funchords
FunChords,
Great, that will help. I have updated my filter string as shown below;
"( ip.src != your.ip.addr.ess ) and ( tcp.flags.reset == 1) and (tcp.seq > 1) and ( tcp.ack > 1)and (tcp.dstport == yourport)"
With name resolution turned on, many of the connection sources are identified. So it is easy for me to recognize the packets from my network provider.
So my question is, are the forged resets spoofed as well? Or will they have the same name as my network provider?
Thanks for taking the time to walk me thru this. Hopefully others will find it useful as well.
Sincerely,
John M. Wilson |
|
funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
·Verizon Online DSL
·Skype
·Comcast
| It looks like you're ready -- right click on one of those red lines and choose "Follow TCP Stream"
The RSTs are forged to appear to come from your Peer. They sometimes come at the end of stream of data, but more often they come right after a peer makes a request or after bitfields are exchanged.
An example is here: »torrentfreak.com/images/comcast-rst1.txt
Many of the RSTs you'll see will be clear cases of injected (forged) RST. Get to know those patterns.
When you look at the TCP Stream, one possibility is that the connection was shaky -- you'll see lots of retransmits and the RSTs that come won't fit the pattern of ones that are positively injected. These RSTs may or may not be legitimate, and when I'm not sure, I discount it.
Hope that helps!
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report. |
|
Movieman420
join:2007-08-28
united state
·Comcast
edit:
September 4th, @10:55PM
| said by funchords :It looks like you're ready -- right click on one of those red lines and choose "Follow TCP Stream" eegads..waaay to deep for me..lol. |
|
funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
·Verizon Online DSL
·Skype
·Comcast
edit:
September 1st, @10:51PM
| 158 kB/s upload is insanely fast! Is this one of those 16Mb/2Mb tiers of service?
Remember, all things in moderation. Even though you have 16M/2M, your neighborhood is still sharing the same pipe. Be a kind sharer.  |
|
johnmwilson
join:2007-08-30
Washington, DC
edit:
September 2nd, @11:27AM
| reply to funchords
FunChords,
Thank you for your kind assistance. I have summarized your explanations on a new post with credit to you.
»[Speed] There are good resets and there are bad resets...
Sincerely,
John M. Wilson |
|
funchords
Robb
Premium,MVM
join:2001-03-11
Hillsboro, OR
·Verizon Online DSL
·Skype
·Comcast
| said by johnmwilson :Regarding Resets, there are good resets and there are bad resets. Good and bad are subjective assessments. How about Expected and Unexpected, or perhaps Genuine and Forged
said by johnmwilson :Along with the received SEQuence is included a command to be executed, such as SYNchronize at the beginning and reset (RST) at the end. Normal network transactions finish with a reset (RST) command. Each received SEQuence may include a command to be executed, such as SYNchronize at the beginning and Final (FIN) at the end. Normal network transactions finish with a Final (FIN) command. »tools.ietf.org/html/rfc793#section-3.5
One command in a sequence may be Abort (RST). Abort is sent by an endpoint when a received SEQuence is not expected or allowed, such as attempting to connect to a closed port, or attempting to send data to an endpoint without first going through the SYN process.
It is not unusual to see an RST being sent at the very end of a properly-ended connection (using the FIN commands). These packets are a result of a stateful firewall at one endpoint or another which has closed the connection but then receives the final acknowledgment ("FIN,ACK") packet. While these RST responses are not necessary, they are harmless.
said by johnmwilson :and then a second reset (RST) with an out of sequence number is also sent. Yeah, I don't know what this second one is about. It is superfluous. There is no reason to send it.
said by johnmwilson :Understand that you cannot easily verify the source of these resets: They can come from anyone who can view and transmit on the network. If they are forged, they can be made to look like anyone, even you. Some sources can be low-end traffic shapers, network blocking programs, hacker programs, or the actual sender may have a problem with their client. It's key to understand that an idle attacker cannot easily accomplish this. This needs to be done by someone/something that it "in-line," that can read both sides of the conversation, and inject or forge a packet with exactly the correct sequence numbers.
Forging TCP packets is exceedingly difficult unless you are "the man in the middle."
said by johnmwilson :Some solutions, in order of difficulty; These are all generally fine suggestions.
One thing I don't see here is anything about tolerating it or "complaining" about it.
The ISP is not necessarily an evil entity. You got 3 resets in 10 minutes, and you're okay with that. I got a lot more and, still, I'm okay with that (for BitTorrent, anyway.)
However, Gnutella is broken for me. One option that I should explore is calling (or writing, with evidence provided) into Support and asking for the problem to be investigated and fixed.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report. |
|
