<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffcc" text="#000000">
5.) I have been doing this a number of years. I simply assigned both
interfaces the same IP, with the effect that as they use only one
interface at a time, everything worked even when switching interfaces
during a download.<br>
<br>
Whether this is in accordance with the RFC, I am not sure. It worked
for me and was simple.<br>
<br>
On 02/06/10 9:23, Simon Hobson wrote:
<blockquote cite="mid:p0624080ec82bb20623c9@simon.thehobsons.co.uk"
type="cite">Marc Chamberlin wrote:
<br>
<br>
<blockquote type="cite">Thanks everyone for all your help, it gave me
a lot to explore and was a big help. I have spent quite a few days on
this, and though I hate throwing stones at a project, with as much
invested in it as this one apparently has, and been around as long as
it has, I am quite surprised at how difficult it is/was to work with
and configure this server. I think a redesign, with particular
attention paid to the model and configuration language should be
seriously considered, but that is just IMHO.... Also, a number of (ok
maybe I should say possible) bugs have surfaced during the course of my
investigations, which made it far more difficult to find a solution,
than it should have been. I will go through these and then present what
I think is a solution and ask for opinions, since much of the
underlying model is undocumented, (as far as I could find) in
particular the precedence that is used by the server as it builds it's
database and decision tree for IP address assignments.
<br>
</blockquote>
<br>
To a certain extent you are right, but you have to remember that there
is a certain amount of "we wouldn't start from here" ! The latest
versions have a new feature that may be useful (reserved leases), and
there is another feature on the wish list (redefine the primary key)
that is as yet unimplemented but would solve (or at least help) quite a
few usage cases like yours.
<br>
<br>
Bear in mind that AFAIK, the ISC server is waaaay more adaptable than
most. And you are in fact asking for functionality that it wasn't
designed to do (and is arguably not in accordance with the standards).
You may have found it difficult, but you achieved it - no other server
that I have any experience with would do anything even remotely close.
Back when this server was started, people were still using BOOTP and
reverse ARP to configure clients - DHCP was a real leap forward !
<br>
<br>
Without looking, I can't say how far back the project goes, but I can
recall starting with version 3 when it was in a late RC version and
that was over a decade ago ! Previous versions go a lot further back
than that. Back when I started with it, I don't think we had **ANY**
wireless devices in the company.
<br>
As an aside, I was coming to the ISC server as I wasn't happy with the
way the SCO Openserver one worked (or in my case didn't) - it was a lot
harder to set up, and lacked virtually every tool you've used in your
setup. It also had a *serious* bug that AFAIK they never fixed.
<br>
<br>
<blockquote type="cite">2. The hardware "object" while it may be
convenient in some cases, I submit it is confusing and difficult to
work with. The underlying data structure for this object is actually
two fields, a hardware type identifier and a numeric encoded mac
address. I don't understand the need to bond the hardware type with the
mac address so tightly, and not provide any easier objects for users to
work with and manipulate instead. It took me quite awhile to figure out
how to use this object effectively, given my goal of using the mac
address of the client's interface in conditional expressions! See
below..
<br>
</blockquote>
<br>
I'm not with you here. What is hard about "hardware ethernet
aa:bb:c:d:ee:ff ;" ? You don't need all those binary-to-ascii and
substring constructs you are using (I think). While you may think it's
complicated to have a hardware type element, it is required as
different hardware types have different identification constructs - and
there was no way of knowing what new types may come along in the
future.
<br>
<br>
<blockquote type="cite">5. In order to handle clients with more than
one interface, and allow clients to dynamically switch between
different interfaces, I included the following two statements in my
dhcpd.conf file -
<br>
<br>
deny duplicates;
<br>
ping-check on;
<br>
<br>
My goal was to force a static IP address assignment to a particular
client, by using the class and pool declarations shown below, in
conjunction with these declarations. I noted instead, that if a client
booted up and initialized one of two interfaces (wired or wireless)
then switched interfaces (disabling the first initialized interface in
the process) that the dhcp server was unable to transfer the IP address
assigned to the first interface to the second one based on a simple
DHCPREQUEST. Instead the transfer only occurred if the client
reinitialize his interface and forcing a DHCPDISCOVER instead.
<br>
<br>
Perhaps this is correct dhcp behavior, but I would think that doing a
ping check and discovering that the client is no longer responding to
it, would have been sufficient to prevent the user unfriendly
requirement of having to reinitialize an interface just because it was
hot-plugged and/or the user turned the other off. So I am confused!
<br>
</blockquote>
<br>
Again, you are hitting a situation that was never envisaged when the
DHCP standards were written. The "problem" is that the way you want it
to work is explicitly not in accordance with the standards. It is a
known problem, that's why the deny-duplicates was introduced to try and
mitigate it to a certain extent. Ping-check has nothing whatsoever to
do with what you are trying to achieve, and is in fact merely a "safety
net" to try and avoid problems from some common network
misconfigurations.
<br>
<br>
<blockquote type="cite">---
<br>
<br>
That said, I set up a test network of a variety of clients, and after
lots of experimentation I arrived at the following configuration
segment, using classes and pools, to assign static IP addresses to
clients based on their operating system and interfaces. This has the
advantage of showing up in the logs, and if I am correct, gets around
the limitations of using host declarations to assign static IP
addresses. I won't show my entire dhcpd.conf file as most of it is
pretty standard stuff, except for the two declarations I mentioned
above. Sorry this is a bit long still, but I limited my test to just 5
systems on a small network.....
<br>
<br>
class "marcslaptop_Vista_Class" {
<br>
match if ((substring(option vendor-class-identifier, 0, 4) = "MSFT")
and
<br>
((ucase(binary-to-ascii(16, 8, ":", substring (hardware, 1,
6))) = ucase("0:1a:73:55:7d:f")) or
<br>
(ucase(binary-to-ascii(16, 8, ":", substring (hardware, 1,
6))) = ucase("0:16:36:c2:65:a4"))));
<br>
log (info, "marcslaptop_Vista_Class matched");
<br>
}
<br>
</blockquote>
<br>
I think
<br>
class "marcslaptop_Vista_Class" {
<br>
match if ((substring(option vendor-class-identifier, 0, 4) = "MSFT")
and
<br>
(hardware=1:0:1a:73:55:7d:f or
<br>
hardware=1:0:16:36:c2:65:a4));
<br>
would work.
<br>
<br>
<blockquote type="cite">subnet 192.168.2.0 netmask 255.255.255.0 {
<br>
default-lease-time 14400;
<br>
max-lease-time 172800;
<br>
pool {allow members of "marcslaptop_Linux_Class"; range
192.168.2.10;}
<br>
pool {allow members of "marcslaptop_Vista_Class"; range
192.168.2.15;}
<br>
pool {allow members of "nova_Linux_Class"; range 192.168.2.20;}
<br>
pool {allow members of "nova_XP_Class"; range 192.168.2.25;}
<br>
pool {allow members of "darkstar_2000_Class"; range 192.168.2.35;}
<br>
pool {allow members of "stephslaptop_Vista_Class"; range
192.168.2.45;}
<br>
pool {allow members of "teraserver_Class"; range 192.168.2.50;}
<br>
pool {
<br>
deny members of "marcslaptop_Linux_Class";
<br>
deny members of "marcslaptop_Vista_Class";
<br>
deny members of "nova_Linux_Class";
<br>
deny members of "nova_XP_Class";
<br>
deny members of "darkstar_2000_Class";
<br>
deny members of "stephslaptop_Vista_Class";
<br>
deny members of "teraserver_Class";
<br>
deny known-clients;
<br>
allow all clients;
<br>
range 192.168.2.101 192.168.2.199;}
<br>
}
<br>
<br>
There are a few things of note in the pool declaration for the final
pool segment that assigns IP addresses to unknown clients.
<br>
<br>
1. I added the deny members of "class" statements to prevent an IP
address assignment to a client which activates a second interface. This
requirement surprised me, but it seems to work.
<br>
</blockquote>
<br>
Why surprised ? Unless you specify that a client should not be allowed
to use a pool, then it can use a pool. It is deliberate that allowing
it in one pool doesn't exclude it from others as that would create just
as many complaints.
<br>
<br>
<blockquote type="cite">3. The allow all clients statement is a guess
on my part, as nothing is said about precedence of configuration
statements in the documentation. But my guess is that this will allow
assignment of an IP address to all unknown clients without my having to
specify all clients on my network with host statements. If this won't
work, and I have to use the allow unknown clients statement instead,
then I would be right back to where I started from, having to specify
hosts declarations, which I am trying to get around due to their
inadequate capabilities. I have not yet fully tested this to my
satisfaction, but initial trials seem to indicate it works....
<br>
</blockquote>
<br>
That is an area that could do with improvement, and it comes up fairly
frequently. Mixing allow and deny is generally advised against as it
does NOT give the results most people expect - specifically the allow
and deny statements are NOT processed linearly.
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</body>
</html>