Hide Forgot
*wpa_supplicant* no longer responds to packets whose destination address does not match the interface address Previously, when *wpa_supplicant* was running on a Linux interface that was configured in `promiscuous` mode, incoming Extensible Authentication Protocol over LAN (EAPOL) packets were processed regardless of the destination address in the frame. However, *wpa_supplicant* checked the destination address only if the interface was enslaved to a bridge. As a consequence, in certain cases, *wpa_supplicant* was responding to EAPOL packets when the destination address was not the interface address. With this update, a socket filter has been added that allows the kernel to discard unicast EAPOL packets whose destination address does not match the interface address, and the described problem no longer occurs.
Description of problem: [ENVIRONMENT] Wired network with VMWare Player 6 in bridged networking mode running on RHEL machine. Customer is running authentication on a wired network. About once per day, the authentication session expires and the wpa_supplicant gets a request to re-authenticate. Everything works fine, until a VM is started inside the RHEL machine using VMWare player in bridged mode, and the VM needs to authenticate itself as well. When EAP packets are sent to the guest, not only the VM is responding, but also the wpa_supplicant on the host is responding (RHEL). So in short, the host is responding to the EAP packets no matter if the packets are destined to the guest and this causes the "wpa_cli status" throwing errors. When same VM is running on a Windows host, the issue is not present as the host does not reply to the traffic being sent to the guest. Also, when KVM is used instead of VMWare player, issue cannot be reproduced. Version-Release number of selected component (if applicable): wpa_supplicant-0.7.3-8.el6_8.1.x86_64 How reproducible: I am not sure whether we can set same environment so we can reproduce the issue. Actual results: wpa_supplicant configured on RHEL host is responding to packets destined for a VM guest running on the host. Expected results: wpa_supplicant to not interfere with packets destined to different machine. Additional info: Captures where the issue is visible Packets destined to VM guest 1 2016-12-15 05:18:28 0 Cisco_8e:c6:11 -> Vmware_0a:db:28 EAP 60 Request, Identity 2 2016-12-15 05:18:28 0 HewlettP_e4:cc:74 -> Nearest EAP 43 Response, Identity <---- RHEL machine is answering 3 2016-12-15 05:18:28 0 Vmware_0a:db:28 -> Nearest EAP 55 Response, Identity 4 2016-12-15 05:18:28 0 Vmware_0a:db:28 -> Nearest EAP 55 Response, Identity 5 2016-12-15 05:18:28 0 Cisco_8e:c6:11 -> Vmware_0a:db:28 EAP 60 Request, TLS EAP (EAP-TLS) 6 2016-12-15 05:18:28 0 HewlettP_e4:cc:74 -> Nearest SSL 211 Client Hello <----- 7 2016-12-15 05:18:28 0 Vmware_0a:db:28 -> Nearest SSL 125 Client Hello 8 2016-12-15 05:18:28 0 Vmware_0a:db:28 -> Nearest SSL 125 Client Hello Packets destined to the host to re-authenticate and there is no problem. 42 2016-12-15 10:24:09 18340 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 EAP 60 Request, Identity 43 2016-12-15 10:24:09 0 HewlettP_e4:cc:74 -> Nearest EAP 43 Response, Identity 44 2016-12-15 10:24:09 0 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 EAP 60 Request, TLS EAP (EAP-TLS) 45 2016-12-15 10:24:09 0 HewlettP_e4:cc:74 -> Nearest TLSv1 179 Client Hello 46 2016-12-15 10:24:09 0 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 EAP 1030 Request, TLS EAP (EAP-TLS) 47 2016-12-15 10:24:09 0 HewlettP_e4:cc:74 -> Nearest EAP 24 Response, TLS EAP (EAP-TLS) 48 2016-12-15 10:24:09 0 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 EAP 1026 Request, TLS EAP (EAP-TLS) 49 2016-12-15 10:24:09 0 HewlettP_e4:cc:74 -> Nearest EAP 24 Response, TLS EAP (EAP-TLS) 50 2016-12-15 10:24:09 0 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 EAP 1026 Request, TLS EAP (EAP-TLS) 51 2016-12-15 10:24:09 0 HewlettP_e4:cc:74 -> Nearest EAP 24 Response, TLS EAP (EAP-TLS) 52 2016-12-15 10:24:09 0 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 TLSv1 193 Server Hello, Certificate, Certificate Request, Server Hello Done 53 2016-12-15 10:24:09 0 HewlettP_e4:cc:74 -> Nearest EAP 1426 Response, TLS EAP (EAP-TLS) 54 2016-12-15 10:24:09 0 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 EAP 60 Request, TLS EAP (EAP-TLS) 55 2016-12-15 10:24:09 0 HewlettP_e4:cc:74 -> Nearest TLSv1 611 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message 56 2016-12-15 10:24:09 0 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 TLSv1 83 Change Cipher Spec, Encrypted Handshake Message 57 2016-12-15 10:24:09 0 HewlettP_e4:cc:74 -> Nearest EAP 24 Response, TLS EAP (EAP-TLS) 58 2016-12-15 10:24:10 0 Cisco_8e:c6:11 -> HewlettP_e4:cc:74 EAP 60 Success Please let me know if additional info in needed. Thank you
http://lists.infradead.org/pipermail/hostap/2017-December/038137.html
Used the reproducer supplied in comment 3 (with some fixes to the script and updated certs) and confirmed that tcpdump captured a packet ("vetha: CTRL-EVENT-EAP-STARTED EAP authentication started") when the reproducer was run against RHEL-7.5. Installed RHEL-7.6-20180823.n.0 on the system and reran the reproducer. tcpdump did not capture any packets on that run. Marking as verified.
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/RHSA-2018:3107