brtravel
could you try the following on the buster image?
wget http://fuzon.co.uk/meveric/pool/xu3/l/linux-image-4.14-armhf-odroid-xu4/linux-image-4.14-armhf-odroid-xu4_4.14.173-1_armhf.deb
He could be using a vpn, hard to tell if I don’t see a traceroute from the system that successfully reached the destination.
thank you Joulinar and trendy, I really appreciate the help
192.168.1.1 is my router, 192.168.13.1 is the gateway of the WISP I connect to, and I assume 192.168.14.1 is something else in the WISP system. they have been down a couple times for maintenance/repairs recently, perhaps they changed something that’s affecting me. Unfortunately they are not very helpful with customer service.
Joulinar when I run a traceroute on my macbook it looks like the DietPi traceroute with just …1.1, …13.1 and …14.1. No VPNs active. But the Macbook has no problem opening those sites and downloading files. They are on the same simple network, only difference is DietPi is wired and Macbook is on wifi.
Just tried that on the Buster image, seems to have ran fine:
root@DietPi:~# wget http://fuzon.co.uk/meveric/pool/xu3/l/linux-image-4.14-armhf-odroid-xu4/linux-image-4.14-armhf-odroid-xu4_4.14.173-1_armhf.deb
--2020-03-28 02:26:34-- http://fuzon.co.uk/meveric/pool/xu3/l/linux-image-4.14-armhf-odroid-xu4/linux-image-4.14-armhf-odroid-xu4_4.14.173-1_armhf.deb
Resolving fuzon.co.uk (fuzon.co.uk)... 185.101.93.34
Connecting to fuzon.co.uk (fuzon.co.uk)|185.101.93.34|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1422 (1.4K) [application/x-debian-package]
Saving to: ‘linux-image-4.14-armhf-odroid-xu4_4.14.173-1_armhf.deb’
linux-image-4.14-armhf-odroid-xu4_4.14.1 100%[================================================================================>] 1.39K --.-KB/s in 0.004s
2020-03-28 02:26:40 (359 KB/s) - ‘linux-image-4.14-armhf-odroid-xu4_4.14.173-1_armhf.deb’ saved [1422/1422]
Right after, I tried to open dietpi-software and got the DNS Resolver error, hit Retry and it went through the second time 
Tried to install only Samba, that failed:
DietPi-Software
─────────────────────────────────────────────────────
Mode: Configuring Samba Server: feature-rich file server
Added user dietpi.
[ OK ] DietPi-Software | /etc/samba/smb.conf: backup to /etc/samba/smb.conf.bak_280320_0
[ INFO ] DietPi-Software | For a full list of backup items, please see /var/tmp/dietpi/logs/G_BACKUP_FP.db
[FAILED] DietPi-Software | Connection test: https://raw.githubusercontent.com/MichaIng/DietPi/master/.conf/dps_96/conf
[ INFO ] DietPi-Software | If problems persist, please report at https://github.com/MichaIng/DietPi/issues for investigation.
UPDATE:
I think we were all starting to suspect the ISP, well I configured a VPN on my router and while active the DietPi device seems to be operating perfectly and able to access all repos.
I’m not optimistic about trying to resolve the issue with the ISP, so needing to activate a VPN when I want to run an install or update isn’t so bad.
So do I understood right, that if you activate the VPN on your router all is working fine? Maybe you ISP has some strange issues and is blocken access for unknown reason quite randomly.
Yes, correct. It is very odd, and since they don’t have great customer service I’ll probably just leave it be. Log into my router and turn the VPN on whenever I want to run some DietPi updates or install new software.
ok good. at least we could figure out the strange behaviour even if we did not fixed it fully. Maybe your ISP will get it solved soon and you did not need to use the workaround for long.
I must say, I actually get simular issues when doing a dietpi-update from .26 to .28:
DietPi-Update
─────────────────────────────────────────────────────
Mode: Installing new DietPi code
######################################################################## 100.0%
[ OK ] DietPi-Update | Unpacking update archive
[ OK ] DietPi-Update | Installing new DietPi scripts to RAMdisk
[ OK ] DietPi-Update | Installing new DietPi system files to disk
[ OK ] DietPi-Update | Setting execute permissions for DietPi scripts
[ SUB1 ] DietPi-Set_software > verify_dietpi.txt ()
[FAILED] DietPi-Set_software | Connection test: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi.txt
[ INFO ] DietPi-Set_software | If problems persist, please report at https://github.com/MichaIng/DietPi/issues for inves tigation.
[FAILED] DietPi-Set_software | Connection test: https://raw.githubusercontent.com/MichaIng/DietPi/master/dietpi.txt
[ INFO ] DietPi-Set_software | If problems persist, please report at https://github.com/MichaIng/DietPi/issues for inves tigation.
[ INFO ] DietPi-Bugreport | Packing upload archive, please wait…
[FAILED] DietPi-Bugreport | Connection test: ssh.dietpi.com
[ INFO ] DietPi-Bugreport | If problems persist, please report at https://github.com/MichaIng/DietPi/issues for investig
Just to let you know, you’re not the only one.
I have a large file move running now, so I cannot test anything, and I did mess with vpn a while ago, so will look into that first.
I don’t want to hijack this thread, and will make a new one if needed…
I used to have the same problem. Dietpi comes with nameserver 1.1.1.1 preconfigured in
/etc/resolvconf/resolv.conf.d/head
however I am hijacking all outbound queries and allow only my Pihole severs.
Before the query times out and the next (allowed) NS is queried, the script times out and appears as failed connection.
I solved it by removing the entry from the head file and then worked fine.
MichaIng I don’t see the point of hardcoding a NS, but if you insist at least place it in tail so the configured NS will be first to be queried.
trendy
Ah, which image do/did you use? I remember one report and already removed/reset the resolvconf head on that particular image to be empty. It is definitely not wanted but was shipped by the pre-image, not recognised by me since the default DNS on DietPi was 1.1.1.1 as well (as long as not overridden via DHCP), now 9.9.9.9 btw.
Finally new images from now on are shipped without resolvconf, as it is not required, which resolves such issue on the basic level. However it can be installed to use its features without breaking anything.
Last time I came across it was in the raspberry and the rockpi.
I downloaded the raspberry image about a month ago and the rockpi a couple of months ago.
trendy
Don’t mix the DNS/Ping connectivity check with the DNS resolution setting for the network interface. These are 2 different thinks. On the Rpi image, it was never the case. I’m using DHCP on all my RPi’s and they all use my PiHole. Non of them is going to a hard coded 1.1.1.1 DNS server.
Mattie
It would be good to know what exactly your issue is. Is it DNS resolution or connectivity? I doubt it’s similar to the original reported issue.
Are you also hijacking the queries that try to bypass the pihole?
there are no queries bypassing PiHole. All my RPi’s using just one singel DNS Server
root@DietPi3:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.11
search lan
root@DietPi3:~#
root@DietPi3:~# cat /etc/resolvconf/resolv.conf.d/head
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
root@DietPi3:~#
I just downloaded them again.
In Raspberry image there isn’t anything, so I could be wrong or it was fixed.
In RockPi image there is still nameserver 1.0.0.1 in /etc/resolvconf/resolv.conf.d/head
for me it was openvpn messing it up, it worked when i disabled the vpn service
trendy
Thanks for the hint, it is the ROCK Pi 4 image, right? I’ll fix and repack that.