[12:51] Hello. My ubuntu 20.04 LTS failed on apt-get update command. I don' know why. Here is the error which I got: https://dpaste.com/FMHHNP659 [13:01] xyzluki: That host is reachable for me, could you try running the same command again? Maybe it was just a hickup [13:02] If not, I would guess there's something up with your network. Are you behind a corporate firewall or something, maybe? [13:06] I am trying again apt-get update [13:07] I got the same error [13:09] I am using my home network. My pc is using wire connection. It is connected directly to ISP infrastructure present i my apartment building [13:09] at home I don't have any router [13:12] I am bale to ping us.archive.ubuntu.com and archive.ubuntu.com [13:13] but I can't access from web browser above sites.The interesting thing is that I can access https://pl.archive.ubuntu.com/ubuntu/ from web browser [14:10] In the meanwhile, I asked my ISP if everythng is ok on their side. I am waiting for the feedback [14:23] can you try `mtr --report -T -P 80 us.archive.ubuntu.com`? [14:24] pl.archive is a community mirror while us.archive is our own infrastructure [14:24] but we've had some routing shenanigans in the past, so this could be a number of things. [14:25] Have you isolated IPv4 and IPv6? [14:25] Your error shows v4 addresses... [15:09] Can I paste output from mtr here ? [15:10] best to use pastebins for larger text output xyzluki [15:10] oki, sure [15:10] https://dpaste.com/2W9V9HCL8 [15:11] xyzluki: Can you add -n to mtr and run it again? [15:11] yes, sure [15:13] https://dpaste.com/BUGB4VCC2 [15:14] xyzluki: Looks like you don't have IPv4 connectivity at all [15:14] it looks really strange [15:15] Can you try it with -6 added? [15:15] can you ping 8.8.8.8 ? just to check your general ipv4 connectivity [15:15] other websites works ok like. ubuntu.com, dpaste.com [15:15] xyzluki: ubuntu.com works with mtr? [15:15] dpaste thinks I'm spamming. Can you use pastebin.ubuntu.com? [15:16] ping 8.8.8.8 works well [15:16] Our hostnames will have both A and AAAA records, so if you have ipv6 connectivity but not 4, that should work. Not sure what apt is doing [15:16] xyzluki: What does "host us.archive.ubuntu.com" say? [15:17] mtr --report -n -T -P 80 ubuntu.com looks the same as for us.archive.ubuntu.com [15:18] https://dpaste.com/4HC7FEST8 [15:19] above link is the output from host us.archive.ubuntu.com [15:19] Spads: can you share a screenshot of the dpaste message? we are testing dpaste.com for #ubuntu support, but this sounds not ideal. [15:20] xyzluki, and you can also ping 2001:67c:1562::15 ? [15:20] tomreyn: it just has the text "You have exceeded our rate limit of 1 request per second. Please pause at least 1 seconds between requests. Full terms: http://bit.ly/dpaste-tos" [15:20] I haven't done more than one request every five minutes, tops [15:20] i know that apt can have some problems if your system thinks it has ipv6 but actually doesnt [15:21] Spads: i assume 'your' egress ip address has, though, if you're on canonical vpn? [15:21] as Spads asked earlier. mtr with -6:mtr --report -6 -n -T -P 80 us.archive.ubuntu.com shows message: mtr: udp socket connect failed: Network is unreachable [15:22] xyzluki, try if "sudo apt-get -o Acquire::ForceIPv4=true update" works for you [15:22] xyzluki: curl -v us.archive.ubuntu.com [15:22] (In a pastebin) [15:23] ping 2001:67c:1562::15 shows ping: connect: Network is unreachable [15:23] This really seems like a client network problem rather than something on our end, but if this assessment changes, just highlight me and I'll take another look. [15:24] sudo apt-get -o Acquire::ForceIPv4=true update exits with teh same error as normal sudo apt-get update [15:25] this really looks like a problem with your home network [15:26] but as we are talking already: is it recommended to enable https on the archive mirrors? i just never thought of it. just saw some that have it [15:28] I will check Berge idea: https://pastebin.com/EjvCMmNJ [15:29] curl also reports problem with connection refused error [15:29] xyzluki: try (and pastebin) tcptraceroute us.archive.ubuntu.com 80 [15:29] (you'll probably need to install it, though...) [15:30] ravage: It provides no benefit as the archive is known data, and it puts overhead in that would make certificates impossible to manage. And apt doesn't need it anyway as it checks actual signatures on payloads. [15:33] ehhh, even I am not able to manually download tcptraceroute package [15:33] ravage: there are different POVs on this topic, you will find lengthy discussions on debian mailing lists, i assume. [15:34] (and different arguments, too) [15:34] there must be an official position on it? i enabled it for my mirror as an option now. does not hurt [15:34] i assume Spads provided the official position [15:35] k [15:35] xyzluki: ok, the point there would just be to see if the "connection refused" was coming from somewhere unexpected. But with that 42089 ms, it's probably a timeout, so not useful [15:36] btw. I am trying to download tcptraceroute from https://packages.ubuntu.com/focal/amd64/tcptraceroute/download, but there I have a problem with access to servers [15:37] thank you guys for help. I assume that my ISP will find what is wrong, because I didn't change any settings on my pc [15:38] rebooting all your devices may help actually. give it a try. [15:40] ravage, I am fighting with apt-get from sunday. My pc was rebooted few times from that time [15:41] and your router? [15:41] at home I don't have router [15:41] my pc is connected directly to ISP device for which I don't have physical access [15:42] it is closed in the box on staircase [15:46] tomreyn: I don't know what degree of officialdom it has, but let's just say that we won't be handing out TLS certs for $COUNTRYCODE.archive.ubuntu.com so it's hard to see a benefit [15:46] I mean turn it on if you like, really. But we're unlikely to require it or provide infra to support it any time soon. [15:52] Spads: It is certainly challenging to both design and maintain an architecture which can handle all the issues around community maintained HTTPS mirrors properly. And there is the trust / false trust issue, too. I understand so much. I also think that it was a good choice by debian to move to https by default. [15:52] (and i think it would be a good chooice for ubuntu, too. but i'm just another user.) [16:00] I hope that my ISP will find why access to ubuntu servres doesn't work [16:00] At this moment thanks again for help and see you :) [16:01] good luck with your ISP :) [16:01] I hope so :)