[Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
themiron.ru at gmail.com
themiron.ru at gmail.com
Mon Jul 27 11:16:01 BST 2020
Hi,
What if just test and tag "laa" independently from "unicast"/"multicast"?
The thing is, LAA bit presence is pretty valid for unicast and multicast both, and taking into account DHCP & Eth nature, chaddr should always be unicast here. If not (and it still works somehow)- I can see at the moment no point to omit such "mcast" clients from laa processing.
Also, before testing and setting laa tags mess->htype and mess->hlen needs to be checked against ARPHDR_ETHER / ETHER_ADDR_LEN, or there will be no guarantee tag is set correctly for other address types.
--
Best Regards, Vladislav Grishenko
-----Original Message-----
From: Dnsmasq-discuss <dnsmasq-discuss-bounces at lists.thekelleys.org.uk> On Behalf Of dev at lutean.com
Sent: Monday, July 27, 2020 12:38 AM
To: dnsmasq-discuss at lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
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-bounces at lists.thekelleys.org.uk> On Behalf Of themiron.ru at gmail.com
Sent: July 26, 2020 8:04 AM
To: dnsmasq-discuss at 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-bounces at lists.thekelleys.org.uk> On Behalf Of Pali Rohar
Sent: Sunday, July 26, 2020 7:20 PM
To: dnsmasq-discuss at 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, dev at 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.rohar at gmail.com
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss at lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss at lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss at lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
More information about the Dnsmasq-discuss
mailing list