US Cable Support > RCN > Bit Torrent Uploads Being Disconnected

reply to phundercover

Re: Bit Torrent Uploads Being Disconnected

reply to phundercover

[21:27:21]  {1:1:0}  Peer connection [R: x.x.x.x: 4099 [BitComet 0.59]] closed: connection exception: end of stream on socket read

[21:27:30]  {1:1:0}  Peer connection [R: y.y.y.y: 1343 [BitComet 0.57]] closed: connection exception: end of stream on socket read

[21:27:49]  {1:1:0}  Peer connection [R: z.z.z.z: 3157 [BitTornado 0.3.10]] closed: connection exception: end of stream on socket read

I'm sorry for being a dunce, but what do these results mean?

Well in my opinion it shows that once my client sends a BT_HANDSHAKE, which is obviously some kind of term that is meant to signal an initiation of an exchange of torrent pieces, an error takes place. The connection exception which interrupts the connection to the other peer is obviously some kind of block. The stream and connection are interrupted right after they start.

This should be sufficient proof that something on RCN's end is interrupting torrent transfers. If this is not an RCN anti-torrent measure then I'll eat my hat.

The question is, what can we do about it? RCN seems to be denying that it is blocking anything, but we be reasonably sure from our logging results (and from the number of people who have experienced this) that blocking is taking place. Is it time to change ISP or is there hope that RCN will remove this block?

reply to phundercover
That hat eating threat is a dangerous one in this thread; be careful!

I think it's too soon to start thinking about changing your ISP. RCN has stated that it doesn't throttle bandwidth, so it should want to help resolve this problem.

At this point it would be helpful if one or more of the RCN reps who read this forum would weigh in and give advice. I'll send a pm and ask for their opinions.

John

[edit: PMs sent 12/19, 6:45am est.]

I've had some success with BitComet 0.59, which encrypts packets to other BitComet clients (and I only see BC clients able to connect) The fact only this works suggest it must be some packet checking that is happening along the way, and the finger must be pointed at RCN right now.

EDIT: And just as a heads up, this isn't just blocking, this is SPOOFING which up to now has been beyond the pale for any ISP.

Joe? Bryan? Bueller?

Bitcomet is not an option for me since private trackers are now refusing it.

Noz, can you explain what you mean by spoofing? What is it and how would it be accomplished?

Spoofing means sending a packet pretending to be from another source - in this case a "close" TCP packet pretending to come from the initial client trying to connect. The fact that connections open, then mysteriously close a 1/2 second later, with ethereal showing the close packet kinda makes this a highly likely scenario, and also means that it isn't simple port blocking

In terms of how it would be accomplished - this would be implemented by sniffing the traffic, then sending out a spoof close packet in reply to a connection handshake. It would have to be done on a router in the chain - most likely in the CMTS plant.

As I've said - I do pity RCN's engineers, as sadly this is the price I believe we have to pay for having a 2MB upload speed. Personally I'd prefer to see some kind of throttle for those excessively abusing the upstream, but we've seen how much that has angered people on OOL.

Doesn't sound good...

Is this something you could work through with RCN support? I'd offer to do it (if I understood it better...) but I'm away from home until after the holiday.

I did leave my cable modem connected in case there's any need (or offer) for RCN to test it.

John

I doubt we will hear any informal comment from RCN support. I'd also be surprised if they own up to this in a more formal setting either, since its going to get them a lot of negative publicity.

I would suggest to anyone from RCN reading this that its probably in your comapnies interest to come out now and explain honestly than appear on the front page of BBR because of this thread.

RCN has got a lot of respect from the tech community for its no throttle, no threaten policy - but that could be lost in a heartbeat.

reply to nozzer
Tried using the protocol header encrypt (anti BT protocol filter) on BitComet and lazy bitfield (helps seeding on networks employing bitfield-based blocking) on the new Azureus 2307 beta. Using both of these, I am able to seed fine.

Has anyone contacted RCN with a link to this topic yet?

Dijitaal,

Thanks for the good news! Glad to hear that there's a workaround solution anyway...

I emailed RCN support this morning with the link and the ticket is still open.

John

reply to dijitaal
Does your solution allow non azureus/BC clients to connect?
EDIT: yup - the azureus beta does the trick. Strangely the lazy bitfield option in uTorrent doesnt tho??

reply to phundercover
where did you find azureus 2.3.0.7? is it an official beta or a hack? ...nothing to be found in »prdownloads.sourceforge.net/azureus/

early results look good.... *crosses fingers*

Look for "beta" on the top row menu of the azureus sourceforge homepage

reply to sycocowz
It is beta: »azureus.sourceforge.net/index_CVS.php

reply to nozzer
Great news!

Can you explain to me what the lazy bitfield option does & why it would work if Noz's id of spoofing is correct?

Strange that it would work in one client and not the other.

John

reply to phundercover
Has anyone who is having this issue tried lowering the total upload speed rather than letting it get saturated?

reply to phundercover
I have no problem with BT. Have been using it for quite a bit of time with different clients. Currently using Azureus 2.3.0.6. All green lights. The only glitch with Azureus and my Linlsys router is that UPnP does not work. Azureus is not able to open the port so I do it manually in the router forwarding config.