ath10k tx to a Macbook Pro stalls

ath10k tx to a Macbook Pro stalls

[Andy Lutomirski]

On my Archer C7 v2, as soon as the MBP tries to do something like
playing a video, it seems like frames *to* the MBP no longer get
there.  At the very least, arp replies don't get there.

I have:

[   13.220000] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw
10.1.467.2-1 api 2 htt 2.1

Station 3c:15:c2:[redacted] (on wlan0)
    inactive time:    1400 ms
    rx bytes:    2157688
    rx packets:    10309
    tx bytes:    16102107
    tx packets:    15622
    tx retries:    0
    tx failed:    0
    signal:      -55 dBm
    signal avg:    -55 dBm
    tx bitrate:    6.0 MBit/s
    rx bitrate:    877.5 MBit/s VHT-MCS 7 80MHz VHT-NSS 3
    authorized:    yes
    authenticated:    yes
    preamble:    long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:    no

Interface wlan0
    ifindex 18
    wdev 0x4
    addr e8:94:f6:[redacted]
    ssid [redacted]
    type AP
    wiphy 0
    channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz

# cat fw_stats

             ath10k PDEV stats
             =================

           Channel noise floor       -108
              Channel TX power         46
                TX frame count          0
                RX frame count          0
                RX clear count          0
                   Cycle count        941
               PHY error count       2612
                 RTS bad count          0
                RTS good count          0
                 FCS bad count        426
               No beacon count          0
                 MIB int count   48158964

          ath10k PDEV TX stats
             =================

            HTT cookies queued      15887
             HTT cookies disp.      15887
                   MSDU queued      21200
                   MPDU queued      20982
                 MSDUs dropped          0
                  Local enqued       5313
                   Local freed       5313
                     HW queued      21655
                  PPDUs reaped      21655
                 Num underruns          0
                 PPDUs cleaned          0
                  MPDUs requed        776
             Excessive retries        767
                       HW rate          3
            Sched self tiggers        334
     Dropped due to SW retries          0
       Illegal rate phy errors          0
         Pdev continous xretry          0
                    TX timeout          0
                   PDEV resets          0
                  PHY underrun          0
  MPDU is more than txop limit          0

          ath10k PDEV RX stats
             =================

         Mid PPDU route change          0
       Tot. number of statuses      52787
        Extra frags on rings 0          0
        Extra frags on rings 1          0
        Extra frags on rings 2          1
        Extra frags on rings 3          0
        MSDUs delivered to HTT      52787
        MPDUs delivered to HTT      52263
      MSDUs delivered to stack      37576
      MPDUs delivered to stack      37576
               Oversized AMSUs          0
                    PHY errors          0
              PHY errors drops       2610
   MPDU errors (FCS, MIC, ENC)       3129

             ath10k PEER stats (1)
             =================

              Peer MAC address 3c:15:c2:[redacted]
                     Peer RSSI 40
                  Peer TX rate 975000
                  Peer RX rate 877500


This is with the a brand-new OpenWRT build that (finally!) has a
correct board.bin for the card.

Is this possibly a rate control issue?  A firmware issue?  Is there
something else I can do to give a more helpful bug report?


Thanks,
Andy

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k tx to a Macbook Pro stalls

[Dave Taht]

This may be related to:

https://dev.openwrt.org/ticket/15320
http://www.bufferbloat.net/issues/442
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2014-July/003213.html

(both on ath9k)

It's been driving multiple folk crazy.

Some advice on more stuff to look at is in both bug reports.

On Mon, Jul 21, 2014 at 10:04 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On my Archer C7 v2, as soon as the MBP tries to do something like
> playing a video, it seems like frames *to* the MBP no longer get
> there.  At the very least, arp replies don't get there.
>
> I have:
>
> [   13.220000] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw
> 10.1.467.2-1 api 2 htt 2.1
>
> Station 3c:15:c2:[redacted] (on wlan0)
>     inactive time:    1400 ms
>     rx bytes:    2157688
>     rx packets:    10309
>     tx bytes:    16102107
>     tx packets:    15622
>     tx retries:    0
>     tx failed:    0
>     signal:      -55 dBm
>     signal avg:    -55 dBm
>     tx bitrate:    6.0 MBit/s
>     rx bitrate:    877.5 MBit/s VHT-MCS 7 80MHz VHT-NSS 3
>     authorized:    yes
>     authenticated:    yes
>     preamble:    long
>     WMM/WME:    yes
>     MFP:        no
>     TDLS peer:    no
>
> Interface wlan0
>     ifindex 18
>     wdev 0x4
>     addr e8:94:f6:[redacted]
>     ssid [redacted]
>     type AP
>     wiphy 0
>     channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz
>
> # cat fw_stats
>
>              ath10k PDEV stats
>              =================
>
>            Channel noise floor       -108
>               Channel TX power         46
>                 TX frame count          0
>                 RX frame count          0
>                 RX clear count          0
>                    Cycle count        941
>                PHY error count       2612
>                  RTS bad count          0
>                 RTS good count          0
>                  FCS bad count        426
>                No beacon count          0
>                  MIB int count   48158964
>
>           ath10k PDEV TX stats
>              =================
>
>             HTT cookies queued      15887
>              HTT cookies disp.      15887
>                    MSDU queued      21200
>                    MPDU queued      20982
>                  MSDUs dropped          0
>                   Local enqued       5313
>                    Local freed       5313
>                      HW queued      21655
>                   PPDUs reaped      21655
>                  Num underruns          0
>                  PPDUs cleaned          0
>                   MPDUs requed        776
>              Excessive retries        767
>                        HW rate          3
>             Sched self tiggers        334
>      Dropped due to SW retries          0
>        Illegal rate phy errors          0
>          Pdev continous xretry          0
>                     TX timeout          0
>                    PDEV resets          0
>                   PHY underrun          0
>   MPDU is more than txop limit          0
>
>           ath10k PDEV RX stats
>              =================
>
>          Mid PPDU route change          0
>        Tot. number of statuses      52787
>         Extra frags on rings 0          0
>         Extra frags on rings 1          0
>         Extra frags on rings 2          1
>         Extra frags on rings 3          0
>         MSDUs delivered to HTT      52787
>         MPDUs delivered to HTT      52263
>       MSDUs delivered to stack      37576
>       MPDUs delivered to stack      37576
>                Oversized AMSUs          0
>                     PHY errors          0
>               PHY errors drops       2610
>    MPDU errors (FCS, MIC, ENC)       3129
>
>              ath10k PEER stats (1)
>              =================
>
>               Peer MAC address 3c:15:c2:[redacted]
>                      Peer RSSI 40
>                   Peer TX rate 975000
>                   Peer RX rate 877500
>
>
> This is with the a brand-new OpenWRT build that (finally!) has a
> correct board.bin for the card.
>
> Is this possibly a rate control issue?  A firmware issue?  Is there
> something else I can do to give a more helpful bug report?
>
>
> Thanks,
> Andy
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k tx to a Macbook Pro stalls

[Kalle Valo]

Andy Lutomirski <luto@amacapital.net> writes:

> On my Archer C7 v2, as soon as the MBP tries to do something like
> playing a video, it seems like frames *to* the MBP no longer get
> there.  At the very least, arp replies don't get there.

A multicast problem? Can you run for example 'arping -b <macbook's ip>'
to check if multicast stops working at some point? What if you hardcode
the ARP address, do unicast packets go to the macbook still?

If there are multicast problems, my first suspect is always power save.
Is there a way to disable power save on the macbook for narrowing down
the problem?

Also we had discussion about macbook problems before and aggreation came
up as one suspect. Now we have a debugfs interface to change aggregation
settings, but I doubt openwrt has that yet. Check the archives for more.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k tx to a Macbook Pro stalls

[Andy Lutomirski]

On Mon, Jul 21, 2014 at 11:31 AM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>> On my Archer C7 v2, as soon as the MBP tries to do something like
>> playing a video, it seems like frames *to* the MBP no longer get
>> there.  At the very least, arp replies don't get there.
>
> A multicast problem? Can you run for example 'arping -b <macbook's ip>'
> to check if multicast stops working at some point? What if you hardcode
> the ARP address, do unicast packets go to the macbook still?

I thought that ARP replies were unicast.  Certainly my laptop replies
to ARP requests with a unicast frame to the requester.

I was also unable to ping the MBP from my laptop, which suggests that
broadcasts were also not being received.  But I could have gotten
confused there.

>
> If there are multicast problems, my first suspect is always power save.
> Is there a way to disable power save on the macbook for narrowing down
> the problem?

No clue.  I'll take a look.

>
> Also we had discussion about macbook problems before and aggreation came
> up as one suspect. Now we have a debugfs interface to change aggregation
> settings, but I doubt openwrt has that yet. Check the archives for more.

This problem seems to be sporadic enough that it's hard to tell, but
changing the AP's mode from VHT80 to HT40 seems to have solved the
problem.

I'll try to reproduce this later tonight and see if I can learn more.

--Andy

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k tx to a Macbook Pro stalls

[Andy Lutomirski]

On Mon, Jul 21, 2014 at 11:31 AM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>> On my Archer C7 v2, as soon as the MBP tries to do something like
>> playing a video, it seems like frames *to* the MBP no longer get
>> there.  At the very least, arp replies don't get there.
>
> A multicast problem? Can you run for example 'arping -b <macbook's ip>'
> to check if multicast stops working at some point? What if you hardcode
> the ARP address, do unicast packets go to the macbook still?

It's a unicast problem, actually.  arping -b works.  arping w/o -b
gets one reply.

arp -s <IP> ff:ff:ff:ff:ff:ff allows me to ping the MBP (with
moderately high loss).  (I'm actually a bit surprised that Linux is
okay with that.)

Does this mean that the MBP is failing to notice TIM entries, or that
ath10k somehow stops buffering packets to power-saving stations?

>
> If there are multicast problems, my first suspect is always power save.
> Is there a way to disable power save on the macbook for narrowing down
> the problem?
>
> Also we had discussion about macbook problems before and aggreation came
> up as one suspect. Now we have a debugfs interface to change aggregation
> settings, but I doubt openwrt has that yet. Check the archives for more.

I'll keep an eye out for it.

--Andy

>
> --
> Kalle Valo



-- 
Andy Lutomirski
AMA Capital Management, LLC

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k tx to a Macbook Pro stalls

[Michal Kazior]

On 22 July 2014 06:12, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Jul 21, 2014 at 11:31 AM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>>> On my Archer C7 v2, as soon as the MBP tries to do something like
>>> playing a video, it seems like frames *to* the MBP no longer get
>>> there.  At the very least, arp replies don't get there.
>>
>> A multicast problem? Can you run for example 'arping -b <macbook's ip>'
>> to check if multicast stops working at some point? What if you hardcode
>> the ARP address, do unicast packets go to the macbook still?
>
> It's a unicast problem, actually.  arping -b works.  arping w/o -b
> gets one reply.
>
> arp -s <IP> ff:ff:ff:ff:ff:ff allows me to ping the MBP (with
> moderately high loss).  (I'm actually a bit surprised that Linux is
> okay with that.)
>
> Does this mean that the MBP is failing to notice TIM entries, or that
> ath10k somehow stops buffering packets to power-saving stations?

Do you have u-APSD enabled in your OpenWRT configuration by any chance?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k tx to a Macbook Pro stalls

[Andy Lutomirski]

On Mon, Jul 28, 2014 at 11:26 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 22 July 2014 06:12, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Mon, Jul 21, 2014 at 11:31 AM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>> Andy Lutomirski <luto@amacapital.net> writes:
>>>
>>>> On my Archer C7 v2, as soon as the MBP tries to do something like
>>>> playing a video, it seems like frames *to* the MBP no longer get
>>>> there.  At the very least, arp replies don't get there.
>>>
>>> A multicast problem? Can you run for example 'arping -b <macbook's ip>'
>>> to check if multicast stops working at some point? What if you hardcode
>>> the ARP address, do unicast packets go to the macbook still?
>>
>> It's a unicast problem, actually.  arping -b works.  arping w/o -b
>> gets one reply.
>>
>> arp -s <IP> ff:ff:ff:ff:ff:ff allows me to ping the MBP (with
>> moderately high loss).  (I'm actually a bit surprised that Linux is
>> okay with that.)
>>
>> Does this mean that the MBP is failing to notice TIM entries, or that
>> ath10k somehow stops buffering packets to power-saving stations?
>
> Do you have u-APSD enabled in your OpenWRT configuration by any chance?

How do I tell?  The docs seem out of date here.  I have:

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11a'
    option path 'pci0000:01/0000:01:00.0'
    option htmode 'VHT80'
    #option htmode 'HT40'
    option disabled '0'
    option channel '149'

The relevant part (I think) of /var/run/hostapd.conf is:

ieee80211n=1
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40
]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=155
ieee80211ac=1
vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PA
TTERN][RX-STBC1][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]

--Andy

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k tx to a Macbook Pro stalls

[Michal Kazior]

On 29 July 2014 19:52, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Jul 28, 2014 at 11:26 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
>> On 22 July 2014 06:12, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Mon, Jul 21, 2014 at 11:31 AM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>>> Andy Lutomirski <luto@amacapital.net> writes:
[...]
>>> Does this mean that the MBP is failing to notice TIM entries, or that
>>> ath10k somehow stops buffering packets to power-saving stations?
>>
>> Do you have u-APSD enabled in your OpenWRT configuration by any chance?
>
> How do I tell?  The docs seem out of date here.  I have:
>
> config wifi-device 'radio0'
>     option type 'mac80211'
>     option hwmode '11a'
>     option path 'pci0000:01/0000:01:00.0'
>     option htmode 'VHT80'
>     #option htmode 'HT40'
>     option disabled '0'
>     option channel '149'
>
> The relevant part (I think) of /var/run/hostapd.conf is:
>
> ieee80211n=1
> ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40
> ]
> vht_oper_chwidth=1
> vht_oper_centr_freq_seg0_idx=155
> ieee80211ac=1
> vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PA
> TTERN][RX-STBC1][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]

Do you have `uapsd_advertisement_enabled=1` set in /var/run/hostapd.conf?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: ath10k tx to a Macbook Pro stalls

[Andy Lutomirski]

On Tue, Jul 29, 2014 at 11:15 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 29 July 2014 19:52, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Mon, Jul 28, 2014 at 11:26 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
>>> On 22 July 2014 06:12, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> On Mon, Jul 21, 2014 at 11:31 AM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>>>> Andy Lutomirski <luto@amacapital.net> writes:
> [...]
>>>> Does this mean that the MBP is failing to notice TIM entries, or that
>>>> ath10k somehow stops buffering packets to power-saving stations?
>>>
>>> Do you have u-APSD enabled in your OpenWRT configuration by any chance?
>>
>> How do I tell?  The docs seem out of date here.  I have:
>>
>> config wifi-device 'radio0'
>>     option type 'mac80211'
>>     option hwmode '11a'
>>     option path 'pci0000:01/0000:01:00.0'
>>     option htmode 'VHT80'
>>     #option htmode 'HT40'
>>     option disabled '0'
>>     option channel '149'
>>
>> The relevant part (I think) of /var/run/hostapd.conf is:
>>
>> ieee80211n=1
>> ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40
>> ]
>> vht_oper_chwidth=1
>> vht_oper_centr_freq_seg0_idx=155
>> ieee80211ac=1
>> vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PA
>> TTERN][RX-STBC1][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]
>
> Do you have `uapsd_advertisement_enabled=1` set in /var/run/hostapd.conf?
>

Here's the whole file, with the obvious redactions:

driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
hw_mode=a
channel=149

ieee80211n=1
ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=155
ieee80211ac=1
vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC1][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]

interface=wlan0
ctrl_interface=/var/run/hostapd
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
wpa_passphrase=PASSPHRASE
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=Aether Wind
bridge=br-lan
okc=0
disable_pmksa_caching=1
macaddr_acl=0
deny_mac_file=/var/run/hostapd-wlan0.maclist
bssid=BSSID

--Andy

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k