Skip to content
This repository has been archived by the owner. It is now read-only.

NetworkManager support #388

Merged
merged 5 commits into from Mar 4, 2018

Conversation

Projects
None yet
5 participants
@MartijnBraam
Copy link
Member

commented Aug 15, 2017

My progress so far to get NetworkManager running.

ToDo:

  • The rc-update add networkmanager default command doesn't seem to be working
  • ifupdown needs to be removed for networkmanager to function completely
  • networkmanager forgets the secret keys for the networks
  • openrc needs to start udev, wpa_supplicant and networkmanager in the right order.
  • udev doest create the interface added events for the wlan interface on boot.
level=INFO

[device-mac-randomization]
wifi.scan-rand-mac-address=yes

This comment has been minimized.

Copy link
@ollieparanoid

ollieparanoid Aug 15, 2017

Member

awesome!

This comment has been minimized.

Copy link
@ollieparanoid

ollieparanoid Aug 16, 2017

Member

@MartijnBraam: I've realized now, that this does not always use a random mac (only during scanning), although NM can do that. How about using that as default, too? This would be a great privacy enhancement.

This comment has been minimized.

Copy link
@PureTryOut

PureTryOut Mar 4, 2018

Contributor

@ollieparanoid I've added mac randomization while connecting to a network.

According to the Arch wiki we can configure it to randomize it once for each wireless connection, and then permanently associate the two, or to use a random mac every time you connect, no matter if you've connected before. I choose the latter, but according to the wiki this might be unstable. If this indeed appears to be unstable, we can always change it to the former in the future.

This comment has been minimized.

Copy link
@PureTryOut

PureTryOut Mar 4, 2018

Contributor

Hmm, I reverted this change again after a short conversation with @MartijnBraam and @bhush9 . Seems most Android devices will not support this (driver limitations) and it might mess with the dhcp pool.

This comment has been minimized.

Copy link
@ollieparanoid

ollieparanoid Mar 4, 2018

Member

Okay, thanks for trying this! Maybe we can add a step in the installer when it is close to daily driver level, that asks if you want to enable this feature or not (and write in the deviceinfo if it works with the device?).

#!/bin/sh

# Reinsert the wireless driver so udev picks it up
rmmod wl1251_spi && modprobe wl1251_spi

This comment has been minimized.

Copy link
@craftyguy

craftyguy Aug 16, 2017

Member

This is super ugly.. there must be a better way to 'notify' networkmanager that this device exists.

@@ -11,6 +11,8 @@ rc-update add acpid default
rc-update add hwdrivers boot
# Enable networking service (requires /etc/interfaces, which is configured below)
rc-update add networking default
rc-update add networkmanager default

This comment has been minimized.

Copy link
@craftyguy

craftyguy Aug 16, 2017

Member

are you sure we want to push NM as the default network management utility for PMOS? Paging @ollieparanoid

In any case, networkmanager and networking conflict with eachother, so only one should be chosen (or none, I suppose)

This comment has been minimized.

Copy link
@MartijnBraam

MartijnBraam Aug 16, 2017

Author Member

Is there an alternative? Basically every shell has NM integration

This comment has been minimized.

Copy link
@craftyguy

craftyguy Aug 16, 2017

Member

Well, I certainly don't use NM on any of my other systems. So, yes there are alternatives. for instance, using the networking service with wpa_supplicant has been working for me very reliably. There are others I'd like to try (e.g. connman). NM certainly has its fans and its detractors.

If PMOS decides to support one vs the other, I'm ok with that. I'm just trying to make sure it's a somewhat informed decision!

This comment has been minimized.

Copy link
@MartijnBraam

MartijnBraam Aug 16, 2017

Author Member

Yeah ifupdown works but editing config files is not really great on smartphones, connman and wicd simply don't have as much UI integration

This comment has been minimized.

Copy link
@craftyguy

craftyguy Aug 16, 2017

Member

I agree with you. I'm just stating this view in order to make sure this PR is in line with the "vision" of PMOS. Choosing a default network management system is a big deal since it restricts some (default) freedom. I only want to make sure this is realized/understood/accepted.

This comment has been minimized.

Copy link
@ollieparanoid

ollieparanoid Aug 16, 2017

Member

I think NetworkManager makes sense, as it is what most desktop/phone environments use (including plasma mobile and ubports).

It can also handle advanced use-cases, such as connecting to the internet over a cellular modem or randomizing the mac.

So in my personal opinion, using NM as default is a sane decision.

@craftyguy: Great, that you have it working reliably already - how about documenting how to use the networking service instead of NM in the wiki, right after the installation with NM? That way we could both have NM as default and offer alternatives for hackers, who want something more lightweight for a specific use case!

This comment has been minimized.

Copy link
@craftyguy

craftyguy Aug 16, 2017

Member

Ok, NM by default then! So the rc-update add networking line needs to be removed else NM will never work right :)

# Change wpa_supplicant into dbus mode and enable both drivers
if ! apk audit /etc | grep -q etc/conf.d/wpa_supplicant; then
{
echo 'wpa_supplicant_args="-u -Dwext,nl80211"'

This comment has been minimized.

Copy link
@craftyguy

craftyguy Aug 16, 2017

Member

This might be device-specific, and probably best handled in the device-nokia-rx51.post-install file. -Dwext,nl80211 works for any/all wifi drivers, then it's fine here!

This comment has been minimized.

Copy link
@MartijnBraam

MartijnBraam Aug 16, 2017

Author Member

This is not device specific, those are the 2 driver APIs that linux has

This comment has been minimized.

Copy link
@craftyguy

craftyguy Aug 16, 2017

Member

Yup, I know, but the enablement/usage may be device-specific? Specifically, there's a NM option to do "wext-only", so I'm assuming that the options here may be specific to certain wifi drivers. I could be wrong.

@PureTryOut

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2017

Has any progress been made on this since last August? Having networkmanager would make pmOS way more user-friendly!

@PureTryOut PureTryOut force-pushed the feature/networkmanager branch from a745b97 to 2f45475 Dec 24, 2017

@PureTryOut

This comment has been minimized.

Copy link
Contributor

commented Dec 24, 2017

I've rebased this on the latest master, please verify if something is missing still.

@PureTryOut

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2018

Rebased again, please verify if something is missing still.

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Mar 1, 2018

Thanks for rebasing!

@MartijnBraam: are the N900 changes safe? we could also make this PR without the N900 changes if that is too uncertain.

And I think we should test this on at least one Android device and in Qemu.

EDIT: The N900 package has been renamed from device-nokia-rx51 to device-nokia-n900, and this is not done in the rebase. That's why travis fails. if we keep the N900 changes, we must fix that.

@PureTryOut

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

I removed the leftover bits from device-nokia-rx51, it just wasn't properly deleted. Also, the NetworkManager service was actually only enabled for the n900, so I moved that over to postmarketos-base so it's enabled for every device.

I can confirm it now works fine on Qemu.

@@ -52,6 +52,8 @@ package() {
"$pkgdir"/etc/pointercal
install -D -m644 "$srcdir"/asound.state \
"$pkgdir"/var/lib/alsa/asound.state
install -D -m755 "$srcdir"/profile.sh\

This comment has been minimized.

Copy link
@z3ntu

z3ntu Mar 2, 2018

Member

missed that

@PureTryOut PureTryOut force-pushed the feature/networkmanager branch 3 times, most recently from dca54f4 to 595f0ef Mar 2, 2018

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Mar 3, 2018

I'll test this on my i9100 (connecting to wifi, following the usb internet guide etc to see how it behaves).

MartijnBraam and others added some commits Aug 15, 2017

Use write_unless_modified in post-install
Notably this changes >> to >, which means the line gets overwritten and
not appended.

@ollieparanoid ollieparanoid force-pushed the feature/networkmanager branch from 595f0ef to 37c00ab Mar 3, 2018

@MartijnBraam
Copy link
Member Author

left a comment

The latest rebased version now works perfectly on my n900

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Mar 3, 2018

Awesome, thanks for testing @MartijnBraam! Unfortunately it does not work out of the box for me on the i9100.

Working:

  • SSH is still working after boot
  • network manager service is running
  • starting nmtui works as normal user

Not working:

  • wpa_supplicant is not running automatically
  • wpa_supplicant, when started manually, picks the wrong interface (it should be wlan0). ps ax says:

/sbin/wpa_supplicant -u -Dwext,nl80211 -B -c/etc/wpa_supplicant/wpa_supplicant.conf -ip2p0

  • when I add -iwlan0 to /etc/conf.d/wpa_supplicant, it uses the right interface
  • when wpa_supplicant is running, starting nmtui takes much longer and prints:

(nmtui:3225): libnm-WARNING **: Unable to get permissions: Timeout was reached

  • there's no wifi interface listed in nmtui (and I would expect it to be there, it is on my laptop!)
  • logread -f currently prints this all the time:

Jan 1 01:59:59 localhost daemon.info NetworkManager[2668]: [946686726.4789] device (wlan0): supplicant interface state: inactive -> disabled
Jan 1 01:59:59 localhost daemon.info NetworkManager[2668]: [946686726.4808] device (wlan0): supplicant interface state: disabled -> inactive
Jan 1 01:59:59 localhost daemon.warn NetworkManager[2668]: [946686726.7516] device (wlan0): set-hw-addr: new MAC address 2A:5E:02:6C:81:11 not successfully set

It might be that I am testing something wrong, I'm still looking into this. However, it would be good if someone else could test it with their Android devices. Especially getting wifi going.

EDIT: That's weird: I can get it to scan when I run these commands repeatedly while running network manager:

sudo ifconfig wlan0 up
sudo iw dev wlan0 scan

Sometimes they fail, sometimes the work (depending on the state networkmanager has put the device in I guess). I'll play with network manager's options and debugging, maybe it can be fixed with a simple config option or something (which we could enable for the i9100 only if necessary).

After doing that, the networks appear in nmtui.

@MartijnBraam

This comment has been minimized.

Copy link
Member Author

commented Mar 3, 2018

Hmm the -ip2p0 part looks like a bug in the upstream wpa_supplicant init script, it appends the first interface implementing phy80211 it can find. It can be overridden by setting wlan0 in /etc/conf.d/wpa_supplicant.conf with wpa_supplicant_if=wlan0

Actually the only reason the interface is specified is because the alpine initd file assumes you want to run it with hardcoded wifi login, not a dbus network manager. The -i isn't even needed to make it work if the dbus interface is enabled for wpa_supplicant.

Also I find that nmcli gives a better overview of the current nm state than nmtui
img_20180303_141802

@MartijnBraam

This comment has been minimized.

Copy link
Member Author

commented Mar 3, 2018

I also can't get it to work on the hammerhead:

$ nmcli
rndis0: connected to rndis0
	ethernet (dwc3), 7A:D7:7F:CE:88:30, hw, mtu 1500
	inet4 172.16.42.1/16
	inet4 169.254.234.124/16
	inet6 fe80::78d7:7fff:fece:8830/64

p2p0: unavailable
	wifi (bcmsdh_sdmmc), 00:90:4C:33:22:11, hw, mtu 1500

wlan0: unavailable
	wifi (bcmsdh_sdmmc), 00:90:4C:F9:AF:0E, hw, mtu 1500

sit0: unmanaged
	iptunnel (unknown), sw, mtu 1480

lo: unmanaged
	loopback (unknown), 00:00:00:00:00:00, sw, mtu 16436

It has the same issue as the i9100 for the p2p0 interface but I also can't get the wifi to work outside networkmanager today (see #36)

@ollieparanoid

This comment has been minimized.

Copy link
Member

commented Mar 3, 2018

It's clear that we need something like NM in the long term in order to support switching between cellular network and Wifi properly, just like one would expect on a phone. So... how about we note in the Wifi wiki article, that NetworkManager needs to be disabled in order to connect manually, and merge it now?

EDIT: @MartijnBraam: from the issue you've linked, have you tried that?

I don't think you can use BCM4329 for this phone. The hammerhead should be BCM4339

@MartijnBraam

This comment has been minimized.

Copy link
Member Author

commented Mar 3, 2018

You probably don't even need to disable networkmanager to connect manually, it should detect you've configured something manually and set it to unmanaged.

I think this PR can be merged since the NetworkManager functionality itself works, its now time to debug device specific stuff.

@PureTryOut PureTryOut force-pushed the feature/networkmanager branch from 53625ed to 37c00ab Mar 4, 2018

@ollieparanoid ollieparanoid merged commit 6e69c8d into master Mar 4, 2018

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 75.642%
Details

@ollieparanoid ollieparanoid deleted the feature/networkmanager branch Mar 4, 2018

postmarketOS-Wiki pushed a commit to postmarketOS/wiki that referenced this pull request Mar 4, 2018

postmarketOS-Wiki pushed a commit to postmarketOS/wiki that referenced this pull request Mar 4, 2018

fooforever added a commit to fooforever/pmbootstrap that referenced this pull request Mar 14, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.