Re: Support for Intel Active Management Technology over wireless in Linux

[Emmanuel Grumbach <egrumbach gmail com>]

On Tue, Jun 1, 2021 at 8:26 PM Thomas Haller <thaller redhat com> wrote:
> On Thu, 2021-05-27 at 21:40 +0300, Emmanuel Grumbach via
> networkmanager-list wrote:
> > Disclaimer: This feature is available only on vPRO Platforms.
> >
> > Question to the NM maintainers:
> > Would you consider merging patches that would implement this?
>
> Definitely. The most important property for implementing a feature is
> that the underlying dependencies are also open soure and merged
> upstream. In this case, the requirement is that (upstream) kernel and
> (upstream) wpa_supplicant can support this feature -- or at least,
> there is a real possibility that it will support it in the future.

Sure, the kernel patches will be included in 5.14.

> That you need a special hardware is fine. It however poses a practical
> problem if upstream contributors cannot test/contribute to it. It
> basically means that those contibutors who care about this feature (and
> can test it) need to carry more burden than usual.

I don't expect to have many more contributors than Intel itself :)
We will work on this: write the code, test it etc...
If there is a testing infra for the NetworkManager, we can see how
we can add test to this infra etc...
But I agree, contributors that don't have the setup will be in trouble.

> > Do you see any blocker to implement this?
>
> Maybe the handling of RFKILL in NetworkManager requires some cleanup
> first. That would be in `src/core/nm-manager.c` and `src/core/rf-kill-
> manager.c`.

Sure, I guess we can cope with that.

> Your description is very detailed. Thank you. It does not sound
> entirely trivial to me however :).
>
> NetworkManager is mostly about having connection profiles and
> activating them. It's not clear to me how this ATM fits with that
> model. Would the user still configure a connection profile? Should a
> connection profile be auto-generated (there are cases where wo do that,
> for example for bluetooth paired devices).

Yes, of course, the NetworkManager will still have connection profiles.
That's the whole point of the RFKILL thing.
NetworkManager has connection profiles configured say:
1) myAP@home
2) MyEmployerEnterpriseNetwork
3) MyPhoneHotspot

AMT on the system's chipset also has profiles. Now, since AMT is more an
enterprise feature, you will have only the profile number 2 configured there.
Note that NetworkManager has no clue about what profiles are configured in
AMT. We could do some profile sync, but this is out of scope (for now - but
there is a user space service that knows how to talk to the NetworkManager
through D-BUS that could possibly do that https://github.com/intel/lms).
Just  imagine that before giving you your machine, the IT department of your
company configured the profile 2) in AMT through the BIOS, and then you
install a Linux distro on your system.

Fine.

Now we get into the flow I described: your machine boots while AMT is having
an active TCP connection. Because of that, AMT will tell the kernel not to touch
the device because we want not to break the TCP connection, and the NM gets
RFKILL.
Here's where NM gets into action. It looks at the profile that AMT is
associated to.
This profile is 2). It fetches the frequency and the BSSID of the AP
we're connected
to in that ESSID.
Profile 2 is supported by NM (it was configured as a connection
profile), so NM *knows*
that it can connect to that profile. This means that NM can get the
device and restore
the link. In order to do so, NM will automatically generate a "hidden"
connection profile
and configure it to the wpa_supplicant. It has the exact same
properties as 2), but it has
a few additional properties: the bssid and the scan_freq. Thanks to
that, the supplicant
won't spend time scanning. NM must *not* do a full scan either, and
then you'll be able to
connect in less than 500ms. Note that you connect to profile 2), a
known connection profile.
Then, NM requests ownership, which removes the RFKILL state, and the supplicant
can associate immediately.
Had AMT replied to NM that it is connection to
MyEmployerEnterpriseNetworkThatNMDoesNotKnow, NM would get to the
conclusion that
it cannot take the device and AMT will keep the device.

There is one thing I didn't mention.
AMT will monitor the connection. If it doesn't see an answer to the DHCP request
within 3 seconds, it'll take the device back (RFKILL again) to avoid
to break the TCP
connection.

Another thing. When the AMT TCP connection is over, NM will get a
notification to say:
back to normal. At this point NM can remove the "sub profile" and use
the normal profile 2)
which will allow to roam etc...

So TD;LR: Yes we use connection profiles (we don't pass the security
credentials over
the new kernel / userspace APIs, so the profile must exist). We just
add a new "sub profile"
that includes the same parameters, but only 1 AP of that ESSID.

Hope this was clearer.

> > Any recommendation for the implementation?
>
> NetworkManager does talk relatively little nl80211 to kernel. Mostly it
> only configures wpa_supplicant. And most things happen when
> "activating" a profile in NetworkManager.
>
> I don't have concrete suggestions. Did you look at NetworkManager
> alraeady? Maybe we can find first "simpler" steps and break this down?

I took a brief look, and yes, I saw it mainly talks D-BUS to the wpa_supplicant.
I guess it only adds one single connection profile at a time, right?
You can technically add several network configuration to the
wpa_supplicant, and let it
choose to whom to connect, but I guess NM configures only one network, right?
Sure, I have simpler tasks I can start with the first NL80211 vendor messages.
Of course, I am on other critical stuff for now, but I guess I'll be
able to start in a few weeks..

> best,
> Thomas