Created attachment 1629063 [details] sudo journalctl -b -f Description of problem: I am unable to authenticate my ethernet connection using 802.1x in our company network with plasma-nm on KDE Plasma and Fedora 30. Version-Release number of selected component (if applicable): $ dnf info NetworkManager Last metadata expiration check: 0:00:07 ago on Fri 25 Oct 2019 10:32:40 AM CEST. Installed Packages Name : NetworkManager Epoch : 1 Version : 1.16.4 Release : 1.fc30 Architecture : x86_64 Size : 11 M Source : NetworkManager-1.16.4-1.fc30.src.rpm Repository : @System From repo : updates [...] $ dnf info plasma-nm Last metadata expiration check: 0:01:15 ago on Fri 25 Oct 2019 10:32:40 AM CEST. Installed Packages Name : plasma-nm Version : 5.15.5 Release : 1.fc30 Architecture : x86_64 Size : 5.4 M Source : plasma-nm-5.15.5-1.fc30.src.rpm Repository : @System From repo : updates [...] How reproducible: Every time. Steps to Reproduce: 1. Set up a wired connection in System Settings 2. Check "Use 802.1x security for this connection" - Authentication: "Tunneled TLS (TTLS)" - Anonymous identity: <empty> - Domain: <empty> - CA certificate: <path to file> (or leave <empty> for same results) - Inner authentication: "PAP" - Username: <CONNECTION_USERNAME> - Password: <...> - Select "Store password for this user only" 3. Watch `sudo journalctl -b -f` 4. Log packets with `sudo tcpdump -i enp0s31f6 -w net.pcap` 5. Click "Connect" button in plasma network manager applet 6. Answer the password dialogue that pops up after a while 7. Wait 8. Return to (6.) Actual results: Nothing visible happens. No connection is established. Expected results: Authentication would be successful and a connection established. Additional info: Please see attached logs from `sudo journalctl -b -f` (some parts are redacted in a hopefully obvious way). Our company's RADIUS server does not log any authentication attempts from my machine when trying to connect via ethernet. (It does log my authentication attempts when connecting via WiFi.) `sudo tcpdump -i enp0s31f6 -w net.pcap` (viewed with wireshark) logs a bunch of STP and LLDP packets, as well as the occasional 802.1x EAP "Request Identity" packet sent from our network hardware to 01:80:c2:00:00:03 (named "Nearest" in wireshark) and some IGMPv2 "Membership Query" packets from 0.0.0.0 to 224.0.0.1. In the whole dump there also appears exactly one broken LLC packet ("length field values goes past the end of the payload"). There appear to be no answers from my machine to the 802.1x EAP requests. Removing the "CA certificate" file from the network connection settings does not change anything. i.e. I am rather confident that the issue is not caused by an unknown / unauthorised certificate on our network hardware. In fact, from the network packet capture, I think our network hardware does not even get as far as sending a certificate. Probably because the identity request is not answered by my machine? The problem first appeared in the morning of 2019-10-18. The output of `sudo rpm -qa --last` for 2019-10-17 (i.e. the last updates before the problem occurred) are attached.
Created attachment 1629064 [details] sudo rpm -qa --last
Created attachment 1629077 [details] sudo rpm -qa --last
Hi, this is possibly related to bug 1759797. Since the rpm log doesn't mention NM , can you try to downgrade the kernel and see if it makes any difference? Also, can you please do as root: busctl set-property fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 fi.w1.wpa_supplicant1 DebugLevel s excessive nmcli general logging level trace then try to connect and attach logs from journal: journalctl -u NetworkManager -u wpa_supplicant --since='2 minutes ago' ? Thanks!
Created attachment 1629152 [details] journalctl -f, with debug logging enabled (In reply to Beniamino Galvani from comment #3) > Hi, this is possibly related to bug 1759797. Seems very similar indeed. The only counter indication I can see is that the other report happened a week earlier than when the problem started to affect my own system (probably; I have a fallback to WiFi, so there is some chance that I did not detect the failure to bring up the network immediately). > Also, can you please do as root: > > busctl set-property fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 > fi.w1.wpa_supplicant1 DebugLevel s excessive > nmcli general logging level trace > > then try to connect and attach logs from journal: > > journalctl -u NetworkManager -u wpa_supplicant --since='2 minutes ago' > > ? Thanks! I ran `journalctl -f > system.debug.log`, then redacted the file. I did not redact the `TX EAPOL - hexdump(len=4): 01 01 00 00` part that you requested more information on in bug #1759797 comment #19.
Created attachment 1629153 [details] journalctl -f, with debug logging enabled
(In reply to Beniamino Galvani from comment #3) > Since the rpm log doesn't mention NM , can you try to downgrade the kernel > and see if it makes any difference? I booted into Linux 5.2.18-200.fc30.x86_64 and can confirm that authenticating the ethernet connection works with this kernel version. I will remove kernel-core-5.3* and put `exclude=kernel*` in the `[main]` section of my dnf.conf for now. Thanks for the workaround!
(In reply to Dennis Schridde from comment #6) > I will remove kernel-core-5.3* and put `exclude=kernel*` in the `[main]` > section of my dnf.conf for now. I've found a better way, that does not hide the entire package from the package manager: sudo dnf install 'dnf-command(versionlock)' for x in kernel{,-core,-modules,-modules-extra}-5.3* ; do sudo dnf versionlock exclude $x ; done
I suspect the issue is the following: since the connection profile has "802-3-ethernet.auto-negotiate: yes", during the activation NM turns on auto-negotiation and the NIC brings the carrier down for some seconds to renegotiate the physical link. wpa_supplicant is not aware of it and sends the EAPoL start packets while the carrier is down, so the packet is lost. NM should be improved to wait for carrier before telling wpa_supplicant to authenticate.
(In reply to Beniamino Galvani from comment #8) > I suspect the issue is the following: since the connection profile has > "802-3-ethernet.auto-negotiate: yes", during the activation NM turns on > auto-negotiation and the NIC brings the carrier down for some seconds to > renegotiate the physical link. wpa_supplicant is not aware of it and sends > the EAPoL start packets while the carrier is down, so the packet is lost. NM > should be improved to wait for carrier before telling wpa_supplicant to > authenticate. I can confirm. I booted into Linux 5.3.6-200.fc30.x86_64, disabled auto negotiation and forced the device to 100Mbps. Afterwards, authentication succeeded and the connection was up. I also tried to set the speed to 1000Mbps (to get the full speed), but then the interface would not connect anymore.
Is a fix for this in the works? Reducing the connection speed to 100Mbps is not very convenient in the long run.
(In reply to Dennis Schridde from comment #10) > Is a fix for this in the works? Reducing the connection speed to 100Mbps is > not very convenient in the long run. I'm working on a fix. BTW, you should be able to avoid the handling of speed/auto-negotiation in NM with: nmcli connection modify $con_name ethernet.speed 0 ethernet.duplex "" ethernet.auto-negotiate no so that the carrier doesn't go down, and still the NIC should retain the default configuration which enables auto-negotiation.
(In reply to Beniamino Galvani from comment #11) > (In reply to Dennis Schridde from comment #10) > > Is a fix for this in the works? Reducing the connection speed to 100Mbps is > > not very convenient in the long run. > > I'm working on a fix. Thank you a lot! > BTW, you should be able to avoid the handling of > speed/auto-negotiation in NM with: > > nmcli connection modify $con_name ethernet.speed 0 ethernet.duplex "" > ethernet.auto-negotiate no > > so that the carrier doesn't go down, and still the NIC should retain the > default configuration which enables auto-negotiation. Thanks for that suggestion. Maybe KDE Plasma NetworkManager interprets the data from NetworkManager wrongly, but: $ nmcli connection show $conn_uuid 802-3-ethernet.speed: 0 802-3-ethernet.duplex: -- 802-3-ethernet.auto-negotiate: no shows up as Auto Negotiate: No, Speed: 100Mbps, Duplex: Half in its configuration dialogue.
(In reply to Dennis Schridde from comment #12) > Thanks for that suggestion. Maybe KDE Plasma NetworkManager interprets the > data from NetworkManager wrongly, but: > $ nmcli connection show $conn_uuid > 802-3-ethernet.speed: 0 > 802-3-ethernet.duplex: -- > 802-3-ethernet.auto-negotiate: no > > shows up as Auto Negotiate: No, Speed: 100Mbps, Duplex: Half in its > configuration dialogue. Yes, that seems wrong. This and bug 1759797 are actually the same issue, I'm going to close this one. I've filed a merge request upstream to fix the authentication failure. *** This bug has been marked as a duplicate of bug 1759797 ***
(In reply to Beniamino Galvani from comment #13) > (In reply to Dennis Schridde from comment #12) > > > Thanks for that suggestion. Maybe KDE Plasma NetworkManager interprets the > > data from NetworkManager wrongly, but: > > $ nmcli connection show $conn_uuid > > 802-3-ethernet.speed: 0 > > 802-3-ethernet.duplex: -- > > 802-3-ethernet.auto-negotiate: no > > > > shows up as Auto Negotiate: No, Speed: 100Mbps, Duplex: Half in its > > configuration dialogue. > > Yes, that seems wrong. There was already a KDE bug report on the matter. See-Also: https://bugs.kde.org/show_bug.cgi?id=413211
(In reply to Dennis Schridde from comment #14) > See-Also: https://bugs.kde.org/show_bug.cgi?id=413211 And there is a patch to fix this, currently in review: https://phabricator.kde.org/D24866 It appears that the devs have some questions regarding how NetworkManager behaves with certain settings, so if you could have a quick look at it that might help them merge it sooner.