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
Here you can find the dietpi.txt we use: MuPiBox/dietpi.txt at main · splitti/MuPiBox · GitHub
did you configured the WiFi credentials using the dietpi-wifi.txt? Otherwise the system doesn’t know where to connect to
and if you go to dietpi-config? What is shown? Did you checked journalctl after reboot? Maybe there are information on why WiFi is not connecting.
BTW: Did you use correct WiFi country code?
I also tried GB and DE as Country Code. Please wait for the logs …
OK, some Update…
- Here is my dietpi.txt => https://mupibox.de/download/dietpi.txt
- 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?
Other users say the same
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.
The first run ended successfully
Not in a Forum. We have a Discord-Channel and a few testers for the project MuPiBox. It is not released and at development stage!
If i use a static IP i have no problems. It happens always in the very first setup steps and sometimes the Pi get’s an IP, sometimes not.
I also restarted my DHCP-Server (dnsmasq), my Router (Fritz-Box) and my AccessPoint (R7000 with Tomato). Static works, DHCP not…
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)
DHCP Server log
Apr 8 11:54:21 dnsmasq-dhcp: DHCPOFFER(eth0) 192.168.0.70 b8:xx
Apr 8 11:54:21 dnsmasq-dhcp: DHCPREQUEST(eth0) 192.168.0.70 b8:xx
Apr 8 11:54:21 dnsmasq-dhcp: DHCPACK(eth0) 192.168.0.70 b8:xx DietPi3-WiFi
Apr 8 11:58:23 dnsmasq-dhcp: DHCPRELEASE(eth0) 192.168.0.70 b8:x
Apr 8 11:58:45 dnsmasq-dhcp: DHCPDISCOVER(eth0) 192.168.0.70 b8:xx
Apr 8 11:58:45 dnsmasq-dhcp: DHCPOFFER(eth0) 192.168.0.70 b8:xx
Apr 8 11:59:04 dnsmasq-dhcp: DHCPDISCOVER(eth0) 192.168.0.70 b8:xx
Apr 8 11:59:04 dnsmasq-dhcp: DHCPOFFER(eth0) 192.168.0.70 b8:xx
Apr 8 11:59:04 dnsmasq-dhcp: DHCPREQUEST(eth0) 192.168.0.70 b8:xx
Apr 8 11:59:04 dnsmasq-dhcp: DHCPACK(eth0) 192.168.0.70 b8:xx DietPi3-WiFi
Maybe the solution is to set the IPv6 Option:
My first try works. I will ask the other users to try it!
Yes, the broadcast request didn’t arrive dnsmasq when the problem occurs…
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
Sometimes i get this error, sometimes not.
I am using dnsmasq for my local network and adguard for the internet.
Here is the error again:
dietpi@MuPiBox:~$ cat /etc/resolv.conf
dietpi@MuPiBox:~$ ping raw.githubusercontent.com
PING raw.githubusercontent.com (220.127.116.11) 56(84) bytes of data.
64 bytes from cdn-185-199-108-133.github.com (18.104.22.168): icmp_seq=1 ttl=56 time=31.4 ms
64 bytes from cdn-185-199-108-133.github.com (22.214.171.124): 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 don’t think so. I tried another installation 10 minutes later, nothing changed and it worked.
The ping was send from the Pi directly after the installation was crashed.
And finally for blocking issues, i have a custom whitelist-filter:
So with IPv6 activated, everything works fine. Strange…
are you sure on IPv6 your system is not bypassing your local DNS server?
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.
What exactly is your issue now?
Is it WiFi not connecting?
No IP address assignment via DHCP?
DNS resolution for raw.githubusercontent.com?
Can you have a look?
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
For purpose of narrowing it down: What happens when you try a different DNS server?