can't connect to google api it seems.


I'm running python-social-auth to get the oauth2 functionality in my app.

When I try to login using google, I get redirected (after i filled in the form) here:

> /complete/google-oauth2/

And then the connection times out.

> 504 Gateway Time-out

That;s from the error log:

> 2014/07/10 19:21:44 [error] 15072#0: *293 upstream timed out (110: Connection timed out) while reading response header from upstream, client:..

That's from the access log:

> - - [10/Jul/2014:19:20:44 +0000] "GET /login/google-oauth2/ HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Linux; Android … - - [10/Jul/2014:19:21:44 +0000] "GET /complete/google-oauth2/?state=xxxxxxxxxxxxxxxx&code=xxxxxxxxxxxxxxxxxxxxxxxxxxx HTTP/1.1" 504 596 "-" "Mozilla/5.0 (Linux; Android … - - [10/Jul/2014:19:21:44 +0000] "GET /favicon.ico HTTP/1.1" 404 4541 "-" "Mozilla/5.0 (Linux; Android …

I tried to see if the server can connect to google's api. I thnk it can't:

    --2014-07-10 15:20:59--
    Resolving ( xxxx:xxxx:xxxx:xxx::xx,
    Connecting to (|xxxx:xxxx:xxxx:xxx::xx|:xxx... failed: Connection timed out.
    Connecting to (||:xxx... connected.
    HTTP request sent, awaiting response... 405 Method Not Allowed
    2014-07-10 15:23:06 ERROR 405: Method Not Allowed.

I'm not sure what this means exactly. But I;m guessing that my network isnt allowing me to call that url.

The time on my server was first the default, and then i switched it to the one you see there which is the one in my home.

If the network isn't allowing me to connec to Google API, how can i make it allow me to do it? If that;s not the problem, then what might the problem be?

If anyone could help, that would be great.

Thanks in advance.


11 Replies

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: … mingtheurl">

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
[root@li428-212 app01]# uname -a
Linux 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:

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
PING 56 data bytes
--- 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
PING 56 data bytes
64 bytes from icmp_seq=1 ttl=52 time=40.9 ms
64 bytes from icmp_seq=2 ttl=52 time=41.1 ms
64 bytes from icmp_seq=3 ttl=52 time=40.9 ms
64 bytes from icmp_seq=4 ttl=52 time=41.0 ms
64 bytes from icmp_seq=5 ttl=52 time=41.6 ms
--- 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' 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


~~![](<URL url=)" />

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:


Please enter an answer

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct