Always loses wi-fi connection, never reconnects...
Hello I have been using Repetier server pro for a few days now and can't find anything to solve this persistent connection issue. I am using a Raspberry Pi 4 with a MK3 and an MK3S, I connected to wi-fi using the GUI and then disabled the GUI if that matters. The GUI made it impossible to set the region because you can't scroll with a mouse but I was able to set it through the web interface, again not sure if this matters.
After a few hours at most the connection will always fail and I can see in Fing that the Pi is no longer on the wi-fi and regardless of how long I wait it does not ever reconnect until the Pi has been restarted. The pi is only one room over from a brand new router so there is no reason for a signal issue.
Do you have any suggestions for solving this issue? it is sort of defeating the purpose of even having Repetier
After a few hours at most the connection will always fail and I can see in Fing that the Pi is no longer on the wi-fi and regardless of how long I wait it does not ever reconnect until the Pi has been restarted. The pi is only one room over from a brand new router so there is no reason for a signal issue.
Do you have any suggestions for solving this issue? it is sort of defeating the purpose of even having Repetier
Comments
Once it is back you should check how good connection is. Login via ssh and run
iwconfig
And see how good bit rate is.
There might also be the chance that you have this problem:
https://forum.armbian.com/topic/11518-rock-pi-4b-dev-boot-up-error-failed-to-start-advanced-ieee-80211-ap/
When I just wanted to test iwconfig I saw that I was also connected but without ip and got lots of brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110
messages in /var/log/syslog
So if you check syslog for brcmf_proto_bcdc_msg you could check if you had same problem.
Now that I'm aware of this linux problem with pi chipset I will try to write a script to monitor for the problem. Just not sure how to check that since it happens very infrequently and I need a safe way to detect that linux bug.
#!/bin/bash
rmmod brcmfmac
rmmod brcmutil
MODULE_PATH="/lib/modules/$(uname -r)/kernel/drivers"
insmod $MODULE_PATH/net/wireless/broadcom/brcm80211/brcmutil/brcmutil.ko
insmod $MODULE_PATH/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko
got wlan running again. Now I only need a way to detect the problem so I can start the script.
Please check you syslog for the linux bug I mentioned.
cat /var/log/syslog | grep "brcmf_proto_bcdc_msg failed"
should show you all lines of that error. If so please send me a pm with mail address. Meanwhile I have finished a script that should repair the bug if it appears and so I could test if it works. For me it normally does not happen only every few weeks one one of the pis, so that would be a great test pi and if it works it would solve your problem.
A other solution would be to disallow activating access point mode. What often happens is that you loose connection and server then switches to AP mode until it sees connection again and switches back. Once started it means around one minute offline. If you prevent switching it reconnects much faster on connection abort.
When logged in via ssh send command
iwconfig
to see network connections. Check if a high baud rate is selected and if link quality is good. If a 2GHz connection that can handle 54Mbit is on 1Mbit you have bad signal at your point.
iwconfig
to see if device was really gone? At least with one router we saw wifi driver hanging. That is why we have a script /usr/local/Repetier-Setup/bin/monitorSyslog running monitoring syslog and restarting wifi module when we detect "brcmf_proto_bcdc_msg failed w/status -110" in log.
You might try renaming that file in case it causes the module to stop for ever. Or there is another message in syslog that indicates that wifi has a sever issue and needs to also reload wifi module to make it work again.
So best is to check syslog once you know at which time you lost wifi. Please also note that syslog might have timestamps in other time zone (UTC)
Were the errors with same error number. If so try renaming the script, just to be sure the module reloading is not causing the no wifi problem it was meant to solve. When we added this, it was on buster with some older kernel.