Re: [PATCH] EAPOL_SUPP: ignore Response at CONNECTING state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,Jouni,
  Thank you for your reply.
eOn 18 4月 22 17:49:04, Jouni Malinen wrote:
> On Thu, Jan 06, 2022 at 09:47:27AM +0800, xinpeng wang wrote:
> > When using PEAP certification, the server may use Identity's Request message
> > as a heartbeat; there will be many clients on the Internet to send address
> > 01: 80: C2: 00: 03 Identity's Response message as a heartbeat; at this time
> > When a client is broken and reconnect, it is easy to receive this message,
> > resulting in triggering restart of EAPOL authentication, resulting in a slow
> > authentication. So Ignore the response message in the Connecting state.
> 
> This sounds really confusing.. Why would a Supplicant process an EAP
> response message in any state (well, with the exception of the quite
> unfortunate LEAP design)? What is special about the CONNECTING state in

In a network using PEAP authentication, the server sends a Request Identity 
message to all clients as a heartbeat message, and the client's suppliant 
will then broadcast an Identity Response message to 01:80:C2:00:00:03 as a 
heartbeat response, so that the suppliant may be at any time received 
broadcast EAP Response message.

> this context? That said, it is quite inconvenient if the EAPOL state
> machine needs to peek into the EAP header for something like this..
>
When the supplicant disconnects and reconnects, it first enters 
SUPP_PAE_CONNECTING from SUPP_PAE_DISCONNECTED. At this time, a timer of 
2s will start. After the timeout, if it is still in SUPP_PAE_CONNECTING, 
an eapol start message will be sent to start reconnection authentication. 
If any EAP message is received within 2s, a state transition occurs so 
that no eapol start message can be issued after the 2s timeout.

Due to many EAP Response heartbeat response messages on the network, the 
supplicant is prone to the above situation, resulting in eapol start not 
being sent within 2s.

> How commonly does this happen? Based on the that address, I'd assuming
> this is about use of EAPOL/IEEE 802.1X on a wired Ethernet interface
> rather than anything with Wi-Fi. Though, that should have been with one
> more zero octet: 01:80:C2:00:00:03, i.e., the PAE group address. Would
> you be able to share some debug logs showing the undesired behavior?
>

Networks that use PEAP authentication and use Request Identity messages as 
heartbeat messages are prone to this problem. 
debug log:(Where "startWhen --> 0" in the log should have issued an eapol 
start message, but there is none here.)
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: External notification - portEnabled=0
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: External notification - portValid=0
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: External notification - portEnabled=1
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_PAE entering state CONNECTING
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state IDLE
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state INITIALIZE
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state IDLE
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: eno1: Cancelling scan request
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: eno1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: dbus: flush_object_timeout_handler: Timeout - 
sending changed properties of object /fi/w1/wpa_supplicant1/Interfaces/3
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: l2_packet_receive: src=1c:83:41:72:08:f3 len=46
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: eno1: RX EAPOL from 1c:83:41:72:08:f3
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: RX EAPOL - hexdump(len=46): 01 00 00 0d 02 77 00 
0d 01 55 54 30 30 32 39 39 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: Received EAP-Packet frame
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_PAE entering state RESTART
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state INITIALIZE
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state IDLE
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_PAE entering state AUTHENTICATING
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state REQUEST
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: getSuppRsp
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state RECEIVED
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: Ignored EAP-Response
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state DISCARD
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state IDLE
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state RECEIVE
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: l2_packet_receive: src=6c:eb:b6:02:08:2a len=46
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: eno1: RX EAPOL from 6c:eb:b6:02:08:2a
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: RX EAPOL - hexdump(len=46): 01 00 00 0d 02 65 00 
0d 01 75 74 30 30 30 33 32 37 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: Received EAP-Packet frame
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state REQUEST
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: getSuppRsp
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state RECEIVED
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: Ignored EAP-Response
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state DISCARD
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAP: EAP entering state IDLE
12月 08 16:22:05 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state RECEIVE
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: l2_packet_receive: src=74:d6:cb:a5:2e:e2 len=46
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: eno1: RX EAPOL from 74:d6:cb:a5:2e:e2
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 
05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: Received EAP-Packet frame
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state REQUEST
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: getSuppRsp
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP entering state RECEIVED
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: Received EAP-Request id=1 method=1 vendor=0 vendorMethod=0
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP entering state IDENTITY
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: eno1: CTRL-EVENT-EAP-STARTED EAP authentication started
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: Status notification: started (param=)
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP-Request Identity data - hexdump_ascii(len=0):
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: using real identity - hexdump_ascii(len=8):
12月 08 16:22:06 aris-PC wpa_supplicant[2121]:      75 74 30 30 31 30 31 36                           ut001016
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP entering state SEND_RESPONSE
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP entering state IDLE
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state RESPONSE
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: txSuppRsp
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: TX EAPOL: dst=01:80:c2:00:00:03
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: TX EAPOL - hexdump(len=17): 01 00 00 0d 02 01 00 0d 01 75 74 30 30 31 30 31 36
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state RECEIVE
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: l2_packet_receive: src=74:d6:cb:a5:2e:e2 len=46
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: eno1: RX EAPOL from 74:d6:cb:a5:2e:e2
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: RX EAPOL - hexdump(len=46): 01 00 00 05 01 01 00 
05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: Received EAP-Packet frame
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state REQUEST
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: getSuppRsp
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP entering state RECEIVED
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: Received EAP-Request id=1 method=1 vendor=0 vendorMethod=0
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP entering state RETRANSMIT
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP entering state SEND_RESPONSE
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAP: EAP entering state IDLE
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state RESPONSE
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: txSuppRsp
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: TX EAPOL: dst=01:80:c2:00:00:03
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: TX EAPOL - hexdump(len=17): 01 00 00 0d 02 01 00 0d 01 75 74 30 30 31 30 31 36
12月 08 16:22:06 aris-PC wpa_supplicant[2121]: EAPOL: SUPP_BE entering state RECEIVE
12月 08 16:22:07 aris-PC wpa_supplicant[2121]: EAPOL: startWhen --> 0
> -- 
> Jouni Malinen                                            PGP id EFC895FA
> 



_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux