dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
319926

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

funchords to Selenia

MVM

to Selenia

Re: Comcast is using Sandvine to manage P2P Connections

said by Selenia:

Its filters can be set in an advanced manner but it sounds like there are some primitive users. Some tools are only as good as their users.
Sandvine (the Company) has a very strong interest in seeing Comcast and its customers succeed with Sandvine (the P2P Policy Product). If Comcast needs help, I'm positive it is just a telephone call away.

PS: I know that this topic is being regularly read by Comcast and Sandvine insiders -- you guys really should pick up the phone and talk to one another.

Roundboy
Premium Member
join:2000-10-04
Drexel Hill, PA

Roundboy to funchords

Premium Member

to funchords
is it possible to selectively drop RST packets?

one packet is not a false packet, but many over a period of time are fake..

can we filter one packet, and after a small period of time (milliseconds) allow it though if its the only one, or keep filtering if its repeated ?
Scilicet (banned)
Spaced Out
join:2005-04-11
Aurora, CO

1 edit

1 recommendation

Scilicet (banned) to funchords

Member

to funchords
It has taken me a few days to read through this whole thread. I took interest in it as Azureus has been acting up badly within the last month or so. I don't do very much P2P, but I find it useful at times.

I first noticed things acting strange after a problem free download. The seed displayed that I was firewalled even though a test of the port showed that it was open. Nothing I could do would get me to seed. I just gave up.

Recently, Azureus updated to 3.0.2.0, so using the CheckRST.bat file (that I am grateful for) I ran another test with logging on and with the following conditions set to on:
- Require Encrypted Transport
- Minimum Encryption level to RC4
- Use Lazy Bitfield

And for the heck of it:
- Allow multiple connections from same IP
- Prioritize first and last pieces of file(s)

This worked. Although the RSTs received were averaging about 25%. The download completed normally as did seeding. It continues as I write this.

Edit: P.S. QoS for the port was enabled at the router as well.
dfxmatt
join:2007-08-21
Crystal Lake, IL

1 edit

dfxmatt to funchords

Member

to funchords
said by funchords:

said by Selenia:

Its filters can be set in an advanced manner but it sounds like there are some primitive users. Some tools are only as good as their users.
Sandvine (the Company) has a very strong interest in seeing Comcast and its customers succeed with Sandvine (the P2P Policy Product). If Comcast needs help, I'm positive it is just a telephone call away.

PS: I know that this topic is being regularly read by Comcast and Sandvine insiders -- you guys really should pick up the phone and talk to one another.
Last time I talked to them on the phone (comcast), I was treated very aggressively, almost threatened by the techs. So I don't know what to say.

For those who call comcast, please record your calls. Do remember that when they say "these calls may be recorded for quality assurance" is the neccessary notification to record them as well. I can't find the exact link but here is an Example: »www.voiceprintonline.com ··· le_id=51

JedSezZed
@comcast.net

JedSezZed to Movieman420

Anon

to Movieman420

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
Presage
join:2004-06-01
Londonderry, NH

Presage

Member

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

I recommend checking freeshells.info for shells.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu

MVM

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

Rom
@comcast.net

Rom to funchords

Anon

to funchords

Re: Comcast is using Sandvine to manage P2P Connections

I just moved to Seattle and I am now having problems related to BT with Comcast, which I wasn't having before. Utorrent is constantly dropping the connection, which seems in line with what is being discussed here, but it is not doing it with every tracker.

Is this something tracker related or something Comcast is doing? I can upload elsewhere at the 90 kb/s rate that I get with the 8mbps package.

Seems strange that it is only shaping traffic in regards to particular trackers.

Could Be The Fix
@tor-exit-node.tor

Could Be The Fix to funchords

Anon

to funchords
I'm not having the problem descibed, but is this the magic bullet for those that are?

»redhatcat.blogspot.com/2 ··· ive.html

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

funchords to Rom

MVM

to Rom
said by Rom :

Utorrent is constantly dropping the connection,
What you will see is, looking at the peer list, is that peers will appear for up to 30 seconds, then disappear. This will happen over and over.

It has nothing to do with the Tracker or your connection with the tracker. It affects the connections with your peers.
funchords

funchords to Could Be The Fix

MVM

to Could Be The Fix
said by Could Be The Fix :

I'm not having the problem descibed, but is this the magic bullet for those that are?

»redhatcat.blogspot.com/2 ··· ive.html
No. The RST packet is sent in both directions -- so even if you ignore the RST, your peer is still going to obey it -- leaving a half-open connection.

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

MVM

said by funchords:
said by Could Be The Fix :

I'm not having the problem descibed, but is this the magic bullet for those that are?

»redhatcat.blogspot.com/2 ··· ive.html
No. The RST packet is sent in both directions -- so even if you ignore the RST, your peer is still going to obey it -- leaving a half-open connection.
You have gone to a depth that surpasses my understanding of the way things work...I think. Still, what if I checked on my end (at&t Yahoo! HSI customer) for forged RST packet from Comcast. If I ignored them and the Comcast user ignored them, what would happen?

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

1 edit

koitsu

MVM

said by NormanS:

You have gone to a depth that surpasses my understanding of the way things work...I think. Still, what if I checked on my end (at&t Yahoo! HSI customer) for forged RST packet from Comcast. If I ignored them and the Comcast user ignored them, what would happen?
Two things -- both bad -- could happen:

1) You'd have a TCP session that was in an unknown/invalid state. Such can happen in the case of latent networks, or where part of the SYN/SYN+ACK handshake fails. TCP RST is quite valid under normal operation (and happens more often than one thinks), so it's important to respect that.

2) You'd have a TCP session that would never get torn down. What decides how the connection is torn down? Essentially it's up to the application to decide how they want to handle an error condition on recv(3) (I'm talking UNIX here; no idea how Windows' TCP stack works on this).

A fairly ugly/vague explanation is here:

»www.flukenetworks.com/fn ··· pert.htm

A better analysis is here:

»pages.cpsc.ucalgary.ca/~ ··· sets.pdf

Your question got me thinking, though:

It *is* possible to write a program that makes some assumptions about the TCP state (that is to say, two programs both written to essentially never induce TCP RST). This means that it *is* possible for someone to write/modify a BitTorrent client to simply ignore RST (by handling the error condition differently), and continue on blindly. However, this situation would have to be negotiated in some way between client/peer and server/seed because you couldn't just blindly assume the TCP session was flawless -- it isn't, which is why TCP is stateful!

Thus brings me to another conclusion:

Why not just use UDP? It's stateless (thus faster than TCP), but has the downside of not having send/receive guaranteed like TCP does. UDP is used by most FPS online games, because if you lose a single packet (due to whatever), that pretty much amounts to a lost bullet, lost step/movement to the right, or whatever else. Chances are less than 1ms later, the client will be sending another one of those anyway (especially in regards to movement), so the lost packet is not a big deal.

If you're an old BBS user, you can consider UDP synonymous with Ymodem-G (known for blazing speeds, but absolutely no data validation, so you took a risk in the case that your modem didn't have EC (or the remote end lacked EC)).

Using UDP datagrams, the clients would have to essentially emulate TCP over UDP (that is to say, do some sort of handshake where one sends a large UDP packet, performs a checksum validation of it, asks the server/seed "is this right?" and have it reply "yes it is" and continue on).

Using this method would work around the Sandvine's interceptor. You might be wondering, "So how could Comcast circumvent *that*?" They'd have to rate-limit or downright block UDP packets altogether -- or, because the Sandvine can do packet analysis, somehow code up an analysis of the stateful-like UDP packets and monitor those, injecting refusals of checksums or whatever else they could do to severe the connection.

Meaning: it would be a matter of time before Sandvine and Comcast worked out a way to deal with using UDP instead of TCP.

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

funchords to NormanS

MVM

to NormanS
said by NormanS:

You have gone to a depth that surpasses my understanding of the way things work...I think. Still, what if I checked on my end (at&t Yahoo! HSI customer) for forged RST packet from Comcast. If I ignored them and the Comcast user ignored them, what would happen?
Nothing, the connection would happily continue.

But there is a mildly-bad side effect -- if something happened on one end or another that interrupted your connection before it was properly closed, the loss of the RST flag means that you wouldn't be able to quickly detect and fix it. You'd have to wait for a timeout either from your application or the network stack. Meanwhile, you have no idea why things just died -- you appear to be connected, but you're not.

There are other, less bad, side effects. For example, "Connection Refused" wouldn't be detected anymore, but the timeouts in that state are generally a lot shorter.

DrCable
@comcast.net

DrCable

Anon

said by funchords:

Nothing, the connection would happily continue.

But there is a mildly-bad side effect -- if something happened on one end or another that interrupted your connection before it was properly closed, the loss of the RST flag means that you wouldn't be able to quickly detect and fix it. You'd have to wait for a timeout either from your application or the network stack. Meanwhile, you have no idea why things just died -- you appear to be connected, but you're not.

There are other, less bad, side effects. For example, "Connection Refused" wouldn't be detected anymore, but the timeouts in that state are generally a lot shorter.
Also not all RST set packets have zero length data. Many have data we need because they are actually sabotaging needed packets and not just inserting standalone RST packets into the stream thus increasing packet count.

In my testing just blocking on both sides works only so so. it is much better to re forge (unset the RST flag) packets that are NOT zero length data, then let them through. So if zero length data just block it. if NOT zero length data unset the RST flag and let it through.

Another thing that could be tried is to just delay your response action to RST and then watch to see if any legit peer packets come in right behind it. If they do then odds are that RST was BOGUS and did not come from the peer. What to do next is obvious


ztmike
Mark for moderation
Premium Member
join:2001-08-02
La Porte, IN

ztmike to funchords

Premium Member

to funchords
Well it looks like my ride is over for seeding as well.

Im currently trying to seed but its seeding around 3.0 to 5.5kb/s and then sometimes it jumps higher..i don't know if its just nobody is downloading or what.

Kinda weird though.. i got an email from some myspace guy that lives in Valpo (A town not far from me) asking if my bit torrent seeding speed has dropped to nothing. I told him no and gave him the link to this topic, after i sent that back to him my seeding speed dropped..

I'll update later if this "Sandvine" is really in effect.

dontask2much
@comcast.net

dontask2much to StuartA67

Anon

to StuartA67

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.
StuartA67
join:2003-08-08
Boulder, CO

StuartA67

Member

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

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

1 recommendation

funchords

MVM

Tests and Results-RSTs are set in both directions

Regarding these Posts and similar:
»redhatcat.blogspot.com/2 ··· pfw.html
»redhatcat.blogspot.com/2 ··· les.html

Several have mentioned that it is possible to defeat the injected/forged RST packets by ignoring them at a firewall. I tested that theory earlier »Re: Comcast is using Sandvine to manage P2P Connections but the rumor persists. "Redhatcat" claims first-hand knowledge that a forged RST is not sent from the Comcast network.

»digg.com/linux_unix/Linu ··· _Killing
quote:
Comcast does not kill non-Comcast connections. I only know from personal experience.

I believe they choose to not do this to avoid lawsuits from other ISPs, as that behavior could be seen as a DoS attack on their customers/networks. That's not to say what they are doing to their customers now is not a DoS attack, but they are less afraid of lawsuits from individuals than other ISPs most likely.
Unfortunately, he is incorrect.

The following are two Wireshark copies of the same TCP conversation -- one from a Comcast system that is seeding a BitTorrent file, one from a Non-Comcast system that is trying to download it. The connection is torn down by forged RST packets about 30 seconds after it starts:

LOG from 192.168.177.109
Wireshark Display Filter: (ip.addr eq 192.168.177.109 and ip.addr eq no.t-c.omc.ast) and (tcp.port eq 10941 and tcp.port eq 3828) and ((tcp.len > 0 and tcp.len < 256) or  tcp.flags.reset == 1)
 
No.     Time        Source                Destination           Protocol Info
   2615 270.433545  no.t-c.omc.ast        192.168.177.109       BitTorrent Handshake
   2616 270.441617  192.168.177.109       no.t-c.omc.ast        BitTorrent Handshake  Continuation data
   2617 270.821830  no.t-c.omc.ast        192.168.177.109       BitTorrent Continuation data
   2619 273.854944  192.168.177.109       no.t-c.omc.ast        BitTorrent Continuation data
   2621 275.031345  no.t-c.omc.ast        192.168.177.109       BitTorrent Continuation data
   2623 275.835629  192.168.177.109       no.t-c.omc.ast        BitTorrent Unchoke
   2624 276.217062  no.t-c.omc.ast        192.168.177.109       BitTorrent Request, Piece (Idx:0x1,Begin:0xc000,Len:0x4000)
   2647 279.154962  no.t-c.omc.ast        192.168.177.109       BitTorrent Not Interested  Have, Piece (Idx:0x1)
   2648 279.155083  192.168.177.109       no.t-c.omc.ast        BitTorrent Choke
   2650 280.981972  192.168.177.109       no.t-c.omc.ast        BitTorrent Have, Piece (Idx:0x2)
   2652 282.025653  no.t-c.omc.ast        192.168.177.109       BitTorrent Interested
   2654 282.834452  192.168.177.109       no.t-c.omc.ast        BitTorrent Unchoke
   2655 283.218291  no.t-c.omc.ast        192.168.177.109       BitTorrent Request, Piece (Idx:0x2,Begin:0x0,Len:0x4000)  Request, Piece (Idx:0x2,Begin:0x4000,Len:0x4000)
   2658 283.329341  192.168.177.109       no.t-c.omc.ast        TCP      [TCP segment of a reassembled PDU]
   2678 283.919542  192.168.177.109       no.t-c.omc.ast        TCP      [TCP segment of a reassembled PDU]
   2684 284.216967  no.t-c.omc.ast        192.168.177.109       BitTorrent Request, Piece (Idx:0x2,Begin:0x8000,Len:0x4000)
   2710 285.284180  no.t-c.omc.ast        192.168.177.109       BitTorrent Request, Piece (Idx:0x2,Begin:0xc000,Len:0x4000)
   2742 288.151657  no.t-c.omc.ast        192.168.177.109       BitTorrent Not Interested  Have, Piece (Idx:0x2)
   2743 288.151817  192.168.177.109       no.t-c.omc.ast        BitTorrent Choke
   2745 289.983878  192.168.177.109       no.t-c.omc.ast        BitTorrent Have, Piece (Idx:0x5)
   2747 291.022881  no.t-c.omc.ast        192.168.177.109       BitTorrent Interested
   2749 291.842268  192.168.177.109       no.t-c.omc.ast        BitTorrent Unchoke
   2750 292.232989  no.t-c.omc.ast        192.168.177.109       BitTorrent Request, Piece (Idx:0x5,Begin:0x0,Len:0x4000)  Request, Piece (Idx:0x5,Begin:0x4000,Len:0x4000)  Request, Piece (Idx:0x5,Begin:0x8000,Len:0x4000)
   2782 293.362854  no.t-c.omc.ast        192.168.177.109       BitTorrent Request, Piece (Idx:0x5,Begin:0xc000,Len:0x4000)
   2839 297.074532  192.168.177.109       no.t-c.omc.ast        TCP      [TCP segment of a reassembled PDU]
   2843 298.111256  no.t-c.omc.ast        192.168.177.109       BitTorrent Not Interested  Have, Piece (Idx:0x5)
   2844 298.111379  192.168.177.109       no.t-c.omc.ast        BitTorrent Choke
   2846 299.882328  192.168.177.109       no.t-c.omc.ast        BitTorrent Have, Piece (Idx:0x6)
   2848 301.036256  no.t-c.omc.ast        192.168.177.109       BitTorrent Interested
   2850 301.949703  192.168.177.109       no.t-c.omc.ast        BitTorrent Unchoke  Continuation data
   2851 302.331317  no.t-c.omc.ast        192.168.177.109       BitTorrent Request, Piece (Idx:0x6,Begin:0x0,Len:0x4000)  Request, Piece (Idx:0x6,Begin:0x4000,Len:0x4000)  Request, Piece (Idx:0x6,Begin:0x8000,Len:0x4000)
   2853 302.332386  192.168.177.109       no.t-c.omc.ast        TCP      [TCP segment of a reassembled PDU]
   2854 302.344482  no.t-c.omc.ast        192.168.177.109       TCP      3828 > 10941 [RST] Seq=406 Len=0
   2855 302.344668  no.t-c.omc.ast        192.168.177.109       TCP      3828 > 10941 [RST] Seq=12909 Len=0
   2856 302.351237  no.t-c.omc.ast        192.168.177.109       TCP      3828 > 10941 [RST] Seq=406 Len=0
   2857 302.351407  no.t-c.omc.ast        192.168.177.109       TCP      3828 > 10941 [RST] Seq=12909 Len=0
 
Note: Packet 2854 indicates receiving an RST from the Non-Comcast system.
 

LOG from no.t-c.omc.ast
Wireshark Display Filter: (ip.addr eq 24.20.3X.XXX and ip.addr eq no.t-c.omc.ast) and (tcp.port eq 10941 and tcp.port eq 3828) and ((tcp.len > 0 and tcp.len < 256) or  tcp.flags.reset == 1)
 
No.     Time        Source                Destination           Protocol Info
   2594 270.413086  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Handshake
   2595 270.820312  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Handshake  Continuation data
   2596 270.821289  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Continuation data
   2598 274.249023  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Continuation data
   2600 275.032226  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Continuation data
   2602 276.213867  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Unchoke
   2603 276.213867  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Request, Piece (Idx:0x1,Begin:0xc000,Len:0x4000)
   2626 279.146484  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Not Interested  Have, Piece (Idx:0x1)
   2627 279.541992  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Choke
   2629 281.361328  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Have, Piece (Idx:0x2)
   2631 282.023437  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Interested
   2633 283.212890  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Unchoke
   2634 283.212890  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Request, Piece (Idx:0x2,Begin:0x0,Len:0x4000)  Request, Piece (Idx:0x2,Begin:0x4000,Len:0x4000)
   2638 283.733398  24.20.3X.XXX          no.t-c.omc.ast        TCP      [TCP segment of a reassembled PDU]
   2655 284.208007  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Request, Piece (Idx:0x2,Begin:0x8000,Len:0x4000)
   2666 284.309570  24.20.3X.XXX          no.t-c.omc.ast        TCP      [TCP segment of a reassembled PDU]
   2676 285.265625  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Request, Piece (Idx:0x2,Begin:0xc000,Len:0x4000)
   2720 288.116211  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Not Interested  Have, Piece (Idx:0x2)
   2721 288.539062  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Choke
   2723 290.380859  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Have, Piece (Idx:0x5)
   2725 291.022461  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Interested
   2727 292.223632  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Unchoke
   2728 292.227539  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Request, Piece (Idx:0x5,Begin:0x0,Len:0x4000)  Request, Piece (Idx:0x5,Begin:0x4000,Len:0x4000)  Request, Piece (Idx:0x5,Begin:0x8000,Len:0x4000)
   2749 293.343750  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Request, Piece (Idx:0x5,Begin:0xc000,Len:0x4000)
   2816 297.459961  24.20.3X.XXX          no.t-c.omc.ast        TCP      [TCP segment of a reassembled PDU]
   2820 298.100586  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Not Interested  Have, Piece (Idx:0x5)
   2821 298.490234  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Choke
   2823 300.263671  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Have, Piece (Idx:0x6)
   2825 301.036132  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Interested
   2827 302.329101  24.20.3X.XXX          no.t-c.omc.ast        BitTorrent Unchoke  Continuation data
   2828 302.329101  no.t-c.omc.ast        24.20.3X.XXX          BitTorrent Request, Piece (Idx:0x6,Begin:0x0,Len:0x4000)  Request, Piece (Idx:0x6,Begin:0x4000,Len:0x4000)  Request, Piece (Idx:0x6,Begin:0x8000,Len:0x4000)
   2830 302.717773  24.20.3X.XXX          no.t-c.omc.ast        TCP      10941 > 3828 [RST] Seq=149186 Len=0
   2831 302.717773  24.20.3X.XXX          no.t-c.omc.ast        TCP      10941 > 3828 [RST] Seq=161689 Len=0
   2832 302.722656  24.20.3X.XXX          no.t-c.omc.ast        TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
   2833 302.722656  24.20.3X.XXX          no.t-c.omc.ast        TCP      10941 > 3828 [RST] Seq=149286 Len=0
   2834 302.722656  24.20.3X.XXX          no.t-c.omc.ast        TCP      10941 > 3828 [RST] Seq=161789 Len=0
 
Note: Packet 2830 indicates receiving an RST from the Comcast system.
 

Conclusion: The RST is sent to both the Comcast and Non-Comcast sides of the connection.

If only one side respects the RST flag, the connection will be left in a half-open state. To one side, the TCP connection will appear to be valid and open. To the other, the TCP connection will have been ended. A half-open TCP connection is useless for exchanging data.

Comcast users should not modify their firewalls to drop RST packets as it is not an effective defense against the injected RST packets.

ztmike
Mark for moderation
Premium Member
join:2001-08-02
La Porte, IN

ztmike to funchords

Premium Member

to funchords

Re: Comcast is using Sandvine to manage P2P Connections

I have a question..Will this Sandvine affect xbox 360 users who try to host a game?

I don't have a 360 but was thinking about picking one up later on down the road.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu

MVM

At this time, no, it shouldn't affected game hosting on a 360 or otherwise. It appears specific to BitTorrent traffic. No 360 games (AFAIK) use BT. Most use UDP, from what I've seen (I sniffed Two Worlds' traffic, to see if the claims of "servers being in Germany" was true or not. Private games appear to be peer-to-peer, and use UDP only.)

ztmike
Mark for moderation
Premium Member
join:2001-08-02
La Porte, IN

ztmike

Premium Member

Can anyone confirm this? That has actually tried it..and has this crap Sandvine on their line?

koitsu
MVM
join:2002-07-16
Mountain View, CA

koitsu

MVM

Yes -- ME!
Expand your moderator at work

ztmike
Mark for moderation
Premium Member
join:2001-08-02
La Porte, IN

ztmike to funchords

Premium Member

to funchords

Re: Comcast is using Sandvine to manage P2P Connections

Strange..my upload speed is back on utorrent, currently pegging my 384upload on torrent that has been done for awhile now.

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

funchords

MVM

said by ztmike:

Strange..my upload speed is back on utorrent, currently pegging my 384upload on torrent that has been done for awhile now.
yeah, they're messing with things. My test results differ one day to the next.

They are also closely monitoring this forum (both Sandvine and Comcast). A few insiders have contacted me (robb at funchords dot com) -- I'll never disclose who. But clearly, this matter is getting some "underground" attention.

I'm not sure if the day-by-day changes are a result of the feedback we're getting, or if they're tuning, or what. But, I agree with you -- it behaves strangely.

ztmike
Mark for moderation
Premium Member
join:2001-08-02
La Porte, IN

1 edit

ztmike

Premium Member

What feedback?

As far as Comcast watching this thread, I have one thing to say to them, kiss my white ass.

This "Sandvine" should be reported to a news agency say..CNN or MSNBC, its obvious Comcast is doing this and should get coverage, Since Comcast failed at telling their own paying customers a lie, And if its against some laws in states im surpised their still expanding the coverage of sandvine.

Comcast as far as big companys go are now worse than Microsoft in my book.

hobgoblin
Sortof Agoblin
Premium Member
join:2001-11-25
Orchard Park, NY

hobgoblin

Premium Member

said by ztmike:

Comcast as far as big companys go are now worse than Microsoft in my book.
cancel your service.

Goodbye

Hob

EG
The wings of love
Premium Member
join:2006-11-18
Union, NJ

2 edits

EG to ztmike

Premium Member

to ztmike
said by ztmike:

What feedback?

As far as Comcast watching this thread, I have one thing to say to them, kiss my white ass.

This "Sandvine" should be reported to a news agency say..CNN or MSNBC, its obvious Comcast is doing this and should get coverage, Since Comcast failed at telling their own paying customers a lie, And if its against some laws in states im surpised their still expanding the coverage of sandvine.

Comcast as far as big companys go are now worse than Microsoft in my book.
Do you really think that they would invest money in an app such as Sandvine without having first done their homework ??

Selenia
Gentoo Convert
Premium Member
join:2006-09-22
Fort Smith, AR

1 edit

1 recommendation

Selenia to hobgoblin

Premium Member

to hobgoblin
said by hobgoblin:

said by ztmike:

Comcast as far as big companys go are now worse than Microsoft in my book.
cancel your service.

Goodbye

Hob
It might be reasonable advice if they have decent alternatives. Some areas don't. I seen you make apathetic comments to this effect before. While one of them is true that "they have the right to manage their networks" leaving out the "as they see fit" part because as they see fit could literally mean anything, these people have the right to bitch. The ISP has gone beyond managing their network and to infringing rights in 2 ways. 1) They don't seem to limit sharing files with who you choose, they seem to outright kill it! and 2) This is the big one. They have NO RIGHT to lie to their customers. That's just false advertising and they could be sued for it if they can prove this Sandvine shaping and record calls with Comcast denying it. Comcast by denying it, in effect, is telling you that you will have an uninhibited connection, provided you do not violate the excessive bandwidth clause, which is fuzzy in itself and could result in legal action someday making them disclose what the customer is getting for limits. This in itself, denies the consumer the right to make an educated choice about their service.

If you're wondering why I'm standing up for these people, it's because this kind of hits home. It took alot of effort to get Rogers to admit what they are doing, but they came out much quicker than Comcast seems to want to. It's also about net neutrality and peoples' right to choose. Would you like it if Comcast blocked dslreports in favor of a competitive site? Well them and other ISPs are playing that same game, only with protocols.