I’m prepared to help look at this a little, but stepping back, I’m not quite sure what the strategy is.
You tested the 4.4-main branch and successfully booted; great! (I probably didn’t install it correctly.) I can’t tell if you got WiFi client mode working though; did you?
If so, the 4.4-main branch makes a great base case to start from while debugging 4.9 or 4.14 drivers. Is that what you’re thinking? I can try to get 4.4-main working and trace the functions in 4.9 and/or 4.14 branches.
If not, I have almost no familiarity with WiFi driver code, and I’m not sure what I can do to help. If you feel like hand-holding me through some specific tests, I can do that if you think we can get it done in less than, say, ten iterations.
Best is if we can start from a known-working base case and compare with other branches.
i want 4.4 booting without errors (to verify client mode is working there) to have a base for comparing whats not working in 4.9…
but please try to find difference between 4.9 and 4.14 which was my main porting work…if we get 4.14 to same point as 4.9, i can patch all further versions.
comparing 4.4 to 4.9 may show us problem persists in 4.9. we cannot compare wifi-driver between 4.4 and 4.9 directly because much more has changed…we need to find problem in 4.9 (which is patch-base for 4.14+)
i cannot test wifi client-mode because it needs installing wpa-supplicant which breaks ap-mode
OK, as a first step I’m going to go back to 4.4 in hopes that client mode works, even though 4.9 is difficult to compare.
4.9 still doesn’t work, though; even though iwconfig wlan0 shows wireless extensions, the basic functionality of setting an ESSID doesn’t work. Getting 4.14 to that same state won’t help my case. (Sorry to be selfish when you’re so generous!)
You might be able to, actually: just set up an open AP; then you can test with iwconfig wlan0 essid myopenap. No wpa-supplicant required.
i know, that 4.9 does not work completely, but wifi-driver is very large codebase and i first need to know where i need to start…so we have a difference between the 4.9-code (that was my base for 4.14) and 4.14…anything in these (relatively small amount of) changes breaks first step of client-mode…if we have 4.14 at same state as 4.9 we can start at location we know to fix the rest of client-mode
It turns out that the 4.4-main branch has the same issues as 4.9-main: sudo iwconfig wlan0 essid myopenap prints the same kernel backtrace. Same as 4.9-main, the sudo iwlist wlan0 scan command successfully lists APs.
So that means we don’t have a working base case to start from. Even if we get 4.14 to the same state as 4.9, on-board WiFi in client mode still won’t work.
If you have any suggestion for how to fix this more fundamental problem, I’m interested. If so, I’d prefer to start with the 4.9 branch, since it appears a little closer to working than the 4.14 branch, and the 4.4 branch doesn’t seem to have support for the switch (based on my 5-minute trial just now).
ok, thanks for the test. so we start at 4.9 and need to know why connection fails.
as i wrote above the warning happens here:
so first we need to check if the bss-param of __cfg80211_connect_result is NULL/invalid. if it’s invalid we need to check where this function is called and where the wrong bss comes from
btw. 4.4 has support for switch, but no dsa-driver for separting all ports (eth0 are lan-ports, eth1 is wan-port).
I don’t think so…have not checked (already off),but it have not asked for pwd…so i guess it does not work. But also not the warning and not my debug-info
i guess it’s rejected before it…need to setup ap with my r64 first
Only running iwconfig wlan0 essid r2_AP0 won’t ask for a password; it will simply associate to the base station. Then it’s up to wpa-supplicant to take care of authentication. Next time you turn it on, give it a try; could be that wlan0 associated!
In any case, I wonder why you’re getting different results.
This call to cfg80211_get_bss() is returning NULL:
Which means cfg80211_get_bss() is failing to find a matching base station:
I wonder if you’re seeing success because your AP uses 802.11 privacy whereas mine does not? That could explain different results.
OK, so maybe this only affects open APs. I could totally be wrong about iwconfig wlan0 essid encrypted_ap; iwconfig wlan0 showing an associated base station. I don’t have a way to test right now, though.
Anyway, I tried to track down exactly where things were going wrong yesterday, but didn’t get a final answer. Here is the dmesg after running iwconfig wlan0 essid 'Los Abuelitos' with debugging enabled (and my own debug statements, including diffs):
Starting at line 139 in the dmesg log, you can see where cfg80211_get_bss() (in net/wireless/scan.c) is checking for base stations matching the requested ESSID. In the first two calls, the ssid string contained the ESSID (plus junk), but apparently there were no base stations listed in the rdev->bss_list. In the third call, the ssid string contained only junk in the ssid string, and while there was a base station in the rdev->bss_list, obviously it couldn’t be matched.
That’s all the tracing I can do on my own, since I don’t know which call to cfg80211_get_bss() should have succeeded, or how the interfaces all work. Let me know if you have any good ideas about where to go from here. I’ll install a miniPCIe card if we can’t figure this out, not a problem.
I purchased Banana R2 for my home router, as well as for learning Linux.
I found the wiki of the respected @frank-w and tried to configure everything using it.
I used an image of ubuntu-18.04-bpi-r2-preview with kernel 4.19.138. I also wanted to have access to Banana via Webmin.
I have now configured internal AP, but I ran into a problem - after some time of operation, the access point becomes unavailable.
hostapd.log
WPA: e0:dc:ff:c9:6c:2b WPA_PTK entering state INITIALIZE
wpa_driver_nl80211_set_key: ifindex=11 (ap0) alg=0 addr=0x570170 key_idx=0 set_tx=1 seq_len=0 key_len=0
addr=e0:dc:ff:c9:6c:2b
nl80211: Set STA flags - ifname=ap0 addr=e0:dc:ff:c9:6c:2b total_flags=0x0 flags_or=0x0 flags_and=0xfffffffe authorized=0
ap0: STA e0:dc:ff:c9:6c:2b IEEE 802.1X: unauthorizing port
Could not set station e0:dc:ff:c9:6c:2b flags for kernel driver (errno=11).
ap0: Deauthentication callback for STA e0:dc:ff:c9:6c:2b
ap0: Removing STA e0:dc:ff:c9:6c:2b from kernel driver
nl80211: sta_remove -> DEL_STATION ap0 e0:dc:ff:c9:6c:2b --> 0 (Success)
ap0: STA e0:dc:ff:c9:6c:2b MLME: MLME-DEAUTHENTICATE.indication(e0:dc:ff:c9:6c:2b, 2)
ap0: STA e0:dc:ff:c9:6c:2b MLME: MLME-DELETEKEYS.request(e0:dc:ff:c9:6c:2b)
wpa_driver_nl80211_set_key: ifindex=11 (ap0) alg=0 addr=0x570170 key_idx=0 set_tx=1 seq_len=0 key_len=0
addr=e0:dc:ff:c9:6c:2b
nl80211: Event message available
nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for ap0
nl80211: Delete station e0:dc:ff:c9:6c:2b
ap0: Event DISASSOC (1) received
ap0: STA e0:dc:ff:c9:6c:2b IEEE 802.11: disassociated
ap0: STA e0:dc:ff:c9:6c:2b WPA: event 2 notification
wpa_driver_nl80211_set_key: ifindex=11 (ap0) alg=0 addr=0x570170 key_idx=0 set_tx=1 seq_len=0 key_len=0
addr=e0:dc:ff:c9:6c:2b
WPA: e0:dc:ff:c9:6c:2b WPA_PTK entering state DISCONNECTED
I tried running with a different core (4.14), in 5GHz mode, and as an open AP. The problem still remains…
Please help me solve this problem
