| Message ID | 20171003071648.5539-1-rosenp@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [LEDE-DEV] firewall3: Enable TCP_ECN by default. | expand |
On 03/10/17 08:16, Rosen Penev wrote: > ECN is used by fq_codel and other AQMs. Kernel 4.2 added a fallback in case of failure, so adjust to kernel default. The kernel default is 2, which is what you've set the firewall3 default to be now as well. 2 accepts ECN on incoming connections but does NOT request it on outbound connections. Therefore the fallback mechanism you mention doesn't actually come in to play at all. Setting the value to '1' permits linux to attempt ECN on both incoming and outgoing connections to/from the router itself (and uses the fallback mechanism) It's tempting to set it to 1 (like I have for the past year+) and be damned :-) > > Signed-off-by: Rosen Penev <rosenp@gmail.com> > --- > defaults.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/defaults.c b/defaults.c > index 85a3750..68e40f5 100644 > --- a/defaults.c > +++ b/defaults.c > @@ -90,6 +90,7 @@ fw3_load_defaults(struct fw3_state *state, struct uci_package *p) > > defs->syn_flood_rate.rate = 25; > defs->syn_flood_rate.burst = 50; > + defs->tcp_ecn = 2; > defs->tcp_syncookies = true; > defs->tcp_window_scaling = true; > defs->custom_chains = true; >
On Tue, 3 Oct 2017, Kevin Darbyshire-Bryant wrote: > It's tempting to set it to 1 (like I have for the past year+) and be damned > :-) So what is the failure mode and how will people who experience failures know what they need to change? David Lang
On 03/10/17 18:22, David Lang wrote: > On Tue, 3 Oct 2017, Kevin Darbyshire-Bryant wrote: > >> It's tempting to set it to 1 (like I have for the past year+) and be >> damned :-) > > So what is the failure mode and how will people who experience failures > know what they need to change? > > David Lang I'd anticipate increased initial connection latency rather than complete failure, suggested by this extract from wiki: Beginning with version 4.1 of the Linux kernel, released in June 2015, the tcp_ecn_fallback mechanism, as specified in RFC 3168 section 6.1.1.1, is enabled by default when ECN is enabled (the value of 1). The fallback mechanism attempts ECN connectivity in the initial setup of outgoing connections, with a graceful fallback for transmissions without ECN capability, mitigating issues with ECN-intolerant hosts or firewalls. https://tools.ietf.org/html/rfc3168 They'd need to add/change if absolutely necessary: /etc/config/firewall config defaults option tcp_ecn '2' <--- from '1' rfc extract: 6.1.1.1. Middlebox Issues ECN introduces the use of the ECN-Echo and CWR flags in the TCP header (as shown in Figure 3) for initialization. There exist some faulty firewalls, load balancers, and intrusion detection systems in the Internet that either drop an ECN-setup SYN packet or respond with a RST, in the belief that such a packet (with these bits set) is a signature for a port-scanning tool that could be used in a denial- of-service attack. Some of the offending equipment has been identified, and a web page [FIXES] contains a list of non-compliant products and the fixes posted by the vendors, where these are available. The TBIT web page [TBIT] lists some of the web servers affected by this faulty equipment. We mention this in this document as a warning to the community of this problem. To provide robust connectivity even in the presence of such faulty equipment, a host that receives a RST in response to the transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. This could result in a TCP connection being established without using ECN. A host that receives no reply to an ECN-setup SYN within the normal SYN retransmission timeout interval MAY resend the SYN and any subsequent SYN retransmissions with CWR and ECE cleared. To overcome normal packet loss that results in the original SYN being lost, the originating host may retransmit one or more ECN-setup SYN packets before giving up and retransmitting the SYN with the CWR and ECE bits cleared. We note that in this case, the following example scenario is possible: (1) Host A: Sends an ECN-setup SYN. (2) Host B: Sends an ECN-setup SYN/ACK, packet is dropped or delayed. (3) Host A: Sends a non-ECN-setup SYN. (4) Host B: Sends a non-ECN-setup SYN/ACK. We note that in this case, following the procedures above, neither Host A nor Host B may set the ECT bit on data packets. Further, an important consequence of the rules for ECN setup and usage in Section 6.1.1 is that a host is forbidden from using the reception of ECT data packets as an implicit signal that the other host is ECN- capable.
On 03/10/17 09:16, Rosen Penev wrote: > ECN is used by fq_codel and other AQMs. Kernel 4.2 added a fallback in case of failure, so adjust to kernel default. > > Signed-off-by: Rosen Penev <rosenp@gmail.com> > --- > defaults.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/defaults.c b/defaults.c > index 85a3750..68e40f5 100644 > --- a/defaults.c > +++ b/defaults.c > @@ -90,6 +90,7 @@ fw3_load_defaults(struct fw3_state *state, struct uci_package *p) > > defs->syn_flood_rate.rate = 25; > defs->syn_flood_rate.burst = 50; > + defs->tcp_ecn = 2; > defs->tcp_syncookies = true; > defs->tcp_window_scaling = true; > defs->custom_chains = true; from kevins reply i gather that this is a no-op setting the default which is already set and that the description is incorrect as there is no fallback when setting 2 as a value. please rework the patch if you still want it applied. John
On Tue, Dec 12, 2017 at 6:07 AM, John Crispin <john@phrozen.org> wrote: > > > On 03/10/17 09:16, Rosen Penev wrote: >> >> ECN is used by fq_codel and other AQMs. Kernel 4.2 added a fallback in >> case of failure, so adjust to kernel default. >> >> Signed-off-by: Rosen Penev <rosenp@gmail.com> >> --- >> defaults.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/defaults.c b/defaults.c >> index 85a3750..68e40f5 100644 >> --- a/defaults.c >> +++ b/defaults.c >> @@ -90,6 +90,7 @@ fw3_load_defaults(struct fw3_state *state, struct >> uci_package *p) >> defs->syn_flood_rate.rate = 25; >> defs->syn_flood_rate.burst = 50; >> + defs->tcp_ecn = 2; >> defs->tcp_syncookies = true; >> defs->tcp_window_scaling = true; >> defs->custom_chains = true; > > > from kevins reply i gather that this is a no-op setting the default which is > already set and that the description is incorrect as there is no fallback > when setting 2 as a value. please rework the patch if you still want it > applied. > > John
resent since gmail sucks. On Tue, Dec 12, 2017 at 10:34 AM, Rosen Penev <rosenp@gmail.com> wrote: > On Tue, Dec 12, 2017 at 6:07 AM, John Crispin <john@phrozen.org> wrote: >> >> >> On 03/10/17 09:16, Rosen Penev wrote: >>> >>> ECN is used by fq_codel and other AQMs. Kernel 4.2 added a fallback in >>> case of failure, so adjust to kernel default. >>> >>> Signed-off-by: Rosen Penev <rosenp@gmail.com> >>> --- >>> defaults.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/defaults.c b/defaults.c >>> index 85a3750..68e40f5 100644 >>> --- a/defaults.c >>> +++ b/defaults.c >>> @@ -90,6 +90,7 @@ fw3_load_defaults(struct fw3_state *state, struct >>> uci_package *p) >>> defs->syn_flood_rate.rate = 25; >>> defs->syn_flood_rate.burst = 50; >>> + defs->tcp_ecn = 2; >>> defs->tcp_syncookies = true; >>> defs->tcp_window_scaling = true; >>> defs->custom_chains = true; >> >> >> from kevins reply i gather that this is a no-op setting the default which is >> already set and that the description is incorrect as there is no fallback >> when setting 2 as a value. please rework the patch if you still want it >> applied. so here's an excerpt from the kernel documentation: tcp_ecn - INTEGER Control use of Explicit Congestion Notification (ECN) by TCP. ECN is used only when both ends of the TCP connection indicate support for it. This feature is useful in avoiding losses due to congestion by allowing supporting routers to signal congestion before having to drop packets. Possible values are: 0 Disable ECN. Neither initiate nor accept ECN. 1 Enable ECN when requested by incoming connections and also request ECN on outgoing connection attempts. 2 Enable ECN when requested by incoming connections but do not request ECN on outgoing connections. Default: 2 tcp_ecn_fallback - BOOLEAN If the kernel detects that ECN connection misbehaves, enable fall back to non-ECN. Currently, this knob implements the fallback from RFC3168, section 6.1.1.1., but we reserve that in future, additional detection mechanisms could be implemented under this knob. The value is not used, if tcp_ecn or per route (or congestion control) ECN settings are disabled. Default: 1 (fallback enabled) For tcp_ecn, I use a value of 1 which causes issues for me when visiting specific websites (I'm looking at you phoronix). This is because ECN is being used on outbound connections. The fallback mechanism (which is enabled by default) only works some of the time. That's why I changed my patch to use a value of 2 which happens to be default. Home connections usually don't go through faulty firewalls or load balancers so this should be fine. > >> >> John
diff --git a/defaults.c b/defaults.c index 85a3750..68e40f5 100644 --- a/defaults.c +++ b/defaults.c @@ -90,6 +90,7 @@ fw3_load_defaults(struct fw3_state *state, struct uci_package *p) defs->syn_flood_rate.rate = 25; defs->syn_flood_rate.burst = 50; + defs->tcp_ecn = 2; defs->tcp_syncookies = true; defs->tcp_window_scaling = true; defs->custom_chains = true;
ECN is used by fq_codel and other AQMs. Kernel 4.2 added a fallback in case of failure, so adjust to kernel default. Signed-off-by: Rosen Penev <rosenp@gmail.com> --- defaults.c | 1 + 1 file changed, 1 insertion(+)