LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 06-13-2008, 05:15 PM   #1
kbighorse
LQ Newbie
 
Registered: Jun 2008
Posts: 20

Rep: Reputation: 0
nslookup: connection timed out; no servers could be reached


I have 2 servers:

xmail1 192.168.1.21
xmail2 192.168.1.22

THE PROBLEM:

[root@xmail1 ~]# nslookup 64.81.79.2
;; connection timed out; no servers could be reached

[root@xmail2 ~]# nslookup 64.81.79.2
Server: 64.81.79.2
Address: 64.81.79.2#53

Non-authoritative answer:
2.79.81.64.in-addr.arpa name = dns.sfo1.speakeasy.net.

Authoritative answers can be found from:


Logging in and sendmail are slow as a result. I can ssh and ping to local machines from xmail1, and sendmail successfully sends slowly, but it's really gummed up because of the DNS issue here.

Here are a few configs I've tried for xmail1 that have failed and xmail2's which works:

[root@xmail1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:30:48:59:A1:F8
IPADDR=192.168.1.21
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
GATEWAY=192.168.1.1
IPV6INIT=no

[root@xmail1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:30:48:59:a1:f8
IPADDR=192.168.1.21
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
GATEWAY=192.168.1.1
TYPE=Ethernet

[root@xmail1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:30:48:59:a1:f8
IPADDR=192.168.1.21
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
GATEWAY=192.168.1.1
TYPE=Ethernet
PEERDNS=no

[root@xmail2 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.1.255
HWADDR=00:12:3F:ED:08:5A
IPADDR=192.168.1.22
NETMASK=255.255.255.0
NETWORK=192.168.1.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
GATEWAY=192.168.1.1
IPV6INIT=no

RESOLV.CONF:

[root@xmail1 ~]# cat /etc/resolv.conf
search glocap.com
nameserver 64.81.79.2
nameserver 216.231.41.2

[root@xmail2 ~]# cat /etc/resolv.conf
search glocap.com
#nameserver 192.168.1.20
nameserver 64.81.79.2 #speakeasy
nameserver 216.231.41.2 #speakeasy
# nameserver 209.17.66.100
# nameserver 209.17.66.79

ROUTE:

[root@xmail1 ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

[root@xmail2 ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
169.254.0.0 * 255.255.0.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Note: the last line (gateway) of xmail1's 'route' command loads very slowly, I think it might be related.

Thanks so much for any response!

Kimball
 
Old 06-13-2008, 06:36 PM   #2
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
It sounds as though xmail1 cannot reach any DNS server in its list. Since xmail2 can, and it appears to be on the same subnet, is there a restriction on the firewall that is allowing DNS traffic (UDP port 53) only to xmail2?

To verify this, can xmail1 ping any machine off the local net (using address, not DNS name)? If not, there may be a blanket prohibition on its address, and/or the firewall (router) may not be doing NAT for it. If ping reports a reply, then you almost certainly have a DNS issue.

(BTW, if you ask xmail1 to report its route table via
Code:
route -n
it should not take a long time to report back. I am speculating that the delay is an attempt by the route command to do the inverse lookup of the IP addresses.)
 
Old 06-13-2008, 10:26 PM   #3
jpbarto
Senior Member
 
Registered: Mar 2003
Location: Pittsburgh, PA
Distribution: Gentoo / NetBSD
Posts: 1,251

Rep: Reputation: 45
easy way to check if its a firewall issue would be to as root from the command line issue:

# iptables -F

this will clear your firewall rules (they'll be restored on reboot) and if your network works as expected then you know its a firewall issue.
 
Old 06-13-2008, 10:33 PM   #4
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
... presuming, of course, that the firewall is actually a un*x box. It might be a router/firewall, in which case, this won't work.
 
Old 06-16-2008, 02:40 PM   #5
kbighorse
LQ Newbie
 
Registered: Jun 2008
Posts: 20

Original Poster
Rep: Reputation: 0
Trying to ping www.google.com by IP address:

[root@xmail1 ~]# ping 74.125.19.104
PING 74.125.19.104 (74.125.19.104) 56(84) bytes of data.
<hangs>

route -n did indeed return immediately, thank you!
 
Old 06-16-2008, 02:43 PM   #6
kbighorse
LQ Newbie
 
Registered: Jun 2008
Posts: 20

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by dkm999 View Post
It sounds as though xmail1 cannot reach any DNS server in its list. Since xmail2 can, and it appears to be on the same subnet, is there a restriction on the firewall that is allowing DNS traffic (UDP port 53) only to xmail2?

To verify this, can xmail1 ping any machine off the local net (using address, not DNS name)? If not, there may be a blanket prohibition on its address, and/or the firewall (router) may not be doing NAT for it. If ping reports a reply, then you almost certainly have a DNS issue.

(BTW, if you ask xmail1 to report its route table via
Code:
route -n
it should not take a long time to report back. I am speculating that the delay is an attempt by the route command to do the inverse lookup of the IP addresses.)
How do I verify/address the 'blanket prohibition' and 'not doing NAT' possibilities, respectively? I'm pretty sure my firewall setup doesn't distinguish by machine, I have at least 7 boxes on the subnet working and 2 that are not, including 3 email relays with the same firewall rules as xmail1. thank you so much for your help!
 
Old 06-16-2008, 03:18 PM   #7
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
If you have separate firewall rules on each machine and no firewall-type device between your local net and the Internet, then check on the machines that do not work, like this:

List the INPUT chain on a non-working machine
Code:
iptables -nvL INPUT
This will give you a list of all the rules that are applied (in order) to an arriving packet. Review this list to see if UDP packets with this machine's IP address and source-port 53 and dest-port 53 or 1024-65535 will be accepted, and revise as necessary.

List the OUTPUT chain similarly, and verify that UDP packets with this machine's IP address and source-port 53 and dest-port 1024-65535 are permitted.

These rules should allow DNS traffic through a single machine's firewall. If you have a common machine between the Internet and the non-working machines, you also need to check that its FORWARD chain will allow the UDP packets to transit that box.

The reason for the asymmetry between INPUT and OUTPUT is that (I assume) your box is running a recent version of BIND, which uses non-privileged (high-numbered) source ports; older DNS implementation still can use source-port 53 in their messages, so you will need to accept them, too.
 
Old 06-16-2008, 03:37 PM   #8
kbighorse
LQ Newbie
 
Registered: Jun 2008
Posts: 20

Original Poster
Rep: Reputation: 0
From my firewall machine, between the subnet and the Internet:

[root@trusty ~]# iptables -nvL INPUT
Chain INPUT (policy DROP 135K packets, 7287K bytes)
pkts bytes target prot opt in out source destination
298K 24M FIREWALL all -- * * 0.0.0.0/0 0.0.0.0/0
[root@trusty ~]# iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 210K packets, 28M bytes)
pkts bytes target prot opt in out source destination
[root@trusty ~]# iptables -nvL FORWARD
Chain FORWARD (policy DROP 36736 packets, 5764K bytes)
pkts bytes target prot opt in out source destination
201M 78G FIREWALL all -- * * 0.0.0.0/0 0.0.0.0/0

[root@xmail1 ~]# iptables -nvL INPUT
Chain INPUT (policy ACCEPT 255 packets, 19819 bytes)
pkts bytes target prot opt in out source destination
[root@xmail1 ~]# iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 5406 packets, 519K bytes)
pkts bytes target prot opt in out source destination
[root@xmail1 ~]# iptables -nvL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

[root@xmail2 ~]# iptables -nvL INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
[root@xmail2 ~]# iptables -nvL OUTPUT
Chain OUTPUT (policy ACCEPT 17 packets, 1876 bytes)
pkts bytes target prot opt in out source destination
[root@xmail2 ~]# iptables -nvL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
 
Old 06-16-2008, 04:06 PM   #9
kbighorse
LQ Newbie
 
Registered: Jun 2008
Posts: 20

Original Poster
Rep: Reputation: 0
I'm investigating these lines I found in /var/log/messages from a few days ago:

Jun 12 20:11:16 xmail1 system-config-network[2108]: mkdir ///etc/cipe
Jun 12 20:11:16 xmail1 system-config-network[2108]: ln //etc/sysconfig/network-scripts//ifcfg-eth0 //etc/sysconfig/networking/devices//ifcfg-eth0
Jun 12 20:11:16 xmail1 system-config-network[2108]: Linking eth0 to devices and putting it in profile default.
Jun 12 20:11:16 xmail1 system-config-network[2108]: ln //etc/sysconfig/networking/devices//ifcfg-eth0 //etc/sysconfig/networking/profiles//default/ifcfg-eth0
Jun 12 20:11:17 xmail1 system-config-network[2108]: ln //etc/sysconfig/network-scripts//ifcfg-eth1 //etc/sysconfig/networking/devices//ifcfg-eth1
Jun 12 20:11:17 xmail1 system-config-network[2108]: Linking eth1 to devices and putting it in profile default.
Jun 12 20:11:17 xmail1 system-config-network[2108]: ln //etc/sysconfig/networking/devices//ifcfg-eth1 //etc/sysconfig/networking/profiles//default/ifcfg-eth1
Jun 12 20:11:17 xmail1 system-config-network[2108]: ln //etc/hosts //etc/sysconfig/networking/profiles//default/hosts
Jun 12 20:11:17 xmail1 system-config-network[2108]: ln //etc/resolv.conf //etc/sysconfig/networking/profiles//default/resolv.conf
Jun 12 20:11:57 xmail1 system-config-network[2108]: chmod 0644 //etc/sysconfig/networking/devices/ifcfg-eth0
Jun 12 20:11:57 xmail1 system-config-network[2108]: chmod 0644 //etc/sysconfig/networking/devices/ifcfg-eth1
Jun 12 20:14:02 xmail1 shutdown[2235]: shutting down for system reboot
Jun 12 20:14:02 xmail1 init: Switching to runlevel: 6
Jun 12 20:14:03 xmail1 restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Invalid argument
Jun 12 20:14:03 xmail1 avahi-daemon[2028]: Got SIGTERM, quitting.
Jun 12 20:14:03 xmail1 avahi-daemon[2028]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.

...

Jun 13 16:59:55 xmail1 avahi-daemon[1979]: Withdrawing address record for 192.168.1.21 on eth0.
Jun 13 16:59:55 xmail1 avahi-daemon[1979]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 16:59:55 xmail1 avahi-daemon[1979]: Interface eth0.IPv4 no longer relevant for mDNS.
Jun 13 16:59:55 xmail1 avahi-daemon[1979]: Withdrawing address record for fe80::230:48ff:fe59:a1f8 on eth0.
Jun 13 16:59:56 xmail1 kernel: IPv6 over IPv4 tunneling driver
Jun 13 16:59:56 xmail1 kernel: sit0: Disabled Privacy Extensions
Jun 13 16:59:56 xmail1 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jun 13 16:59:59 xmail1 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Jun 13 16:59:59 xmail1 kernel: tg3: eth0: Flow control is on for TX and on for RX.
Jun 13 16:59:59 xmail1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun 13 17:00:00 xmail1 avahi-daemon[1979]: Registering new address record for fe80::230:48ff:fe59:a1f8 on eth0.*.
Jun 13 17:00:00 xmail1 avahi-daemon[1979]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 17:00:00 xmail1 avahi-daemon[1979]: New relevant interface eth0.IPv4 for mDNS.
Jun 13 17:00:00 xmail1 avahi-daemon[1979]: Registering new address record for 192.168.1.21 on eth0.IPv4.
Jun 13 17:18:46 xmail1 yum-updatesd-helper: error getting update info: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again
Jun 13 18:03:14 xmail1 avahi-daemon[1979]: Withdrawing address record for 192.168.1.21 on eth0.
Jun 13 18:03:14 xmail1 avahi-daemon[1979]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 18:03:14 xmail1 avahi-daemon[1979]: Interface eth0.IPv4 no longer relevant for mDNS.
Jun 13 18:03:14 xmail1 avahi-daemon[1979]: Withdrawing address record for fe80::230:48ff:fe59:a1f8 on eth0.
Jun 13 18:03:15 xmail1 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jun 13 18:03:17 xmail1 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Jun 13 18:03:17 xmail1 kernel: tg3: eth0: Flow control is on for TX and on for RX.
Jun 13 18:03:17 xmail1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun 13 18:03:18 xmail1 avahi-daemon[1979]: Registering new address record for fe80::230:48ff:fe59:a1f8 on eth0.*.
Jun 13 18:03:19 xmail1 avahi-daemon[1979]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 18:03:19 xmail1 avahi-daemon[1979]: New relevant interface eth0.IPv4 for mDNS.
Jun 13 18:03:19 xmail1 avahi-daemon[1979]: Registering new address record for 192.168.1.21 on eth0.IPv4.
Jun 13 18:09:55 xmail1 avahi-daemon[1979]: Withdrawing address record for 192.168.1.21 on eth0.
Jun 13 18:09:55 xmail1 avahi-daemon[1979]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 18:09:55 xmail1 avahi-daemon[1979]: Interface eth0.IPv4 no longer relevant for mDNS.
Jun 13 18:09:55 xmail1 avahi-daemon[1979]: Withdrawing address record for fe80::230:48ff:fe59:a1f8 on eth0.
Jun 13 18:09:56 xmail1 kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jun 13 18:09:59 xmail1 kernel: tg3: eth0: Link is up at 1000 Mbps, full duplex.
Jun 13 18:09:59 xmail1 kernel: tg3: eth0: Flow control is on for TX and on for RX.
Jun 13 18:09:59 xmail1 kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun 13 18:10:00 xmail1 avahi-daemon[1979]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.21.
Jun 13 18:10:00 xmail1 avahi-daemon[1979]: New relevant interface eth0.IPv4 for mDNS.
Jun 13 18:10:00 xmail1 avahi-daemon[1979]: Registering new address record for 192.168.1.21 on eth0.IPv4.
Jun 13 18:10:00 xmail1 avahi-daemon[1979]: Registering new address record for fe80::230:48ff:fe59:a1f8 on eth0.*.

...

Jun 13 18:26:10 xmail1 restorecond: Will not restore a file with more than one hard link (/etc/resolv.conf) Invalid argument
 
Old 06-16-2008, 05:23 PM   #10
kbighorse
LQ Newbie
 
Registered: Jun 2008
Posts: 20

Original Poster
Rep: Reputation: 0
Perhaps SELinux is involved? See below, regarding resolv.conf and restorecond error in /var/logs/messages:

http://www.fedoraforum.org/forum/arc.../t-159533.html

Perhaps avahi-daemon is also involved?
 
Old 06-16-2008, 09:58 PM   #11
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
While interesting, the log messages do not, by themselves, indicate anything wrong. They do, however, indicate that you are running a multicast DNS scheme to provide DNS service to some number of your machines.

The original problem you reported was that some of your servers could not resolve the address 64.81.79.2, which is off your local net. Subsequent posts indicate that you have effectively no firewalling between the offending machine and the Internet. It seems to me that it might be time to actually do a packet trace on (for example) xmail1 to find out what in the world it is doing when you ask it to resolve that address. There should be no problem in its resolution, but there definitely is.

The tool you need is tcpdump, and the thing you want to look for is UDP packets with either source- or destination-port 53. I think it will be very informative to find out where that machine is actually sending such packets, because they clearly are not going where they should.
 
Old 06-17-2008, 02:46 PM   #12
kbighorse
LQ Newbie
 
Registered: Jun 2008
Posts: 20

Original Poster
Rep: Reputation: 0
Some tcpdump output that might be helpful:

...

13:31:00.110143 IP 192.168.1.21.ssh > 192.168.1.1.39540: P 663016090:663016282(192) ack 2620139830 win 90 <nop,nop,timestamp 1894415 228009203>
13:31:00.110230 IP 192.168.1.1.39540 > 192.168.1.21.ssh: . ack 192 win 22444 <nop,nop,timestamp 228009212 1894415>
13:31:00.110633 IP 192.168.1.21.32798 > 64.81.79.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:05.110224 IP 192.168.1.21.32799 > 216.231.41.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:10.110215 IP 192.168.1.21.32798 > 64.81.79.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:15.110212 IP 192.168.1.21.32799 > 216.231.41.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:20.110282 IP 192.168.1.21.32799 > 64.81.79.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:25.110236 IP 192.168.1.21.32800 > 216.231.41.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:30.110212 IP 192.168.1.21.32799 > 64.81.79.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:35.110217 IP 192.168.1.21.32800 > 216.231.41.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:40.110196 arp who-has 192.168.1.1 tell 192.168.1.21
13:31:40.110305 arp reply 192.168.1.1 is-at 00:30:48:59:dd:dc (oui Unknown)

...

[root@xmail1 var]# less tcplog.txt | grep UDP
13:33:51.904148 IP 192.168.1.25.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP PACKET(138)
13:33:51.904418 IP 192.168.1.25.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP PACKET(138)
13:35:51.150368 IP 192.168.1.25.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP PACKET(138)
13:38:48.078832 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:38:48.828701 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:38:49.578715 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:40:57.531666 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:40:58.281135 IP 192.168.1.25.netbios-ns > 192.168.1.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

...

[root@xmail1 var]# less tcplog.txt | grep 64.81.79.2
13:31:00.110633 IP 192.168.1.21.32798 > 64.81.79.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:10.110215 IP 192.168.1.21.32798 > 64.81.79.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:20.110282 IP 192.168.1.21.32799 > 64.81.79.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:30.110212 IP 192.168.1.21.32799 > 64.81.79.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:40.110357 IP 192.168.1.21.32800 > 64.81.79.2.domain: 12659+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:31:50.110211 IP 192.168.1.21.32800 > 64.81.79.2.domain: 12659+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:31:55.366859 IP 192.168.1.21.32802 > 64.81.79.2.domain: 28429+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:32:00.110344 IP 192.168.1.21.32804 > 64.81.79.2.domain: 33628+ PTR? 2.41.231.216.in-addr.arpa. (43)

...

[root@xmail1 var]# less tcplog.txt | grep 216.231.41.2
13:31:05.110224 IP 192.168.1.21.32799 > 216.231.41.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:15.110212 IP 192.168.1.21.32799 > 216.231.41.2.domain: 39250+ PTR? 1.1.168.192.in-addr.arpa. (42)
13:31:25.110236 IP 192.168.1.21.32800 > 216.231.41.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:35.110217 IP 192.168.1.21.32800 > 216.231.41.2.domain: 28995+ PTR? 21.1.168.192.in-addr.arpa. (43)
13:31:45.110219 IP 192.168.1.21.32801 > 216.231.41.2.domain: 12659+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:31:55.110213 IP 192.168.1.21.32801 > 216.231.41.2.domain: 12659+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:31:56.366784 IP 192.168.1.21.32803 > 216.231.41.2.domain: 28429+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:32:02.366824 IP 192.168.1.21.32803 > 216.231.41.2.domain: 28429+ PTR? 2.79.81.64.in-addr.arpa. (41)
13:32:05.110218 IP 192.168.1.21.32805 > 216.231.41.2.domain: 33628+ PTR? 2.41.231.216.in-addr.arpa. (43)

...

Should I grep for something in particular? thanks so much!
 
Old 06-17-2008, 04:15 PM   #13
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
Rather than 'grep'ping for stuff after the fact, it is probably better to get tcpdump to filter the traffic for you right away. Here is a command that I think will provide some instructive data:
Code:
tcpdump -nn -v udp port 53
This command will record only UDP packets either coming from or going to port 53, the DNS port.
On my machine, this produces a result like this:
Quote:
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 80) 216.39.145.64.32768 > 192.33.4.12.53: 52949% [1au] PTR? 2.79.81.64.in-addr.arpa. (52)
IP (tos 0x0, ttl 50, id 33487, offset 0, flags [none], proto UDP (17), length 231) 192.33.4.12.53 > 216.39.145.64.32768: 52949- 0/7/1 (203)
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 80) 216.39.145.64.32768 > 192.5.6.32.53: 60547% [1au] PTR? 2.79.81.64.in-addr.arpa. (52)
IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto UDP (17), length 129) 192.5.6.32.53 > 216.39.145.64.32768: 60547- 0/2/1 (101)
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 74) 216.39.145.64.32768 > 66.93.87.8.53: 42195% [1au] A? ns1.speakeasy.net. (46)
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 74) 216.39.145.64.32768 > 66.93.87.8.53: 11005% [1au] AAAA? ns1.speakeasy.net. (46)
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 74) 216.39.145.64.32768 > 66.93.87.8.53: 13326% [1au] A? ns2.speakeasy.net. (46)
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 74) 216.39.145.64.32768 > 66.93.87.8.53: 13919% [1au] AAAA? ns2.speakeasy.net. (46)
IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 182) 66.93.87.8.53 > 216.39.145.64.32768: 42195*- 1/4/2 ns1.speakeasy.net. A 72.1.140.145 (154)
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 80) 216.39.145.64.32768 > 72.1.140.145.53: 5726% [1au] PTR? 2.79.81.64.in-addr.arpa. (52)
IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 118) 66.93.87.8.53 > 216.39.145.64.32768: 11005*- 0/1/0 (90)
IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 182) 66.93.87.8.53 > 216.39.145.64.32768: 13326*- 1/4/2 ns2.speakeasy.net. A 216.231.41.19 (154)
IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 118) 66.93.87.8.53 > 216.39.145.64.32768: 13919*- 0/1/0 (90)
IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto UDP (17), length 141) 72.1.140.145.53 > 216.39.145.64.32768: 5726*- 1/2/0 2.79.81.64.in-addr.arpa. PTR[|domain]
 
Old 06-17-2008, 05:54 PM   #14
kbighorse
LQ Newbie
 
Registered: Jun 2008
Posts: 20

Original Poster
Rep: Reputation: 0
Thanks, I ran 'nslookup 64.79.81.2' and 'ping www.google.com' with no results, and then ran 'nslookup 216.231.41.2' and got this:

[root@xmail1 ~]# tail -f /var/tcplog.txt
18:42:07.719876 IP (tos 0x0, ttl 64, id 49257, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32871 > 64.81.79.2.53: 451+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:42:12.719215 IP (tos 0x0, ttl 64, id 54257, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32872 > 216.231.41.2.53: 451+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:42:17.719207 IP (tos 0x0, ttl 64, id 49258, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32871 > 64.81.79.2.53: 451+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:42:22.719210 IP (tos 0x0, ttl 64, id 54258, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32872 > 216.231.41.2.53: 451+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:45:17.143869 IP (tos 0x0, ttl 64, id 42073, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32872 > 64.81.79.2.53: 59727+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:45:22.143234 IP (tos 0x0, ttl 64, id 47073, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32875 > 216.231.41.2.53: 59727+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:45:27.143206 IP (tos 0x0, ttl 64, id 42074, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32872 > 64.81.79.2.53: 59727+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:45:32.143207 IP (tos 0x0, ttl 64, id 47074, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32875 > 216.231.41.2.53: 59727+ PTR? 19.1.168.192.in-addr.arpa. (43)
18:46:02.741892 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32875 > 64.81.79.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:03.741814 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32876 > 216.231.41.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:08.741822 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32875 > 64.81.79.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:09.741847 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32876 > 216.231.41.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:14.741880 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32875 > 64.81.79.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:46:15.741907 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.1.21.32876 > 216.231.41.2.53: 4116+ PTR? 2.79.81.64.in-addr.arpa. (41)
18:47:07.028418 IP (tos 0x0, ttl 64, id 20886, offset 0, flags [DF], proto UDP (17), length 60) 192.168.1.21.32876 > 64.81.79.2.53: 22006+ A? www.google.com. (32)
18:47:12.028237 IP (tos 0x0, ttl 64, id 25886, offset 0, flags [DF], proto UDP (17), length 60) 192.168.1.21.32877 > 216.231.41.2.53: 22006+ A? www.google.com. (32)
18:47:17.028214 IP (tos 0x0, ttl 64, id 20887, offset 0, flags [DF], proto UDP (17), length 60) 192.168.1.21.32876 > 64.81.79.2.53: 22006+ A? www.google.com. (32)
18:47:22.028209 IP (tos 0x0, ttl 64, id 25887, offset 0, flags [DF], proto UDP (17), length 60) 192.168.1.21.32877 > 216.231.41.2.53: 22006+ A? www.google.com. (32)
18:47:27.028268 IP (tos 0x0, ttl 64, id 40886, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32877 > 64.81.79.2.53: 26241+ A? www.google.com.glocap.com. (43)
18:47:32.028220 IP (tos 0x0, ttl 64, id 45886, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32878 > 216.231.41.2.53: 26241+ A? www.google.com.glocap.com. (43)
18:47:37.028216 IP (tos 0x0, ttl 64, id 40887, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32877 > 64.81.79.2.53: 26241+ A? www.google.com.glocap.com. (43)
18:47:42.028216 IP (tos 0x0, ttl 64, id 45887, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32878 > 216.231.41.2.53: 26241+ A? www.google.com.glocap.com. (43)
18:50:49.798302 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32878 > 64.81.79.2.53: 39588+ PTR? 2.41.231.216.in-addr.arpa. (43)
18:50:50.798225 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 71) 192.168.1.21.32880 > 216.231.41.2.53: 39588+ PTR

I just don't know how to read this yet..
 
Old 06-17-2008, 06:37 PM   #15
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
Well, that is pretty definitive: it says that your machine 192.168.1.21 is trying to reach quite a few servers, and getting replies from none of them. For reference, here is the resolution I get from my systems:
64.81.79.2 ==> dns.sfo1.speakeasy.net
216.231.41.2 ==> ns-legacy.speakeasy.net

The reason that you are not getting any answer is that your query is for resolution of an IP address 192.168.1.19. No self-respecting public DNS server is going to answer to that, for two reasons: first, it won't know the answer, and second, the request is for a Private Networking address. That address is almost certainly assigned to one of the machines on your local net, and is probably the address of a DNS server. I am betting that your xmail1 machine somehow thinks that it ought to be asking for that nameserver, rather than the ones you reported in your resolv.conf. Is there more than one such file? I have read about some GUI tools that keep system configuration in other places, and overwrite (or link to other files) the default stuff I am familiar with on Fedora systems.

And if you repeat the tcpdump experiment on xmail2 (that works), how does it compare?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
sendmail - Connection timed out [dsn=4.0.0 stat=Deferred: Connection timed out] ananthak Linux - Software 0 04-24-2007 07:28 AM
Connection time out;no servers could be reached sonvu Linux - Networking 1 12-16-2006 09:43 PM
DNS: connection timed out; no servers could be reached ubu_roi Linux - Networking 1 04-13-2005 11:45 AM
nslookup gives "connection timed out; no server could be reached" hello321_1999 Linux - Networking 3 11-26-2004 11:23 AM
connection timed out;no servers could be reached nitin34847 Linux - Networking 0 05-23-2004 12:47 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 09:44 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration