[Dnsmasq-discuss] IP address based on switch port number (option 82)
michael.rack at rsm-freilassing.de
Mon Feb 15 08:24:03 GMT 2010
Is your switch able to set the DHCP Server Identifier Override Suboption?
In my network i use this suboption to tell clients to unicast my
Relay-DHCP Server and not DNSMASQ directly. DNSMASQ supports this
I don't think thats the right place to do some changes in your
sourcecode. But a new option to enable / disable the permit of
unicast-messages without tags on renewals is welcome.
Liebe Grüße aus Freilassing,
RSM Freilassing Tel.: +49 8654 607110
Nocksteinstr. 13 Fax.: +49 8654 670438
D-83395 Freilassing www.rsm-freilassing.de
Am 14.02.2010 21:50, schrieb Simon Kelley:
> richardvoigt at gmail.com wrote:
>> On Sun, Feb 14, 2010 at 2:16 PM, Simon Kelley<simon at thekelleys.org.uk> wrote:
>>> richardvoigt at gmail.com wrote:
>>>>> I'm going to have to think about code changes to fix this in the general
>>>>> case. Are you able to compile and test new versions of dnsmasq?
>>>> ebtables or iptables can be used to match the source MAC address and
>>>> only accept inbound DHCP requests from the relay(s). No change needed
>>>> to dnsmasq.
>>> I think there's still the problem that a configured host will attempt to
>>> renew a lease by unicast direct to the DHCP server, so that the request
>>> never goes to the relay, and doesn't pick up the option-82 information.
>>> The lack of that information will make dnsmasq think that the existing
>>> address is not permitted.
>>> A simple fix would be to suppress filtering of dhcp-ranges by tags, but
>>> only for lease renewals.
>> As far as the client knows, the lease was granted by the relay, right?
>> So it would unicast to the switch with dhcp-relay capability.
> You would think so, it would certainly make life easier and make a relay
> a true proxy, so that routability between clients and server wasn't needed.
> In fact the client knows the IP address of the server from the server-id
> field, and uses that for unicast renewal.
> It sucks, but it's the standard.
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
More information about the Dnsmasq-discuss