How about this. A device showing up with an LAA gets tagged twice. Always with an "laa" tag, but also with one of "laa-unicast" or "laa-multicast".
If someone wanted to block devices, it would be easy with # Block all LAA-presenting devices dhcp-ignore=tag:laa # Block unicast LAA-presenting devices dhcp-ignore=tag:laa-unicast diff --git a/src/rfc2131.c b/src/rfc2131.c index fc54aab..b9da511 100644 --- a/src/rfc2131.c +++ b/src/rfc2131.c @@ -93,7 +93,7 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index, unsigned char *agent_id = NULL, *uuid = NULL; unsigned char *emac = NULL; int vendor_class_len = 0, emac_len = 0; - struct dhcp_netid known_id, iface_id, cpewan_id; + struct dhcp_netid known_id, iface_id, cpewan_id, laa_id, laa_cast_id; struct dhcp_opt *o; unsigned char pxe_uuid[17]; unsigned char *oui = NULL, *serial = NULL; @@ -114,6 +114,32 @@ size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int int_index, if (mess->htype == 0 && mess->hlen != 0) return 0; + /* Check if sender has a Locally-Administered ethernet Address and set a tag if so. */ + if (mess->htype == ARPHRD_ETHER) + { + /* Locally Administered Addresses (LAA) have the 2nd LSb of the first address byte set */ + if ((mess->chaddr[0] & 2) == 2) + { + laa_id.net = "laa"; + laa_id.next = netid; + netid = &laa_id; + + /* Check if this is a unicast or multicast LAA. Also set a tag + for the type of LAA. So a device with an LAA will have two tags + "laa" and either "laa-multicast" or "laa-unicast" */ + if ((mess->chaddr[0] & 1) == 1) + { + laa_cast_id.net = "laa-multicast"; + } + else + { + laa_cast_id.net = "laa-unicast"; + } + laa_cast_id.next = netid; + netid = &laa_cast_id; + } + } + /* check for DHCP rather than BOOTP */ if ((opt = option_find(mess, sz, OPTION_MESSAGE_TYPE, 1))) { -----Original Message----- From: Dnsmasq-discuss <dnsmasq-discuss-boun...@lists.thekelleys.org.uk> On Behalf Of themiron...@gmail.com Sent: July 26, 2020 8:04 AM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address Hi, LAA stands for locally-administrated address itself, so from my opinion "laa-address" is a bit tautologic. Let's use just "laa", also it ~fits already used one word tags: "bootp" "cpewan-id" "dhcpv6" "known" "known-othernet" <interface> -- Best Regards, Vladislav Grishenko -----Original Message----- From: Dnsmasq-discuss <dnsmasq-discuss-boun...@lists.thekelleys.org.uk> On Behalf Of Pali Rohar Sent: Sunday, July 26, 2020 7:20 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address On Sunday 26 July 2020 15:35:24 Geert Stappers wrote: > On Sun, Jul 26, 2020 at 06:07:52AM -0700, d...@lutean.com wrote: > > > > iOS 14 > > > > > > CISCO provides an IOS, https://en.wikipedia.org/wiki/Cisco_IOS > > > My second guess on IOS is an Apple Computer Inc product. > > > > > > > > > > will by default use randomized, private MAC addresses. > > > > > > Yeah right, let's sell a depleted MAC address pool as a privacy > > > improvement ... > > > > > > > It is an upcoming feature of Apple products that will be on by > > default: https://support.apple.com/en-ca/HT211227 Ah :-( So Apple devices would be broken on lot of networks. Another reason why to not buy them. I heard from lot of people that they are not supporting Apple devices on networks anymore and I now I'm seeing reasons for such decisions. Maintaining such crap must be really pain. > > It is already available through the public beta. > > > > So Apple devices as of October or sooner will be changing their MAC > > addresses by default > > > > > > > > > In my testing these devices use a MAC address with the LAA bit > > > > set (2nd least significant bit of the first byte of the MAC). It > > > > restricts this to host addresses (least significant bit is set to 0). > > > > > > Speaks about two bits > > > > > > > > > > This patch detects MAC addresses with this bit set and tags the > > > > request with the tag "laa-address". This would allow other rules > > > > to decide what to do with these requests (such as ignoring them). > > > > > > Speaks about one bit > > > > > > > > > > > > Speaking about bits, see > > https://en.wikipedia.org/wiki/MAC_address#/media/File:MAC-48_Address > > .svg > > > for the "exploded view" > > > > > > > https://en.wikipedia.org/wiki/MAC_address#Unicast_vs._multicast > > > > The reason two bits are tested is because: > > - one bit is the UAA / LAA bit > > - one bit is the unicast / multicast bit > > > > so this patch wouldn't tag LAA multicast MAC addresses should those > > happen to be in use somewhere. > > > > So specifically a device with an LAA unicast MAC address would get a > > tag. This requires testing two bits. > > > > OK, thanks for elaborating I think that big misunderstanding comes from commit message which says that one bit (LAA) is tested, but in patch itself are tested two bits. I guess that fixing commit message to properly describe that testing both bits (and which) are needed should be enough. Anyway, I'm not sure if 'laa-address' is correct name if it is not set for every laa-address, but only for unicast laa-address. -- Pali Rohár pali.ro...@gmail.com _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss