Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Extend configure_isolated_interface to support more network stacks #8

Open
CyrilBrulebois opened this issue Aug 23, 2024 · 3 comments
Open

Extend configure_isolated_interface to support more network stacks #8

CyrilBrulebois opened this issue Aug 23, 2024 · 3 comments
Labels
in-progress

Comments

@CyrilBrulebois
Copy link
Collaborator

At the moment, we only support IFUPDOWN and NETWORKD_RESOLVED, we'll want to support more use cases so that the APPLIANCE mode can be used with a Debian system set up with other network stacks (e.g. NetworkManager).

See also #7 regarding reverting such modifications.
@CyrilBrulebois
Copy link
Collaborator Author

The current plan is to wait for the upcoming point release (12.7, planned tomorrow) to get fresh images, and use “debian-installer test laptops” as generic machines.

@CyrilBrulebois
Copy link
Collaborator Author

CyrilBrulebois commented Sep 5, 2024 •
edited
Loading

First things first: netinst, no desktop, therefore ifupdown is broken: the detection fails, and we end up with NetworkStack.UNKNOWN.

In this scenario, we have everything configured via /etc/network/interfaces directly, as opposed to using snippets (one per interface) under /etc/network/interfaces.d/ as that is the case with Debian/PTS images.

In passing, if we end up making it possible to toggle between interfaces, we might have some interfaces configured via snippets, some others via /etc/network/interfaces itself.

Edit: In any case, the code isn't/wasn't crazy: it relies on the output of ifquery --list --all which for some reasons only returns lo… But then we encounter an annoying issue, the auto vs. allow-hotplug duality. --all only operates on auto interfaces, while D-I configures ifupdown with allow-hotplug ones.

Proposed change: Run ifquery --list --all once for auto interfaces, and ifquery --list --allow hotplug once for allow-hotplug interfaces. At least in Debian 12, both can't be combined, otherwise only allow-hotplug interfaces are returned.

CyrilBrulebois added a commit that referenced this issue Sep 5, 2024
@CyrilBrulebois
Improve ifupdown detection.
9673423 
Call `ifquery --list` twice, once with `--all` and once with `--allow
hotplug`. The former works for /e/n/i as set up in Debian/PTS Raspberry
Pi images, the latter is required to spot allow-hotplug interfaces set
up by debian-installer.

[ Best viewed with -b due to indentation changes. ]

Link: #8
CyrilBrulebois added a commit that referenced this issue Sep 5, 2024
@CyrilBrulebois
Make sure to avoid any duplicates.
ac0e7cc 
This seems unlikely but ifquery /could/ change behaviour over time.

Plus we'll probably want to make it possible to update the config,
e.g. for interfaces that are coming and going (e.g. a USB/Ethernet
or USB/Wi-Fi dongle, or tethering, etc.), so we might end up with
several interfaces being configured via /e/n/i at a given time.

Link: #7
Link: #8
CyrilBrulebois added a commit to PiRogueToolSuite/debian-12-virogue that referenced this issue Sep 6, 2024
@CyrilBrulebois
Merge pirogue-admin 1.4.0 and pirogue-networking 1.3.2
d8eeed3 
Link: PiRogueToolSuite/pirogue-admin#8
CyrilBrulebois added a commit that referenced this issue Sep 6, 2024
@CyrilBrulebois
Add support for Wi-Fi interfaces in the NM case.
9a9eca9 
It seems NetworkManager doesn't want to let us set up just an IP address
as we would do in the ifupdown case, if the interface is configured with
mode=ap.

Go with the flow, and include as many settings as needed to make the
connection usable from a test phone.

Link: #8
CyrilBrulebois added a commit that referenced this issue Sep 6, 2024
@CyrilBrulebois
Disable hostapd in the NM case.
6de096c 
If NM manages our network, we have to fully configure the Wi-Fi
interface when it comes to the isolated network. That means hostapd
isn't required, and it couldn't deal with the interface anyway, as
it's already configured by NM.

Link: #8
CyrilBrulebois added a commit that referenced this issue Sep 6, 2024
@CyrilBrulebois
Extend support for NetworkManager.
75fcd10 
This adds support for APPLIANCE mode, when the isolated interface is
an Ethernet one (APPLIANCE mode):
 - Create/update pirogue-isolated-network.nmconnection via nmcli, with
   fewer parameters than in the Wi-Fi case (AP mode).

Link: #8
CyrilBrulebois added a commit to PiRogueToolSuite/debian-12 that referenced this issue Sep 6, 2024
@CyrilBrulebois
Merge pirogue-admin 1.4.1
e6bb3d9 
Link: PiRogueToolSuite/pirogue-admin#8
CyrilBrulebois added a commit to PiRogueToolSuite/deb-packages that referenced this issue Sep 6, 2024
@CyrilBrulebois
Mask hostapd.service if the condition is failed.
29dda33 
Let's make extra sure it cannot be enabled/started accidentally.

Link: PiRogueToolSuite/pirogue-admin#8
CyrilBrulebois added a commit to PiRogueToolSuite/debian-12-virogue that referenced this issue Sep 6, 2024
@CyrilBrulebois
Merge pirogue-networking 1.3.3
72d8095 
Link: PiRogueToolSuite/pirogue-admin#8
@CyrilBrulebois
Copy link
Collaborator Author

Marking with in-progress as I think I'm all done: we have a successful configuration with:

  • Pi 3, 4, and 5
  • laptop with a single wireless interface, with or without a USB/Ethernet adapter;
  • laptop with dual wired/wireless, configured with external interface = wired or wireless;
  • laptop with all desktop choices offered by Debian Installer (text-only, GNOME, KDE Plasma, etc.);
  • VM with a single interface: Debian Cloud image, or Hetzner-provided Debian image (with a few tweaks).

Most desktop environments use NetworkManager (newly-supported). Text-only uses ifupdown (already supported before those changes). Exceptions are LXDE and LQXt, which use connman. I haven't investigated integrating with that one, as ifupdown is installed as well, and can be configured as usual. If we get complaints about the lack of integration of isolated interface management into connman, we can always recommend against those two desktop environments…

This can be closed once tests have been documented in a dedicated page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
in-progress
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@CyrilBrulebois