i am not sure i am reaching out right way, but i would like to ask for this feature: mac address randomization.
i guess networkmanager has randomization already? and that can be used since pmos already uses nm?
imho this should be made on system level (not sxmo) depending on what os you are using..
i believe it is already done on system level. i have opened sxmo ticket because sxmo has its own network connection tool. and it uses network manager, at least on pmos. so since pmos is using nm, and nm has randomization i think sxmo shoudl use it too.
Hi norayr
sxmo (at least under Alpine/postmarketOS) specifically disables the mac randomization feature, as you can see from the packaging [1]. I am not sure why this is the case, since there does not seem to be an explanation in the commit history.
However, the first commit adding sxmo to Alpine (including the file in question) is dated 27th April 2021 [2]. On the other hand, the commit adding mac randomization under pmOS is dated 1 July 2023 [3]. sxmo installs its file in a higher priority location than where pmOS stores its forced randomization file.
So, you could conclude that mac randomization has not been specifically tested under sxmo and found to have issues. So, you could experiment with removing that file from your system, and see if anything breaks. If not, perhaps you can send a patch to drop it, and who knows - it may just get merged.
Hope this helps.
Sicelo A.
[1] https://git.alpinelinux.org/aports/tree/community/sxmo-utils/rootfs-etc-NetworkManager-conf.d-00-sxmo.conf [2] https://git.alpinelinux.org/aports/commit/?id=3a9ea7a415fb775ce0bef077632ab97ef27394c9 [3] https://gitlab.com/postmarketOS/pmaports/-/commit/4e0229f789c28e505d2d4f9c15ab1e94b9079ac2
Sicelo, thank you.
so i have changed the configuration:
pine64-pinephone:~$ cd /etc/NetworkManager/ conf.d/ dnsmasq-shared.d/ system-connections/ dispatcher.d/ dnsmasq.d/ pine64-pinephone:~$ cd /etc/NetworkManager/conf.d/ pine64-pinephone:/etc/NetworkManager/conf.d$ cat 00-sxmo.conf [main] plugins+=ifupdown [ifupdown] managed=true [logging] level=INFO [device-mac-randomization] wifi.scan-rand-mac-address=yes [keyfile] unmanaged-devices=interface-name:p2p0
changed 'no' to 'yes'.
and after reboot it worked. then i restarted network manager, and i saw
pine64-pinephone:~$ sudo /etc/init.d/networkmanager restart [sudo] password for user: * Stopping tor ... [ ok ] * Stopping chronyd ... [ ok ] Current MAC: f6:4c:ef:56:a4:8a (unknown) Permanent MAC: 02:ba:6d:a8:0b:79 (unknown) [ERROR] Could not change MAC: interface up or insufficient permissions: Operation not permitted * Stopping networkmanager ... [ ok ] Current MAC: 16:16:d6:67:25:9e (unknown) Permanent MAC: 02:ba:6d:a8:0b:79 (unknown) New MAC: 46:94:3c:3a:54:63 (unknown) * Starting networkmanager ...
ifconfig wlan0 still shows that old hwaddr:
$ ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr F6:4C:EF:56:A4:8A
and when i am doing arm i can see from my machine:
$ arp Address HWtype HWaddress Flags Mask Iface pinephone.lan ether f6:4c:ef:56:a4:8a C wlan0
this all was done from ssh session.
but then i stopped networkmanager from the 'st' on the device. used
macchanger -r wlan0
as root.
started networkmanager.
and it got the same ip as my openwrt router should give by that mac, and ifconfig still shows the same mac, and arp from my machine too.
so i don't understand what is happening.
it tells you right there:
[ERROR] Could not change MAC: interface up or insufficient permissions: Operation not permitted
try to reboot, so this applies from boot.
Also, do not use
macchanger
. As you pointed out,NetworkManager
can do the MAC changing itself. I thought you would actually remove the/etc/NetworkManager/conf.d/00-sxmo.conf
...
thanks for the hint. we need to remove the file completely, just writing yes in /etc/NetworkManager/conf.d/00-sxmo.conf
[device-mac-randomization] wifi.scan-rand-mac-address=yes
will be reseted on next boot....
On Wed Apr 24, 2024 at 10:23 PM CEST, ~Sicelo wrote:
sxmo (at least under Alpine/postmarketOS) specifically disables the mac randomization feature, as you can see from the packaging [1]. I am not sure why this is the case, since there does not seem to be an explanation in the commit history.
I don't recall either why this was done. It's probably best just to drop this file from the packaging entirely yes. I assume the defaults suffice and have randomized mac on nowadays.
i tested now a few days without this file but having wifi trouble from time to time.. so i recreate the file and test again over the next few days to figure out if this causes the issues or something else.... edit: still facing the same issues, does not matter if the file exists or not..