Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message , Kyle Evans writes: > On Mon, Jul 23, 2018 at 7:55 AM, Dave Cottlehuber wrote: > > On Thu, 19 Jul 2018, at 15:25, Niclas Zeising wrote: > >> On 07/19/18 15:20, Cy Schubert wrote: > >> > In message <2f0ab2c2-b7cc-3dae-2d65-ea3c4a951...@daemonic.se>, Niclas > >> > Zeising w > >> > rites: > >> >> [ sending this again since I missed the list the first time, apologies > >> >> if anyone receives a duplicate ] > >> >> > >> >> On 07/19/18 13:57, Kyle Evans wrote: > >> >>> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev > wrote > >> >> : > >> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: > >> > ... > >> > Yesterday I updated my notebook (with iwm(4)) and also noticed that > >> > wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant resta > rt > >> > wlan0 helps. After your message I reinstalled wpa_supplicant from ol > d > >> > source and now it works stable already about 2 hours. > > > > Reporting the same thing. At my end it looks like an issue with the AP itse > lf, > > not iwm but maybe more expert eyes see something I don't? I've seen this on > ce > > downstairs where the family has an imac on wifi, and it also disconnected a > t > > the same time, and reconnected. I collected all this for the Ubiquiti forum > s > > but maybe it helps here. > > > > I'm using intel 8265, WPA-PSK, and unifi UAC Pro AP. I've been seeing this > > for ~ 5 days, around the time my UAC firmware got bumped to 3.9.27.8537, an > d > > also the last CURRENT update I did. > > > > Sometimes it's brutal (every 1-2 minutes) and other times it takes a while > (hours) to occur: > > > > 2018-07-18T19:03:10.843020+00:00 akai kernel: [9200] wlan0: [80:2a:a8:5a:bd > :3f] AMRR: current rate 2, txcnt=12, retrycnt=167 > > 2018-07-18T19:03:11.684065+00:00 akai kernel: [9200] wlan0: [80:2a:a8:5a:bd > :3f] AMRR: current rate 2, txcnt=11, retrycnt=94 > > 2018-07-18T19:03:11.847485+00:00 akai 1 2018-07-18T19:03:11.847320+00:00 ak > ai.skunkwerks.at wpa_supplicant 91696 - - wlan0: CTRL-EVENT-DISCONNECTED bssi > d=80:2a:a8:5a:bd:3f reason=1 locally_generated=1 > > 2018-07-18T19:03:11.848239+00:00 akai 1 2018-07-18T19:03:11.848123+00:00 ak > ai.skunkwerks.at devd 17186 - - Processing event '!system=IFNET subsystem=wla > n0 type=LINK_DOWN' > > 2018-07-18T19:03:11.848846+00:00 akai 1 2018-07-18T19:03:11.848384+00:00 ak > ai.skunkwerks.at dhclient 57397 - - wlan0 link state up -> down > > 2018-07-18T19:03:11.848899+00:00 akai 1 2018-07-18T19:03:11.848593+00:00 ak > ai.skunkwerks.at devd 17186 - - Popping table > > 2018-07-18T19:03:11.892696+00:00 akai kernel: [9201] wlan0: [80:2a:a8:5a:bd > :3f] station deauth via MLME (reason: 1 (unspecified)) > > 2018-07-18T19:03:11.892720+00:00 akai kernel: [9201] wlan0: ieee80211_swsca > n_cancel_scan: called; F_SCAN=0, vap=match, signal=0 > > 2018-07-18T19:03:11.892733+00:00 akai kernel: [9201] wlan0: ieee80211_swsca > n_cancel_scan: called; F_SCAN=0, vap=match, signal=0 > > 2018-07-18T19:03:11.892736+00:00 akai kernel: [9201] wlan0: [80:2a:a8:5a:bd > :3f] send station disassociate (reason: 8 (sending STA is leaving/has left BS > S)) > > 2018-07-18T19:03:11.892740+00:00 akai kernel: [9201] [80:2a:a8:5a:bd:3f] se > nd disassoc on channel 6 > > 2018-07-18T19:03:11.892743+00:00 akai kernel: [9201] wlan0: [00:28:f8:d0:91 > :52] amrr_node_init: non-11n node > > 2018-07-18T19:03:11.892746+00:00 akai kernel: [9201] wlan0: link state chan > ged to DOWN > > 2018-07-18T19:03:11.892749+00:00 akai kernel: [9201] wlan0: [00:28:f8:d0:91 > :52] AMRR: nrates=0, initial rate 0 > > 2018-07-18T19:03:12.114718+00:00 akai kernel: [9201] wlan0: ieee80211_scanr > eq: flags 0x20052 duration 0x7fff mindwell 0 maxdwell 0 nssid 1 > > 2018-07-18T19:03:12.114744+00:00 akai kernel: [9201] wlan0: ieee80211_scan_ > flush > > > > this time I got both the wlandebug output and also /var/log/messages & pcap > from > > the AP. I'm not sure how much privileged info is in the AP pcap so its avai > lable > > privately on request if needed. > > > > laptop - looks like a normal exit of the AP to me: > > > > 2018-07-23T12:20:22.469857+00:00 akai kernel: [1823] wlan0: [80:2a:a8:5a:bd > :3f] AMRR decreasing rate 11 (txcnt=46 retrycnt=16) > > 2018-07-23T12:20:25.396670+00:00 akai kernel: [1825] wlan0: [80:2a:a8:5a:bd > :3f] AMRR: current rate 11, txcnt=11, retrycnt=105 > > 2018-07-23T12:20:25.396700+00:00 akai kernel: [1825] wlan0: [80:2a:a8:5a:bd > :3f] AMRR decreasing rate 4 (txcnt=11 retrycnt=105) > > 2018-07-23T12:20:25.698421+00:00 akai 1 2018-07-23T12:20:25.698238+00:00 ak > ai.skunkwerks.at wpa_supplicant 22034 - - wlan0: CTRL-EVENT-DISCONNECTED bssi > d=80:2a:a8:5a:bd:3f reason=1 locally_generated=1 > > 2018-07-23T12:20:25.699374+00:00 akai 1 2018-07-23T12:20:25.699249+00:00 ak > ai.skunkwerks.at dhclient 23843 - - wlan0 link state up -> down > > 2018-07-23T12:20:25.699465+00:00 akai 1 2018-07-23T12:20:25.699319+00:00 ak > ai.skunkwerks.at devd 37330 - - Processing event '!system=IF
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message <1532350523.2338008.1449756200.7870027F@webmail.messagingengi ne.com> , Dave Cottlehuber writes: > On Thu, 19 Jul 2018, at 15:25, Niclas Zeising wrote: > > On 07/19/18 15:20, Cy Schubert wrote: > > > In message <2f0ab2c2-b7cc-3dae-2d65-ea3c4a951...@daemonic.se>, Niclas > > > Zeising w > > > rites: > > >> [ sending this again since I missed the list the first time, apologies > > >> if anyone receives a duplicate ] > > >> > > >> On 07/19/18 13:57, Kyle Evans wrote: > > >>> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev w > rote > > >> : > > On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: > > > ... > > > Yesterday I updated my notebook (with iwm(4)) and also noticed that > > > wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant restar > t > > > wlan0 helps. After your message I reinstalled wpa_supplicant from old > > > source and now it works stable already about 2 hours. > > Reporting the same thing. At my end it looks like an issue with the AP itself > , > not iwm but maybe more expert eyes see something I don't? I've seen this once > downstairs where the family has an imac on wifi, and it also disconnected at > the same time, and reconnected. I collected all this for the Ubiquiti forums > but maybe it helps here. > > I'm using intel 8265, WPA-PSK, and unifi UAC Pro AP. I've been seeing this > for ~ 5 days, around the time my UAC firmware got bumped to 3.9.27.8537, and > also the last CURRENT update I did. > > Sometimes it's brutal (every 1-2 minutes) and other times it takes a while (h > ours) to occur: > > 2018-07-18T19:03:10.843020+00:00 akai kernel: [9200] wlan0: [80:2a:a8:5a:bd:3 > f] AMRR: current rate 2, txcnt=12, retrycnt=167 > 2018-07-18T19:03:11.684065+00:00 akai kernel: [9200] wlan0: [80:2a:a8:5a:bd:3 > f] AMRR: current rate 2, txcnt=11, retrycnt=94 > 2018-07-18T19:03:11.847485+00:00 akai 1 2018-07-18T19:03:11.847320+00:00 akai > .skunkwerks.at wpa_supplicant 91696 - - wlan0: CTRL-EVENT-DISCONNECTED bssid= > 80:2a:a8:5a:bd:3f reason=1 locally_generated=1 > 2018-07-18T19:03:11.848239+00:00 akai 1 2018-07-18T19:03:11.848123+00:00 akai > .skunkwerks.at devd 17186 - - Processing event '!system=IFNET subsystem=wlan0 > type=LINK_DOWN' > 2018-07-18T19:03:11.848846+00:00 akai 1 2018-07-18T19:03:11.848384+00:00 akai > .skunkwerks.at dhclient 57397 - - wlan0 link state up -> down > 2018-07-18T19:03:11.848899+00:00 akai 1 2018-07-18T19:03:11.848593+00:00 akai > .skunkwerks.at devd 17186 - - Popping table > 2018-07-18T19:03:11.892696+00:00 akai kernel: [9201] wlan0: [80:2a:a8:5a:bd:3 > f] station deauth via MLME (reason: 1 (unspecified)) > 2018-07-18T19:03:11.892720+00:00 akai kernel: [9201] wlan0: ieee80211_swscan_ > cancel_scan: called; F_SCAN=0, vap=match, signal=0 > 2018-07-18T19:03:11.892733+00:00 akai kernel: [9201] wlan0: ieee80211_swscan_ > cancel_scan: called; F_SCAN=0, vap=match, signal=0 > 2018-07-18T19:03:11.892736+00:00 akai kernel: [9201] wlan0: [80:2a:a8:5a:bd:3 > f] send station disassociate (reason: 8 (sending STA is leaving/has left BSS) > ) > 2018-07-18T19:03:11.892740+00:00 akai kernel: [9201] [80:2a:a8:5a:bd:3f] send > disassoc on channel 6 > 2018-07-18T19:03:11.892743+00:00 akai kernel: [9201] wlan0: [00:28:f8:d0:91:5 > 2] amrr_node_init: non-11n node > 2018-07-18T19:03:11.892746+00:00 akai kernel: [9201] wlan0: link state change > d to DOWN > 2018-07-18T19:03:11.892749+00:00 akai kernel: [9201] wlan0: [00:28:f8:d0:91:5 > 2] AMRR: nrates=0, initial rate 0 > 2018-07-18T19:03:12.114718+00:00 akai kernel: [9201] wlan0: ieee80211_scanreq > : flags 0x20052 duration 0x7fff mindwell 0 maxdwell 0 nssid 1 > 2018-07-18T19:03:12.114744+00:00 akai kernel: [9201] wlan0: ieee80211_scan_fl > ush > > this time I got both the wlandebug output and also /var/log/messages & pcap f > rom > the AP. I'm not sure how much privileged info is in the AP pcap so its availa > ble > privately on request if needed. > > laptop - looks like a normal exit of the AP to me: > > 2018-07-23T12:20:22.469857+00:00 akai kernel: [1823] wlan0: [80:2a:a8:5a:bd:3 > f] AMRR decreasing rate 11 (txcnt=46 retrycnt=16) > 2018-07-23T12:20:25.396670+00:00 akai kernel: [1825] wlan0: [80:2a:a8:5a:bd:3 > f] AMRR: current rate 11, txcnt=11, retrycnt=105 > 2018-07-23T12:20:25.396700+00:00 akai kernel: [1825] wlan0: [80:2a:a8:5a:bd:3 > f] AMRR decreasing rate 4 (txcnt=11 retrycnt=105) > 2018-07-23T12:20:25.698421+00:00 akai 1 2018-07-23T12:20:25.698238+00:00 akai > .skunkwerks.at wpa_supplicant 22034 - - wlan0: CTRL-EVENT-DISCONNECTED bssid= > 80:2a:a8:5a:bd:3f reason=1 locally_generated=1 > 2018-07-23T12:20:25.699374+00:00 akai 1 2018-07-23T12:20:25.699249+00:00 akai > .skunkwerks.at dhclient 23843 - - wlan0 link state up -> down > 2018-07-23T12:20:25.699465+00:00 akai 1 2018-07-23T12:20:25.699319+00:00 akai > .skunkwerks.at devd 37330 - - Processing event '!system=IFNET subsystem=wlan0 > type=LINK_DOWN' > 2018-07-23T12:20:25.699521+00:00 akai 1 2018-07-23T12:20:25.6
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message , Kyle Evans writes: > On Thu, Jul 19, 2018 at 7:57 PM, Cy Schubert wrot > e: > > In message > il.com> > > , Kyle Evans writes: > >> On Thu, Jul 19, 2018 at 7:32 PM, Shawn Webb w > rot > >> e: > >> > On Thu, Jul 19, 2018 at 07:24:46PM -0500, Kyle Evans wrote: > >> >> On Thu, Jul 19, 2018 at 6:21 PM, Kyle Evans wrote: > >> >> > On Thu, Jul 19, 2018 at 4:33 PM, Cy Schubert om> > >> wrote: > >> >> >> In message <201807192114.w6jleapa097...@slippy.cwsent.com>, Cy Schub > ert > >> >> >> writes: > >> >> >>> In message <17042686.mc0x0p6...@asus.theweb.org.ua>, "Oleg V. Nauma > n" > >> >> >>> writes: > >> >> >>> > On Thursday, July 19, 2018 4:54:42 PM EEST Cy Schubert wrote: > >> >> >>> > > In message @ma > >> il.gma > >> >> >>> > > il.com> > >> >> >>> > > > >> >> >>> > > , Kyle Evans writes: > >> >> >>> > > > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising > >> >> >>> > > > > >> >> >>> > > > wrote: > >> >> >>> > > > > [ sending this again since I missed the list the first time > , a > >> pologie > >> >> >>> s > >> >> >>> > > > > if > >> >> >>> > > > > anyone receives a duplicate ] > >> >> >>> > > > > > >> >> >>> > > > > On 07/19/18 13:57, Kyle Evans wrote: > >> >> >>> > > > >> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev ree > >> bsd.org > >> >> >>> > > >> >> >>> > > > >> > >> >> >>> > > > >> wrote: > >> >> >>> > > > >>> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsuk > ov > >> wrote: > >> >> >>> > > > ... > >> >> >>> > > > Yesterday I updated my notebook (with iwm(4)) and also n > oti > >> ced tha > >> >> >>> t > >> >> >>> > > > wi-fi connection periodically breaks. /etc/rc.d/wpa_supp > lic > >> ant > >> >> >>> > > > restart > >> >> >>> > > > wlan0 helps. After your message I reinstalled wpa_suppli > can > >> t from > >> >> >>> ol > >> >> >>> > d > >> >> >>> > > > source and now it works stable already about 2 hours. > >> >> >>> > > > >>> > >> >> >>> > > > >>> So, right now, we have broken wpa_supplicant(8) in -CURRE > NT? > >> :-/ > >> >> >>> > > > >> > >> >> >>> > > > >> Well, "broken". It's incredibly stable outside of rekeying > ev > >> ents, a > >> >> >>> nd > >> >> >>> > > > >> further testing shows that I don't actually notice these d > isc > >> onnects > >> >> >>> > > > >> most of the time because it reassociates fast enough. I no > tic > >> ed it t > >> >> >>> he > >> >> >>> > > > >> first time because apparently I had both SSIDs from my AP > unc > >> ommente > >> >> >>> d > >> >> >>> > > > >> in my wpa_supplicant.conf and it decided at that point to > con > >> nect to > >> >> >>> > > > >> the other one, which took a little longer. > >> >> >>> > > > >> > >> >> >>> > > > >> Contrary to Andrey's report, though, I don't have to kick > >> >> >>> > > > >> wpa_supplicant at all. It will reassociate on its own ever > y s > >> ingle > >> >> >>> > > > >> time. > >> >> >>> > > > > > >> >> >>> > > > > Hi! > >> >> >>> > > > > I have the exact same problem as Andrey, with the same driv > er. > >> I've > >> >> >>> no > >> >> >>> > t > >> >> >>> > > > > investigated very much, but when using the 2.8 wpa_supplica > nt > >> the wif > >> >> >>> i > >> >> >>> > > > > network dies after a little while, and I have to restart it > (u > >> sually > >> >> >>> > > > > with > >> >> >>> > > > > /etc/rc.d/netif restart). Then it works for a little while > , b > >> efore > >> >> >>> > > > > going > >> >> >>> > > > > down again. With the old wpa_supplicant I didn't have this > pr > >> oblem. > >> >> >>> > > > > > >> >> >>> > > > > I don't have very much else to add except noting that I'm a > ffe > >> cted as > >> >> >>> > > > > well. > >> >> >>> > > > > I haven't had time to debug it properly (which is why I've > nev > >> er > >> >> >>> > > > > reported > >> >> >>> > > > > it) > >> >> >>> > > > > >> >> >>> > > > I plan on trying out the latest from upstream beyond the patc > h C > >> y sent > >> >> >>> > > > along earlier to see if it's perhaps been addressed elsewhere > in > >> the > >> >> >>> > > > past two years since this release was made. > >> >> >>> > > > >> >> >>> > > A point of reference. I've had no issues here with any of the n > etw > >> orks > >> >> >>> > > I use. All the networks I use are either WPA-PSK or open. The l > ast > >> >> >>> > > WPA-EAP I used was at former $JOB a few years ago. However, at > the > >> Link > >> >> >>> > > Lounge just outside where $JOB is at my wifi would disconnect e > ver > >> y 30 > >> >> >>> > > minutes using our old wpa 2.5, requiring a netif restart. 2.6 r > eso > >> lved > >> >> >>> > > that issue. > >> >> >>> > > > >> >> >>> > > Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also > lo > >> oks > >> >> >>> > > interesting. > >> >> >>> > > > >> >> >>> > > ommit 0adc9b28b39d414d5febfff752f6a1576f785c85 > >> >> >>> > > Author: Jouni Malinen > >> >> >>> > > Date: Sun Oct 1 12:32:57 2017 +0300 > >> >> >>> > > > >> >> >>> > > Fix PTK rekeying to generate a new ANonce > >> >> >>> > > > >> >>
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message , Kyle Evans writes: > On Thu, Jul 19, 2018 at 7:32 PM, Shawn Webb wrot > e: > > On Thu, Jul 19, 2018 at 07:24:46PM -0500, Kyle Evans wrote: > >> On Thu, Jul 19, 2018 at 6:21 PM, Kyle Evans wrote: > >> > On Thu, Jul 19, 2018 at 4:33 PM, Cy Schubert > wrote: > >> >> In message <201807192114.w6jleapa097...@slippy.cwsent.com>, Cy Schubert > >> >> writes: > >> >>> In message <17042686.mc0x0p6...@asus.theweb.org.ua>, "Oleg V. Nauman" > >> >>> writes: > >> >>> > On Thursday, July 19, 2018 4:54:42 PM EEST Cy Schubert wrote: > >> >>> > > In message il.gma > >> >>> > > il.com> > >> >>> > > > >> >>> > > , Kyle Evans writes: > >> >>> > > > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising > >> >>> > > > > >> >>> > > > wrote: > >> >>> > > > > [ sending this again since I missed the list the first time, a > pologie > >> >>> s > >> >>> > > > > if > >> >>> > > > > anyone receives a duplicate ] > >> >>> > > > > > >> >>> > > > > On 07/19/18 13:57, Kyle Evans wrote: > >> >>> > > > >> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev bsd.org > >> >>> > > >> >>> > > > >> > >> >>> > > > >> wrote: > >> >>> > > > >>> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov > wrote: > >> >>> > > > ... > >> >>> > > > Yesterday I updated my notebook (with iwm(4)) and also noti > ced tha > >> >>> t > >> >>> > > > wi-fi connection periodically breaks. /etc/rc.d/wpa_supplic > ant > >> >>> > > > restart > >> >>> > > > wlan0 helps. After your message I reinstalled wpa_supplican > t from > >> >>> ol > >> >>> > d > >> >>> > > > source and now it works stable already about 2 hours. > >> >>> > > > >>> > >> >>> > > > >>> So, right now, we have broken wpa_supplicant(8) in -CURRENT? > :-/ > >> >>> > > > >> > >> >>> > > > >> Well, "broken". It's incredibly stable outside of rekeying ev > ents, a > >> >>> nd > >> >>> > > > >> further testing shows that I don't actually notice these disc > onnects > >> >>> > > > >> most of the time because it reassociates fast enough. I notic > ed it t > >> >>> he > >> >>> > > > >> first time because apparently I had both SSIDs from my AP unc > ommente > >> >>> d > >> >>> > > > >> in my wpa_supplicant.conf and it decided at that point to con > nect to > >> >>> > > > >> the other one, which took a little longer. > >> >>> > > > >> > >> >>> > > > >> Contrary to Andrey's report, though, I don't have to kick > >> >>> > > > >> wpa_supplicant at all. It will reassociate on its own every s > ingle > >> >>> > > > >> time. > >> >>> > > > > > >> >>> > > > > Hi! > >> >>> > > > > I have the exact same problem as Andrey, with the same driver. > I've > >> >>> no > >> >>> > t > >> >>> > > > > investigated very much, but when using the 2.8 wpa_supplicant > the wif > >> >>> i > >> >>> > > > > network dies after a little while, and I have to restart it (u > sually > >> >>> > > > > with > >> >>> > > > > /etc/rc.d/netif restart). Then it works for a little while, b > efore > >> >>> > > > > going > >> >>> > > > > down again. With the old wpa_supplicant I didn't have this pr > oblem. > >> >>> > > > > > >> >>> > > > > I don't have very much else to add except noting that I'm affe > cted as > >> >>> > > > > well. > >> >>> > > > > I haven't had time to debug it properly (which is why I've nev > er > >> >>> > > > > reported > >> >>> > > > > it) > >> >>> > > > > >> >>> > > > I plan on trying out the latest from upstream beyond the patch C > y sent > >> >>> > > > along earlier to see if it's perhaps been addressed elsewhere in > the > >> >>> > > > past two years since this release was made. > >> >>> > > > >> >>> > > A point of reference. I've had no issues here with any of the netw > orks > >> >>> > > I use. All the networks I use are either WPA-PSK or open. The last > >> >>> > > WPA-EAP I used was at former $JOB a few years ago. However, at the > Link > >> >>> > > Lounge just outside where $JOB is at my wifi would disconnect ever > y 30 > >> >>> > > minutes using our old wpa 2.5, requiring a netif restart. 2.6 reso > lved > >> >>> > > that issue. > >> >>> > > > >> >>> > > Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also lo > oks > >> >>> > > interesting. > >> >>> > > > >> >>> > > ommit 0adc9b28b39d414d5febfff752f6a1576f785c85 > >> >>> > > Author: Jouni Malinen > >> >>> > > Date: Sun Oct 1 12:32:57 2017 +0300 > >> >>> > > > >> >>> > > Fix PTK rekeying to generate a new ANonce > >> >>> > > > >> >>> > > The Authenticator state machine path for PTK rekeying ended up > >> >>> > > bypassing > >> >>> > > the AUTHENTICATION2 state where a new ANonce is generated when > going > >> >>> > > directly to the PTKSTART state since there is no need to try t > o > >> >>> > > determine the PMK again in such a case. This is far from ideal > >> >>> > > since the > >> >>> > > new PTK would depend on a new nonce only from the supplicant. > >> >>> > > > >> >>> > > Fix this by generating a new ANonce when moving to the PTKSTAR > T > >> >>> > > state > >> >>> >
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message <201807192114.w6jleapa097...@slippy.cwsent.com>, Cy Schubert writes: > In message <17042686.mc0x0p6...@asus.theweb.org.ua>, "Oleg V. Nauman" > writes: > > On Thursday, July 19, 2018 4:54:42 PM EEST Cy Schubert wrote: > > > In message > > il.com> > > > > > > , Kyle Evans writes: > > > > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising > > > > > > > > wrote: > > > > > [ sending this again since I missed the list the first time, apologie > s > > > > > if > > > > > anyone receives a duplicate ] > > > > > > > > > > On 07/19/18 13:57, Kyle Evans wrote: > > > > >> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev > > > > > >> > > > > >> wrote: > > > > >>> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: > > > > ... > > > > Yesterday I updated my notebook (with iwm(4)) and also noticed tha > t > > > > wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant > > > > restart > > > > wlan0 helps. After your message I reinstalled wpa_supplicant from > ol > > d > > > > source and now it works stable already about 2 hours. > > > > >>> > > > > >>> So, right now, we have broken wpa_supplicant(8) in -CURRENT? :-/ > > > > >> > > > > >> Well, "broken". It's incredibly stable outside of rekeying events, a > nd > > > > >> further testing shows that I don't actually notice these disconnects > > > > >> most of the time because it reassociates fast enough. I noticed it t > he > > > > >> first time because apparently I had both SSIDs from my AP uncommente > d > > > > >> in my wpa_supplicant.conf and it decided at that point to connect to > > > > >> the other one, which took a little longer. > > > > >> > > > > >> Contrary to Andrey's report, though, I don't have to kick > > > > >> wpa_supplicant at all. It will reassociate on its own every single > > > > >> time. > > > > > > > > > > Hi! > > > > > I have the exact same problem as Andrey, with the same driver. I've > no > > t > > > > > investigated very much, but when using the 2.8 wpa_supplicant the wif > i > > > > > network dies after a little while, and I have to restart it (usually > > > > > with > > > > > /etc/rc.d/netif restart). Then it works for a little while, before > > > > > going > > > > > down again. With the old wpa_supplicant I didn't have this problem. > > > > > > > > > > I don't have very much else to add except noting that I'm affected as > > > > > well. > > > > > I haven't had time to debug it properly (which is why I've never > > > > > reported > > > > > it) > > > > > > > > I plan on trying out the latest from upstream beyond the patch Cy sent > > > > along earlier to see if it's perhaps been addressed elsewhere in the > > > > past two years since this release was made. > > > > > > A point of reference. I've had no issues here with any of the networks > > > I use. All the networks I use are either WPA-PSK or open. The last > > > WPA-EAP I used was at former $JOB a few years ago. However, at the Link > > > Lounge just outside where $JOB is at my wifi would disconnect every 30 > > > minutes using our old wpa 2.5, requiring a netif restart. 2.6 resolved > > > that issue. > > > > > > Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also looks > > > interesting. > > > > > > ommit 0adc9b28b39d414d5febfff752f6a1576f785c85 > > > Author: Jouni Malinen > > > Date: Sun Oct 1 12:32:57 2017 +0300 > > > > > > Fix PTK rekeying to generate a new ANonce > > > > > > The Authenticator state machine path for PTK rekeying ended up > > > bypassing > > > the AUTHENTICATION2 state where a new ANonce is generated when going > > > directly to the PTKSTART state since there is no need to try to > > > determine the PMK again in such a case. This is far from ideal > > > since the > > > new PTK would depend on a new nonce only from the supplicant. > > > > > > Fix this by generating a new ANonce when moving to the PTKSTART > > > state > > > for the purpose of starting new 4-way handshake to rekey PTK. > > > > > > Signed-off-by: Jouni Malinen > > > > > > > > > I suspect a timeout because reason=1 in Kyle's log. > > > > > > I have two systems experienced wifi connection issues after recent HEAD > > update. > > Both of them experiencing frequent up/down wlan0 events on boot so wireles > s > > connection can not negotiate DHCP requests, possibly due to fact that both > > connecting to the same AP. > > AP capabilities list: > > > > * f8:1a:67:56:16:161 54M -74:-96 100 EPS WPA WME ATH WPS > > > > Interesting enough that switching wpa_supplicant to version 2.6 from ports > > fixes that issue completely. > > > > Hopefully it helps. > > > > Thank you. > > I've imported all the patches in the port, from our upline into base. > Some were already committed to > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > base 2.5 others not. This should bring
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message <17042686.mc0x0p6...@asus.theweb.org.ua>, "Oleg V. Nauman" writes: > On Thursday, July 19, 2018 4:54:42 PM EEST Cy Schubert wrote: > > In message > il.com> > > > > , Kyle Evans writes: > > > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising > > > > > > wrote: > > > > [ sending this again since I missed the list the first time, apologies > > > > if > > > > anyone receives a duplicate ] > > > > > > > > On 07/19/18 13:57, Kyle Evans wrote: > > > >> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev > > > >> > > > >> wrote: > > > >>> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: > > > ... > > > Yesterday I updated my notebook (with iwm(4)) and also noticed that > > > wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant > > > restart > > > wlan0 helps. After your message I reinstalled wpa_supplicant from ol > d > > > source and now it works stable already about 2 hours. > > > >>> > > > >>> So, right now, we have broken wpa_supplicant(8) in -CURRENT? :-/ > > > >> > > > >> Well, "broken". It's incredibly stable outside of rekeying events, and > > > >> further testing shows that I don't actually notice these disconnects > > > >> most of the time because it reassociates fast enough. I noticed it the > > > >> first time because apparently I had both SSIDs from my AP uncommented > > > >> in my wpa_supplicant.conf and it decided at that point to connect to > > > >> the other one, which took a little longer. > > > >> > > > >> Contrary to Andrey's report, though, I don't have to kick > > > >> wpa_supplicant at all. It will reassociate on its own every single > > > >> time. > > > > > > > > Hi! > > > > I have the exact same problem as Andrey, with the same driver. I've no > t > > > > investigated very much, but when using the 2.8 wpa_supplicant the wifi > > > > network dies after a little while, and I have to restart it (usually > > > > with > > > > /etc/rc.d/netif restart). Then it works for a little while, before > > > > going > > > > down again. With the old wpa_supplicant I didn't have this problem. > > > > > > > > I don't have very much else to add except noting that I'm affected as > > > > well. > > > > I haven't had time to debug it properly (which is why I've never > > > > reported > > > > it) > > > > > > I plan on trying out the latest from upstream beyond the patch Cy sent > > > along earlier to see if it's perhaps been addressed elsewhere in the > > > past two years since this release was made. > > > > A point of reference. I've had no issues here with any of the networks > > I use. All the networks I use are either WPA-PSK or open. The last > > WPA-EAP I used was at former $JOB a few years ago. However, at the Link > > Lounge just outside where $JOB is at my wifi would disconnect every 30 > > minutes using our old wpa 2.5, requiring a netif restart. 2.6 resolved > > that issue. > > > > Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also looks > > interesting. > > > > ommit 0adc9b28b39d414d5febfff752f6a1576f785c85 > > Author: Jouni Malinen > > Date: Sun Oct 1 12:32:57 2017 +0300 > > > > Fix PTK rekeying to generate a new ANonce > > > > The Authenticator state machine path for PTK rekeying ended up > > bypassing > > the AUTHENTICATION2 state where a new ANonce is generated when going > > directly to the PTKSTART state since there is no need to try to > > determine the PMK again in such a case. This is far from ideal > > since the > > new PTK would depend on a new nonce only from the supplicant. > > > > Fix this by generating a new ANonce when moving to the PTKSTART > > state > > for the purpose of starting new 4-way handshake to rekey PTK. > > > > Signed-off-by: Jouni Malinen > > > > > > I suspect a timeout because reason=1 in Kyle's log. > > > I have two systems experienced wifi connection issues after recent HEAD > update. > Both of them experiencing frequent up/down wlan0 events on boot so wireless > connection can not negotiate DHCP requests, possibly due to fact that both > connecting to the same AP. > AP capabilities list: > > * f8:1a:67:56:16:161 54M -74:-96 100 EPS WPA WME ATH WPS > > Interesting enough that switching wpa_supplicant to version 2.6 from ports > fixes that issue completely. > > Hopefully it helps. > > Thank you. I've imported all the patches in the port, from our upline into base. Some were already committed to -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. base 2.5 others not. This should bring base up to par with the port, address the remaining security issues, and probably fix this thread too. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message , Kyle Evans writes: > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising > wrote: > > [ sending this again since I missed the list the first time, apologies if > > anyone receives a duplicate ] > > > > > > On 07/19/18 13:57, Kyle Evans wrote: > >> > >> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev > >> wrote: > >>> > >>> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: > > ... > Yesterday I updated my notebook (with iwm(4)) and also noticed that > wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant restart > wlan0 helps. After your message I reinstalled wpa_supplicant from old > source and now it works stable already about 2 hours. > >>> > >>> > >>> So, right now, we have broken wpa_supplicant(8) in -CURRENT? :-/ > >> > >> > >> Well, "broken". It's incredibly stable outside of rekeying events, and > >> further testing shows that I don't actually notice these disconnects > >> most of the time because it reassociates fast enough. I noticed it the > >> first time because apparently I had both SSIDs from my AP uncommented > >> in my wpa_supplicant.conf and it decided at that point to connect to > >> the other one, which took a little longer. > >> > >> Contrary to Andrey's report, though, I don't have to kick > >> wpa_supplicant at all. It will reassociate on its own every single > >> time. > > > > > > > > Hi! > > I have the exact same problem as Andrey, with the same driver. I've not > > investigated very much, but when using the 2.8 wpa_supplicant the wifi > > network dies after a little while, and I have to restart it (usually with > > /etc/rc.d/netif restart). Then it works for a little while, before going > > down again. With the old wpa_supplicant I didn't have this problem. > > > > I don't have very much else to add except noting that I'm affected as well. > > I haven't had time to debug it properly (which is why I've never reported > > it) > > I plan on trying out the latest from upstream beyond the patch Cy sent > along earlier to see if it's perhaps been addressed elsewhere in the > past two years since this release was made. I'll see if I can create a wpa_supplicant-devel port at noon today. Should be simple enough if I use the sysutils/mmc-utils approach. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message , Kyle Evans writes: > On Thu, Jul 19, 2018 at 7:13 AM, Niclas Zeising > wrote: > > [ sending this again since I missed the list the first time, apologies if > > anyone receives a duplicate ] > > > > > > On 07/19/18 13:57, Kyle Evans wrote: > >> > >> On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev > >> wrote: > >>> > >>> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: > > ... > Yesterday I updated my notebook (with iwm(4)) and also noticed that > wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant restart > wlan0 helps. After your message I reinstalled wpa_supplicant from old > source and now it works stable already about 2 hours. > >>> > >>> > >>> So, right now, we have broken wpa_supplicant(8) in -CURRENT? :-/ > >> > >> > >> Well, "broken". It's incredibly stable outside of rekeying events, and > >> further testing shows that I don't actually notice these disconnects > >> most of the time because it reassociates fast enough. I noticed it the > >> first time because apparently I had both SSIDs from my AP uncommented > >> in my wpa_supplicant.conf and it decided at that point to connect to > >> the other one, which took a little longer. > >> > >> Contrary to Andrey's report, though, I don't have to kick > >> wpa_supplicant at all. It will reassociate on its own every single > >> time. > > > > > > > > Hi! > > I have the exact same problem as Andrey, with the same driver. I've not > > investigated very much, but when using the 2.8 wpa_supplicant the wifi > > network dies after a little while, and I have to restart it (usually with > > /etc/rc.d/netif restart). Then it works for a little while, before going > > down again. With the old wpa_supplicant I didn't have this problem. > > > > I don't have very much else to add except noting that I'm affected as well. > > I haven't had time to debug it properly (which is why I've never reported > > it) > > I plan on trying out the latest from upstream beyond the patch Cy sent > along earlier to see if it's perhaps been addressed elsewhere in the > past two years since this release was made. A point of reference. I've had no issues here with any of the networks I use. All the networks I use are either WPA-PSK or open. The last WPA-EAP I used was at former $JOB a few years ago. However, at the Link Lounge just outside where $JOB is at my wifi would disconnect every 30 minutes using our old wpa 2.5, requiring a netif restart. 2.6 resolved that issue. Upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85 also looks interesting. ommit 0adc9b28b39d414d5febfff752f6a1576f785c85 Author: Jouni Malinen Date: Sun Oct 1 12:32:57 2017 +0300 Fix PTK rekeying to generate a new ANonce The Authenticator state machine path for PTK rekeying ended up bypassing the AUTHENTICATION2 state where a new ANonce is generated when going directly to the PTKSTART state since there is no need to try to determine the PMK again in such a case. This is far from ideal since the new PTK would depend on a new nonce only from the supplicant. Fix this by generating a new ANonce when moving to the PTKSTART state for the purpose of starting new 4-way handshake to rekey PTK. Signed-off-by: Jouni Malinen I suspect a timeout because reason=1 in Kyle's log. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message <2f0ab2c2-b7cc-3dae-2d65-ea3c4a951...@daemonic.se>, Niclas Zeising w rites: > [ sending this again since I missed the list the first time, apologies > if anyone receives a duplicate ] > > On 07/19/18 13:57, Kyle Evans wrote: > > On Thu, Jul 19, 2018 at 4:51 AM, Alexey Dokuchaev wrote > : > >> On Thu, Jul 19, 2018 at 11:48:03AM +0300, Andrey V. Elsukov wrote: > >>> ... > >>> Yesterday I updated my notebook (with iwm(4)) and also noticed that > >>> wi-fi connection periodically breaks. /etc/rc.d/wpa_supplicant restart > >>> wlan0 helps. After your message I reinstalled wpa_supplicant from old > >>> source and now it works stable already about 2 hours. > >> > >> So, right now, we have broken wpa_supplicant(8) in -CURRENT? :-/ > > > > Well, "broken". It's incredibly stable outside of rekeying events, and > > further testing shows that I don't actually notice these disconnects > > most of the time because it reassociates fast enough. I noticed it the > > first time because apparently I had both SSIDs from my AP uncommented > > in my wpa_supplicant.conf and it decided at that point to connect to > > the other one, which took a little longer. > > > > Contrary to Andrey's report, though, I don't have to kick > > wpa_supplicant at all. It will reassociate on its own every single > > time. > > > Hi! > I have the exact same problem as Andrey, with the same driver. I've not > investigated very much, but when using the 2.8 wpa_supplicant the wifi > network dies after a little while, and I have to restart it (usually > with /etc/rc.d/netif restart). Then it works for a little while, before > going down again. With the old wpa_supplicant I didn't have this problem. > > I don't have very much else to add except noting that I'm affected as > well. I haven't had time to debug it properly (which is why I've never > reported it) Do these events happen at regular intervals as Kyle experienced or randomly? What sort of key_mgmt do you connect with to your AP? Could it be WPA-EAP? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
Hi Kyle,
Can you try the attached patch please?
The upline commit log entry says:
commit e8d08cf37844f783b389e601ecedd13edd2b9196
Author: Jouni Malinen
Date: Wed Jun 6 01:22:01 2018 +0300
SAE: Do not drop STA entry on reauthentication in infrastructure BSS
A new SAE Commit message should not be allowed to drop an existing
STA
entry since the sender of that Commit message cannot be
authenticated
before receiving the Confirm message. This is important in
particular
when PMF is used since this would provide a potential new path for
forcing a connection to be dropped.
Fix this by allowing a new SAE Authentication instance to be started
when the old instance is in Accepted state and the new Commit
message
does not use the same peer-scalar value (checked in
sae_parse_commit_scalar()). When PMF is used, the AP will use SA
Query
procedure when receiving the (Re)Association Request frame. In
theory,
that step could be skipped in case of SAE Authentication since the
non-AP STA is demonstrating knowledge of the password. Anyway,
there is
no allowance for that exception in the IEEE 802.11 standard, so at
least
for now, leave this using SA Query procedure just like any other PMF
case.
Signed-off-by: Jouni Malinen
In message
, Kyle Evans writes:
> Poking at the router indicates that it is indeed during a rekey event.
>
> On Wed, Jul 18, 2018 at 12:56 PM, Adrian Chadd wrote
> :
> > Is it during a rekey event?
> >
> >
> >
> > -adrian
> >
> > On Wed, 18 Jul 2018 at 08:16, Kyle Evans wrote:
> >>
> >> On Wed, Jul 11, 2018 at 1:53 PM, Cy Schubert wrote:
> >> > Author: cy
> >> > Date: Wed Jul 11 18:53:18 2018
> >> > New Revision: 336203
> >> > URL: https://svnweb.freebsd.org/changeset/base/336203
> >> >
> >> > Log:
> >> > MFV r324714:
> >> >
> >> > Update wpa 2.5 --> 2.6.
> >> >
> >> > MFC after:1 month
> >> >
> >>
> >> Hi,
> >>
> >> Thanks again for the update! For some reason with 2.6, I'm seeing
> >> hourly (+/- a minute or two) disconnects:
> >>
> >> Jul 18 08:16:47 shiva wpa_supplicant[63771]: wlan0:
> >> CTRL-EVENT-DISCONNECTED bssid=... reason=1 locally_generated=1
> >> Jul 18 08:16:47 shiva kernel: wlan0: link state changed to DOWN
> >> Jul 18 08:16:47 shiva wpa_supplicant[63771]: ioctl[SIOCS80211, op=20,
> >> val=0, arg_len=7]: Can't assign requested address
> >> Jul 18 08:18:03 shiva wpa_supplicant[63771]: wlan0: Trying to
> >> associate with ... (SSID='FBI Surveillance Cat' freq=2437 MHz)
> >> Jul 18 08:18:03 shiva wpa_supplicant[63771]: wlan0: Associated with ...
> >> Jul 18 08:18:03 shiva kernel: wlan0: link state changed to UP
> >> Jul 18 08:18:03 shiva dhclient[40889]: send_packet: No buffer space availa
> ble
> >> Jul 18 08:18:03 shiva wpa_supplicant[63771]: wlan0: WPA: Key
> >> negotiation completed with ... [PTK=CCMP GTK=CCMP]
> >> Jul 18 08:18:03 shiva wpa_supplicant[63771]: wlan0:
> >> CTRL-EVENT-CONNECTED - Connection to ... completed [id=0 id_str=]
> >> Jul 18 08:18:06 shiva dhclient[42269]: New IP Address (wlan0): 192.168.1.1
> 50
> >> Jul 18 08:18:06 shiva dhclient[42841]: New Subnet Mask (wlan0): 255.255.25
> 5.0
> >> Jul 18 08:18:06 shiva dhclient[43080]: New Broadcast Address (wlan0):
> >> 192.168.1.255
> >> Jul 18 08:18:06 shiva dhclient[43248]: New Routers (wlan0): 192.168.1.1
> >>
> >> Any idea what that might be about? My wpa_supplicant.conf is fairly
> >> minimal with exactly one network specified.
> >>
> >> Thanks,
> >>
> >> Kyle Evans
> >>
diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
index 9027bbfc0..a1a037311 100644
--- a/src/ap/ieee802_11.c
+++ b/src/ap/ieee802_11.c
@@ -753,12 +753,24 @@ static int sae_sm_step(struct hostapd_data *hapd, struct
sta_info *sta,
}
break;
case SAE_ACCEPTED:
- if (auth_transaction == 1) {
+ if (auth_transaction == 1 &&
+ (hapd->conf->mesh & MESH_ENABLED)) {
wpa_printf(MSG_DEBUG, "SAE: remove the STA (" MACSTR
") doing reauthentication",
MAC2STR(sta->addr));
ap_free_sta(hapd, sta);
wpa_auth_pmksa_remove(hapd->wpa_auth, sta->addr);
+ } else if (auth_transaction == 1) {
+ wpa_printf(MSG_DEBUG, "SAE: Start reauthentication");
+ ret = auth_sae_send_commit(hapd, sta, bssid, 1);
+ if (ret)
+ return ret;
+ sae_set_state(sta, SAE_COMMITTED, "Sent Commit");
+
+ if (sae_process_commit(sta->sae) < 0)
+ return WLAN_STATUS_UNSPECIFIED_FAILURE;
+ sta->sae->sync = 0;
+ sae_set_retransmit_timer(hapd, sta);
} else {
if (sae_check_big_sync(hapd, sta))
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message <201807111853.w6biri9b080...@repo.freebsd.org>, Cy Schubert writes: > Author: cy > Date: Wed Jul 11 18:53:18 2018 > New Revision: 336203 > URL: https://svnweb.freebsd.org/changeset/base/336203 > > Log: > MFV r324714: > > Update wpa 2.5 --> 2.6. > > MFC after: 1 month Relnotes: yes -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336203 - in head: contrib/wpa contrib/wpa/hostapd contrib/wpa/hs20/client contrib/wpa/patches contrib/wpa/src/ap contrib/wpa/src/common contrib/wpa/src/crypto contrib/wpa/src/drive
In message <201807111853.w6biri9b080...@repo.freebsd.org>, Cy Schubert writes: > Author: cy > Date: Wed Jul 11 18:53:18 2018 > New Revision: 336203 > URL: https://svnweb.freebsd.org/changeset/base/336203 > > Log: > MFV r324714: > > Update wpa 2.5 --> 2.6. > > MFC after: 1 month This has been sitting in a to be committed tree and in my "prod" tree and in use for a while. Thanks to kevens@ for reminding me. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
