Cannot get WiFi to work, RPi3B+

Hi, I downloaded an image from this official website just today, from link:
I have a Raspberry Pi 3 Model B+, I’m using genuine PNY 32Gb MicroSD cards. Device is powered by 2.4A USB Charger. Using 3.5" “Waveshare-copy” TFT with 480x320 resolution, connected via HDMI. (EDIT: Image flashed to card with Etcher on Win10)

Armbian, Raspbian, RetroPie. All of these are tested and working on this exact same hardware (even the same MicroSD, just reflashed while testing).

Flashed OK, first boot OK (but resolution wrong so it was REALLY difficult to read anything). Got resolution changed via /DietPi/config.txt, because dietpi-config does NOT have 480x320 as selectable resolution (really? WHY? This is such a common display this SHOULD be there by default!).

went to dietpi-config → Network and tried to configure that. Turning Ethernet/WiFi on/off activates a script that does… something, and then errors out because it can’t find command “rfkill” and says it has no installation candidates. BUT it seems still to have activated/deactivated what it meant to in the first place.

OK, then go to configure WiFi settings… Selecting "Scan and … " auto-setup just blinks the screen really fast. I had some trouble seeing what’s happening, but after hitting enter like a crazy woman for awhile I managed to see that it can’t find “iwlist” and then just quits.

Setting AP/Passwd manually doesn’t seem to work, or more precisely I can set them up, but it does not connect to the network.

I don’t have Ethernet available at that spot, and WiFi is working with that exact same board across all other operating systems.

So… what can I do? I really would like to test out DietPi, it looked like something I’d like to use and I thought because RPi is the most prominent board out there (not the best, but the one with most active community), it would work right out of the box like everything else (well, except I always have to change screen resolution, because these Waveshare-knockups for some reason report their max res as 1920x1080 and it is NOT usable like that)…



usually you can configure Wifi before first boot following the Getting started Guide, Step2 (Optional (Wifi))

Anyway you should be able to configure WiFi as well from DietPi Config as well. On my RPi3B+ I don’t have any issues using WiFi.

Question: do you have Ethernet connection while you are trying to active WiFi?

Many thanks for reporting.

Very strange, I just verified that:

  • rfkill is installed by default on the image, the package is installed and the command is present.
  • iwlist is part of the wireless-tools package, which is as well installed by default, command is available.

So if you did not manually remove those packages, something went wrong during flashing or similar.
Of course if WiFi packages and related commands are missing, WiFi config and connections cannot work.

About the resolution one has to separate between HDMI resolutions (which is what dietpi-config resolution options refers to) and e.g. I2C touch or similar mini LCDs. For HDMI, the Raspberry Pi officially does not have any 480x320 mode:

I don’t know which LCD you have, but there is a separate LCD menu which supports to auto setup some. But there are uncountable different LCDs, so in some cases one needs to setup them manually, including the correct resolution, respectively framebuffer size, like on Raspbian. Note that DietPi is an overlay for purified Raspbian/Debian, hence one can follow any guide for those distros on DietPi as well.

So I would try a fresh download and flash, then run an fsck across the two partitions from another Linux system (if you have one) to assure that the SDcard does not have bad blocks, that could explain the missing WiFi commands/packages.
Then pre-configure WiFi via dietpi.txt on the FAT partition, as suggested by Joulinar and the LCD configuration via config.txt accordingly.

Yeah I read that, but I figured since I’m not running headless I might as well configure everything on the device itself. I’ll flash again and try that route.
About the Ethernet, I’ll quote myself

I don’t have Ethernet available at that spot […]

So, no :slight_smile: Even if I wanted one. I tried with eth0 disabled/enabled via dietpi-config, but it didn’t make any difference (other than if disabling either one, it automatically also disables Onboard WiFi, which needs to be enabled separately after that. No big deal though.)

I didn’t remove anything. All I did before dietpi-config and all that, was to change the resolution over at config.txt

Oh. Thanks for letting me know. That’s kinda weird since the 480x320 displays seem to be the most common. I wonder if that’ll change in the near future.

It doesn’t need any LCD auto-setup or anything, it’s connected via HDMI. Well, it could be connected via GPIO and used like that, but I prefer using HDMI because I have had less problems that way - no drivers needed, it just works (well, beside the resolution).

I’ll try downloading and flashing again as we speak. I’ll most probably come back and report how it went.

Thanks for all the replies!

Ah okay, and changing framebuffer_width + height in config.txt alone makes the whole LCD being filled with correct resolution?

Correct. Well, “filled”. It leaves just a bit of black either side of the screen, but the image is crips and sharp, so I’m guess the screen does something fishy to get 16:9 resolutions work, or then it is actually a 480+ x 320 display (like 500x320). Anyway, setting the framebuffer to 480x320 makes the screen work as well as I expect it to. (in Console, that is, haven’t tried X yet).

btw does the WiFi issue still persist?

Uh… No, but yes. It’s kind of funny, actually. Lemme explain…

After that last time, I flashed the card again and did the initial textfile configuration route - and everything worked. Well, I could have left it there. COULD. I’m me though, and way too curious… so I flashed again, and installed without touching the text files - and couldn’t get the WiFi to work. I did that… three times? Perhaps four. Each time the exact same result: configure everything in the text files and everything works; don’t touch the text files and WiFi is not working - at all. (Complains about iwlist every time). I suspect something isn’t installed in the first boot if the info is not in the text files. I have no idea though, just spit-balling here.

At this moment, everything IS working (I left it at the last working install).

I’m kinda liking the distro now, I just hoped I could’ve used it on my Orange Pi devices too, but… eh, I might try that script and see what it says about Armbian base installs. (I have a resolution problem with Orange Pi 3 and Armbian that I hope DietPi would fix - Armbian doesn’t have the config.txt settings anymore, but has boot.cmd which isn’t working for some reason. As it works on DietPi right now, I’m hoping it could work on the OPi3 too. But I digress.)

that sounds strange, if it’s working with pre-configured txt files, it should work as well using dietpi-config

One question step into my mind: if you did not use pre-configured txt files, your first installation run should fail due to missing network connection. correct? How did you proceed at this point? Would be good to know as I would like to run a test on my RPi3B+ with a similar setup, procedure as yours.

Yes, that is correct. It fails and displays an error message and then exists the installer/configurator/whatever that thing is called. I’m guessing this is the point when everything changes - it fails, so certain things do not get installed/configured as they should.

Unfortunately, I cannot provide you with the error message or whatever it says, as this is always the first boot of the device, so I haven’t had time at this point to edit the config.txt to set a correct resolution - so my display just displays little tiny (3-pixel-tall) letters that are unreadable. I can guess by colors what’s happening and go with that, but I don’t know what it actually says, sorry :frowning:

It gives me two options, one I guess is “Retry”, because it does something and just brings the same-looking dialog back. The other is something like “exit/abort/quite/etc.”, 'cause that “finishes” the installation and allows me to log in with root credentials and the system is in generally usable state at this point - I can use nano to edit the framebuffer size and reboot. On second boot my screen is correct, but of course the dialog won’t pop up again and I can just log in and start using it.

It’s kind of a moot point though, really, as the recommended way works where you provide the settings before first boot in the two txt files. I think I’m such an edge case here, trying to use it straight without wired connection and no configuring it beforehand.

yes, having a valid network connection is a prerequisite otherwise first boot will fail. In a case like yours, it recommended to use pre-config files to establish network/wifi connection during first boot and to be able to download latest version/updates.

Okay, so generally, when WiFi is required, it is indeed recommended to enable + pre-configure WiFi credentials etc via dietpi.txt + dietpi-wifi.txt before first boot, so the whole firstrun setup can be done as intended.
Else indeed connection test will fail, but it should allow you to enter dietpi-config from the error handler, where you should be able to enable WiFi, enter credentials and establish network connectivity by this, then exit dietpi-config which should allow to you continue firstrun setup. However the dialog could be difficult to read on your little screen, especially if resolution is not set too great. Damn thing that the RPi does not auto-configure HDMI for 480x320 nicely it seems :frowning:.
Else you can also exit firstrun setup (as you did), then manually call dietpi-config to enable WiFi. You can then either run /DietPi/dietpi/dietpi-login manually to redo firstrun setup, or logout/exit+login, or reboot to bring you there.

…I just checked the code. Actually if WiFi was not enabled before first boot (via dietpi.txt), then WiFi modules are disabled and as well the internal WiFi via device tree overlay to free resources. This means a reboot is required in every case after you enabled internal WiFi via dietpi-config.

What I find still strange is the missing rfkill install candidate error, as this is installed on the fresh image and hence the install should not re-attempted. When one interactively disables WiFi via dietpi-config, one is asked whether to remove or keep related APT packages. But during first boot, this is done non-interactively, hence all packages are left in place. I’ll do a test install to verify that.

I removed the session loading of dtoverlays:
This causes some other issues, result might be not what we want anyway. Once a new image is done, this means that one can enable WiFi right from the connection test error prompt during firstrun setup, selecting the dietpi-config entry. At a later release it is planned anyway to add some more solutions right into the error prompt, e.g. enable/disable WiFi, reload all connections, enable/disable IPv6, and some other stuff. The infrastructure to implement this easily has been added just recently.

On my RPI4 I had the same problem.
On first boot, the Wifi was not configured, a few months later I try to enable using dietpi-config - no success, just message:

No supported WiFi hardware was found.

To verify, if this is not a hardware problem, installed a new dietpi instance on an old sd-card, this time enabled WiFi in Step2 (Optional (Wifi)). After installation, no problems wifi is working :slight_smile:

I did a comparison - on the working wifi dietpi installation found installed package “firmware-brcm80211” that was not available on my old setup and installed it:
apt install firmware-brcm80211

Finally after reboot, on the list found wifi device:

~# rfkill list
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
1: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

Last command:
rfkill unblock wlan

Now the wifi is up and connecting :slight_smile:

we had such an issue on DietPi v6.29 but was fixed with hotfix release v6.30

Jep, on all new images rfkill soft blocks are removed and the package afterwards removed.