Re: [LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

[Rosen Penev]

resent since gmail sucks.

On Tue, Dec 12, 2017 at 10:34 AM, Rosen Penev  wrote:
> On Tue, Dec 12, 2017 at 6:07 AM, John Crispin  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 
>>> ---
>>>   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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

[Rosen Penev]

On Tue, Dec 12, 2017 at 6:07 AM, John Crispin  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 
>> ---
>>   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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

[John Crispin]

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 
---
  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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

[Kevin Darbyshire-Bryant]

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.



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

[David Lang]

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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

[Kevin Darbyshire-Bryant]

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 
---
  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;



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev