Local Lan DNS Problems

My LAN is having all sorts of problems resolving names and I'm not sure
where to go from here. Could there be a problem with the IPCop DNS ?

IPCop is the DHCP & DNS Server and all machines except 1 (server) use DHCP
however name resolution is erratic.

From example on the server (angus 192.168.1.2)
* I can "ping 192.168.1.1"
* I cannot "ping ipcop"

From the IPCop machine
* I can "ping 192.168.1.2"
* I cannot "ping angus"

From a client machine
* I can ping IP addresses
* I cannot ping names

Both machines have a /etc/hosts file with the sole entry being
127.0.0.1 localhost

All machines have a /etc/resolv.conf file with the sole entry being
nameserver 192.168.1.1 (on the server angus and clients)
nameserver 127.0.0.1 (on the IPCop machine)

Any help would be greatly appreciated

Thanks

Murphy

> IPCop is the DHCP & DNS Server and all machines except 1 (server) use DHCP
> however name resolution is erratic.
>
> From example on the server (angus 192.168.1.2)
> * I can "ping 192.168.1.1"
> * I cannot "ping ipcop"
>
> From the IPCop machine
> * I can "ping 192.168.1.2"
> * I cannot "ping angus"
>
> From a client machine
> * I can ping IP addresses
> * I cannot ping names
>
> Both machines have a /etc/hosts file with the sole entry being
> 127.0.0.1 localhost
>
> All machines have a /etc/resolv.conf file with the sole entry being
> nameserver 192.168.1.1 (on the server angus and clients)
> nameserver 127.0.0.1 (on the IPCop machine)

All of the above looks right, for making ipcop responsible for resolving
LAN host names. Yet, ipcop isn't resolving queries about its DHCP
leases. So two possibilities come to mind:

(1) IPcop isn't configured to check its DHCP leases when resolving LAN
host names. I don't know anything about IPcop, but in dnsmasq there's a
parameter that sets the order of preference for name resolution, e.g.
first /etc/hosts, then DHCP leases, then upstream DNS. If you don't
mention DHCP leases, they don't get checked.

(2) A firewall is blocking DNS queries or answers to/from ipcop.

Good luck,
Andrew.

--
To reply by email, replace "deadspam.com" by "alumni.utexas.net"

In article <7m0Fd.115021$K7.99452@news-server.bigpond.net.au>, Murphy wrote:

>My LAN is having all sorts of problems resolving names and I'm not sure
>where to go from here. Could there be a problem with the IPCop DNS ?

Sure looks that way.

>IPCop is the DHCP & DNS Server and all machines except 1 (server) use DHCP
>however name resolution is erratic.

"erratic" means inconsistent - as if it works sometimes, and not at others.
Is this so? If so, under what circumstances? I never liked using DHCP (with
RFC1918, there are 17 million addresses available, so the original rational
for dynamic addressing is long gone), as it complicates setting up DNS. Are
you using 'reserved' addresses (so that the host with MAC address $FOO is
always getting IP address $BAR), or is it random?

>From example on the server (angus 192.168.1.2)
>* I can "ping 192.168.1.1"
>* I cannot "ping ipcop"

And the error message is?

>From the IPCop machine
>* I can "ping 192.168.1.2"
>* I cannot "ping angus"

Same. Well, let's start with the basics. Is bind installed? Is it
configured? Is it running ('ps auxw' and look for 'named')? Are the DNS
tools installed (normally called bind-utils or bind-utilities, this would
be 'dig', 'dnsquery', 'host' and maybe the deprecated 'nslookup'. If you
use one of those tools, does it get information from the name server? If
not, what is the error message? On the IPCop machine, is there something
listening on port 53/UDP ('netstat -tupan' should show it)?

>Both machines have a /etc/hosts file with the sole entry being
>127.0.0.1 localhost

OK. On hosts with static addresses, like your 'ipcop' and 'angus', I
like to see the address and _full_ hostname (with dots and a domain)
in their own hosts file. That way, when the systems boot, they know who
they are without waiting for a response from the DNS server, but that is
a personal preference, not a system requirement.

>All machines have a /etc/resolv.conf file with the sole entry being

OK, though if you read the resolver man page, the 127.0.0.1 entry is not
absolutely required.

>Any help would be greatly appreciated

91563 Dec 23 2001 DNS-HOWTO

a bit old, but still usable.

Old guy

Murphy wrote:
> My LAN is having all sorts of problems resolving names and I'm not
sure
> where to go from here. Could there be a problem with the IPCop DNS ?
>
> IPCop is the DHCP & DNS Server and all machines except 1 (server) use
DHCP
> however name resolution is erratic.
>
> From example on the server (angus 192.168.1.2)
> * I can "ping 192.168.1.1"
> * I cannot "ping ipcop"
>
> From the IPCop machine
> * I can "ping 192.168.1.2"
> * I cannot "ping angus"
>
> From a client machine
> * I can ping IP addresses
> * I cannot ping names
>
> Both machines have a /etc/hosts file with the sole entry being
> 127.0.0.1 localhost
>
> All machines have a /etc/resolv.conf file with the sole entry being
> nameserver 192.168.1.1 (on the server angus and clients)
> nameserver 127.0.0.1 (on the IPCop machine)
>

Is your name resolution erratic or nonexistent?

No experience with IPCop, so I'm not sure what, if any, changes they
made to dnsmaq -- can't imagine they would.

So I'm looking at this as a straight dnsmasq issue. I assume dnsmasq
is providing _both_ DHCP and DNS services.

Do you have the latest IPCop version (IPCop v1.4.2) added 20-Dec-2004?
There seem to be some dhcp fixes.

What if any dnsmasq documentation did IPCop include? The example conf
file is loaded with comments -- dnsmasq.conf.example. Did they include
setup.html from the dnsmasq source? You might compare yours with the
example.

The reason I ask is because the IPCop docs I downloaded and the FAQ
don't seem to address the gothchas that can arise with name resolvers
-- especially if the client machines have seen previous duty with other
DHCP/DNS usage patterns. And the docs predede 1.4.x which is supposed
to be a major change.

The dnsmasq source provides documentation -- it's here:
http://www.thekelleys.org.uk/dnsmasq/

That out of the way ...

No name resolution would indicate to me that the clients are not set up
to provide IPCop -- actually dnsmasq -- with their hostnames. When
using DHCP dnsmasq expects hosts to send along their names so that
dnsmasq knows how to assoaciate their names with the IP given out.
Otherwise dnsmasq satisfies the IP request and maps to an autogenerated
name of this form:
xxx-xxx-domain.name
It used to, anyway ;-)

There are several ways to approach this and it can depend on the distro
the client is using. Here are a couple of links offering examples I
found googling:
http://www.linuxnetmag.com/en/issue7/m7dnsmasq1.html
http://www.enterprisenetworkingplane...0951_3377351_2
and from the dnsmasq setup.html:
[quote]
Integration with DHCP.

Dnsmasq reads /etc/hosts so that the names of local machines are
available in DNS. This is fine when you give all your local machines
static IP addresses which can go in /etc/hosts, but it doesn't work
when local machines are configured via DHCP, since the IP address
allocated to machine is not fixed. Dnsmasq comes with an integrated
DHCP daemon to solve this problem.

The dnsmasq DHCP daemon allocates addresses to hosts on the network and
tries to determine their names. If it succeeds it add the name and
address pair to the DNS. There are basically two ways to associate a
name with a DHCP-configured machine; either ***the machine knows its
name*** which it gets a DHCP lease, or dnsmasq gives it a name, based
on the MAC address of its ethernet card. For the former to work, ***a
machine needs to know its name when it requests a DHCP lease. For
_dhcpcd_ [many distros now using dhclient], the -h option specifies
this.*** The names may be anything as far as DHCP is concerned, but
dnsmasq adds some limitations. By default the names must not have a
domain part, ie they must just be a alphanumeric name, without any
dots. This is a security feature to stop a machine on your network
telling DHCP that its name is "www.microsoft.com" and thereby grabbing
traffic which shouldn't go to it. A domain part is only allowed by
dnsmasq in DHCP machine names if the domain-suffix option is set, the
domain part must match the suffix.

As an aside, make sure not to tell DHCP to set the hostname when it
obtains a lease (in dhcpcd that's the -H flag.) This is not reliable
since the DHCP server gets the hostname from DNS which in this case is
dnsmasq. There is a race condition because the host's name in the DNS
may change as a result of it getting a DHCP lease, but this does not
propagate before the name is looked up. The net effect may be that the
host believes it is called something different to its name in the DNS.
***To be safe, set the hostname on a machine locally, and pass the same
name to DHCP when requesting a lease. ***
[end quote]

$ man dhclinet.conf
$ man dhcp-options

>From dhcp-options:
option host-name string;

This option specifies the name of the client. The name may or may
not be qualified with the local domain name (it is preferable to use
the domain-name option to specify the domain name). See RFC 1035 for
character set restrictions.

You may need to look at:
nsswitch.conf
/etc/networks
/etc/hostname
/etc/host.conf
/etc/sysconfig/network << I know RH uses this ;)

For other distros (I'm using RH) I can't be certain (so I'm silent),
but check through them is you have problems. You'll almost certainly
need to edit one or two on each client -- that's my experience :(

Ah, but done once and dnsmasq hums along nicely.
hth,
prg
email above disabled

prg wrote:

>
> Murphy wrote:
>> My LAN is having all sorts of problems resolving names and I'm not
> sure
>> where to go from here. Could there be a problem with the IPCop DNS ?
>>
>> IPCop is the DHCP & DNS Server and all machines except 1 (server) use
> DHCP
>> however name resolution is erratic.
>>
>> From example on the server (angus 192.168.1.2)
>> * I can "ping 192.168.1.1"
>> * I cannot "ping ipcop"
>>
>> From the IPCop machine
>> * I can "ping 192.168.1.2"
>> * I cannot "ping angus"
>>
>> From a client machine
>> * I can ping IP addresses
>> * I cannot ping names
>>
>> Both machines have a /etc/hosts file with the sole entry being
>> 127.0.0.1 localhost
>>
>> All machines have a /etc/resolv.conf file with the sole entry being
>> nameserver 192.168.1.1 (on the server angus and clients)
>> nameserver 127.0.0.1 (on the IPCop machine)
>>
>
> Is your name resolution erratic or nonexistent?
>
> No experience with IPCop, so I'm not sure what, if any, changes they
> made to dnsmaq -- can't imagine they would.
>
> So I'm looking at this as a straight dnsmasq issue. I assume dnsmasq
> is providing _both_ DHCP and DNS services.
>
> Do you have the latest IPCop version (IPCop v1.4.2) added 20-Dec-2004?
> There seem to be some dhcp fixes.
>
> What if any dnsmasq documentation did IPCop include? The example conf
> file is loaded with comments -- dnsmasq.conf.example. Did they include
> setup.html from the dnsmasq source? You might compare yours with the
> example.
>
> The reason I ask is because the IPCop docs I downloaded and the FAQ
> don't seem to address the gothchas that can arise with name resolvers
> -- especially if the client machines have seen previous duty with other
> DHCP/DNS usage patterns. And the docs predede 1.4.x which is supposed
> to be a major change.
>
> The dnsmasq source provides documentation -- it's here:
> http://www.thekelleys.org.uk/dnsmasq/
>
> That out of the way ...
>
> No name resolution would indicate to me that the clients are not set up
> to provide IPCop -- actually dnsmasq -- with their hostnames. When
> using DHCP dnsmasq expects hosts to send along their names so that
> dnsmasq knows how to assoaciate their names with the IP given out.
> Otherwise dnsmasq satisfies the IP request and maps to an autogenerated
> name of this form:
> xxx-xxx-domain.name
> It used to, anyway ;-)
>
> There are several ways to approach this and it can depend on the distro
> the client is using. Here are a couple of links offering examples I
> found googling:
> http://www.linuxnetmag.com/en/issue7/m7dnsmasq1.html
>
http://www.enterprisenetworkingplane...0951_3377351_2
> and from the dnsmasq setup.html:
> [quote]
> Integration with DHCP.
>
> Dnsmasq reads /etc/hosts so that the names of local machines are
> available in DNS. This is fine when you give all your local machines
> static IP addresses which can go in /etc/hosts, but it doesn't work
> when local machines are configured via DHCP, since the IP address
> allocated to machine is not fixed. Dnsmasq comes with an integrated
> DHCP daemon to solve this problem.
>
> The dnsmasq DHCP daemon allocates addresses to hosts on the network and
> tries to determine their names. If it succeeds it add the name and
> address pair to the DNS. There are basically two ways to associate a
> name with a DHCP-configured machine; either ***the machine knows its
> name*** which it gets a DHCP lease, or dnsmasq gives it a name, based
> on the MAC address of its ethernet card. For the former to work, ***a
> machine needs to know its name when it requests a DHCP lease. For
> _dhcpcd_ [many distros now using dhclient], the -h option specifies
> this.*** The names may be anything as far as DHCP is concerned, but
> dnsmasq adds some limitations. By default the names must not have a
> domain part, ie they must just be a alphanumeric name, without any
> dots. This is a security feature to stop a machine on your network
> telling DHCP that its name is "www.microsoft.com" and thereby grabbing
> traffic which shouldn't go to it. A domain part is only allowed by
> dnsmasq in DHCP machine names if the domain-suffix option is set, the
> domain part must match the suffix.

>
> As an aside, make sure not to tell DHCP to set the hostname when it
> obtains a lease (in dhcpcd that's the -H flag.) This is not reliable
> since the DHCP server gets the hostname from DNS which in this case is
> dnsmasq. There is a race condition because the host's name in the DNS
> may change as a result of it getting a DHCP lease, but this does not
> propagate before the name is looked up. The net effect may be that the
> host believes it is called something different to its name in the DNS.
> ***To be safe, set the hostname on a machine locally, and pass the same
> name to DHCP when requesting a lease. ***
> [end quote]
>
> $ man dhclinet.conf
> $ man dhcp-options
>
>>From dhcp-options:
> option host-name string;
>
> This option specifies the name of the client. The name may or may
> not be qualified with the local domain name (it is preferable to use
> the domain-name option to specify the domain name). See RFC 1035 for
> character set restrictions.
>
> You may need to look at:
> nsswitch.conf
> /etc/networks
> /etc/hostname
> /etc/host.conf
> /etc/sysconfig/network << I know RH uses this ;)
>
> For other distros (I'm using RH) I can't be certain (so I'm silent),
> but check through them is you have problems. You'll almost certainly
> need to edit one or two on each client -- that's my experience :(
>
> Ah, but done once and dnsmasq hums along nicely.
> hth,
> prg
> email above disabled

I found this that states that static IP addresses need to be added to the
IPCop hosts file, which I've done:

http://www.ipcop.org/modules.php?op=...=yes&id_cat=10

I now have entries in the IPCop hosts file for
127.0.0.1 Localhost
192.168.1.1 ipcop.local ipcop
192.168.1.2 angus.local angus


Interestingly the only machine on the LAN that I cannot ping by hostname is
a dual boot Linux client. I can check the DHCP leases in the IPCop admin
web page and see that 192.168.1.253 has no entry under hostname, the other
entries do have a hostname however I I reboot this Linux machine and boot
up Windows then check the DHCP leases then I can see the same IP add has
been assigned and there is an entry under hostname of the machine !

Still looking...

--
Thanks

Murph

Murphy wrote:
> prg wrote:
>
> >
> > Murphy wrote:
> >> My LAN is having all sorts of problems resolving names and I'm not
> > sure
> >> where to go from here. Could there be a problem with the IPCop DNS
?
[snip]
>
> I found this that states that static IP addresses need to be added to
the
> IPCop hosts file, which I've done:
>
>
http://www.ipcop.org/modules.php?op=...=yes&id_cat=10

You mean this?
How can I access my servers via their public domain names from the
internal network?

You mean you added _all_ your hosts to IPCop's /etc/hosts? Or just the
two following?

> I now have entries in the IPCop hosts file for
> 127.0.0.1 Localhost
> 192.168.1.1 ipcop.local ipcop
> 192.168.1.2 angus.local angus
>
>
> Interestingly the only machine on the LAN that I cannot ping by
hostname is
> a dual boot Linux client. I can check the DHCP leases in the IPCop
admin
> web page and see that 192.168.1.253 has no entry under hostname, the
other
> entries do have a hostname however I I reboot this Linux machine and
boot
> up Windows then check the DHCP leases then I can see the same IP add
has
> been assigned and there is an entry under hostname of the machine !

You statement here contradicts your earlier:
>From a client machine
* I can ping IP addresses
* I cannot ping names <<<<<< what's up

Exactitude is a _primary_ requirement when trying to solve network
problems -- especially via email or ngs.

When you reboot into Windows you will be asking to renew _Windows_
lease -- it is ignorant of the lease file used in Linux. And vice
versa.

The problem with this is that depending on how the dhcp server is
tracking host requests (using client-identifier which is commonly a MAC
address?) the Windows request can look like a different machine to dhcp
as it can pre-pend an 0x01 to the MAC that Linux uses.

Other than this common observation, which may have _nothing_ to do with
your problem, I can offer nothing new. Utmost clarification from you
on your net layout, IPCop setup re: dhcp, and which machines can ping
which machines or not by name would be _minmum_ necessities. Details,
details, more details and exactness is the only hope for us to help.
You have to be our eyes and hands at your end.

Otherwise you have to go to a mailing list set up for your specific
software, where the folks are _much_ more familiar with setting it up.
Pick your poison.

regards,
prg
email above disabled

prg wrote:

>
> Murphy wrote:
>> prg wrote:
>>
>> >
>> > Murphy wrote:
>> >> My LAN is having all sorts of problems resolving names and I'm not
>> > sure
>> >> where to go from here. Could there be a problem with the IPCop DNS
> ?
> [snip]
>>
>> I found this that states that static IP addresses need to be added to
> the
>> IPCop hosts file, which I've done:
>>
>>
>
http://www.ipcop.org/modules.php?op=...=yes&id_cat=10
>
> You mean this?
> How can I access my servers via their public domain names from the
> internal network?
>
> You mean you added _all_ your hosts to IPCop's /etc/hosts? Or just the
> two following?

I've only added the two entries below to the ipcop hosts file as I
understand, correct me if wrong, that as theothers use DHCP then they
should be able to be located with dns queries.

>
>> I now have entries in the IPCop hosts file for
>> 127.0.0.1 Localhost
>> 192.168.1.1 ipcop.local ipcop
>> 192.168.1.2 angus.local angus
>>
>>
>> Interestingly the only machine on the LAN that I cannot ping by
> hostname is
>> a dual boot Linux client. I can check the DHCP leases in the IPCop
> admin
>> web page and see that 192.168.1.253 has no entry under hostname, the
> other
>> entries do have a hostname however I I reboot this Linux machine and
> boot
>> up Windows then check the DHCP leases then I can see the same IP add
> has
>> been assigned and there is an entry under hostname of the machine !
>
> You statement here contradicts your earlier:
>>From a client machine
> * I can ping IP addresses
> * I cannot ping names <<<<<< what's up

My appologies, I was incorrect in what I posted previously.
It now appears that everyone can ping everyone with the exception that the
dual boot Linux workstation when running as Linux can only be pinged by
ipaddress not name only when running as Linux.

In the IPCop DHCP leases section this Linux workstation is the only entry
that does not have a name in the hostname column.

>
> Exactitude is a _primary_ requirement when trying to solve network
> problems -- especially via email or ngs.
>
> When you reboot into Windows you will be asking to renew _Windows_
> lease -- it is ignorant of the lease file used in Linux. And vice
> versa.
>
> The problem with this is that depending on how the dhcp server is
> tracking host requests (using client-identifier which is commonly a MAC
> address?) the Windows request can look like a different machine to dhcp
> as it can pre-pend an 0x01 to the MAC that Linux uses.

Whn it's booted as Windows it can be pinged by name and the hostname appears
in the IPCop DHCP lease list, when it's booted as Linux it has the same
IPAdd however cannot be pinged by name and has no hostname listed in the
IPCop DHCP lease list.
>
> Other than this common observation, which may have _nothing_ to do with
> your problem, I can offer nothing new. Utmost clarification from you
> on your net layout, IPCop setup re: dhcp, and which machines can ping
> which machines or not by name would be _minmum_ necessities. Details,
> details, more details and exactness is the only hope for us to help.
> You have to be our eyes and hands at your end.
>
> Otherwise you have to go to a mailing list set up for your specific
> software, where the folks are _much_ more familiar with setting it up.
> Pick your poison.
>
> regards,
> prg
> email above disabled

--
Thanks

Murph

Murphy wrote:
> prg wrote:
>
> > [snip]
> >
> > You mean you added _all_ your hosts to IPCop's /etc/hosts? Or just
the
> > two following?
>
> I've only added the two entries below to the ipcop hosts file as I
> understand, correct me if wrong, that as theothers use DHCP then they
> should be able to be located with dns queries.
>
> >
> >> I now have entries in the IPCop hosts file for
> >> 127.0.0.1 Localhost
> >> 192.168.1.1 ipcop.local ipcop
> >> 192.168.1.2 angus.local angus
> >>
[snip]
> It now appears that everyone can ping everyone with the exception
that the
> dual boot Linux workstation when running as Linux can only be pinged
by
> ipaddress not name only when running as Linux.
>
> In the IPCop DHCP leases section this Linux workstation is the only
entry
> that does not have a name in the hostname column.

As a general rule, don't summarize or comment on command output or
config files -- just post them verbatim via copy-n-paste. What means
nothing to you may be just the clue someone else needs. For now I
don't need it and probably won't ask for it.

> > When you reboot into Windows you will be asking to renew _Windows_
> > lease -- it is ignorant of the lease file used in Linux. And vice
> > versa.
> >
> > The problem with this is that depending on how the dhcp server is
> > tracking host requests (using client-identifier which is commonly a
MAC
> > address?) the Windows request can look like a different machine to
dhcp
> > as it can pre-pend an 0x01 to the MAC that Linux uses.
>
> Whn it's booted as Windows it can be pinged by name and the hostname
appears
> in the IPCop DHCP lease list, when it's booted as Linux it has the
same
> IPAdd however cannot be pinged by name and has no hostname listed in
the
> IPCop DHCP lease list.

This symptom is what I told you earlier. Here's an explanation from
the dnsmasq FAQ that is similar to acquiring a lease with Win then
rebooting into Linux:
[quote]
Q: I'm network booting my machines, and trying to give them static
DHCP-assigned addresses. The machine gets its correct address
whilst booting, but then the OS starts and it seems to get
allocated a different address.

A: What is happening is this: The boot process sends a DHCP
request and gets allocated the static address corresponding to its
MAC address. The boot loader does not send a client-id. Then the OS
starts and repeats the DHCP process, but it it does send a
client-id. Dnsmasq cannot assume that the two requests are from the
same machine (since the client ID's don't match) and even though
the MAC address has a static allocation, that address is still in
use by the first incarnation of the machine (the one from the boot,
without a client ID.) dnsmasq therefore has to give the machine a
dynamic address from its pool. There are three ways to solve this:
(1) persuade your DHCP client not to send a client ID, or (2) set up
the static assignment to the client ID, not the MAC address. The
default client-id will be 01:<MAC address>, so change the dhcp-host
line from "dhcp-host=11:22:33:44:55:66,1.2.3.4" to
"dhcp-host=id:01:11:22:33:44:55:66,1.2.3.4" or (3) tell dnsmasq to
ignore client IDs for a particular MAC address, like this:
dhcp-host=11:22:33:44:55:66,id:*
[end quote]

Here are two other items from FAQ you may need:
[quote]
Q: Names on the internet are working fine, but looking up local names
from /etc/hosts or DHCP doesn't seem to work.

A: Resolver code sometime does strange things when given names without
any dots in. Win2k and WinXP may not use the DNS at all and just
try and look up the name using WINS. On unix look at "options
ndots:"
in "man resolv.conf" for details on this topic. Testing lookups
using "nslookup" or "dig" will work, but then attempting to run
"ping" will get a lookup failure, appending a dot to the end of the
hostname will fix things. (ie "ping myhost" fails, but "ping
myhost." works. The solution is to make sure that all your hosts
have a domain set ("domain" in resolv.conf, the network applet in
windows, or set a domain in your DHCP server). Any domain will do,
but "localnet" is traditional. Now when you resolve "myhost" the
resolver will attempt to look up "myhost.localnet" so you need to
have dnsmasq reply to that name. The way to do that is to include
the domain in each name on /etc/hosts and/or to use the
--expand-hosts and --domain-suffix options.

Q: I'm running Debian, and my machines get an address fine with DHCP,
but their names are not appearing in the DNS.

A: By default, none of the DHCP clients send the host-name when asking
for a lease. For most of the clients, you can set the host-name to
send with the "hostname" keyword in /etc/network/interfaces. (See
"man interfaces" for details.) That doesn't work for dhclient, were
you have to add something like "send host-name daisy" to
/etc/dhclient.conf [Update: the lastest dhcpcd packages _do_ send
the hostname by default.
[end quote]

Note that in RH the relaevant file _may_ be
/etc/sysconfig/networking/profiles/default/network

On this machine it contains _only_ this:
HOSTNAME=pbrain

I'm in a bind helping you as I've never installed IPCop and can't now
as it requires a dedicated hard disk -- sorry, but... ;)

You are not quite far enough along to decipher some of the explanations
in the docs or that I give, but you getting there. Read the dnsmasq
docs in the source download -- it's only 131.3 KB. Even IPCop
indicates that they are the authoritative documentation for dnsmasq in
IPCop. You will very likely have to extrapolate the examples in the
docs -- the source of your problem is your client setup, I convinced.
RH is the only one I would even venture a guess on.

Get used to reading man pages -- some of them _are_ useful ;)

Don't make a bunch of config changes at once in hopes that one will
work. Make a single change, test, if no change go on to the next most
likely winner based on the symptoms and docs. Be patient.

BTW, be sure to try the "ping host." with-a-dot test. That one is a no
change test that clearly points to a symptom/solution. But, it may not
be the _only_ needed change :-(

hth,
prg
email above disabled

Solved.

All I needed to do was specify DHCP_HOSTAME[0]="workstationname" in
rc.inet1.conf. The default setting is ""

Thanks

Murphy

Murphy wrote:
> Solved.
>
> All I needed to do was specify DHCP_HOSTAME[0]="workstationname" in
> rc.inet1.conf. The default setting is ""
>
> Thanks
>
> Murphy

Good job :-)

And thanks for posting the solution so others may find the answer.

After delving into IPCop so much, I'll have to keep it mind for
customers that need something more than can be had from even a good
broadband router.

Now, go have some fun this weekend ;)

prg