On Thu, Sep 12, 2019 at 09:20:02PM +0200, Alexander Wetzel wrote:
Let wpa_supplicant/hostapd generated control frames bypass the QDISC
when the linux kernel supports the feature, to make sure the frames
are reaching the driver and are not delayed or dropped by QDISC.
What impact would this have on reliability of sending out the EAPOL
frames in cases where there is significant traffic load on the
interface? Documentation for PACKET_QDISC_BYPASS seems to imply that
this option is targeted for traffic testing applications and as a side
effect, this increases packet drops when transmit queues are busy. Would
all those drops be frames that go through qdisc or would this also apply
for the frames that go out through the socket that uses
PACKET_QDISC_BYPASS (i.e., these EAPOL frames)?
First, I do not think the patch should be merged as it is. PTK rekeying
is at the moment mostly broken and this patch is just replacing one
broken solution with a less broken one. I was hoping for some discussion
here how to generally handle that. That did not happen so far.
Second, I'll soon have a quite radical patch ready to address the PTK
rekey issues with what seems to be the only solution: Make rekeying
optional and use reconnects by default as replacement. There are just
too many broken implementations in the wild which in at least one case
enable plain text attacks on the outgoing PTK: Ath9k with mac80211 from
a kernel < 4.20 can repeat lost MPDUs but skips the encryption...
Generally all cards using HW crypto and mac80211 likely have some issues
with a kernel 4.20, which more or less added proper rekey support,
handling the corner cases. (ath10k is the known exception so far.)
But quite many authors seem to have missed at least some of the corner
cases PTK rekeying with only keyid 0 has I invite anyone believing that
rekey is working in his setup to set the rekey intervall to 30s and try
a download. Even with an AP able to handle that error free many devices
- probably most if my samples are representative - will have have
issues. Most common are download aborts, caused to to a reconnect due to
an error during rekeying. Making that to the default action and allow
users knowing what they do to override it seems to be the best way out
of the PTK rekey mess.
But pack to this patch here:
The patch would disconnect a STA when the socket refuse to accept the
MPDU. Now the easy fix would be to simply ignore send errors and trust
that one of the retransmits will be accepted and can get through.
But this should only be a fallback strategy when we can't use CONTROL PORT.
That said the current solution using QDISC is probably worse then just
hoping the HW is accepting the first send attempt. Short of a really
loaded connection the driver should be able to accept the MPDU. And when
the driver can't only the drives with special PTK rekeying hacks can
hope to rekey the PTK when we are using QDISC.
The price of using QDISC is, that when the send call returns one skb has
probably been send out, but next to sure not our EAPOL frame we just
added at the end of the queue. Assuming die QDISC queues are filled it
may take quite some time the MPDU is OTA and has therefore a very good
chance to get encrypted with the new key. Which will never be decrypted
by the AP and also cause a disconnect.
Setting PACKET_QDISC_BYPASS on the socket is just "jumping" QDISC.
- We lose retransmits handling when the HW is busy and not accepting
skb's. (Which is kind of dangerous to outsource in the first place)
+ We get the guarantee that the skb is at least in a driver buffer when
the send call returns (instead of a QDISC bufer)
This fixes a potential race when rekeying a connection under load:
Without that an EAPOL#4 frame send out by wpa_supplicant may not have
reached the driver when switching over to the new key, causing the AP to
disconnect the STA.
It would seem to me that it would be better to send and receive EAPOL
frames using nl80211 commands/events (i.e., same mechanism that is used
to perform authentication/association and key configuration) to get
matching behavior for all these management operations.
Yes, but CONTROL PORT is optionally and many drivers are not
implementing it.
The intend of this patch is to make sure the eapol#4 frame has at least
reached the driver when we replace the key.
Based on PACKET_QDISC_BYPASS documentation, I'm not convinced this
"makes sure" of that.. Using nl80211 commands for sending EAPOL-Key msg
4/4 and setting the key on the other hand would make that pretty clear
(or would provide clear error reporting if that is not the case).
I checked the code, not the documentation. The ioctl can only return
when the skb has been either accepted by the driver or hit an error
somewhere.
Now this is is just the quick & easy fix to make sure EAPOL#4 is at
least in the driver queues when we replace the key, as discussed here:
http://lists.infradead.org/pipermail/hostap/2019-September/040514.html
That other patch, i.e., EAPOL-over-nl80211 would seem to be a better
direction to finally get working. Was anyone still working on that or
can I assume that no one is going to address my comment on it (use it
more consistently for all EAPOL frames rather than have a special case
for EAPOL-Key)?
If nobody is else is I'll sooner or more likely later pick that up.
I just fear the final patch will be quite invasive when done proper and
is merging the eapol paths from hostapd and wpa_supplicant.
And while it should be the preferred path when available so far only
mac80211 is supporting it from the in-tree drivers.
Alexander
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
