dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
41
johnmwilson7
join:2007-08-30
Washington, DC

1 edit

johnmwilson7 to funchords

Member

to funchords

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

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords

MVM

said by johnmwilson7:

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 johnmwilson7:

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/rfc7 ··· tion-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 johnmwilson7:

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 johnmwilson7:

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 johnmwilson7:

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.

dontask2much
@comcast.net

dontask2much

Anon

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.

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords

MVM

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 FAQ »How do I get a different IP address?

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to dontask2much

MVM

to dontask2much
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.