On Thu, Jul 04, 2002 at 12:46:38PM -0700, Jeff Newmiller wrote:
>On Thu, 4 Jul 2002, George Georgalis wrote:
>
>> 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

Sorry if my tone came across the wrong way :-} I simply meant I knew
what they should be. I actually did check all those things, but
apparently I cated resolv.conf from the wrong host, I don't usually make
mistakes like that and I feel pretty dumb about it.

>Note that I do not presume to know more than you do about networking... or

I do hope you do know more than me :-) and I don't mind if you are
presumptuous, really. I only meant to communicate that detailed basic
instructions aren't necessary. In fact, I like 'did you check' type
answers because they save everyone time. If I don't know what you're
talking about, you've pointed me in the right direction and I need to
do some homework before I can frame a good followup question, and doing
that just might lead me to the answer.


>> 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?

The 10.0.0.0 network is for a DMZ, the ip aliases aren't necessary on
this host.  They are the remains of stock network configuration script
I use. I've completely removed the stock shorewall and networking for
networking.sh and iptables.sh scripts that I put in init.d. There will
be aliases on the internet(s) interface(s) however, this will facilitate
forwarding to hosts on the 10.0.0.0 DMZ. I'm not running a resolver on
this box.


>
>> >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

Thanks for the detailed account. It's the checks program I'm looking
for.  What checks? I don't have dig, host, nslookup, dnsqr or dnsq. Is
there something in busybox that will do this? I don't see it.

Thanks,
// George

-- 
GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229 
Security Services, Web, Mail,            mailto:[EMAIL PROTECTED] 
File, Print, DB and DNS Servers.       http://www.galis.org/george 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Bringing you mounds of caffeinated joy.
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

Reply via email to