Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
> Thanks! > > Do I understand correctly, in order to ignore "laa-unicast" MACs, a user would define this ? > > # Block unicast LAA-presenting devices > dhcp-ignore=tag:laa,tag:!multicast Yes, that would work. Although it is by no means clear to me that it makes sense to accept a DHCP request from a device with a LAA multicast address. > > Lonnie > > BTW, here is a good article on this "Random MAC Address" topic: > https://community.cisco.com/t5/security-documents/random-mac-address-how-to- deal-with-it-using-ise/ta-p/4049321 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
Hi everyone,
The following proposed patch includes my attempt at a man page change. It also
includes Vladislav Grishenko's suggestion to tag LAA source addresses
independently from multicast addresses.
If these changes are acceptable, I propose the following commit message:
DHCP requests from ethernet MAC addresses that have either the Locally
Administered Address flag set or the multicast flag set automatically get
tagged with "laa" and "multicast" respectively before further processing.
Todd Sankey
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -2152,9 +2152,24 @@ include set:, including one from the
.B --dhcp-range
used to allocate the address, one from any matching
.B --dhcp-host
-(and "known" or "known-othernet" if a \fB--dhcp-host\fP matches)
-The tag "bootp" is set for BOOTP requests, and a tag whose name is the
-name of the interface on which the request arrived is also set.
+In addition, several tags may be applied automatically. These are:
+.PP
+.B - "known"
+if a \fB--dhcp-host\fP matches and it is being used
+.PP
+.B - "known-othernet"
+if a \fB--dhcp-host\fP matches but it cannot be used because it does not apply
on the network the request was received on
+.PP
+.B - "bootp"
+if the request is a BOOTP request
+.PP
+.B - "laa"
+if the request source MAC address is a Locally Administered Address
+.PP
+.B - "multicast"
+if the request source MAC address is a multicast address
+.PP
+- the name of the interface on which the request arrived.
Any configuration lines which include one or more tag: constructs
will only be valid if all that tags are matched in the set derived
diff --git a/src/rfc2131.c b/src/rfc2131.c
index fc54aab..4358b52 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, multicast_id;
struct dhcp_opt *o;
unsigned char pxe_uuid[17];
unsigned char *oui = NULL, *serial = NULL;
@@ -114,6 +114,30 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
if (mess->htype == 0 && mess->hlen != 0)
return 0;
+ /* Ethernet addresses have 2 special bits, the 2 LSbs of the first address
byte.
+ Check those 2 special bytes and tag DHCP requests from devices for the
unusual
+ cases of these 2 bits. */
+ if (mess->htype == ARPHRD_ETHER && (mess->chaddr[0] & 3))
+ {
+/* Check if sender has a Locally-Administered ethernet Address and set a
tag if so. */
+/* 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 = _id;
+}
+
+/* Check if sender has a multicast ethernet and set a tag if so. */
+/* Multicast addresses have the LSb of the first address by set. Set a tag
it multicast. */
+if ((mess->chaddr[0] & 1) == 1)
+{
+ multicast_id.net = "multicast";
+ multicast_id.next = netid;
+ netid = _id;
+}
+ }
+
/* check for DHCP rather than BOOTP */
if ((opt = option_find(mess, sz, OPTION_MESSAGE_TYPE, 1)))
{
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
> On Jul 27, 2020, at 1:12 PM, d...@lutean.com wrote: > > Hi everyone, > > The following proposed patch includes my attempt at a man page change. It > also includes Vladislav Grishenko's suggestion to tag LAA source addresses > independently from multicast addresses. > > If these changes are acceptable, I propose the following commit message: > > DHCP requests from ethernet MAC addresses that have either the Locally > Administered Address flag set or the multicast flag set automatically get > tagged with "laa" and "multicast" respectively before further processing. > > Todd Sankey Thanks! Do I understand correctly, in order to ignore "laa-unicast" MACs, a user would define this ? # Block unicast LAA-presenting devices dhcp-ignore=tag:laa,tag:!multicast Lonnie BTW, here is a good article on this "Random MAC Address" topic: https://community.cisco.com/t5/security-documents/random-mac-address-how-to-deal-with-it-using-ise/ta-p/4049321 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
On 7/27/2020 8:12 PM, d...@lutean.com wrote:
Hi everyone,
The following proposed patch includes my attempt at a man page change. It also
includes Vladislav Grishenko's suggestion to tag LAA source addresses
independently from multicast addresses.
If these changes are acceptable, I propose the following commit message:
DHCP requests from ethernet MAC addresses that have either the Locally Administered Address flag
set or the multicast flag set automatically get tagged with "laa" and
"multicast" respectively before further processing.
Todd Sankey
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -2152,9 +2152,24 @@ include set:, including one from the
.B --dhcp-range
used to allocate the address, one from any matching
.B --dhcp-host
-(and "known" or "known-othernet" if a \fB--dhcp-host\fP matches)
-The tag "bootp" is set for BOOTP requests, and a tag whose name is the
-name of the interface on which the request arrived is also set.
+In addition, several tags may be applied automatically. These are:
+.PP
+.B - "known"
+if a \fB--dhcp-host\fP matches and it is being used
+.PP
+.B - "known-othernet"
+if a \fB--dhcp-host\fP matches but it cannot be used because it does not apply
on the network the request was received on
+.PP
+.B - "bootp"
+if the request is a BOOTP request
+.PP
+.B - "laa"
+if the request source MAC address is a Locally Administered Address
+.PP
+.B - "multicast"
+if the request source MAC address is a multicast address
+.PP
+- the name of the interface on which the request arrived.
Any configuration lines which include one or more tag: constructs
will only be valid if all that tags are matched in the set derived
diff --git a/src/rfc2131.c b/src/rfc2131.c
index fc54aab..4358b52 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, multicast_id;
struct dhcp_opt *o;
unsigned char pxe_uuid[17];
unsigned char *oui = NULL, *serial = NULL;
@@ -114,6 +114,30 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
if (mess->htype == 0 && mess->hlen != 0)
return 0;
+ /* Ethernet addresses have 2 special bits, the 2 LSbs of the first address
byte.
+ Check those 2 special bytes and tag DHCP requests from devices for the
unusual
+ cases of these 2 bits. */
+ if (mess->htype == ARPHRD_ETHER && (mess->chaddr[0] & 3))
+ {
+/* Check if sender has a Locally-Administered ethernet Address and set a
tag if so. */
+/* 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 = _id;
+}
+
+/* Check if sender has a multicast ethernet and set a tag if so. */
+/* Multicast addresses have the LSb of the first address by set. Set a tag
it multicast. */
+if ((mess->chaddr[0] & 1) == 1)
+{
+ multicast_id.net = "multicast";
+ multicast_id.next = netid;
+ netid = _id;
+}
+ }
+
/* check for DHCP rather than BOOTP */
if ((opt = option_find(mess, sz, OPTION_MESSAGE_TYPE, 1)))
{
I think that it would be wise to wait for input from the maintainer of
Dnsmasq (Simon Kelley ).
--
John Doe
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
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 On
Behalf Of d...@lutean.com
Sent: Monday, July 27, 2020 12:38 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
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 = _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 = _cast_id;
+}
+ }
+
/* check for DHCP rather than BOOTP */
if ((opt = option_find(mess, sz, OPTION_MESSAGE_TYPE, 1)))
{
-Original Message-
From: Dnsmasq-discuss 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"
--
Best Regards, Vladislav Grishenko
-Original Message-----
From: Dnsmasq-discuss 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 alread
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 = _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 = _cast_id;
+}
+ }
+
/* check for DHCP rather than BOOTP */
if ((opt = option_find(mess, sz, OPTION_MESSAGE_TYPE, 1)))
{
-Original Message-
From: Dnsmasq-discuss 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"
--
Best Regards, Vladislav Grishenko
-Original Message-
From: Dnsmasq-discuss 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
> >
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
On Sun, Jul 26, 2020 at 12:37:32PM -0700, d...@lutean.com wrote:
> From: Vladislav Grishenko Sent: July 26, 2020 8:04 AM
> > From: Pali Rohar Sent: Sunday, July 26, 2020 7:20 PM
> > 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:
> > > > On Sunday 26 July 2020 Geert Stappers wrote:
> > > > > On Sun, Jul 26, 2020, d...@lutean.com wrote:
> > > > > >
> > > > > > > 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.
> > >
> >
> > 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"
> >
> >
> 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 = _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 = _cast_id;
> +}
> + }
> +
>/* check for DHCP rather than BOOTP */
>if ((opt = option_find(mess, sz, OPTION_MESSAGE_TYPE, 1)))
> {
That revisited patch solves the main problem I had with previous
version.
I think the next version should also update the manual page
and have the verbatim text for the commit message.
Groeten
Geert Stappers
--
Silence is hard to parse
___
Dnsmasq-discuss mailing list
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
Greetings, So how would dnsmasq users go about not granting DHCP leases to LAA (anonymous) MAC addresses ? I liken this to a PBX not accepting calls with anonymous/invalid caller-id entries. Lonnie > On Jul 26, 2020, at 10:04 AM, themiron...@gmail.com wrote: > > 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" > > -- > Best Regards, Vladislav Grishenko > > -Original Message- > From: Dnsmasq-discuss 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
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
> > 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 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. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
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" -- Best Regards, Vladislav Grishenko -Original Message- From: Dnsmasq-discuss 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
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
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
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 > > 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 Groeten Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Tag requests for a DHCP address from devices using a Locally Administered MAC address
On Sat, Jul 25, 2020 at 09:01:51AM -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 ...
> 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"
> --- 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;
>struct dhcp_opt *o;
>unsigned char pxe_uuid[17];
>unsigned char *oui = NULL, *serial = NULL;
> @@ -114,6 +114,18 @@ 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)
> + {
> +/* LAA host addresses have the the LSbs of the first address byte set to
> b'10' */
> +if ((mess->chaddr[0] & 3) == 2)
> +{
> + laa_id.net = "laa-address";
> + laa_id.next = netid;
> + netid = _id;
> +}
> + }
> +
>/* check for DHCP rather than BOOTP */
>if ((opt = option_find(mess, sz, OPTION_MESSAGE_TYPE, 1)))
> {
>
Main problem I have with the patch is that it checks on two bits
and uses the name of one bit.
Patch reviewed and rejected by me.
Groeten
Geert Stappers
--
Silence is hard to parse
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
