WiFi lost, auto-reconnects only after minutes

ciclista71 · July 2, 2021 at 1:40 PM

I have read many posts talking about issues wirh pi4 and LE10, but if instead for you it's working, then why not giving it a try?

It's an attempt I can do.

I do not have a spare SD so I am backing it up (dd'ing) and once I am done, I will do a scratch install - anyway I don't think I am going to play with LE9 anymore....

Thanks for your hint, I will play with it and report my findings.

BTW, can I ise TVH 4.3.3 instead of 4.3.2 under LE10? I understood the "unstable" version of TVH is much more up-to-date but LE9 doesn't let me chose it.

ciclista71 · July 6, 2021 at 11:47 AM

I'm back, after doing various attempts.

First of all, I backed up my LE9 SD card and I have to say that Win32 Disk Imager always gives me issues, so I used dd to copy the card to an image in my (old) mac. This takes around 3h.... Maybe there is a better way.

Anyhow, I first installed LE10 and used TVH 4.3.3 as a server. Installation was smooth and all the tweaks I did in config.txt to make my TV work under LE9 weren't needed (actually, I initially copied them from LE9 to LE10 and I couldn't see anything in my TV, so I removed them and it all worked). I also checked the brcm firmware and was up-to-date, I could also update the BootLoader (I don't exactly know what it is, but I did it).

WiFi looked very stable, I normally have wifi flapping apart from hard disconnection but I tested it for 4 hours and I never saw any disconnection.

The problem is that TVH couldn't find the TV channels I was looking for. There is a mux at 626Mhz, where TVH could see 3 services but these weren't mapped to any channels. Here below, what I should get from 626Mhz

As you see, TVH sees the mux, scan is OK, 4 services are found (why 4?), 0 are mapped to a channel

If I go to the services tab, though, I do not see anything under the 626Mhz

This means that I cannot record anything from Rai3 because I just cannot find it.

I played quite a lot of time with the configuration but I couldn't do anything to solve the issue.

I then uninstalled TVH 4.3.3 (also because the TV scans always stopped at 97%) and installed TVH 4.2.x. In this case, TV scan reached 100% but I couldn't find Rai3 either, so I gave up.

I saved the image and went back to LE9 (dd took around 5 hours!) and this morning I run it again. I had forgotten the TVH Server GUI password, but after some research I have discovered it is uuencoded in the passwd folder, so I could enter it again.

I did found Rai3 HD this time, I see the services and the channels, I see the EPG, I can watch the channel. Strange thing is that the mux scan shows "FAILURE"

Anyhow, I see the channels (all the three services which are Rai2 HD, Rai3 HD and RaiSport+) and I can watch them.

Of course I still had the network issue so this time I have given it a try and I have updated the brcm firmware

Kodi GUI says that the bootloader is still updated to 2021 (I think the first time I used LE9 it was showing a different date, maybe upgrading it from LE10 made this change persistent? Maybe it's not SD dependent?), so there's nothing else I can upgrade.

I will now leave the system on for a while to see if I lose connection. I have disabled the script that tried to reconnect automatically, so let's see.

I will also report the TVH issue in the TVH forum to see what people say.

I will keep you posted.

[EDIT]

So far, no wifi issues anymore. I will keep this configuration for a while, let's see.

Case closed, for the moment.

Thanks for helping!

ciclista71 · July 15, 2021 at 1:36 PM

Well,

it all happened again. Disconnections are way less frequent, but intrestingly, it looks like I lose connection when I am playing a video while it's been recorded. The server keeps recording and storing the video to the NAS but the client cannot connect to the server anymore.

During August I will play with different configurations

frakkin64 · July 15, 2021 at 10:39 PM

Quote from ciclista71

Well,
it all happened again. Disconnections are way less frequent, but intrestingly, it looks like I lose connection when I am playing a video while it's been recorded. The server keeps recording and storing the video to the NAS but the client cannot connect to the server anymore.
During August I will play with different configurations

Goes back to one of my early points, specifically about saturating the SDIO bus with the built-in WiFi. The built-in Wi-Fi is not usable for HD playback & recordings on the Raspberry Pi, in my opinion.

I would suggest plugging in an ethernet cable, or moving your video recording to a machine that is on your network. I don't know what encoding or bitrates & resolutions your recordings are, but HD 1080p MPEG2 can run around 20Mb/s and probably higher for some scenes. I could see this easily saturating your SDIO bus and causing timeouts with WiFi, especially if your recording a few channels and playing back video.

ciclista71 · July 16, 2021 at 1:08 PM

frakkin64, I don't think the BUS gets saturated because I have issues only when playing the videos, but not when recording them.

What I have noticed is instead something that may have nothing to do with WiFi, and I will explain why:

If I play a video while it's being recorded, after around 30 minutes I get a client disconnection and from that moment on, least for 10 minutes, I cannot resume the connection even if I disable and re-enable the PVR Player.

No matter what, the TV Program gets recorded without any issues and actually, I can watch it with VLC.

If instead I play a video after it's been recorded, everything goes fine.

I see this because every Wednesday I get the issue (and it's when I record the program) but on Thursday or in other days, it's all good.

For this reason I will do the following attempts:

- But back the latest LE + Kodi Release, record and play while recording to see if the new TVH client is better

- While recording, use a different player (I have a FireTV with an older Kodi instance) to see if this leads to the same issues

- While recording, play the video with a different player (Kodi, through the files section or VLC from my PC)

According to what I find, I will decide what to do.

I have read of other people having this issue of getting disconnected while playing a video being recorded and even if they used ethernet cable, still the problem wasn't solved. And actually, how can it be that the client cannot connect to the server if they are both on the same machine? It cannot be network dependent if the loopback is involved!

I'm going on holiday tomorrow, so I will resume my analysis in August when I am back.

That's a really tough issue... TV programs will switch to HD in September and I need to solve my problems by then, as my legacy PVR only supports SD and therefore I will have to rely only on my pi4.

ciclista71 · September 1, 2021 at 9:23 AM

OK,

During the last week I upgraded from LE10 to LE10RC1, but the behaviour is basically the same:

Whenever there is a short network loss, connmand removes the IP address and the routes (and the same is notified by avahi), and three things happen:

- TVH Server keeps recording the video, which is prolly locally stored and then sent to the NAS as soon as network recovers (I don't lose any frames when I watch it later)

- PVR Simple IPTV Client cannot reconnect because there is no interface to use (they have been removed) and will succeed quite late (I saw improvements in LE10RC1, but still it's 3 to 4 minutes)

- If I go to the Network Section of LE with the remote ands check the IP address, I will not see it (it's blank) and LE hangs (I need to unplug it and re-plug it)

So, for me the issue is the way connman or avahi work whenever a connection is lost. I would expect the IP to stay there, and instead the routes, and DNS, everything is teared down. Strangely enough, the TVH server keeps working (I think it's saving locally and then flushing to the NAS as soon as network is up again)

I tried to configure a static IP, but still, interfaces are removed.

The problem is that only that Rpi has connection problems. I lose SSH connectivity to it but I can perfectly browse the NAS from my Windows PC which is over the same WiFi.

I can't think of any other workaround.....

**chewitt** · September 1, 2021 at 12:55 PM Official Post

Three suggestions - in order of best to least-best:

a) Switch to Ethernet

b) Switch to Ethernet connection to a wireless bridge

c) Fix the network so it doesn't have dropouts (harder than it sounds sometimes)

In B .. because the Ethernet link to the bridge device remains up at all times you don't see a dropout which results in the connman 'teardown' that you see when the link is lost on the wireless connection.

ciclista71 · September 1, 2021 at 2:27 PM

Switching to ethernet is too complicated because I am just opposite the router and I would need to lay a cable across the room, not easy and not nice.

However, I have done another attempt, which is bringing the wifi down and up programmatically on my FritzBox router. I have created a python script that does the job. WiFi is taken down for three seconds and then up again.

Now, when this happens, wpa_supplicant sees a connection drop with valid reason codes (2, 3 or 6), still I can see the teardown of the interfaces but the system is not affected. The connection doesn't drop, I keep watching what I was watching, I keep recording what I was recording.

I can bring down the wifi like that many times and still, the behaviour will be perfect.

The issue occur when the wpa_supplicant throws an error with reason=0 locally_generated=1. In that case, the system doesn't recover

reason=0 is not one of the valid wpa_supplicant codes, though....

GDPR-7 · September 2, 2021 at 7:53 PM

ciclista71

regarding chewitt option c)

what do your fritzbox log's say (wifi connect/disconnect option regarding log's ON ?)

alas in german from a FB 7590:

- left side: "Ereignisse"

- right side, Top box: choose "WLAN"

=> Option to log wifi connects/disconnects and wifi info's

you know that FB's do wifi channel scans from time to time (RADAR) and that there were a lot of complains moon's ago esp. with elder router firmware ?

for further reading/investigation:

FRITZ!Box tot? Recover, Firmware Up-/ Downgrade | IP Phone Forum

wifi problems are mostly on both ends: the router and the client.

a router setting working for years means not to fit the need of today ([maybe] your neighbours are in the "wifi-game" too) !

P.S.

a long enough cable with usefull color could also be layed an the floor following the walls or hidden under/nailed on the "skirting board"

ciclista71 · September 7, 2021 at 5:23 PM

The FritzBox tells me about connections and disconnections, but actually I see it also for other devices (for which I do not get any issues whatsoever)

I am using Firmware 07.28, installed on the 30th of August. Sometimes the device gets de-registered, sometimes is de-registers itself.

Code

02.09.21 15:41:35 Wireless device deregistered itself (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 12:36:33 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 12:36:17 Wireless device was deregistered (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 12:35:45 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 12:35:31 Wireless device was deregistered (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 08:51:21 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 08:51:03 Wireless device was deregistered (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 08:50:49 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 08:50:49 New wireless device registered itself (2,4 GHz), 72 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 08:50:49 Wireless device was deregistered (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 08:50:48 Reregistered wireless device (Band-Steering): Automatic change of Wi-Fi frequency band to improve data transmission, LibreELEC, IP 192.168.1.143
02.09.21 05:01:37 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 05:01:35 Reregistered wireless device (Band-Steering): Automatic change of Wi-Fi frequency band to improve data transmission, LibreELEC, IP 192.168.1.143,
02.09.21 05:00:15 New wireless device registered itself (2,4 GHz), 72 Mbit/s, LibreELEC, IP 192.168.1.143

Display More

I see similar messages also for my iPhone and my IP Cameras but I do not suffer network outages, amnd anyway there is nothing I can do about it.

The 5Ghz channel is set manually to 40 (because I need it for the FireTV to work properly with 5Ghz).

Deoptim · February 22, 2022 at 2:14 PM

Hello.

For me fix the WiFi freeze is sdio patch from this source:

Community - Silicon Labs

The Silicon Labs Community is ideal for development support through Q&A forums, articles, discussions, projects and resources.

community.silabs.com

Adapted patch for new linux kernel (5.10.xx):

Diff

--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -374,6 +374,7 @@
 #define MMC_CAP2_CQE_DCMD    (1 << 24)    /* CQE can issue a direct command */
 #define MMC_CAP2_AVOID_3_3V    (1 << 25)    /* Host must negotiate down from 3.3V */
 #define MMC_CAP2_MERGE_CAPABLE    (1 << 26)    /* Host can merge a segment over the segment size */
+#define MMC_REPLY_GO_IDLE    (1 << 27)    /* Connected chip reply to GO_IDLE_STATUS command (CMD0) */
 
     int            fixed_drv_type;    /* fixed driver type for non-removable media */
 
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -336,6 +336,8 @@
         host->caps2 |= MMC_CAP2_HS400_1_8V | MMC_CAP2_HS200_1_8V_SDR;
     if (device_property_read_bool(dev, "mmc-hs400-1_2v"))
         host->caps2 |= MMC_CAP2_HS400_1_2V | MMC_CAP2_HS200_1_2V_SDR;
+    if (device_property_read_bool(dev, "mmc-reply-go-idle"))
+        host->caps2 |= MMC_REPLY_GO_IDLE;
     if (device_property_read_bool(dev, "mmc-hs400-enhanced-strobe"))
         host->caps2 |= MMC_CAP2_HS400_ES;
     if (device_property_read_bool(dev, "no-sdio"))
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -153,6 +153,8 @@
     cmd.opcode = MMC_GO_IDLE_STATE;
     cmd.arg = 0;
     cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_NONE | MMC_CMD_BC;
+    if (host->caps2 & MMC_REPLY_GO_IDLE)
+        cmd.flags |= MMC_RSP_R1;
 
     err = mmc_wait_for_cmd(host, &cmd, 0);
 
--- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
@@ -226,6 +226,11 @@
     minimum: 0
     maximum: 0xffff
 
+  mmc-reply-go-idle:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description:
+      expect reply on GO_IDLE_STATE command (CMD0)
+
   no-sdio:
     $ref: /schemas/types.yaml#/definitions/flag
     description:

Display More

Copy these code as patch file to the project directory, for example libreelec-10.0/projects/Allwinner/patches/linux/ or other your specific platform.

Also you must to add new flag mmc-reply-go-idle to the DTS file of your device in the mmc node (where is sdio-wifi connected).

For example of my patch for my Orange-Pi Lite device:

Diff

--- a/arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts
@@ -84,6 +84,7 @@
         status_led {
             label = "orangepi:red:status";
             gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
+            linux,default-trigger="mmc0";
         };
     };
 
@@ -92,16 +93,41 @@
 
         sw4 {
             label = "sw4";
-            linux,code = <BTN_0>;
+            linux,code = <KEY_POWER>;
             gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+            wakeup-source;
         };
     };
+
+    reg_sy8113b: vdd-cpux-regulator {
+        compatible = "regulator-gpio";
+        regulator-name = "vdd-cpux";
+        regulator-type = "voltage";
+        regulator-boot-on;
+        regulator-always-on;
+        regulator-min-microvolt = <1100000>;
+        regulator-max-microvolt = <1300000>;
+        regulator-ramp-delay = <50>; /* 4ms */
+
+        gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; /* PL6 */
+        enable-active-high;
+        gpios-states = <1>;
+        states = <1100000 0>, <1300000 1>;
+    };
 };
 
 &de {
     status = "okay";
 };
 
+&cpu0 {
+    cpu-supply = <&reg_sy8113b>;
+};
+
+&ehci0 {
+    status = "okay";
+};
+
 &ehci1 {
     status = "okay";
 };
@@ -135,8 +161,11 @@
 
 &mmc1 {
     vmmc-supply = <&reg_vcc3v3>;
+    vqmmc-supply = <&reg_vcc3v3>;
     bus-width = <4>;
     non-removable;
+    keep-power-in-suspend;
+    mmc-reply-go-idle;
     status = "okay";
 
     /*
@@ -148,6 +177,10 @@
     };
 };
 
+&ohci0 {
+    status = "okay";
+};
+
 &ohci1 {
     status = "okay";
 };
@@ -162,6 +195,11 @@
     status = "okay";
 };
 
+&usb_otg {
+    status = "okay";
+    dr_mode = "peripheral";
+};
+
 &usbphy {
     /* USB VBUS is always on */
     status = "okay";

Display More

Good luck.

ciclista71 · April 4, 2022 at 3:41 PM

Time has passed and in the meantime I have upgraded to LE10, latest version (and I have to say I am extremely happy about the de-interlacing feature, wow!).

WiFi drops are very rare and they don't affect performance or network connectivity, as they last between 4 to 6 seconds only and the connection doesn't drop. The latest version and firmware were key, I believe.

But I have another big problem, that was present even before, I think: at least once a day I get the following error:

Code

LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying

This occurs about 4 minutes after the connection with my NAS is lost and this status continues for about 10 minutes, when the router disconnects LibreELEC from the WiFi, reconnection takes place and the NFS FS comes up again

Code

Apr 03 21:13:55 Last data sent to InfluxDB (every 30s via a POST to a server located in a Raspberry at .132)


Apr 03 21:17:06 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Apr 03 21:23:48 LibreELEC wpa_supplicant[509]: wlan0: CTRL-EVENT-DISCONNECTED bssid=dc:39:6f:xx:xx:xx reason=2
Apr 03 21:23:53 LibreELEC wpa_supplicant[509]: wlan0: CTRL-EVENT-CONNECTED - Connection to dc:39:6f:xx:xx:xx completed [id=0 id_str=]
Apr 03 21:24:03 LibreELEC kernel: nfs: server 192.168.1.120 OK


Apr 03 21:24:07 Data recovered from InfluxDB

The NAS is working properly and also the network connection, because I have other two RPi sending data to the server and at that very same time their connection was perfectly working. So it's not a server error. And, as you see, we would be talking about two servers going down: the NAS (at .120) and the Grafana server (at .133). The grafana server is not mounted, I just send a POST to it. The NFS instead is mounted, as per the documentation.

I created some monitoring scripts and found out a strange behaviour:

WiFi is seen as UP and connection with the Router is established; however, at a certain point, the ARP table can't find the MAC for the NAS (and also for the other Raspberry). When the WiFi gets disconnected and reconnected, everything comes back:

Code

Sun Apr 3 21:12:24 CEST 2022|signal: -55 dBm|associated: yes|tx failed: 73|connected time: 65301 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:12:54 CEST 2022|signal: -58 dBm|associated: yes|tx failed: 73|connected time: 65331 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:13:24 CEST 2022|signal: -61 dBm|associated: yes|tx failed: 73|connected time: 65361 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:13:55 CEST 2022|signal: -62 dBm|associated: yes|tx failed: 75|connected time: 65392 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0

Until here, good; next line is when NFS is lost, TX failures increase. Still WiFi is associated and connected

Sun Apr 3 21:14:43 CEST 2022|signal: -58 dBm|associated: yes|tx failed: 82|connected time: 65422 seconds|(192.168.1.120) at <incomplete> on wlan0|(192.168.1.133) at <incomplete> on wlan0
Sun Apr 3 21:15:17 CEST 2022|signal: -56 dBm|associated: yes|tx failed: 82|connected time: 65470 seconds|(192.168.1.120) at <incomplete> on wlan0|(192.168.1.133) at <incomplete> on wlan0
Sun Apr 3 21:15:50 CEST 2022|signal: -60 dBm|associated: yes|tx failed: 82|connected time: 65504 seconds|(192.168.1.120) at <incomplete> on wlan0|(192.168.1.133) at <incomplete> on wlan0
Sun Apr 3 21:16:23 CEST 2022|signal: -56 dBm|associated: yes|tx failed: 82|connected time: 65537 seconds|(192.168.1.120) at <incomplete> on wlan0|(192.168.1.133) at <incomplete> on wlan0
...
When the WiFi gets disconnected and reconnected, TX Failures of course go to 0, connected time is reset and the MAC addresses of the NAS and Rpi are found again
...
Sun Apr 3 21:24:08 CEST 2022|signal: -56 dBm|associated: yes|tx failed: 0|connected time: 14 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:24:38 CEST 2022|signal: -58 dBm|associated: yes|tx failed: 0|connected time: 44 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:25:12 CEST 2022|signal: -59 dBm|associated: yes|tx failed: 0|connected time: 77 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:25:42 CEST 2022|signal: -54 dBm|associated: yes|tx failed: 0|connected time: 107 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0

Display More

Now,

I wonder if I can decrease this long timeout between NFS down (4 minutes after the MAC Address is lost) and WiFi Reconnection (which takes places about 10 minutes after the down - wifi reconnection seems to solve the problem).

During this time, if I am watching a recorded program, TVH client and server will fail and I will have to wait until it recovers.

10 minutes is a very long time!

Thanks for helping!

ciclista71 · April 14, 2022 at 12:10 PM

Let's close this topic, WiFi is not lost anymore. Now I have different issues.

The solution was basically to upgrade the firmware of the raspberry and probably also LE

GDPR-7 · April 20, 2022 at 9:34 PM

Quote from ciclista71

Let's close this topic, ...

care to mark it as resolved ?

see the box just under the thread title