hmm, that log looks like you freshly booted with ethernet cable plugged in - I don't see any failed wifi connection attempts here
so long,
Hias
hmm, that log looks like you freshly booted with ethernet cable plugged in - I don't see any failed wifi connection attempts here
so long,
Hias
Of course I booted with the cable connected. How else would I be able to ssh to it? You probably do not see any failed wifi attempts because as I said connman prefers wired to wireless and turns off wireless when wired is connected
I could not hold myself any longer and downloaded today's nightly from the hotdog folder. I have disconnected the cable since I managed to connect wirelessly a few minutes earlier and I am now waiting for it to upgrade and boot. If it does connect wirelessly, do you want a fresh pastekodi or do you want to wait until the wireless fails to connect again, so as to connect with ethernet AFTER it boots?
Please tell me when that change from wpa_supplicant to iwr was made. Or at least point me at the relevant commit in github.
---edit
It just booted to the new nightly and connected wirelessly. I will do my kodi stuff (= add more addons and repos) until you reply.
You can just plug in ethernet after a wifi issue, it should connect automatically. Ethernet takes precedence over wifi so if you have ethernet plugged in wifi won't be tried at all.
so long,
Hias
Why does pastekodi return "no results to fetch" and sometimes it just gets me back to the prompt without this message or the paste url? I just run it 5 times before it returned the url eventually.
There you go though. It failed to connect wirelessly, so I connected the cable and sshed to it. I will do the upgrade to the new nightly now.
---edit
And it just connected automatically on the first boot with 20220603-98b9aa2. What if the wifi takes longer to connect and I am just too impatient to wait? However, I think 1 minute is enough time for it to boot and connect, given the fact that it also has to wait for network connection right before kodi starts. Right now, wait-time-sync.service and kodi-waitonnetwork.service top the board of systemd-analyse blame with 32 and 10 seconds of delay respectively, while the remaining services each have a delay of 3 seconds at most.
Time for the x64 nightly installation to shine
After 2^n reboots and 2^n-1 flicks of the wifi switch (yes, the laptop is so old that it has such a hardware switch), it finally showed the wireless networks. As for the wifi signal, you are right about its calculation. It show as ~10% weaker than on le 9 and 10.
At the first try to connect, it failed and complained about the key being wrong, while it wasn't. At the second try it was accepted with no issues and connected to my wifi. Instead of installing confluence and greek, I had the idea of upgrading to the latest nightly and after it rebooted it showed no connections again. Right now, 2-3 reboots later, there are still no connections listed in libreelec settings and there is no wlan0 in ifconfig
Also, kodi-send --action=InstallAddon does not work, neither locally (run via ssh) nor remotely (run from my pc with the --host= parameter). I have already enabled remote control from applications on this system and from other systems.
Fresh pastekodi from the rpi. I waited for like 5 minutes for it to connect to the wifi, it didn't, so I plugged the cable, sshed to it and connected to the wifi via connman again. This time though connman asked for the wifi key, although it was already stored. And I did not remove .cache/connman/wifi_whatever beforehand!
The service wait-time-sync.service topped the systemd-analyze blame board with a massive 5 minutes and 30 seconds, much higher than the 10 seconds delay of kodi-waitonnetwork.service which was second. It is more than obvious that le was waiting for a network connection here.
I asked a friend to lend me his rpi3b (not sure if it is the plus version) to do some more troubleshooting because its wireless connection inconsistency is driving me mad. Can I use the same sd card that contains the nightly for it?
Yes, you can use the SD card in the other RPi.
so long,
Hias
Ok then, I am waiting for the other rpi to come.
In other news, wifi could not connect earlier, so I connected the cable and I retried it with connman. But this time, connman mentioned that it had the key stored and it showed its right value
And after 3 days without a single issue, the above behavior appeared again today. Today though I noticed that wlan0 was not even mentioned in dmesg! Shouldn't it be mentioned, at least once?
dmesg is only showing kernel messages. Use journalctl to see all system messages.
I know that about dmesg. Wouldn't the kernel find a wireless interface at boot and name it wlan, like I mentiona above? Why is it not in dmesg then? I will keep searching, athough I do not know how much longer I can keep that installation.
Also, I noticed that wl is used for it, like in le 10 and 9. How can I blacklist it and test b43 that also supports it?
In other news, one thing I managed to test on x64 le 11 was video playback on my old laptop. One of the reasons I have not yet moved to le 10 there is because I get frame drops on every video (file or stream), regardless of resolution.
The stream/file plays fine, the cpu usage is at normal levels, but the motion is not as smooth as in le 9. It seems as if it skips some frames and it happens even on low resolutions like 360p. So, I discovered that it does not happen on le 11 and I am pleased
---edit
Well, this happened on the first boot of today's nightly. It is on dmesg and it seems serious.
---reedit
I just found the way to blacklist a module.
https://wiki.libreelec.tv/how-to/blacklist-kernel-module
But there is no b43!
Back to the rpi with a new error in connman. As usual, 1st boot of the day, it does not connect wirelessly so I connect the cable, ssh to it to launch connman to see what is going on. First try returned no prompts to enter the key or anything
I waited a bit, checked ifconfig, checked iwconfig and it had not connected yet. Back to connman for another try and I get this progress error for the first time ever
connmanctl> connect wifi_bxxx_4xxx_managed_psk
Error /net/connman/service/wifi_bxxx_4xxx_managed_psk: In progress
connmanctl> exit
I waited a bit more, checked ifconfig again, checked iwconfig again and still nothing. So I tried again and this time it popped the usual "the network exists and has this key" prompt
connmanctl> connect wifi_bxxx_4xxx_managed_psk
Agent RequestInput wifi_bxxx_4xxx_managed_psk
Passphrase = [ Type=psk, Requirement=mandatory ]
PreviousPassphrase = [ Type=psk, Requirement=informational, Value=mywifikey ]
Passphrase? mywifikey
connmanctl> exit
And it finally connected!
Back to x64. Has le 11 moved to iwd? Because I can not make connman connect to the wifi and it just gets this error, which according to arch wiki is related to iwd. Sadly, the instructions there are not applicable to le because wpa_supplicant does not exist.
Has le 11 moved to iwd?
That change was done only 1 month ago. 1 month ago I wasn't even using the nightly on the rpi, let alone on x64.
And the issue with that message has appeared very recenty, like 3-4 nighlies ago. Did something else change recently, e.g. the kernel maybe? I am sad, because 11 fixed the framedrops issue that 10 has but introduced that wifi issue. Anyway, I will keep looking.
Another day, another new weird thing comes up. As usual, the rpi did not connect wirelessly on first boot, so I went wired to do today's update.
First, it stopped at like 95% of the download, so I had to cancel it with ctrl+c and continue it with wget's -c parameter and it completed it after a few seconds. This was happening at the start due to poor wireless signal, but why did it happen on wired connection too?
Second, I did the usual connman procedure of connecting it wirelessly, but connman returned no propmt for the key this time, so I thought it connected successfully. But it did not, according to iwconfig and ifconfig, so I tried again and this time I got this new output of the connection being in progress
connmanctl> connect wifi_bxxx_4xxx_managed_psk
Error /net/connman/service/wifi_bxxx_4xxx_managed_psk: In progress
I retried again after like 1 minute but it showed the same, so I let it continue for a couple of minutes, did the procedure again and I was prompted for the key like usual.
Third, once the update was downloaded (and after checking its sum with the same file downloaded on my pc), I issued a reboot. Unlike previous versions where the connection was terminated instantly (especially via ethernet), le 11 takes some to disconnect and putty to report that the connection was terminated. After like 1 minute, putty was still on and returned to the prompt so as to run another command. I then ran dmesg, which showed the usual cec errors that come up when it is not connected to the tv, but nothing more related to the filesystem.
Then I decided to run htop to check if some other process is delaying it, and it said "sh: htop: access denied" (or something like that). Its green led was permanently on, not blinking, so I hesitated to pull the plug. But I pulled the ethernet cable and after like 30 seconds, I finally saw the green led come of and back on again.
Long story short, it booted to the new nightly, I sshed to it, checked dmesg again for filesystem issues, but still no luck. I ran connman again, reconnected to the wireless (it did not ask for the key this time), rebooted, and luckily wireless was active again after the reboot.
I just noticed that wlan0 is not mentioned anywhere in dmesg of the rpi. Is this logical? I checked on yesterday's and today's nightlies, i.e. before and after the upgrade.
Also, has the nightly for le 10 moved to iwd yet? I may switch my 10.0.2 x64 installation to nightly and check if those dropped frames still happen. I am totally giving up on le 11 on x64 by the end of the month because of that wifi issue.
---edit
In case anyone has any idea, this is the... horror that happens on dmesg when I run ifconfig wlan up to bring up the wifi
[ 59.411902] wl 0000:04:00.0 wlan0: Current addr: 00 25 56 b6 4e 4a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 59.411911] wl 0000:04:00.0 wlan0: Expected addr: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 59.411915] ------------[ cut here ]------------
[ 59.411917] netdevice: wlan0: Incorrect netdev->dev_addr
[ 59.411961] WARNING: CPU: 1 PID: 701 at net/core/dev_addr_lists.c:517 dev_add r_check.cold+0x43/0x7d
[ 59.411972] Modules linked in: rfcomm bluetooth ecdh_generic ecc 8021q wl(PO) snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio uvcvideo videobuf2_v malloc videobuf2_memops cfg80211 videobuf2_v4l2 videobuf2_common snd_hda_intel v ideodev snd_hda_codec mc snd_hwdep snd_intel_dspcfg snd_hda_core rfkill pkcs8_ke y_parser fuse
[ 59.412007] CPU: 1 PID: 701 Comm: ifconfig Tainted: P O 5.18.5 #1
[ 59.412012] Hardware name: LENOVO 20023 /KIWA7, BIOS 18CN19WW(V 1.05) 05/27/2009
[ 59.412014] RIP: 0010:dev_addr_check.cold+0x43/0x7d
[ 59.412020] Code: 01 e8 1d ee f3 ff 0f 0b 49 c7 c4 92 6e cc ae 80 3b 00 75 30 48 c7 c6 9d 6e cc ae 4c 89 e2 48 c7 c7 50 8b e1 ae e8 f9 ed f3 ff <0f> 0b e9 8b 1c d8 ff 49 c7 c4 92 6e cc ae eb d5 4c 8b 24 d5 60 19
[ 59.412023] RSP: 0018:ffffb877c0c17c10 EFLAGS: 00010282
[ 59.412027] RAX: 0000000000000000 RBX: ffff9fdc032b2000 RCX: 0000000000000027
[ 59.412030] RDX: ffff9fdc7d51b428 RSI: 0000000000000001 RDI: ffff9fdc7d51b420
[ 59.412033] RBP: ffffb877c0c17c20 R08: ffffffffaf0c4888 R09: 00000000ffffefff
[ 59.412035] R10: ffffffffaf0548a0 R11: ffffffffaf0ac8a0 R12: ffffffffaecb464b
[ 59.412038] R13: ffffffffc0a30480 R14: 0000000000000001 R15: ffff9fdc032b2000
[ 59.412041] FS: 00007fd8bc339740(0000) GS:ffff9fdc7d500000(0000) knlGS:00000 00000000000
[ 59.412044] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 59.412047] CR2: 0000000000465efb CR3: 000000000c16e000 CR4: 00000000000406a0
[ 59.412049] Call Trace:
[ 59.412052] <TASK>
[ 59.412055] __dev_open+0x43/0x1b0
[ 59.412062] __dev_change_flags+0x1a9/0x220
[ 59.412066] dev_change_flags+0x26/0x60
[ 59.412070] devinet_ioctl+0x5fe/0x810
[ 59.412075] inet_ioctl+0x165/0x190
[ 59.412079] ? netdev_name_node_lookup_rcu+0x61/0x70
[ 59.412084] ? dev_get_by_name_rcu+0xe/0x20
[ 59.412088] ? dev_ioctl+0x46c/0x530
[ 59.412093] sock_do_ioctl+0x45/0xf0
[ 59.412098] sock_ioctl+0xef/0x300
[ 59.412103] __x64_sys_ioctl+0x91/0xb0
[ 59.412108] do_syscall_64+0x3b/0x90
[ 59.412115] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 59.412120] RIP: 0033:0x7fd8bc431648
[ 59.412123] Code: 00 00 48 8d 44 24 08 48 89 54 24 e0 48 89 44 24 c0 48 8d 44 24 d0 48 89 44 24 c8 b8 10 00 00 00 c7 44 24 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 0e 44 89 c0 c3 66 2e 0f 1f 84 00 00 00
[ 59.412126] RSP: 002b:00007ffe792a8d18 EFLAGS: 00000246 ORIG_RAX: 00000000000 00010
[ 59.412130] RAX: ffffffffffffffda RBX: 00007ffe792a9d8f RCX: 00007fd8bc431648
[ 59.412133] RDX: 00007ffe792a8d90 RSI: 0000000000008914 RDI: 0000000000000003
[ 59.412136] RBP: 0000000000008914 R08: 0000000000000000 R09: 0000000000000000
[ 59.412138] R10: 00007fd8bc34dda0 R11: 0000000000000246 R12: 0000000000461660
[ 59.412140] R13: 00007ffe792a8f90 R14: 00007ffe792a8f98 R15: 0000000000000003
[ 59.412144] </TASK>
[ 59.412145] ---[ end trace 0000000000000000 ]---
Display More
This does not happen on le 10 or 9 on x64 on the same hw.