Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp3430896pxa; Tue, 25 Aug 2020 23:19:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJHpB/K1P9xR4Us7k9Svc6GKWwhK/NPwytH9v2bDs3sMNXtqL5jyZJCZv/GxbI9XGaOvh8 X-Received: by 2002:a05:6402:1545:: with SMTP id p5mr13065311edx.388.1598422740786; Tue, 25 Aug 2020 23:19:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598422740; cv=none; d=google.com; s=arc-20160816; b=EZNgdNUVEbokvTaGxvAu9hTg/dsuxHkk1dc4a2/DKZRwZeADKNQmqGqKKyqOaBsSxT iHL8k+jsj1nDEFbjlClvUM8lv7RCUSKDonSXtlRCaFUthTjzfKGvAEw8NfhM+cIA+VJA i8siGqQ2go+N1wp5TFHUnskgM9vv19lmD1+hrPwJkkaHVltxXwtz26pPGh7ZbJ3XHsim dUFpHRR3dI4F0z5nIp22UAJygh8jlIdllax1cZF9x3lqYezyjnh2iGR1PBALnjeZcOh3 gxDptaU6nUy+NTLOWF1lFOq8iGx4IWehEWoN8YQmQaVwEj74/5uIM6LWQH5hWQQfAyOi b1xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject; bh=GrCuTmrJr0A2dywSeMat+pOxYc+SDHzsamgyMpEpMNg=; b=sBqV0UAFt6ihSbMNHFy/NHCt24iSS8xSYza/Ew/FHY+wnecvSHsoWYngVha5yjrFgf 7QNAYPkiIY4vmW3b4aGGlNt70ryEyik8XbvrPWTHBO9Hu0x/v7tu2TlAA3CXrL96Ss6L ZHjg4UUhjWeLfPP3m3vgAVyaJwgDbcMxpDaeMbqQU9Pl4GqACEs7cXW9eim2rWSXq524 K6ehnO1Ut8dnHJiHTcVC6clsWFZxCbFk/kIVCY3GKqcaRJ75c1DntziYwChx1c7b/5Yt zKiVz1lp1f9zGPblDODY6BW/2Un6D9eThxWXeWuUxrG36A7qOPlsp4F9hmF0BsNwQBgg J2hw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a17si986057ejx.396.2020.08.25.23.18.27; Tue, 25 Aug 2020 23:19:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726014AbgHZGSY (ORCPT + 99 others); Wed, 26 Aug 2020 02:18:24 -0400 Received: from mx3.molgen.mpg.de ([141.14.17.11]:44431 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725786AbgHZGSV (ORCPT ); Wed, 26 Aug 2020 02:18:21 -0400 Received: from [192.168.0.2] (ip5f5af678.dynamic.kabel-deutschland.de [95.90.246.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id C3F7320225BDA; Wed, 26 Aug 2020 08:18:17 +0200 (CEST) Subject: Re: Issue with iwd + Linux 5.8.3 + WPA Enterprise To: Caleb Jorden , Herbert Xu , Sasha Levin References: <20200826055150.2753.90553@ml01.vlan13.01.org> Cc: iwd@lists.01.org, stable@vger.kernel.org, Greg KH , LKML , "David S. Miller" , linux-crypto@vger.kernel.org From: Paul Menzel Message-ID: Date: Wed, 26 Aug 2020 08:18:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200826055150.2753.90553@ml01.vlan13.01.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Dear Caleb, Thank you for the report. Linux has a no regression policy, so the correct forum to report this to is the Linux kernel folks. I am adding the crypto and stable folks to the receiver list. Am 26.08.20 um 07:51 schrieb caljorden@hotmail.com: > I wanted to note an issue that I have hit with iwd when I upgraded to > the Linux 5.8.3 stable kernel. My office network uses WPA Enterprise > with EAP-PEAPv0 + MSCHAPv2. When using this office network, > upgrading to Linux 5.8.3 caused my system to refuse to associate > successfully to the network. I get the following in my dmesg logs: > > [ 40.846535] wlan0: authenticate with :60 > [ 40.850570] wlan0: send auth to :60 (try 1/3) > [ 40.854627] wlan0: authenticated > [ 40.855992] wlan0: associate with :60 (try 1/3) > [ 40.860450] wlan0: RX AssocResp from :60 (capab=0x411 status=0 aid=11) > [ 40.861620] wlan0: associated > [ 41.886503] wlan0: deauthenticating from :60 by local choice (Reason: 23=IEEE8021X_FAILED) > [ 42.360127] wlan0: authenticate with :22 > [ 42.364584] wlan0: send auth to :22 (try 1/3) > [ 42.370821] wlan0: authenticated > [ 42.372658] wlan0: associate with :22 (try 1/3) > [ 42.377426] wlan0: RX AssocResp from :22 (capab=0x411 status=0 aid=15) > [ 42.378607] wlan0: associated > [ 43.402009] wlan0: deauthenticating from :22 by local choice (Reason: 23=IEEE8021X_FAILED) > [ 43.875921] wlan0: authenticate with :60 > [ 43.879988] wlan0: send auth to :60 (try 1/3) > [ 43.886244] wlan0: authenticated > [ 43.889273] wlan0: associate with :60 (try 1/3) > [ 43.894586] wlan0: RX AssocResp from :60 (capab=0x411 status=0 aid=11) > [ 43.896077] wlan0: associated > [ 44.918504] wlan0: deauthenticating from :60 by local choice (Reason: 23=IEEE8021X_FAILED) > > This continues as long as I let iwd run. > > I downgraded back to Linux 5.8.2, and verified that everything works > as expected. I also tried using Linux 5.8.3 on a different system at > my home, which uses WPA2-PSK. It worked fine (though it uses an > Atheros wireless card instead of an Intel card - but I assume that is > irrelevant). > > I decided to try to figure out what caused the issue in the changes > for Linux 5.8.3. I assumed that it was something that changed in the > crypto interface, which limited my bisection to a very few commits. > Sure enough, I found that if I revert commit > e91d82703ad0bc68942a7d91c1c3d993e3ad87f0 (crypto: algif_aead - Only > wake up when ctx->more is zero), the problem goes away and I am able > to associate to my WPA Enterprise network successfully, and use it. > I found that in order to revert this commit, I also first had to > revert 465c03e999102bddac9b1e132266c232c5456440 (crypto: af_alg - Fix > regression on empty requests), because the two commits have coupled > changes. > > I normally would have assumed that this should be sent to the kernel > list, but I thought I would first mention it here because of what I > found in some email threads on the Linux-Crypto list about the crypto > interfaces to the kernel being sub-optimal and needing to be fixed. > The changes in these commits look like they are just trying to fix > what could be broken interfaces, so I thought that it would make > sense to see what the iwd team thinks about the situation first. > > The wireless card I was using during this testing is an Intel > Wireless 3165 (rev 81). If there is any additional information I > could help provide, please let me know. It’d be great, if you verified, if the problem occurs with Linus’ master branch too. Kind regards, Paul