I just checked how openbsd dhcpd handles this:
subnet 10.10.10.0 netmask 255.255.255.0 {
option routers 20.10.10.1;
range 10.10.10.10 10.10.10.50;
}
It starts fine and happily sends unusable configuration to client.
dhcpcd (dhcp client I use on linux-based client) installed fun
Here's a new diff that removes the duplicate parsing bits as mentioned
before but leaves masking the address to mask_addr() instead of doing it
manually.
Furthermore, it also stops route(8) from assuming address strings
without explicit prefix length to be /64.
The old behaviour described in RFC
Rob Pierce(r...@2keys.ca) on 2018.06.10 13:25:23 -0400:
> This brings snmpd agentx.c closer to relayd agentx.c.
>
> In the remaining delta, I am not sure if the pdu context code should be
> removed
> from the snmpd version or added to the relayd version.
>
> Anyway, this is one step closer.
>
>
Another approach is to extend subnet by decreasing mask to include router to
client subnet.
I.e.: 10.112.38.73/16.
dhcp-options(5), RFC-2132: "The router option specifies a list of IP
addresses for routers on the client's subnet."
>From my point of view dhcp server in your example violates RFC,
On Sat, Jun 09, 2018 at 02:10:09PM +0200, Claudio Jeker wrote:
> On Sat, Jun 09, 2018 at 01:31:20PM +0200, Martin Pieuchot wrote:
> > On 08/06/18(Fri) 18:06, Kenneth R Westerback wrote:
> > > Testing at the alternate DHCP lab (the one that serves beer) I find
> > > that its wifi gives me the lease
This brings snmpd agentx.c closer to relayd agentx.c.
In the remaining delta, I am not sure if the pdu context code should be removed
from the snmpd version or added to the relayd version.
Anyway, this is one step closer.
Ok?
Rob
Index: agentx.c
