problems with Google using DL-624 router

[jgengler]

Hi!

I have used Ubuntu, Debian and Mandriva distros and I now stick to Ubuntu 8.10 for a long time. I have a very, very strange problem.

I have a DL-624S (D-Link) router.

If I try Google and I use any Linux OS, the page doesn't open (server says the page doesn't exist). Ping Google also doesn't show any packages. I can use all the rest of the Internet without any difficulty.

In same conditions, the problem doesn't happen at all using any Windows OS. I can freely use Google and Gmail.

Obviously, I dissabled all the firewalls and parental control, both local machine software and router. I also tryed to use Demilitarized zone and I can't use Google with Linux OS at all.

If I connect one Linux OS machine directly to the Internet Modem (not using the router), Firefox shows Google correctly.

Please help with any suggestions.

Thanks a lot for any help,

Joe

[coopstah13]

what is the content of these files when you are connected through the router?

cat /etc/resolv.conf
cat /etc/hosts

[jgengler]

cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.0.1


cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 jose-laptop

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

[coopstah13]

seems right, what happens when you execute

dig www.google.com

[jgengler]

dig Google

;; Truncated, retrying in TCP mode.

; <<>> DiG 9.5.0-P2 <<>> Google
;; global options: printcmd
;; connection timed out; no servers could be reached

[coopstah13]

but if you run that using some other site it works??? You should get something like this

ccooper@usxxcoopec3l1c:~/p4/pcc/tools/appliance$ dig www.google.com

; <<>> DiG 9.5.1-P2 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6757
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
www.google.com.		86366	IN	CNAME	www.l.google.com.
www.l.google.com.	120	IN	A	64.233.161.104
www.l.google.com.	120	IN	A	64.233.161.147

;; Query time: 1 msec
;; SERVER: 10.100.8.204#53(10.100.8.204)
;; WHEN: Mon Jul 13 12:24:28 2009
;; MSG SIZE  rcvd: 84

I don't see what could possibly cause this, since you said it works on windows, and the rest of the net works. The files you have are correct.

[jgengler]

yes, it works nicely with any other site...

dig Linux forums - linux articles forums downloads

; <<>> DiG 9.5.0-P2 <<>> Linux forums - linux articles forums downloads
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28374
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;Linux forums - linux articles forums downloads. IN A

;; ANSWER SECTION:
Linux forums - linux articles forums downloads. 96 IN CNAME linuxforums.org.
linuxforums.org. 96 IN A 174.132.123.98

;; AUTHORITY SECTION:
linuxforums.org. 96 IN NS ns2.linuxforums.org.
linuxforums.org. 96 IN NS ns1.linuxforums.org.

;; Query time: 18 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Mon Jul 13 16:46:46 2009
;; MSG SIZE rcvd: 103

[jgengler]

I found an interesting article regarding this subject:

It leaves me with the following questions:

Can package sizes be setup in Linux (in the case of the article, UDP))? How? What size should they have?

Now I quote the article:

Here's an interesting puzzle involving DNS.

It's about Windows, Linux, and OS X, and I don't have a complete answer yet, but I thought I'd share what I've found so far.

The other day I was working on my Mac and wanted to access my.calendars.net. I couldn't, and my browser told me that "Firefox can't find the server at my.calendars.net". I assumed the site was down, but later in the day I happened to be working at my wife's computer for a few minutes, and while I was there I tried again and the site worked. OK, so it happened to be down when I tried it earlier..

Well no. Back at my Mac, Firefox still said it was down. Time to drop to the command line:

$ dig my.calendars.net
;; Truncated, retrying in TCP mode.
;; Connection to 192.168.2.1#53(192.168.2.1) for my.calendars.net failed: connection refused.

Hmmm.. that's the Verizon router, but my wife's machine uses the same thing, so it's not at fault. Or is it? Let's try something different. dig will let you specify a server to use. I gave it something I know is in Boston:

$ dig @192.74.137.5 my.calendars.net
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.4 <<>> @192.74.137.5 my.calendars.net
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1020
;; flags: qr rd ra; QUERY: 1, ANSWER: 37, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;my.calendars.net. IN A

;; ANSWER SECTION:
my.calendars.net. 5239 IN A 207.202.158.15
my.calendars.net. 5239 IN A 207.202.158.16
.. (and so on)

That tells me that this machine indeed can resolve the address; it just doesn't like something about the Verizon router. Let's try something else:

$ dig +ignore my.calendars.net

; <<>> DiG 9.3.4 <<>> +ignore my.calendars.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25360
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 29, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;my.calendars.net. IN A

;; ANSWER SECTION:
my.calendars.net. 4269 IN A 207.202.158.121
my.calendars.net. 4269 IN A 207.202.158.15
.. (and so on)

That "+ignore" tells dig to (from the man page) "Ignore truncation in UDP responses instead of retrying with TCP". If you look carefully, you'll notice that when I used the server in Boston, I got 37 addresses back, but with "+ignore", I only got 29. Is that the "truncation"? Looking at the "MSG SIZE rcvd" section, the Boston server has ";; MSG SIZE rcvd: 691", while the "+ignore" dig has ";; MSG SIZE rcvd: 498", making me very certain that there's a 512 byte packet involved.

Let's try Linux. I have a Linux server on the network, and several Linux machines inside Parallels. I tried all of them: they fail exactly as the Mac does..

Back to dig on the Mac again. You can tell dig not to use tcp with "dig +tcp". I tried that with a name dig could resolve, and the router refused me. Apparently this router doesn't want to give any tcp DNS replies.. I looked into that, but couldn't find any setting I could change. It did let me download a text config file, which told me that this router is actually an Actiontec model MI424WR, but I don't entirely understand the config file.. looks like it only accepts udp:

(name(DNS ALG))
(old_id(16777235))
(advanced(1))
(description(UDP Domain Name Server))
(alg(dns))
(trigger
(0
(protocol(17))
(dst
(start(53))
(end(53))
)
)
)
)

What do we know so far? The answer from UDP (the default) is larger than will fit in the UDP packet. My Verizon router apparently doesn't want to use TCP for DNS. Windows works.. does Windows use a different size? Let's try to find out..

My wife's machine wasn't available, but I have Windows XP running under Parallels, so I alt-tabbed over to that. Just to be compulsive, I tried it in a browser first - it works.

OK, so let's see what's really going on. In a command prompt, I ran "nslookup" and asked it to resolve my.calendars.net - it could not, though it took a long time trying. I did "set debug" and was able to observe that it tried twice, and got truncated answers both times. That's interesting: apparently "nslookup" doesn't use whatever dlls the rest of Windows uses.

That's as far as I've been able to get so far. It looks like Windows might use a different udp packet size (though not for nslookup). I found "dig" for Windows, but couldn't get it to work.. so I need better Windows tools to find out more..

*Originally published at APLawrence.com
About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services Unix, Linux, Mac OS X Help, Tutorials and support pages