a friend and me are currently developing a ready to go application based on DietPi. The clients (we have a few testers) are Rasperry 3b+ oder Pi 4 from 1 up to 4 GB.
We want to install only over wifi network and here seems to be a problem.
The most testers get problems on the first boot. See the following screen:
After invest some time to find the error, it seems like the Pi’s are getting no IP over wifi. There are a few steps for discovering
If we switch over to ethernet, everything works fine. The problem comes only with wifi!
Other things we tried;:
Restart Router
Change the value in dietpi.txt: AUTO_SETUP_BOOT_WAIT_FOR_NETWORK=1
Change the value in dietpi.txt: CONFIG_G_CHECK_URL_TIMEOUT=15
Change the value in dietpi.txt: CONFIG_G_CHECK_URL_ATTEMPTS=4
Changing the position to the Access Point
Different microSD-Cards
There is something with the Wifi, i installed with onboard wifi (3b+, 4 1GB), different USB Wifi dongles and mostly get no DHCP lease. Other users say the same, the dietpi-Setup has problems.
please see attached dietpi-firstboot.log (a brand new microSD, first use!!!)
I think, there is anything wrong in my dietpi.txt. Maybe here is anyone with an idea?
who? Do you have some forum post related to this issue?
Btw: you did got an IP address assigned
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPOFFER of 192.168.2.52 from 192.168.2.4
DHCPREQUEST for 192.168.2.52 on wlan0 to 255.255.255.255 port 67
DHCPACK of 192.168.2.52 from 192.168.2.4
bound to 192.168.2.52 -- renewal in 16797 seconds.
did you tried to setup tcpdump on the DHCP/dnsmasq server and did some tracing to see if and how DHCP request are managed?
I did a test on my RPi3B+ without issues
First boot log
Initializing machine ID from random generator.
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 0 with SSID "xx"
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 1 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 2 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 3 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 4 with SSID ""
[ SUB1 ] DietPi-Set_hardware > wificountrycode (de)
[ OK ] DietPi-Set_hardware | Setting in /etc/default/crda adjusted: REGDOMAIN=DE
[ OK ] DietPi-Set_hardware | Desired setting in /boot/dietpi.txt was already set: AUTO_SETUP_NET_WIFI_COUNTRY_CODE=DE
[ OK ] wificountrycode DE | Completed
[ SUB1 ] DietPi-Set_hardware > enableipv6 (disable)
[ OK ] DietPi-Set_hardware | Desired setting in /boot/dietpi.txt was already set: CONFIG_ENABLE_IPV6=0
[ OK ] enableipv6 disable | Completed
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/b8:xx
Sending on LPF/wlan0/b8:xx
Sending on Socket/fallback
Created duid "\xxx".
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 20
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 192.168.0.70 from 192.168.0.11
DHCPREQUEST for 192.168.0.70 on wlan0 to 255.255.255.255 port 67
DHCPACK of 192.168.0.70 from 192.168.0.11
bound to 192.168.0.70 -- renewal in 35958 seconds.
[ SUB1 ] DietPi-Set_software > boot_wait_for_network (1)
My first try works. I will ask the other users to try it!
tcpdump:
Yes, the broadcast request didn’t arrive dnsmasq when the problem occurs…
another problem
OK, i found out, that the name resolution of raw.githubusercontent.com fails after the first reboot. Not sure why, if i reboot again and start the installation in the console, it works fine. That’s new since the new dietpi-version.
name resolution is not related to a DietPi version. Do you have a local DNS server? We had a couple of cases where raw.githubusercontent.com was blocked by a local AdBlocker or some other network component. This is a global public URL and should be reachable usually. It if fails, it would be interesting to know which DNS is used at that time cat /etc/resolv.conf
dietpi@MuPiBox:~$ cat /etc/resolv.conf
domain local
search local
nameserver 192.168.2.4
dietpi@MuPiBox:~$ ping raw.githubusercontent.com
PING raw.githubusercontent.com (185.199.108.133) 56(84) bytes of data.
64 bytes from cdn-185-199-108-133.github.com (185.199.108.133): icmp_seq=1 ttl=56 time=31.4 ms
64 bytes from cdn-185-199-108-133.github.com (185.199.108.133): icmp_seq=2 ttl=56 time=25.6 ms
192.168.2.4 is my dnsmasq-Server. Github was never a problem before, i am really confused this time. And chromium also don’t want to work, damn, the update makes me sad.
But this has nothing to do with DietPi or an update of our scripts. As you can see on your picture, internet as well as DNS check passed. You are able to ping Quad9 IP + DNS name, indicating a valid internet connection. At least as long as you did not changed the default network connection taget IP + DNS. Means, your system is connected to a local network, your system has internet connection. The thing not working seems to be your DNS resolution for specific web sites.
Have a look to your DNS server setup why raw.githubusercontent.com is not being resolved correctly on your local network.
I hope not! And i see the request (whitelistet) in the logs of AdGuard.
And please notice: in the old version of dietpi, the setup works fine. It is since the new version.
If i disable IPv6 in dietpi.txt, it is like rolling dices, sometimes it works, sometimes not. I tried really a lot of things and my network is strict IPv4. Not sure why this is a problem. I will change to activate IPv6 and it works for me
