On 17/09/14 21:47, Simon Kelley wrote:
> To make this work, you'd need some extra semantics, either explicit or
> implicit, to enable the old binding to be abandoned. Abandoning a
> binding is dangerous, since when it granted the lease, the server was
> promising the client exclusive use of the IP
On 17/09/14 09:49, Joachim Nilsson wrote:
> Hi Simon,
>
> I've found a little problem with how Option 82 circuit-id/remote-id
> works. Everything is fine in the below setup until I replace the client
> with a replacement unit that has a different MAC.
>
> [client]---LAN1---[dhcrelay]---LAN2--
On 17/09/14 14:05, Richard Genoud wrote:
> Left shifting int values is a undefined behaviour in C.
> So we cast explicitly in in_addr_t (uint32_t) the value to be
> shifted.
>
Both patches applied. Many thanks.
Simon.
___
Dnsmasq-discuss mailing li
Hi,
I completely agree with Joachim and have also run into this issue while
using Option-82. Also, since each lease is tied to a client identifier, I
have seen issues where the PXE client will give a different identifier
from the OS and DNSMasq will refuse to hand out the IP thinking that the
pool
The masks used to check if an address is from a local network was not
using the htonl() function, so when they where used in is_same_net(),
the address (network order) was compared to the mask (host order).
That failed for little endian machines.
Moreover, left shifting int values is a undefined b
Left shifting int values is a undefined behaviour in C.
So we cast explicitly in in_addr_t (uint32_t) the value to be
shifted.
Signed-off-by: Richard Genoud
---
src/auth.c| 2 +-
src/netlink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/auth.c b/src/auth.c
inde
Hi Simon,
I've found a little problem with how Option 82 circuit-id/remote-id
works. Everything is fine in the below setup until I replace the client
with a replacement unit that has a different MAC.
[client]---LAN1---[dhcrelay]---LAN2---[dnsmasq]
dhcp-range=subnet0,tag:!static,192.168.2
