-1

Raspbian stretch (NOOBS)

I have just received a new Raspberry Pi to run scripts on at work, and while I was installing the dependencies for Python 3.7, I ran into a peculiar issue.

The machine is connected to the internet and using the browser to connect to google.com and 93.93.128.93 (raspbian package index) works, as does using wget from the command line. However, trying to install dependencies using apt-get fails with the following error:

Err:1 http://raspbian.raspberrypi.org/raspbian/pool/main/s/sqlite3/libsqlite3-dev_3.16.2-5+deb9u1
  Connection failed [IP 93.93.128.193 80]
E: Failed to fetch [...].deb  Connection failed [IP: 93.93.128.193 80]

Trying to ping the package index leads to 100% packet loss, but connecting to it through the browser works, and using wget, I am able to retrieve the package from the URL in the error without issue.

On the topic of pinging, I cannot ping google.com or 93.93.128.193, but 8.8.8.8 works.

Trying to install the package I downloaded with wget gives me an error message saying "The package download failed. Please check your network connectivity." Same for packages I downloaded from the index through the browser.

Trying to install the package through the "Add / Remove Software" menu option just fails without giving me any errors.

My hosts file is empty except for the loopback addresses. resolvconf only has google's 8.8.8.8 nameserver in it.

I cannot work out why this is not working, there is no pattern to what does and doesn't work.
It can't be the internet because I can use the browser.
It can't be the command line because I can use wget.
It can't be the package index itself or our company firewall because I can access the index through wget and browser.
It can't be the nameserver because pinging IPs also doesn't work sometimes.

Edit 1:

My resolv.conf file is changing.
Before I rebooted my Pi, it read

nameserver 8.8.8.8

but after I rebooted it, it now reads

# Generated by resolvconf
nameserver 188.172.144.120
nameserver 141.0.144.2

Pinging google returns

$ ping -c5 -W5 google.com
PING google.com (216.58.208.142) 56(84) bytes of data.

--- google.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4155ms

Seeing the namespace resolve suggests to me that this may be a firewall/proxy issue that I'd need to contact my company's sysadmin about. This still doesn't explain why ping packets are being blocked but HTTP packets are not unless that is something a firewall can do, and if that is the case, what kind of packets is apt using s.t. I can access the package index through the browser, but not through apt-get?

Sam Rockett
  • 99
  • 2
  • Try putting nameserver 8.8.8.8 back into resolv.conf at the top, then ping google.com again. – goldilocks Nov 19 '18 at 16:14
  • Adding the google DNS helped nothing. The name is being resolved, but the packets are being blocked anyway. This might be a firewall/proxy issue. – Sam Rockett Nov 19 '18 at 16:20
  • It appears you have modified the networking setup. Put it back to standard; see How to set up networking/WiFi It is unclear what "installing the dependencies for Python 3.7" means or what it has to do with your issue. – Milliways Nov 19 '18 at 22:36
  • Does traceroute give you an idea which hop doesn't response? Does dig (maybe dig google.com) give you some more information about name resolution? – Ingo Nov 21 '18 at 09:38
  • I don't have dig, but traceroute is telling me that its bouncing around a lot in 10.0.0.0/8 which just confirms that this is an internal issue, nothing to do with the machine. Thanks for all the help. – Sam Rockett Nov 21 '18 at 09:58

1 Answers1

0

Few questions regarding your question.

  • what is exact content of your resolv.conf file
  • when you ping www.google.com by name does it get resolved or just fails with host not found?

What I suspect here is that you have problem with DNS resolution.
Another option that I experienced some time ago is that apt-get was using IPv6 system and that caused similar problems. That can be resolved by running following command:

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

Command will create new file 99force-ipv4 with content that will force aptitude to use only IPv4.

Bungee75
  • 121
  • 4
  • I edited the question to add the contents of resolv.conf and the result of the ping. I tried the force IPv4 thing but it did not work. This might be a firewall issue... – Sam Rockett Nov 19 '18 at 15:57
  • Well according to your findings you do have blocked access to the net. And yes new generations of firewalls will differentiate between packets not only protocols so even on http level you can block some traffic/applications. – Bungee75 Nov 19 '18 at 21:13