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]
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 richard.gen...@gmail.com
---
src/auth.c| 2 +-
src/netlink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
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
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
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 list
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.
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
