dhcp integrated in rlm_sql

[Alan DeKok]

Stephen R. van den Berg wrote:
> Only in the definition of the "jumptable".  This in order to ensure that
> the number of entries there doesn't shift up and down with WITH_COA
> being present or not.

  That's what #ifdef's are for...

>>  The RLM_COMPONENT_DHCP code is *not* conditionally compiled.  So it's
>> still there even if you don't build with DHCP.
> 
> Yes, on purpose, to keep the "binary" interface the same.  It's extremely
> messy trying to debug compilation issues when the modules are not all
> properly rebuilt (yes, there are issues with the Makefiles too).

  I don't see why.  src/main/rules.mak ensures that all of the modules
depend on src/include/modules.h.  So any changes to that will result in
the modules being re-built.

>>  Adding RLM_COMPONENT_DHCP means that *all* of the modules need a DHCP
>> component.  That's why the modules have entries for the COA code.  It
>> initializes the array entries so that the CoA entry exist if CoA
>> enabled.  Right now, most modules don't have a DHCP entry.  This means
>> that if someone accidentally lists a module in a DHCP section, the
>> "modcall.c" code will walk off of the end of the module_t array.
> 
> Didn't I add null values in every module that didn't have it?
> Hmmm..., maybe I didn't.  What if I fixed this?

  No.  *All* of the modules need to be updated.  Every single last one.
 The patch changed only a select few.

>>  The real way to do this is to change the code to allow it to
>> dynamically register callbacks.  That requires a lot more work,
>> unfortunately.
> 
> Yes, sounds like more work than I bargained for.  Is the fix mentioned
> above enough to get it in?

  Not really, no.

>>  For now, the DHCP code works by overloading the "post-auth" section.
>> It's ugly, but it pretty much works.
> 
> Well, I tried it, but in combination with SQL it sort of didn't work.
> Was I too soon to judge?

  The SQL code doesn't do dynamic IP allocation for DHCP.  That requires
some fairly small changes to sqlippool.  That's pretty much it, IIRC.

  Alan DeKok.