[Dnsmasq-discuss] Test release with tag-if support (was IP address based on switch port number (option 82))

[richardvoigt at gmail.com]

On Sat, Feb 20, 2010 at 5:04 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> richardvoigt at gmail.com wrote:
>>
>> Resending this e-mail because it's very relevant to the broken
>> behavior noted by Ignacio in the test release.
>>
>>>> Ignacio, why not configure you switch to relay all ports? Then you can
>>>> block broadcasts without problems. You don't have to have special
>>>> configuration in dnsmasq for all the ports, it will do boring dynamic
>>>> address allocation fine on relayed requests. (Remember that the netmask
>>>> is not option in dhcp-range lines used by clients behind a relay.)
>>>>
>>>> Michael: the change I was thinking of should be completely transparent
>>>> in all other situations except this. It just inhibits filtering of
>>>> available dhcp-ranges by tag on a unicast DHCP renewal. Since by that
>>>> time a lease will exist and the address is known, at most one dhcp-range
>>>> can match anyway.
>>
>> I don't think this is a solution.  If you moved a station between
>> ports, it would renew the address assigned to the old port, which both
>> doesn't meet the OP's stated requirement and leaves the next device
>> connected to the old port with no available address.
>>
>
> True, but if it's not possible to arrange for the relay to behave as a full
> proxy, there's no choice, since there's no way to make unicast renewals
> work.
>
> In the absence of server-id-override support in the relay, it might be
> possible to implement it wholly in the server: the server-id code could be
> configure to always use the address of the relay as server-id, and get the
> same effect.
>

If you implement something like that, I'd suggest that the behavior of
forcing server-id-override (--relay-masquerade perhaps) be applicable
either to all relays or to only some leases based on matching the
relay IP address against an explicit list (optional parameter to the
config line).  Allowing tag matching conditions is probably not
necessary, but would be more consistent.

> If that works, there would be no need for modified behaviour on unicast
> renewal.
>
> Cheers,
>
> Simon.