-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mwifiex 1.0 (16.68.10.p159) - PCIEUSB-8997 firmware is buggy #1
Comments
|
root@ULTRA-5G:/# uname -ar
dmesg / logread give :
|
after a reboot, it may works... |
It looks like only one client get access successfully... |
I add two tweaks in my /etc/rc.local :
But I still get problems... |
ping @sharvari-nxp |
This help to make the Access Point visible and available... |
I have activated the optional verbose debug log on the wifi device : with
with forcing legacy rates I get it up again :
|
Clients may still have issues, like Apples clients (iOS iPAD and iPhone) which get no access to the AP... |
I have add a /etc/modules.d/mwifiex file with the following content :
|
removed... same !
|
I test it now also by removing wpad and replacing it by hostapd-openssl |
added in /etc/rc.local now I have 4 clients on it...
|
This commit has not the problem :
still added
No more crypto keys added error and multi clients on the AP are OK ! |
|
...<REPEATED MESSAGE !!!>
|
|
Slow and very unstable ! |
Crash at network restart ! Only reboot get the WiFi working, since network restart, and reboot required again ! |
I give a try to : MWIFIEX VERSION: mwifiex 1.0 (16.68.1.p145)
|
Network could now be restarted... |
Still buggy :
|
root@ULTRA-5G:~# dmesg | grep wifi
two clients : OK |
root@ULTRA-5G:~# dmesg | grep wifi
two clients : OK |
root@ULTRA-5G:~# dmesg | grep wifi
two clients : OK |
KO root@ULTRA-5G:~# dmesg | grep wifi
|
Tests (quick tests) made only with ONE AP and TWO CLIENTS on the AP... Config used :
|
@pali hope I forget nothing ! ;-) |
Error message And is caused by loop retries, up the
You could try to increase |
Thanks for the information @pali ... |
I will test more with the V16.68.1.p145 ! |
Well, driver should work with any firmware version. Above |
I get issue in old tests with V16.68.1.p145 : #1 (comment) |
Okay, but I have not compile the OpenWrt firmware I actually use on my ULTRA. |
You can also put this card into any other device (for which you can re-compile kernel easily). |
Perfect! So obviously problematic is version W16.68.1.p195. Version And latest version Please send this test summary to Either responsible people will come up with patches (to firmware or to driver) OR firmware files in linux-fimware would be revered. |
No ! Another question :
Okay, I will send the test summary |
It is using mwifiex driver which Marvell developers (now they are in NXP as NXP bought wireless division from Marvell including developers) developed, send to upstream and maintained it. So ex-Marvell/NXP already upstreamed it in commit, also see history 1 2.
I did not know about it, but it seems like fork of older linux mwifiex driver which NXP modified? No idea. |
In that mwifiex_8997 is similar code with |
With this patch:
|
May be this specific loading problem may need to modify also |
I got kernel panic at boot ! and reboot with a loop of kernel panic ! I think theses OOPS are not related of the MWIFIEX patch, but may be this board is bugging related to MarvellEmbeddedProcessors/linux-marvell#20 ! I have 4 EspressoBin-Ultras, two are working partially fine, but are still in OpenWrt 21.02.0-RC, one another, my third one, crash too easily and fastly, and the last fourth one is still in stock for now.
|
With this patch: #1 (comment)
Loop issue
resolved (known issue) by adding to /etc/config/wireless :
new error, and no access to AP from clients !?
UPDATE :
Second client (try to) access (unsuccessful) :
This error loop !!! Result : |
If I de-authenticate the first client, the second get access successfully !
I confirm that this versions still work with one client only. The errors looks like to be from the firmware itself :
|
No WiFi AP this morning...
Kernel.log
|
Again... No AP this morning ! UpTime : 5d 22h 56m 32s
Resolution : AP available again without a Reboot but only with a manual WiFi "reset" (Restart Device + Disable Access Point + Enable Access Point). |
@pali |
Nothing more to test. This is NXP bug, so you have to report it to NXP... probably only NXP can fix it. I have seen upper limit for number of clients which could connect to AP. For 8997 it was IIRC 5. So either NXP reduced it by new firmware version or introduced some bug which decreased it. Really, you had to contact NXP for support. Per https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS is 8997 (MWIFIEX WIRELESS DRIVER) still supported. |
Look there is a new BSP and also new firmware ?
|
Possible new firmware at NXP, I received a email announcement with:
But the link is restricted. I open a support request, and get answered of signing a NDA. I have no access also at the 9098 BSP and firmware... |
Any news ? all is said here, 6ae3652#commitcomment-66183539 |
still urgently needed |
MVEBU - EspressoBin ULTRA wifi - BUGS with OpenWrt 21.02-RC
312ca02
Can anyone help with this bug ?
kaloz/mwlwifi#397
https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/32
EDIT:
Hardware used for testing:
EspressoBin-ULTRA from GlobalScaleTechnologies.
Official Product: https://globalscaletechnologies.com/product/espressobin-ultra/
CNX review: https://www.cnx-software.com/2019/12/30/espressobin-ultra-gateway-features-5-gigabit-ethernet-ports-wifi-5-supports-4g-lte-cellular-connectivity/
Block Diagram: http://espressobin.net/wp-content/uploads/2020/05/ESPRESSOBin-Ultra-V1_-Block-diagram_.pdf
OS info (from OpenWrt 21.02.x):
EDIT: A summary of my tests here:
#1 (comment)
Tests (quick tests) made only with ONE AP and TWO CLIENTS on the AP...
Config used :
cat /etc/config/wireless
The text was updated successfully, but these errors were encountered: