On Wed, 2018-07-18 at 17:28 -0400, Paul W. Frields wrote:
> Hi Davide,
>
> The Magazine editorial board reviewed the pitch/draft you submitted to
> the Magazine about PMF. We liked the idea that this content helps
> users solve a problem they may run into if they upgrade to Fedora 28.
> However, it was also very detailed in ways that will probably deter
> readers from reading the article.
(cc-ing Francesco as he reviewed the post)
sorry for answering late: I was on vacation in the last two weeks.
I felt the need for adding some details on how to troubleshoot PMF on
fedora, as we are receiving many bugzilla notifications from users
experiencing wifi connectivity troubles, and almost all of them relate to
PMF.
All users restored connectivity by disabling PMF with nmcli, like I
suggest at the end of the second chapter. Nevertheless, PMF is a security
improvement and users should use it if the Access Point is advertising to
be MFP-Capable.
These problems are not a bug in wpa_supplicant. Most of the times they are
caused by bugs in wireless drivers (specially Intel), Rarely, they are
misconfigurations / bugs in the Access Point. In both cases, a software
upgrade containing a fix will not probably happen in a short time.
So, I tried to do a comprehensive text trying to anticipate the "WiFi
sucks on Fedora" rant (before we see another 'WiFi sucks' rant, like it
happened with [1]).
> Could you rework this article to be simpler, and eliminating some of
> the unnecessary technical details? We don't assume all users are
> stupid. But on the other hand, readers have a limited attention span
> according to our metrics, so the Magazine aims for higher readability,
> and articles that focus on their problem and how to solve it.
>
> Let us know what you think.
Stupid people just don't exist. Anyway, even though I can assume all
readers can upgrade/downgrade an rpm, and see a wireless connection
problem apperaing/disappearing, I'm not 100% sure they know how ciphers
are negotiated between Access Points and clients in a managed BSS.
after a fresh re-read, I think I can get rid of this paragraph
<<
Like other features in the 802.11 standard, PMF is designed to be
backwards-compatible. It is possible to configure the desired PMF
enforcement level, both on the Access Point and on the client, depending
on the desired trade-off between protection and interoperability:
PMF Disabled: no protection present, nor required.
PMF Optional: protect only frames sent to nodes that advertise the PMF
capability, and keep transmitting unprotected frames to other “legacy”
nodes.
PMF Required: only associate/accept association if the peer node is
PMF-capable
When a client associates to an AP, and both nodes have PMF enabled (with
‘Optional’ or ‘Required’), they will negotiate the cipher suite that is
going to be used for MICs. Negotiation will be successful if the two nodes
(usually the Access Point and the client) will agree on one of the ciphers
belonging to the BIP (Broadcast Integrity Protection) Group Management
suite. Within wpa_supplicant it’s possible to specify the algorithm among
a set of available cipher suites, that are made available by the NIC
hardware, or by the kernel crypto library, or both. All these information
can be read in the RSN Information Element (i.e. the MFP Capable and the
MFP Required bit in the RSN Capabilities subelement, and the BIP Group
Management Suite listing the configured ciphers).
>>
We can remove it, many users read the system log and attach it to
bugzilla; almost nobody attachs EAPOL traces (and it's not trivial to
capture auth/deauth packets).
Alternatively, I can publish this post "as-is" elsewhere, and write a
small introductive chapter for fedora magazine.
WDYT?
thanks!
--
davide
[1]
http://blog.cerowrt.org/post/disabling_channel_scans/
Hi Davide, thanks for the note back. I think, based on your
explanation here, your second suggestion might be a better fit for the
magazine.
--
Paul W. Frields