How to test how many connections are being reset by RST pack

How to test how many connections are being reset by RST pack
Links: home · search · speed test · login · more ·

Links: Reply New Topic
Forums » Comcast » Comcast HSI » Comcast is using Sandvine to manage P2P Connections
page: 1 · 2
funchords @ 18th Aug 05:23PM:
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:

@echo offSETLOCAL FOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Active Opens"`) DO set /A CESTABL1=%%iFOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Passive Opens"`) DO set /A CESTABL1=%CESTABL1%+%%iFOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Failed Connection Attempts"`) DO set /A CESTABL1=%CESTABL1%-%%iFOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Reset Connections"`) DO set /A CRESETS1=%%iSET /A TESTCYCLE=0SET /A TESTMINS=0 clsecho results will begin to be reported shortly,echo please wait or use Ctrl-c to quit... :repeatcycleping -n 9 localhost >nulFOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Active Opens"`) DO set /A CESTABL2=%%iFOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Passive Opens"`) DO set /A CESTABL2=%CESTABL2%+%%iFOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Failed Connection Attempts"`) DO set /A CESTABL2=%CESTABL2%-%%iFOR /F "usebackq tokens=2 delims==" %%i IN (`netstat -s ^| find "Reset Connections"`) DO set /A CRESETS2=%%iSET /A TESTCYCLE=%TESTCYCLE%+1SET /A TESTMINS=%TESTCYCLE% / 6SET /A TESTSECS=%TESTCYCLE%%%6*10IF %TESTSECS% EQU 0 SET TESTSECS=00SET /A CESTABL=%CESTABL2%-%CESTABL1%SET /A CRESETS=%CRESETS2%-%CRESETS1%SET /A PCTRST=(%CRESETS% * 100)/%CESTABL%ECHO %TESTMINS%:%TESTSECS% - %CRESETS% out of %CESTABL% connections reset (%PCTRST%%%) [Ctrl-c quit]goto repeatcycle

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.

reply

macguy @ 24th Aug 10:30PM:
Re: How to test how many connections are being reset by RST pack

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.
reply

funchords @ 24th Aug 11:35PM:
Re: How to test how many connections are being reset by RST pack

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.
reply
NormanS @ 24th Aug 11:44PM:
Re: How to test how many connections are being reset by RST pack

Two torrents running. AT&T is not (AFAIK) running Sandvine (or Ellacoya):
TCP Statistics for IPv4 Active Opens = 1683318 Passive Opens = 58529 Failed Connection Attempts = 4309 Reset Connections = 1651849 Current Connections = 42 Segments Received = 49963488 Segments Sent = 38610912 Segments Retransmitted = 26816776
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
reply
funchords @ 25th Aug 12:00AM:
Re: How to test how many connections are being reset by RST pack

Those are some really, really, really strange numbers. :o

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? :p
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.
reply
NormanS @ 25th Aug 02:06AM:
Re: How to test how many connections are being reset by RST pack

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
reply
johnmwilson @ 30th Aug 09:13PM:
Re: How to test how many connections are being reset by RST pack

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 ------
reply
Movieman420 @ 31st Aug 08:54AM:
Re: How to test how many connections are being reset by RST pack

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'.
reply
funchords @ 31st Aug 06:21PM:
Re: How to test how many connections are being reset by RST pack

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.
reply
johnmwilson @ 31st Aug 08:10PM:
Re: How to test how many connections are being reset by RST pack

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
reply
funchords @ 31st Aug 08:36PM:
Re: How to test how many connections are being reset by RST pack

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.
reply
johnmwilson @ 31st Aug 09:33PM:
Re: How to test how many connections are being reset by RST pack

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
reply
johnmwilson @ 31st Aug 10:26PM:
Re: How to test how many connections are being reset by RST pack

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
reply
funchords @ 31st Aug 11:28PM:
Re: How to test how many connections are being reset by RST pack

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).
reply
johnmwilson @ 1st Sep 08:40AM:
Re: How to test how many connections are being reset by RST pack

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
reply
funchords @ 1st Sep 12:09PM:
Re: How to test how many connections are being reset by RST pack

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.
reply
Movieman420 @ 1st Sep 10:11PM:
Re: How to test how many connections are being reset by RST pack

said by funchords :

It looks like you're ready -- right click on one of those red lines and choose "Follow TCP Stream"

:o eegads..waaay to deep for me..lol.
reply
funchords @ 1st Sep 10:50PM:
Re: How to test how many connections are being reset by RST pack

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. :)
reply
johnmwilson @ 2nd Sep 10:54AM:
Re: How to test how many connections are being reset by RST pack

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
reply
funchords @ 2nd Sep 11:31AM:
Re: How to test how many connections are being reset by RST pack

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.
reply
anon @ 2nd Sep 11:41AM:
Re: How to test how many connections are being reset by RST pack

The problem though is whatever Comcast is doing to monitor P2P is resulting in serious latency crud for some of the rest of us who don't use or even have BitTorrent. 3 days straight I have had my cable modem here in the MD/VA/DC area literally bombarded with 6881 incoming port traffic (the log is long and glorious) - a reverse lookup on those IPs reveal cable modems from both comcast.net as well as other cable/dsl providers and our routes are toasted as a result. Comcast Tech Support knows about it and calls it "network maintenance" If they're going to use to such software and monitoring tools, perhaps they should at least configure it correctly.
reply
funchords @ 2nd Sep 01:21PM:
Re: How to test how many connections are being reset by RST pack

said by dontask2much :

The problem though is whatever Comcast is doing to monitor P2P is resulting in serious latency crud for some of the rest of us who don't use or even have BitTorrent.

I read your whole message. I'm 100% sure this is not related to Sandvine or BitTorrent monitoring.

What you are seeing sounds like "P2P Afterglow." »Re: Dangers of P2P filesharing networks?

Your firewall should be ignoring these packets. If they are causing latency, it probably is due to the number of CPU cycles that the router has to spend to evaluate or log them. It doesn't take any CPU cycles to drop them.

But if they really are causing problems, you can change your IP: »Comcast High Speed Internet »How do I get a different IP address?
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.
reply
NormanS @ 2nd Sep 02:48PM:
Re: How to test how many connections are being reset by RST pack

said by dontask2much :

3 days straight I have had my cable modem here in the MD/VA/DC area literally bombarded with 6881 incoming port traffic...

Such connection attempts have never been a problem for me. And I often see them after I close a torrent. It sound more like your equipment can't handle the probes than that the Comcast network is suffering.

Also, I don't see how Sandvine can be a part of the problem. You shouldn't see so many BT connection attempts if you never use it. The peers only attempt to connect to a client which was part of torrent.

If I were a guessing person, I'd guess you have a wireless LAN, and an uninvited hitch hiker using your WLAN for their torrent sessions.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum
reply
Movieman420 @ 2nd Sep 05:42PM:
Re: How to test how many connections are being reset by RST pack

Heh..this will blow your mind...Blast! isn't available in my area (WV..go figure...lol)! I signed up for the premium tier..the 8Mb line..when I asked what the upload bw was, I couldn't get an answer from the comcast person I talked to...I just figured it couldn't be any worse than my previous RoadRunner 9Mb line w/ 512kbps up, ~60k max u/l. My local computer guru who is also on comcast (formerly adephia like my area) told me of his speeds (he's in a semi-rural area)..thought it was a fluke. But I was wrong :)...I can maintain ~1,500k down (1.5MB) and between 80 and 160k up...u/l fluctuates. My only guess is my node is way undersold (I'm in a semi-rural area as well)..or it has something to do with the comcast/time warner buyout of Adelphia cable and my 'limits' got lost in the shuffle..I dunno but I love it..lol. On the flash bw test I hit 20+ down and usually 1.5Mb up but thats powerboost involved.

My last few tests:

»/archive/comca···t=Search

Any way...a quick thought (for wat it's worth..lol)..Some clients do not show as a seed to other peers when in superseed mode...wonder if this mode could somehow be modified/used/employed to help 'fool' the sandvine box into thinking your not 'seeding'. I may be p!issin in the wind..just thought I'd mention it tho.
reply
funchords @ 2nd Sep 07:00PM:
Re: How to test how many connections are being reset by RST pack

said by Movieman420 :

My last few tests:

»/archive/comca···t=Search

I hate you and everything that you stand for! ;)
said by Movieman420 :

Any way...a quick thought (for wat it's worth..lol)..Some clients do not show as a seed to other peers when in superseed mode...wonder if this mode could somehow be modified/used/employed to help 'fool' the sandvine box into thinking your not 'seeding'.

Lazy Bitfield does about the same thing, but I think your suggestion is worth a test.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.
reply
funchords @ 3rd Sep 07:09PM:
Optimize BitTorrent To Outwit Traffic Shaping ISPs

said by funchords :

said by Movieman420 :Some clients do not show as a seed to other peers when in superseed mode...wonder if this mode could somehow be modified/used/employed to help 'fool' the sandvine box into thinking your not 'seeding'.

Lazy Bitfield does about the same thing, but I think your suggestion is worth a test.

I tried it both ways today, no joy. But very good thinking on your part! :)

On a related note, here's something from Wired's HOW-TO Wiki. I am not the original author, but since I provided the last revisions, some displays (like the RSS) have listed me as the author. I don't deserve the credit:

Optimize BitTorrent To Outwit Traffic Shaping ISPs
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
Are you affected by Comcast's RST forging? How to test it! -or- Read my original report.
reply
Movieman420 @ 3rd Sep 07:25PM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

A somewhat dark ending in that article...let's just hope the developers of Az and uT are getting busy with something. As the two most popular clients it'd be nice if they came up with a joint strategy together. One can only hope... :hmm:
reply
deblin @ 3rd Sep 10:18PM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

Doesn't enabling (forcing) encryption have a similar effect, though? At least until it catches on, this means less peers (both up and down) if you enable and force encryption. Perhaps not as detrimental to the upstream side, but then the downstream side suffers, too.
--
"The Dude abides."
reply
jig @ 3rd Sep 11:47PM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

the major reason to care about seeding is for ratio purposes, and there are two ways to fix that....
reply
StuartA67 @ 4th Sep 12:39PM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

I'm a little technically challenged. What would I be looking for to see if the rst's are being sent. I have a network sniffer and saw quite a bit of action coming from Comcast and going to the port I have opened for bittorrent. Just not sure what it means exactly and I don't see rst in those.
reply
Movieman420 @ 4th Sep 04:14PM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

Thu a vpn or ssh tunnel (works for now at least) ...or spend a little money and get a host for a seed box. :)
reply
anon @ 5th Sep 07:29PM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

said by Movieman420 :

Thu a vpn or ssh tunnel (works for now at least) ...or spend a little money and get a host for a seed box. :)

Can you give a little more direction, even in the form of a link with info. Several posters above have said they haven't had success with this method (I'm not able to get it working either with SecureIx).

Thanks
reply
Presage @ 6th Sep 08:33PM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

Use PuTTy and a shell to use SSH and tunnel your bittorrent traffic. Info here: »whalesalad.com/2006/08/27/tunnel···/#eberth

I recommend checking freeshells.info for shells.
reply
koitsu @ 7th Sep 03:10AM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

And I recommend talking to your shell provider before doing this. It's considered "rude" to blindly siphon network traffic through a shell host like this, since now you're not only using up large amounts of bandwidth yourself, but on your shell providers' uplink as well.

I can tell you that as a hosting provider that offers SSH, if our users started doing that with their shell accounts, I'd be *livid*.
reply
anon @ 8th Sep 10:10AM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

"What would I be looking for to see if the rst's are being sent. I have a network sniffer and saw quite a bit of action coming from Comcast and going to the port I have opened for bittorrent"

I didn't have my port open, don't use or even have BitTorrent and I saw the same thing you did. Someone posted in reply to me last weekend that I either had someone on my wireless router (sorry, there's no joy there, it's WEP and MAC filtered/restricted for that very reason) and I was seeing P2P afterglow and alas too, not the case. Instead, this was loop back traffic from a specific network router locally affected in conjunction with Comcast's filtering implementation in this area - they cleared it up this past Sunday night and I no longer have any of the issues that I had before. I might also mention that when calling Comcast last weekend, I was told by the 3 folks to whom I spoke that the call center's own network was intermittently degraded or completely down while this work was taking place.

It is no surprise that Comcast (or any other ISP/broadband provider for that matter) would be attempting to throttle excessive bandwidth consumption based on their published TOS and advertised service packages you can purchase. Sorry folks, I can also say that since this all took place, my service is better than it ever has been before - and I am glad.

To the poster who mentioned UDP - good luck. UDP is notoriously unreliable even though it's lighter and quicker and my bet is you'll have the same issues you are now and perhaps worse. Especially on Comcast's network - at least in my area, my employer wanted us use UDP as the default protocol for VPN into their network and I tested it for them from both Cox and Comcast connections. It was so bad (frequent drops, hanging out there in the ether) that the UDP "standard" idea was abandoned after 3 weeks of testing.
reply
StuartA67 @ 8th Sep 11:02AM:
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPs

I just heard (from an undisclosed source) that Comcast is not throttling as much those on the higher speed package (8mbs). Not sure if this is a fact or not but curious to know if others are noticing this distinction.

S
reply

Thank you for using lo-fi dslreports.com - report bugs
© 99-2008 silver matrix LLC