Re: macchanger - is it still working?
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.
Re: macchanger - is it still working?
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
Re: macchanger - is it still working?
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
> 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
>
>
>
> $ 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
Re: macchanger - is it still working?
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
Re: macchanger - is it still working?
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
$ 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
Re: macchanger - is it still working?
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
#!/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
Re: macchanger - is it still working?
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.
Re: macchanger - is it still working?
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
Re: macchanger - is it still working?
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, --versionPrint version and exit > -s, --show Print the MAC address and exit > -e, --ending Don't change the vendor bytes > -a, --anotherSet random vendor MAC of the same kind > -ASet 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, --biaPretend 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.
Re: macchanger - is it still working?
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, --versionPrint version and exit -s, --show Print the MAC address and exit -e, --ending Don't change the vendor bytes -a, --anotherSet random vendor MAC of the same kind -ASet 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, --biaPretend 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
Re: macchanger - is it still working?
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? │
│ │
│ │
│ │
└───┘
# grep ENA /etc/default/macchanger
ENABLE_ON_POST_UP_DOWN=true
#ENABLE_INTERFACES="wlan0"
# apt-get purge macchanger
Cheers,
David.
Re: macchanger - is it still working?
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
> 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
Re: macchanger - is it still working?
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
Re: macchanger - is it still working?
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
Re: macchanger - is it still working?
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.
Re: macchanger - is it still working?
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
Re: macchanger - is it still working?
On Sun 24 Apr 2022 at 15:23:55 (+0200), Hans wrote: > Am Sonntag, 24. April 2022, 15:00:21 CEST schrieb Reco: > > 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. 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.
Re: macchanger - is it still working?
Hi Andrew, I did as you suggested. Filed a wish-report to the package. Let's hope for the best. Best regards Hans > 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
Re: macchanger - is it still working?
Le 24/04/2022 à 16:15, Andrew M.A. Cater a écrit : On Sun, Apr 24, 2022 at 03:23:55PM +0200, Hans wrote: 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 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 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.
Re: macchanger - is it still working?
On Sun, Apr 24, 2022 at 03:23:55PM +0200, Hans wrote: > 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 > > 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
Re: macchanger - is it still working?
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
Re: macchanger - is it still working?
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
