Question about TCP Checksum errors

Question about TCP Checksum errors

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

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

Re: Question about TCP Checksum errors

[Eric Dumazet]

Le samedi 17 décembre 2011 à 17:18 -0600, Larry Finger a écrit :
> 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?
> 

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

Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[李刚]

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

Re: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[Mohammed Shafi]

2011/12/19 李刚 <gang.li@watchdata.com>:
> 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)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index edcd1c7..0454dee 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -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 ||



-- 
shafi

RE: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[李刚]

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


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.


> 
> @@ -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)
> 
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index edcd1c7..0454dee 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -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
||
> 
> 
> 
> --
> shafi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[Daniel Smith]

Hi!

On 12/19/2011 6:38 AM, 李刚 wrote:
> 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?
>

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

RE: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[李刚]

> 
> Hi!
> 
> On 12/19/2011 6:38 AM, 李刚 wrote:
> > 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?
> >
> 
> 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.



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

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


> 
> 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
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[Daniel Smith]

2011/12/19 李刚 <gang.li@watchdata.com>:
>
> 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.


> 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

[ath9k-devel] Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[Daniel Smith]

2011/12/19 ?? <gang.li@watchdata.com>:
>
> 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.


> 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

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

[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

Re: Question: ieee80211_rx called twice after one ieee80211_subif_start_xmit call

[Adrian Chadd]

2011/12/30 李刚 <gang.li@watchdata.com>:
> 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

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

[Adrian Chadd]

2011/12/30 ?? <gang.li@watchdata.com>:
> 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

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

[李刚]

> -----????-----
> ???: 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
> 
> 2011/12/30 ?? <gang.li@watchdata.com>:
> > 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? 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?  

> 
> 
> Adrian

Question about duration of data frame in ath9k_htc

[李刚]

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

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

[李刚]

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

Question about duration of data frame in ath9k_htc

[Sujith Manoharan]

李刚 wrote:
> 	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

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

[Sujith Manoharan]

?? wrote:
> 	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

Re: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[Helmut Schaa]

2011/12/19 李刚 <gang.li@watchdata.com>:
> 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

Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[Sujith]

李刚 wrote:
> 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?
> 

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

Sujith

RE: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[李刚]

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

> Sujith
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Question about IEEE80211_TX_CTL_NO_ACK in ath_9k

[Sujith]

李刚 wrote:
> 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