[klibc] PATCH: ipconfig may discard useful packets

[Άλκης]

Στις 08-10-2008, ημέρα Τετ, και ώρα 13:48 +0200, ο/η maximilian attems
έγραψε:
> that be the perfect 1 round, looking forward to those patches :D

I've already implemented a custom patch for personal use back in June
(it needed less than 10 lines). Anyway, I'd better do this the right
way, I do have some free time this week. Also, I think I still see some
weird delays (in my labs) that need debugging (both in the original +
modified version).


So, (many) thoughts & (simple) proposal:
----------------------------------------
An administrator may need ipconfig to select one out of many dhcp
servers, based on these criteria:
1. An option existance, like dhclient "require":
     require [ option ] [, ... option ];
     The require statement lists options that must be sent in order
     for an offer to be accepted. Offers that do not contain all the
     listed options will be ignored.
This way, I could easily run "ipconfig -require 67" to require a
bootfile name, and that would solve my LTSP labs problem.
Another administrator might want to *prefer* a dhcp server that
specifies this option, but not *require* it (i.e. completely ignore
other offers).

2. A best value for one option, something like gpxe.priority, which is
an integer, and the client selects the server offering the highest
value.
So for LTSP labs, I could tell the LTSP server to return "1" for this
option, while all other servers would return nothing (=0), and the
correct server would be selected.
In another scenario, the dhcp servers could be configured to return
their current idle CPU time in this value, so ipconfig would be able to
perform load balancing by selecting the less loaded server.
But I think implementing option comparisons in a generic way (integers,
strings etc) is too much overhead for little gain, so if you'd like me
to implement this, I would propose to only look for the highest value
for a specific (=constant) integer option, like gpxe does. The admin
could take care of the rest with dhcp server scripts.

3. An option matching, e.g. the administrator might need some dhcp
clients to select the server with server identifier = 0xe3f83adb
(=option 54).


*. Another thing an administrator might want to have control over, is
how much the client will wait until the dhcp offer collecting state is
over.
I don't think this is really important, it can be constant = 1 sec.


Proposal:
---------
I'd like to only implement (2), I think it's the most powerful and
simple implementation, and it doesn't need *any* new command line
parameters.
So I'll be defining
  #define IPCONFIG_DHCP_OPTION 176
and in /etc/dhcpd.conf an administrator would do
  option space ipconfig;
  option ipconfig-encap-opts code 176 = encapsulate ipconfig;
  option ipconfig.priority code 1 = signed integer 8;

  option ipconfig.priority 1;

Also, I'll be modifying ipconfig to wait for 1 second to collect offers,
always keeping the one with the higher ipconfig.priority value.
If you like, I may put a command line option for how much to wait (or
don't wait at all if not defined), but I don't think it's necessary.

Peter, are you interested in any of these?

Kind regards,
Alkis Georgopoulos