This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Hierdie gesprek is in die argief. Vra asseblief 'n nuwe vraag as jy hulp nodig het.

firefox does not re-initiate TCP session when receiving RST-ACK

  • 1 antwoord
  • 11 hierdie probleem
  • 3 views
  • Laaste antwoord deur tan.taifeng

more options

Hello guys,

I’m writing to report a disparity between firefox and IE/Chrome when receiving RST-ACK.

To mitigate SYN flood attack, one of the countermeasures of anti-ddos appliance is to reset the first 3-way handshake and expect a re-initiated new tcp session from that client. If the real client, browser for example, automatically re-initiate a new session, users won’t feel too much differences except time of delay. If a browser does not automatically start a new session, users have to manually refresh the page within an interval, like 60 seconds.

We got reports from customers that firefox gave notifications of connection reset, as Graph 1 is. I tested with IE11, Chrome and firefox. It’s found that Chrome and IE will automatically started a new session, while firefox does not. For firefox users, they had to manually refresh the page.

Anti-ddos appliance (A10 TPS, Arbor & HUAWEI secospace) does provide another option to avoid seeing this notification. I understand there must be consideration and good reasons for firefox to design the browser this way. May I ask whether it is possible to adjust a little on firefox to let it automatically re-fresh the page when seeing a RST-ACK please? Guess it’s quite common for firefox users to see the notification when access URLs during DDos attacks, because for A10 TPS & Arbor, the default setting is to reset the first 3-way handshake.

Feel free to let me know if I missed something and got things wrong.

Appreciate it much for your time!

Graph 1 Notification seen on screen


Graph 2 Screen shot of the captured packets


Graph 3 How it works for Arbor TMS to authentication a client by default.

Hello guys, I’m writing to report a disparity between firefox and IE/Chrome when receiving RST-ACK. To mitigate SYN flood attack, one of the countermeasures of anti-ddos appliance is to reset the first 3-way handshake and expect a re-initiated new tcp session from that client. If the real client, browser for example, automatically re-initiate a new session, users won’t feel too much differences except time of delay. If a browser does not automatically start a new session, users have to manually refresh the page within an interval, like 60 seconds. We got reports from customers that firefox gave notifications of connection reset, as Graph 1 is. I tested with IE11, Chrome and firefox. It’s found that Chrome and IE will automatically started a new session, while firefox does not. For firefox users, they had to manually refresh the page. Anti-ddos appliance (A10 TPS, Arbor & HUAWEI secospace) does provide another option to avoid seeing this notification. I understand there must be consideration and good reasons for firefox to design the browser this way. May I ask whether it is possible to adjust a little on firefox to let it automatically re-fresh the page when seeing a RST-ACK please? Guess it’s quite common for firefox users to see the notification when access URLs during DDos attacks, because for A10 TPS & Arbor, the default setting is to reset the first 3-way handshake. Feel free to let me know if I missed something and got things wrong. Appreciate it much for your time! Graph 1 Notification seen on screen Graph 2 Screen shot of the captured packets Graph 3 How it works for Arbor TMS to authentication a client by default.

All Replies (1)

more options

ops, seems packets are not allowed to be uploaded. anyone willing to check my question, kindly reach me at tan.taifeng@oe.21vianet.com.

Best regards,