wlan0 issues with wpa_cli [rpi3b+]

[tswaehn]

I am using wpa_cli to manage the wlan0.

sudo wpa_cli -i wlan0 status
Failed to connect to non-global ctrl_ifname: wlan0  error: No such file or directory

However this way seems to be broken since a couple of days.

I figured out that there was a new firmware for wifi 2 days ago. Switching back to old firmware makes wpa_cli to properly work.

Not sure how to continue.
(1) maybe this is a wpa_cli issue - not fitting to newer firmware
(2) maybe this is a firmware issue

I filled and issue here : RPi-Distro/firmware-nonfree#6

[burnbabyburn]

so the combination of firmware and old kernel is the prob? if you skipped compiling your own kernel, it's possible the links for the precompiled ones are not up to date.

Enabling nexmon makes the script using another, possible outdated, kernel source too.

[tswaehn]

It’s actually difficult all in all. How can we make sure the precompiled kernel fits to the Debian stretch or buster release from ftp.debian.org Same way, how to make sure the downloaded firmware fits. This topic is kind of solved as “taking the correct files” does the job. However, for me it opens the question of consistency kernel, packages, firmware (WiFi + boot). Best Sven

…

Am 24.10.2019 um 21:19 schrieb burnbabyburn ***@***.***>: so the combination of firmware and old kernel is the prob? if you skipped compiling your own kernel, it's possible the links for the precompiled ones are not up to date. Enabling nexmon makes the script using another, possible outdated, kernel source too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[tswaehn]

I am wondering about the design target of the rpi23-gen-image project :

(1) Should rpi23-gen-image create an image which always succeed and be dummy proof?

or

(2) Is the rpi23-gen-image a guideline of scripts that can be used to determine a valid image - but its in user hands to make things fit together (Kernel + DEB packages + firmware)

My personal opinion is actually (2), which is easier to fulfill. Where (1) needs qualified and tested branches / tags. (But this is just my stupid opinion.)

[tswaehn]

(BTW. we can rename the topic as it ended up in a more general discussion)

[drtyhlpr]

hi there!

sorry I don't have much time left for this project. thanks burn for the patches etc.

In my opinion rpi23-gen-image should always create the "complete" and working output image. I think there are plenty options to extend and or append "all" the non std deps, pkgs, late includes, custom includes etc. with the regular command line parameters of the script. Hm the idea is to create a advanced non standard rpi23 image (the idea "back then" was to create a minimal rpi image cause there was no -minimal- variant of the offical rpi image "back then"). The script may not be dummy proof.

I don't know if its debian specific. but it is just sad and boring in my opinion how often the regular, minimal boot os installation gets broken by new patches or features. AND the way these changes are sometimes communicated (hey just let the user find out...) but this is only my opinion based on the experience with this project so far. sure the goal was to create a rock solid minimal build script (if you use it without any custom options) that should create a minimal working output image now and in the future.

ps. i think the self encrypted full hd encryption of the size optimized generated output image, and its onboot expand is quite unique (for any bootstrapping script you will find ... well i think), not sure if its still working fine or used mutch :)

[tswaehn]

I think its possible to achive a rock-solid image that builds out of the box.

BUT: it needs well selected sources for the downloads (kernel, deb-packages, firmware, wifi-firmware) and it needs to be maintained, at least for the standard package.

BTW: this project is awesome cool! Its exactly what I need - just a small image with essential packages.

Dont get me wrong, I just wanted to understand what the target is, then we can fine tune. No problem.

[burnbabyburn]

(2) Is the rpi23-gen-image a guideline of scripts that can be used to determine a valid image - but its in user hands to make things fit together (Kernel + DEB packages + firmware)

This! There will be errors as i think its too much work to test all combinations possible atm . Especially if we now add wifi_fw to the calculation.
Just by scrolling through the readme, looking @ all those options, makes me NOT wanna build test cases for this. We would need someone that is willing to do the auto/continoues integration,building,testing stuff. E.g. i was not able to get a chroot in travis, but maybe you have to use docker... i dunno
BUT the goal should be, that building the default config always succeeds. I tried to fix that by raising default kernel version to 4.19. As its the same version used in raspian. That should fit atleast latest wifi_fw. Maybe i add additional description to the readme, which option changes kernel source so you atleast know when to change wifi_fw.
Adding an option for selecting wifi_fw, finding the git commits of wifi_fw fitting your kernel version etc is not on my agenda. I just go latest/most recent, but i would be happy to see some pulls for that :)

So my way to contribute is by fixing the reported errors and do build an image from time to time. I have more fun adding stuff that i want in my fork and pull back some of the changes that imho fit to the projects scope. Even getting a clean and proper pull done can take some hours.

In my opinion rpi23-gen-image should always create the "complete" and working output image. I think there are plenty options to extend and or append "all" the non std deps, pkgs, late includes, custom includes etc. with the regular command line parameters of the script. Hm the idea is to create a advanced non standard rpi23 image (the idea "back then" was to create a minimal rpi image cause there was no -minimal- variant of the offical rpi image "back then"). The script may not be dummy proof.

That's also my understanding of the projects scope.

[tswaehn]

Thats perfect explaination. Thank you for all your thoughts on that topic.

[tswaehn]

(I close that issue as it was remote repo firmware releated)

[tswaehn]

BTW: I solved this topic by forking the original firmware repo and rolling back to the last "known" working version.

That means for stretch you can find a tested firmware repo here: https://github.com/rpi23-img/firmware-nonfree

[tswaehn]

I just thought about re-open.

Why?

Because I think I could create a branch or tag on that repo and finally modify the default-templates of stretch to point here.

So basically this will be a reminder for myself to fix it :)