so it looks like channel-definition is invalid…maybe you try to use a channel not allowed for your country-setting (some channels are blocked in some countries especially for 5ghz)?
THANK YOU to the folks here for everything you’ve done to build a kernel that supports the R2 so well. I’ve been using mine for a year now without issues.
I’m still missing something after starting up the wlan0 interface.
The interface exists:
$ ip link show dev wlan0
10: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
link/ether 00:08:22:40:c4:fb brd ff:ff:ff:ff:ff:ff
But doesn’t seem configurable as a WiFi interface:
$ iwconfig wlan0
wlan0 no wireless extensions.
I only found one other such report, where @troumadhad this problem, it either resolved itself or the fix wasn’t posted.
i bring up wifi on boot by calling wifi.sh in rc.local (needs to be activated in systemd first)
You want internal wifi in client-mode (not ap-mode)? Had not tested it yet…my wifi.sh is for ap-mode and device created is ap0
Troumad had problem with ethernet…wlan0 is only listed in output.
Which kernel do you use? Does it it work in earlier version (4.14,4.19)? Which image do you use (i experienced strange behaviour when using official images)? Can you post full dmesg? Any firewall active?
Is this the best place to do it? In the other post, you wrote:
These systemd units don’t have that problem, since they’re brought up before network-pre.target.
Correct. (This is used to provision wired hosts over PXE in a lab with no Ethernet.) You could bring up ap0 by adding a mt76_ap.service unit file, copied from mt76_wlan.service but instead using /bin/echo A > /dev/wmtWifi.
He actually had problems with both, although the Ethernet problems were the main focus of that thread. I’m referring to these bits, which appear to be the same problem I’m having:
4.14.189-bpi-r2-main, built yesterday from your repo, 4.14-main branch (rev. aa521b9a2417)
I can try. Which versions do you recommend?
I built this Stretch image myself with multistrap.
No, but isn’t this problem at a lower level? The interface can’t be brought up, so firewall settings can’t be applied yet.
Then you should try prior version 4.9-main/4.4-main (including patches from bpi)…i cannot add more functionality, but maybe i had broken driver while porting. As i do not know how to connect via commandline without wpa-supplicant (which is known to break ap-mode if installed) and i do not use client mode, i had not tested it
Dmesg looks good so far…fm/gps not available (first errors) and config-options not needed (only file itself).
The 4.4-main branch mysteriously wouldn’t even start booting the kernel, just a boot loop. I didn’t try hard to fix it.
The 4.9-main branch booted (but needed updates to uEnv.txt and fstab because the order of the SD card and internal MMC devices are reversed).
The wlan0 device now shows wireless extensions:
$ iwconfig wlan0
wlan0 Disconnected ESSID:""
Mode:Managed Access Point: Not-Associated Tx-Power=off
RTS thr=0 B Fragment thr:off
Power Management:off
Link Quality=0/100 Signal level=-65 dBm Noise level=0 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
But setting an ESSID fails with iwconfig wlan0 essid my-essid:
[ 19.547866] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 21.716460] ------------[ cut here ]------------
[ 21.721141] WARNING: CPU: 0 PID: 97 at net/wireless/sme.c:733 __cfg80211_connect_result+0x240/0x2dc
[ 21.730146] Modules linked in: mtk_thermal spi_mt65xx thermal_sys mt6577_auxadc pwm_mediatek ip_tables x_tables ipv6
[ 21.740754] CPU: 0 PID: 97 Comm: kworker/u8:1 Not tainted 4.9.212-bpi-r2-4.9-main #1
[ 21.748457] Hardware name: Mediatek Cortex-A7 (Device Tree)
[ 21.754004] Workqueue: cfg80211 cfg80211_event_work
[ 21.758875] [<c0112a5c>] (unwind_backtrace) from [<c010d054>] (show_stack+0x20/0x24)
[ 21.766584] [<c010d054>] (show_stack) from [<c03bafec>] (dump_stack+0xc4/0xd8)
[ 21.773777] [<c03bafec>] (dump_stack) from [<c012e768>] (__warn+0xf8/0x110)
[ 21.780702] [<c012e768>] (__warn) from [<c012e850>] (warn_slowpath_null+0x30/0x38)
[ 21.788238] [<c012e850>] (warn_slowpath_null) from [<c085df7c>] (__cfg80211_connect_result+0x240/0x2dc)
[ 21.797586] [<c085df7c>] (__cfg80211_connect_result) from [<c0834718>] (cfg80211_process_wdev_events+0x154/0x194)
[ 21.807794] [<c0834718>] (cfg80211_process_wdev_events) from [<c0834794>] (cfg80211_process_rdev_events+0x3c/0x70)
[ 21.818087] [<c0834794>] (cfg80211_process_rdev_events) from [<c082ea80>] (cfg80211_event_work+0x24/0x2c)
[ 21.827603] [<c082ea80>] (cfg80211_event_work) from [<c0149a04>] (process_one_work+0x190/0x498)
[ 21.836258] [<c0149a04>] (process_one_work) from [<c014a814>] (worker_thread+0x60/0x578)
[ 21.844308] [<c014a814>] (worker_thread) from [<c014fef8>] (kthread+0x108/0x120)
[ 21.851671] [<c014fef8>] (kthread) from [<c0108cd0>] (ret_from_fork+0x14/0x24)
[ 21.858915] ---[ end trace 31af6edb32f3e655 ]---
After this traceback, running sudo bash -c 'echo 0 > /dev/wmtWifi successfully removes the wlan0 interface, but then sudo bash -c 'echo 1 > /dev/wmtWifi usually triggers another traceback, and if not, iwconfig wlan0 essid my-essid does.
Tried 4.4 long time no more…only did some updates (only compiling).
Ok,intersting first step in 4.9 works. These are vendor patches i ported to 4.14. Seems like i made a mistake here. The traceback is only a warning (warn_on) at net/wireless/sme.c:733 __cfg80211_connect_result
We need to find differences in both versions…afair i did only porting,no much cleanup. The patches in 4.9 were from vendors openwrt/lede i only applied to 4.9 and only updating the tree some time.you can easily swap mmc in dtsi (put mmc1 before mmc0)
For 4.4 you could try my fork from official which should be bootable:
But build.sh is a bit different
edit: made a quick diff between 4.9-main and 4.14-main
config MTK_WAPI_SUPPORT
bool "MTK_WAPI_SUPPORT"
depends on MTK_COMBO_WIFI
- default y
+ #default y
help
if it is set to TRUE: Support WAPI (WLAN Authentication and
Privacy Infrastructure)
maybe this is needed for client-support?
i see i did some cleanup too…but that does not affect client-mode because it was not compiled in…afair there were some redundant (header) files
maybe you can trace the functions called for client-mode in 4.9 and then add same debug to 4.14?
but this warn_on also exists in old 4.4, so it seems that pmic->irq_domain is wrong
poweroff is not working in 4.4-main, if setting irq_daomain-param to NULL fixes warning, but not the poweroff itself. irq_domain is set in drivers/mfd/mt6397-core.c mt6397_irq_init()
and should result in error “could not create irq domain” if it fails (return -ENOMEM)
4.4.160 (commit where i copied source from other repo in) does not have this warning (.169 have it…so i try to bisect further), but also poweroff does not work, official kernel is not buildable with current gcc, so i cannot verify poweroff is working there
for ssid-issue you could try adding some debugs around this point (4.9-main)
and compare with 4.14, maybe try to list bss first instead of try to connect to a specific one? maybe no bssid is found…and so you can’t connect to any. you have attached an antenna to r2??
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
full ack.