Discussion:
DHCP vs RARP?
(too old to reply)
Mouse
2021-09-05 12:52:34 UTC
Permalink
In the 1.4T days, my netboot setup usually used RARP to assign
addresses. (Still does, for the ROM-code stage of some of my
machines, and for the occasional case where I netboot 1.4T.)

I recently tried to run something newer on one of my SPARCs. The 1.4T
netboot bootblock crashed trying to load the newer kernel, so I tried a
bootblock from the same vintage as the kernel. The newer bootblock
code uses DHCP isntead of RARP to get its address.

But my /etc/ethers had a long list of MACs that all got the same IP, so
I could netboot the same diskless setup on whichever hardware I'm
trying to use at the moment:

08:00:20:00:85:81 10.0.1.11
08:00:20:02:b5:60 10.0.1.11
08:00:20:03:a1:f4 10.0.1.11
08:00:20:08:02:44 10.0.1.11
08:00:20:09:59:34 10.0.1.11
08:00:20:0a:1e:95 10.0.1.11
08:00:20:0b:cd:c7 10.0.1.11
...etc.

When I convert this to a dhcpd.conf clause with multiple "hardware
ethernet" lines, it doesn't work. I don't see any obvious complaints
anywhere, but dhcpd hands out an address as if it didn't recognize the
hardware address. (It might work if the address is the first in the
list, or the last, or some such; I haven't experimented that much.)

The dhcpd in question is relatively old ("isc-dhcp-V3.0.3", according
to the leases file - I don't know where else to get a version number
for it from). Would this be fixed by importing a newer dhcpd, or is it
another case of software being improved until it can't do what used to
be easy?

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Pierre-Philipp Braun
2021-09-05 13:47:11 UTC
Permalink
Hello der Mouse
Post by Mouse
When I convert this to a dhcpd.conf clause with multiple "hardware
ethernet" lines, it doesn't work. I don't see any obvious complaints
anywhere, but dhcpd hands out an address as if it didn't recognize the
hardware address. (It might work if the address is the first in the
list, or the last, or some such; I haven't experimented that much.)
is the syntax for every host/mac alright e.g. as follows, including the
trailing line separator?

host SHORT {
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address x.x.x.x;
}

there's a point about sorting the hardware addresses in the 3.0 branch
release notes line 221 *1, and that's for 3.0.5. Maybe that's it?

```
- The server's "by client-id" and "by hardware address" hash table lists
are now sorted according to the preference to re-allocate that lease to
returning clients. This should eliminate pool starvation problems
arising when "INIT" clients were given new leases rather than presently
active ones.
```

*1 https://github.com/alandekok/isc-dhcp-3.0/blob/master/RELNOTES
Post by Mouse
/~\ The ASCII Mouse
\ / Ribbon Campaign
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mouse
2021-09-05 21:52:32 UTC
Permalink
Post by Pierre-Philipp Braun
Post by Mouse
When I convert this to a dhcpd.conf clause with multiple "hardware
ethernet" lines, it doesn't work. I don't see any obvious
complaints anywhere, but dhcpd hands out an address as if it didn't
recognize the hardware address.
is the syntax for every host/mac alright
As far as I can tell it is. They are all formatted the same way (not
surprising, since I generated it mechanically from /etc/ethers), and
commenting out all but one (and restarting dhcpd) makes it work for
that one.
Post by Pierre-Philipp Braun
there's a point about sorting the hardware addresses in the 3.0
branch release notes line 221 *1, and that's for 3.0.5. Maybe that's
it?
Maybe, though I'm inclined to doubt it. I actually was surprised I
didn't get errors upon including multiple `hardware ethernet' clauses.

I'll have to dig into this more at some point.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mouse
2021-09-05 23:26:14 UTC
Permalink
Post by Robert Elz
It sounds as if you might be doing (to start with the example in the
dhcpd man page)
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
hardware ethernet 08:00:12:33:45:66;
hardware ethernet 08:00:ff:ee:dd:b0;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}
Yes, that's exactly the sort of thing I'm doing.
Post by Robert Elz
I actually was surprised I didn't get errors upon including multiple
`hardware ethernet' clauses.
Generating an error for multiple mac addr specs is one possibility,
simply discarding earlier ones and using the last encountered is another.
Replicating most of the declaration just to make up for deficiencies in
the parser is...aesthetically offensive, is perhaps the best short
description. (It's also annoyingly tedious to add a new address to.)

If I end up doing much that depends on DHCP-assigned diskless booting
addresses, I'll probably fix this at some point. (I had a look at the
code and it's too much of a twisty maze for me to fix it quickly. But
I'm confident that, by adding some debugging code and running further
tests, I can figure it out.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mike Pumford
2021-09-07 18:32:18 UTC
Permalink
Post by Mouse
Post by Robert Elz
It sounds as if you might be doing (to start with the example in the
dhcpd man page)
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
hardware ethernet 08:00:12:33:45:66;
hardware ethernet 08:00:ff:ee:dd:b0;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}
Yes, that's exactly the sort of thing I'm doing.
You can just have multiple host entries with the same IP e.g

host haagen-1 {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}
host haagen-2 {
hardware ethernet 08:00:12:33:45:66;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}

That's what I do for hosts that have wifi and ethernet connections.

Mike

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Robert Elz
2021-09-06 15:15:51 UTC
Permalink
Date: Sun, 5 Sep 2021 19:26:14 -0400 (EDT)
From: Mouse <***@Rodents-Montreal.ORG>
Message-ID: <***@Stone.Rodents-Montreal.ORG>

| Replicating most of the declaration just to make up for deficiencies in
| the parser is...aesthetically offensive,

It isn't a deficiency, it is a design choice, in general it is much
more flexible.

| (It's also annoyingly tedious to add a new address to.)

It actually isn't, it is easier - the way you'r trying to do it you need
to add a new line into the middle of the file (and pick the right place
to do it, in case you have several different groups like this).

The way it is, all you do is

printf 'host foo%d { hardware ethernet %s; fixed-address 1.2.3.4; }' \
$((++foocount)) "${macaddr+" >> config-file

which is much simpler - stick that in a script (or sh function) which
works out an initial value for foocount from what is already in the
file, and all you need to do is

addmac 22:33:44:55:66:77

or perhaps
addmac foo 22:33:44:55:66:77
and parameterise a bit more, so it can handle multiple different groupings
more easily.

Put a loop around the printf, and you can add as many mac addrs in one
command line as you like. [And of course, add \t and \n into the printf
format string to make the results be whatever format you like best.]

| If I end up doing much that depends on DHCP-assigned diskless booting
| addresses, I'll probably fix this at some point.

Don't. I used to dislike this kind of config when I first encountered
it (in some ancient bind perhaps) but with more experience I realise
just how much better it is than the old way.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Mouse
2021-09-06 15:52:45 UTC
Permalink
Post by Robert Elz
Post by Mouse
Replicating most of the declaration just to make up for deficiencies
in the parser is...aesthetically offensive,
It isn't a deficiency, it is a design choice, in general it is much
more flexible.
Eh. Explain how it's more flexible to support only style XYZ as
compared to supporting both style XYZ and style ABC?
Post by Robert Elz
Post by Mouse
(It's also annoyingly tedious to add a new address to.)
It actually isn't, it is easier - the way you'r trying to do it you
need to add a new line into the middle of the file (and pick the
right place to do it, in case you have several different groups like
this).
The way it is, all you do is
printf 'host foo%d { hardware ethernet %s; fixed-address 1.2.3.4; }' \
$((++foocount)) "${macaddr+" >> config-file
which is much simpler
...?? Simpler, to have to compute the correct value of foocount and
figure out which template's other lines to insert into the foo%d
clause? (You're oversimplifying away the need for at least another
line or two in each clause. Maybe _your_ setup doesn't need them, but
mine is heterogenous enough that it does.)

I'd sooner throw a preprocessing step (m4, awk, whatever) around it.
Post by Robert Elz
Post by Mouse
If I end up doing much that depends on DHCP-assigned diskless
booting addresses, I'll probably fix this at some point.
Don't.
Why not? Why should I not change software to work in better ways for
the environment it's being used in?

It's not as if you have to use the result. (And, even if you did, I
don't propose to break support for the style you prefer.) It's
reasonably likely upstream wouldn't even take the changes back; I'd be
doing this to the DHCP that comes with 5.2, not ISC's latest. (I had a
look at their latest and the activation energy for my adopting it is
_way_ too high; it's drunk the ./configure koolaid. So has the one in
/usr/src/dist, but that configure script (a) is fixed and already
vetted and (b) is known to work with the system it comes with.)
Post by Robert Elz
I used to dislike this kind of config when I first encountered it (in
some ancient bind perhaps) but with more experience I realise just
how much better it is than the old way.
For your tradeoffs, perhaps, it is.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Robert Elz
2021-09-05 22:44:19 UTC
Permalink
Date: Sun, 5 Sep 2021 17:52:32 -0400 (EDT)
From: Mouse <***@Rodents-Montreal.ORG>
Message-ID: <***@Stone.Rodents-Montreal.ORG>

| As far as I can tell it is. They are all formatted the same way (not
| surprising, since I generated it mechanically from /etc/ethers), and
| commenting out all but one (and restarting dhcpd) makes it work for
| that one.

It sounds as if you might be doing (to start with the example in the
dhcpd man page)

host haagen {
hardware ethernet 08:00:2b:4c:59:23;
hardware ethernet 08:00:12:33:45:66;
hardware ethernet 08:00:ff:ee:dd:b0;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}

or something like it, rather than

host haagen1 {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}
host haagen2 {
hardware ethernet 08:00:12:33:45:6;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}
host haagen3 {
hardware ethernet 08:00:ff:ee:dd:b0;
fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
}

| I actually was surprised I
| didn't get errors upon including multiple `hardware ethernet' clauses.

Generating an error for multiple mac addr specs is one possibility,
simply discarding earlier ones and using the last encountered is another.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Edgar Fuß
2021-09-06 08:23:58 UTC
Permalink
Post by Mouse
Replicating most of the declaration just to make up for deficiencies in
the parser is...aesthetically offensive, is perhaps the best short
description. (It's also annoyingly tedious to add a new address to.)
It doen't need to be a defiency of the parser. Probably the rest of the code
needs a one-to-one relation between host and hardware-address?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Ted Lemon
2021-09-05 13:47:05 UTC
Permalink
That's how I would do it. If you want the DHCP server to enforce the lease
(that is, not give the same address out twice) you can create a class with
all the hardware addresses in it, and then a pool that is only allowed for
that class with the one address you want to share. But I'm guessing that's
more trouble than is required here.
Post by Mouse
When I convert this to a dhcpd.conf clause with multiple "hardware
ethernet" lines, it doesn't work. I don't see any obvious complaints
anywhere, but dhcpd hands out an address as if it didn't recognize the
hardware address. (It might work if the address is the first in the
list, or the last, or some such; I haven't experimented that much.)
I just use separate host entries with the same fixed-address entry which
makes for a verbose dhcpd.conf file but it works. For example:

host euclid {
hardware ethernet 00:14:22:ab:ea:b6;
fixed-address euclid;
}
host euclid-wpi {
hardware ethernet 00:13:02:8e:1e:a0;
fixed-address euclid;
}

I've never checked if there's an easier/cleaner way.

Cheers,
Simon.
Loading...