wrtpat wrote:Greetings OpenWRT community. I've been lurking here, reading and learning, for some time. I think it's time to jump into the fray.
I've built my own image from the latest trunk (R44464), and flashed it to the WRT1900AC. All went as expected.
That is until I try to wirelessly connect my daily driver laptop, a MacBook Pro (late 2011) running Mac OS Yosemite 10.10.2
The MacBook connects ok, but then disconnects 25-30 seconds later. Well, sort of disconnects. It shows as "associated" but I can no longer access anything on the network. Immediately after establishing the wireless connection, I can ping the default gw (ie. 192.168.1.1). But 25-30 seconds later can no longer ping it.
The problem happens on both 2.4Ghz and 5Ghz. And it only seems to happen when wireless security is in effect - either WPA2-PSK (AES) or WPA2-PSK (TKIP). It doesn't happen if wireless security is turned off.
This same MacBook Pro is able to wirelessly connect to the following without any problem - using WPA2-PSK (TKIP);
- The exact same WRT1900AC hardware running the Linksys factory/OEM firmware.
- A NetGear R7000
- My old [before it died] WRT54G
So, I'm thinking this has to be a problem with either the latest trunk code, or the Marvell wireless drivers therein.
Has anyone out there run into this, and know how to fix it?
Anyone have any guidance on how to debug this? Being so new to OpenWRT, I'm not "up" on the ins/outs of debugging in this environment, and would welcome any guidance.
BTW, as mentioned some pages back in this thread, I have done the following;
uci set wireless.@wifi-iface[0].disassoc_low_ack=0
uci set wireless.@wifi-iface[1].disassoc_low_ack=0
uci commit
wifi
It has not helped.
Thanks for any help. And thanks to all those here who contribute. Great stuff going on here.
I think I have a working solution for this.
Since making that post a few weeks back, I’ve been busy working on finding a solution to the problem. I think I’ve got something worthy of analysis by the greater community.
Here goes…..
Mac OS (10.10.2 Yosemite in my case), for whatever reason, appears to re-auth/re-associate within approximately 25 seconds of initially associating. Don’t know why (Apple logs would lead you to believe the Mac thinks you've roamed). Specifically, the following can be seen in the Apple system log;
MM/DD/YY HH:MM:SS.sss AM kernel[0]: wl0: Roamed or switched channel, reason #8, bssid xx:xx:xx:xx:xx:xx
Even though there has been no channel change, and I have not roamed.... Oh well, it is what it is.
Anyway, long-story-short, it appears the Marvell driver isn’t generating a NL80211_CMD_FRAME_TX_STATUS event on xmiting a response to a reassociate request. Thus, the reasssoc_resp_cb callback function (in hostapd’s ieee802_11.c) never gets driven, ultimately leading to the problem.
I’ve made the following simple change to the Marvel driver code -
filename = build_dir/target-arm_cortex-a9+vfpv3_uClibc-0.9.33.2_eabi/linux-mvebu/mwlwifi-10.2.6.1.p4-20141228/mwl_tx.c
Change line 398
from;
if (ieee80211_is_assoc_resp(tr->wh.frame_control)) {
to;
if (ieee80211_is_assoc_resp(tr->wh.frame_control) ||
ieee80211_is_reassoc_resp(tr->wh.frame_control) ||
ieee80211_is_auth(tr->wh.frame_control)) {
My MacBook now connects and stays connected… Yay!
I initially did the testing on R44464 trunk.
This morning, I integrated the change into a fresh build of latest trunk (R44783), and it seems to be working well there too.
Thought I would put it out there, for others in the greater community to test/consider/comment.
It's quite possible the change has implications for devices other than Mac. Since I don't have access to every possible device type that someone might want to connect with, it would be good if others out there could give it a go and report findings.
(Last edited by wrtpat on 15 Mar 2015, 17:59)