Cox Scraps App-Specific Throttling Trials > Thanks for your desicion, but...

reply to Ikyuao

Re: Thanks for your desicion, but...

reply to espaeth
Huh? that doesn't breaks any of applications so my iptables firewall is supposed be protecting the system from TCP RST attack packets by *forged packet creator hacker*
--
Professional Linux environmental blows microsoft windows out of the water.

does that means this valid TCP RST will disconnect my application from server if TCP have a good reason to send out a TCP RST packet to cut my connection off...? I only block all of TCP RST packets incoming. not outcoming direction of TCP RST blocked. it is only incoming direction that I blocked TCP RST packets. so there, it is not caused of applications be problems.
--
Professional Linux environmental blows microsoft windows out of the water.

If you block incoming TCP RST packets there are only 2 ways for a TCP session to close: a valid FIN/FIN-ACK sequence, or the session has to time out.

A common place where TCP RSTs are used is in applications that reside behind a load balancer. Say you go to a website that is balanced across a pool of servers, usually your session will have a sticky association to just one of the servers. If that back-end server you are associated with goes down, the load balancer handles that by resetting the TCP session and redirecting you to another server once you establish a new TCP connection.

If you block the incoming TCP reset your browser will still assume the connection is valid and that website will appear to be down until the TCP session eventually times out and you attempt to establish a new session.

This is just one case of many where TCP RSTs serve a valid function.

that is not gonna be happen to bite me at all so not either happening to the applications and applications of functions are fine and there is nothing wrong with applications in matters that i have no issues with applications, TCP RST is not used by the applications unless if there is no response of connection over TCP so user application browser may have to click on "reload" tab to send the TCP RST to the host server to disconnect the virtual circuit of TCP of server side but server side really can send out the TCP RST if there is connection problems but that isn't going to work that due the client side of iptables firewall swallows TCP RST packet in the hole till user have to do manually click reload tab button of browser to send out the TCP RST packet to server side to cut connection out.
--
Professional Linux environmental blows microsoft windows out of the water.

reply to espaeth
If this is the same person, then I tried to explain this to him more than a year ago. He won't accept the explanation.

Oh well, he breaks it, he owns both pieces.

Breaks? what are you talking about? there's nothing wrong with TCP specific that is nature of flag bits of TCP specific so there is nothing do with applications, if administrator don't like to receiving the TCP RST flag bit packet inbound direction then administrator have right to block the TCP RST flag bit packet off of inbound completely and you don't know what are you talking about...
--
Professional Linux environmental blows microsoft windows out of the water.

I agree. You have the right to break (as in cripple the functionality of) your network stack and leave a bunch of half-open TCP connections in your state table.

And I do indeed know what I'm talking about, and so does Espaeth.

I told you then, and I'm telling you know, screening out TCP RSTs does not avoid any problem and only harms you. YOU HAVE THE RIGHT. It doesn't harm me, so go right ahead. It's yours. Break it if you want to.
--
Robb Topolski -= funchords.com =- District of Columbia -- KJ7RL
Test your Broadband connection today! -- »measurementlab.net/

Again, I were telling that I'd blocked the TCP RST abuser packets INBOUND DIRECTION, NOT OUTBOUND DIRECTION of iptables firewall packet filter that way the iptable firewall operate that I designed that way to filtering TCP RST out of inbound direction but TCP RST is not filtered at outbound in firewall processing before going out of outbound direction that is nothing harms me at all. So screening TCP RST out can help, that bittorrent application won't be interrupted that where TCP RST is filtered out of inbound direction that is I don't have problem with that where TCP RST abuser is filtered out of inbound direction. TCP RST in RFC that were designed to disrupt the connection immediately or cut connection out immediately and unfortunate, abuser can take advantage of TCP RST to abuse the TCP RST flag bit set packet to forge it but I set it to filter TCP RST out for inbound only with iptable firewall that's it I have peace now and my internet performance were great of speeds.
--
Professional Linux environmental blows microsoft windows out of the water.