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