On Thu, Mar 21, 2019 at 09:55:09PM -0600, martian67 wrote:
> Should also note that without your patch perhaps the speed was slightly
> more stable, its difficult to be certain, but it was definitely still 
> hitting 0 a lot, with randomly high pings.

Your AP is sending a lot of retries which is why speed is so low.
The assoc problems you are seeing are likely also due to this because
there are many of reties when the AP sends assoc responses.
I can't explain why this is happening but it looks like a driver bug.
I don't see this issue on my APs and I am not aware of anyone else seeing
this issue.

> Should also note again that this behavior definitely was not present in
> 6.4-stable, N mode wasn't really any faster than G mode, but both were 
> close to 54mbps (at least until the panic struck for N mode).

We need to figure out which change introduced excessive retries for you.

Given kernel images from http://ftp.hostserver.de/archive/ and the dates
of my commits to these files from OPENBSD_6_4 onwards:
http://cvsweb.openbsd.org/src/sys/dev/ic/athn.c
http://cvsweb.openbsd.org/src/sys/dev/ic/ar5008.c
Can you figure out which post-6.4 kernel image which first shows the issue?
The first commit happened on Jan 31 2018, so please try to confirm that
kernels before this date were OK and then move forward from there.

While looking at your pcap files, I realized my previous patch had a bug
with QoS frames using 'normal ACK' policy, which are sent by your client
device. Perhaps this version works a bit better in 11n mode, but it won't
fix your 'retry' problem.

diff 85d5a2d13c62494befd8404b760a73f8146aa70a /usr/src
blob - 24fd9c068968a041fcff497be8fdaa8705995001
file + sys/net80211/ieee80211_input.c
--- sys/net80211/ieee80211_input.c
+++ sys/net80211/ieee80211_input.c
@@ -210,11 +210,23 @@ ieee80211_input(struct ifnet *ifp, struct mbuf *m, str
                tid = 0;
        }
 
-       if (type == IEEE80211_FC0_TYPE_DATA && hasqos &&
+       if (ic->ic_state == IEEE80211_S_RUN &&
+           type == IEEE80211_FC0_TYPE_DATA && hasqos &&
            (subtype & IEEE80211_FC0_SUBTYPE_NODATA) == 0 &&
-           !(rxi->rxi_flags & IEEE80211_RXI_AMPDU_DONE)) {
+           !(rxi->rxi_flags & IEEE80211_RXI_AMPDU_DONE)
+#ifndef IEEE80211_STA_ONLY
+           && (ic->ic_opmode == IEEE80211_M_STA || ni != ic->ic_bss)
+#endif
+           ) {
                int ba_state = ni->ni_rx_ba[tid].ba_state;
 
+#ifndef IEEE80211_STA_ONLY
+               if (ic->ic_opmode == IEEE80211_M_HOSTAP &&
+                   !IEEE80211_ADDR_EQ(wh->i_addr1, ic->ic_bss->ni_bssid)) {
+                       ic->ic_stats.is_rx_wrongbss++;
+                       goto err;
+               }
+#endif
                /* 
                 * If Block Ack was explicitly requested, check
                 * if we have a BA agreement for this RA/TID.
@@ -222,6 +234,13 @@ ieee80211_input(struct ifnet *ifp, struct mbuf *m, str
                if ((qos & IEEE80211_QOS_ACK_POLICY_MASK) ==
                    IEEE80211_QOS_ACK_POLICY_BA &&
                    ba_state != IEEE80211_BA_AGREED) {
+#ifndef IEEE80211_STA_ONLY
+                       if (ic->ic_opmode == IEEE80211_M_HOSTAP &&
+                           ni->ni_state != IEEE80211_S_ASSOC) {
+                               ic->ic_stats.is_rx_notassoc++;
+                               goto err;
+                       }
+#endif
                        DPRINTF(("no BA agreement for %s, TID %d\n",
                            ether_sprintf(ni->ni_macaddr), tid));
                        /* send a DELBA with reason code UNKNOWN-BA */

Reply via email to