The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Paul Dekkers <paul.dekkers AT surf.nl>]

Hi Jethro,

On 29/11/2023 11:35, Jethro Binks wrote:

LO0P265MB5894B297927B8DF39EDD189EB383A AT LO0P265MB5894.GBRP265.PROD.OUTLOOK.COM">

Paul said:

"P.S. I can go in a bit more detail about the challenges we still have

for the geteduroam version, maybe I'll share in a separate post, but

that would be a lengthy mail ;-)"

The holidays are coming, we will have time 🙂.

Haha, so now you ask:

Since Android 11 there are basically two ways to install a WiFi profile on Android (and one of the two options works (partly) on Android 10, but that's an entirely different story).

You can install a WiFi network as "saved network", just like what a user would do, and in a way that's managed by the App.

The advantage of the "saved network" is that in principle you could even remove the App afterwards. You would lose reminders that your account is going to expire. The current geteduroam App uses this approach, but it doesn't do this for Passpoint because it has disadvantages too.

The disadvantage is that you cannot manage the App/remove it, but only overwrite it. It's possible that if you switch from IdP (eg. from pseudo accounts to a u/p profile) that some settings are still "stale" and the profile fails (happened since recent Android versions), but the question then is how likely it is that people change from pseudo to u/p (maybe more likely the other way around).

The other disadvantage is that while you can overwrite SSID profiles for eduroam, you can't for Passpoint so they end up with double entries. This is why the current App only used saved networks for the eduroam SSID and not Passpoint.

The third disadvantage is that apparently on ChromeOS, the new network isn't overwritten if you're currently connected to it.

Now the "managed by App" like version, makes the network config a bit more hidden. In fact, it would still be possible to manage a network by yourself, and you need to delete any "saved networks" for eduroam to make the phone decide to use the "via geteduroam" version. But migrating between one and the other profile works well, the App is able to manage these networks and that's also why you don't end up with multiple passpoint profiles.

The downside is that on older Android versions, it's not very clear that the App "did something": if you'd click on the SSID, it would still allow you to configure settings (for some Android versions), so people may think that the network isn't configured (this happens to in particular power users we noticed). This is worst on Android 11, which is unfortunately what ChromeOS uses, so that makes it a bit less clear for ChromeOS. Sometimes it's clearer when you disabled WiFi briefly. On Android 10 it's even worse: you need to click a silent notification, but that's just something very broken in Android 10 that's never going to be fixed but something we'd have to accept. We can include an instruction.

If you remove the App, you remove all managed networks. That can also be seen as an advantage.

Migrating from one to the other seems to be a bit painfull, in particular from saved networks to the managed version because you need to delete the saved version manually.

In general the "via app" managed solution seems to be a little preferred, since it got better in more recent Android. Not per se on ChromeOS: for getgovroam we already released a version that uses the "via app" managed workflow, the old App also did that. For ChromeOS we stick to the "saved network" for now, but it doesn't overwrite old networks. I plan to contact Google about that.

For geteduroam we always used the "saved network" approach, from Android 12 on. It was buggy in the first Android 11 release, and Google fixed that but not all OEMs got that code. We may need to switch as more recent Android versions do a bit better, but we're not 100% certain this is the best decision yet. (So feedback is appreciated. And perhaps a test version would help also, we can consider to open up the beta.)

Regards,

Paul

LO0P265MB5894B297927B8DF39EDD189EB383A AT LO0P265MB5894.GBRP265.PROD.OUTLOOK.COM">

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 

Jethro R Binks, Network Manager, 

Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in Scotland, number SC015263.

---

From: cat-users-request AT lists.geant.org <cat-users-request AT lists.geant.org> on behalf of Paul Dekkers <cat-users AT lists.geant.org>
Sent: 29 November 2023 10:24
To: Lukas Wringer <Lukas.Wringer AT rz.uni-augsburg.de>; cat-users AT lists.geant.org <cat-users AT lists.geant.org>
Subject: Re: [[cat-users]] eduroam on ChromeOS ist very, very weird....

 

Hi,

Worth sharing is that we are very close to having a geteduroam version
available for ChromeOS. It's part of the redeveloped version for Android.

We already released it for getgovroam, we need to do some more tests and
make some more and maybe different choices for geteduroam, but I think
we'll try to release it soon, maybe even before the end of the year.

For ChromeOS there's two (outside of ONC) ways to install the profiles,
and both have caveats, but I kind of like it a lot we'll be able to do
this with geteduroam, as it appears more friendly to me compared to ONC
or a manual config.

Regards,
Paul

P.S. I can go in a bit more detail about the challenges we still have
for the geteduroam version, maybe I'll share in a separate post, but
that would be a lengthy mail ;-)


On 29/11/2023 11:10, Lukas Wringer (via cat-users Mailing List) wrote:
> Hi,
>
> as Chromebooks are becomming somewhat more common I sat down to test
> some of our services if and how they work on ChromeOS for example
> eduroam.
>
> A bit of background Info:
>
> Some EAP-Methods require specific settings to be actually secure and
> are protected against fake "Rouge-APs" - For example: EAP-TTLS(PAP)
> should configure both, the Root-CA used to issue the RADIUS-Certificate
> and the (alt-)subject-match with the name of the actual RADIUS to
> match.
>
> CAT makes sure these settings are applied across all supported devices
> especially in cases like (older) Android or (modern) Apple Devices
> where these options are not exposed to the GUI.
>
> ChromeOS in this regard is confusing at best - on some devices and
> versions the required settings are actually available in the GUI on
> some they don't and one some only partially but not consistent.
>
> CAT provides an ONC-Profile that can be imported via chrome://network
> that **should** configure this values. But at least in my experience
> that is not always the case.
>
> What I have experienced so far is that if the used CA is already known
> to the system, the imported configuration will fail (which is always
> the case when using a known Trusted-CA)
>
> When using a self-signed (or not Trusted) ca-certifcate the import will
> work - if not for the other possible error when on systems that don't
> expose the corresponding values for CA-Verfication and (alt)subject-
> match.
>
> Now comes the ridiculous part - the first problem can be fixed in a
> very weird way which also solves the problem when trying to manually
> configure eduroam:
>
> CA-Certificates can be manually imported via
> chrome://settings/certificates - *but* normally only if they are _not_
> already known (it will just throw an error).
>
> But here comes the trick: if you use the tab for "Server"-certificates
> it will actually import the CA into the correct CA-Tab for roots and
> can now be configured to be trusted for websites.
>
> If an ONC-Profile is already installed it will now be fixed
> automagically and the CA can be specifically selected in manual
> configuration.
>
> The only catch - the CA can not be deleted like other manually imported
> CAs...
>
> Hopefully Googles proposed project Lacros will finaly move these
> settings out of the webbrowser into the system and fix some of this
> weirdness...
>
> Greetings, Lukas
>
To unsubscribe, send this message: mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
Or use the following link: https://lists.geant.org/sympa/sigrequest/cat-users