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 

Comments

  • If you know how to reconnect using ethernet cable in case of problems you could try setting AP to never. I guess when it does not connect any more it switches back to AP mode. If you prevent that it will not remove the connection definition for linux so linux will continuously try to reconnect and not only the server when it sees the network.

    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.
  • In my case this script:

    #!/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.



  • Setting AP to never seems to have worked 
  • Setting AP to never seems to have worked 
    Repetier said:
    If you know how to reconnect using ethernet cable in case of problems you could try setting AP to never. I guess when it does not connect any more it switches back to AP mode. If you prevent that it will not remove the connection definition for linux so linux will continuously try to reconnect and not only the server when it sees the network.

    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.
    it didn't actually... will restarting the Pi during the print destroy the print? 
  • In general yes, it will destroy the print.

    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.
  • Repetier said:
    In general yes, it will destroy the print.

    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.
    yes I ran this command and there are around a hundred returns. I also just updated to 0.94.1 and have already gotten the issue very quickly. What is mail address needed for? Do you have a way for your script to self trigger? Ethernet connection is not an option for me 
  • See PM in forum for mail address
  • Sorry for the necro, I'm getting this issue now too, even after and apt update, apt upgrade, rpi-eeprom-update.  I'm a linux newbie still, is there a way I can detect the msg failed error and run a bash script to reinstall those kernel modules?  Or is there some other fix?
  • There are multiple solutions. One is to define /boot/wpa-supplicant.conf as described on out image download page. At least for recent images. That will take wifi control completely from server and just tell linux the connection data.

    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.
  • Yeah, I'm having a different issue I think.  The last time the wifi dropped out, I went to the local interface to see the wifi status and it showed no wifi adapters installed.  This is after disabling AP mode, and I did have wpa-supplicant set up because I originally set up the image headless.
  • So you had ethernet to check for it? Did you run
    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)

  • edited August 28
    I had a local touchscreen display, and after rebooting I found instances of brcmf_proto_bcdc_msg failed in the log file.  This was after updating through adb and updating the kernel too.
  • Ok updating is normally no issue, but no one knows if that contains changes to wifi driver or if it would be before or not. We always update to newest before releasing new images, just because we always assume that updates fix issues. Of course sometimes they introduce errors, but how to know.

    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.
  • Oh I'm running into other minor issues now.  If I power reset, I get the incognito screen.  If I software reboot, I only get it 1 of 3 times or so.  I tried removing the --incognito flag and it boots to the Google home screen instead.  It's launching Chromium but not consistently loading the app page for some reason.
Sign In or Register to comment.