[PATCH 5.11 129/210] mlxsw: spectrum: Fix ECN marking in tunnel decapsulation

From: Ido Schimmel [ Upstream commit 66167c310deb4ac1725f81004fb4b504676ad0bf ] Cited commit changed the behavior of the software data path with regards to the ECN marking of decapsulated packets. However, the commit did not change other callers of __INET_ECN_decapsulate(), namely mlxsw

[PATCH 5.10 118/188] mlxsw: spectrum: Fix ECN marking in tunnel decapsulation

From: Ido Schimmel [ Upstream commit 66167c310deb4ac1725f81004fb4b504676ad0bf ] Cited commit changed the behavior of the software data path with regards to the ECN marking of decapsulated packets. However, the commit did not change other callers of __INET_ECN_decapsulate(), namely mlxsw

[PATCH 5.11 185/254] selftests: forwarding: vxlan_bridge_1d: Fix vxlan ecn decapsulate value

From: Hangbin Liu [ Upstream commit 5aa3c334a449bab24519c4967f5ac2b3304c8dcf ] The ECN bit defines ECT(1) = 1, ECT(0) = 2. So inner 0x02 + outer 0x01 should be inner ECT(0) + outer ECT(1). Based on the description of __INET_ECN_decapsulate, the final decapsulate value should be ECT(1). So fix

[PATCH 5.10 162/221] selftests: forwarding: vxlan_bridge_1d: Fix vxlan ecn decapsulate value

From: Hangbin Liu [ Upstream commit 5aa3c334a449bab24519c4967f5ac2b3304c8dcf ] The ECN bit defines ECT(1) = 1, ECT(0) = 2. So inner 0x02 + outer 0x01 should be inner ECT(0) + outer ECT(1). Based on the description of __INET_ECN_decapsulate, the final decapsulate value should be ECT(1). So fix

[PATCH 5.4 085/111] selftests: forwarding: vxlan_bridge_1d: Fix vxlan ecn decapsulate value

From: Hangbin Liu [ Upstream commit 5aa3c334a449bab24519c4967f5ac2b3304c8dcf ] The ECN bit defines ECT(1) = 1, ECT(0) = 2. So inner 0x02 + outer 0x01 should be inner ECT(0) + outer ECT(1). Based on the description of __INET_ECN_decapsulate, the final decapsulate value should be ECT(1). So fix

[PATCH 5.10 150/199] netfilter: rpfilter: mask ecn bits before fib lookup

From: Guillaume Nault commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream. RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt() treats Not-ECT or ECT(1) packets in a different way than those with ECT(0) or CE. Reproducer: Create two netns, connected with a veth: $ ip

[PATCH 5.4 69/86] netfilter: rpfilter: mask ecn bits before fib lookup

From: Guillaume Nault commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream. RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt() treats Not-ECT or ECT(1) packets in a different way than those with ECT(0) or CE. Reproducer: Create two netns, connected with a veth: $ ip

[PATCH 4.19 44/58] netfilter: rpfilter: mask ecn bits before fib lookup

From: Guillaume Nault commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream. RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt() treats Not-ECT or ECT(1) packets in a different way than those with ECT(0) or CE. Reproducer: Create two netns, connected with a veth: $ ip

[PATCH 4.9 10/45] ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst()

From: Guillaume Nault [ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ] RT_TOS() only clears one of the ECN bits. Therefore, when fib_compute_spec_dst() resorts to a fib lookup, it can return different results depending on the value of the second ECN bit. For example, ECT(0) and ECT

[PATCH 4.19 27/77] ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst()

From: Guillaume Nault [ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ] RT_TOS() only clears one of the ECN bits. Therefore, when fib_compute_spec_dst() resorts to a fib lookup, it can return different results depending on the value of the second ECN bit. For example, ECT(0) and ECT

[PATCH 5.4 33/92] ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst()

From: Guillaume Nault [ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ] RT_TOS() only clears one of the ECN bits. Therefore, when fib_compute_spec_dst() resorts to a fib lookup, it can return different results depending on the value of the second ECN bit. For example, ECT(0) and ECT

[PATCH 5.10 034/145] ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst()

From: Guillaume Nault [ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ] RT_TOS() only clears one of the ECN bits. Therefore, when fib_compute_spec_dst() resorts to a fib lookup, it can return different results depending on the value of the second ECN bit. For example, ECT(0) and ECT

[PATCH 4.14 17/57] ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst()

From: Guillaume Nault [ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ] RT_TOS() only clears one of the ECN bits. Therefore, when fib_compute_spec_dst() resorts to a fib lookup, it can return different results depending on the value of the second ECN bit. For example, ECT(0) and ECT

[PATCH 4.4 07/38] ipv4: Ignore ECN bits for fib lookups in fib_compute_spec_dst()

From: Guillaume Nault [ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ] RT_TOS() only clears one of the ECN bits. Therefore, when fib_compute_spec_dst() resorts to a fib lookup, it can return different results depending on the value of the second ECN bit. For example, ECT(0) and ECT

[PATCH 4.4 15/39] geneve: pull IP header before ECN decapsulation

From: Eric Dumazet IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume IP header is already pulled. geneve does not ensure this yet. Fixing this generically in IP_ECN_decapsulate() and IP6_ECN_decapsulate() is not possible, since callers pass a pointer that might be freed by pskb_may_pull()

[PATCH 4.9 21/45] geneve: pull IP header before ECN decapsulation

From: Eric Dumazet IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume IP header is already pulled. geneve does not ensure this yet. Fixing this generically in IP_ECN_decapsulate() and IP6_ECN_decapsulate() is not possible, since callers pass a pointer that might be freed by pskb_may_pull()

[PATCH 4.14 04/31] geneve: pull IP header before ECN decapsulation

From: Eric Dumazet IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume IP header is already pulled. geneve does not ensure this yet. Fixing this generically in IP_ECN_decapsulate() and IP6_ECN_decapsulate() is not possible, since callers pass a pointer that might be freed by pskb_may_pull()

Re: [PATCH 4.4 15/39] geneve: pull IP header before ECN decapsulation

On Thu, Dec 10, 2020 at 03:32:12PM +0100, Eric Dumazet wrote: > On Thu, Dec 10, 2020 at 3:26 PM Greg Kroah-Hartman > wrote: > > > > From: Eric Dumazet > > > > IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume > > IP header is already pulled. > > > > geneve does not ensure this yet. > > > >

Re: [PATCH 4.4 15/39] geneve: pull IP header before ECN decapsulation

On Thu, Dec 10, 2020 at 03:53:09PM +0100, Eric Dumazet wrote: > On Thu, Dec 10, 2020 at 3:40 PM Greg Kroah-Hartman > wrote: > > > > On Thu, Dec 10, 2020 at 03:38:44PM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Dec 10, 2020 at 03:32:12PM +0100, Eric Dumazet wrote: > > > > On Thu, Dec 10, 2020

Re: [PATCH 4.4 15/39] geneve: pull IP header before ECN decapsulation

On Thu, Dec 10, 2020 at 03:38:44PM +0100, Greg Kroah-Hartman wrote: > On Thu, Dec 10, 2020 at 03:32:12PM +0100, Eric Dumazet wrote: > > On Thu, Dec 10, 2020 at 3:26 PM Greg Kroah-Hartman > > wrote: > > > > > > From: Eric Dumazet > > > > > > IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume >

Re: [PATCH 4.4 15/39] geneve: pull IP header before ECN decapsulation

On Thu, Dec 10, 2020 at 3:40 PM Greg Kroah-Hartman wrote: > > On Thu, Dec 10, 2020 at 03:38:44PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Dec 10, 2020 at 03:32:12PM +0100, Eric Dumazet wrote: > > > On Thu, Dec 10, 2020 at 3:26 PM Greg Kroah-Hartman > > > wrote: > > > > > > > > From: Eric

Re: [PATCH 4.4 15/39] geneve: pull IP header before ECN decapsulation

On Thu, Dec 10, 2020 at 3:26 PM Greg Kroah-Hartman wrote: > > From: Eric Dumazet > > IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume > IP header is already pulled. > > geneve does not ensure this yet. > > Fixing this generically in IP_ECN_decapsulate() and > IP6_ECN_decapsulate() is not

[PATCH 5.9 24/46] geneve: pull IP header before ECN decapsulation

From: Eric Dumazet [ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ] IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume IP header is already pulled. geneve does not ensure this yet. Fixing this generically in IP_ECN_decapsulate() and IP6_ECN_decapsulate() is not possible, since

[PATCH 5.4 22/39] geneve: pull IP header before ECN decapsulation

From: Eric Dumazet [ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ] IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume IP header is already pulled. geneve does not ensure this yet. Fixing this generically in IP_ECN_decapsulate() and IP6_ECN_decapsulate() is not possible, since

[PATCH 4.19 18/32] geneve: pull IP header before ECN decapsulation

From: Eric Dumazet [ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ] IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume IP header is already pulled. geneve does not ensure this yet. Fixing this generically in IP_ECN_decapsulate() and IP6_ECN_decapsulate() is not possible, since

[PATCH 5.7 022/265] tcp: don't ignore ECN CWR on pure ACK

incoming segments with CE set +0.1 <[ect0] . 11001:12001(1000) ack 1001 win 65535 +0.0 <[ce]. 12001:13001(1000) ack 1001 win 65535 +0.0 <[ect0] P. 13001:14001(1000) ack 1001 win 65535 // Stack repsonds with ECN ECHO +0.0 >[noecn] . 1001:1001(0) ack 12001 +0.0 >[noecn] E. 1001:10

[PATCH 4.19 028/131] tcp: don't ignore ECN CWR on pure ACK

incoming segments with CE set +0.1 <[ect0] . 11001:12001(1000) ack 1001 win 65535 +0.0 <[ce]. 12001:13001(1000) ack 1001 win 65535 +0.0 <[ect0] P. 13001:14001(1000) ack 1001 win 65535 // Stack repsonds with ECN ECHO +0.0 >[noecn] . 1001:1001(0) ack 12001 +0.0 >[noecn] E. 1001:10

[PATCH 5.4 018/178] tcp: don't ignore ECN CWR on pure ACK

incoming segments with CE set +0.1 <[ect0] . 11001:12001(1000) ack 1001 win 65535 +0.0 <[ce]. 12001:13001(1000) ack 1001 win 65535 +0.0 <[ect0] P. 13001:14001(1000) ack 1001 win 65535 // Stack repsonds with ECN ECHO +0.0 >[noecn] . 1001:1001(0) ack 12001 +0.0 >[noecn] E. 1001:10

[PATCH 5.6 053/118] wireguard: receive: use tunnel helpers for decapsulating ECN markings

From: "Toke H�iland-J�rgensen" [ Upstream commit eebabcb26ea1e3295704477c6cd4e772c96a9559 ] WireGuard currently only propagates ECN markings on tunnel decap according to the old RFC3168 specification. However, the spec has since been updated in RFC6040 to recommend slightly

[PATCH 4.19 15/63] net/mlx5e: Set ECN for received packets using CQE indication

. On a certain configuration, under congestion, the HW emulates a switch doing ECN marking on packets using ECN indication on the completion descriptor (CQE). The driver needs to set the ECN bits on the packet SKB, such that the network stack can react on that, this commit does that. Needed by downstream

[PATCH 3.18 72/85] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd

[PATCH 3.18 72/85] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd

[PATCH 3.18 70/85] tcp: do not aggressively quick ack after ECN events

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 3.18 70/85] tcp: do not aggressively quick ack after ECN events

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.4 111/124] tcp: do not aggressively quick ack after ECN events

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.4 111/124] tcp: do not aggressively quick ack after ECN events

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.4 113/124] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd (&quo

[PATCH 4.4 113/124] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd (&quo

[PATCH 4.9 15/32] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd (&quo

[PATCH 4.9 15/32] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd (&quo

[PATCH 4.9 13/32] tcp: do not aggressively quick ack after ECN events

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.9 13/32] tcp: do not aggressively quick ack after ECN events

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.17 331/336] tcp: do not aggressively quick ack after ECN events

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.17 331/336] tcp: do not aggressively quick ack after ECN events

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.17 333/336] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd

[PATCH 4.17 333/336] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd

[PATCH 4.14 244/246] tcp: do not aggressively quick ack after ECN events

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.14 244/246] tcp: do not aggressively quick ack after ECN events

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ] ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets

[PATCH 4.14 246/246] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd

[PATCH 4.14 246/246] tcp: add one more quick ack after after ECN events

) made us rethink about our recent patch removing ~16 quick acks after ECN events. tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive. Fixes: 522040ea5fdd

[PATCH 4.15 14/84] tcp: allow TLP in ECN CWR

4.15-stable review patch. If anyone has any objections, please let me know. -- From: Neal Cardwell [ Upstream commit b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd ] This patch enables tail loss probe in cwnd reduction (CWR) state to detect potential losses.

[PATCH 4.15 14/84] tcp: allow TLP in ECN CWR

4.15-stable review patch. If anyone has any objections, please let me know. -- From: Neal Cardwell [ Upstream commit b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd ] This patch enables tail loss probe in cwnd reduction (CWR) state to detect potential losses. Prior to this patch,

[PATCH AUTOSEL for 4.15 15/78] tcp: allow TLP in ECN CWR

From: Neal Cardwell [ Upstream commit b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd ] This patch enables tail loss probe in cwnd reduction (CWR) state to detect potential losses. Prior to this patch, since the sender uses PRR to determine the cwnd in CWR state, the combination

[PATCH AUTOSEL for 4.15 15/78] tcp: allow TLP in ECN CWR

From: Neal Cardwell [ Upstream commit b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd ] This patch enables tail loss probe in cwnd reduction (CWR) state to detect potential losses. Prior to this patch, since the sender uses PRR to determine the cwnd in CWR state, the combination of CWR+PRR plus

Process phantom ECN event in TCP without CWR response

I'm trying to generate phantom ECN events to (manually) decrease the transmission rate/throughput. The signals is meant to be generated and received on a single host. I don't want the ECN event to generate a CWR (Congestion Window Reduced) response to the sender. I'm trying to think of ways

Process phantom ECN event in TCP without CWR response

I'm trying to generate phantom ECN events to (manually) decrease the transmission rate/throughput. The signals is meant to be generated and received on a single host. I don't want the ECN event to generate a CWR (Congestion Window Reduced) response to the sender. I'm trying to think of ways

Process phantom ECN event in TCP without CWR response

I'm trying to generate phantom ECN events to (manually) decrease the transmission rate/throughput. The signals is meant to be generated and received on a single host. I don't want the ECN event to generate a CWR (Congestion Window Reduced) response to the sender. I'm trying to think of ways

Process phantom ECN event in TCP without CWR response

I'm trying to generate phantom ECN events to (manually) decrease the transmission rate/throughput. The signals is meant to be generated and received on a single host. I don't want the ECN event to generate a CWR (Congestion Window Reduced) response to the sender. I'm trying to think of ways

[PATCH 3.2 160/164] tcp: be more strict before accepting ECN negociation

3.2.65-rc1 review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet commit bd14b1b2e29bd6812597f896dde06eaf7c6d2f24 upstream. It appears some networks play bad games with the two bits reserved for ECN. This can trigger false congestion

[PATCH 3.2 160/164] tcp: be more strict before accepting ECN negociation

3.2.65-rc1 review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet eduma...@google.com commit bd14b1b2e29bd6812597f896dde06eaf7c6d2f24 upstream. It appears some networks play bad games with the two bits reserved for ECN. This can trigger false

[PATCH 3.16 338/357] ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding

, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by: Alex Gartrell Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- net/netfilter/ipvs/ip_vs_xmit.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net

[PATCH 3.10 129/143] ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding

, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by: Alex Gartrell Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- net/netfilter/ipvs/ip_vs_xmit.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net

[PATCH 3.14 224/238] ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding

, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by: Alex Gartrell Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- net/netfilter/ipvs/ip_vs_xmit.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net

[PATCH 3.14 224/238] ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding

the behavior of ipv4, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by: Alex Gartrell agartr...@fb.com Acked-by: Julian Anastasov j...@ssi.bg Signed-off-by: Simon Horman ho...@verge.net.au Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- net

[PATCH 3.10 129/143] ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding

the behavior of ipv4, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by: Alex Gartrell agartr...@fb.com Acked-by: Julian Anastasov j...@ssi.bg Signed-off-by: Simon Horman ho...@verge.net.au Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- net

[PATCH 3.16 338/357] ipvs: Maintain all DSCP and ECN bits for ipv6 tun forwarding

the behavior of ipv4, though whether or not we should reflect ECN bits may be up for debate. Signed-off-by: Alex Gartrell agartr...@fb.com Acked-by: Julian Anastasov j...@ssi.bg Signed-off-by: Simon Horman ho...@verge.net.au Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org --- net

[ 67/85] ipv6: GRO should be ECN friendly

3.6-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 51ec04038c113a811b177baa85d293feff9ce995 ] IPv4 side of the problem was addressed in commit a9e050f4e7f9d (net: tcp: GRO should be ECN friendly) This patch

[ 67/85] ipv6: GRO should be ECN friendly

3.6-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet eduma...@google.com [ Upstream commit 51ec04038c113a811b177baa85d293feff9ce995 ] IPv4 side of the problem was addressed in commit a9e050f4e7f9d (net: tcp: GRO should be ECN

Re: FYI: ECN approved as Standard

On Thu, Jun 14, 2001 at 01:33:53PM +0200, Anders Peter Fugmann wrote: > Great to hear, but I cannot find anything that backs it up. > I really want to see the final RFC. > > Perhaps you could send me an URL pointing to it? Usually takes a few days until the RFC editor will announce and publish

Re: FYI: ECN approved as Standard

Hi Jamal Great to hear, but I cannot find anything that backs it up. I really want to see the final RFC. Perhaps you could send me an URL pointing to it? TIA Anders Fugmann jamal wrote: > > The IESG approved ECN as a proposed standard on the 12th of June. > That means as of no

Re: FYI: ECN approved as Standard

Hi Jamal Great to hear, but I cannot find anything that backs it up. I really want to see the final RFC. Perhaps you could send me an URL pointing to it? TIA Anders Fugmann jamal wrote: The IESG approved ECN as a proposed standard on the 12th of June. That means as of now, anyone

Re: FYI: ECN approved as Standard

On Thu, Jun 14, 2001 at 01:33:53PM +0200, Anders Peter Fugmann wrote: Great to hear, but I cannot find anything that backs it up. I really want to see the final RFC. Perhaps you could send me an URL pointing to it? Usually takes a few days until the RFC editor will announce and publish the

FYI: ECN approved as Standard

The IESG approved ECN as a proposed standard on the 12th of June. That means as of now, anyone blocking ECN bits is considered to be blaspheming. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTE

FYI: ECN approved as Standard

The IESG approved ECN as a proposed standard on the 12th of June. That means as of now, anyone blocking ECN bits is considered to be blaspheming. cheers, jamal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo

Re: ECN is on!

Rogier Wolff wrote: > The "we'll turn it on in February" warning is worth NOTHING in this > situation: February comes and goes. March comes and goes. Everybody > who read the warning will think: Ok, so I must be fine. > > A warning of the form: "ECN will go on

Re: ECN is on!

Rogier Wolff wrote: The we'll turn it on in February warning is worth NOTHING in this situation: February comes and goes. March comes and goes. Everybody who read the warning will think: Ok, so I must be fine. A warning of the form: ECN will go on as soon as this message clears the queues

Re: ECN is on!

Folks, herewith I declare this topic ("ECN is on") TABOO, if you want to continue discussing it, do that at linux-kernel WITH NEW TOPIC. My original message had reply-to pointing to linux-kernel, but all it takes is single person to ignore that... Spare the other

Re: ECN is on!

Folks, herewith I declare this topic (ECN is on) TABOO, if you want to continue discussing it, do that at linux-kernel WITH NEW TOPIC. My original message had reply-to pointing to linux-kernel, but all it takes is single person to ignore that... Spare the other lists, my

Re: ECN is on!

Richard Gooch <[EMAIL PROTECTED]> writes: > Sure, Dave is being bloody-minded, but that's the only way we'll see > people get off their fat, lazy asses and fix their broken systems. > In fact, hopefully he's still in a dark mood, and he may take up the > suggestion to bounce mails of the

Re: Final Warning [ was: ECN is on! ]

On Tue, May 22, 2001 at 11:55:59AM -0500, Joe Barr wrote: > What is ECN? Is it the reason SNORT has started this lately: http://vger.kernel.org/ Follow the links, and you will get an exellent answer. > > Active System Attack Alerts > =-=-=-=-=-=-=-=-=-=-=-=-=-= > May 2

Re: ECN is on!

FOLKS, I HAVE ALL THE TIME USED 'Reply-To:' HEADER POINTING TO linux-kernel -- INSTEAD OF ALL THE LISTS... If you want to continue this, do it there. (Before I decide to taboo "Re: ECN is on!" subject line..) On Tue, May 22, 2001 at 12:23:29PM -0400, Richard Gooch wrote:

Re: Final Warning [ was: ECN is on! ]

What is ECN? Is it the reason SNORT has started this lately: Active System Attack Alerts =-=-=-=-=-=-=-=-=-=-=-=-=-= May 22 10:11:18 pooh snort: spp_portscan: PORTSCAN DETECTED from 199.183.24.194 (STEALTH) May 22 10:11:22 pooh snort: spp_portscan: portscan status from 199.183.24.194: 1

RE: ECN is on!

PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: ECN is on! Rogier Wolff wrote: > The "we'll turn it on in February" warning is worth NOTHING in this > situation: February comes and goes. March comes and goes. Everybody > who read the warning will t

Re: ECN is on!

Tony Hoyle writes: > Richard Gooch wrote: > > > In fact, hopefully he's still in a dark mood, and he may take up the > > suggestion to bounce mails of the following type: > > - MIME encoded > > - HTML encoded > > - quoted printables (those stupid "=20" things are particuarly hard to > > read).

Re: ECN is on!

Matti Aarnio writes: > On Tue, May 22, 2001 at 09:06:25AM -0400, Richard Gooch wrote: > ... > > Sure, Dave is being bloody-minded, but that's the only way we'll see > > people get off their fat, lazy asses and fix their broken systems. > > In fact, hopefully he's still in a dark mood, and he may

Re: ECN is on!

ouncement, I updated the FAQ > to reflect that we're now running ECN. > > People have had plenty of warning. Think of it as a bonus that it > didn't happen back in February. They've had an extra 3 months to sort > something out. The "we'll turn it on in February" warning is wort

Re: ECN is on!

On Tue, May 22, 2001 at 05:00:22PM +0100, Tony Hoyle wrote: > > suggestion to bounce mails of the following type: > > - MIME encoded > > - HTML encoded > > - quoted printables (those stupid "=20" things are particuarly hard to > > read). > > Surely it'd be better to get the list to filter them

Re: ECN is on!

On Tue, May 22, 2001 at 09:06:25AM -0400, Richard Gooch wrote: ... > Sure, Dave is being bloody-minded, but that's the only way we'll see > people get off their fat, lazy asses and fix their broken systems. > In fact, hopefully he's still in a dark mood, and he may take up the > suggestion to

Re: ECN is on!

Richard Gooch wrote: > In fact, hopefully he's still in a dark mood, and he may take up the > suggestion to bounce mails of the following type: > - MIME encoded > - HTML encoded > - quoted printables (those stupid "=20" things are particuarly hard to > read). Surely it'd be better to get the

Re: ECN is on!

Brent D. Norris writes: > > I veto, the whole point of moving to ECN was to make a statement and > > get people to fix their kit. > > > > We will remove these people, that's all. > > Isn't this a problem though because the messge saying that ECN was > enabled was

Re: ECN is on!

Alan Cox writes: > > Matti Aarnio writes: > > > I am contemplating to periodically turn off the ECN bit to > > > let email out, but DaveM has veto there. > > > > I veto, the whole point of moving to ECN was to make a statement and > > get people

Re: Final Warning [ was: ECN is on! ]

Folks, don't speculate. You are late anyway. We just had ECN off for two hours, and all sites which didn't commit harakiri at their firewalls ("bad TCP frame from that address, I will place that source into dead list") now either got their message, or are having some

Final Warning [ was: ECN is on! ]

e-enabled on June 10th or something, and everyone must >do thus and so or they will break on that day? > >Vague things like "it'll be turned on real soon now" or ASAP really mean >"never" since admins always have things with real deadlines at the top >of their list.

Re: ECN is on!

"David S. Miller" wrote: > > Matti Aarnio writes: > > I am contemplating to periodically turn off the ECN bit to > > let email out, but DaveM has veto there. > > I veto, the whole point of moving to ECN was to make a statement and > get people

Re: ECN is on!

Matti Aarnio <[EMAIL PROTECTED]> writes: > ... and immediately I have been able to verify a bunch of > domains/servers which won't get thru when incoming connection > has ECN. As a matter of interest, are you also noting how many actually negotiate ECN rather than si

Re: ECN is on!

> I veto, the whole point of moving to ECN was to make a statement and > get people to fix their kit. > Isn't this a problem though because the messge saying that ECN was enabled was set after ECN was enabled? Thus these people have no idea what is going on and they probably won't

Re: ECN is on!

On Tue, May 22, 2001 at 01:10:31PM +0300, Matti Aarnio wrote: > This list is NOT exhaustive of domains with problems, it > primarily lists only those who are subscribers of linux-kernel, > and thus accumulated (al lot) more than 1 email with "connection > timed out" status into vger's queue. >

Re: ECN is on!

> Matti Aarnio writes: > > I am contemplating to periodically turn off the ECN bit to > > let email out, but DaveM has veto there. > > I veto, the whole point of moving to ECN was to make a statement and > get people to fix their kit. > > We will remove these p

Re: ECN is on!

Matti Aarnio writes: > I am contemplating to periodically turn off the ECN bit to > let email out, but DaveM has veto there. I veto, the whole point of moving to ECN was to make a statement and get people to fix their kit. We will remove these people, that's all. Later, David S.

ECN is on!

... and immediately I have been able to verify a bunch of domains/servers which won't get thru when incoming connection has ECN.I tested all of these with Linux running ECN, and Solaris 2.6 without ECN. When Solaris got connection, and ECN-Linux didn't, domain and its server got listed

  1   2   3   4   5   6   7   8   >