Went to the office at SS13 today. Branch supervisor by the name of Encik Hussein said he has no knowledge of such blocking since he is only managing hardware between phone trunks to DSLAM exchange. Took my number. Told him about the attitude of his staff regarding the "not our problem" attitude, he defended his staff. I said "as a customer I don't care what you are in charge of, I just know TM and Streamyx, and your staff told me to come to the SS13 office, now I'm here. And you should not say it's not your problem because my logs said it is your problem". Showed him the logs, he said he will pass it onto other departments.

Sounds like this will be buried under a mountain of other cases. Looks like the people managing the network packets are the "untouchables" part of the TM org chart. Told him if it happens again, my next visit is to MCMC.

This post has been edited by spanker: Apr 28 2008, 06:36 PM

The problem with your results is that any part in the path between you and 75.158.91.220 could have spoofed the RST, not just TMNet. You need to come up with a more solid experiment that isolates these 3rd parties from being a possible factor.

...i scare those TM stuff cant understand what you say...

Of course tmnut won't understand what the hell he's trying to said....
It's too complicated for them to understand, they're just a nut............

Topic starter, you should open your case with MCMC, no point keep on complaining with nut ppl for no point, i very sure they won't understand what the hell you're trying to said.

Just write a letter to MCMC and CFM........
have a nice day:D

This could be so true it's scary

Maybe some ISPs exercise a reset command to malaysian IPs only.

Don't bother, it'll just fall unto deaf ears looking for blood. Over eagerness and hastiness to prove something are trademarks of this sub forum.

Well if someone other than Streamyx is spoofing them, I'd get RST packets from sources between Streamyx and 75.158.91.220 only (i.e. any relay servers connecting the 2 points). However, I get them on different channels, which does suggest someone much closer to home is spoofing the RST.

Nice catch though

wait, just out of curiosity, would complaning to MCMC about bandwidth shaping eventually lead to the hard pushing for copyright infringement control ?

example, say we complain about bandwidth shaping. MCMC acknowledges and "bam" releases the throttling issue. With TMNet unable to cope with rising performances and bandwidth, they decide its time to crackdown on illegal downloads of copyrighted materials because controlling bandwidth can no longer be under their control. This might eventually lead us to be like singapore. download copyrighted materials , get heavy fine.

is it such a good idea to be doing so ? would this affect TMnet's decision to push out and support RIAA and RIM to notify the companies of users that breach that law ?


i for one am not affiliated with TM. please understand that i am also not happy bout the throttling going on hence seeking alternatives that are free. clients such as xunlei and also thinking of re-activating my old VPN a/c. but by doing so, would we be under more fire ?

The faith is weak in you

What do you mean by "channels"? TCP/IP has no notion of that.

The source IP in IP packets is very spoofable (not just in theory, in practice too) due to the design of IP. Plain TCP/IP while it adds some protection from blind spoofing cannot prevent these man-in-the-middle RST spoofs. Now, if you can believe that TMNet is able to spoof a RST packet from you to 75.158.91.220, then by transitivity you will also accept that any party in between (including 75.158.91.220's ISP) is also able to.

---

Added on April 29, 2008, 5:58 pmDon't see why. It's none of their business.

Out of everything available in IP protocols, I wonder why TM wanted to tease your NNTP traffic?
Teasing your HTTP traffic would be more frustrating, I guess.

Furthermore, if they are doing shaping, I'm sure they would shape something more than just a mere NNTP right?

Well, the last time I got this, I just disable Tx & Rx offload on the NIC and everything was solved!

If you're going to TM you can use mine as well.. It's attached to this post... more evidence for you. And this isn't even BT, it's normal everyday use

---

Added on April 29, 2008, 6:29 pmDoesn't the connection slow down if you do that ?

This post has been edited by wodenus: Apr 29 2008, 06:30 PM

It's faster now after disabling it....
Theoretically it is suppose to be faster, but I guess it's the NIC driver issue that's why it could not unleash it full potential...

Blah.. what NIC are you using ? must go and get it

This post has been edited by wodenus: Apr 29 2008, 07:30 PM

That guy doesn't know what he's talking about


"Channels" as in peers/seeders. If the RST packets are coming in from various sources, it'll be much closer to me than it is to the seeders/peers.

If it is ONLY to 75.158.91.220, then yes you have a point. Plus, it doesn't explain my NNTP traffic being dropped

My NNTP traffic exceeds 50GB a month

This post has been edited by spanker: May 8 2008, 05:09 PM