On Thu, 4 Jul 2002, George Georgalis wrote:
> On Thu, Jul 04, 2002 at 07:36:29AM -0700, Ray Olszewski wrote:
> >At 08:26 AM 7/4/02 -0400, George Georgalis wrote:
> >>I just remembered, my bering distro won't do hostname lookups.
> >>
> >>resolv.conf is okay
> >>hosts.allow/deny are okay
> >>the route is okay
> >
> >
> >How do you know all of these are "okay"? In particular, have you confirmed
> >that you can ping the IP addresses of the resolvers listed in resolv.conf?
> >You should confirm that, at least, before looking to more complicated answers.
>
> I know they are okay, because I pretty much know what I'm doing. I'm
> new to LRP not Linux.
Let's get something straight... you are asking for help, so you need to
behave like it. Whether you know what you are doing or not, you need to
be clear about which diagnostics you have performed, because if you were
really doing it right you would be able to tell where the problem was
without asking us. However, even the most experienced troubleshooter can
forget to check basic things, so you might as well follow the SR FAQ
listed at the bottom of the message and show us the results of an
organized attack on the problem, with questions about results that you
don't understand. Be prepared for people to suggest anything you fail to
show us... sometimes you may not see the relevance but someone else will,
and sometimes you may in fact find that they are on a wild goose chase....
and for that, you need patience... that is the nature of this medium.
Note that I do not presume to know more than you do about networking... or
even enough to solve your problem. You may have years of experience...
but if you cannot provide a clear report of the configuration and
diagnostic results, then any value we might have as additional eyes to
help you is lost. We are not psychic, though we can occasionally appear
to be if you haven't mutated your configuration far from the standard
ones we have seen.
> I can ping the LAN resolver, and it does work.
I can't figure out what pinging yourself has to do with getting hostname
lookups to work on the router. I think Ray was not considering that your
resolv.conf might have 127.0.0.1 and 10.1.1.1 in it, and that you might be
running tinydns and dnscache.
> I forgot to mention, I've also checked the iptables rules and they are
> okay, verified by no messages in the log.
>
> I also tried adding these to both the lrp and the LAN resolver.
>
> # iptables -I INPUT -p udp --dport 53 -j ACCEPT
> # iptables -I INPUT -p udp --dport 53 -j LOG --log-prefix "DNS-in "
>
> The LAN resolver logs other host lookups but not the lrp. Likewise, the
> lrp logs when I dig it, but no log when I try to ping a hostname, I can
> ping the resolver by ip.
Packets from the router will not go through the input chain.
>
> >>ping galis.org just hangs. not sure how else to look up a name, am I
> >>missing a package? What could be wrong? It does ping ip addresses.
> >
> >
> >If your system passes the above test, try posting the usual dagnostics.
>
> I didn't assign a broadcast address when I brought up the interfaces,
> could that be a problem?
I don't think so.
> Bering V1.0-rc2
> Linux fw01 2.4.18 #1 Sun Apr 21 12:50:34 CEST 2002 i586 unknown
> 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:a0:cc:5a:b6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.9.66/24 scope global eth0
> 4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:a0:cc:d9:21:e0 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.1/8 scope global eth1
> inet 10.0.0.1/8 scope global secondary eth1:1
> inet 10.0.0.2/8 scope global secondary eth1:2
> inet 10.0.0.3/8 scope global secondary eth1:3
> inet 10.0.0.4/8 scope global secondary eth1:4
> 5: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:a0:cc:5b:1c:37 brd ff:ff:ff:ff:ff:ff
> inet 62.81.93.66/26 scope global eth2
> 6: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:40:05:41:9d:1d brd ff:ff:ff:ff:ff:ff
> inet 201.13.105.34/27 scope global eth3
> 201.13.105.32/27 dev eth3 proto kernel scope link src 201.13.105.34
> 62.81.93.64/26 dev eth2 proto kernel scope link src 62.81.93.66
> 192.168.9.0/24 dev eth0 proto kernel scope link src 192.168.9.66
> 10.0.0.0/8 dev eth1 proto kernel scope link src 10.1.1.1
> 127.0.0.0/8 via 127.0.0.1 dev lo
> default via 62.81.93.65 dev eth2
Your abuse of eth1 is really bizarre. Why all the aliases? Why
10.1.1.1 at all? Even if there are valid reasons for all of this, you
should be aware that many assumptions are made in the configuration files
on the basic 192.168.0.254 ip address for the internal network. I think
there are several places in the dnscache and tinydns configurations that
will need to be fixed... can you show us what you have changed?
> >Finally, this sort of question belongs on leaf-user, NOT leaf-devel. I'be
> >moved it in my reply.
>
> Okay by me. I thought I had a development issue. My guess is I've
> stripped something that's required for name resolution. So I ask, what
> is used for host lookups (the udp/53 call) on lrp?
The following is my understanding of how this works from using Bering RC2:
Requests originating on the router are handled according to
/etc/resolv.conf. Bering comes configured with dnscache, and you will
need to add tinydns to the syslinux.cfg file to support local lan
lookups. Then following the lrcfg menus should lead you to all the
configuration files that need to be edited for dnscache and tinydns. You
will need to "svi tinydns restart" after altering tinydns' files.
A lookup on the router goes something like:
a) checks /etc/nsswitch.conf to determine whether to check local files
and/or use dns protocol, and in what order. By default, files are
checked first, then dns protocol.
b) checks /etc/hosts, done if answer found
c) checks /etc/resolv.conf, queries nameservers as follows:
for each nameserver
done if nameserver recognizes literal name
if literal name is a hostname only, then
for each search network
done if nameserver recognizes literal name+search network
d) fail
tinydns is configured to respond to either or both of 127.0.0.1 (a
tinyds-private instance handling masq'd LAN names) and your public ip
address (a tinydns-public instance handling your public dns names). and
dnscache responds on eth1, caching results from both tinydns-private and
from the internet root servers (which lead back to tinydns-public if you
are serving public names). Thus, a lookup from the router will hit
tinydns-private twice in the as-shipped configuration... once from libnss,
and once from dnscache. A lookup from the LAN will only hit
tinydns-private once.
You should make sure that you have edited /etc/tinydns-private/env/DOMAINS
(lrcfg/3/"tinydns"/6) to have appropriate lan names and reverse lookups
for your lan.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
