funchordsHello MVM join:2001-03-11 Yarmouth Port, MA |
to Selenia
Re: Comcast is using Sandvine to manage P2P Connectionssaid 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. |
actions · 2007-Sep-4 8:34 pm · (locked) |
Roundboy Premium Member join:2000-10-04 Drexel Hill, PA |
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 ? |
actions · 2007-Sep-4 8:48 pm · (locked) |
Scilicet (banned)Spaced Out join:2005-04-11 Aurora, CO 1 edit
1 recommendation |
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. |
actions · 2007-Sep-4 9:48 pm · (locked) |
dfxmatt join:2007-08-21 Crystal Lake, IL 1 edit |
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 |
actions · 2007-Sep-4 10:55 pm · (locked) |
|
to Movieman420
Re: Optimize BitTorrent To Outwit Traffic Shaping ISPssaid 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 |
actions · 2007-Sep-5 7:29 pm · (locked) |
|
Presage join:2004-06-01 Londonderry, NH |
Use PuTTy and a shell to use SSH and tunnel your bittorrent traffic. Info here: » whalesalad.com/2006/08/2 ··· /#eberthI recommend checking freeshells.info for shells. |
actions · 2007-Sep-6 8:33 pm · (locked) |
koitsu MVM join:2002-07-16 Mountain View, CA Humax BGW320-500
|
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*. |
actions · 2007-Sep-7 3:10 am · (locked) |
Rom @comcast.net |
to funchords
Re: Comcast is using Sandvine to manage P2P ConnectionsI 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. |
actions · 2007-Sep-7 4:40 am · (locked) |
|
Could Be The Fix to funchords
Anon
2007-Sep-7 10:48 am
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 |
actions · 2007-Sep-7 10:48 am · (locked) |
funchordsHello MVM join:2001-03-11 Yarmouth Port, MA |
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. |
actions · 2007-Sep-7 4:02 pm · (locked) |
funchords |
to Could Be The Fix
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. |
actions · 2007-Sep-7 4:04 pm · (locked) |
NormanSI 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
|
said by funchords: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? |
actions · 2007-Sep-7 4:51 pm · (locked) |
koitsu MVM join:2002-07-16 Mountain View, CA Humax BGW320-500
1 edit |
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.htmA better analysis is here: » pages.cpsc.ucalgary.ca/~ ··· sets.pdfYour 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. |
actions · 2007-Sep-7 5:16 pm · (locked) |
funchordsHello MVM join:2001-03-11 Yarmouth Port, MA |
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. |
actions · 2007-Sep-7 8:06 pm · (locked) |
|
DrCable
Anon
2007-Sep-8 6:20 am
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 |
actions · 2007-Sep-8 6:20 am · (locked) |
ztmikeMark for moderation Premium Member join:2001-08-02 La Porte, IN |
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. |
actions · 2007-Sep-8 6:52 am · (locked) |
|
dontask2much to StuartA67
Anon
2007-Sep-8 10:10 am
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. |
actions · 2007-Sep-8 10:10 am · (locked) |
|
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 |
actions · 2007-Sep-8 11:02 am · (locked) |
funchordsHello MVM join:2001-03-11 Yarmouth Port, MA
1 recommendation |
Tests and Results-RSTs are set in both directionsRegarding these Posts and similar: » redhatcat.blogspot.com/2 ··· pfw.html» redhatcat.blogspot.com/2 ··· les.htmlSeveral 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 ··· _Killingquote: 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. |
actions · 2007-Sep-8 3:57 pm · (locked) |
ztmikeMark for moderation Premium Member join:2001-08-02 La Porte, IN |
to funchords
Re: Comcast is using Sandvine to manage P2P ConnectionsI 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. |
actions · 2007-Sep-8 4:08 pm · (locked) |
koitsu MVM join:2002-07-16 Mountain View, CA Humax BGW320-500
|
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.) |
actions · 2007-Sep-8 4:16 pm · (locked) |
ztmikeMark for moderation Premium Member join:2001-08-02 La Porte, IN |
ztmike
Premium Member
2007-Sep-8 4:20 pm
Can anyone confirm this? That has actually tried it..and has this crap Sandvine on their line? |
actions · 2007-Sep-8 4:20 pm · (locked) |
koitsu MVM join:2002-07-16 Mountain View, CA |
Yes -- ME! |
actions · 2007-Sep-8 7:25 pm · (locked) |
your moderator at work
hidden :
|
ztmikeMark for moderation Premium Member join:2001-08-02 La Porte, IN |
to funchords
Re: Comcast is using Sandvine to manage P2P ConnectionsStrange..my upload speed is back on utorrent, currently pegging my 384upload on torrent that has been done for awhile now. |
actions · 2007-Sep-9 12:33 pm · (locked) |
funchordsHello MVM join:2001-03-11 Yarmouth Port, MA |
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. |
actions · 2007-Sep-9 1:44 pm · (locked) |
ztmikeMark for moderation Premium Member join:2001-08-02 La Porte, IN 1 edit |
ztmike
Premium Member
2007-Sep-9 2:19 pm
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. |
actions · 2007-Sep-9 2:19 pm · (locked) |
hobgoblinSortof Agoblin Premium Member join:2001-11-25 Orchard Park, NY |
said by ztmike:Comcast as far as big companys go are now worse than Microsoft in my book. cancel your service. Goodbye Hob |
actions · 2007-Sep-9 6:00 pm · (locked) |
EGThe wings of love Premium Member join:2006-11-18 Union, NJ 2 edits |
EG to ztmike
Premium Member
2007-Sep-9 9:47 pm
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 ?? |
actions · 2007-Sep-9 9:47 pm · (locked) |
SeleniaGentoo Convert Premium Member join:2006-09-22 Fort Smith, AR 1 edit
1 recommendation |
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. |
actions · 2007-Sep-9 10:03 pm · (locked) |