In best case, while the connection is upgraded, established connections should survive.

Perhaps NM should implement a 802.1x.fallback-noauth option that allows to fall back to unauthenticated access when authentication fails. Windows has a similar option: https://social.technet.microsoft.com/Forums/getfile/1233569 . Related discussion: https://bugzilla.gnome.org/show_bug.cgi?id=723084

When the authentication fails, NM would keep retrying periodically to upgrade to an authenticated access.

Maybe an option would be, to build some junction between non-authorized, limited network connection and appropriate authenticated connection.
This might provide some more security, to only fall back to connections, which are wanted to use.

Just as an idea. Is there a way to get this discussion in [1] to get more speed? I see it's very old and such feature is still not existing. Only the timeout was improved, which is totally related to this request.

[1]: https://bugzilla.gnome.org/show_bug.cgi?id=723084

Hi,

we are currently evaluating different approaches to implement this
functionality.


In the first, a new 'optional' boolean property is added to the 802-1x
setting. When it is set to true, the failure of 802.1X doesn't cause a
connection failure. Instead, upon failure NM continues with activation
and keeps wpa_supplicant alive. If the supplicant is able to complete
authentication later, NM restarts DHCP to guarantee a fresh address is
obtained for the authenticated network. Since it makes sense to have
different firewall zones for authenticated and non-authenticated
networks we would probably need also a new '802-1x.fallback-zone'
property.


In the second approach two profiles are defined, one for the
authenticated network and one for the unauthenticated one; the first
profile references the second one in the '802-1x.fallback-connection'
property. When the first connection fails to authenticate, NM swaps
the settings in the current ActiveConnection with the ones from the
second profile and reapplies them without tearing the device
down. When doing it, it also keeps the supplicant alive so that the
swap can done again later if the authentication succeeds.

These profile swaps are something new and they need core changes that
might not be trivial to implement. The advantage of this second
approach is that it becomes possible to define different settings
(like the firewall zone, or IP configuration) for the two
connections. But perhaps from a user point of view it is simpler to
just set an 802-1x.optional=yes flag instead of defining two profiles.


I will update you when there are news regarding the development of
this feature.

Hi,

this sounds really interesting. I looking forward to get some news.

Thanks.

Hi,

in the support cases attached to this bz, the customer mentions that
running wpa_supplicant alone without NM on the interface lets the
client connect to network even if the authentication server is
temporarily down, as the client is put in a limited-access network.

I have a few questions regarding this setup. Does the limited-access
network use a different DHCP server than the authenticated one? If so,
what happens after the infrastructure is restored, does the client
have to wait the lease expiration to get a valid address in the
authenticated network?

Also, how does the switch completes authentication when the
authentication server is not available? I tried this locally and I see
the switch performs 3 authentication attempts, each returning a
failure, and afterwards it sends an EAP-success, putting the client
into a separate VLAN. But since I couldn't find any documentation in
standards about this behavior, I'm wondering if it is implemented in
the same way by all vendors.

Would it be possible to ask the customer to provide a packet capture
of the authentication and DHCP phases when using wpa_supplicant alone
during the outage? And, if possible, also a capture of what happens
when the infrastructure comes up again.

Thanks!

Hey Beniamino,

I've talked with my customer, and beside the questions from your side totally make sense, they are not applicable to their environment.
If the client is unauthenticated, it's basically impossible to do anything. The connection is limited to a few basic protocols like DHCP, ICMP and DNS. Anything else is blocked by infrastructure (switch).
If there is an outage of Authentication service, e.g. RADIUS, it will be out of scope. The only thing, which matter is if 802.1x available, NetworkManager should try to authenticate. If there is nothing like this available, stay at "fallback"-connection and try to authenticate from time to time.

Does it make sense?

/steffen

Hi Steffen,

I have prepared a RFC branch [1] that adds a new 'optional' property
to the 802-1x setting. When it is set to TRUE, NM will not fail the
activation upon authentication timeout or failure, and will instead
continue, leaving wpa_supplicant running. wpa_supplicant tries to 
reauthenticate every 60 seconds.

I think should address the customer's needs, please let me know
otherwise.

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/249

Created attachment 1615997 [details]
test script

Merged upstream:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/495ae4a6761b1c458fa40cca501652e201243cac

Is see that this is Fixed In Version: NetworkManager-1.22.0-0.1.el8.  Will the fix become available in Fedora 31, too?

(In reply to Dennis Schridde from comment #34)
> Is see that this is Fixed In Version: NetworkManager-1.22.0-0.1.el8.  Will
> the fix become available in Fedora 31, too?

Yes, it is already in F31 (NetworkManager-1.20.6-1.fc31).

Hi Vlad,

connection.auth-retries is the number of retries with a new password supplied by a secret agent. If there is no agent (i.e. no '--ask') the activation fails after the first attempt (after 20 seconds).

Ideally the reproducer for this RFE would be similar to the script attached to this bz. But if it is too complicated, we can check that when setting 802-1x.optional=yes and there is no authenticator, the connection is established after the timeout period.

test @8021x_auto_auth_retry_with_backup_network added

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1847