Re: flaky network connection after 6.1 upgrade

[Stefan Sperling]

On Sun, Apr 23, 2017 at 10:46:56PM +0200, Stefan Sperling wrote:
> Your other option is to stop reading now, forget about athn for now,
> and use some other AP.

I got mixed up between problem reports in my inbox. You have an athn
client, not an athn AP. Sorry about that.

A pcap file showing your athn client interacting with your AP would still be
very interesting. Please collect separate pcaps for 11b, 11g, and 11n mode.

Re: flaky network connection after 6.1 upgrade

[Stefan Sperling]

On Sat, Apr 22, 2017 at 03:49:35PM -0500, Colton Lewis wrote:
> I applied the patch and compiled a new kernel using the stable branch.
> 11n and 11g both work now,
> but with significantly worse performance than 11b. Downloads are about
> 40% slower.
> 
> $ curl http://download.thinkbroadband.com/200MB.zip -O
> was my test.

Thanks for testing this fix. I will commit it shortly.

The performance issues with athn are known and unrelated to my diff.
Performance with athn is worse than what e.g. iwm(4) clients get with
commercial APs. Obviously there is a lot of work left to do and
very many things to fix.

My own priority right now is that 11n support with athn is stable,
i.e. does not crash and does not drop out entirely for no good reason.
So far, this seems to be the case.

It is already fast enough for my own needs inspite of some issues.
E.g. my athn AP never transmits with rates higher than MCS 12. I don't
know why it never goes up to MCS 15. It sucks pretty badly on 2 GHz but
works fine on 5. There are many networks on 2 GHz around here which are
very active at times. I have gotten reports from people living out
in the country where they can use 2 GHz just fine, though.

It's not entirely clear to me where issues other people are reporting are
coming from. Do they see what I see or is it actually worse for them?
I have no way of knowing.

So far nobody who complained about performance has provided pcap files
of their traffic that are actually useful for debugging. Before I can do
anything to improve performance, you must capture some interesting pcap data.
Your other option is to stop reading now, forget about athn for now,
and use some other AP.

To capture a pcap file, you need an iwn interface.

Associate your client and figure out the channel of your AP.
Below I will use channel 5 as an example.

On your iwn device, prepare monitor mode (assuming unconfigured default state):

ifconfig iwn0 mediaopt monitor
ifconfig iwn0 chan 5
ifconfig iwn0 up

Verify that iwn is receiving on channel 5:

tcpdump -n -i iwn0 -y IEEE802_11_RADIO

The last part of each line should show the channel:



I have seen a quirk every now and then where the channel is not
set up correctly the first time through. If it's not listening
on the right channel yet, try again with:

ifconfig iwn0 down
ifconfig iwn0 chan 5
ifconfig iwn0 up
tcpdump -n -i iwn0 -y IEEE802_11_RADIO

Once the channel is OK, you can run this to capture any frames the
hardware can receive:

tcpdump -n -i iwn0 -y IEEE802_11_RADIO -s 4096 -w /tmp/iwn.pcap

Now do whatever on the client to provoke the low performance situation.
Leave the monitor running during this time. Ideally, give the monitor
30 seconds of margin around your experiments so we can see what's
going on while your client is idle.

Now zip the pcap file and send it to me, and tell me the MAC addresses
of your AP and your client involved in the speed test.

I will run wireshark (as non-root) to view the pcap file:

wireshark /tmp/iwn.pcap

The interesting bits of information can be seen in the lower pane in the
'802.11 radio information' section and the '802.11 ... frame' section.
The 'Wireless' -> 'WLAN Traffic' statistics menu is also useful.

Things I will be looking for include:

What transmit rates are reported for packets sent from/to your client?
Are there beacons, RTS and/or data frames from other networks?
How many frames are marked as retries?
What is the ratio of RTS vs data frames?
Is the client doing power saving and how does the AP handle this?

Ideally, we'll be able to figure out what kind of traffic the available
air time on your channel is spent on, and whether the AP is actually
misbehaving in some way.

Re: flaky network connection after 6.1 upgrade

[Colton Lewis]

On Thu, Apr 20, 2017 at 5:31 AM, Stefan Sperling  wrote:
> On Wed, Apr 19, 2017 at 10:08:01AM +0200, Stefan Sperling wrote:
>> On Tue, Apr 18, 2017 at 11:29:22PM -0500, Colton Lewis wrote:
>> > > Can you show me a dmesg please, specifically the lines which are
>> > > related to your wifi card?
>>
>> > athn0 at pci6 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 8 int 17
>> > athn0: AR9280 rev 2 (1T2R), ROM rev 11, address 00:15:af:cd:f2:4f
>>
>> Thank you! This confirms my suspicion that your wifi card is a weird one.
>> It can receive MIMO but cannot send MIMO (2 Rx chains but only 1 Tx chain).
>>
>> Likely there's a bug in the code which fails to account for this situation.
>> AFAIK this kind of device has not been tested before.
>>
>> I'll take a look.
>
> Please try this patch.
>
> This patch makes unequal numbers of Tx and Rx streams work in 11n mode.
> I have tested this patch by artificially limiting iwm(4) to one Tx stream.
> This works as expected (AP sends with two streams, iwm(4) sends with one).
>
> I still cannot explain why 11g mode became worse for you such that only 11b
> mode works. I cannot recall any change which would make a difference between
> 6.0 and 6.1 in that regard. Are you sure you were testing 11g mode correctly?
> When you switched your athn client to 11g mode, did your AP follow this change
> or did it continue treating your client as 11n capable? A quirk like that
> would explain this discrepancy.
>
> Index: sys/net80211/ieee80211.h
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211.h,v
> retrieving revision 1.58
> diff -u -p -r1.58 ieee80211.h
> --- sys/net80211/ieee80211.h12 May 2016 18:18:48 -  1.58
> +++ sys/net80211/ieee80211.h19 Apr 2017 13:47:13 -
> @@ -612,8 +612,8 @@ enum {
>  /* Bits 96-100: Tx MCS set */
>  #define IEEE80211_TX_MCS_SET_DEFINED   0x01
>  #define IEEE80211_TX_RX_MCS_NOT_EQUAL  0x02
> -#define IEEE80211_TX_SPATIAL_STREAMS   0x18
> -#define IEEE80211_TX_UNEQUAL_MODULATION0x20
> +#define IEEE80211_TX_SPATIAL_STREAMS   0x0c
> +#define IEEE80211_TX_UNEQUAL_MODULATION0x10
>  /* Bits 101-127: Reserved */
>
>  /*
> Index: sys/net80211/ieee80211_mira.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_mira.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 ieee80211_mira.c
> --- sys/net80211/ieee80211_mira.c   28 Jan 2017 16:01:36 -  1.10
> +++ sys/net80211/ieee80211_mira.c   20 Apr 2017 09:37:53 -
> @@ -81,6 +81,7 @@ int   ieee80211_mira_check_probe_timers(st
> struct ieee80211_node *);
>  void   ieee80211_mira_probe_next_rate(struct ieee80211_mira_node *,
> struct ieee80211_node *);
> +intieee80211_mira_valid_tx_mcs(struct ieee80211com *, int);
>  uint32_t ieee80211_mira_valid_rates(struct ieee80211com *,
> struct ieee80211_node *);
>  uint32_t ieee80211_mira_mcs_below(struct ieee80211_mira_node *, int);
> @@ -991,6 +992,21 @@ ieee80211_mira_probe_next_rate(struct ie
> ni->ni_txmcs = ieee80211_mira_next_mcs(mn, ni);
>  }
>
> +int
> +ieee80211_mira_valid_tx_mcs(struct ieee80211com *ic, int mcs)
> +{
> +   uint32_t ntxstreams = 1;
> +   static const int max_mcs[] = { 7, 15, 23, 31 };
> +
> +   if ((ic->ic_tx_mcs_set & IEEE80211_TX_RX_MCS_NOT_EQUAL) == 0)
> +   return isset(ic->ic_sup_mcs, mcs);
> +
> +   ntxstreams += ((ic->ic_tx_mcs_set & IEEE80211_TX_SPATIAL_STREAMS) >> 
> 2);
> +   if (ntxstreams < 1 || ntxstreams > 4)
> +   panic("invalid number of Tx streams: %u", ntxstreams);
> +   return (mcs <= max_mcs[ntxstreams - 1] && isset(ic->ic_sup_mcs, mcs));
> +}
> +
>  uint32_t
>  ieee80211_mira_valid_rates(struct ieee80211com *ic, struct ieee80211_node 
> *ni)
>  {
> @@ -999,8 +1015,11 @@ ieee80211_mira_valid_rates(struct ieee80
>
> for (i = 0;
> i < MIN(IEEE80211_MIRA_NUM_MCS, IEEE80211_HT_NUM_MCS); i++) {
> -   if (isset(ic->ic_sup_mcs, i) && isset(ni->ni_rxmcs, i))
> -   valid_mcs |= (1 << i);
> +   if (!isset(ni->ni_rxmcs, i))
> +   continue;
> +   if (!ieee80211_mira_valid_tx_mcs(ic, i))
> +   continue;
> +   valid_mcs |= (1 << i);
> }
>
> return valid_mcs;

I applied the patch and compiled a new kernel using the stable branch.
11n and 11g both work now,
but with significantly worse performance than 11b. Downloads are about
40% slower.

$ curl http://download.thinkbroadband.com/200MB.zip -O
was my test.

Re: flaky network connection after 6.1 upgrade

[Stefan Sperling]

On Wed, Apr 19, 2017 at 10:08:01AM +0200, Stefan Sperling wrote:
> On Tue, Apr 18, 2017 at 11:29:22PM -0500, Colton Lewis wrote:
> > > Can you show me a dmesg please, specifically the lines which are
> > > related to your wifi card?
> 
> > athn0 at pci6 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 8 int 17
> > athn0: AR9280 rev 2 (1T2R), ROM rev 11, address 00:15:af:cd:f2:4f
> 
> Thank you! This confirms my suspicion that your wifi card is a weird one.
> It can receive MIMO but cannot send MIMO (2 Rx chains but only 1 Tx chain).
> 
> Likely there's a bug in the code which fails to account for this situation.
> AFAIK this kind of device has not been tested before.
> 
> I'll take a look.

Please try this patch.

This patch makes unequal numbers of Tx and Rx streams work in 11n mode.
I have tested this patch by artificially limiting iwm(4) to one Tx stream.
This works as expected (AP sends with two streams, iwm(4) sends with one).

I still cannot explain why 11g mode became worse for you such that only 11b
mode works. I cannot recall any change which would make a difference between
6.0 and 6.1 in that regard. Are you sure you were testing 11g mode correctly?
When you switched your athn client to 11g mode, did your AP follow this change
or did it continue treating your client as 11n capable? A quirk like that
would explain this discrepancy.

Index: sys/net80211/ieee80211.h
===
RCS file: /cvs/src/sys/net80211/ieee80211.h,v
retrieving revision 1.58
diff -u -p -r1.58 ieee80211.h
--- sys/net80211/ieee80211.h12 May 2016 18:18:48 -  1.58
+++ sys/net80211/ieee80211.h19 Apr 2017 13:47:13 -
@@ -612,8 +612,8 @@ enum {
 /* Bits 96-100: Tx MCS set */
 #define IEEE80211_TX_MCS_SET_DEFINED   0x01
 #define IEEE80211_TX_RX_MCS_NOT_EQUAL  0x02
-#define IEEE80211_TX_SPATIAL_STREAMS   0x18
-#define IEEE80211_TX_UNEQUAL_MODULATION0x20
+#define IEEE80211_TX_SPATIAL_STREAMS   0x0c
+#define IEEE80211_TX_UNEQUAL_MODULATION0x10
 /* Bits 101-127: Reserved */
 
 /*
Index: sys/net80211/ieee80211_mira.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_mira.c,v
retrieving revision 1.10
diff -u -p -r1.10 ieee80211_mira.c
--- sys/net80211/ieee80211_mira.c   28 Jan 2017 16:01:36 -  1.10
+++ sys/net80211/ieee80211_mira.c   20 Apr 2017 09:37:53 -
@@ -81,6 +81,7 @@ int   ieee80211_mira_check_probe_timers(st
struct ieee80211_node *);
 void   ieee80211_mira_probe_next_rate(struct ieee80211_mira_node *,
struct ieee80211_node *);
+intieee80211_mira_valid_tx_mcs(struct ieee80211com *, int);
 uint32_t ieee80211_mira_valid_rates(struct ieee80211com *,
struct ieee80211_node *);
 uint32_t ieee80211_mira_mcs_below(struct ieee80211_mira_node *, int);
@@ -991,6 +992,21 @@ ieee80211_mira_probe_next_rate(struct ie
ni->ni_txmcs = ieee80211_mira_next_mcs(mn, ni);
 }
 
+int
+ieee80211_mira_valid_tx_mcs(struct ieee80211com *ic, int mcs)
+{
+   uint32_t ntxstreams = 1;
+   static const int max_mcs[] = { 7, 15, 23, 31 };
+
+   if ((ic->ic_tx_mcs_set & IEEE80211_TX_RX_MCS_NOT_EQUAL) == 0)
+   return isset(ic->ic_sup_mcs, mcs);
+
+   ntxstreams += ((ic->ic_tx_mcs_set & IEEE80211_TX_SPATIAL_STREAMS) >> 2);
+   if (ntxstreams < 1 || ntxstreams > 4)
+   panic("invalid number of Tx streams: %u", ntxstreams);
+   return (mcs <= max_mcs[ntxstreams - 1] && isset(ic->ic_sup_mcs, mcs));
+}
+
 uint32_t
 ieee80211_mira_valid_rates(struct ieee80211com *ic, struct ieee80211_node *ni)
 {
@@ -999,8 +1015,11 @@ ieee80211_mira_valid_rates(struct ieee80
 
for (i = 0;
i < MIN(IEEE80211_MIRA_NUM_MCS, IEEE80211_HT_NUM_MCS); i++) {
-   if (isset(ic->ic_sup_mcs, i) && isset(ni->ni_rxmcs, i))
-   valid_mcs |= (1 << i);
+   if (!isset(ni->ni_rxmcs, i))
+   continue;
+   if (!ieee80211_mira_valid_tx_mcs(ic, i))
+   continue;
+   valid_mcs |= (1 << i);
}
 
return valid_mcs;

Re: flaky network connection after 6.1 upgrade

[Colton Lewis]

> Can you show me a dmesg please, specifically the lines which are
> related to your wifi card?
athn0 at pci6 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 8 int 17
athn0: AR9280 rev 2 (1T2R), ROM rev 11, address 00:15:af:cd:f2:4f

Re: flaky network connection after 6.1 upgrade

[Stefan Sperling]

On Tue, Apr 18, 2017 at 01:15:38AM -0500, Colton Lewis wrote:
> I tried channels 2, 5, and 10 with no better luck.
> 
> Could you explain what made you think interference?
> My computer and AP have been in their current spots for months with no
> issue, and no new sources of come around
> to the best of my knowledge. I had no networking trouble with 6.0 and
> booting Linux from a CD is likewise without issue.
> 
> My BSD system will fail to ping my AP with "sendmsg: Host is down",
> yet I can bring a laptop to that same chair
> and have no problem.

Can you show me a dmesg please, specifically the lines which are
related to your wifi card?

Re: flaky network connection after 6.1 upgrade

[Colton Lewis]

I tried channels 2, 5, and 10 with no better luck.

Could you explain what made you think interference?
My computer and AP have been in their current spots for months with no
issue, and no new sources of come around
to the best of my knowledge. I had no networking trouble with 6.0 and
booting Linux from a CD is likewise without issue.

My BSD system will fail to ping my AP with "sendmsg: Host is down",
yet I can bring a laptop to that same chair
and have no problem.


On Mon, Apr 17, 2017 at 2:35 AM, Stefan Sperling  wrote:
> On Sun, Apr 16, 2017 at 05:31:58PM -0500, Colton Lewis wrote:
>> Stephan,
>>
>> > I would guess you are running into some issue with 802.11n support which
>> > was added to this driver in 6.1. You should be able to restore the previous
>> > behaviour with: ifconfig athn0 mode 11g
>>
>> Your hunch was almost right. 11g had the same problem, but 11b worked
>> as expected.
>
> Looks like too much interference from other networks (try a different channel)
> or too large distance from the AP.
>
>> Attached is the info you asked for.
>> 17:05:52.707822 802.11 flags=0<>: beacon, 
>> caps=12021, ssid (Stormlord), 
>> rates 1M* 2M* 5M 11M 18M 24M 36M 54M, ds (chan 9), tim 0x0102, erp 0x04, 
>> xrates 6M 9M 12M 48M, rsn 0x010fac04010fac04010fac020c00, 6 
>> stations, 4% utilization, admission capacity 0us/s, 70:5 0x320801, 
>> htcaps=<20MHz,LDPC,SGI@20MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 7935,A-MPDU max 
>> 65535,A-MPDU spacing 4.00us,RxMCS 0xff00>, htop=<20MHz chan 
>> 9,STA chanw 20MHz,RIFS,htprot none,non-greenfield STA,basic MCS set 
>> 0x>, 74:14 0x14000a002c01c800140005001900, 127:8 
>> 0x05000840, vendor 0x00146c00, vendor 
>> 0x0050f204104a0001101044000102104700102a1ecc3b122c82e30b19d406361deb33103c0001031049000600372a000120,
>>  vendor 0x00904c0408bf0cb259820feaffeaffc005000900c3020002, 
>> vendor 0x0010180206001c, vendor 
>> 0x0050f2020101880003a427a44243bc0062326600, > chan 9, 11n, sig 13dBm, antenna 1>
>> athn0: flags=8843 mtu 1500
>>   lladdr 00:15:af:cd:f2:4f
>>   index 2 priority 4 llprio 3
>>   groups: wlan egress
>>   media: IEEE802.11 autoselect (HT-MCS1 mode 11n)
>>   status: active
>>   ieee80211: nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm wpakey 
>>  wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher 
>> ccmp
>>   inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255
>>   nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm HT-MCS23 
>> privacy,short_slottime,radio_measurement,wpa2
>>   inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255
>>

Re: flaky network connection after 6.1 upgrade

[Stefan Sperling]

On Sun, Apr 16, 2017 at 05:31:58PM -0500, Colton Lewis wrote:
> Stephan,
>
> > I would guess you are running into some issue with 802.11n support which
> > was added to this driver in 6.1. You should be able to restore the
previous
> > behaviour with: ifconfig athn0 mode 11g
>
> Your hunch was almost right. 11g had the same problem, but 11b worked
> as expected.

Looks like too much interference from other networks (try a different
channel)
or too large distance from the AP.

> Attached is the info you asked for.
> 17:05:52.707822 802.11 flags=0<>: beacon,
caps=12021, ssid (Stormlord),
rates 1M* 2M* 5M 11M 18M 24M 36M 54M, ds (chan 9), tim 0x0102, erp 0x04,
xrates 6M 9M 12M 48M, rsn 0x010fac04010fac04010fac020c00, 6
stations, 4% utilization, admission capacity 0us/s, 70:5 0x320801,
htcaps=<20MHz,LDPC,SGI@20MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 7935,A-MPDU max
65535,A-MPDU spacing 4.00us,RxMCS 0xff00>, htop=<20MHz chan
9,STA chanw 20MHz,RIFS,htprot none,non-greenfield STA,basic MCS set
0x>, 74:14 0x14000a002c01c800140005001900, 127:8
0x05000840, vendor 0x00146c00, vendor
0x0050f204104a0001101044000102104700102a1ecc3b122c82e30b19d406361deb33103c000
1031049000600372a000120, vendor
0x00904c0408bf0cb259820feaffeaffc005000900c3020002, vendor
0x0010180206001c, vendor
0x0050f2020101880003a427a44243bc0062326600, 
> athn0: flags=8843 mtu 1500
>   lladdr 00:15:af:cd:f2:4f
>   index 2 priority 4 llprio 3
>   groups: wlan egress
>   media: IEEE802.11 autoselect (HT-MCS1 mode 11n)
>   status: active
>   ieee80211: nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm wpakey 
>  wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
>   inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255
>   nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm HT-MCS23
privacy,short_slottime,radio_measurement,wpa2
>   inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255

Re: flaky network connection after 6.1 upgrade

[Colton Lewis]

Stephan,

> I would guess you are running into some issue with 802.11n support which
> was added to this driver in 6.1. You should be able to restore the previous
> behaviour with: ifconfig athn0 mode 11g

Your hunch was almost right. 11g had the same problem, but 11b worked
as expected.

Attached is the info you asked for.
17:05:52.707822 802.11 flags=0<>: beacon, 
caps=12021, ssid (Stormlord), 
rates 1M* 2M* 5M 11M 18M 24M 36M 54M, ds (chan 9), tim 0x0102, erp 0x04, 
xrates 6M 9M 12M 48M, rsn 0x010fac04010fac04010fac020c00, 6 
stations, 4% utilization, admission capacity 0us/s, 70:5 0x320801, 
htcaps=<20MHz,LDPC,SGI@20MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 7935,A-MPDU max 
65535,A-MPDU spacing 4.00us,RxMCS 0xff00>, htop=<20MHz chan 
9,STA chanw 20MHz,RIFS,htprot none,non-greenfield STA,basic MCS set 
0x>, 74:14 0x14000a002c01c800140005001900, 127:8 
0x05000840, vendor 0x00146c00, vendor 
0x0050f204104a0001101044000102104700102a1ecc3b122c82e30b19d406361deb33103c0001031049000600372a000120,
 vendor 0x00904c0408bf0cb259820feaffeaffc005000900c3020002, vendor 
0x0010180206001c, vendor 
0x0050f2020101880003a427a44243bc0062326600, 
athn0: flags=8843 mtu 1500
lladdr 00:15:af:cd:f2:4f
index 2 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS1 mode 11n)
status: active
ieee80211: nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm wpakey 
 wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255
nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm HT-MCS23 
privacy,short_slottime,radio_measurement,wpa2 
inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255

Re: flaky network connection after 6.1 upgrade

[Stefan Sperling]

On Sat, Apr 15, 2017 at 10:06:44PM -0500, Colton Lewis wrote:
> After upgrading to 6.1, I have been unable to maintain an internet
> connection for more than a few seconds at a time.
> 
> The machine in question uses an Atheros AR9281 for a wifi connection.
> All other machines on that wifi network have no problems. The Atheros
> card worked perfectly yesterday.
> 
> Pinging the machine over a long period of time gives about 40% packet
> loss. Trying to access the internet in any way often seems to work for
> a few seconds, then hangs.
> 
> It may work in short spurts over the next couple of minutes before
> hanging for good. I have monitored this with tcpdump and noticed no
> tcp packets sent when the connection is hung.
> 
> What could be happening and how can I fix this?
> 
> Sincerely,
> Colton Lewis

I would guess you are running into some issue with 802.11n support which
was added to this driver in 6.1. You should be able to restore the previous
behaviour with: ifconfig athn0 mode 11g

Please tell me more details about your setup. Which AP you are using, how
you configure the athn0 interface (output of ifconfig athn0 as a non-root
user), whether your wifi is alone on its channel or not (show the output
of ifconfig athn0 scan).

Also show me beacons of your AP. Connect to your AP as usual, and then run:
  tcpdump -n -i athn0 -y IEEE802_11_RADIO -v -s 4096 -l | grep beacon
This prints one line per beacon received. Please show me one such line.