0

So I've been smashing my face against this for the last few hours. I'm not terribly familiar/comfortable with linux yet, so I'm sure I missed some obvious fix. When I attempt sudo apt-get update, I get this:

pi@raspberrypi:~ $ sudo apt-get update
Hit:1 http://archive.raspberrypi.org/debian bullseye InRelease
Get:2 http://raspbian.raspberrypi.org/raspbian bullseye InRelease [15.0 kB]
Get:3 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages [13.2 MB]
Ign:3 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
Get:3 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages [18.2 MB]
Ign:3 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
Err:3 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
Connection timed out [IP: 93.93.128.193 80]
Fetched 15.0 kB in 1min 9s (218 B/s)
Reading package lists... Done
E: Failed to fetch http://raspbian.raspberrypi.org/raspbia ... f/Packages Connection timed out [IP: 93.93.128.193 80]
E: Some index files failed to download. They have been ignored, or old ones used instead.

As far as I can tell, it's managing to make contact, briefly start to download, and then gets throttled/dies? I've tried to turn off firewalls/enable port forwarding on the router, but I suspect that's not the issue, as it's making contact in the first place (I think at least).

OS I'm running:

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)" NAME="Raspbian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=raspbian ID_LIKE=debian

Any help would be amazing, I'm at a loss and am clearly out of my depth. Imagine a small toddler drowning in a puddle.

Update:

Sources appeared to be the same,

pi@raspberrypi:~ $ cat /etc/apt/sources.list  
#deb http://mirrors.ocf.berkeley.edu/raspbian/raspbian bullseye main contrib non-free rpi  
deb http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi  
#Uncomment line below then 'apt-get update' to enable 'apt-get source'  
#deb-src http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi

As you can see, I did attempt a different mirror, to no change. Sudo apt update resolved the same as apt-get, in that it looked to begin the download, then quickly just stopped. Just a moment ago, I went to http://raspbian.raspberrypi.org/raspbian/dists/bullseye/ in chromium and downloaded the contents-armhf.gz files as suggested, which seemed to display the same issue: the download starts with a slow download speed of (about)7 kb/s dropping quickly to 0 B/s. Occasionally it would just up to a couple kb/s, but then just goes back to 0. Eventually it just fails and lists the reason as Failed -Network error. As a test, I went to the same page and downloaded the same file with firefox on my windows pc. The download went smoothly, no issues. The raspberry pi is connected to the network wirelessly, so I'm off to plug it into the router with ethernet, will update with results.

Update 2: No luck, a physical connection did not resolve it.

Update 3: The information from ip addr and ip route below. It should be noted that for this, I moved it back to wireless so it wasn't cluttering up the counter by the router.

pi@raspberrypi:~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:11:8c:54 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:44:d9:01 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.15/24 brd 10.0.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 86165sec preferred_lft 75365sec
    inet6 fe80::a1dd:5e09:5682:f612/64 scope link
       valid_lft forever preferred_lft forever
pi@raspberrypi:~ $ ip route
default via 10.0.0.1 dev wlan0 proto dhcp src 10.0.0.15 metric 303
10.0.0.0/24 dev wlan0 proto dhcp scope link src 10.0.0.15 metric 303

Addendum to update 3: DHCP on the router is up, and from what I can see (it's a bit weirder than others I've had), it does seem to have an active lease. I should mention that the rpi is able to browse the internet well enough, and I'm accessing it through vnc as well as ssh from my desktop.

Update 4:

pi@raspberrypi:~ $ iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.


wlan0     IEEE 802.11  ESSID:"redacted even though no one would care"
          Mode:Managed  Frequency:2.427 GHz  Access Point: 9C:C9:EB:14:77:EF
          Bit Rate=72.2 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=66/70  Signal level=-44 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:3  Invalid misc:0   Missed beacon:0
Ineptitude
  • 21
  • 6
  • 2
    Does this answer your question? Problems installing blender on a Raspberry Pi 4 – Milliways Mar 20 '22 at 00:03
  • 1
    This is a question answer site. Please don't put the answer inside the question. You can answer your own question by pressing the Answer your own question button. However, since the problem was in the router, and not in the Raspberry Pi, it may be better to delete the question altogether. – user68186 Mar 22 '22 at 14:54
  • Thanks for the correction, didn't realize I could/should do that. As for removing it, I'm not sure about that. While the issue wasn't actually related to apt-get, that's the area it first manifested in. If someone else has a similar network configuration as I do, and a similar lack of technical experience, I would imagine that they may also start with the erroneous assumption that apt-get is at fault. Just because it's not the actual problem doesn't mean others won't start their search with it. – Ineptitude Mar 22 '22 at 22:16

2 Answers2

1

Before changing anything, I'd suggest you first verify that your repo source is properly set. This is easy to do from the command line; your output should be the same as mine:

$ cat /etc/apt/sources.list
deb http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi

There may be some options listed below that about getting "source files". You can ignore that unless you wish to modify & re-compile some of the packages on your system.

The other thing you might try differently is to forego apt-get for apt; i.e.:

$ sudo apt update

Does that make any difference in the results?

If it's a networking issue, it could be unique to your RPi, or it could be something at your "site". You may get a hint about that by visiting the repo (http://raspbian.raspberrypi.org/raspbian/) in your browser on another machine, and try to download something - perhaps Contents-armhf.gz as it's the largest file. Does it download smoothly & quickly? If so, look for errors in your RPi network configuration.

Try those, and if you're still having a problem, please post any additional details you learn - or just let us know your results if there's no difference. The next step may involve ferreting out the source of your Ign and Err lines, requiring a search - for example.

Updates:

  • Your Update 2 suggests you have a networking issue with your RPi. Assuming you have made no changes to your /etc/dhcpcd.conf file, you should do two things:

    1. check your RPi's IP address & route, and post the result to your Q:
    $ ip addr  
... (post the output) 
$ ip route
... (post the output)
    1. look into the DHCP status (or something similar) on your router through its interface. Is the DHCP server enabled & running? Do you see anything in the logs with your RPi hostname; do you see an active lease for your RPi - or the IP address listed above for eth0?? Do you see an active lease for your windows pc?
Seamus
  • 21,868
  • 3
  • 33
  • 70
  • Have attempted, results placed in update to main post! Now off to find a free power outlet by the router. – Ineptitude Mar 20 '22 at 01:32
  • @Ineptitude: Pls see my Updates: – Seamus Mar 20 '22 at 05:38
  • Output has been posted, and man is most of that beyond me. – Ineptitude Mar 20 '22 at 07:11
  • @Ineptitude: The output of ip addr indicates that your RPi's ethernet interface (eth0) is disabled or disconnected. I do not know why your eth0 is listed as DOWN & NO CARRIER - unless you've not connected it properly?? Beyond that, your WiFi seems to have a valid IP & Gateway - which leads me to conclude that your WiFi AP is far away? or has a weak signal? Run iwconfig from the command line & check the output line: Link Quality=70/70 Signal level=-40 dBm is excellent - what do you see? – Seamus Mar 20 '22 at 07:46
  • Updated with the iwconfig information. The eth0 thing is probably because I physically disconnected it after it seemed that the physical connection did not change the situation. Also I did not want to have to explain why there was a small computer on our counter. – Ineptitude Mar 20 '22 at 15:51
  • @Ineptitude: Your wifi signal seems strong enough. And if your RPi functions well with other websites (http seems to work). My next thought is that it's in your router, but your responses here suggest that's not something you control. Other than that, I'm at a loss - no idea what's causing it. Sorry we couldn't help. – Seamus Mar 20 '22 at 21:26
  • The router I control, I'm just terrible with it. Though I fear having to dig through that because it is (against my will) behind a combination modem/router, so who knows what "fun" stuff that that particular combination is introducing. I appreciate the help though. At the very least, I've ruled out apt-get as the problem, and can press on with that. – Ineptitude Mar 20 '22 at 23:00
  • @Ineptitude: Yeah - every router I've ever owned had a different interface, but you learn to look for the common elements. Most do DHCP, and so have logfiles & active lease tables to peruse. Likewise many do filtering - for blocking websites, and some include packet filters/firewalls. Armed with your RPi's IP address, you may try searching these logs for anything relevant. All I can suggest is spend some time with the router interface & "poke around". It really does seem to be your most likely suspect now, but very odd it would impede something as benign as RPi's repo. Very odd! – Seamus Mar 20 '22 at 23:19
  • @Ineptitude: On the off-chance that somehow your RPi's network configuration has been altered somehow, you could try flashing another SD card & starting from scratch. Try running sudo apt update as soon as you're up & running & note any diffs. – Seamus Mar 20 '22 at 23:25
  • I'll probably poke around the router some more once I try another sd card tomorrow evening. Pretty sure that I've managed to disable any security measures that would have caused issues, but if this new image doesn't work, I'll have to keep poking around. May attempt to reserve an address and set the pi to static instead of dhcp? Not sure if that would help, given that it does have a connection, but at this point trial and error will guide me. – Ineptitude Mar 20 '22 at 23:47
  • @Ineptitude: You could try this first as an alternative to static: inform 10.0.0.15/24. Add that to the end of /etc/dhcpcd.conf. If you want to go full static, you need to declare not only the ip address, but also routers and name_servers. See man dhcpcd.conf for details. – Seamus Mar 21 '22 at 03:07
  • Problem solved, specifics in main post. Thanks so much for the help! Was quite educational in general troubleshooting. – Ineptitude Mar 22 '22 at 00:43
  • @Ineptitude: Good for you! – Seamus Mar 22 '22 at 09:29
1

RESOLUTION: The pi is behind two layers of routers (one is a combination modem/router). I've connected the pi physically to the modem/router itself, and this seems to have resolved the issue. Long term not ideal, but it has narrowed the issue down to needing to learn more about router administration. Mystery solved!

Ineptitude
  • 21
  • 6