From nobody Mon Sep 06 17:31:33 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BC03B17B43AB for ; Mon, 6 Sep 2021 17:31:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H3FnP0N0Jz3p3G for ; Mon, 6 Sep 2021 17:31:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id NH54msGecps7PNIT2mok7K; Mon, 06 Sep 2021 17:31:36 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id NIT1m561TdCHGNIT2moGze; Mon, 06 Sep 2021 17:31:36 +0000 X-Authority-Analysis: v=2.4 cv=SdyUytdu c=1 sm=1 tr=0 ts=61365078 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=7QKq2e-ADPsA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=QCccru2TAAAA:8 a=0DU4wlSrt08kT7HQN4IA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 a=rCjsK_HQOcgUb9vb-KUg:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 0D6CCED; Mon, 6 Sep 2021 10:31:34 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 186HVXr5004438; Mon, 6 Sep 2021 10:31:33 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202109061731.186HVXr5004438@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Oleg V. Nauman" cc: Cy Schubert , current@freebsd.org, Idwer Vollering Subject: Re: wlan0 no longer functional after n249128-a0c64a443e4c -> n249146-cb5c07649aa0 In-reply-to: <3000346.ZmR5Pbtf01@sigill.theweb.org.ua> References: <202109061541.186FfDRR024955@slippy.cwsent.com> <3000346.ZmR5Pbtf01@sigill.theweb.org.ua> Comments: In-reply-to "Oleg V. Nauman" message dated "Mon, 06 Sep 2021 19:26:34 +0300." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Sep 2021 10:31:33 -0700 X-CMAE-Envelope: MS4xfDQRUpQTgbDLlmb6HaYABnzO2jNeHEzYT8v2J0N9mchBLk2vtwQAi5HTJGDaR9VVg2EZ9J+4TCpXbqH/Pda5VeDKWPy7niRc+cKkOx6U8zwqwCB5VcYV i/mqrMZu9oMr/T/iiHRyJbrrEmMDmO+E2/muhaTGrTYoplxz9XM2m8HWucz9nSr5L5vDyjiu4ZWhckruLwI0drtj1AuxGCEa+IHKuv2PZvch8w6AtGwBxAHs pE10fIiV5NUs0TGT5BuwIQ== X-Rspamd-Queue-Id: 4H3FnP0N0Jz3p3G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N One last favour to ask, can you try this with the wpa_supplicant-devel port, please? I'm trying to narrow down if this is related to the options in usr.sbin/wpa/Makefile.inc or an upstream problem. If this behaves the same using wpa_supplicant-devel, this tells me to look at the code instead of Makefiles. I can reproduce the service netif restart problem using the old wpa_supplicant 2.9, so at least here there is no change in behaviour. Though on my sandbox machine the ifconfig dow/up is not required -- though even the older wpa_supplicant 2.9 behaves the same on my laptop, (no regression experienced here). To help point to either Makefile.inc or contrib/wpa, can you please try the wpa_supplicant-devel port. This will tell me where to look next. Fifteen seconds isn't needed. Two or three, even no wait, will do. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. In message <3000346.ZmR5Pbtf01@sigill.theweb.org.ua>, "Oleg V. Nauman" writes: > On 2021 M09 6, Mon 18:41:13 EEST Cy Schubert wrote: > > I changed mine to be the same as yours. I can connect. (I use iwn(4) and > > ath(4) here.) > > a ) regular reboot - wlan can not associate > b ) service netif restart - wlan can not associate > c ) service netif stop wlan0 ; service netif start wlan0 - wlan can not > associate > d ) ifconfig wlan0 down; sleep 15 ; ifconfig wlan0 up - wlan associated > e ) regular reboot with ifconfig wlan0 down; sleep 15 ; ifconfig wlan0 up > added to /etc/rc.local - wlan associated > > Thank you. > > > > > Do you reboot every time you test or simply this? > > > > service netif stop wlan0 > > service netif start wlan0 > > > > If simply above, does a reboot have it work again? > > > > The reason I ask is, I discovered, today, a quirk in 14-CURRENT, regardless > > of the wpa_supplicant installed. It will always associate following a > > reboot however when running the above two commands to stop and start wlan0 > > I can reproduce your problem. The workaround for now is when running the > > above two commands to also ifconfig wlan0 down; ifconfig wlan0 up. > > > > Can you try ifconfig wlan0 down; ifconfig wlan0 up after stopping/starting > > wlan0? You may need to wait 2-3 seconds between down and up. > >