can't connect to google api it seems.

It looks like the networking is fine – 405 Method Not Allowed is probably because that API endpoint isn't expecting a GET.

Whatever part of your application is handling /complete/google-oauth2/ is taking a really long time to return anything. It might be a good idea to throw some debugging into there to see where it's dying.

Actually, upon further review, it looks like your IPv6 might be munged – I missed the "Connection timed out".

Post the output of:

ip -6 addr
ip -6 route
ip6tables -L -n -v

Thanks a lot hoopycat.

I didn't see that you asked me to post the output. I was thinking about it but didnt know if the info there is confidential. I guess if you asked

then its not sensitive.

There;s the output:

[root@li428-212 app01]# ip -6 addr        
1: lo: <loopback,up,lower_up> mtu 65536 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
3: eth0: <broadcast,multicast,up,lower_up> mtu 1500 qlen 1000
    inet6 2600:3c00::9169:4517:8d82:2ef2/64 scope global noprefixroute dynamic 
       valid_lft 2591975sec preferred_lft 604775sec
    inet6 2600:3c00::f03c:91ff:fe73:7860/64 scope global mngtmpaddr dynamic 
       valid_lft 2590924sec preferred_lft 603724sec
    inet6 fe80::f03c:91ff:fe73:7860/64 scope link 
       valid_lft forever preferred_lft forever</broadcast,multicast,up,lower_up></loopback,up,lower_up>

[root@li428-212 app01]# ip -6 route
2600:3c00::/64 dev eth0  proto kernel  metric 203  mtu 1500
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::1 dev eth0  metric 203  mtu 1500

[root@li428-212 app01]# ip6tables -L -n -v
Chain INPUT (policy ACCEPT 571 packets, 245K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 622 packets, 248K bytes)
 pkts bytes target     prot opt in     out     source               destination         

You'll want to review the google api docs:

https://developers.google.com/accounts/ … mingtheurl">https://developers.google.com/accounts/docs/OAuth2WebServer#formingtheurl

I'm pretty sure you need to pass the required params to /auth, and /token is supposed to be POST not GET.

Hmm, I can't ping either 2600:3c00::9169:4517:8d82:2ef2 nor 2600:3c00::f03c:91ff:fe73:7860 from here. I've also never seen the "noprefixroute" and "mngtmpaddr" flags before. (Which Linux distribution are you running?)

I suspect your system is trying to originate traffic as 2600:3c00::9169:4517:8d82:2ef2, which is likely not an IP address which Linode has allocated to you… it should just be using the 2600:3c00::f03c:91ff:fe73:7860 address (the ..ff:fe.. in the middle of it indicates that it is auto-configured). I wonder if there's some sort of network management daemon running which is trying to be too clever.

Another thing to try:

cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr

That should return '0'. If it returns '1' or '2', try:

echo 0 > /proc/sys/net/ipv6/conf/eth0/use_tempaddr

… and reply back. (The output of 'uname -a' might be interesting in this case.)

It returned 0.

I'm running Arch Linux.

[root@li428-212 app01]# cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr
0
[root@li428-212 app01]# uname -a
Linux li428-212.members.linode.com 3.15.4-x86_64-linode45 #1 SMP Mon Jul 7 08:42:36 EDT 2014 x86_64 GNU/Linux

I'm running arch at my house too, and it works no problems.

By it I mean the app that initiates the oauth communication and also the wget in the sense that there's no timeout error, only the bad method error.

Oh I forgot, I turned off the server yerterday, that is why you couldnt ping those ip addresses.

Also, I;m starting my network using this:

dhcpcd eht0

Maybe I should use this instead:

https://wiki.archlinux.org/index.php/Systemd-networkd

So this is weird… I deployed a fresh Arch install in Dallas, updated it, rebooted it, etc.

I ping a known good host and it fails:

[root@li581-100 ~]# ping6 rocwiki.org
PING rocwiki.org(rocwiki.org) 56 data bytes
^C
--- rocwiki.org ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2007ms

I do an mtr, which works fine.

Then I ping it again, and it works:

[root@li581-100 ~]# ping6 rocwiki.org
PING rocwiki.org(rocwiki.org) 56 data bytes
64 bytes from rocwiki.org: icmp_seq=1 ttl=52 time=40.9 ms
64 bytes from rocwiki.org: icmp_seq=2 ttl=52 time=41.1 ms
64 bytes from rocwiki.org: icmp_seq=3 ttl=52 time=40.9 ms
64 bytes from rocwiki.org: icmp_seq=4 ttl=52 time=41.0 ms
64 bytes from rocwiki.org: icmp_seq=5 ttl=52 time=41.6 ms
^C
--- rocwiki.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 40.973/41.165/41.695/0.325 ms

Upon reboot, IPv4 failed to come up, but IPv6 works fine. I'm inclined to blame systemd :-)

Going out on a limb here, try 'mtr accounts.google.com' and see if that goes through.

````
[root@localhost ~]# tail /var/log/syslog
tail: cannot open ‘/var/log/syslog’ for reading: No such file or directory
[root@localhost ~]# tail /var/log/messages
tail: cannot open ‘/var/log/messages’ for reading: No such file or directory

````

~~http://zippy.gfycat.com/IcyCompetentHare.gif" />

I usually stick to the Debian side of the world, so this is well outside my expertise. Hopefully someone knows Arch Linux better than myself. Good luck!~~

Do you think I can post the output of the command you asked for to stack overflow and so on without much risk?

This is related to behavior introduced in dhcpcd 6.4.0 which now generates stable private IPv6 addresses when using stateless address autoconfiguration (SLAAC).

The solution that worked for me (also running Arch Linux on a Linode) was to edit /etc/dhcpcd.conf and comment out the line "slaac private":

# Generate Stable Private IPv6 Addresses instead of hardware based ones         
#slaac private

This is also discussed in this Gentoo bug report: https://bugs.gentoo.org/show_bug.cgi?id=514198