Orange Pi Zero doesn't reconnect on wifi

[Marcus Nguyen 0]

Hi everyone,

 

I have a problem when work on OPi zero wifi which is running Armbian linux sunxi 4.19.62. I used nmtui to configure wifi connection with static ip. It works fine even rebooting or re-powering up however I tried to power off the router and the result is it has never reconnected again. Next, I plugged in the ethernet cable into RJ45 port, the connection is established. I use sudo ifconfig to show the information, I saw that both the wifi (static) and ethernet are correctly then I can access via ssh or scanning the ip. One again, I continued plugging out the ethernet cable, all connections were disappeared even wifi and connection via ssh is failed. Is there anyone face on this issue? Giving me some help, please.

[Werner 499]

armbianmonitor -u missing.

OPi zero WiFi is known to be unstable.

Your kernel is outdated.

Alternative experimental WiFi drivers for XR819 are included in newer builds.

 

[Marcus Nguyen 0]

18 minutes ago, Werner said:

armbianmonitor -u missing.

OPi zero WiFi is known to be unstable.

Your kernel is outdated.

Alternative experimental WiFi drivers for XR819 are included in newer builds.

 

This is my armbianmonitor result
http://ix.io/2drb
Like you said, I'll try with newer kernel

[Igor 2455]

2 hours ago, Marcus Nguyen said:

I'll try with newer kernel

There are many many users with this board - better use a search engine and throw in: XR819 or xradio and check results.

[Marcus Nguyen 0]

23 hours ago, Igor said:

There are many many users with this board - better use a search engine and throw in: XR819 or xradio and check results.

Sorry, I have not clearly understood your suggestion yet.  You mean that I should search and install the XR819 or xradio driver for my board to check first, right?

[Werner 499]

27 minutes ago, Marcus Nguyen said:

Sorry, I have not clearly understood your suggestion yet.  You mean that I should search and install the XR819 or xradio driver for my board to check first, right?

I guess what Igor meant to say was that you should search for XR819 or xradio in forums to find topics with similar issues and if users solved their issues.

Regardless of that I'd still recommened that you upgrade your kernel to sunxi-current (to say Linux 5.4.x) and check if the issue persists.

[Marcus Nguyen 0]

On 3/6/2020 at 4:44 PM, Werner said:

I guess what Igor meant to say was that you should search for XR819 or xradio in forums to find topics with similar issues and if users solved their issues.

Regardless of that I'd still recommened that you upgrade your kernel to sunxi-current (to say Linux 5.4.x) and check if the issue persists.

I have updated the kernel
"5.4.20-sunxi #20.02.1 SMP Mon Feb 17 02:09:41 CET 2020 armv7l GNU/Linux"
However the problem has not been resolved. Do you have another suggestion?

[Werner 499]

Can you provide a new armbianmonitor -u with the new kernel after a disconnect happens?

[Igor 2455]

50 minutes ago, Marcus Nguyen said:

However the problem has not been resolved. Do you have another suggestion?

Only other option is to use proven working USB wireless solution.

 

Nobody will address this Concorde fallacy.

 

[1] https://www.google.com/search?q=concorde+fallacy

[Marcus Nguyen 0]

1 hour ago, Werner said:

Can you provide a new armbianmonitor -u with the new kernel after a disconnect happens?

How can I do that? The board was disconnected then plug cable ethernet and show the armbianmonitor right? Alternatively,  I have to use a USB comport to keep track it during connection and disconnection?

 

35 minutes ago, Igor said:

Only other option is to use proven working USB wireless solution.

 

Nobody will address this Concorde fallacy.

 

[1] https://www.google.com/search?q=concorde+fallacy

Does it really have no other methods? May I can write a script to check and recover the wlan by code?

 

An other hand, when I update kernel from 4.19 to 5.4 I don't get lines during run

 

Spoiler

[63639.603942] xradio_wlan mmc1:0001:1: missed interrupt
[63983.021823] xradio_wlan mmc1:0001:1: missed interrupt
[65262.383433] xradio_wlan mmc1:0001:1: missed interrupt
[66343.960082] xradio_wlan mmc1:0001:1: missed interrupt

 

[Igor 2455]

Just now, Marcus Nguyen said:

Does it really have no other methods?

 

Don't know for sure, but if you want to proceed to this Concorde Fallacy project and answer the question, you are on your own - raise cash, hire experts. I estimate we already lost for 20.000 EUR + of working hours (you don't support) trying to solve and support this problem ... We should stop way sooner.

[Werner 499]

43 minutes ago, Marcus Nguyen said:

May I can write a script to check and recover the wlan by code?

I dont know what exactly happens and what this causes. As stated XR819 is known to be unstable or even considerable broken by design (like PCIe on H6 but at least it works somehow). I own the board by myself but the first thing I did was removing the wireless antenna as I did not need it

Anyway. Sure you can script yourself some kind a watchdog that checks by pinging a host outside every second or so and when a disconnect happens do something like ifdown/ifup if that helps or do forcefully rmmod and modprobe the wireless module to recover it  (if that works at all, no idea). You have to try around by yourself. Maybe you can come up with something nice.

[Marcus Nguyen 0]

13 minutes ago, Werner said:

I dont know what exactly happens and what this causes. As stated XR819 is known to be unstable or even considerable broken by design (like PCIe on H6 but at least it works somehow). I own the board by myself but the first thing I did was removing the wireless antenna as I did not need it

Anyway. Sure you can script yourself some kind a watchdog that checks by pinging a host outside every second or so and when a disconnect happens do something like ifdown/ifup if that helps or do forcefully rmmod and modprobe the wireless module to recover it  (if that works at all, no idea). You have to try around by yourself. Maybe you can come up with something nice.

Thank for kind of your suggestion. I think so, we should never give up if we don't try all the ways. I think your guide is very nice, one small process can really resolve it. I ask this issue because of I think my board or my setup was problem, if it is a "natural available" bug that I don't need to spend a lot of time to investigate more , it should handle by some methods that fit to my application is better.