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
Improve this question
3
  • 2
    Does this answer your question? Problems installing blender on a Raspberry Pi 4
    – Milliways
    Mar 20, 2022 at 0: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, 2022 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, 2022 at 22:16

2 Answers 2

Reset to default
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?
Improve this answer
13
  • Have attempted, results placed in update to main post! Now off to find a free power outlet by the router.
    – Ineptitude
    Mar 20, 2022 at 1:32
  • @Ineptitude: Pls see my Updates:
    – Seamus
    Mar 20, 2022 at 5:38
  • Output has been posted, and man is most of that beyond me.
    – Ineptitude
    Mar 20, 2022 at 7: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, 2022 at 7: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, 2022 at 15:51
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!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.