macchanger - is it still working?

[Hans]

Hi folks,

I discovered, that macchanger does not change my mac-adresses at every boot, like the installation promised.

So I looked around and I found some explanations in an Ubuntu forum. This is tellingm, I need to add a systemd.service, so that this is executed at every boot:

https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-address.html 

Of course, I could do so.

However, if this is changed, because Debian is using systemd now, and macchanger is not adapted to this changes of Debian, should I file a bugreport?

Or did I miss something else, why macchanger is not working any more, something I have overseen during the years, I am uusing Debian?

It would be nice, if someone else more experienced could have a look at this and maybe verify or deny, that this is a bug.

Thanks for reading this.

Best regards

Hans

[Reco]

Hi.

On Sun, Apr 24, 2022 at 02:34:44PM +0200, Hans wrote:
> I discovered, that macchanger does not change my mac-adresses at every
> boot, like the installation promised.

Because that's disabled by default.

> So I looked around and I found some explanations in an Ubuntu forum.
> This is tellingm, I need to add a systemd.service, so that this is
> executed at every boot:
> https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-address.html
>
> Of course, I could do so.

This link only shows us that if the only thing one has is systemd then
everything will look as a systemd unit. An interesting approach to the
unit template though.

> However, if this is changed, because Debian is using systemd now, and
> macchanger is not adapted to this changes of Debian, should I file a
> bugreport?

Of course not. What you should probably do is to enable changing MACs in
/etc/default/macchanger. And probably look at
/etc/macchanger/ifupdown.sh for the implementation details.


Doing the same thing with systemd would take a drastically different
approach, involving creation of .link files.

Reco

[Hans]

Am Sonntag, 24. April 2022, 15:00:21 CEST schrieb Reco:
Hi Reco,

> Hi.
>
> On Sun, Apr 24, 2022 at 02:34:44PM +0200, Hans wrote:
> > I discovered, that macchanger does not change my mac-adresses at every
> > boot, like the installation promised.
>
> Because that's disabled by default.

Nope. The installer expicity is asking "if I want macchanger change the mac
whenever the device is activated". Yes/No, I set "Yes". Check dpkg-reconfigure
macchanger.

>
> > So I looked around and I found some explanations in an Ubuntu forum.
> > This is tellingm, I need to add a systemd.service, so that this is
> > executed at every boot:
> > https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-addres
> > s.html
> >
> > Of course, I could do so.
>
> This link only shows us that if the only thing one has is systemd then
> everything will look as a systemd unit. An interesting approach to the
> unit template though.

Yes, that is the question: Should it be added so by default?

>
> > However, if this is changed, because Debian is using systemd now, and
> > macchanger is not adapted to this changes of Debian, should I file a
> > bugreport?
>
> Of course not. What you should probably do is to enable changing MACs in
> /etc/default/macchanger. And probably look at
> /etc/macchanger/ifupdown.sh for the implementation details.
>

I rechecked, and everything is set as YES.

>
> Doing the same thing with systemd would take a drastically different
> approach, involving creation of .link files.

I know, and this should be done by the maintainer, if necessary and wanted.
>
> Reco

Best

Hans

[Andrew M.A. Cater]

Hello Hans,

I would suggest filing a bug at normal/wishlist priority against macchanger
and pointing out that you need this to work with systemd.

There are example files for writing the necessary systemd scripts: if
one of those can be readily adapted, then it should be a relatively
simple task.

With every good wish, as ever,

Andy Cater

[tv.debian]

Maybe not relevant for you, but if you are using network-manager you can
tell it to randomize your MAC address for wifi, scanning and connection:

NetworkManager.conf:Wifi.scan-rand-mac-address=
NetworkManager.conf:wifi.mac-address-randomization=

I don't know if the same option is available for ethernet.

[Hans]

Hi Andrew,

I did as you suggested. Filed a wish-report to the package.

Let's hope for the best.

Best regards

[David Wright]

So what are the contents of /etc/default/macchanger (after all,
putting ENABLE_ON_POST_UP_DOWN=YES would be interpreted as the
default, ENABLE_ON_POST_UP_DOWN=false), and what's getting logged
in /var/log/macchanger.log?

It might be worth checking when macchanger is attempting to make its
change and see how this compares with when systemd is changing the
name of the relevant interface.

> > Doing the same thing with systemd would take a drastically different
> > approach, involving creation of .link files.
>
> I know, and this should be done by the maintainer, if necessary and wanted.

BTW, looking at the package, the last entry in
/usr/share/doc/macchanger/changelog.gz is dated 2004-05-10 and the
last in /usr/share/doc/macchanger/changelog.Debian.gz 17 Jun 2018.

As you're running systemd, any reason you're avoiding using its
own method?

Cheers,
David.

[Hans]

Am Sonntag, 24. April 2022, 16:53:49 CEST schrieb David Wright:
Hi David,

> So what are the contents of /etc/default/macchanger (after all,
> putting ENABLE_ON_POST_UP_DOWN=YES would be interpreted as the
> default, ENABLE_ON_POST_UP_DOWN=false), and what's getting logged
> in /var/log/macchanger.log?
>

It is set =YES

> It might be worth checking when macchanger is attempting to make its
> change and see how this compares with when systemd is changing the
> name of the relevant interface.
>

It can be changed, whenever I set the interface to down (so that it is not in
use), thus telling me, macchanger is generally working.

> BTW, looking at the package, the last entry in
> /usr/share/doc/macchanger/changelog.gz is dated 2004-05-10 and the
> last in /usr/share/doc/macchanger/changelog.Debian.gz 17 Jun 2018.

Hmm, there are some similar bugreports related to this issue, too.
Let us hope, the mainatiner does fix them.

>
> As you're running systemd, any reason you're avoiding using its
> own method?
>

Yes, because it does not work! However, for me personally I can fix it by
editing those files myself. But I am thinking of all the other people, who
want software, that is working.

For myself, I will often find a solution, but I know a lot of people, who are
much less experienced than myself - those are in my mind (and are in the
devlopers, too, I hope).
> Cheers,
> David.

Best

Hans

[David Wright]

On Sun 24 Apr 2022 at 17:06:48 (+0200), Hans wrote:
> Am Sonntag, 24. April 2022, 16:53:49 CEST schrieb David Wright:
> Hi David,
> > So what are the contents of /etc/default/macchanger (after all,
> > putting ENABLE_ON_POST_UP_DOWN=YES would be interpreted as the
> > default, ENABLE_ON_POST_UP_DOWN=false), and what's getting logged
> > in /var/log/macchanger.log?
> >
>
> It is set =YES

Then I don't understand your problem. AFAICT, setting
ENABLE_ON_POST_UP_DOWN=YES
in /etc/default/macchanger will prevent ifupdown from running
macchanger. Then where's the bug?

I'm not in front of the machine, of course, so I can't choose
to look at anything I would like to. So, in the absence of
being told what's logged, I guess I'll draw the conversation
to a close.

> > It might be worth checking when macchanger is attempting to make its
> > change and see how this compares with when systemd is changing the
> > name of the relevant interface.
> >
> It can be changed, whenever I set the interface to down (so that it is not in
> use), thus telling me, macchanger is generally working.
> > BTW, looking at the package, the last entry in
> > /usr/share/doc/macchanger/changelog.gz is dated 2004-05-10 and the
> > last in /usr/share/doc/macchanger/changelog.Debian.gz 17 Jun 2018.
>
> Hmm, there are some similar bugreports related to this issue, too.
> Let us hope, the mainatiner does fix them.
> >
> > As you're running systemd, any reason you're avoiding using its
> > own method?
> >
>
> Yes, because it does not work!

Systemd, or macchanger? In case I was unclear, systemd's own method
is to put MACAddressPolicy=random into a .link file. I wondered why
you don't use systemd's (sole, individual, unaided) method. Or does
that not work?

OTOH are you saying that the /combination/ of systemd driving macchanger
does not work? (That's why I asked about the timings earlier.)

As an example, it's well known that systemd and iwd, both set up to
perform "natively", create a race condition, mitigated by a systemd
.link file.

Now, I don't know how macchanger deals with any such possibility
(and, quite frankly, I don't really care either), but I'm not going
to figure it out remotely, am I. So while macchanger is apparently
configured not to run, as I said, I'll leave.

> However, for me personally I can fix it by
> editing those files myself. But I am thinking of all the other people, who
> want software, that is working.
>
> For myself, I will often find a solution, but I know a lot of people, who are
> much less experienced than myself - those are in my mind (and are in the
> devlopers, too, I hope).

Experienced bug reporters post the facts, rather than their
interpretation of those facts.

Cheers,
David.

[Hans]

Hi David,
ok, let us close this issue.

Well, I was unprecise, it was set to =true , not YES.

However, I purged and reinstralled macchanger and when the installer asked me,
if want the macaddress changed everytime the interface gets active, I chose
"yes".

Ok, my fault, I should have checked /etc/default/macchanger, but "true" in my
sense is "yes, change it!". That true means "no, do nothing!" I wasn't aware.

Sorry my fault. I also looked at some doc, which explained more, but didn't
find any, but changelog* and copyright.
My fault, too.

> Experienced bug reporters post the facts, rather than their
> interpretation of those facts.

Sorry for the noise.
>
> Cheers,
> David.

I will find my solutions myself, next time, and not to try to help others,
when I see, something is looking fishy.

Sorry for wasting your time!

Hans

[Reco]

Hi.

On Sun, Apr 24, 2022 at 03:23:55PM +0200, Hans wrote:

> I rechecked, and everything is set as YES.

And that's the source of your problem, believe it or not.

Because what /etc/macchanger/ifupdown.sh does is it explicitly checks
for "true" value:

if [ "$ENABLE_ON_POST_UP_DOWN" != "true" ]; then
echo "disabled in /etc/default/${package}" >> $LOGFILE
exit
fi

Anything else, be it "TRUE", "YES" or "y" is considered "disabled" by
that check.


Now if "YES" appeared in /etc/default/macchanger by means of running
debconf - that's a bug in the package. Either debconf template or
ifupdown.sh should be changed to account that "YES" value.

But does systemd affects the package somehow - no, it does not.

Reco

[Hans]

Am Sonntag, 24. April 2022, 18:50:14 CEST schrieb Reco:
Originally I did not want to post any more to this issue, but I rechecked and
as I was unprecise I at least should correct it:

The param is set to "=true" not YES (as I postulated), sorry for that.

But thanks for all the help, I will not bother you with this further on.

I will find a solution for me myself, see this issue as solved.

Thanks for the help!

Best regards

Hans

[David Wright]

On Sun 24 Apr 2022 at 19:50:14 (+0300), Reco wrote:
> On Sun, Apr 24, 2022 at 03:23:55PM +0200, Hans wrote:
> > I rechecked, and everything is set as YES.
>
> And that's the source of your problem, believe it or not.
>
> Because what /etc/macchanger/ifupdown.sh does is it explicitly checks
> for "true" value:
>
> if [ "$ENABLE_ON_POST_UP_DOWN" != "true" ]; then
> echo "disabled in /etc/default/${package}" >> $LOGFILE
> exit
> fi
>
> Anything else, be it "TRUE", "YES" or "y" is considered "disabled" by
> that check.
>
> Now if "YES" appeared in /etc/default/macchanger by means of running
> debconf - that's a bug in the package. Either debconf template or
> ifupdown.sh should be changed to account that "YES" value.

As might be expected, both debconf and, on this, macchanger get a
clean bill of health:

# grep ENA /etc/default/macchanger
ENABLE_ON_POST_UP_DOWN=false
#ENABLE_INTERFACES="wlan0"
# dpkg-reconfigure macchanger


┌────────────────────────┤ Configuring macchanger ├─────────────────────────┐
│ │
│ Please specify whether macchanger should be set up to run automatically │
│ every time a network device is brought up or down. This gives a new MAC │
│ address whenever you attach an ethernet cable or reenable wifi. │
│ │
│ Change MAC automatically? │
│ │
│ <Yes> <No> │
│ │
└───────────────────────────────────────────────────────────────────────────┘


# grep ENA /etc/default/macchanger
ENABLE_ON_POST_UP_DOWN=true
#ENABLE_INTERFACES="wlan0"
# apt-get purge macchanger

Cheers,
David.

[Hans]

So, tried again.

The param in /etc/default/macchanger is set to "=true"

---

# before bringing up any network interface, run macchanger. Careful, this is
# not guaranteed to prevent leaking your real MAC address before the new one
# gets assigned!
#
ENABLE_ON_POST_UP_DOWN=true


# by default, macchanger runs on all network interfaces but loopback (lo).  If
# you only want it to run on specific network interfaces, set them here:
#
#ENABLE_INTERFACES="wlan0"

---

Hoqwever, it looks, somewhere the IFACE variable is wrong set. But it looks like, this is not set by macchanger.

I searched through all configs below /etc, but could not find any.

This is the log output of macchanger:

---

IFACE = --all
/usr/bin/macchanger: unrecognized option '--all'
GNU MAC Changer
Usage: macchanger [options] device

 -h,  --help                   Print this help
 -V,  --version                Print version and exit
 -s,  --show                   Print the MAC address and exit
 -e,  --ending                 Don't change the vendor bytes
 -a,  --another                Set random vendor MAC of the same kind
 -A                            Set random vendor MAC of any kind
 -p,  --permanent              Reset to original, permanent hardware MAC
 -r,  --random                 Set fully random MAC
 -l,  --list[=keyword]         Print known vendors
 -b,  --bia                    Pretend to be a burned-in-address
 -m,  --mac=XX:XX:XX:XX:XX:XX
      --mac XX:XX:XX:XX:XX:XX  Set the MAC XX:XX:XX:XX:XX:XX

Report bugs to https://github.com/alobbs/macchanger/issues
IFACE = lo
ignoring loopback

---

Hope this helps.

Best

Hans

[David Wright]

On Mon 09 May 2022 at 08:52:39 (+0200), Hans wrote:
> So, tried again.
>
> The param in /etc/default/macchanger is set to "=true"
>
>

> --------------------

>
> # before bringing up any network interface, run macchanger. Careful, this is
> # not guaranteed to prevent leaking your real MAC address before the new one
> # gets assigned!
> #
> ENABLE_ON_POST_UP_DOWN=true
>
>
> # by default, macchanger runs on all network interfaces but loopback (lo). If
> # you only want it to run on specific network interfaces, set them here:
> #
> #ENABLE_INTERFACES="wlan0"

> --------------------

> Hoqwever, it looks, somewhere the IFACE variable is wrong set. But it looks like, this is not set
> by macchanger.
>
> I searched through all configs below /etc, but could not find any.

I don't know what you searched for.

> This is the log output of macchanger:
>
>

> --------------------

>
>
> IFACE = --all
> /usr/bin/macchanger: unrecognized option '--all'
> GNU MAC Changer
> Usage: macchanger [options] device
>
> -h, --help Print this help
> -V, --version Print version and exit
> -s, --show Print the MAC address and exit
> -e, --ending Don't change the vendor bytes
> -a, --another Set random vendor MAC of the same kind
> -A Set random vendor MAC of any kind
> -p, --permanent Reset to original, permanent hardware MAC
> -r, --random Set fully random MAC
> -l, --list[=keyword] Print known vendors
> -b, --bia Pretend to be a burned-in-address
> -m, --mac=XX:XX:XX:XX:XX:XX
> --mac XX:XX:XX:XX:XX:XX Set the MAC XX:XX:XX:XX:XX:XX
>
> Report bugs to https://github.com/alobbs/macchanger/issues
> IFACE = lo
> ignoring loopback

> --------------------
> Hope this helps.

ifup has --all as one of its possible options. The man page uses
IFACE as a placeholder for the interface name, ie

ifup -a|IFACE...

would be specified as

ifup -a

or

ifup --all

or

ifup wlan0

or

ifup wlan0 eth1

etc. I don't use ifup much, but typically the d-i would install
something like

allow-hotplug enpXsY
iface enpXsY inet dhcp

into /e/n/i.

However, the man page implies that you could write just

auto

and I wonder what ifup command would be generated from that.

What does your /etc/network/interfaces (and subdirectories) contain?

A workaround for your problem might be to set IFACE appropriately
in /etc/default/macchanger.

Cheers,
David.

[Hans]

Hi David,

> I don't know what you searched for.

>

I searched for all files below /etc of a string "IFACE", then looked at something like "IFACE=all" or "IFACE=--all" or similar.

>

v

> What does your /etc/network/interfaces (and subdirectories) contain?

>

Only this:

---

auto lo wlp5s0 enp0s10

iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

---

Everything else is commented out, as network-manager recommends this.

However, there are other configs below from other packages (these are clamav, ethtool, mountnfs, openvpn, postfix and wpasupplicant). These are in the original state and were never touched by me. But I can not exclude, these might interfere with macchanger.

 

> A workaround for your problem might be to set IFACE appropriately

> in /etc/default/macchanger.

Yes, that is a good idea, I will do so.

>

> Cheers,

> David.

Thanks and best regards

Hans

[David Wright]

On Mon 09 May 2022 at 19:49:11 (+0200), Hans wrote:
> > I don't know what you searched for.
> >
> I searched for all files below /etc of a string "IFACE", then looked at something like "IFACE=all"
> or "IFACE=--all" or similar.

It's always worth searching for the parts separately, even though a
lot of false hits can result.

But I googled iface=--all network

(adding network to avoid phone cases), and that hit man interfaces,
wherein I find (selected lines):

--✄✄✄✄--

ENVIRONMENT VARIABLES
All hook scripts, and the commands executed by pre-up, up, post-up,
pre-down, down and post-down have access to the following environment
variables:

IFACE The physical name of the interface being processed, or "--all"
(see below).

[ … ]

Additionally, all options given in an interface definition stanza are
exported to the environment in upper case with "IF_" prepended and with
hyphens converted to underscores and non-alphanumeric characters dis‐
carded.

When ifupdown is being called with the --all option, before doing any‐
thing to interfaces, it calls all the hook scripts (pre-up or down)
with IFACE set to "--all", LOGICAL set to the current value of --allow
parameter (or "auto" if it's not set), ADDRFAM="meta" and
METHOD="none". After all the interfaces have been brought up or taken
down, the appropriate scripts (up or post-down) are executed.

--✄✄✄✄--

So now the search might be for ifup or down, other options perhaps,
and somewhere or other, --all. A lot of alternatives. So best search
for just '\--all' (noting the escaped hyphen). Nowadays I tend to
check /etc/, /var/lib/dpkg/info/, and /lib/systemd/ for your
configuration, Debian's, and systemd's. So

# grep -r '\--all' /etc/ /var/lib/dpkg/info/ /lib/systemd/

and you'll know it's working as you'll hit some --allow strings.

> > What does your /etc/network/interfaces (and subdirectories) contain?
> >
>
> Only this:
>

> --------------------

>
> auto lo wlp5s0 enp0s10
>
> iface lo inet loopback
> address 127.0.0.1
> netmask 255.0.0.0
>

> --------------------

> Everything else is commented out, as network-manager recommends this.

Does NM really want "auto lo wlp5s0 enp0s10" in /e/n/i? That surprises
me. Another (pre-bullseye) package that avoided interfaces in /e/n/i,
wicd, would expect no mention of its interfaces in /e/n/i, leaving just:

auto lo
iface lo inet loopback

I would try that.

> > A workaround for your problem might be to set IFACE appropriately
> > in /etc/default/macchanger.
>
> Yes, that is a good idea, I will do so.

You could then unwind this, and just set ENABLE_INTERFACES in
/etc/default/macchanger as appropriate (and if required).

Cheers,
David.

[Stefan Krusche]

Good Day Everyone,

Am Montag, 9. Mai 2022 schrieb Hans:
> IFACE = --all
> /usr/bin/macchanger: unrecognized option '--all'
> GNU MAC Changer

Yes. The problem is that the script /etc/macchanger/ifupdown.sh which is
shipped with the macchanger package processes $IFACE without checking
its value.

package=macchanger
/usr/bin/${package} -e $IFACE >> $LOGFILE 2>&1

When $IFACE == "--all" which is a valid option for ifup as David pointed
out then macchanger fails and reports the above error message to its
logfile because macchanger understands "--all" as on option which it
doesn't know.

Am Montag, 9. Mai 2022 schrieb David Wright:
> A workaround for your problem might be to set IFACE appropriately
> in /etc/default/macchanger.

A solution I found is to change the script /etc/macchanger/ifupdown.sh
so that it checks for the value of $IFACE against the value of
$ENABLE_INTERFACES (sourced from /etc/default/macchanger) and only then
processes that accordingly. $ENABLE_INTERFACES on my system contains
only "net0" so all is fine here.

A version of this script which works on my system (Devuan Beowulf) is
attached.

Another approach I haven't tested yet could be to add "--" to the line
which invokes maccanger so that the value of "$IFACE" being "--all"
wouldn't be treated as an option but as an argument and given to ifup
or whatever macchanger internally uses to actually change the MAC. But
I don't know if macchanger understands "--".

/usr/bin/$package -a -- "$IFACE" >> $LOGFILE 2>&1

HTH

Kind regards,
Stefan

[Stefan Krusche]

Good Day Everyone,

Am Montag, 9. Mai 2022 schrieb Hans:

> IFACE = --all
> /usr/bin/macchanger: unrecognized option '--all'
> GNU MAC Changer

$ cat /etc/macchanger/ifupdown.sh
#!/bin/sh
# $Id: ifupdown.sh,v 2.0 2021-04-21 16:23:42+02 stekru Exp $
# randomize MAC address before connecting to wifi or ethernet
#
# This script should always be run in if-pre-up.d, but unfortunately
# NetworkManager does not run if-pre-up.d scripts before it sets up a
network
# connection (https://bugzilla.gnome.org/show_bug.cgi?id=387832).
# if-post-down.d scripts are run, so there is a symlink to this script
# there. That means when running network config from the terminal,
macchanger
# will be run twice, but it'll only be run in if-post-down.d when using
# NetworkManager.

package=macchanger
LOGFILE=/var/log/$package.log
#LOGFILE=~/.local/log/$package.log

echo >> $LOGFILE
date '+%Y-%m-%d %T' >> $LOGFILE

# Vorgaben einlesen; hier wird auch ENABLE_INTERFACES="net0" eingelesen.
if [ -f /etc/default/$package ]; then
. /etc/default/$package
else
echo "Config file /etc/default/$package not found" >> $LOGFILE
exit 1
fi

if [ "$ENABLE_ON_POST_UP_DOWN" != "true" ]; then

echo "Macchanger is disabled in /etc/default/$package" >> $LOGFILE
exit
fi

# Where comes '$IFACE' from? From networking or ifup/-down/-query?
# The variable could be read from the environment. Where (from which
# program) would it be exported. No arguemnts are being processed here.
echo "Processing: IFACE = $IFACE" >> $LOGFILE

if [ -z "$ENABLE_INTERFACES" ]; then
echo "No interface enabled in /etc/default/$package" >> $LOGFILE
exit 0
else
case "$IFACE" in
*$ENABLE_INTERFACES*)
/usr/bin/$package -a "$IFACE" >> $LOGFILE 2>&1
;;
*)
echo "Ignoring not configured interface: $IFACE" >> $LOGFILE
exit 0
;;
esac
fi

[Stefan Krusche]

Am Freitag, 13. Mai 2022 schrieb Stefan Krusche:
> When $IFACE == "--all" which is a valid option for ifup as David
> pointed out then macchanger fails and reports the above error message
> to its logfile because macchanger understands "--all" as on option
> which it doesn't know.

See also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780165

[Hans]

Am Freitag, 13. Mai 2022, 13:21:17 CEST schrieb Stefan Krusche:
Hi Stefan,

I believe, changing the ifup-script might be a good idea. Additionally I will
try to set the environment variable in /etc/default/macchanger to my needs.

At the moment I am using a random MAC set by network-manager, but this one is
always the same, what I also do not want.

As I would like to forget about changing my MAC whenever I am online,
macchanger looks like the best solution.

In the meantime I filed a buugreport to it, because as we see, macchanger
does not do its job by default as intended.

So it is indeed buggy! Or let's say: Its configuration and scripts are buggy.

I will also take a look at your script, maybe this will work, too.

Thank you for the help!

Best regards

Hans

[Stefan Krusche]

Am Freitag, 13. Mai 2022 schrieb Hans:
> In the meantime I filed a buugreport to it,  because as we see,
> macchanger does not do its job by default as intended.

Yes, it is a bug. It has already been reported in 2015. I referenced
that in my other message:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780165


Kind regards,
Stefan

PS: no need to CC me, I'm subscribed

[David Wright]

On Fri 13 May 2022 at 16:19:52 (+0200), Hans wrote:
> Am Freitag, 13. Mai 2022, 13:21:17 CEST schrieb Stefan Krusche:
>
> I believe, changing the ifup-script might be a good idea. Additionally I will
> try to set the environment variable in /etc/default/macchanger to my needs.
>
> At the moment I am using a random MAC set by network-manager, but this one is
> always the same, what I also do not want.
>
> As I would like to forget about changing my MAC whenever I am online,
> macchanger looks like the best solution.

Did you consider systemd's approach, using a .link file? Pros, Cons?

> In the meantime I filed a buugreport to it, because as we see, macchanger
> does not do its job by default as intended.
>
> So it is indeed buggy! Or let's say: Its configuration and scripts are buggy.

Did you track down who or what was setting --all, and where?
I think the bug report says somebody, but presumably, only
someone who hits this bug will be able to search for it.

> I will also take a look at your script, maybe this will work, too.

Cheers,
David.