After a few hours I can't browse google sites

[npc]

Hey there, folks.
The most frustrating thing is happening here at home. After the last update, both my x86 and amd64 pcs are running into the same problem. After a couple of hours of browsing, sometimes a bit more, any google page and only google pages aren't reachable. Firefox, elinks, wget, anything just hangs there for a few minutes before timing out. I have tried to restart most of services, including all of them related to networking, but nothing seems to fix it. Restarting my router, the isp modem, changing DNS providers, restarting xorg, relogging to my user, nothing works. I'm getting a bit desperate here and i lot frustrated, because the only thing that works is rebooting, but after another couple of hours I face the same problem all over again. Does anyone around here have faced anything like this? Googling (when possible) didn't help much.

Thanks.

[darkphader]

Compare the output of something like

Code: Select all

dig google.com

when it's working to when it's not working, to see if it's a DNS issue.

[npc]

It doesn't seem to be DNS related, I ran dig before and after the problem showed up:

Code: Select all

BEFORE

dig google.com;dig +nocmd google.com any +multiline +noall +answer

; <<>> DiG 9.7.1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.            IN    A

;; ANSWER SECTION:
google.com.        93    IN    A    72.14.253.104

;; Query time: 48 msec
;; SERVER: 200.204.0.10#53(200.204.0.10)
;; WHEN: Thu Nov  4 09:57:46 2010
;; MSG SIZE  rcvd: 44

google.com.        90 IN A    72.14.253.104
google.com.        115147 IN NS ns1.google.com.
google.com.        115147 IN NS ns2.google.com.
google.com.        115147 IN NS ns4.google.com.
google.com.        115147 IN NS ns3.google.com.
google.com.        465 IN MX 300 google.com.s9b1.psmtp.com.
google.com.        465 IN MX 200 google.com.s9a2.psmtp.com.
google.com.        465 IN MX 400 google.com.s9b2.psmtp.com.
google.com.        465 IN MX 100 google.com.s9a1.psmtp.com.

AFTER

dig google.com;dig +nocmd google.com any +multiline +noall +answer

; <<>> DiG 9.7.1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50521
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.            IN    A

;; ANSWER SECTION:
google.com.        247    IN    A    72.14.253.104

;; Query time: 64 msec
;; SERVER: 200.204.0.10#53(200.204.0.10)
;; WHEN: Thu Nov  4 14:43:48 2010
;; MSG SIZE  rcvd: 44

google.com.        271 IN A 72.14.253.104
google.com.        95764 IN NS ns4.google.com.
google.com.        95764 IN NS ns1.google.com.
google.com.        95764 IN NS ns3.google.com.
google.com.        95764 IN NS ns2.google.com.
google.com.        579 IN MX 200 google.com.s9a2.psmtp.com.
google.com.        579 IN MX 100 google.com.s9a1.psmtp.com.
google.com.        579 IN MX 300 google.com.s9b1.psmtp.com.
google.com.        579 IN MX 400 google.com.s9b2.psmtp.com.

Any suggestions? I'm really lost here.

[darkphader]

Really, no clue, very strange looking problem. Are you funneling (or being funneled) through a proxy? If you take your system somewhere else, using a different ISP do you experience the same issue?

[npc]

No tunneling, no proxy, just good ol' generic-brand router that used to work quite okay until a couple of weeks ago. I just found out that tinyurl.com is also broken.

I'll take my netbook to some other neighborhood and try to connect to these faulty addresses and report back. Indeed it's odd, i couldn't manage yet to figure out where lies the problem.

Thanks again.

[marens]

use net-analyzer/wireshark to analyze what's going on

[npc]

After weeks of hacking around in desperation I guess i solved it. I did set my router to assign static IP binded to my laptop wifi MAC address a few months ago. For some reason the router only allows such an action providing hosts with a permanent lease time. I believe my dhcp client did not agree with that, and after a couple of hours it would try to renew my IP but could't, thus jamming everything. I solved it by setting the router back to default dynamic ip stuff and 120 min lease time. No hangs in the last 2 days.

Thanks a lot guys.

[rainer]

I'm experiencing exactly the same problem in my home network. Google, and only Google, refuses to communicate after some hours, for all Linux machines in the network. Reboot, and only reboot, helps.

I'd like to copy your solution but I'm not sure if I understand.

I have a dnsmasq server between the router and the machines in the network. All regular clients are identified by their MAC and get their IP address from the dnsmasq server with lease times of 7 days. Are you suggesting that reducing that lease time to 120 min would solve the problem - or better, that it did in your case? Or am I missing something?

Thanks very much, getting rid of this extremely annoying hiccup would be great!
Rainer

[darkphader]

I'm experiencing exactly the same problem in my home network. Google, and only Google, refuses to communicate after some hours, for all Linux machines in the network. Reboot, and only reboot, helps.

Very strange stuff. Would be interested in seeing the output of (replace eth0 with your interface if different):

Code: Select all

ip addr show eth0

or if not using iproute2:

Code: Select all

ifconfig eth0

plus:

Code: Select all

cat /etc/resolv.conf

for before and after the Google problem.

Also the the log entries for dhcpcd (if that's what you're using as the dhcp client), if any, around the time frame of the change:

Code: Select all

grep 'dhcpcd' /var/log/daemon.log

works here to obtain that info.

[darkphader]

Just to add that many home routers run dnsmasq and that may the common denominator in both cases.
On the networks I administer as well as here on my server I run a combination of dhcpd, nsd, and unbound. Might be a little more setup involved but it's very flexible, stable, and works well.

EDIT: Would be interested in the result of editing /etc/resolv.conf when the problem occurs so that:

Code: Select all

nameserver 8.8.8.8
nameserver 8.8.4.4

replaces any current nameserver entries. These are Google's Public DNS servers. Of course you wont get local DNS resolution but if Google sites start working then it implicates dnsmasq's DNS cache/resolver as the culprit. If so and you're running stable net-dns/dnsmasq-2.52 you might try installing ~ net-dns/dnsmasq-2.55 instead (or the reverse).

[rainer]

Before:

Code: Select all

ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:90:f5:58:04:71 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.217/24 brd 192.168.1.255 scope global eth0
    inet6 fe80::290:f5ff:fe58:471/64 scope link 
       valid_lft forever preferred_lft forever

Code: Select all

# Generated by resolvconf
nameserver 192.168.1.2

The nameserver (and dhcp server) is my dnsmasq box. As one can see, I let netmanager do the configuration...
I'd like to show the "after" as well, but as it is so often the case, now that I'm waiting for it, Google connects flawlessly; will edit th post once I get the issue again!

I run dhclient - here the info:

Code: Select all

augeatur rainer # dhclient
Internet Systems Consortium DHCP Client V3.1.2p1-Gentoo
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/wlan0/00:18:de:d1:25:00
Sending on   LPF/wlan0/00:18:de:d1:25:00
Listening on LPF/eth0/00:90:f5:58:04:71
Sending on   LPF/eth0/00:90:f5:58:04:71
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPOFFER from 192.168.1.2
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.2
bound to 192.168.1.217 -- renewal in 276539 seconds.

Maybe that gives some hints already,
Rainer


EDIT:

This is my /etc/conf.d/net:

Code: Select all

config_eth0=( "192.168.1.2 netmask 255.255.255.0 brd 192.168.1.255" )
routes_eth0=( "default via 192.168.1.1" )
dns_servers_eth0=( "208.67.222.222" "208.67.220.220" )

...so that dnsmasq gets its name resolution from OpenDNS and then serves as the local nameserver.

[darkphader]

I found this tidbit at https://wiki.archlinux.org/index.php/Dnsmasq:
To prevent OpenDNS from redirecting all Google queries to their own search server, add to /etc/dnsmasq.conf:

Code: Select all

server=/www.google.com/X.X.X.X

Replace X.X.X.X with your ISP's DNS server/Router IP.

Although I would recommend using Google's Public DNS servers (8.8.8.8, 8.8.4.4) instead of your ISP's.
I actually do a similar thing with Unbound at the accounts where we use OpenDNS as I don't like OpenDNS's hijacking of Google domain queries, although I never had a problem with allowing it previously.

To me dnsmasq seems overly complicated and somewhat hackish compared to more robust products (dhcpd, nsd, unbound).

[rainer]

Thanks - I had no idea about OpenDNS 'hijacking!

Reason enough to stop using them with immediate effect - set my name server to 8.8.8.8 and 8.8.4.4 and will report if the problem continues.

As to dnsmasq - I have a running configuration that works very well for me, so I'll probably not touch it at this time. But I'll keep your comment in mind for the moment I have to make some major changes.

Thanks again,
Rainer

[darkphader]

Thanks - I had no idea about OpenDNS 'hijacking!

At several accounts we use OpenDNS's filtering (you need to sign up to use this feature) to prevent some nastiness. But for some domains I override their redirects.

Also I looked at some dnsmasq info and it appears proper configuration of the dnsmasq server would have resolv.conf like this:
/etc/resolv.conf

Code: Select all

nameserver=127.0.0.1

and specify the upstream servers directly to dnsmasq using --server options or put their addresses in another file, say /etc/resolv.dnsmasq and run dnsmasq with the -r /etc/resolv.dnsmasq option.

Or simpler, just have:
/etc/resolv.conf

Code: Select all

nameserver=127.0.0.1
nameserver=8.8.8.8
nameserver=8.8.4.4

where dnsmasq ignores the first name server line to find the upstream servers.
Without nameserver=127.0.0.1 in /etc/resolv.conf the actual server that dnsmasq is running on does not get the benefit of using its cache and being able to resolve local names and addresses.

Also, instead of the line in:
/etc/conf.d/net

Code: Select all

dns_servers_eth0=( "208.67.222.222" "208.67.220.220" )

You may be better served by a prepend statement in /etc/dhclient.conf

Code: Select all

prepend domain-name-servers 127.0.0.1;

Again I've never used dnsmasq before and I don't know your entire configuration, but I know I would want my server, as all of my other local systems, to resolve local DNS data from my local cache.

Chris

[rainer]

Again I've never used dnsmasq before and I don't know your entire configuration, but I know I would want my server, as all of my other local systems, to resolve local DNS data from my local cache.

I think that's what I'm doing: The machines in the network use dhclient (most of them - some use dhcpcd, there is the odd Windows or Apple machine from time to time around), and they all get, via dhcp, 192.168.1.2 as their nameserver - which is the dnsmasq machine. dnsmasq is configured as a caching nameserver for the local net, as you suggest, but it needs to get the DNS info in the first place, that is what I used OpenDNS (now Google) for.

At the same time, it works as the dhcp server which puts me in the position to maintain the host names in my LAN centrally with one program - a feature I really appreciate.

I actually forgot why I put the nameserver configuration into /etc/conf.d/net rather than straight into /etc/resolv.conf - there was a reason but maybe I should have another look!

Thanks anyway, so far, Google responds promptly even after hours of continuous operation - haven't had that for quite some time...

Rgds,
Rainer

[rainer]

Success was only perceived - definitely, Google cuts of after some hours, at least for all Linux machines in the house.

:The machine I'm sitting on I left running over night (last Google access yesterday around 22:30) and now (local time 07:30) Fire fox (and Konqueror and Opera) just stay at "Connecting to www.google.com", timeout after the usual period.

Most annoying! I can live without Facebook and Twitter, but a life without Google is impossible...

I have tried deleting all cookies but that doesn't help.

Any ideas out there?

[npc]

I'm still facing this oddity too. It seems it takes a few more hours to get buggy, but it does at some point. Another thing I've noticed is that ping works, but http related stuff won't. My download and upload rates reach a bare minimum and loading pages just timesout or gets corrupted. Only rebooting solves the problem. I'm starting to consider it's a kernel issue. I thought for a brief period that wicd would be the guilty part, but it seems you guys aren't using it.
Damn, it's annoying.