65.182.224.39 is the address for the mirror that Raspbian is trying to send you to. But you have masked that address internally to your network with the 65.0.0.0/8 block, so it fails over to IPv6 and there is no IPv6 available. If you change your network to a non-public IP address space, you should be able to get the packages again.
I don't know how that even happens. Cause when I run raspbian without pihole I have no problems. It's only after an install of pihole and a reboot after that is when this exact problems occurs.
So something is changing on its own.. It's only on a fresh install of pihole. My other pi's run perfectly fine but those were updated straight from the older versions and from an older version of raspbian. I don't know why a fresh install does this.
It makes no sense that everything else works and works perfectly. And that only after installing pihole is when it does this...
Is there a way for me to install an older version of pihole? Before the slew up updates? I'm confident I won't have any problems if I install that and update from there. But no way to be sure until I try. Of if it's even available
Is that all the solution you can offer me?
I'm confident it's not my ip range for my network. Cause it's worked fine for 20 years and I've configured multiple pi's on this network. And the raspbian works perfectly normal until I install the new version of pihole...
This problem started after the update of pihole. Cause I installed a fresh copy of pihole on a fresh image of raspbian recently onto someone else's pi on this very same network and it worked fine, I believe it was v2.9.1 when I installed it. Or around there. pre-2.10
I'm not sure what version after 2.9.1 this started happening. I just know it was during the big stream of updates over December that broke my pi. To fix it, I have to reflash the raspbian image and start from scratch..
What changed during that updates that could cause this?
Let's take the Pi-hole out of the entire operation:
What is the result of ping 65.182.224.39 from any machine?
@SubatomicGenome Let me get this straight...
Your internal network is setup as:[quote="SubatomicGenome, post:11, topic:1365"]
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 65.4.154.41 0.0.0.0 UG 202 0 0 eth0
65.0.0.0 0.0.0.0 255.0.0.0 U 202 0 0 eth0
pi@raspberrypi:~ $
Or probably this
default via 65.4.154.41 dev eth0 metric 20265.0.0.0/8 dev eth0 proto kernel scope link src 65.4.154.51 metric 202
pi@raspberrypi:~ $
[/quote]
If I'm reading this right, you have essentially reserved 65.0.0.1 - 65.255.255.255 as addresses for your internal network...
Recently the raspbian mirror detector had some downtime (like, in the last week), and it's possible (though I can't confirm) that before the downtime it did not resolve to 65.182.224.39, and it just happens that now it's back up, they have changed the IP address their end (new servers/hosts?)
So if I'm thinking correctly, you are currently telling devices on your network "If you want to resolve any address on the 65.0.0.0/8 range, then it's internal, so look for it there")
What is the result of traceroute 65.182.224.39 for you? Both from the pi with pi-hole, and from another device (if Windows, switch out traceroute with tracert)
I don't know, I'm not a network expert by any stretch of the imagination but if you're using a range that is reserved for/by ARIN then you're going to have a bad time when anything on your network wants to reach any one of 16777214 publicly resolvable IP addresses in the world.
My W7SP1 machine, a remote pi running raspbian with pihole (This guy is not on my network), my pi2 as my mumble server and pihole that's currently working, and my pi1 (This is the device in question) that isn't working after an install of pihole. I can reflash this image on this very same device, update it and ping it again before an install of pihole if you'd like to ensure that it will work on this device. I have another pi3 here as well that breaks all the same, I can plug in and flash raspbian on that too if you'd like to cover bases.
All the other ones on my network were all updated from both older versions of raspbian, and older versions of pihole. It's only installing the new version on a fresh image is when I get this issue. What I can do is take this thing down to my neighbor's house to verify that it is breaking on his network. Just to double check.
What device is at 65.4.154.51? That's the one that has determined that the destination is unreachable.
And when just to try and duplicate, when you say new and old Raspbian, what dates are you referring to? Jan 2017 and Nov 2016?
traceroute 65.182.224.39 from the devices to see where the traffic is going and coming from would also be helpful.
65.4.154.51 is the device that is breaking. That is the Pi1. And it doesn't have this problem until after an install of pihole.... But it will work before a reboot. After a reboot this is what happens. And then I can not install anything.
The most recent 2016 image and 2017 image both do this. I installed a fresh raspbian jessie 2017 image because I thought a fresh raspbian update would fix it. So I went ahead and started over on several devices. But no go.
Lets compare routing tables then, what do the tables look like on a working compared to the non-working Pi?
Also, traceroutes to the target address from a working and non-working Pi would help narrow down the field we are looking at.
Is this what you are looking for?
I just noticed destination on both. 65.4.154.100-255 is my internal range. the broken pi has 65.0.0.0 that's way further back than it's supposed to be.
Yes, the device on the left is set to a network of 65.4.154.0/24, which is a very narrow range, (65.4.154.0-65.4.154.0.255 inclusive.) That one has no problems reaching 65.182.0.0 since it's on a completely different network.
The device on the right is set to 65.0.0.0/8 (65.0.0.0-65.255.255.255 inclusive.) That network block includes the target address 65.182.224.39 and routing fails.
So, even though using a public IP block internally for private addressing is a bad choice, if you set the right to 65.4.154.0/24 netblock, then you will get the repository back. But any address in that range that comes up in the future will fail.
How do I manually set the device on the right? And why did it do that only after a restart? My network range actually goes from 65.4.154.100-255 that's what DHCP assigns to any device that connects to my network. Anything 65.4.154.0-99 are manually configured. But I have nothing in those ranges at the moment. so 0-24 is totally open an unbothered.
I also configured noththing further on the pi's other than running the commands to get them installed. Anything else that happened was done without my knowing by the device during setup I assume. The mumble on the Pi2 is something I've had for a long time so that has all of my input and configuration. Everything else is pretty straight forward. Install pi. Set dns, browse internet. That's all I did on either pi when installing pihole
Previous to the reboot, the device was using the IP address given via DHCP. On install, we ask for an IP and set it static via dhcpcd5 which is the Raspbian preferred way to set static IP addresses. The initial address via DHCP works on your network, and the static IP doesn't come into effect until the reboot.
Looking over the code to see if there is a way for / notation to change depending on the network block picked.
And you can use any address you'd like in the /24 network block, but the best would be to set a static reservation at the router and manually enter that address when asked for configuration information.
We'll review the IP selection code and see if there is any way that we could have been given a /8 CIDR mask.
We allow the kernel to choose the natural mask for the address given, instead of using the CIDR notation of the address. Trying to determine a way to choose the proper address with CIDR notation and not select a secondary IP address that manifested in another bug on a different issue with interfaces having multiple IP addresses assigned to them.
I actually have static addressing for every device on my network in my network range. This pi, no matter what OS I put on it will always be at .51 same with my Pi2 at .52 and so on. I do hosting and we get power outages. So when everything comes back online it's the best way to ensure ports all go where they need to go. Static ipv4 assigned to each MAC on my network for permanent devices. I don't manually assign guests since it doesn't matter.
It's just weird that it brings it from the working 65.4.154.0/24 a working range to 65.0.0.0/8.
Seriously, thanks again for taking the time to deal with this. I'm a primary Windows user, I've always used linux but I game so primary machine was always a windows machine. I have experience with linux but only the basics to use it really. I've learned a lot so far. Thanks again.
I'm trying to get a fix in that will work. For now, try running pihole -r and choose reconfigure. At the IP address prompt, enter in 65.4.154.51/24 and then the gateway for the device. After that has run, reboot the Pi so it picks up the new configuration. (The /etc/dhcpcd.conf file should now have the /24 at the end of the IP address.) That should have you back online. But just keep in mind that you are using a block that could be out on the Internet if you have situations like this. The /24 is smaller and will have less chance of collision, but the chances are still there.
If it tests out okay this will go in the next release in a few days.
I ran the reconfigure with pihole -r and did as you instructed, It didn't work.
And I had no idea I was using a public block. I've seriously been using that exact ip address for my LAN since like 1998.
Next time I upgrade firmware on my router I'll take the time to go through each set of ip's and transfer them over to a different private block. This has never happened before.
I did notice an extra entry on the pi1 (Broken pi) in the dhcpcd.conf for eth0
On the one on the right, take out the upper block from ## to .41 so that you just have the lower block of
## interface eth0
to the end. You want the static ip_address to be the line ending in /24. There may be another issue with duplicating the static address blocks, but we'll take a look.
The fix should be in the next release and will allow you to use any network mask that you would like.
Yeah, that worked.
htop installed right away no problems.
This has been interesting. Sorry for being a wrench in the wheel here.. This is the first time my local ranges have EVER given me a problem.
Thank you again for all your effort. I am very grateful. What kinda beer do you drink? I'll donate enough to get you a 6 pack of it =D