* Regression: TCP connections fail over wireless: bad cksum?
@ 2014-09-04 20:11 Ted Percival
2014-09-04 22:50 ` Eric Dumazet
0 siblings, 1 reply; 8+ messages in thread
From: Ted Percival @ 2014-09-04 20:11 UTC (permalink / raw)
To: netdev
Yesterday's linux-next build introduced a problem with wireless
networking on my machine. ie. next-20140901 worked fine but
next-20140902 does not seem able to sustain a TCP connection over
wireless. Wired networking works fine. I am using the brcmsmac driver
and the hardware is "Broadcom Corporation BCM4313 802.11b/g/n Wireless
LAN Controller (rev 01)".
Pings, even large pings (ping -s 16000) work fine but TCP connections hang.
I looked through the changes between the bad & good commits from the net
& net-next trees and I wonder if some of the changes to checksumming
have surfaced a problem with this driver. When I look at a tcpdump, it
indicates that all the checksums are wrong (although I don't know if
that is just due to hardware offload).
Here is a short trace of the hung connection attempt of
curl http://lwn.net/
$ sudo tcpdump -vvn -i wlan0 port 80
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size
65535 bytes
13:20:15.120770 IP (tos 0x0, ttl 64, id 22734, offset 0, flags [DF],
proto TCP (6), length 60)
10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
(incorrect -> 0x4fac), seq 2861986597, win 29200, options [mss
1460,sackOK,TS val 142315 ecr 0,nop,wscale 7], length 0
13:20:16.121755 IP (tos 0x0, ttl 64, id 22735, offset 0, flags [DF],
proto TCP (6), length 60)
10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
(incorrect -> 0x4bc3), seq 2861986597, win 29200, options [mss
1460,sackOK,TS val 143316 ecr 0,nop,wscale 7], length 0
13:20:18.125748 IP (tos 0x0, ttl 64, id 22736, offset 0, flags [DF],
proto TCP (6), length 60)
10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
(incorrect -> 0x43ef), seq 2861986597, win 29200, options [mss
1460,sackOK,TS val 145320 ecr 0,nop,wscale 7], length 0
13:20:22.133743 IP (tos 0x0, ttl 64, id 22737, offset 0, flags [DF],
proto TCP (6), length 60)
10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
(incorrect -> 0x3447), seq 2861986597, win 29200, options [mss
1460,sackOK,TS val 149328 ecr 0,nop,wscale 7], length 0
13:20:30.149754 IP (tos 0x0, ttl 64, id 22738, offset 0, flags [DF],
proto TCP (6), length 60)
10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
(incorrect -> 0x14f7), seq 2861986597, win 29200, options [mss
1460,sackOK,TS val 157344 ecr 0,nop,wscale 7], length 0
I don't see anything that looks related in dmesg. The only brcmsmac
messages I see are:
[ 567.122218] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed:
associated
[ 567.122226] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp
filtering: 1 addresses (implement)
[ 567.122231] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos
enabled: true (implement)
[ 567.192283] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos
enabled: true (implement)
I am writing to linux-netdev rather than linux-wireless because
according to Next/SHA1s the wireless & wireless-next trees were not
updated between next-20140901 and next-20140902, but the net & net-next
trees were updated, so maybe the regression came from there. (I haven't
tested next-20140903 because it won't boot for unrelated reasons.)
Let me know if I should just file this in Bugzilla or what information I
can provide to help track this down, if it hasn't already been identified.
The here are the good (-) and bad (+) trees from Next/SHA1s at the
next-* tags mentioned earlier that I built from.
-net 38ab1fa981d543e1b00f4ffbce4ddb480cd2effe
+net cc25f0cbe4409d6a573b1f3bf7020d5b04076ee9
-net-next dace1b54726bffe1c009f7661e3cee6b762f30c8
+net-next 364a9e93243d1785f310c0964af0e24bf1adac03
--
Cheers,
-Ted
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression: TCP connections fail over wireless: bad cksum?
2014-09-04 20:11 Regression: TCP connections fail over wireless: bad cksum? Ted Percival
@ 2014-09-04 22:50 ` Eric Dumazet
2014-09-04 23:21 ` Ted Percival
0 siblings, 1 reply; 8+ messages in thread
From: Eric Dumazet @ 2014-09-04 22:50 UTC (permalink / raw)
To: Ted Percival; +Cc: netdev
On Thu, 2014-09-04 at 14:11 -0600, Ted Percival wrote:
> Yesterday's linux-next build introduced a problem with wireless
> networking on my machine. ie. next-20140901 worked fine but
> next-20140902 does not seem able to sustain a TCP connection over
> wireless. Wired networking works fine. I am using the brcmsmac driver
> and the hardware is "Broadcom Corporation BCM4313 802.11b/g/n Wireless
> LAN Controller (rev 01)".
>
> Pings, even large pings (ping -s 16000) work fine but TCP connections hang.
>
> I looked through the changes between the bad & good commits from the net
> & net-next trees and I wonder if some of the changes to checksumming
> have surfaced a problem with this driver. When I look at a tcpdump, it
> indicates that all the checksums are wrong (although I don't know if
> that is just due to hardware offload).
>
> Here is a short trace of the hung connection attempt of
> curl http://lwn.net/
>
> $ sudo tcpdump -vvn -i wlan0 port 80
> tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size
> 65535 bytes
> 13:20:15.120770 IP (tos 0x0, ttl 64, id 22734, offset 0, flags [DF],
> proto TCP (6), length 60)
> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
> (incorrect -> 0x4fac), seq 2861986597, win 29200, options [mss
> 1460,sackOK,TS val 142315 ecr 0,nop,wscale 7], length 0
> 13:20:16.121755 IP (tos 0x0, ttl 64, id 22735, offset 0, flags [DF],
> proto TCP (6), length 60)
> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
> (incorrect -> 0x4bc3), seq 2861986597, win 29200, options [mss
> 1460,sackOK,TS val 143316 ecr 0,nop,wscale 7], length 0
> 13:20:18.125748 IP (tos 0x0, ttl 64, id 22736, offset 0, flags [DF],
> proto TCP (6), length 60)
> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
> (incorrect -> 0x43ef), seq 2861986597, win 29200, options [mss
> 1460,sackOK,TS val 145320 ecr 0,nop,wscale 7], length 0
> 13:20:22.133743 IP (tos 0x0, ttl 64, id 22737, offset 0, flags [DF],
> proto TCP (6), length 60)
> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
> (incorrect -> 0x3447), seq 2861986597, win 29200, options [mss
> 1460,sackOK,TS val 149328 ecr 0,nop,wscale 7], length 0
> 13:20:30.149754 IP (tos 0x0, ttl 64, id 22738, offset 0, flags [DF],
> proto TCP (6), length 60)
> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
> (incorrect -> 0x14f7), seq 2861986597, win 29200, options [mss
> 1460,sackOK,TS val 157344 ecr 0,nop,wscale 7], length 0
>
>
> I don't see anything that looks related in dmesg. The only brcmsmac
> messages I see are:
>
> [ 567.122218] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed:
> associated
> [ 567.122226] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp
> filtering: 1 addresses (implement)
> [ 567.122231] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos
> enabled: true (implement)
> [ 567.192283] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos
> enabled: true (implement)
>
> I am writing to linux-netdev rather than linux-wireless because
> according to Next/SHA1s the wireless & wireless-next trees were not
> updated between next-20140901 and next-20140902, but the net & net-next
> trees were updated, so maybe the regression came from there. (I haven't
> tested next-20140903 because it won't boot for unrelated reasons.)
>
> Let me know if I should just file this in Bugzilla or what information I
> can provide to help track this down, if it hasn't already been identified.
>
> The here are the good (-) and bad (+) trees from Next/SHA1s at the
> next-* tags mentioned earlier that I built from.
>
> -net 38ab1fa981d543e1b00f4ffbce4ddb480cd2effe
> +net cc25f0cbe4409d6a573b1f3bf7020d5b04076ee9
>
> -net-next dace1b54726bffe1c009f7661e3cee6b762f30c8
> +net-next 364a9e93243d1785f310c0964af0e24bf1adac03
>
Could you post
ethtool -k wlan0
And try
ethtool -K wlan tx off
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression: TCP connections fail over wireless: bad cksum?
2014-09-04 22:50 ` Eric Dumazet
@ 2014-09-04 23:21 ` Ted Percival
2014-09-04 23:28 ` Eric Dumazet
2014-09-05 3:41 ` Tom Herbert
0 siblings, 2 replies; 8+ messages in thread
From: Ted Percival @ 2014-09-04 23:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
On 09/04/2014 04:50 PM, Eric Dumazet wrote:
> On Thu, 2014-09-04 at 14:11 -0600, Ted Percival wrote:
>> Yesterday's linux-next build introduced a problem with wireless
>> networking on my machine. ie. next-20140901 worked fine but
>> next-20140902 does not seem able to sustain a TCP connection over
>> wireless. Wired networking works fine. I am using the brcmsmac driver
>> and the hardware is "Broadcom Corporation BCM4313 802.11b/g/n Wireless
>> LAN Controller (rev 01)".
>>
>> Pings, even large pings (ping -s 16000) work fine but TCP connections hang.
>>
>> I looked through the changes between the bad & good commits from the net
>> & net-next trees and I wonder if some of the changes to checksumming
>> have surfaced a problem with this driver. When I look at a tcpdump, it
>> indicates that all the checksums are wrong (although I don't know if
>> that is just due to hardware offload).
>>
>> Here is a short trace of the hung connection attempt of
>> curl http://lwn.net/
>>
>> $ sudo tcpdump -vvn -i wlan0 port 80
>> tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size
>> 65535 bytes
>> 13:20:15.120770 IP (tos 0x0, ttl 64, id 22734, offset 0, flags [DF],
>> proto TCP (6), length 60)
>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>> (incorrect -> 0x4fac), seq 2861986597, win 29200, options [mss
>> 1460,sackOK,TS val 142315 ecr 0,nop,wscale 7], length 0
>> 13:20:16.121755 IP (tos 0x0, ttl 64, id 22735, offset 0, flags [DF],
>> proto TCP (6), length 60)
>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>> (incorrect -> 0x4bc3), seq 2861986597, win 29200, options [mss
>> 1460,sackOK,TS val 143316 ecr 0,nop,wscale 7], length 0
>> 13:20:18.125748 IP (tos 0x0, ttl 64, id 22736, offset 0, flags [DF],
>> proto TCP (6), length 60)
>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>> (incorrect -> 0x43ef), seq 2861986597, win 29200, options [mss
>> 1460,sackOK,TS val 145320 ecr 0,nop,wscale 7], length 0
>> 13:20:22.133743 IP (tos 0x0, ttl 64, id 22737, offset 0, flags [DF],
>> proto TCP (6), length 60)
>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>> (incorrect -> 0x3447), seq 2861986597, win 29200, options [mss
>> 1460,sackOK,TS val 149328 ecr 0,nop,wscale 7], length 0
>> 13:20:30.149754 IP (tos 0x0, ttl 64, id 22738, offset 0, flags [DF],
>> proto TCP (6), length 60)
>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>> (incorrect -> 0x14f7), seq 2861986597, win 29200, options [mss
>> 1460,sackOK,TS val 157344 ecr 0,nop,wscale 7], length 0
>>
>>
>> I don't see anything that looks related in dmesg. The only brcmsmac
>> messages I see are:
>>
>> [ 567.122218] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed:
>> associated
>> [ 567.122226] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp
>> filtering: 1 addresses (implement)
>> [ 567.122231] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos
>> enabled: true (implement)
>> [ 567.192283] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos
>> enabled: true (implement)
>>
>> I am writing to linux-netdev rather than linux-wireless because
>> according to Next/SHA1s the wireless & wireless-next trees were not
>> updated between next-20140901 and next-20140902, but the net & net-next
>> trees were updated, so maybe the regression came from there. (I haven't
>> tested next-20140903 because it won't boot for unrelated reasons.)
>>
>> Let me know if I should just file this in Bugzilla or what information I
>> can provide to help track this down, if it hasn't already been identified.
>>
>> The here are the good (-) and bad (+) trees from Next/SHA1s at the
>> next-* tags mentioned earlier that I built from.
>>
>> -net 38ab1fa981d543e1b00f4ffbce4ddb480cd2effe
>> +net cc25f0cbe4409d6a573b1f3bf7020d5b04076ee9
>>
>> -net-next dace1b54726bffe1c009f7661e3cee6b762f30c8
>> +net-next 364a9e93243d1785f310c0964af0e24bf1adac03
>>
>
> Could you post
>
> ethtool -k wlan0
>
> And try
>
> ethtool -K wlan tx off
# ethtool -k wlan0
Features for wlan0:
rx-checksumming: off [fixed]
tx-checksumming: off
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: off
tx-scatter-gather: off [fixed]
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [fixed]
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: on [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
# ethtool -K wlan0 tx off
Cannot change tx-checksumming
I will try to isolate the commit that caused the regression.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression: TCP connections fail over wireless: bad cksum?
2014-09-04 23:21 ` Ted Percival
@ 2014-09-04 23:28 ` Eric Dumazet
2014-09-04 23:38 ` Eric Dumazet
2014-09-05 3:41 ` Tom Herbert
1 sibling, 1 reply; 8+ messages in thread
From: Eric Dumazet @ 2014-09-04 23:28 UTC (permalink / raw)
To: Ted Percival; +Cc: netdev
On Thu, 2014-09-04 at 17:21 -0600, Ted Percival wrote:
> # ethtool -k wlan0
> Features for wlan0:
> rx-checksumming: off [fixed]
> tx-checksumming: off
> tx-checksum-ipv4: off [fixed]
> tx-checksum-ip-generic: off [fixed]
> tx-checksum-ipv6: off [fixed]
> tx-checksum-fcoe-crc: off [fixed]
> tx-checksum-sctp: off [fixed]
> scatter-gather: off
> tx-scatter-gather: off [fixed]
> tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off [fixed]
> tx-tcp-ecn-segmentation: off [fixed]
> tx-tcp6-segmentation: off [fixed]
> udp-fragmentation-offload: off [fixed]
> generic-segmentation-offload: off [requested on]
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: off [fixed]
> tx-vlan-offload: off [fixed]
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: off [fixed]
> rx-vlan-filter: off [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: on [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: off [fixed]
> tx-gre-segmentation: off [fixed]
> tx-ipip-segmentation: off [fixed]
> tx-sit-segmentation: off [fixed]
> tx-udp_tnl-segmentation: off [fixed]
> tx-mpls-segmentation: off [fixed]
> fcoe-mtu: off [fixed]
> tx-nocache-copy: off
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
> l2-fwd-offload: off [fixed]
> busy-poll: off [fixed]
>
> # ethtool -K wlan0 tx off
> Cannot change tx-checksumming
>
> I will try to isolate the commit that caused the regression.
Ah well, I guess we know it ;)
tc -s -d qd show dev wlan0
tc qdisc replace dev wlan0 fq
This should temporarily help.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression: TCP connections fail over wireless: bad cksum?
2014-09-04 23:28 ` Eric Dumazet
@ 2014-09-04 23:38 ` Eric Dumazet
0 siblings, 0 replies; 8+ messages in thread
From: Eric Dumazet @ 2014-09-04 23:38 UTC (permalink / raw)
To: Ted Percival; +Cc: netdev
On Thu, 2014-09-04 at 16:28 -0700, Eric Dumazet wrote:
> tc -s -d qd show dev wlan0
>
> tc qdisc replace dev wlan0 fq
I forgot the root keyword :
tc qdisc replace dev wlan0 root fq
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression: TCP connections fail over wireless: bad cksum?
2014-09-04 23:21 ` Ted Percival
2014-09-04 23:28 ` Eric Dumazet
@ 2014-09-05 3:41 ` Tom Herbert
2014-09-05 4:38 ` Eric Dumazet
1 sibling, 1 reply; 8+ messages in thread
From: Tom Herbert @ 2014-09-05 3:41 UTC (permalink / raw)
To: Ted Percival; +Cc: Eric Dumazet, Linux Netdev List
On Thu, Sep 4, 2014 at 4:21 PM, Ted Percival <ted@tedp.id.au> wrote:
> On 09/04/2014 04:50 PM, Eric Dumazet wrote:
>> On Thu, 2014-09-04 at 14:11 -0600, Ted Percival wrote:
>>> Yesterday's linux-next build introduced a problem with wireless
>>> networking on my machine. ie. next-20140901 worked fine but
>>> next-20140902 does not seem able to sustain a TCP connection over
>>> wireless. Wired networking works fine. I am using the brcmsmac driver
>>> and the hardware is "Broadcom Corporation BCM4313 802.11b/g/n Wireless
>>> LAN Controller (rev 01)".
>>>
>>> Pings, even large pings (ping -s 16000) work fine but TCP connections hang.
>>>
>>> I looked through the changes between the bad & good commits from the net
>>> & net-next trees and I wonder if some of the changes to checksumming
>>> have surfaced a problem with this driver. When I look at a tcpdump, it
>>> indicates that all the checksums are wrong (although I don't know if
>>> that is just due to hardware offload).
>>>
>>> Here is a short trace of the hung connection attempt of
>>> curl http://lwn.net/
>>>
>>> $ sudo tcpdump -vvn -i wlan0 port 80
>>> tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size
>>> 65535 bytes
>>> 13:20:15.120770 IP (tos 0x0, ttl 64, id 22734, offset 0, flags [DF],
>>> proto TCP (6), length 60)
>>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>>> (incorrect -> 0x4fac), seq 2861986597, win 29200, options [mss
>>> 1460,sackOK,TS val 142315 ecr 0,nop,wscale 7], length 0
>>> 13:20:16.121755 IP (tos 0x0, ttl 64, id 22735, offset 0, flags [DF],
>>> proto TCP (6), length 60)
>>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>>> (incorrect -> 0x4bc3), seq 2861986597, win 29200, options [mss
>>> 1460,sackOK,TS val 143316 ecr 0,nop,wscale 7], length 0
>>> 13:20:18.125748 IP (tos 0x0, ttl 64, id 22736, offset 0, flags [DF],
>>> proto TCP (6), length 60)
>>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>>> (incorrect -> 0x43ef), seq 2861986597, win 29200, options [mss
>>> 1460,sackOK,TS val 145320 ecr 0,nop,wscale 7], length 0
>>> 13:20:22.133743 IP (tos 0x0, ttl 64, id 22737, offset 0, flags [DF],
>>> proto TCP (6), length 60)
>>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>>> (incorrect -> 0x3447), seq 2861986597, win 29200, options [mss
>>> 1460,sackOK,TS val 149328 ecr 0,nop,wscale 7], length 0
>>> 13:20:30.149754 IP (tos 0x0, ttl 64, id 22738, offset 0, flags [DF],
>>> proto TCP (6), length 60)
>>> 10.5.51.93.38035 > 72.51.34.34.80: Flags [S], cksum 0xa7e5
>>> (incorrect -> 0x14f7), seq 2861986597, win 29200, options [mss
>>> 1460,sackOK,TS val 157344 ecr 0,nop,wscale 7], length 0
>>>
>>>
>>> I don't see anything that looks related in dmesg. The only brcmsmac
>>> messages I see are:
>>>
>>> [ 567.122218] brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed:
>>> associated
>>> [ 567.122226] brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp
>>> filtering: 1 addresses (implement)
>>> [ 567.122231] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos
>>> enabled: true (implement)
>>> [ 567.192283] brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos
>>> enabled: true (implement)
>>>
>>> I am writing to linux-netdev rather than linux-wireless because
>>> according to Next/SHA1s the wireless & wireless-next trees were not
>>> updated between next-20140901 and next-20140902, but the net & net-next
>>> trees were updated, so maybe the regression came from there. (I haven't
>>> tested next-20140903 because it won't boot for unrelated reasons.)
>>>
>>> Let me know if I should just file this in Bugzilla or what information I
>>> can provide to help track this down, if it hasn't already been identified.
>>>
>>> The here are the good (-) and bad (+) trees from Next/SHA1s at the
>>> next-* tags mentioned earlier that I built from.
>>>
>>> -net 38ab1fa981d543e1b00f4ffbce4ddb480cd2effe
>>> +net cc25f0cbe4409d6a573b1f3bf7020d5b04076ee9
>>>
>>> -net-next dace1b54726bffe1c009f7661e3cee6b762f30c8
>>> +net-next 364a9e93243d1785f310c0964af0e24bf1adac03
>>>
>>
>> Could you post
>>
>> ethtool -k wlan0
>>
>> And try
>>
>> ethtool -K wlan tx off
>
> # ethtool -k wlan0
> Features for wlan0:
> rx-checksumming: off [fixed]
> tx-checksumming: off
> tx-checksum-ipv4: off [fixed]
> tx-checksum-ip-generic: off [fixed]
> tx-checksum-ipv6: off [fixed]
> tx-checksum-fcoe-crc: off [fixed]
> tx-checksum-sctp: off [fixed]
> scatter-gather: off
> tx-scatter-gather: off [fixed]
> tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off [fixed]
> tx-tcp-ecn-segmentation: off [fixed]
> tx-tcp6-segmentation: off [fixed]
> udp-fragmentation-offload: off [fixed]
> generic-segmentation-offload: off [requested on]
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: off [fixed]
> tx-vlan-offload: off [fixed]
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: off [fixed]
> rx-vlan-filter: off [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: on [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: off [fixed]
> tx-gre-segmentation: off [fixed]
> tx-ipip-segmentation: off [fixed]
> tx-sit-segmentation: off [fixed]
> tx-udp_tnl-segmentation: off [fixed]
> tx-mpls-segmentation: off [fixed]
> fcoe-mtu: off [fixed]
> tx-nocache-copy: off
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
> l2-fwd-offload: off [fixed]
> busy-poll: off [fixed]
>
> # ethtool -K wlan0 tx off
> Cannot change tx-checksumming
>
> I will try to isolate the commit that caused the regression.
Please provide 'netstat -s' to see if bad checksums are being
reported. Also, try disabling GRO to see the effect.
Thanks,
Tom
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Regression: TCP connections fail over wireless: bad cksum?
2014-09-05 3:41 ` Tom Herbert
@ 2014-09-05 4:38 ` Eric Dumazet
2014-09-05 15:29 ` Solved: Regression: TCP connections fail over wireless: bad checksum Ted Percival
0 siblings, 1 reply; 8+ messages in thread
From: Eric Dumazet @ 2014-09-05 4:38 UTC (permalink / raw)
To: Tom Herbert; +Cc: Ted Percival, Linux Netdev List
On Thu, 2014-09-04 at 20:41 -0700, Tom Herbert wrote:
> Please provide 'netstat -s' to see if bad checksums are being
> reported. Also, try disabling GRO to see the effect.
Most probably this is already fixed in net-next tree
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1f59533f9ca5634e7b8914252e48aee9d9cbe501
^ permalink raw reply [flat|nested] 8+ messages in thread
* Solved: Regression: TCP connections fail over wireless: bad checksum
2014-09-05 4:38 ` Eric Dumazet
@ 2014-09-05 15:29 ` Ted Percival
0 siblings, 0 replies; 8+ messages in thread
From: Ted Percival @ 2014-09-05 15:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, Linux Netdev List
On 09/04/2014 10:38 PM, Eric Dumazet wrote:
> Most probably this is already fixed in net-next tree
>
> http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1f59533f9ca5634e7b8914252e48aee9d9cbe501
Yep. 50cbe9ab5f8d was the regressing commit and cherry-picking that
commit on top of it solves the problem.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-09-05 15:28 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-04 20:11 Regression: TCP connections fail over wireless: bad cksum? Ted Percival
2014-09-04 22:50 ` Eric Dumazet
2014-09-04 23:21 ` Ted Percival
2014-09-04 23:28 ` Eric Dumazet
2014-09-04 23:38 ` Eric Dumazet
2014-09-05 3:41 ` Tom Herbert
2014-09-05 4:38 ` Eric Dumazet
2014-09-05 15:29 ` Solved: Regression: TCP connections fail over wireless: bad checksum Ted Percival
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.