Mac address random failed

[unkno]

Hello ,

Sorry for my english but i am french . macchanger-r interface does not work .

Kernel release : 3.13.0-24-generic GNU MAC changer 1.7.0

Problem :

macchanger-r interface

Current MAC: 15:82:e6:80:a0:fb (Hon Hai Precision Ind. Co.,Ltd.) Permanent MAC: 15:82:e6:80:a0:fb (Hon Hai Precision Ind. Co.,Ltd.) New MAC: 15:82:e6:80:a0:fb (Hon Hai Precision Ind. Co.,Ltd.) it's the same mac !!

but macchanger -m 52:9E:42:BC:4A:EF interface it's ok no problem

---

I try GNU MAC changer 1.6.0 on the same distribution and macchanger -r interface it's ok no problem

[thoger]

Can you post output of two subsequent runs of something like this?

# strace -e trace=open,read macchanger -r eth0 2>&1 | tail -n 15

[unkno]

read(3, "2 DF Vnl Europe Ab\nF8 5F 2A Noki"..., 4096) = 3874 read(3, "", 4096) = 0 open("/usr/local/share/macchanger/wireless.list", O_RDONLY) = 3 read(3, "00 00 8F Raytheon Raylink/WebGea"..., 4096) = 1358 read(3, "", 4096) = 0 read(3, "", 4096) = 0 read(3, "00 00 8F Raytheon Raylink/WebGea"..., 4096) = 1358 read(3, "", 4096) = 0 read(3, "", 4096) = 0 open("/dev/urandom", O_RDONLY) = 3 read(3, "\2344\272\6", 4) = 4 Current MAC: 15:82:e6:80:a0:fb (Hon Hai Precision Ind. Co.,ltd.) Permanent MAC: 15:82:e6:80:a0:fb (Hon Hai Precision Ind. Co.,ltd.) New MAC: 42:35:d4:f0:44:72 (unknown) +++ exited with 0 +++

but I install version 1.6.0, because 1.7.0 was not working The version 1.6.0 it's ok

do you think I try the command with the 1.7.0 version ?

[thoger]

Right, problematic version was meant to be tested. But now I noticed that my guess your problem might be related to random seeding is probably wrong, as new (random) MAC matches your permanent MAC.

[unkno]

effectively, the random of mac address does not work with the new version. I post the problem to contribute to the development .

thank you anyway :-)

[thoger]

It works fine here. Question above was to get some information that may hint why it's failing for you.

[nirgal]

Make sure you are not using the buggy Debian patch. https://bugs.debian.org/738460 (unlikely, but just in case)

[casseruola]

The same problem

Linux version: Linux Mint 17 Qiana Kernel: 3.13.0-24-generic

sudo macchanger -r wlan0 Current MAC: xx:xx:xx:xx:xx:xx (--------) Permanent MAC: xx:xx:xx:xx:xx:xx (--------) New MAC: xx:xx:xx:xx:xx:xx (--------) It's the same MAC!!

sudo macchanger -e wlan0 Current MAC: xx:xx:xx:xx:xx:xx (--------) Permanent MAC: xx:xx:xx:xx:xx:xx (--------) New MAC: xx:xx:xx:xx:xx:xx (--------) It's the same MAC!!

And if use option -A, it changes just the vendor bytes, not the last 6 as it should do

sudo macchanger -A wlan0 Current MAC: 00:11:11:11:11:11 (Intel Corporation) Permanent MAC: xx:xx:xx:xx:xx:xx (--------) New MAC: e8:8d:28:11:11:11 (Apple)

On the other end, -m option works

sudo macchanger -m 00:11:11:11:11:11 wlan0 Current MAC: xx:xx:xx:xx:xx:xx (--------) Permanent MAC: xx:xx:xx:xx:xx:xx (--------) New MAC: 00:11:11:11:11:11 (Intel Corporation)

[abreksa4]

Same on Xubuntu 14.04, latest version.

[brecha]

It happened also to me in Gentoo with version 1.7.0, when I did the strace command suggested above, I got the following output: open("/dev/hwrng", O_RDONLY) = 3 read(3,0x7fd705ecbc, 4) = -1 ENODEV (No such device) Current: .* Permanent : .* New: .* It's the same MAC!!

The weird thing is that hwrng does indeed exist, but when I try to cat it it says no such device, on the other hand, if I move /dev/hwrng to /dev/bak.hwrng it works, because as it doesn't load it it tries with /dev/random which gives the correct output.

Is there a way to make macchanger not look on hwrng? or if it fails load the next random source?

Thanks

[thoger]

Is there a way to make macchanger not look on hwrng? or if it fails load the next random source?

read() errors are currently not checked. The easiest way to fix should be revert of commit 99ea379 to avoid the use of /dev/hwrng. Issue #5 has further discussion of the change.

[yurihentai]

apologies for posting in half-decade old thread, but I wanted to include this solution for future Gentoo users coming from a search engine:

(run as root)

echo "net-analyzer/macchanger ~amd64" >> /etc/portage/package.accept_keywords
emerge -av net-analyzer/macchanger

Debian patches for fixing this issue and various others are included in the testing package for macchanger. It has something to do with using a non-working TPM.

[jlj2]

Thank you so much @yurihentai for taking the effort and the determination to reopen this issue, as it helped me the very next day that you posted!

The It's the same MAC! error recurs when rerunning sudo macchanger eth0 -e, and it has persisted in both of my last installations of an up-to-date gentoo derivative, Calculate Linux 20.6.

Your solution works! Please note that in Calculate Linux, as with some other Gentoo installations, as I understand, /etc/portage/package.accept_keywords is a directory, and so a file needs to be created instead in that folder, say, by the name of macchanger.

Also, this may be unnecessary, but I thought that --autounmask-write then needs to be added with emerge:

As root:

touch /etc/portage/package.accept_keywords/macchanger
echo "net-analyzer/macchanger ~amd64" >> /etc/portage/package.accept_keywords/macchanger
emerge macchanger  --autounmask-write

Thanks also to Gentoo's package maintainer (@robbat2 if the link you kindly provided is up-to-date) for his attention with this package. Perhaps he could also consider:-

1. Flagging the issue at the time of installation and the workaround, or somehow setting the architecture flag as a default flag at the time of installation; and
2. Perhaps enable eix to list ~amd64 as a possible flag, because even after setting the ~amd64 flag, the eix installer doesn't display it:

$ eix macchanger
[I] net-analyzer/macchanger
     Available versions:  1.7.0{tbz2} (~)1.7.0-r1 (~)1.7.0_p5_p4
     Installed versions:  1.7.0_p5_p4(10:23:16 PM 11/25/2020)
     Homepage:            https://github.com/alobbs/macchanger
     Description:         Utility for viewing/manipulating the MAC address of network interfaces