Question about TCP Checksum errors

DISCUSSION Larry Finger 9 participants 17 messages Dec 17, 2011 – Jan 7, 2012 mac80211

Share & tools

Larry Finger

author

2011-12-17 23:18 UTC #0 lore raw

In https://bugzilla.novell.com/show_bug.cgi?id=718736, a user reports that his network using an RTL8188CE becomes very slow under "heavy" load. This condition started when he updated from openSUSE 11.4 to 12.1. The kernels involved are 2.6.37 and 3.1. I am unable to duplicate the problem.

Packet capture with Wireshark shows that the slow down is due to retransmissions due to TCP checksum errors. I found nothing to explain the situation with a Google search, thus I am asking here.

I put heavy in quotes because the traffic is from a web browser to yahoo.com, thus the potential throughput is not very high.

As far as I know, this checksum is generated in a higher layer of the network stack, and that data is just passed through the 802.11 layer, and the wireless driver. Is this correct? Anyone have any ideas on where to look for the problem?

Thanks,

Larry

Eric Dumazet

2011-12-17 23:43 UTC #1 lore raw

Quoted 9 lines · Larry Finger

In https://bugzilla.novell.com/show_bug.cgi?id=718736, a user reports that his network using an RTL8188CE becomes very slow under "heavy" load. This condition started when he updated from openSUSE 11.4 to 12.1. The kernels involved are 2.6.37 and 3.1. I am unable to duplicate the problem.
Packet capture with Wireshark shows that the slow down is due to retransmissions due to TCP checksum errors. I found nothing to explain the situation with a Google search, thus I am asking here.

Quoted 7 lines

I put heavy in quotes because the traffic is from a web browser to yahoo.com, thus the potential throughput is not very high.
As far as I know, this checksum is generated in a higher layer of the network stack, and that data is just passed through the 802.11 layer, and the wireless driver. Is this correct? Anyone have any ideas on where to look for the problem?

I see nothing special in the packet capture from this bug report.

(Only suboptimal application opening many concurrent flows in //)

Keep in mind most modern NICS compute checksums themselve.

Linux offloads this to NIC

This can be controled eventually by "ethtool -k ethX" (-K to change settings)

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

# ethtool -K eth0 tx off
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

李刚

2011-12-19 12:10 UTC #2 lore raw

Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

In reply to Larry Finger

Hi everybody!

My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before send a packet, but found it no use. It still wait for an ACK. Then I read the code,
in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:

#define ATH9K_HTC_TX_CTSONLY 0x1
#define ATH9K_HTC_TX_RTSCTS 0x2

None is about ack.

Does anyone know how to make this flag work properly?

Thanks a lot!

gang.li

Mohammed Shafi

2011-12-19 12:33 UTC #3 lore raw

Re: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

2011/12/19 李刚 <[email protected]>:

Quoted 5 lines

Hi everybody!
My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before send a packet, but found it no use. It still wait for an ACK. Then I read the code,

may be any of the following hacks may work ?

@@ -1039,6 +1039,9 @@ static void ath_tx_fill_desc(struct ath_softc *sc, struct ath_buf *bf,

        info.qcu = txq->axq_qnum;

        info.flags = ATH9K_TXDESC_INTREQ;
+
+               info.flags |= ATH9K_TXDESC_NOACK;
+
        if (tx_info->flags & IEEE80211_TX_CTL_NO_ACK)
                info.flags |= ATH9K_TXDESC_NOACK;
        if (tx_info->flags & IEEE80211_TX_CTL_LDPC)

(or)

net/mac80211/tx.c +2 -0

index edcd1c7..0454dee 100644
@@ -1185,6 +1185,8 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data *sdata,
        } else
                tx->flags |= IEEE80211_TX_UNICAST;
 
+               info->flags |= IEEE80211_TX_CTL_NO_ACK;
+
        if (!(info->flags & IEEE80211_TX_CTL_DONTFRAG)) {
                if (!(tx->flags & IEEE80211_TX_UNICAST) ||
                    skb->len + FCS_LEN <= local->hw.wiphy->frag_threshold ||

Signature · 1 line

shafi

李刚

2011-12-19 13:04 UTC #4 lore raw

RE: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

Quoted 4 lines

Quoted 4 lines
Hi everybody!
My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag

before

Quoted 1 line

Quoted 1 line
send a packet, but found it no use. It still wait for an ACK. Then I

read

Quoted 3 lines

Quoted 1 line
the code,
may be any of the following hacks may work ?

Sorry, I didn't make it clear! My 9280 is an USB card, and the send function is ath9k_htc_tx_data, there is no corresponding flag.

Quoted 28 lines

(quoted diff) +3 -0

@@ -1039,6 +1039,9 @@ static void ath_tx_fill_desc(struct ath_softc
 *sc, struct ath_buf *bf,
        info.qcu = txq->axq_qnum;
 
        info.flags = ATH9K_TXDESC_INTREQ;
+
+               info.flags |= ATH9K_TXDESC_NOACK;
+
        if (tx_info->flags & IEEE80211_TX_CTL_NO_ACK)
                info.flags |= ATH9K_TXDESC_NOACK;

        if (tx_info->flags & IEEE80211_TX_CTL_LDPC)

(or)

net/mac80211/tx.c +2 -0

index edcd1c7..0454dee 100644
@@ -1185,6 +1185,8 @@ ieee80211_tx_prepare(struct ieee80211_sub_if_data
 *sdata,
        } else
                tx->flags |= IEEE80211_TX_UNICAST;
 
+               info->flags |= IEEE80211_TX_CTL_NO_ACK;
+
        if (!(info->flags & IEEE80211_TX_CTL_DONTFRAG)) {
                if (!(tx->flags & IEEE80211_TX_UNICAST) ||

Quoted 1 line

                    skb->len + FCS_LEN <= local->hw.wiphy->frag_threshold

Quoted 7 lines

--
shafi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless"

Quoted 2 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Daniel Smith

2011-12-19 12:34 UTC #5 lore raw

Re: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

In reply to 李刚

Hi!

Quoted 7 lines · 李刚

Hi everybody!
My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before send a packet, but found it no use. It still wait for an ACK. Then I read the code,
in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:

Quoted 7 lines

#define ATH9K_HTC_TX_CTSONLY 0x1
#define ATH9K_HTC_TX_RTSCTS 0x2
None is about ack.
Does anyone know how to make this flag work properly?

As an FYI if your card is a AR9280, then you should be looking in xmit.c and not at the HTC related code.

I am also working on this issue to enable per-frame no-ack and have already tracked it down to the following snippet in the function ieee80211_tx_prepare (mac80211/tx.c).

if (is_multicast_ether_addr(hdr->addr1)) {
tx->flags &= ~IEEE80211_TX_UNICAST;
info->flags |= IEEE80211_TX_CTL_NO_ACK;
} else {
tx->flags |= IEEE80211_TX_UNICAST;
if (unlikely(local->wifi_wme_noack_test))
info->flags |= IEEE80211_TX_CTL_NO_ACK;
else
info->flags &= ~IEEE80211_TX_CTL_NO_ACK;
}

So if you send a unicast frame without this wifi_wme_noack_test flag set then mac80211 will force the frame to require an ACK. To set the flag,

# sudo -s "echo 1> /sys/kernel/debug/ieee80211/phy0/noack"

Assuming phy0 is the wireless card with which you are wanting to do the frame injection. The downside to this is that now every frame is passed to ath9k with the no ack flag set.

Daniel

李刚

2011-12-19 13:01 UTC #6 lore raw

RE: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

Quoted 7 lines

Hi!
Quoted 3 lines · 李刚
Hi everybody!
My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag

before

Quoted 1 line

Quoted 1 line
send a packet, but found it no use. It still wait for an ACK. Then I

read

Quoted 6 lines

Quoted 6 lines
the code,
in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:
#define ATH9K_HTC_TX_CTSONLY 0x1
#define ATH9K_HTC_TX_RTSCTS 0x2

Quoted 7 lines

Quoted 4 lines
None is about ack.
Does anyone know how to make this flag work properly?
As an FYI if your card is a AR9280, then you should be looking in xmit.c and not at the HTC related code.

Hi, Daniel, Thanks you !

Sorry, I didn't make it clear! My 9280 is an USB card, so the related code is htc_drv_*.c.

Quoted 5 lines

I am also working on this issue to enable per-frame no-ack and have already tracked it down to the following snippet in the function ieee80211_tx_prepare (mac80211/tx.c).

Quoted 10 lines

if (is_multicast_ether_addr(hdr->addr1)) {
tx->flags &= ~IEEE80211_TX_UNICAST;
info->flags |= IEEE80211_TX_CTL_NO_ACK;
} else {
tx->flags |= IEEE80211_TX_UNICAST;
if (unlikely(local->wifi_wme_noack_test))
info->flags |= IEEE80211_TX_CTL_NO_ACK;
else
info->flags &= ~IEEE80211_TX_CTL_NO_ACK;
}

I have seen these codes in tx.c, and at first I thought it should work, but does not.

Quoted 6 lines

So if you send a unicast frame without this wifi_wme_noack_test flag set then mac80211 will force the frame to require an ACK. To set the flag,
# sudo -s "echo 1> /sys/kernel/debug/ieee80211/phy0/noack"

Quoted 8 lines

Assuming phy0 is the wireless card with which you are wanting to do the frame injection. The downside to this is that now every frame is passed to ath9k with the no ack flag set.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless"

Quoted 2 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Daniel Smith

2011-12-19 13:43 UTC #7 lore raw

[ath9k-devel] Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

2011/12/19 ?? <[email protected]>:

Quoted 5 lines

Hi, Daniel, Thanks you !
Sorry, I didn't make it clear! My 9280 is an USB card, so the related code is htc_drv_*.c.

No worries, I just was not aware of any USB devices with the 9280 in it and the ath9k_htc "supported chips" are the 9271 and 7010.

Quoted 2 lines

I have seen these codes in tx.c, and at first I thought it should work, but does not.

So will assume you dealt with this then.

I have not done a lot of delving into the ath9k_htc code myself and I am not familiar with interfacing with the chips via USB. Normally with a 9280 where the tx ctrl descriptors are DMA'ed in I just need to make sure that bit 24 of the third tx ctrl descriptor is set to 1. I did a cursory look at how a frame is handed from kernel down to hardware and the hardware control is done through flags set on a struct tx_frame_hdr. I looked at the flags defined for ath9k_htc and I see no sign of a flag to control ACK's. So I think this has to be punted to one of the Atheros guys or someone with the spec sheets that can say if there is a bit in the flags field to turn off ACK.

Sorry I couldn't be much more help.

Daniel

李刚

2011-12-30 08:15 UTC #8 lore raw

[ath9k-devel] Question: ieee80211_rx called twice after one ieee80211_subif_start_xmit call

Hi sirs,

Today, I noticed that when an data frame is sent by
ieee80211_subif_start_xmit, then ieee80211_rx will be called twice , first is an Acknowledgement frame and second is the response data frame. Is this
the normal case? It seems the RA frame is nonsense and just be freed in
ieee80211_rx_monitor.

Is there anyway to tell the hardware not report RA frame to
mac80211?

Thanks very much!

Li gang

Adrian Chadd

2011-12-30 09:30 UTC #9 lore raw

[ath9k-devel] Question: ieee80211_rx called twice after one ieee80211_subif_start_xmit call

2011/12/30 ?? <[email protected]>:

Quoted 10 lines

Hi sirs,
Today, I noticed that when an data frame is sent by
ieee80211_subif_start_xmit, then ieee80211_rx will be called twice , first is an Acknowledgement frame and second is the response data frame. Is this
the normal case? It seems the RA frame is nonsense and just be freed in
ieee80211_rx_monitor.
Is there anyway to tell the hardware not report RA frame to
mac80211?

.. its receiving ACKs? I thought it only did that when either promisc or control was enabled. Try fiddling around with the RX filter bitmask and see if you can determine (for your NIC :) which filter bit is doing it.

Maybe the interface is in promisc mode in hostap mode and this is why you're seeing ACKs.

Adrian

李刚

2011-12-30 11:13 UTC #10 lore raw

[ath9k-devel] 答复: Question: ieee80211_rx called twice after one ieee80211_subif_start_xmit call

Quoted 9 lines

-----????-----
???: adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] ?? Adrian Chadd
????: 2011?12?30? 17:31
???: ??
??: linux-wireless at vger.kernel.org; Ath9k Devel List
??: Re: Question: ieee80211_rx called twice after one ieee80211_subif_start_xmit call

Quoted 5 lines

2011/12/30 ?? <[email protected]>:
Quoted 4 lines
Hi sirs,
Today, I noticed that when an data frame is sent by
ieee80211_subif_start_xmit, then ieee80211_rx will be called twice ,

first

Quoted 1 line

Quoted 1 line
is an Acknowledgement frame and second is the response data frame. Is

this

Quoted 1 line

Quoted 1 line
the normal case? It seems the RA frame is nonsense and just be freed

Quoted 5 lines

Quoted 4 lines
ieee80211_rx_monitor.
Is there anyway to tell the hardware not report RA frame to
mac80211?

Quoted 7 lines

.. its receiving ACKs? I thought it only did that when either promisc or control was enabled. Try fiddling around with the RX filter bitmask and see if you can determine (for your NIC :) which filter bit is doing it.
Maybe the interface is in promisc mode in hostap mode and this is why you're seeing ACKs.

Adrian? Thank you very much.

You reminded me that the RX filter is not correct, Yes, I almost forget that I have changed the RX filter in ieee80211_configure_filter :

new_flags |= FIF_PROMISC_IN_BSS;

and the mode is STATION.

What I want is to make two devices communicate directly without creating an BSS or IBSS in advance, just using a wildcard BSSID instead. But if setting the RX flag as normal case 0 in STATION mode, the hardware can receive noting. I don't know what's the matter. May be an BSSID must be set to the hardware?

Quoted 3 lines

Adrian

李刚

2012-01-07 02:11 UTC #11 lore raw

[ath9k-devel] Question about duration of data frame in ath9k_htc

In reply to Daniel Smith

Hi Sirs,

From wireshark, I noticed that when send an data frame , the
duration of frame control is fixed at 60 , no matter the frame length is 100 bytes or 1000 bytes.

It seems this value is calculated in firmware and should be correct.
But I don't know why. And this value can be set in mac80211?

Thanks in advance!

Li gang

Sujith Manoharan

2012-01-07 05:29 UTC #12 lore raw

[ath9k-devel] Question about duration of data frame in ath9k_htc

Quoted 6 lines · 李刚

From wireshark, I noticed that when send an data frame , the
duration of frame control is fixed at 60 , no matter the frame length is 100 bytes or 1000 bytes.
It seems this value is calculated in firmware and should be correct.
But I don't know why. And this value can be set in mac80211?

Duration calculation is broken for ath9k_htc.
See: http://linuxwireless.org/en/users/Drivers/ath9k_htc#TODO

Sujith

Helmut Schaa

2011-12-19 13:07 UTC #13 lore raw

Re: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

In reply to 李刚

2011/12/19 李刚 <[email protected]>:

Quoted 2 lines

My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before send a packet, but found it no use. It still wait for an ACK.

How did you verify that? For unicast frames with IEEE80211_TX_CTL_NO_ACK set you will still see an ACK on the air (since the peer has to generate it according
to the 802.11 spec). The only thing this flag does is to advise the hardware to ignore a missing ACK and hence to not retry the frame in this case ...

Helmut

Sujith

2011-12-19 14:42 UTC #14 lore raw

Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

In reply to 李刚

Quoted 7 lines · 李刚

Hi everybody!
My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag before send a packet, but found it no use. It still wait for an ACK. Then I read the code,
in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:

Quoted 7 lines

#define ATH9K_HTC_TX_CTSONLY 0x1
#define ATH9K_HTC_TX_RTSCTS 0x2
None is about ack.
Does anyone know how to make this flag work properly?

NOACK usage is not handled by ath9k_htc.
See: http://linuxwireless.org/en/users/Drivers/ath9k_htc#TODO

Sujith

李刚

2011-12-20 05:40 UTC #15 lore raw

RE: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

Quoted 3 lines

Quoted 3 lines
Hi everybody!
My wireless card is AR9280. I set the IEEE80211_TX_CTL_NO_ACK flag

before

Quoted 1 line

Quoted 1 line
send a packet, but found it no use. It still wait for an ACK. Then I

read

Quoted 6 lines

Quoted 6 lines
the code,
in ath9k_htc_tx_data(htc_drv_txrx.c) , it seems there is only two flags:
#define ATH9K_HTC_TX_CTSONLY 0x1
#define ATH9K_HTC_TX_RTSCTS 0x2

Quoted 8 lines

Quoted 4 lines
None is about ack.
Does anyone know how to make this flag work properly?
NOACK usage is not handled by ath9k_htc.
See: http://linuxwireless.org/en/users/Drivers/ath9k_htc#TODO

Thanks！

So , is there any way to set the re-transmit times when ACK not received? Now , it will send 10 times.

Quoted 3 lines

Sujith
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless"

Quoted 2 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Sujith

2011-12-20 15:24 UTC #16 lore raw

RE: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

Quoted 2 lines · 李刚

So , is there any way to set the re-transmit times when ACK not received? Now , it will send 10 times.

Unfortunately no, it cannot be done. The firmware has to be modified to allow such changes and the firmware is currently available only in binary form.

Sujith