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

[Tomasz Wolniewicz <address@concealed>]

Hi,

   it seems from the older mails that such characters made login impossible even if one simply typed the password into the Windows prompt, thus without pushing the password via the CAT (or geteduroam) installer. It this is true then we could perhaps still try to put the password in in some encoded form in a better way that the Windows prompt can do, but it would be great to have a clear picture on this.

Of course I can set up my own tests for this, but if you already have such results then it would save time.

Cheers

Tomasz

W dniu 27.02.2026 o 16:50, Stefan Paetow (via cat-users Mailing List) pisze:

Ahhh,

 

The joys of character encoding (UTF-8 and UTF-16). We have the same issue with £… it has a different ASCII value (in the ASCII extended characters list, character 156) to its UTF-8 equivalent, and the same goes for UTF-16 encodings. AFAIK Windows now lives and breathes ‘w_char’, which is UTF-16 (I think – I’ve not done Windows development for quite a while).

 

So one suggestion is to make sure characters are stored as UTF-8 (especially on Windows).

 

We also had this issue internally where a £ sign existed in a test account password ok throughout our setup until it hit the database, and it was then retrieved to be send to a NRPS (for a test). My way of working around it was Base64-encoding it and storing the Base64 value, then passing the Base64 value between servers). It’s ridiculous, but there we are. :-/

 

Kind regards

 

Stefan Paetow

Federated Roaming Technical Specialist

eduroam(UK), Jisc

 

email/teams: address@concealed

gpg: 0x3FCE5142

 

For eduroam support, please contact the eduroam team via address@concealed and mark it for eduroam’s attention.

I am not available on Mondays and Fridays between 12:00 and 15:00 London time (UTC in winter, UTC+0100 in summer).

 

Note: I don’t expect a reply outside of your working hours, since I work internationally with colleagues in different nationalities with different religions, customs, and holidays. Reply when it is convenient for you.

 

Jisc is a registered charity (in England and Wales under charity number 1149740; in Scotland under charity number SC053607) and a company limited by guarantee registered in England under company number 05747339, VAT number GB 197 0632 86. Jisc's registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.

 

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.

 

For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice

 

 

From: <address@concealed> on behalf of Tom Ivar Myren <address@concealed>
Reply to: Tom Ivar Myren <address@concealed>
Date: Friday, 27 February 2026 at 15:33
To: Philippe Taurines <address@concealed>, Tomasz Wolniewicz <address@concealed>, "address@concealed" <address@concealed>
Subject: [[cat-users]] Svar: Windows Authentication Issue (MSCHAPv2 / €) - Request for Feedback

 

Hi Philippe / Tomasz

I am way behind reading this e-mail but found this interesting.

 

We have seen the same behavior with the Norwegian characters [æ ø å Æ Ø Å]

In our case we use eduroam with TTLS/PAP.

The above characters work fine in passwords, but not for Windows 10/11 and eduroam.

With Android, Mac, iPhone no problems.

With Windows and for example Entra ID, no problem.

 

/Tom 

 

 

Fra: address@concealed <address@concealed> på vegne av Philippe Taurines <address@concealed>
Dato: onsdag, 17. september 2025 kl. 13:06
Til: Tomasz Wolniewicz <address@concealed>, address@concealed <address@concealed>, address@concealed <address@concealed>
Emne: RE: [[cat-users]] Windows Authentication Issue (MSCHAPv2 / €) - Request for Feedback

Hello Tomasz,

 

Thanks for this suggestion. I just checked it after forgetting the eduroam Wi-Fi network and eduroam®.

 

And here is the result of the configuration using only the Windows login without cat-eduroam:

 

1.      If the password contains the "€" character, the eduroam login does not work.

 

2.      If the password does not contain the "€" character, the eduroam login works.

 

And I found this thread that seems to address this issue: https://community.arubanetworks.com/discussion/special-characters-in-passwords-peap

 

It seems a real shame that no one has been able to resolve this issue for years. It's likely that many users are turning away from using eduroam because they don't understand why the login isn't working on their computers.

 

If anyone is able to submit a report to Microsoft, that might be another avenue to fix this bug.

 

If any of you have any ideas for fixing this or a list of problematic characters, that would be a good start.

 

Sincerely,

 

De : Tomasz Wolniewicz <address@concealed>
Envoyé : mercredi 17 septembre 2025 11:26
À : Philippe Taurines <address@concealed>; address@concealed; address@concealed
Objet : Re: [[cat-users]] Windows Authentication Issue (MSCHAPv2 / €) - Request for Feedback

 

Hi,

  Did you try delete all eduroam profiles and just connect to eduroam without prior CAT installation. Windows should pop up some confirmations but it should connect. This test would tell us if it is the actual Windows supplicant fault or perhaps a CAT error in handling the password with this character.

I will do my own tests as well, of course.

Yours

Tomasz Wolniewicz

W dniu 17.09.2025 o 11:08, Philippe Taurines (via cat-users Mailing List) pisze:

Hello,

 

We are experiencing an authentication issue with Windows 11 clients when the user's password contains the character "€".

 

We have observed the following behavior with a FreeRADIUS server and MSCHAPv2 authentication:

 

1. Windows 11 client: Connection fails if the password contains a "€".

2. Android client: Connection works, even if the password contains a "€".

3. Windows 11 client (without a "€"): Connection works.

4. Android client (without a "€"): Connection works.

 

What seems even more surprising to me is when configuring the Windows supplicant with cat-eduroam, analyzing the connection logs on the radius servers:

 

1. With an invalid password and without the "€" symbol, the client's connection attempt is clearly visible in the radius server logs.

2. With an invalid password and the "€" symbol, the client's connection attempt is not visible in the radius server logs.

3. With a valid password and the "€" symbol, the client's connection attempt is not visible in the radius server logs.

4. With a valid password and without the "€" symbol, the client's connection attempt is visible in the radius server logs.

 

This behavior suggests that the problem lies with the Windows supplicant.

 

Have you ever encountered a similar problem or do you have any feedback to share on this issue?

 

Are there any other characters you know of that might not be well supported?

 

Sincerely,

-- 

Tomasz Wolniewicz

To unsubscribe, send this message: mailto:address@concealed?subject=unsubscribe%20cat-users
Or use the following link: https://lists.geant.org/sympa/sigrequest/cat-users

      To
        unsubscribe, send this message:
        mailto:address@concealed?subject=unsubscribe%20cat-users
        Or use the following link:
        https://lists.geant.org/sympa/sigrequest/cat-users
    
-- 
Tomasz Wolniewicz

Attachment: smime.p7s
Description: Kryptograficzna sygnatura S/MIME