Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #247474 > unrolled thread

macchanger - is it still working?

Back to article view | Back to linux.debian.user

Contents

  macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-04-24 14:40 +0200
    Re: macchanger - is it still working? Reco <recoverym4n@enotuniq.net> - 2022-04-24 15:20 +0200
      Re: macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-04-24 15:30 +0200
        Re: macchanger - is it still working? "Andrew M.A. Cater" <amacater@einval.com> - 2022-04-24 16:20 +0200
          Re: macchanger - is it still working? "tv.debian" <tv.debian@googlemail.com> - 2022-04-24 16:30 +0200
          Re: macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-04-24 16:50 +0200
        Re: macchanger - is it still working? David Wright <deblis@lionunicorn.co.uk> - 2022-04-24 17:00 +0200
          Re: macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-04-24 17:10 +0200
            Re: macchanger - is it still working? David Wright <deblis@lionunicorn.co.uk> - 2022-04-24 18:10 +0200
              Re: macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-04-24 19:10 +0200
        Re: macchanger - is it still working? Reco <recoverym4n@enotuniq.net> - 2022-04-24 19:10 +0200
          Re: macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-04-24 19:30 +0200
          Re: macchanger - is it still working? David Wright <deblis@lionunicorn.co.uk> - 2022-04-24 20:50 +0200
          Re: macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-05-09 09:00 +0200
            Re: macchanger - is it still working? David Wright <deblis@lionunicorn.co.uk> - 2022-05-09 19:30 +0200
              Re: macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-05-09 19:50 +0200
                Re: macchanger - is it still working? David Wright <deblis@lionunicorn.co.uk> - 2022-05-10 01:20 +0200
            Re: macchanger - is it still working? Stefan Krusche <linux@stefan-krusche.de> - 2022-05-13 13:20 +0200
              Re: macchanger - is it still working? Stefan Krusche <linux@stefan-krusche.de> - 2022-05-13 13:40 +0200
            Re: macchanger - is it still working? Stefan Krusche <linux@stefan-krusche.de> - 2022-05-13 13:30 +0200
              Re: macchanger - is it still working? Hans <hans.ullrich@loop.de> - 2022-05-13 16:30 +0200
                Re: macchanger - is it still working? Stefan Krusche <linux@stefan-krusche.de> - 2022-05-13 16:50 +0200
                Re: macchanger - is it still working? David Wright <deblis@lionunicorn.co.uk> - 2022-05-13 17:20 +0200

Page 1 of 2  [1] 2  Next page →

#247474 — macchanger - is it still working?

[Multipart message — attachments visible in raw view] — view raw

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[1] 

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 




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

[toc] | [next] | [standalone]

#247475

	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

[toc] | [prev] | [next] | [standalone]

#247476

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

[toc] | [prev] | [next] | [standalone]

#247477

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 

[toc] | [prev] | [next] | [standalone]

#247478

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.

[toc] | [prev] | [next] | [standalone]

#247479

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

[toc] | [prev] | [next] | [standalone]

#247480

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.

[toc] | [prev] | [next] | [standalone]

#247481

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

[toc] | [prev] | [next] | [standalone]

#247484

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.

[toc] | [prev] | [next] | [standalone]

#247485

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

 

[toc] | [prev] | [next] | [standalone]

#247486

	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

[toc] | [prev] | [next] | [standalone]

#247488

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

[toc] | [prev] | [next] | [standalone]

#247490

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.

[toc] | [prev] | [next] | [standalone]

#248034

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#248043

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.

[toc] | [prev] | [next] | [standalone]

#248045

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#248057

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.

[toc] | [prev] | [next] | [standalone]

#248150

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#248152

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

[toc] | [prev] | [next] | [standalone]

#248151

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web