Re: wifi not resuming after zzz
On 2018-02-07 02:36, Stefan Sperling wrote: There is a known behaviour of the firmware where, on a 5 GHz channel, it will not transmit a probe request unless it first sees some other valid packet on the channel. This has to do with how the firmware deals with regulatory domains, which restrict 5Ghz channels in some parts of the world. I don't really understand exactly how it works, and how we can control it. But there are some parameters which go into the scan command which you could try tweaking to see if they have any effect, and let us know your results. Confirmed that this was the source of the behavior I was seeing. Other devices were sending valid packets in my prior testing where the 5GHz SSID was seen reliably. I moved to the 6.2 snapshots at the same time as other devices stopped being present. Bringing the other devices back on line returns the 6.2 snapshots to almost always working on 5GHz. If you want to try playing with these parameters to the firmware, (i.e. change them, recompile kernel, and test) you can find them in if_iwnreg.h: Thank you. I will try adjusting the active dwell times when I next have a quiet 5GHz SSID. Richard
Re: wifi not resuming after zzz
On Tue, Feb 06, 2018 at 08:10:10PM -0700, Richard Johnson wrote: > I initially noticed problems after I upgraded from 6.2 stable to the 6.2 > 2018-02-01 and 2018-02-05 snapshots. My trunk0 interface stopped being able > to use iwn0 on the 5GHz SSID for failover at boot time. > However, using the 2.4GHz SSID for failover works. > I can get 5GHz SSID working by first bringing iwn0 up on the 2.4GHz SSID, > then changing to the 5GHz SSID. One way: edit hostname.iwn0 and `doas sh > /etc/netstart iwn0`. > A zzz then sticks iwn0 in a non-responsive state. > If I then `ifconfig iwn0 down delete`, and switch back to the 2.4GHz SSID > (edit hostname.iwn0, redo netstart), I again get a working iwn0 on the > 2.4GHz net. > From there, I can switch back to the 5GHz SSID as above, until reboot or zzz > requires a repeat. There is a known behaviour of the firmware where, on a 5 GHz channel, it will not transmit a probe request unless it first sees some other valid packet on the channel. This has to do with how the firmware deals with regulatory domains, which restrict 5Ghz channels in some parts of the world. I don't really understand exactly how it works, and how we can control it. But there are some parameters which go into the scan command which you could try tweaking to see if they have any effect, and let us know your results. If you want to try playing with these parameters to the firmware, (i.e. change them, recompile kernel, and test) you can find them in if_iwnreg.h: /* * For active scan, listen ACTIVE_DWELL_TIME (msec) on each channel after * sending probe req. This should be set long enough to hear probe responses * from more than one AP. */ #define IWN_ACTIVE_DWELL_TIME_2GHZ (30)/* all times in msec */ #define IWN_ACTIVE_DWELL_TIME_5GHZ (20) #define IWN_ACTIVE_DWELL_FACTOR_2GHZ(3) #define IWN_ACTIVE_DWELL_FACTOR_5GHZ(2) /* * For passive scan, listen PASSIVE_DWELL_TIME (msec) on each channel. * Must be set longer than active dwell time. * For the most reliable scan, set > AP beacon interval (typically 100msec). */ #define IWN_PASSIVE_DWELL_TIME_2GHZ (20)/* all times in msec */ #define IWN_PASSIVE_DWELL_TIME_5GHZ (10) #define IWN_PASSIVE_DWELL_BASE (100) #define IWN_CHANNEL_TUNE_TIME (5) The firmware command is built in at iwn_scan() in if_iwn.c, so see there for more details. An 'active scan' happens if you have an SSID configured with 'ifconfig iwn0 nwid foo', and 'passive scan' happens if no SSID is configured. My theory is that because of the firmware's behaviour described above, sometimes 5Ghz APs do not show up in the list, as you can see in debug output I'm quoting below. > iwn0: end active scan > - 02:6b:9e:84:48:20 11 +181 54M ess privacy rsn "DIRECT-JC-VIZIOTV"! > - 04:bf:6d:c1:24:8f 11 +182 54M ess privacy rsn "OwlAmigas"! > - 06:0e:83:a3:6f:9f1 +185 54M ess no! rsn! "xfinitywifi"! > - 06:0e:83:a3:6f:a0 149 +171 54M ess no! rsn! "xfinitywifi"! > - 10:13:31:28:85:921 +181 54M ess privacy rsn "CenturyLink3108"! > - 2c:30:33:7b:29:136 +178 54M ess privacy rsn "Wonka"! > - 38:63:bb:74:a1:d3 11 +180 54M ess privacy rsn > "HP-Print-D3-Officejet Pro 8610"! > - 58:8b:f3:d6:97:63 11 +186 54M ess privacy rsn "Owlhaus"! > - 58:8b:f3:e2:cb:b9 11 +183 54M ess privacy rsn "CenturyLink7111"! > + c4:ea:1d:96:d6:7b1 +227 54M ess privacy rsn "Rope" > - c4:ea:1d:96:d6:80 48 +223 54M ess privacy rsn ""! > - c4:ea:1d:96:d6:81 48 +223 54M ess privacy rsn "Rope-5G"! Here it was found (but it didn't match our configured SSID) ^ > - e4:18:6b:e6:94:8b3 +185 54M ess privacy rsn "CenturyLink2479"! > - f4:0e:83:a3:6f:9f1 +185 54M ess privacy rsn "CurlySam"! > iwn0: end active scan > - 06:0e:83:a3:6f:9f1 +187 54M ess no! rsn! "xfinitywifi"! > - 10:13:31:28:85:921 +180 54M ess privacy rsn "CenturyLink3108"! > - 16:0e:83:a3:6f:a0 149 +171 54M ess privacy rsn ""! > - 2c:30:33:7b:29:136 +179 54M ess privacy rsn "Wonka"! > - 38:63:bb:74:a1:d3 11 +183 54M ess privacy rsn > "HP-Print-D3-Officejet Pro 8610"! > - 58:8b:f3:d6:97:63 11 +182 54M ess privacy rsn "Owlhaus"! > - 58:8b:f3:e2:cb:b9 11 +183 54M ess privacy rsn "CenturyLink7111"! > - 5c:8f:e0:6a:10:ac1 +187 54M ess privacy rsn "RedHouse"! > - 6e:8f:e0:6a:10:ac1 +196 54M ess no! rsn! "xfinitywifi"! > - 9e:8f:e0:6a:10:b1 36 +191 54M ess privacy rsn! ""! > + c4:ea:1d:96:d6:7b1 +227 54M ess privacy rsn "Rope" > - e0:b9:e5:87:3a:308 +181 54M ess privacy rsn "CenturyLink3451"! This time it was not found, even though other 5GHz APs are in the list. So the firmware didn't pass your AP's beacon/probe response to the driver, probably because it never received it.
Re: wifi not resuming after zzz
On 2018-02-03 10:02, Stefan Sperling wrote: On Fri, Feb 02, 2018 at 07:33:26PM -0800, kelly wrote: To: bugs@openbsd.org Subject: From: kelly Cc: kelly Reply-To: kelly Synopsis: wifi does not resume when waking up from zzz Category: wifI Environment: System : OpenBSD 6.2 Details : OpenBSD 6.2-current (GENERIC.MP) #398: Thu Feb 1 18:22:03 MST 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: I put the computer to sleep using zzz. When I resume, the internet does not connect automatically like it used to. I have to manually ifconfig to get the wifi connected again. I just updated OpenBSD today so I think it's related to the update. Before the update, wifi always reconnected automatically when I resumed from zzz. How-To-Repeat: Put computer to sleep using zzz. Resume/wake up computer later. Fix: Manually connect using ifconfig iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e: msi, MIMO 3T3R, MoW, address 24:77:03:1b:63:78 iwn auto-connects fine for me after resume from sleep with this kernel: $ sysctl kern.version kern.version=OpenBSD 6.2-current (GENERIC.MP) #399: Fri Feb 2 18:28:58 MST 2018 I am using this iwn device: iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, MIMO 2T2R, MoW, address xx:xx:xx:xx:xx:xx On my Lenovo X230 Tablet, a momentary zzz causes the same result, but only on 5GHz net. This happens on 6.2 amd64 snapshot from 2018-02-05 (yesterday). Steps to reproduce and results are below [1], where iwn0 only works on 5GHz after boot, or after return from zzz, if it's first brought up on 2.4GHz net. My device: | iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e: \ | msi, MIMO 3T3R, MoW, address 3c:a9:f4:82:f4:a4 fw_update tells me I have "iwn-firmware-5.11p1: ok". The /etc/firmware/iwn* files are dated Jan 21 16:44 (-0700). Full dmesg below, with iwn0 in debug mode. Richard === [1] I initially noticed problems after I upgraded from 6.2 stable to the 6.2 2018-02-01 and 2018-02-05 snapshots. My trunk0 interface stopped being able to use iwn0 on the 5GHz SSID for failover at boot time. However, using the 2.4GHz SSID for failover works. I can get 5GHz SSID working by first bringing iwn0 up on the 2.4GHz SSID, then changing to the 5GHz SSID. One way: edit hostname.iwn0 and `doas sh /etc/netstart iwn0`. A zzz then sticks iwn0 in a non-responsive state. If I then `ifconfig iwn0 down delete`, and switch back to the 2.4GHz SSID (edit hostname.iwn0, redo netstart), I again get a working iwn0 on the 2.4GHz net. From there, I can switch back to the 5GHz SSID as above, until reboot or zzz requires a repeat. === /etc/hostname.iwn0 for 2.4Ghz: - debug nwid Rope wpakey redactedforreporting dhcp - /etc/hostname.iwn0 for 5GHz: - debug nwid Rope-5G wpakey redactedforreporting dhcp - dmesg with iwn0 in debug, first multiple zzz on 2.4GHz without problems, then triggering zzz on 5GHz net: - OpenBSD 6.2-current (GENERIC.MP) #401: Mon Feb 5 21:07:05 MST 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16844521472 (16064MB) avail mem = 16327081984 (15570MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (69 entries) bios0: vendor LENOVO version "GCETA0WW (2.60 )" date 09/12/2014 bios0: LENOVO 343524U acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.80 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache acpihpet0: recalibrated TSC frequency 2893449557 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz cpu1:
Re: wifi not resuming after zzz
On Fri, Feb 02, 2018 at 07:33:26PM -0800, kelly wrote: > To: bugs@openbsd.org Subject: From: kelly Cc: kelly Reply-To: kelly > > >Synopsis:wifi does not resume when waking up from zzz Category: wifI > >Environment: > System : OpenBSD 6.2 Details : OpenBSD 6.2-current > (GENERIC.MP) #398: Thu Feb 1 18:22:03 MST 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 Machine : amd64 > >Description: > I put the computer to sleep using zzz. When I resume, the internet > does not connect automatically like it used to. I have to manually > ifconfig to get the wifi connected again. I just updated OpenBSD > today so I think it's related to the update. Before the update, wifi > always reconnected automatically when I resumed from zzz. > >How-To-Repeat: > Put computer to sleep using zzz. Resume/wake up computer later. > >Fix: > Manually connect using ifconfig > iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e: msi, > MIMO 3T3R, MoW, address 24:77:03:1b:63:78 iwn auto-connects fine for me after resume from sleep with this kernel: $ sysctl kern.version kern.version=OpenBSD 6.2-current (GENERIC.MP) #399: Fri Feb 2 18:28:58 MST 2018 I am using this iwn device: iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, MIMO 2T2R, MoW, address xx:xx:xx:xx:xx:xx If your problem persists, can you please show the full additional dmesg output generated by: ifconfig iwn0 debug
