Bug#782515: [PATCH stable 3.10-3.16] tcp: Fix crash in TCP Fast Open
On Wed, 2015-04-15 at 19:00 +0100, Ben Hutchings wrote:
Commit 355a901e6cf1 (tcp: make connect() mem charging friendly)
changed tcp_send_syn_data() to perform an open-coded copy of the 'syn'
skb rather than using skb_copy_expand().
The open-coded copy does not cover the skb_shared_info::gso_segs
field, so in the new skb it is left set to 0. When this commit was
backported into stable branches between 3.10.y and 3.16.7-ckty
inclusive, it triggered the BUG() in tcp_transmit_skb().
Since Linux 3.18 the GSO segment count is kept in the
tcp_skb_cb::tcp_gso_segs field and tcp_send_syn_data() does copy the
tcp_skb_cb structure to the new skb, so mainline and newer stable
branches are not affected.
Set skb_shared_info::gso_segs to the correct value of 1.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
net/ipv4/tcp_output.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index d5457e4..1ea0a07 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2992,6 +2992,7 @@ static int tcp_send_syn_data(struct sock *sk, struct
sk_buff *syn)
goto fallback;
syn_data-ip_summed = CHECKSUM_PARTIAL;
memcpy(syn_data-cb, syn-cb, sizeof(syn-cb));
+ skb_shinfo(syn_data)-gso_segs = 1;
if (unlikely(memcpy_fromiovecend(skb_put(syn_data, space),
fo-data-msg_iov, 0, space))) {
kfree_skb(syn_data);
Looks goot to me, thanks Ben !
Acked-by: Eric Dumazet eduma...@google.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782515: [stable regression] tcp: make connect() mem charging friendly
On Tue, 2015-04-14 at 08:32 +0100, Ben Hutchings wrote: Commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a (tcp: make connect() mem charging friendly) was backported to various stable branches: v3.10.73: e64a85197b3f tcp: make connect() mem charging friendly v3.12.40: d06381e8aac5 tcp: make connect() mem charging friendly v3.14.37: 5a8e8f482b4a tcp: make connect() mem charging friendly v3.18.11: e8f117f002ca tcp: make connect() mem charging friendly v3.13.11-ckt19: de023863df9d tcp: make connect() mem charging friendly v3.16.7-ckt9: bea5f6ef9fcb tcp: make connect() mem charging friendly On the 3.16 branch, this has resulted in a regression for TCP Fast Open: https://bugs.debian.org/782515. The BUG() at the top of tcp_transmit_skb() fires as tcp_skb_pcount(skb) == 0. tcp_send_syn_data() does: memcpy(syn_data-cb, syn-cb, sizeof(syn-cb)); Since commit cd7d8498c9a5 (tcp: change tcp_skb_pcount() location) this is sufficient to set the GSO segment count correctly. But in older branches ( 3.18) the GSO segment count in skb_shared_info is used and is no longer copied by tcp_send_syn_data(). All the versions listed above, except v3.18.11, appear to have suffered this regression. Ben. Hi Ben Sorry to ear that. Have you already fixed this, or are you asking for help ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708995: iptables firewall is dropping GRO'd packets
On Tue, 2013-05-21 at 14:55 +0200, Jiri Pirko wrote: This is looking good to me. On my test machine it makes tbf work correctly with gso packets. I worked on similar patch (enqueue path) myself some time ago but I got distracted by other tasks. Yes, I understood this. Do you plan to submit this patch? Of course I will, when correctly tested. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708995: iptables firewall is dropping GRO'd packets
On Tue, 2013-05-21 at 01:28 +0100, Ben Hutchings wrote: I'm seeing packet loss when forwarding from a LAN to PPP, whenever GRO kicks in on the LAN interface. On Mon, 2013-05-20 at 05:48 +0100, Ben Hutchings wrote: [...] The Windows system is connected to the LAN interface (int0). Turning off GRO on this interface works around the problem. But since GRO is on by default, it clearly ought to work properly with iptables. I'll try to work out where the drops are occurring, but the perf net_dropmonitor script is also broken... [...] I've fixed that script and now I can see that it's not iptables but tbf_enqueue() that is dropping the GRO'd packets. I do traffic-shaping on the PPP link like this: tc qdisc replace dev ppp0 root tbf rate 420kbit latency 50ms burst 1540 The local TCP will never generate an skb larger than the burst size because it knows the PPP interface can't do GSO or TSO. And the wifi network doesn't seem to be fast enough for GRO to have much of an effect. But a peer on the wired network can trigger GRO and this produces an skb that exceeds the burst size. Is this a bug in sch_tbf, or should I accept it as a limitation? It seems like it should do GSO on entry to the queue if necessary. This has been discussed on netdev this year. Jiri Pirko was working on this. (thread : tbf: take into account gso skbs) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708995: iptables firewall is dropping GRO'd packets
On Mon, 2013-05-20 at 17:53 -0700, Eric Dumazet wrote:
On Tue, 2013-05-21 at 01:28 +0100, Ben Hutchings wrote:
I'm seeing packet loss when forwarding from a LAN to PPP, whenever GRO
kicks in on the LAN interface.
On Mon, 2013-05-20 at 05:48 +0100, Ben Hutchings wrote:
[...]
The Windows system is connected to the LAN interface (int0). Turning
off GRO on this interface works around the problem. But since GRO is
on by default, it clearly ought to work properly with iptables.
I'll try to work out where the drops are occurring, but the
perf net_dropmonitor script is also broken...
[...]
I've fixed that script and now I can see that it's not iptables but
tbf_enqueue() that is dropping the GRO'd packets. I do traffic-shaping
on the PPP link like this:
tc qdisc replace dev ppp0 root tbf rate 420kbit latency 50ms burst 1540
The local TCP will never generate an skb larger than the burst size
because it knows the PPP interface can't do GSO or TSO. And the wifi
network doesn't seem to be fast enough for GRO to have much of an
effect. But a peer on the wired network can trigger GRO and this
produces an skb that exceeds the burst size.
Is this a bug in sch_tbf, or should I accept it as a limitation? It
seems like it should do GSO on entry to the queue if necessary.
This has been discussed on netdev this year.
Jiri Pirko was working on this.
(thread : tbf: take into account gso skbs)
I have tested the following (net-next) patch
diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
index c8388f3..a132620 100644
--- a/net/sched/sch_tbf.c
+++ b/net/sched/sch_tbf.c
@@ -116,14 +116,50 @@ struct tbf_sched_data {
struct qdisc_watchdog watchdog; /* Watchdog timer */
};
+
+static int tbf_segment(struct sk_buff *skb, struct Qdisc *sch, struct Qdisc
*child)
+{
+ struct sk_buff *segs, *nskb;
+ netdev_features_t features = netif_skb_features(skb);
+ int ret, nb;
+
+ segs = skb_gso_segment(skb, features ~NETIF_F_GSO_MASK);
+
+ if (IS_ERR_OR_NULL(segs))
+ return qdisc_reshape_fail(skb, sch);
+
+ nb = 0;
+ while (segs) {
+ nskb = segs-next;
+ segs-next = NULL;
+ qdisc_skb_cb(segs)-pkt_len = segs-len;
+
+ ret = qdisc_enqueue(segs, child);
+ if (ret != NET_XMIT_SUCCESS) {
+ if (net_xmit_drop_count(ret))
+ sch-qstats.drops++;
+ } else {
+ nb++;
+ }
+ segs = nskb;
+ }
+ sch-q.qlen += nb;
+ if (nb 1)
+ qdisc_tree_decrease_qlen(sch, 1 - nb);
+ consume_skb(skb);
+ return nb 0 ? NET_XMIT_SUCCESS : NET_XMIT_DROP;
+}
+
static int tbf_enqueue(struct sk_buff *skb, struct Qdisc *sch)
{
struct tbf_sched_data *q = qdisc_priv(sch);
int ret;
- if (qdisc_pkt_len(skb) q-max_size)
+ if (qdisc_pkt_len(skb) q-max_size) {
+ if (skb_is_gso(skb))
+ return tbf_segment(skb, sch, q-qdisc);
return qdisc_reshape_fail(skb, sch);
-
+ }
ret = qdisc_enqueue(skb, q-qdisc);
if (ret != NET_XMIT_SUCCESS) {
if (net_xmit_drop_count(ret))
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
in the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I
can even raise it to 0x3000 and don't see any tcp retransmits. Do you
have an advice on how to size this value (e.g. should we switch to the
windows values)?
This looks like an overflow error...
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index 7e0a822..7965f89 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -1569,18 +1569,17 @@ static u16 atl1e_cal_tdp_req(const struct sk_buff *skb)
{
int i = 0;
u16 tpd_req = 1;
- u16 fg_size = 0;
- u16 proto_hdr_len = 0;
for (i = 0; i skb_shinfo(skb)-nr_frags; i++) {
- fg_size = skb_frag_size(skb_shinfo(skb)-frags[i]);
+ u32 fg_size = skb_frag_size(skb_shinfo(skb)-frags[i]);
+
tpd_req += ((fg_size + MAX_TX_BUF_LEN - 1) MAX_TX_BUF_SHIFT);
}
if (skb_is_gso(skb)) {
if (skb-protocol == htons(ETH_P_IP) ||
(skb_shinfo(skb)-gso_type == SKB_GSO_TCPV6)) {
- proto_hdr_len = skb_transport_offset(skb) +
+ u32 proto_hdr_len = skb_transport_offset(skb) +
tcp_hdrlen(skb);
if (proto_hdr_len skb_headlen(skb)) {
tpd_req += ((skb_headlen(skb) - proto_hdr_len +
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
On Wed, 2013-04-03 at 00:15 +0200, Hannes Frederic Sowa wrote:
On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote:
On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote:
The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN
in the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I
can even raise it to 0x3000 and don't see any tcp retransmits. Do you
have an advice on how to size this value (e.g. should we switch to the
windows values)?
This looks like an overflow error...
Thanks for your input, Eric.
I am limited in my time to work on this today but nontheless just tested
your patch without any of my changes and count a lot of TcpRetransSegs
again. Either there is really some hardware limitation or another
overflow.
Another overflow...
Really I don't understand why people use u16 instead of u32.
u16 is slower most of the time, and more prone to overflows.
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index 7e0a822..48ac487 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -1569,18 +1569,17 @@ static u16 atl1e_cal_tdp_req(const struct sk_buff *skb)
{
int i = 0;
u16 tpd_req = 1;
- u16 fg_size = 0;
- u16 proto_hdr_len = 0;
for (i = 0; i skb_shinfo(skb)-nr_frags; i++) {
- fg_size = skb_frag_size(skb_shinfo(skb)-frags[i]);
+ u32 fg_size = skb_frag_size(skb_shinfo(skb)-frags[i]);
+
tpd_req += ((fg_size + MAX_TX_BUF_LEN - 1) MAX_TX_BUF_SHIFT);
}
if (skb_is_gso(skb)) {
if (skb-protocol == htons(ETH_P_IP) ||
(skb_shinfo(skb)-gso_type == SKB_GSO_TCPV6)) {
- proto_hdr_len = skb_transport_offset(skb) +
+ u32 proto_hdr_len = skb_transport_offset(skb) +
tcp_hdrlen(skb);
if (proto_hdr_len skb_headlen(skb)) {
tpd_req += ((skb_headlen(skb) - proto_hdr_len +
@@ -1670,7 +1669,7 @@ static void atl1e_tx_map(struct atl1e_adapter *adapter,
{
struct atl1e_tpd_desc *use_tpd = NULL;
struct atl1e_tx_buffer *tx_buffer = NULL;
- u16 buf_len = skb_headlen(skb);
+ u32 buf_len = skb_headlen(skb);
u16 map_len = 0;
u16 mapped_len = 0;
u16 hdr_len = 0;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet
Your patch does solve the problem, thanks!
Thanks for testing.
Here is the official patch I submit for review then.
[PATCH] ipsec: be careful of non existing mac headers
Nicollo Belli reported ipsec crashes in case we handle a frame without
mac header (atm in his case)
Before copying mac header, better make sure it is present.
Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809
Reported-by: Niccolò Belli darkba...@linuxsystems.it
Tested-by: Niccolò Belli darkba...@linuxsystems.it
Signed-off-by: Eric Dumazet eric.duma...@gmail.com
---
net/ipv4/xfrm4_mode_beet.c |9 +
net/ipv4/xfrm4_mode_tunnel.c | 10 ++
net/ipv6/xfrm6_mode_beet.c |9 +
net/ipv6/xfrm6_mode_tunnel.c | 10 ++
4 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/xfrm4_mode_beet.c b/net/ipv4/xfrm4_mode_beet.c
index 6341818..d3451f6 100644
--- a/net/ipv4/xfrm4_mode_beet.c
+++ b/net/ipv4/xfrm4_mode_beet.c
@@ -111,10 +111,11 @@ static int xfrm4_beet_input(struct xfrm_state *x, struct
sk_buff *skb)
skb_push(skb, sizeof(*iph));
skb_reset_network_header(skb);
- memmove(skb-data - skb-mac_len, skb_mac_header(skb),
- skb-mac_len);
- skb_set_mac_header(skb, -skb-mac_len);
-
+ if (skb_mac_header_was_set(skb)) {
+ memmove(skb-data - skb-mac_len, skb_mac_header(skb),
+ skb-mac_len);
+ skb_set_mac_header(skb, -skb-mac_len);
+ }
xfrm4_beet_make_header(skb);
iph = ip_hdr(skb);
diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
index 534972e..a646f30 100644
--- a/net/ipv4/xfrm4_mode_tunnel.c
+++ b/net/ipv4/xfrm4_mode_tunnel.c
@@ -66,7 +66,6 @@ static int xfrm4_mode_tunnel_output(struct xfrm_state *x,
struct sk_buff *skb)
static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
{
- const unsigned char *old_mac;
int err = -EINVAL;
if (XFRM_MODE_SKB_CB(skb)-protocol != IPPROTO_IPIP)
@@ -84,9 +83,12 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x,
struct sk_buff *skb)
if (!(x-props.flags XFRM_STATE_NOECN))
ipip_ecn_decapsulate(skb);
- old_mac = skb_mac_header(skb);
- skb_set_mac_header(skb, -skb-mac_len);
- memmove(skb_mac_header(skb), old_mac, skb-mac_len);
+ if (skb_mac_header_was_set(skb)) {
+ const unsigned char *old_mac = skb_mac_header(skb);
+
+ skb_set_mac_header(skb, -skb-mac_len);
+ memmove(skb_mac_header(skb), old_mac, skb-mac_len);
+ }
skb_reset_network_header(skb);
err = 0;
diff --git a/net/ipv6/xfrm6_mode_beet.c b/net/ipv6/xfrm6_mode_beet.c
index a81ce94..74c4b92 100644
--- a/net/ipv6/xfrm6_mode_beet.c
+++ b/net/ipv6/xfrm6_mode_beet.c
@@ -80,7 +80,6 @@ static int xfrm6_beet_output(struct xfrm_state *x, struct
sk_buff *skb)
static int xfrm6_beet_input(struct xfrm_state *x, struct sk_buff *skb)
{
struct ipv6hdr *ip6h;
- const unsigned char *old_mac;
int size = sizeof(struct ipv6hdr);
int err;
@@ -91,10 +90,12 @@ static int xfrm6_beet_input(struct xfrm_state *x, struct
sk_buff *skb)
__skb_push(skb, size);
skb_reset_network_header(skb);
- old_mac = skb_mac_header(skb);
- skb_set_mac_header(skb, -skb-mac_len);
- memmove(skb_mac_header(skb), old_mac, skb-mac_len);
+ if (skb_mac_header_was_set(skb)) {
+ const unsigned char *old_mac = skb_mac_header(skb);
+ skb_set_mac_header(skb, -skb-mac_len);
+ memmove(skb_mac_header(skb), old_mac, skb-mac_len);
+ }
xfrm6_beet_make_header(skb);
ip6h = ipv6_hdr(skb);
diff --git a/net/ipv6/xfrm6_mode_tunnel.c b/net/ipv6/xfrm6_mode_tunnel.c
index 261e6e6..edb7091 100644
--- a/net/ipv6/xfrm6_mode_tunnel.c
+++ b/net/ipv6/xfrm6_mode_tunnel.c
@@ -63,7 +63,6 @@ static int xfrm6_mode_tunnel_output(struct xfrm_state *x,
struct sk_buff *skb)
static int xfrm6_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
{
int err = -EINVAL;
- const unsigned char *old_mac;
if (XFRM_MODE_SKB_CB(skb)-protocol != IPPROTO_IPV6)
goto out;
@@ -80,9 +79,12 @@ static int xfrm6_mode_tunnel_input(struct xfrm_state *x,
struct sk_buff *skb)
if (!(x-props.flags XFRM_STATE_NOECN))
ipip6_ecn_decapsulate(skb);
- old_mac = skb_mac_header(skb);
- skb_set_mac_header(skb, -skb-mac_len);
- memmove(skb_mac_header(skb), old_mac, skb-mac_len);
+ if (skb_mac_header_was_set(skb)) {
+ const unsigned char *old_mac = skb_mac_header(skb);
+
+ skb_set_mac_header(skb, -skb-mac_len);
+ memmove(skb_mac_header(skb), old_mac, skb-mac_len);
+ }
skb_reset_network_header(skb);
err = 0;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet
Le jeudi 23 février 2012 à 15:36 +0100, Eric Dumazet a écrit : [PATCH] ipsec: be careful of non existing mac headers Nicollo Belli reported ipsec crashes in case we handle a frame without mac header (atm in his case) Oops sorry for your name being mangled in changelog, its Niccolò as correctly spelled in the Reported-by and Tested-by tags -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet
Le jeudi 23 février 2012 à 15:11 -0500, David Miller a écrit : Three instances of the same piece of code, maybe a helper function is appropriate at that point? :-) You might even get ambitious and add a big comment to that helper function explaining the situation. I did have this idea but refrained because this kind of things is harder to backport to stable kernels. I'll make a cleanup in net-next if you agree ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet
Le jeudi 23 février 2012 à 15:23 -0500, David Miller a écrit : I think the work to backport is equal whether you use a helper function or not. Heck, use an inline function so you don't have to worry about module exports or any details like that. Besides, I'm the one who likely has to backport this thing, so... :-) Great, I'll send an updated version in a couple of minutes ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660804: [PATCH V2] ipsec: be careful of non existing mac headers
Niccolo Belli reported ipsec crashes in case we handle a frame without
mac header (atm in his case)
Before copying mac header, better make sure it is present.
Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809
Reported-by: Niccolò Belli darkba...@linuxsystems.it
Tested-by: Niccolò Belli darkba...@linuxsystems.it
Signed-off-by: Eric Dumazet eric.duma...@gmail.com
---
V2: added skb_mac_header_rebuild() helper as David suggested.
include/linux/skbuff.h | 10 ++
net/ipv4/xfrm4_mode_beet.c |5 +
net/ipv4/xfrm4_mode_tunnel.c |6 ++
net/ipv6/xfrm6_mode_beet.c |6 +-
net/ipv6/xfrm6_mode_tunnel.c |6 ++
5 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 50db9b0..ae86ade 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1465,6 +1465,16 @@ static inline void skb_set_mac_header(struct sk_buff
*skb, const int offset)
}
#endif /* NET_SKBUFF_DATA_USES_OFFSET */
+static inline void skb_mac_header_rebuild(struct sk_buff *skb)
+{
+ if (skb_mac_header_was_set(skb)) {
+ const unsigned char *old_mac = skb_mac_header(skb);
+
+ skb_set_mac_header(skb, -skb-mac_len);
+ memmove(skb_mac_header(skb), old_mac, skb-mac_len);
+ }
+}
+
static inline int skb_checksum_start_offset(const struct sk_buff *skb)
{
return skb-csum_start - skb_headroom(skb);
diff --git a/net/ipv4/xfrm4_mode_beet.c b/net/ipv4/xfrm4_mode_beet.c
index 6341818..e3db3f9 100644
--- a/net/ipv4/xfrm4_mode_beet.c
+++ b/net/ipv4/xfrm4_mode_beet.c
@@ -110,10 +110,7 @@ static int xfrm4_beet_input(struct xfrm_state *x, struct
sk_buff *skb)
skb_push(skb, sizeof(*iph));
skb_reset_network_header(skb);
-
- memmove(skb-data - skb-mac_len, skb_mac_header(skb),
- skb-mac_len);
- skb_set_mac_header(skb, -skb-mac_len);
+ skb_mac_header_rebuild(skb);
xfrm4_beet_make_header(skb);
diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
index 534972e..ed4bf11 100644
--- a/net/ipv4/xfrm4_mode_tunnel.c
+++ b/net/ipv4/xfrm4_mode_tunnel.c
@@ -66,7 +66,6 @@ static int xfrm4_mode_tunnel_output(struct xfrm_state *x,
struct sk_buff *skb)
static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
{
- const unsigned char *old_mac;
int err = -EINVAL;
if (XFRM_MODE_SKB_CB(skb)-protocol != IPPROTO_IPIP)
@@ -84,10 +83,9 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x,
struct sk_buff *skb)
if (!(x-props.flags XFRM_STATE_NOECN))
ipip_ecn_decapsulate(skb);
- old_mac = skb_mac_header(skb);
- skb_set_mac_header(skb, -skb-mac_len);
- memmove(skb_mac_header(skb), old_mac, skb-mac_len);
skb_reset_network_header(skb);
+ skb_mac_header_rebuild(skb);
+
err = 0;
out:
diff --git a/net/ipv6/xfrm6_mode_beet.c b/net/ipv6/xfrm6_mode_beet.c
index a81ce94..9949a35 100644
--- a/net/ipv6/xfrm6_mode_beet.c
+++ b/net/ipv6/xfrm6_mode_beet.c
@@ -80,7 +80,6 @@ static int xfrm6_beet_output(struct xfrm_state *x, struct
sk_buff *skb)
static int xfrm6_beet_input(struct xfrm_state *x, struct sk_buff *skb)
{
struct ipv6hdr *ip6h;
- const unsigned char *old_mac;
int size = sizeof(struct ipv6hdr);
int err;
@@ -90,10 +89,7 @@ static int xfrm6_beet_input(struct xfrm_state *x, struct
sk_buff *skb)
__skb_push(skb, size);
skb_reset_network_header(skb);
-
- old_mac = skb_mac_header(skb);
- skb_set_mac_header(skb, -skb-mac_len);
- memmove(skb_mac_header(skb), old_mac, skb-mac_len);
+ skb_mac_header_rebuild(skb);
xfrm6_beet_make_header(skb);
diff --git a/net/ipv6/xfrm6_mode_tunnel.c b/net/ipv6/xfrm6_mode_tunnel.c
index 261e6e6..9f2095b 100644
--- a/net/ipv6/xfrm6_mode_tunnel.c
+++ b/net/ipv6/xfrm6_mode_tunnel.c
@@ -63,7 +63,6 @@ static int xfrm6_mode_tunnel_output(struct xfrm_state *x,
struct sk_buff *skb)
static int xfrm6_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
{
int err = -EINVAL;
- const unsigned char *old_mac;
if (XFRM_MODE_SKB_CB(skb)-protocol != IPPROTO_IPV6)
goto out;
@@ -80,10 +79,9 @@ static int xfrm6_mode_tunnel_input(struct xfrm_state *x,
struct sk_buff *skb)
if (!(x-props.flags XFRM_STATE_NOECN))
ipip6_ecn_decapsulate(skb);
- old_mac = skb_mac_header(skb);
- skb_set_mac_header(skb, -skb-mac_len);
- memmove(skb_mac_header(skb), old_mac, skb-mac_len);
skb_reset_network_header(skb);
+ skb_mac_header_rebuild(skb);
+
err = 0;
out:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet
Le jeudi 23 février 2012 à 01:59 +0100, Niccolò Belli a écrit : Hi, The bug is still present in latest 3.2.7 vanilla kernel. I wasted the whole day debugging that damn thing and I finally discovered the root cause. The problem is with my Traverse Solos multi-port ADSL2+ PCI card[1] (which has open source drivers included in the kernel) when using RFC 2684 routed. I have two adsl lines, the first one connected using RFC 2684 routed, the second one using PPPoA. If I create a vpn toward the PPPoA line it works flawlessly, while if I create a vpn toward the RFC 2684 routed line the whole system hangs in a kernel panic (with both 2.6.32.54 and 3.2.7). I really don't know how to fix it and I need to setup that damn ipsec vpn :( This is the bug on bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=42809 Niccolò [1]http://www.traverse.com.au/productview.php?product_id=116 Which driver handles this Traverse Solos card ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet
Le jeudi 23 février 2012 à 02:38 +0100, Eric Dumazet a écrit : Which driver handles this Traverse Solos card ? If br2684_push() is used, it seems it lacks proper call to skb_reset_mac_header(skb) in paths where eth_type_trans() is not called. Later in xfrm4_mode_tunnel_input() we crash because we assume skb_mac_header() is valid. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable
Le lundi 30 janvier 2012 à 12:51 +0300, Denis Kirjanov a écrit :
I'll check this out. After kernel.org was cracked I've missed
@kernel.org mail account.
At first glance, start_tx() is racy against TX completion.
It does :
if (np-cur_tx - np-dirty_tx TX_QUEUE_LEN - 1
!netif_queue_stopped(dev)) {
/* do nothing */
} else {
netif_stop_queue (dev);
}
So it can call netif_stop_queue() while TX completion handler did a
cleanup of all queued packets right before.
Note intr_handler() doesnt hold the queue spinlock when it does :
if (netif_queue_stopped(dev)
np-cur_tx - np-dirty_tx TX_QUEUE_LEN - 4) {
/* The ring is no longer full, clear busy flag. */
netif_wake_queue (dev);
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable
Le lundi 30 janvier 2012 à 11:14 +0100, Eric Dumazet a écrit :
Le lundi 30 janvier 2012 à 12:51 +0300, Denis Kirjanov a écrit :
I'll check this out. After kernel.org was cracked I've missed
@kernel.org mail account.
At first glance, start_tx() is racy against TX completion.
It does :
if (np-cur_tx - np-dirty_tx TX_QUEUE_LEN - 1
!netif_queue_stopped(dev)) {
/* do nothing */
} else {
netif_stop_queue (dev);
}
So it can call netif_stop_queue() while TX completion handler did a
cleanup of all queued packets right before.
Note intr_handler() doesnt hold the queue spinlock when it does :
if (netif_queue_stopped(dev)
np-cur_tx - np-dirty_tx TX_QUEUE_LEN - 4) {
/* The ring is no longer full, clear busy flag. */
netif_wake_queue (dev);
}
So I would try following patch :
drivers/net/ethernet/dlink/sundance.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/dlink/sundance.c
b/drivers/net/ethernet/dlink/sundance.c
index 28a3a9b..c671a6c 100644
--- a/drivers/net/ethernet/dlink/sundance.c
+++ b/drivers/net/ethernet/dlink/sundance.c
@@ -1099,11 +1099,13 @@ start_tx (struct sk_buff *skb, struct net_device *dev)
tasklet_schedule(np-tx_tasklet);
/* On some architectures: explicitly flush cache lines here. */
- if (np-cur_tx - np-dirty_tx TX_QUEUE_LEN - 1
- !netif_queue_stopped(dev)) {
- /* do nothing */
- } else {
- netif_stop_queue (dev);
+ if (np-cur_tx - np-dirty_tx = TX_QUEUE_LEN - 1) {
+ unsigned long flags;
+
+ spin_lock_irqsave(np-lock, flags);
+ if (np-cur_tx - np-dirty_tx = TX_QUEUE_LEN - 1)
+ netif_stop_queue(dev);
+ spin_unlock_irqrestore(np-lock, flags);
}
if (netif_msg_tx_queued(np)) {
printk (KERN_DEBUG
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable
Le lundi 30 janvier 2012 à 14:05 +, Ben Hutchings a écrit : Yes, I spotted that. But no descriptors are pushed to the hardware here; that's done in the driver's TX tasklet. Although... maybe that can run immediately when scheduled from here? I've never had to deal with tasklets so I really don't know their semantics. Thats probable on SMP ... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable
Le lundi 30 janvier 2012 à 14:41 +, Ben Hutchings a écrit : On Mon, 2012-01-30 at 15:28 +0100, Eric Dumazet wrote: Le lundi 30 janvier 2012 à 14:05 +, Ben Hutchings a écrit : Yes, I spotted that. But no descriptors are pushed to the hardware here; that's done in the driver's TX tasklet. Although... maybe that can run immediately when scheduled from here? I've never had to deal with tasklets so I really don't know their semantics. Thats probable on SMP ... The bug report is for a UP system running a kernel built with SMP-alternatives. Hmm, TX _completion_ is not run from tasklet but hardware IRQ, this is why I added the spin_lock_irqsave(). Tasklet fires the TX, but hardware IRQ does the TX completion part. This driver is ... interesting :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable
Le lundi 30 janvier 2012 à 15:57 +0100, Eric Dumazet a écrit :
Hmm, TX _completion_ is not run from tasklet but hardware IRQ, this is
why I added the spin_lock_irqsave().
Tasklet fires the TX, but hardware IRQ does the TX completion part.
This driver is ... interesting :)
Oh well, we also must make sure we held np-lock in TX completion when
doing our test to eventually call netif_wake_queue(), I missed it was
released too early.
here is a more complete patch.
diff --git a/drivers/net/ethernet/dlink/sundance.c
b/drivers/net/ethernet/dlink/sundance.c
index 28a3a9b..d5e9472 100644
--- a/drivers/net/ethernet/dlink/sundance.c
+++ b/drivers/net/ethernet/dlink/sundance.c
@@ -1099,11 +1099,13 @@ start_tx (struct sk_buff *skb, struct net_device *dev)
tasklet_schedule(np-tx_tasklet);
/* On some architectures: explicitly flush cache lines here. */
- if (np-cur_tx - np-dirty_tx TX_QUEUE_LEN - 1
- !netif_queue_stopped(dev)) {
- /* do nothing */
- } else {
- netif_stop_queue (dev);
+ if (np-cur_tx - np-dirty_tx = TX_QUEUE_LEN - 1) {
+ unsigned long flags;
+
+ spin_lock_irqsave(np-lock, flags);
+ if (np-cur_tx - np-dirty_tx = TX_QUEUE_LEN - 1)
+ netif_stop_queue(dev);
+ spin_unlock_irqrestore(np-lock, flags);
}
if (netif_msg_tx_queued(np)) {
printk (KERN_DEBUG
@@ -1242,8 +1244,8 @@ static irqreturn_t intr_handler(int irq, void
*dev_instance)
hw_frame_id = ioread8(ioaddr + TxFrameId);
}
+ spin_lock(np-lock);
if (np-pci_dev-revision = 0x14) {
- spin_lock(np-lock);
for (; np-cur_tx - np-dirty_tx 0; np-dirty_tx++) {
int entry = np-dirty_tx % TX_RING_SIZE;
struct sk_buff *skb;
@@ -1267,9 +1269,7 @@ static irqreturn_t intr_handler(int irq, void
*dev_instance)
np-tx_ring[entry].frag[0].addr = 0;
np-tx_ring[entry].frag[0].length = 0;
}
- spin_unlock(np-lock);
} else {
- spin_lock(np-lock);
for (; np-cur_tx - np-dirty_tx 0; np-dirty_tx++) {
int entry = np-dirty_tx % TX_RING_SIZE;
struct sk_buff *skb;
@@ -1286,7 +1286,6 @@ static irqreturn_t intr_handler(int irq, void
*dev_instance)
np-tx_ring[entry].frag[0].addr = 0;
np-tx_ring[entry].frag[0].length = 0;
}
- spin_unlock(np-lock);
}
if (netif_queue_stopped(dev)
@@ -1294,6 +1293,7 @@ static irqreturn_t intr_handler(int irq, void
*dev_instance)
/* The ring is no longer full, clear busy flag. */
netif_wake_queue (dev);
}
+ spin_unlock(np-lock);
/* Abnormal error summary/uncommon events handlers. */
if (intr_status (IntrPCIErr | LinkChange | StatsMax))
netdev_error(dev, intr_status);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650495: linux-image-3.1.0-1-amd64: oops
Le mercredi 30 novembre 2011 à 14:25 +, Ben Hutchings a écrit : On Wed, 2011-11-30 at 03:05 -0600, Jonathan Nieder wrote: Hi Tim, Tim Connors wrote: ** Tainted: PWCO (5633) * Proprietary module has been loaded. * Taint on warning. * Module from drivers/staging has been loaded. * Out-of-tree module has been loaded. Thanks for reporting this, but we're not going to look into it unless you can reproduce it without the nvidia driver. Sorry. If you can reproduce it with the nvidia driver and not without, that's fine too, since in that case we can pass it on to the nvidia driver packagers (who would presumably help you file a report with nvidia). Actually this bug is really obvious (to me). It's this change: commit 4924f44b97a034dbf44c14b709b0b0907ee23f04 Author: Eric Dumazet eric.duma...@gmail.com Date: Mon Jul 4 17:57:10 2011 -0700 b44: use dev_kfree_skb() in b44_tx() Eric didn't take into account that b44_poll() masks IRQs while calling b44_tx(). So we need to revert that (or fix b44_tx() to not do that, as it's unlikely to be necessary). Yes, this was reverted in mainline : 15ac2b08a2fd0f (b44: Use dev_kfree_skb_irq() in b44_tx()) Apparently some people think NAPI must run with IRQ disabled... Oh well... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646063: net: fix route cache rebuilds
Le mardi 08 novembre 2011 à 01:39 +0100, Florian Fuessl a écrit : Unfortunately the system still suffered from two network disconnects starting with the following messages in the kernel log: Nov 7 06:38:41 spozerl kernel: [ 9025.854230] Route hash chain too long! Nov 7 06:38:41 spozerl kernel: [ 9025.854237] Adjust your secret_interval! Nov 7 07:10:53 spozerl kernel: [10953.398869] eth0: 5 rebuilds is over limit, route caching disabled Nov 7 07:10:53 spozerl kernel: [10953.398876] Route hash chain too long! Nov 7 07:10:53 spozerl kernel: [10953.398878] Adjust your secret_interval! Nov 7 07:12:59 spozerl kernel: [11080.006209] dst cache overflow ... Nov 7 07:13:04 spozerl kernel: [11085.007358] __ratelimit: 595 callbacks suppressed Nov 7 07:13:04 spozerl kernel: [11085.007362] dst cache overflow Nov 7 07:13:04 spozerl kernel: [11085.009144] dst cache overflow [...] If patch is already in your kernel, your machine is under stress, and route cache is disabled. You probably need to adjust route cache hash size. grep . /proc/sys/net/ipv4/route/* -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646063: net: fix route cache rebuilds
Le vendredi 21 octobre 2011 à 01:07 +0100, Ben Hutchings a écrit : Eric, do you see any problems with this? Would we need any more follow-up fixes? Hi Ben This patch is probably safe, it should avoid the emergency rebuild trigger.even with few entries in cache, because of one long chain [different TOS values being mapped to the same slot ] But I believe another bug was fixed in 6a2bad70d546cf30 (ipv4: Restart rt_intern_hash after emergency rebuild ) If Florian route cache use is light/normal, this second commit is probably not needed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631945: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler
Le vendredi 29 juillet 2011 à 16:11 +0200, Patrick McHardy a écrit : Yeah, that seems to be the correct fix, thanks for looking into this. Thanks Patrick, here is the official patch submission then ;) [PATCH] sch_sfq: fix sfq_enqueue() commit 8efa88540635 (sch_sfq: avoid giving spurious NET_XMIT_CN signals) forgot to call qdisc_tree_decrease_qlen() to signal upper levels that a packet (from another flow) was dropped, leading to various problems. With help from Michal Soltys and Michal Pokrywka, who did a bisection. Bugzilla ref: https://bugzilla.kernel.org/show_bug.cgi?id=39372 Debian ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631945 Reported-by: Lucas Bocchi lucas.boc...@gmail.com Reported-and-bisected-by: Michal Pokrywka wolfm...@o2.pl Signed-off-by: Eric Dumazet eric.duma...@gmail.com CC: Michal Soltys sol...@ziu.info Acked-by: Patrick McHardy ka...@trash.net --- net/sched/sch_sfq.c |7 ++- 1 files changed, 6 insertions(+), 1 deletion(-) diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c index 4536ee6..2a2d287 100644 --- a/net/sched/sch_sfq.c +++ b/net/sched/sch_sfq.c @@ -410,7 +410,12 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch) /* Return Congestion Notification only if we dropped a packet * from this flow. */ - return (qlen != slot-qlen) ? NET_XMIT_CN : NET_XMIT_SUCCESS; + if (qlen != slot-qlen) + return NET_XMIT_CN; + + /* As we dropped a packet, better let upper stack know this */ + qdisc_tree_decrease_qlen(sch, 1); + return NET_XMIT_SUCCESS; } static struct sk_buff * -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631945: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler
Le vendredi 29 juillet 2011 à 14:29 +0200, Michal Soltys a écrit : On 11-07-15 00:14, Andrew Morton wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). Here: WARN_ON(next_time == 0); From the other thread on netfilter-devel: On 11-07-22 11:58, Michal Pokrywka wrote: After bisecting 2.6.39.1 it turned out that the bug is caused independently by two patches: commit b262a5da755cc6ed0cb4fba230cd9bf4037e1096 sch_sfq: fix peek() implementation and commit 9df49f2bfe862573911a080c75a6d81113c5c81d sch_sfq: avoid giving spurious NET_XMIT_CN signals Reverting these patches makes HFSC work again. This one (upstream 8efa885406359af300d46910642b50ca82c0fe47) seems to be the culprit (does reverting only that one cures the problem ?) It allows SFQ to return success on enqueuing, when the packet really replaced some other packet in some other flow. This confuses outer qdisc (in this particular case HFSC) which thinks new packet was actually added each time such situation happes. Technically speaking, _this_ packet was successfuly enqueued. Returning NET_XMIT_CN or NET_XMIT_SUCCESS should not trigger a bug in caller. This in turn causes additional dequeues and ends with attempt to schedule non-existent packets, and triggers the warning. Then its probably a bug in HFSC : It doesnt understand SFQ lost a packet. I'll take a look, thanks for the report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631945: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler
Le vendredi 29 juillet 2011 à 15:27 +0200, Eric Dumazet a écrit : Le vendredi 29 juillet 2011 à 14:29 +0200, Michal Soltys a écrit : On 11-07-15 00:14, Andrew Morton wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). Here: WARN_ON(next_time == 0); From the other thread on netfilter-devel: On 11-07-22 11:58, Michal Pokrywka wrote: After bisecting 2.6.39.1 it turned out that the bug is caused independently by two patches: commit b262a5da755cc6ed0cb4fba230cd9bf4037e1096 sch_sfq: fix peek() implementation and commit 9df49f2bfe862573911a080c75a6d81113c5c81d sch_sfq: avoid giving spurious NET_XMIT_CN signals Reverting these patches makes HFSC work again. This one (upstream 8efa885406359af300d46910642b50ca82c0fe47) seems to be the culprit (does reverting only that one cures the problem ?) It allows SFQ to return success on enqueuing, when the packet really replaced some other packet in some other flow. This confuses outer qdisc (in this particular case HFSC) which thinks new packet was actually added each time such situation happes. Technically speaking, _this_ packet was successfuly enqueued. Returning NET_XMIT_CN or NET_XMIT_SUCCESS should not trigger a bug in caller. This in turn causes additional dequeues and ends with attempt to schedule non-existent packets, and triggers the warning. Then its probably a bug in HFSC : It doesnt understand SFQ lost a packet. I'll take a look, thanks for the report. Oh well, it seems one qdisc_tree_decrease_qlen(sch, 1) is missing Maybe following patch would help... diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c index 4536ee6..2a2d287 100644 --- a/net/sched/sch_sfq.c +++ b/net/sched/sch_sfq.c @@ -410,7 +410,12 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch) /* Return Congestion Notification only if we dropped a packet * from this flow. */ - return (qlen != slot-qlen) ? NET_XMIT_CN : NET_XMIT_SUCCESS; + if (qlen != slot-qlen) + return NET_XMIT_CN; + + /* as we dropped a packet, better let upper stack know this */ + qdisc_tree_decrease_qlen(sch, 1); + return NET_XMIT_SUCCESS; } static struct sk_buff * -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599816: Nested GRE locking bug
Le lundi 25 octobre 2010 à 12:53 -0700, David Miller a écrit : I'll commit the following to upstream, and submit a combined patch to -stable. net: Increase xmit RECURSION_LIMIT to 10. Three is definitely too low, and we know from reports that GRE tunnels stacked as deeply as 37 levels cause stack overflows, so pick some reasonable value between those two. Signed-off-by: David S. Miller da...@davemloft.net --- net/core/dev.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/core/dev.c b/net/core/dev.c index 78b5a89..2c7da3a 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2213,7 +2213,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q, } static DEFINE_PER_CPU(int, xmit_recursion); -#define RECURSION_LIMIT 3 +#define RECURSION_LIMIT 10 /** * dev_queue_xmit - transmit a buffer Perfect, thanks ! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599816: Nested GRE locking bug
Le mardi 19 octobre 2010 à 01:53 -0700, David Miller a écrit : From: Eric Dumazet eric.duma...@gmail.com Date: Thu, 14 Oct 2010 06:11:59 +0200 net-next-2.6 contains a fix for this, adding the perc_cpu xmit_recursion limit. We might push it to net-2.6 We need to think a bit more about this. We are essentially now saying that one can only configure tunnels 3 levels deep, and no more. I can guarentee you someone out there uses at least 4, perhaps more. And those people will be broken by the new limit. So putting this into net-2.6 with such a low limit will be quite dangerous. Well limit is actually 4, but I get your point ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595265: linux-image-2.6.32-5-686: Nerwork card fails to come up again after suspend
Le lundi 18 octobre 2010 à 23:45 +0200, Francois Romieu a écrit : Ben Hutchings b...@decadent.org.uk : [...] Arnout Boelens reported that his RTL8111/8168B fails to link-up after suspend and resume, both under Debian's kernel based on 2.6.32 and under 2.6.36-rc6. Full details are at http://bugs.debian.org/595265, though the log isn't very informative: [31837.396594] PM: Finishing wakeup. [31837.396597] Restarting tasks ... done. [31840.267267] r8169: eth0: link down Can you suggest how to investigate this further? Something like the patch made by Stanislaw at : https://bugzilla.redhat.com/show_bug.cgi?id=502974 Seems to be down at this moment, patch is also here (and included in 2.6.36-rc8 ) : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=aeb19f6052b5e5c8a24aa444fbff73b84341beac -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599816: Nested GRE locking bug
Le jeudi 14 octobre 2010 à 05:00 +0100, Ben Hutchings a écrit :
Beatrice Barbe reported a reproducible crash after creating large
numbers of nested GRE tunnels and then pinging with the source address
forced. I was able to reproduce this using net-2.6. I'm attaching the
kernel config I used and a script to reproduce this based on the script
she provided. The magic number of tunnels to create is apparently 37.
With lockdep enabled, I get the following output:
Thats a known problem, actually, called stack exhaustion :)
net-next-2.6 contains a fix for this, adding the perc_cpu xmit_recursion
limit. We might push it to net-2.6
Thanks
commit 745e20f1b626b1be4b100af5d4bf7b3439392f8f
Author: Eric Dumazet eric.duma...@gmail.com
Date: Wed Sep 29 13:23:09 2010 -0700
net: add a recursion limit in xmit path
As tunnel devices are going to be lockless, we need to make sure a
misconfigured machine wont enter an infinite loop.
Add a percpu variable, and limit to three the number of stacked xmits.
Reported-by: Jesse Gross je...@nicira.com
Signed-off-by: Eric Dumazet eric.duma...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/net/core/dev.c b/net/core/dev.c
index 48ad47f..50dacca 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2177,6 +2177,9 @@ static inline int __dev_xmit_skb(struct sk_buff *skb,
struct Qdisc *q,
return rc;
}
+static DEFINE_PER_CPU(int, xmit_recursion);
+#define RECURSION_LIMIT 3
+
/**
* dev_queue_xmit - transmit a buffer
* @skb: buffer to transmit
@@ -2242,10 +2245,15 @@ int dev_queue_xmit(struct sk_buff *skb)
if (txq-xmit_lock_owner != cpu) {
+ if (__this_cpu_read(xmit_recursion) RECURSION_LIMIT)
+ goto recursion_alert;
+
HARD_TX_LOCK(dev, txq, cpu);
if (!netif_tx_queue_stopped(txq)) {
+ __this_cpu_inc(xmit_recursion);
rc = dev_hard_start_xmit(skb, dev, txq);
+ __this_cpu_dec(xmit_recursion);
if (dev_xmit_complete(rc)) {
HARD_TX_UNLOCK(dev, txq);
goto out;
@@ -2257,7 +2265,9 @@ int dev_queue_xmit(struct sk_buff *skb)
queue packet!\n, dev-name);
} else {
/* Recursion is detected! It is possible,
-* unfortunately */
+* unfortunately
+*/
+recursion_alert:
if (net_ratelimit())
printk(KERN_CRIT Dead loop on virtual device
%s, fix it urgently!\n, dev-name);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le mardi 13 avril 2010 à 11:03 +0100, stephen mulcahy a écrit : Eric Dumazet wrote: OK it seems forcedeth has problem with checksums ? Try to change ethtool -k eth0 settings ? ethtool -K eth0 tso off tx off Yes, that makes an unresponsive system responsive again immediately, nice! Should the driver default to disabling this until we problem is corrected? -stephen Both flags need to be disabled, or only one is OK ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le mardi 13 avril 2010 à 15:27 +0100, stephen mulcahy a écrit : Ok, I've tried both of the following with my reproducer 1. ethtool -K eth0 tso off RESULT: reproducer causes multiple hosts to be come unresponsive on first run. 2. ethtool -K eth0 tx off RESULT: reproducer runs three times without any hosts becoming unresponsive. -stephen Thanks Stephen ! Now some brave fouls to check the 6410 lines of this driver ? ;) Question of the day : Why TSO is broken in forcedeth ? Is it generically broken or is it broken for specific NICS ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le mardi 13 avril 2010 à 15:49 +0100, stephen mulcahy a écrit : Eric Dumazet wrote: Le mardi 13 avril 2010 à 15:27 +0100, stephen mulcahy a écrit : Ok, I've tried both of the following with my reproducer 1. ethtool -K eth0 tso off RESULT: reproducer causes multiple hosts to be come unresponsive on first run. 2. ethtool -K eth0 tx off RESULT: reproducer runs three times without any hosts becoming unresponsive. -stephen Thanks Stephen ! Now some brave fouls to check the 6410 lines of this driver ? ;) Question of the day : Why TSO is broken in forcedeth ? Is it generically broken or is it broken for specific NICS ? Actually, it is only when tx-checksumming is turned off that the problem doesn't occur (so I'm not sure TSO is the problem). Additionally, a google also turns up this existing Debian bug http://bugs.debian.org/506419 which seems to be related. -stephen I am scratching my head, but I thought you told me that ethtool -K eth0 tso off ethtool -K eth0 tx on was working ? And, given that when you perform ethtool -K eth0 tx off, TSO is automatically off... tx checksums work, TSO doesnt work, therefore TSO is broken ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le mardi 13 avril 2010 à 16:08 +0100, stephen mulcahy a écrit : Eric Dumazet wrote: I am scratching my head, but I thought you told me that ethtool -K eth0 tso off ethtool -K eth0 tx on was working ? No, sorry for the confusion. ethtool -K eth0 tx off fixes the problem. Setting only ethtool -K eth0 tso off ethtool -K eth0 tx on still results in failures. OK, thanks for clarification. Last question, did you tried a vanilla kernel, aka 2.6.33.2 for example ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le mardi 13 avril 2010 à 16:25 +0100, stephen mulcahy a écrit : Eric Dumazet wrote: OK, thanks for clarification. Last question, did you tried a vanilla kernel, aka 2.6.33.2 for example ? I built a Debian package from the vanilla 2.6.33.2 and installed that on all nodes and tried my reproducer with the same results - nodes becoming unresponsive. I didn't try changing the tso and tx settings with the 2.6.33.2 kernel though. Let me know if that would be useful (and/or if there is another kernel that you would like me to test with) and I'll try to fit it in. I tried 2.6.34-rc4 (64bits) on an old machine I had lying at home. 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx+ Latency: 0 (250ns min, 5000ns max) Interrupt: pin A routed to IRQ 21 Region 0: Memory at d400 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at b000 [size=8] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- Kernel driver in use: forcedeth Kernel modules: forcedeth I could not reproduce the problem you have. processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 31 model name : AMD Athlon(tm) 64 Processor 3200+ stepping: 0 cpu MHz : 1000.000 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good lahf_lm bogomips: 2010.09 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp RAM : 3 Gbytes Only strange thing I noticed is ethtool -S results with an insane tx_broadcast # ethtool -S eth1 NIC statistics: tx_bytes: 90388 tx_zero_rexmt: 348 tx_one_rexmt: 0 tx_many_rexmt: 0 tx_late_collision: 0 tx_fifo_errors: 0 tx_carrier_errors: 0 tx_excess_deferral: 0 tx_retry_error: 0 rx_frame_error: 0 rx_extra_byte: 0 rx_late_collision: 0 rx_runt: 0 rx_frame_too_long: 0 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_align_error: 0 rx_length_error: 0 rx_unicast: 413 rx_multicast: 22 rx_broadcast: 2 rx_packets: 437 rx_errors_total: 0 tx_errors_total: 0 tx_deferral: 718 tx_packets: 718 rx_bytes: 718 tx_pause: 718 rx_pause: 718 rx_drop_frame: 718 tx_unicast: 15748 tx_multicast: 5552 tx_broadcast: 115174309658 [r...@localhost ~]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:11:D8:9A:6D:06 inet adr:192.168.99.99 Bcast:192.168.99.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:466 errors:0 dropped:0 overruns:0 frame:0 TX packets:354 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:50751 (49.5 KiB) TX bytes:92974 (90.7 KiB) Interruption:21 Adresse de base:0x2000 [r...@localhost ~]# grep eth1 /proc/interrupts 21:954 IO-APIC-fasteoi eth1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le mardi 13 avril 2010 à 14:43 -0700, David Miller a écrit : Do you really come to the conclusion that TSO is broken with the above test results? I would conclude that there is a TX checksumming issue, since merely turning TSO off does not fix the problem whereas turning TX checksumming off does. Indeed, we clarified the point and it is a TX checksum issue. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le lundi 12 avril 2010 à 13:39 +0100, stephen mulcahy a écrit : stephen mulcahy wrote: It doesn't - further testing over the weekend saw 6 of 45 machines drop off the network with this problem. Nothing in dmesg or system logs. Happy to run more tests if someone can advise on what should be run. I also just tried using the 2.6.30-2-amd64 (Debian) forcedeth kernel module while running the 2.6.32-3-amd64 (Debian) kernel and experienced the same symptoms. Not sure if thats any help. I am not sure I understand. Are you saying that using 2.6.30-2-amd64 kernel also makes your forcedeth adapter being not functional ? Are both way non functional (RX and TX), or only one side ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le lundi 12 avril 2010 à 14:19 +0100, stephen mulcahy a écrit :
Does that help?
Well, yes, because it seems a TCP problem.
r...@node20:~# tcpdump host node20 and node05
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
14:12:59.612626 IP node05.webstar.cnet.36295 node20.ssh: Flags [S], seq
3677858646, win 5840, options [mss 1460,sackOK,TS val 1599534 ecr 0,nop,wscale
7], length 0
14:12:59.612656 IP node20.ssh node05.webstar.cnet.36295: Flags [S.], seq
3610575850, ack 3677858647, win 5792, options [mss 1460,sackOK,TS val 1598775
ecr 1599534,nop,wscale 7], length 0
14:12:59.612718 IP node05.webstar.cnet.36295 node20.ssh: Flags [.], ack 1,
win 46, options [nop,nop,TS val 1599534 ecr 1598775], length 0
14:12:59.617434 IP node20.ssh node05.webstar.cnet.36295: Flags [P.], seq
1:33, ack 1, win 46, options [nop,nop,TS val 1598776 ecr 1599534], length 32
14:12:59.617522 IP node05.webstar.cnet.36295 node20.ssh: Flags [.], ack 33,
win 46, options [nop,nop,TS val 1599535 ecr 1598776], length 0
14:12:59.617609 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
1:33, ack 33, win 46, options [nop,nop,TS val 1599535 ecr 1598776], length 32
All following xmitted frames are completely out of sync, this makes no sense.
Sequence number went backward.
14:12:59.820434 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
4294936586:4294936618, ack 2620194849, win 46, options [nop,nop,TS val 1599586
ecr 1598776], length 32
14:13:00.229069 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
4294961734:4294961766, ack 3928358945, win 46, options [nop,nop,TS val 1599688
ecr 1598776], length 32
14:13:01.044396 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
4294964167:4294964199, ack 410320929, win 46, options [nop,nop,TS val 1599892
ecr 1598776], length 32
14:13:02.676308 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
1:33, ack 33, win 46, options [nop,nop,TS val 1600300 ecr 1598776], length 32
14:13:05.940804 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
17294:17326, ack 3045851169, win 46, options [nop,nop,TS val 1601116 ecr
1598776], length 32
14:13:12.468484 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
17294:17326, ack 3045851169, win 46, options [nop,nop,TS val 1602748 ecr
1598776], length 32
14:13:25.523850 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
1:33, ack 33, win 46, options [nop,nop,TS val 1606012 ecr 1598776], length 32
14:13:51.633934 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
4294963190:4294963222, ack 9830433, win 46, options [nop,nop,TS val 1612540 ecr
1598776], length 32
14:14:43.855380 IP node05.webstar.cnet.36295 node20.ssh: Flags [P.], seq
1:33, ack 33, win 46, options [nop,nop,TS val 1625596 ecr 1598776], length 32
14:14:59.617675 IP node20.ssh node05.webstar.cnet.36295: Flags [F.], seq 33,
ack 1, win 46, options [nop,nop,TS val 1628777 ecr 1599535], length 0
14:14:59.618202 IP node05.webstar.cnet.36295 node20.ssh: Flags [FP.], seq
4294959654:4294960446, ack 3930456098, win 46, options [nop,nop,TS val 1629536
ecr 1628777], length 792
14:14:59.821527 IP node20.ssh node05.webstar.cnet.36295: Flags [F.], seq 33,
ack 1, win 46, options [nop,nop,TS val 1628828 ecr 1599535], length 0
14:14:59.821598 IP node05.webstar.cnet.36295 node20.ssh: Flags [.], ack 34,
win 46, options [nop,nop,TS val 1629587 ecr 1628828,nop,nop,sack 1 {33:34}],
length 0
Do you have some netfilters rules ?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572201: forcedeth driver hangs under heavy load
Le lundi 12 avril 2010 à 17:11 +0100, stephen mulcahy a écrit : Eric Dumazet wrote: Le lundi 12 avril 2010 à 14:19 +0100, stephen mulcahy a écrit : Do you have some netfilters rules ? Hi Eric, I don't have any netfilters rules: r...@node34:~# for table in filter nat mangle raw; do iptables -t $table -L; done Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination I re-ran this on the 2.6.32 kernel (with the 2.6.32 forcedeth module) just in case that was screwing something up. node33 is in the unresponsive state this time. I'm running tcpdump on node34. on node33 I try to ssh to node34 (using ip address of node34). I note that I can ping between node33 and node34. r...@node34:~# tcpdump -v host node34 and node33 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 17:05:19.622384 IP (tos 0x0, ttl 64, id 21435, offset 0, flags [DF], proto TCP (6), length 60) node33.webstar.cnet.43653 node34.ssh: Flags [S], cksum 0xb994 (correct), seq 1675314077, win 5840, options [mss 1460,sackOK,TS val 331814 ecr 0,nop,wscale 7], length 0 17:05:19.622754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) node34.ssh node33.webstar.cnet.43653: Flags [S.], cksum 0x9d81 (correct), seq 1669769379, ack 1675314078, win 5792, options [mss 1460,sackOK,TS val 331779 ecr 331814,nop,wscale 7], length 0 17:05:19.622813 IP (tos 0x0, ttl 64, id 21436, offset 0, flags [DF], proto TCP (6), length 52) node33.webstar.cnet.43653 node34.ssh: Flags [.], cksum 0xe2bf (correct), ack 1, win 46, options [nop,nop,TS val 331814 ecr 331779], length 0 17:05:19.627666 IP (tos 0x0, ttl 64, id 47271, offset 0, flags [DF], proto TCP (6), length 84) node34.ssh node33.webstar.cnet.43653: Flags [P.], seq 1:33, ack 1, win 46, options [nop,nop,TS val 331780 ecr 331814], length 32 17:05:19.627748 IP (tos 0x0, ttl 64, id 21437, offset 0, flags [DF], proto TCP (6), length 52) node33.webstar.cnet.43653 node34.ssh: Flags [.], cksum 0xe29c (correct), ack 33, win 46, options [nop,nop,TS val 331816 ecr 331780], length 0 17:05:19.627833 IP (tos 0x0, ttl 64, id 21438, offset 0, flags [DF], proto TCP (6), length 84, bad cksum 1f8a (-d189)!) node33.webstar.cnet.43653 node34.ssh: Flags [P.], seq 23413:23445, ack 2749038625, win 46, options [nop,nop,TS val 331816 ecr 331780], length 32 17:05:19.831634 IP (tos 0x0, ttl 64, id 21439, offset 0, flags [DF], proto TCP (6), length 84, bad cksum d189 (-d188)!) node33.webstar.cnet.43653 node34.ssh: Flags [P.], seq 1:33, ack 33, win 46, options [nop,nop,TS val 331867 ecr 331780], length 32 17:05:20.239603 IP (tos 0x0, ttl 64, id 21440, offset 0, flags [DF], proto TCP (6), length 84, bad cksum 15c6 (-d187)!) node33.webstar.cnet.43653 node34.ssh: Flags [P.], seq 30492:30524, ack 809893921, win 46, options [nop,nop,TS val 331969 ecr 331780], length 32 17:05:21.055534 IP (tos 0x0, ttl 64, id 21441, offset 0, flags [DF], proto TCP (6), length 84, bad cksum d187 (-d186)!) node33.webstar.cnet.43653 node34.ssh: Flags [P.], seq 1:33, ack 33, win 46, options [nop,nop,TS val 332173 ecr 331780], length 32 17:05:22.687386 IP (tos 0x0, ttl 64, id 21442, offset 0, flags [DF], proto TCP (6), length 84, bad cksum d186 (-d185)!) node33.webstar.cnet.43653 node34.ssh: Flags [P.], seq 1:33, ack 33, win 46, options [nop,nop,TS val 332581 ecr 331780], length 32 17:05:25.950935 IP (tos 0x0, ttl 64, id 21443, offset 0, flags [DF], proto TCP (6), length 84, bad cksum 15c4 (-d184)!) node33.webstar.cnet.43653 node34.ssh: Flags [P.], seq 30492:30524, ack 809893921, win 46, options [nop,nop,TS val 97 ecr 331780], length 32 17:05:32.478527 IP (tos 0x0, ttl 64, id 21444, offset 0, flags [DF], proto TCP (6), length 84, bad cksum c01 (-d183)!) node33.webstar.cnet
