• Support

  • Moodlebox 4.0.0 : Wifi connections drops after each request

Hello Krause
Thank you for the recommendation to use WifiAnalyzer on a mobile phone to check if there are channels used by other access points. So not far as I can see. However I do not know what 5(3) means. And there is only one Moodlebox wifi meanwhile you had three.

Maybe I should change the MoodleBox default SSID settings from country CH to GH where I use it and maintain the channel?

SSID MoodleBox
Password moodlebox
Country CH
Channel 11

If yes in which file is that done?

Kind regards
Hannes

    Your channel graph looks fine. I think that 5(3) means channel 5 and width 3. My Bertha wifi is on channel 1 and has also the with 3. In your wifi analyser you were connected to the MoodleBox wifi. The graph shows a wider line for the MoodleBox wifi.

    Now you can analyse the time graph. Connect the wifi analyser with the MoodleBox wifi. The time graph for the MoodleBox will be the wider line again. Now you can check the stability of the MoodleBox wifi. If the line breaks and the wifi analyser disconnects then you will have a problem. I tested this for over 4 hours and I got no break with the MoodleBox 4.0.0 image. I tested this with a Raspberry Pi 4B, a Raspberry Pi 3B+ and a Raspberry Pi 3B at the same time. I needed to rename the wifi ssid for the MoodleBoxes.

    Ralf

    The country code allows and disallows some wifi channels. https://en.wikipedia.org/wiki/List_of_WLAN_channels#2.4_GHz_(802.11b/g/n/ax)

    The MoodleBox uses the wifi standard 802.11n. If you choose the wifi country US then the RaspiOS should not allow the channels 12 and 13. In most other countries these channels 12 and 13 are allowed. The next two pictures show the none overlapping channels for 802.11g. As you see you should only use the channels 1, 5, 9, and 13 because these channels do not overlap. For my teachers workshops I want to get more ... so I'm using 1, 4, 7, 10, and 13 without any problem.

    Ralf

    Hi again

    Thank you for the help. The results so far:

    1. The wifi access point time graph analysis with the WifiAnalyzer app on the phone connected to the MoodleBox Wifi shows no dropping of the signal. The resolution seems to be too low because a concurrent ping 10.0.0.1 test continues to show the dropping of the signal.
      !

    2. With the other Wifi net (=the local router) switched off the dropping of the signal continues:

    3. I used the Moodle box web gui to change the Wifi settings:
      From country 'Switzerland' to 'Ghana' while maintaining channel 11.

      The result is similar. I also tested the access with another tablet and could do some work on it. But the response time was rather slow. Because of the dropping of the wifi signal and the re-connection time used I guess.

    4. To check against another system I used another micro sd card with
      https://www.raspberrypi.com/software/operating-systems/
      Raspberry Pi OS Lite --- Release date: October 30th 2021 installed.
      I connected through the local wifi run the ping command
      ping 192.168.1.11
      .....
      64 bytes from 192.168.1.11: icmp_seq=562 ttl=64 time=3.26 ms
      64 bytes from 192.168.1.11: icmp_seq=563 ttl=64 time=7.14 ms
      64 bytes from 192.168.1.11: icmp_seq=564 ttl=64 time=3.26 ms

    --- 192.168.1.11 ping statistics ---
    564 packets transmitted, 545 received, 3.36879% packet loss, time 564188ms
    rtt min/avg/max/mdev = 2.402/7.476/1213.642/52.849 ms, pipe 2

    The results so far seem to indicate that it is not an access point channel conflict and probably also not a hardware problem of the Pi3B+ though I am not sure if the test in under point 4 covers the access point issue properly.

    What should I try next?

    Regards
    Hannes

    P.S. Point 4 tests the RPi as a Wifi client, not as an access point, I suppose.

    Hi again

    Update: I installed a moodlebox-3.12.0.img on a different micro sd card.
    There is no problem with the wifi signal as the following ping test shows.

    Moodlebox
    Version 3.12.0, 2021-07-11.

    ping 10.0.0.1
    .........
    64 bytes from 10.0.0.1: icmp_seq=499 ttl=64 time=3.52 ms
    64 bytes from 10.0.0.1: icmp_seq=500 ttl=64 time=3.09 ms
    64 bytes from 10.0.0.1: icmp_seq=501 ttl=64 time=4.48 ms
    64 bytes from 10.0.0.1: icmp_seq=502 ttl=64 time=16.1 ms
    64 bytes from 10.0.0.1: icmp_seq=503 ttl=64 time=2.50 ms
    C
    --- 10.0.0.1 ping statistics ---
    503 packets transmitted, 503 received, 0% packet loss, time 502796ms
    rtt min/avg/max/mdev = 1.398/7.450/323.424/24.228 ms

    So I plan to work with version 3.12.0.
    I am though ready to do inquiries why version 4.0.0 has problems if somebody can show me how to enable debugging / tracing of the access point activities.

    But as for moodlebox version 3.12.0
    I do not know the moodle admin account user name and password for 3.12.0. I did not find it on the moodlebox.net website. Could somebody help me please?

    --Hannes

    The admin user name / password for Moodlebox 3.12.0 is also
    moodlebox
    MoodleBox4$

    5 days later

    I understand that Moodlebox 4.1.0 will have a different firmware software for the wireless access point (AP). And that your tests went well so far. Is the test image available for download?

      Hannes I understand that Moodlebox 4.1.0 will have a different firmware software for the wireless access point (AP).

      It depends. MoodleBox relies on the official Raspberry Pi OS. The new minimal firmware is already included in MoodleBox 4.0.0, and the tests went well indeed. I'm afraid I got no other feedback of buggy behaviour than this.

      For next version, there's no plan to use unofficial firmware, but if Raspberry Foundation updates the firmware, we'll have a new one.

      And there's no test image yet. For reference, progress towards next version can be followed in Github.

      Edit: There's another similar feedback (in french), but with no detail.

        So the firmware for the AP currently included in Moodlebox 4.0.0 is a minimal one and from the official RPi OS distribution. It is supposed to support more WIFI clients again.

        So for my case I continue to use Moodlebox 3.12.0 (which needs an ethernet cable to connect to another network) and check for news from time to time.

        ralfkrause I think this is not the same issue: the wireless chip firmware version is different. On MoodleBox 4.0.0, version is 7.45.241. The report linked shows older version 7.45.18.

        FYI: Check your wireless chip firmware version with

        dmesg | grep brcmfmac

        You'll get a line like

        [    6.328844] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov  1 2021 00:37:12 version 7.45.241 (1a2f2fa CY) FWID 01-5209c09

        indicating the version.

          5 months later

          Hello, any updates on this topic? Is anyone else using Moodle 4 yet and can report on the stability of wifi connections.

            moodlemuse Right now I don't have a RPi 4. When I tested about two years ago http://www.syndrega.ch/blog/#benchmarking-moodlebox-on-different-raspberry-pi-models, Pi 4 wireless performance/stability was not different from either 3 B or 3 B+. I don't expect the situation to be different today, because they still share same the wireless circuitry and firmware. Insufficient power supplies and conflicting wireless transmitters (sending on the same channel) have been the main causes of instability as reported here.

              18 days later

              I have experienced a similar problem with wifi connection instability on Moodlebox 4.3.0

              I have made a fresh installation with no changes from default settings and run it on RPi 4 hardware that works fine for other applications that have wifi Access Point.
              The Moodlebox runs on Ch 11 and there are two other wifi APs in the vicinity running on Ch 1 and Ch 6.
              The regulatory domain is set to Au.
              Client devices (eg HP Probook 4340 with Intel wifi and similar) drop the wifi connection randomly, sometimes after just a minute or so. There are only a few client devices connected.
              If the client is set up to auto connect to the Moodlebox AP, it will reconnect fairly quickly.

              I have not seen an obvious pattern to the disconnects, but they do seem to be somewhat related to a user making a request as Hannes mentioned in his original post. That said, If the client device is logged in to Moodlebox and left alone without any user activity it will usually disconnect after a while.

              Connecting the Moodlebox to my LAN via Ethernet, then connecting the client device via an Access Point on the LAN does not appear to produce the problem. This seems to indicate that the problem lies with the RPi wifi.

              I note that one of the features of Moodlebox 4 is the introduction of wifi AP-STA mode.
              I assume that this feature is not operational by default (since no host wifi credentials are set) but is there some setting for this?

              I have attached the relevant dmesg output for "brcmfmac" below for info.
              I note that "power save" is enabled.
              Is it possible that this may be causing a problem?

              I suspect that trying to use the RPi wifi for any significant number of user device connections is always going to be problematic. Even with the new "minimal" wifi firmware mod, the most wifi connections is 20, best case, which is not terribly useful for classes of 30 students.

              Any ideas appreciated.

              moodlebox@moodlebox:~ $ dmesg | grep brcmfmac
              [ 5.432251] brcmfmac: F1 signature read @0x18000000=0x15264345
              [ 5.547934] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
              [ 5.569289] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin failed with error -2
              [ 5.599380] usbcore: registered new interface driver brcmfmac
              [ 5.841003] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
              [ 5.841345] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
              [ 5.846818] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Nov 1 2021 00:37:12 version 7.45.241 (1a2f2fa CY) FWID 01-5209c09
              [ 7.720920] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled