This can ease installation, while providing enough flexibility to cover
both installation use-cases:
* systemd installs, using the service file and specific udev rules
* generics installs, using the basic udev rules only

On systemd-based systemd, running `bootmac` directly from the `udev`
rules doesn't work very well for bluetooth. As previously noted, using
a systemd service instead fixes those problems, although it requires
finding an appropriate "reverse dependency" (such as e.g.
`bluetooth.target`).

Using unit activation from `udev` makes it easier, at it will be
triggered once the interface exists. Moreover, in order to avoid
creating service files for both wlan and bluetooth, we can make it a
template and use the instance parameter as bootmac's main command-line
argument.

If bootmac is running under systemd, sending output to `logger` usually
means that the output is not sent to journald, and is lost. This can
make debug more difficult. The var tested here is one that systemd sets
when running a daemon (see `man systemd.exec`.)

This replaces 3bfb183f with a retry mechanism, where the BT and wlan
mac is (re)tried every 1 second for up to 5 seconds (configurable).

If this doesn't play nicely with udev rules when using RUN, then
BT_TIMEOUT and/or WLAN_TIMEOUT can be set in the env.

Being part of the bluetooth.target means that this service (if
enabled) is started automatically every time the bluetooth service is
(re)started.

WiFi was skipped since I've not found a reliable way to have
bootmac configure the mac, it's racing with the driver, NM, and
iwd/wpa_supplicant. The udev rule for wifi should just be dropped
altogether when packaging bootmac for a systemd OS since it's unreliable
and buggy.

The udev rule for bluetooth doesn't work on systemd[1], by splitting the
rule into two separate rules, distros can leave this bluetooth rule out
when packaging for systemd.

Distros packaging bootmac will have to make note of the new rule
files/names.

1. https://github.com/systemd/systemd/issues/35003

add mandatory parameter checking for right format of if-name and bytes

Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>

use case: overwrite the default host address already set. In this case the
bt host is already up but needs the new address.

Signed-off-by: Jens Glathe <jglathe@oldschoolsolutions.biz>

parameter for variable static prefix

Signed-off-by: Jens Glathe <jglathe@oldschoolsolutions.biz>

In this mode bootmac prints the derived MAC value for either Bluetooth
or Wi-Fi, but does not actually configure the hardware.

Hardcoding all possible argument values is not feasible for more than
2 options, since there will be N! (N factorial) possible options.

Syboxez Blank authored 1 year ago and Dylan Van Assche committed 1 year ago

This allows for more granular service enablement and ordering,
along with enabling the ability to configure MAC post-boot.

Thanks to @NekoCWD for the workaround.
Fixes: https://gitlab.com/postmarketOS/bootmac/-/issues/3

Something must have gone wrong with the previous commit

Be compatible with any POSIX shell

Run shellcheck on every merge request.

Manufacturer OUI lookup is removed

Read rfkill state of Bluetooth and WLAN interfaces before setting
the MAC address. After setting the MAC address, restore the saved
rfkill state.

Fixes https://gitlab.com/postmarketOS/bootmac/-/issues/2

qmac was renamed to bootmac

Use 02:00 to specify that we generate a local administered
address as MAC address. This approach is used by all MSM8916 devices.

Fixes https://gitlab.com/postmarketOS/bootmac/-/issues/1

qmac was renamed too bootmac

Bootmac configures the MAC addresses of WLAN and Bluetooth interfaces at boot.
Bootmac can be invoked in various ways at boot, but currently only udev rules are tested.
Bootmac generates MAC addresses from the `serialno` provided by Android bootloaders
through /proc/cmdline or from /etc/machine-id. The Organizationally Unique Identifier (OUI)
is retrieved from a lookup database macdb by matching deviceinfo_manufacturer
from /etc/deviceinfo with the entries in the database.