This is really badly hacky, but I do not know a better way to solve this
with our existing "setup" program which would be a nightmare to extend.
So we are using the device number to generate a static MAC address which
can then be used as usual. I doubt many people will have more than one
device.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When acquiring an IP address, dhcpcd seems to think that the interface
is down or does not work properly for some reason. It will
subsequentially decide to exit which is not what we want here.
Therefore this patch tells dhcpcd to ignore the link state and keep
happily running.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This could potentially create problems when we abuse these functions to
launch the DHCP client on IPTV interfaces. This would have to be tested
and confirmed or potentially we would need some more changes to keep
supporting that use-case, too.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This has been removed a long time ago and we should probably spend a
little bit more time on keeping the networking code tidy :)
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
QMI is a proprietary interface from Qualcomm which are absolute pioneers
when it comes to interfacing with modems. I don't think there would be
any way to make this any more complicated and bloated.
So, bascially we will put the modem into a raw IP mode which changes the
interface into Point-to-Point mode.
We then configure the provider settings using qmicli. After that, the
modem will try to connect to the provider and obtain an IP address.
We will then start a DHCP client which does not do any DHCP-ing because
implementing that would be too complicated. Instead we do something even
*more* complicated where we would launch a custom script which asks the
modem for the allocated IP address and will configure it into the
device. The DHCP client then reads that IP address from the device and
pretends it came up with it by itself. Such an easy way to do this.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This ensures restoring a backup won't silently bring back an insecure
Diffie-Hellman parameter (which could also not be inspected through the
web interface anymore).
Reported-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Full changelog:
Changes in version 0.4.7.12 - 2022-12-06
This version contains a major change that is a new key for moria1. Also, new
metrics are exported on the MetricsPort for the congestion control
subsystem.
o Directory authority changes (moria1):
- Rotate the relay identity key and v3 identity key for moria1. They
have been online for more than a decade and refreshing keys
periodically is good practice. Advertise new ports too, to avoid
confusion. Closes ticket 40722.
o Minor feature (Congestion control metrics):
- Add additional metricsport relay metrics for congestion control.
Closes ticket 40724.
o Minor features (fallbackdir):
- Regenerate fallback directories generated on December 06, 2022.
o Minor features (geoip data):
- Update the geoip files to match the IPFire Location Database, as
retrieved on 2022/12/06.
o Minor bugfixes (cpuworker, relay):
- Fix an off by one overload calculation on the number of CPUs being
used by our thread pool. Fixes bug 40719; bugfix on 0.3.5.1-alpha.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
This patch will gracefully terminate the daemon when it loses its
connection to the OpenVPN daemon.
Fixes: #12963
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
- On CU172 Testing Build: master/eb9e29f9 when selecting the OpenVPN menu it showed the
Diffie-Hellman info and pressing back took you to the same DH page.
- Tested patch suggestion from Erik on vm testbed and confirmed that it worked.
Suggested-by: Erik Kapfer <erik.kapfer@ipfire.org>
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Again, xz currently present on an IPFire machine is linked
against this. Thus, deleting this file causes the unpack
routine to fail, which is why we should have never deleted
it in the first place.
Reported-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
