[Dnsmasq-discuss] using DHCP with virtual interfaces

[dnsmasq at lists.bod.org]

Perhaps a dnsmasq wiki? (not a free-for-all, one where only people Simon 
has approved can edit).

I'm guessing there's a handful of people that'd be willing to contribute 
back by adding to the documentation, howto/recipe-type info, etc. I know 
I've learned much about dnsmasq from reading posts on the list, be nice 
to capture it somewhere.

-- Paul

Simon Kelley wrote:
> Tom Metro wrote:
>> Simon Kelley wrote:
>>> The behaviour WRT to MAC addresses and client-identifiers is 
>>> mandated by
>>> the DHCP standards, which don't allow the server to assume identify
>>> between two hosts with different MAC addresses or client-ids based on
>>> the hostname it supplies.
>> Ah, OK. I wasn't aware of that. I suspect most casual users of DHCP 
>> wouldn't be either. Superficially the two attributes seem like they 
>> should be interchangeable (in terms of their impact on the IP address 
>> selection decision logic), and if I recall correctly the man page 
>> doesn't say otherwise.
>>
>> I'd like to offer a documentation patch to correct for that, but I'm 
>> not sure if tacking another paragraph onto the dhcp-host 
>> documentation is the best place for it. I'm wondering if something 
>> more like a "theory of operation" section, which could then document 
>> the full set of steps Dnsmasq uses to get from discover to offer, 
>> would be the better way to go. Sure, it's going to be largely 
>> redundant with what's in the RFC, but  it'll be documenting things 
>> specific to the Dnsmasq implementation as well.
>>
>> I see the man page already has a few paragraphs near the end covering 
>> network-id, which is a portion of the DHCP decision logic. This patch 
>> would probably involve reorganizing the notes section, renaming it 
>> something like OPERATION, giving DNS and DHCP their own sub-headings, 
>> and putting the signal behaviors under their own SIGNALS heading.
>>
>> Would this approach make sense? I could take a stab at a first draft 
>> for it, using the RFC as guidance, but I'd be dependent on you to 
>> refine it to be Dnsmasq-specific.
>
> I'm well aware that the documentation for dnsmasq could be improved, 
> and that sounds like a good strategy. I'm certainly willing to do my bit.
>
> Cheers,
>
> Simon.
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss