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:
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:
> xxx.xxx.xxx.xxx - - [10/Jul/2014:19:20:44 +0000] "GET /login/google-oauth2/ HTTP/1.1" 302 5 "-" "Mozilla/5.0 (Linux; Android …
xxx.xxx.xxx.xxx - - [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 …
xxx.xxx.xxx.xxx - - [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:
wget https://accounts.google.com/o/oauth2/token --2014-07-10 15:20:59-- https://accounts.google.com/o/oauth2/token Resolving accounts.google.com (accounts.google.com)... xxxx:xxxx:xxxx:xxx::xx, xx.xxx.xxx.xx Connecting to accounts.google.com (accounts.google.com)|xxxx:xxxx:xxxx:xxx::xx|:xxx... failed: Connection timed out. Connecting to accounts.google.com (accounts.google.com)|xx.xxx.xxx.xx|: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.
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.
Post the output of:
ip -6 addr ip -6 route ip6tables -L -n -v
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
I'm pretty sure you need to pass the required params to /auth, and /token is supposed to be POST not GET.
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:
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.)
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.
Also, I;m starting my network using this:
Maybe I should use this instead:
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
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!~~
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: