RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1434434 - wpa_supplicant is responding to packets which are not destined for it.
Summary: wpa_supplicant is responding to packets which are not destined for it.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: wpa_supplicant
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 7.6
Assignee: Davide Caratti
QA Contact: Ken Benoit
Ioanna Gkioka
URL:
Whiteboard:
Depends On:
Blocks: 1477664 1554861 1582501
TreeView+ depends on / blocked
 
Reported: 2017-03-21 13:48 UTC by Fani Orestiadou
Modified: 2022-03-13 14:13 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
*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.
Clone Of:
: 1582501 (view as bug list)
Environment:
Last Closed: 2018-10-30 09:48:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4494841 0 None None None 2019-10-11 14:03:35 UTC
Red Hat Product Errata RHSA-2018:3107 0 None None None 2018-10-30 09:49:25 UTC

Description Fani Orestiadou 2017-03-21 13:48:35 UTC
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

Comment 26 Ken Benoit 2018-08-27 14:29:48 UTC
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.

Comment 28 errata-xmlrpc 2018-10-30 09:48:39 UTC
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


Note You need to log in before you can comment on or make changes to this bug.