When I run apt-get update on my machine it gets stuck at:

100% [Connecting to security.ubuntu.com (2001:67c:1562::15)] [Connecting to archive.canonical.com (2001:67c:1360:8c01::16)]

I have made no recent changes to the system and use my home network which worked fine previously.

I can't explain why it switched to using IPv6.
I have IPv6 set to ignore for the wireless network:

enter image description here

Ouput of ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: mlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 4c:0b:be:22:0a:b4 brd ff:ff:ff:ff:ff:ff
inet brd scope global dynamic mlan0
   valid_lft 1814086sec preferred_lft 1814086sec
inet6 ::d5:b551:28db:2789:225/64 scope global temporary dynamic 
   valid_lft 604483sec preferred_lft 85483sec
inet6 ::d5:4e0b:beff:fe22:ab4/64 scope global mngtmpaddr dynamic 
   valid_lft 604779sec preferred_lft 86379sec
inet6 fe80::4e0b:beff:fe22:ab4/64 scope link 
   valid_lft forever preferred_lft forever
  • Change the IP addressing to IPv4 and then try again.. – heemayl May 6 '15 at 22:33
  • Why are you using IPv6? Like heemayl said, change to using IPv4, under Network Settings>[Adapter]>Advanced. – TheWanderer May 6 '15 at 23:32
  • 1
    It looks as if you may have a host sending router advertisements with 0:0:0:d5::/64. This range is listed as reserved by IETF, so that is definitely not a valid prefix to be advertising. If those RAs have stopped already, it may be impossible to find out, where they came from. In that case all you can really do is to restart the network interface and the problem goes away. If the RAs are still being send, then you can look at a packet capture to see which MAC they are coming from. – kasperd May 7 '15 at 8:39
  • 1
    Other than the misconfigured IPv6 connectivity, another contributor to your problem is the lack of RFC 6555 support in apt-get. Had apt-get followed RFC 6555, you would never have noticed any problem. – kasperd May 7 '15 at 8:43
  • 1
    Your local router is doing something wrong, and giving you invalid IPv6 addresses. Check and fix the router's configuration. – Michael Hampton May 7 '15 at 19:40

This worked for me, courtesy of Zach Adams (https://zach-adams.com/2015/01/apt-get-cant-connect-to-security-ubuntu-fix/):

Turns out this is an issue where connecting over IPv6 on some servers causes them to get stuck at this point. The fix is really simple.

Open /etc/gai.conf

Under the line

# For sites which prefer IPv4 connections change the last line to

Uncomment the following line by removing the #:

# precedence ::ffff:0:0/96 100

This will allow you to still use IPv6 but sets IPv4 as the precedence so that apt-get won’t get stuck.

  • 21
    Thanks! This answer is much better than just slavishly disabling ipv6. – Cyrusmith Jun 17 '16 at 2:30
  • 2
    If you get no luck with this, try that: askubuntu.com/a/759540/4246 – Gauthier Oct 30 '16 at 21:24
  • 2
    OMG that helped so much! – GaTechThomas Jan 9 '17 at 5:29
  • 4
    Note: This is still valid on 14.04 and 16.04 LTS versions – Elder Geek Jul 22 '17 at 18:59
  • 2
    Worked for me on Linux Mint 18.1 & 18.2. This should be default. – mat Jul 24 '17 at 17:42

The IPv6 setting for the network were ignored, but disabling IPv6 via /etc/sysctl.conf worked:

Add the following lines at the bottom of /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Run sudo sysctl -p to reload the /etc/sysctl.conf settings.

  • 6
    That's not how you should be doing. Those lines means once you connect to a network, which actually has IPv6, you'll get a less reliable connection than you were supposed to. Also, those lines do nothing to fix the root cause of your problem, which you haven't even identified. – kasperd May 7 '15 at 8:33
  • 1
    I do not need IPv6 anywhere so this works just fine. – Pabi May 7 '15 at 8:42
  • 4
    That's just silly, because for connecting to hosts on the same network segment there are multiple advantages in IPv6 link-local addresses compared to IPv4. – kasperd May 7 '15 at 9:39
  • 2
    Can't do that from my phone ;) Lets just agree that we disagree. – Pabi May 7 '15 at 13:00
  • 4
    Do what you want to do. I just comment to ensure that anybody else who might come across the same problem knows that making the suggested changes to sysctl.conf is going to cause problems eventually. – kasperd May 7 '15 at 13:10

A better approach is to use apt-get as follows instead of editing gai.conf file.

sudo apt-get -o Acquire::ForceIPv4=true update

If you want to make this persistent just add an alias for 'apt-get' in your bash file.

  • But wouldn't this make connections that could be IPv6 all IPv4? – metame Feb 16 '17 at 20:35
  • @metame that's the whole point. OP said his IPv6 is disabled, and attempting to use it causes problems. – Francesco Dondi Apr 10 '17 at 7:22

Other solutions did not help ... in my case I created an aws ec2 instance Ubuntu 18.04 using

Auto-assign Public IP -> no pick disable

after trying all suggested solutions I threw up my hands and killed that and created a new ec2 instance using

Auto-assign Public IP -> yes  Use subnet setting (Enable) 

and it worked fine ... apt-get update && apt-get upgrade are happy now

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