subject:"Re\: initial 11n support for iwn \(n, not m\)"

Re: initial 11n support for iwn (n, not m)

2015-12-22 Thread Timo Myyrä

Stefan Sperling  writes:

> On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote:
>> On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
>> > With sthen@'s patch I can associate, dhcp, and use net.
>> 
>> Here's an updated iwn diff with a better approach for Stuart's fix.
>> 
>> Thanks for helping, Stuart, and to everyone who sent beacons which
>> allowed us to narrow this problem down to protection settings being
>> set up the wrong way in iwn_run().
>
> And another update (hopefully) fixing some reported issues, with some
> uncommitted net80211 changes included.
>
> I haven't put these diffs in yet because I'm still hearing about regressions
> in some form or another. Sometimes it's unclear what people are running,
> so I hope this version will linger for a bit and get tested.
> Thanks for all the help so far from more people than I expected!
>
> Index: dev/pci/if_iwn.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
> retrieving revision 1.148
> diff -u -p -r1.148 if_iwn.c
> --- dev/pci/if_iwn.c  25 Nov 2015 03:09:59 -  1.148
> +++ dev/pci/if_iwn.c  20 Dec 2015 11:18:52 -
> @@ -148,7 +148,7 @@ int   iwn_newstate(struct ieee80211com *,
>  void iwn_iter_func(void *, struct ieee80211_node *);
>  void iwn_calib_timeout(void *);
>  int  iwn_ccmp_decap(struct iwn_softc *, struct mbuf *,
> - struct ieee80211_key *);
> + struct ieee80211_node *);
>  void iwn_rx_phy(struct iwn_softc *, struct iwn_rx_desc *,
>   struct iwn_rx_data *);
>  void iwn_rx_done(struct iwn_softc *, struct iwn_rx_desc *,
> @@ -189,7 +189,7 @@ int   iwn5000_add_node(struct iwn_softc *
>   int);
>  int  iwn_set_link_quality(struct iwn_softc *,
>   struct ieee80211_node *);
> -int  iwn_add_broadcast_node(struct iwn_softc *, int);
> +int  iwn_add_broadcast_node(struct iwn_softc *, int, int);
>  void iwn_updateedca(struct ieee80211com *);
>  void iwn_set_led(struct iwn_softc *, uint8_t, uint8_t, uint8_t);
>  int  iwn_set_critical_temp(struct iwn_softc *);
> @@ -280,7 +280,7 @@ void  iwn_stop(struct ifnet *, int);
>  #ifdef IWN_DEBUG
>  #define DPRINTF(x)   do { if (iwn_debug > 0) printf x; } while (0)
>  #define DPRINTFN(n, x)   do { if (iwn_debug >= (n)) printf x; } while (0)
> -int iwn_debug = 0;
> +int iwn_debug = 1;
>  #else
>  #define DPRINTF(x)
>  #define DPRINTFN(n, x)
> @@ -458,6 +458,15 @@ iwn_attach(struct device *parent, struct
>   IEEE80211_C_PMGT;   /* power saving supported */
>  
>  #ifndef IEEE80211_NO_HT
> + /* No optional HT features supported for now, */
> + ic->ic_htcaps = 0;
> + ic->ic_htxcaps = 0;
> + ic->ic_txbfcaps = 0;
> + ic->ic_aselcaps = 0;
> +#endif
> +
> +#ifdef notyet
> +#ifndef IEEE80211_NO_HT
>   if (sc->sc_flags & IWN_FLAG_HAS_11N) {
>   /* Set HT capabilities. */
>   ic->ic_htcaps =
> @@ -475,6 +484,7 @@ iwn_attach(struct device *parent, struct
>   ic->ic_htcaps |= IEEE80211_HTCAP_SMPS_DIS;
>   }
>  #endif   /* !IEEE80211_NO_HT */
> +#endif   /* notyet */
>  
>   /* Set supported legacy rates. */
>   ic->ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
> @@ -487,10 +497,12 @@ iwn_attach(struct device *parent, struct
>   if (sc->sc_flags & IWN_FLAG_HAS_11N) {
>   /* Set supported HT rates. */
>   ic->ic_sup_mcs[0] = 0xff;   /* MCS 0-7 */
> +#ifdef notyet
>   if (sc->nrxchains > 1)
> - ic->ic_sup_mcs[1] = 0xff;   /* MCS 7-15 */
> + ic->ic_sup_mcs[1] = 0xff;   /* MCS 8-15 */
>   if (sc->nrxchains > 2)
>   ic->ic_sup_mcs[2] = 0xff;   /* MCS 16-23 */
> +#endif
>   }
>  #endif
>  
> @@ -515,9 +527,11 @@ iwn_attach(struct device *parent, struct
>  #ifndef IEEE80211_NO_HT
>   ic->ic_ampdu_rx_start = iwn_ampdu_rx_start;
>   ic->ic_ampdu_rx_stop = iwn_ampdu_rx_stop;
> +#ifdef notyet
>   ic->ic_ampdu_tx_start = iwn_ampdu_tx_start;
>   ic->ic_ampdu_tx_stop = iwn_ampdu_tx_stop;
>  #endif
> +#endif
>  
>   /* Override 802.11 state transition machine. */
>   sc->sc_newstate = ic->ic_newstate;
> @@ -1635,6 +1649,11 @@ iwn_read_eeprom_channels(struct iwn_soft
>   /* Save maximum allowed TX power for this channel. */
>   sc->maxpwr[chan] = channels[i].maxpwr;
>  
> +#ifndef IEEE80211_NO_HT
> + if (sc->sc_flags & IWN_FLAG_HAS_11N)
> + ic->ic_channels[chan].ic_flags |= IEEE80211_CHAN_HT;
> +#endif
> +
>   DPRINTF(("adding chan %d flags=0x%x maxpwr=%d\n",
>   chan, channels[i].flags, sc->maxpwr[chan]));
>   }
> @@ -1693,13 +1712,18 @@

Re: initial 11n support for iwn (n, not m)

2015-12-21 Thread Holger Mikolon

Works without issues on my Dell Studio 1555 since a day now.

$ ifconfig iwn0 | grep media
media: IEEE802.11 autoselect (HT-MCS7 mode 11n)

$ dmesg | grep iwn
iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO 3T3R, 
MoW, address 00:21:6a:56:2b:36

$ sysctl hw.product
hw.product=Studio 1555

Thanks!

Holger

> Date: Sun, 20 Dec 2015 19:59:19
> From: Stefan Sperling <s...@stsp.name>
> To: tech@openbsd.org
> Subject: Re: initial 11n support for iwn (n, not m)
> 
> On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote:
> > On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
> > > With sthen@'s patch I can associate, dhcp, and use net.
> > 
> > Here's an updated iwn diff with a better approach for Stuart's fix.
> > 
> > Thanks for helping, Stuart, and to everyone who sent beacons which
> > allowed us to narrow this problem down to protection settings being
> > set up the wrong way in iwn_run().
> 
> And another update (hopefully) fixing some reported issues, with some
> uncommitted net80211 changes included.
> 
> I haven't put these diffs in yet because I'm still hearing about regressions
> in some form or another. Sometimes it's unclear what people are running,
> so I hope this version will linger for a bit and get tested.
> Thanks for all the help so far from more people than I expected!

Re: initial 11n support for iwn (n, not m)

2015-12-21 Thread Marcus MERIGHI

s...@stsp.name (Stefan Sperling), 2015.12.20 (Sun) 19:59 (CET):
> On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote:
> > On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
> > > With sthen@'s patch I can associate, dhcp, and use net.
> > 
> > Here's an updated iwn diff with a better approach for Stuart's fix.
> > 
> > Thanks for helping, Stuart, and to everyone who sent beacons which
> > allowed us to narrow this problem down to protection settings being
> > set up the wrong way in iwn_run().
> 
> And another update (hopefully) fixing some reported issues, with some
> uncommitted net80211 changes included.
> 
> I haven't put these diffs in yet because I'm still hearing about regressions
> in some form or another. Sometimes it's unclear what people are running,
> so I hope this version will linger for a bit and get tested.
> Thanks for all the help so far from more people than I expected!

my iwn works:

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO
  3T3R, MoW
media: IEEE802.11 autoselect (HT-MCS7 mode 11n)
status: active

Thanks again, Stefan!

OpenBSD 5.9-beta (GENERIC.MP) #1: Mon Dec 21 13:49:20 CET 2015
fifi@fofo:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4166717440 (3973MB)
avail mem = 4036313088 (3849MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version "6DET72WW (3.22 )" date 10/25/2012
bios0: LENOVO 7470W1W
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.32 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz, 1862.00 MHz
cpu1: 
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "93P5030" serial   165 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 1862 MHz: speeds: 1867, 1866, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1280x800
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 
00:1f:16:32:df:5c
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev

Re: initial 11n support for iwn (n, not m)

2015-12-21 Thread Gregor Best

Hi Stefan,

On Sun, Dec 20, 2015 at 07:59:19PM +0100, Stefan Sperling wrote:
> On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote:
> > On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
> > > With sthen@'s patch I can associate, dhcp, and use net.
> > 
> > Here's an updated iwn diff with a better approach for Stuart's fix.
> > 
> > Thanks for helping, Stuart, and to everyone who sent beacons which
> > allowed us to narrow this problem down to protection settings being
> > set up the wrong way in iwn_run().
> 
> And another update (hopefully) fixing some reported issues, with some
> uncommitted net80211 changes included.
> 
> I haven't put these diffs in yet because I'm still hearing about regressions
> in some form or another. Sometimes it's unclear what people are running,
> so I hope this version will linger for a bit and get tested.
> Thanks for all the help so far from more people than I expected!

I've been  running a  kernel with  this patch  for a  few hours  and I'm
seeing a few fatal firmware errors in my dmesg:

iwn0: fatal firmware error
firmware error log:
  error type  = "SYSASSERT" (0x0005)
  program counter = 0x0001DFB0
  source line = 0x01FB
  error data  = 0x01FB000A
  branch link = 0x0001DF940001DF94
  interrupt link  = 0x0916
  time= 55706156
driver status:
  tx ring  0: qid=0  cur=2   queued=0
  tx ring  1: qid=1  cur=0   queued=0
  tx ring  2: qid=2  cur=0   queued=0
  tx ring  3: qid=3  cur=0   queued=0
  tx ring  4: qid=4  cur=30  queued=0
  tx ring  5: qid=5  cur=0   queued=0
  tx ring  6: qid=6  cur=0   queued=0
  tx ring  7: qid=7  cur=0   queued=0
  tx ring  8: qid=8  cur=0   queued=0
  tx ring  9: qid=9  cur=0   queued=0
  tx ring 10: qid=10 cur=0   queued=0
  tx ring 11: qid=11 cur=0   queued=0
  tx ring 12: qid=12 cur=0   queued=0
  tx ring 13: qid=13 cur=0   queued=0
  tx ring 14: qid=14 cur=0   queued=0
  tx ring 15: qid=15 cur=0   queued=0
  tx ring 16: qid=16 cur=0   queued=0
  tx ring 17: qid=17 cur=0   queued=0
  tx ring 18: qid=18 cur=0   queued=0
  tx ring 19: qid=19 cur=0   queued=0
  rx ring: cur=46
  802.11 state 4

These seem  to happen infrequently (the  last one was 3  hours ago), and
I've just noticed them so I don't have a pcap yet. I'm dumping right now
to see if it turns up again.

Apart from the  firmware errors, bandwidth is okay (3  Mbit/sec, but I'm
not the only  person in this WLAN) and scanning/attaching  seems to work
fine.

dmesg follows after the signature.

-- 
Gregor

OpenBSD 5.9-beta (GENERIC.MP) #153: Sun Dec 20 20:09:37 CET 2015
g...@hydrogen.unobtanium.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6314201088 (6021MB)
avail mem = 6118682624 (5835MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 6474B84
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) 
EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) 
EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.42 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 266MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.01 MHz
cpu1: 
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpiprt6 at acpi0:

Re: initial 11n support for iwn (n, not m)

2015-12-20 Thread Stefan Sperling

On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote:
> On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
> > With sthen@'s patch I can associate, dhcp, and use net.
> 
> Here's an updated iwn diff with a better approach for Stuart's fix.
> 
> Thanks for helping, Stuart, and to everyone who sent beacons which
> allowed us to narrow this problem down to protection settings being
> set up the wrong way in iwn_run().

And another update (hopefully) fixing some reported issues, with some
uncommitted net80211 changes included.

I haven't put these diffs in yet because I'm still hearing about regressions
in some form or another. Sometimes it's unclear what people are running,
so I hope this version will linger for a bit and get tested.
Thanks for all the help so far from more people than I expected!

Index: dev/pci/if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.148
diff -u -p -r1.148 if_iwn.c
--- dev/pci/if_iwn.c25 Nov 2015 03:09:59 -  1.148
+++ dev/pci/if_iwn.c20 Dec 2015 11:18:52 -
@@ -148,7 +148,7 @@ int iwn_newstate(struct ieee80211com *,
 void   iwn_iter_func(void *, struct ieee80211_node *);
 void   iwn_calib_timeout(void *);
 intiwn_ccmp_decap(struct iwn_softc *, struct mbuf *,
-   struct ieee80211_key *);
+   struct ieee80211_node *);
 void   iwn_rx_phy(struct iwn_softc *, struct iwn_rx_desc *,
struct iwn_rx_data *);
 void   iwn_rx_done(struct iwn_softc *, struct iwn_rx_desc *,
@@ -189,7 +189,7 @@ int iwn5000_add_node(struct iwn_softc *
int);
 intiwn_set_link_quality(struct iwn_softc *,
struct ieee80211_node *);
-intiwn_add_broadcast_node(struct iwn_softc *, int);
+intiwn_add_broadcast_node(struct iwn_softc *, int, int);
 void   iwn_updateedca(struct ieee80211com *);
 void   iwn_set_led(struct iwn_softc *, uint8_t, uint8_t, uint8_t);
 intiwn_set_critical_temp(struct iwn_softc *);
@@ -280,7 +280,7 @@ voidiwn_stop(struct ifnet *, int);
 #ifdef IWN_DEBUG
 #define DPRINTF(x) do { if (iwn_debug > 0) printf x; } while (0)
 #define DPRINTFN(n, x) do { if (iwn_debug >= (n)) printf x; } while (0)
-int iwn_debug = 0;
+int iwn_debug = 1;
 #else
 #define DPRINTF(x)
 #define DPRINTFN(n, x)
@@ -458,6 +458,15 @@ iwn_attach(struct device *parent, struct
IEEE80211_C_PMGT;   /* power saving supported */
 
 #ifndef IEEE80211_NO_HT
+   /* No optional HT features supported for now, */
+   ic->ic_htcaps = 0;
+   ic->ic_htxcaps = 0;
+   ic->ic_txbfcaps = 0;
+   ic->ic_aselcaps = 0;
+#endif
+
+#ifdef notyet
+#ifndef IEEE80211_NO_HT
if (sc->sc_flags & IWN_FLAG_HAS_11N) {
/* Set HT capabilities. */
ic->ic_htcaps =
@@ -475,6 +484,7 @@ iwn_attach(struct device *parent, struct
ic->ic_htcaps |= IEEE80211_HTCAP_SMPS_DIS;
}
 #endif /* !IEEE80211_NO_HT */
+#endif /* notyet */
 
/* Set supported legacy rates. */
ic->ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
@@ -487,10 +497,12 @@ iwn_attach(struct device *parent, struct
if (sc->sc_flags & IWN_FLAG_HAS_11N) {
/* Set supported HT rates. */
ic->ic_sup_mcs[0] = 0xff;   /* MCS 0-7 */
+#ifdef notyet
if (sc->nrxchains > 1)
-   ic->ic_sup_mcs[1] = 0xff;   /* MCS 7-15 */
+   ic->ic_sup_mcs[1] = 0xff;   /* MCS 8-15 */
if (sc->nrxchains > 2)
ic->ic_sup_mcs[2] = 0xff;   /* MCS 16-23 */
+#endif
}
 #endif
 
@@ -515,9 +527,11 @@ iwn_attach(struct device *parent, struct
 #ifndef IEEE80211_NO_HT
ic->ic_ampdu_rx_start = iwn_ampdu_rx_start;
ic->ic_ampdu_rx_stop = iwn_ampdu_rx_stop;
+#ifdef notyet
ic->ic_ampdu_tx_start = iwn_ampdu_tx_start;
ic->ic_ampdu_tx_stop = iwn_ampdu_tx_stop;
 #endif
+#endif
 
/* Override 802.11 state transition machine. */
sc->sc_newstate = ic->ic_newstate;
@@ -1635,6 +1649,11 @@ iwn_read_eeprom_channels(struct iwn_soft
/* Save maximum allowed TX power for this channel. */
sc->maxpwr[chan] = channels[i].maxpwr;
 
+#ifndef IEEE80211_NO_HT
+   if (sc->sc_flags & IWN_FLAG_HAS_11N)
+   ic->ic_channels[chan].ic_flags |= IEEE80211_CHAN_HT;
+#endif
+
DPRINTF(("adding chan %d flags=0x%x maxpwr=%d\n",
chan, channels[i].flags, sc->maxpwr[chan]));
}
@@ -1693,13 +1712,18 @@ iwn_newassoc(struct ieee80211com *ic, st
ieee80211_amrr_node_init(>amrr, >amn);
/* Start at lowest available bit-rate, AMRR will raise. */
ni->ni_txrate = 0;
+#ifndef

Re: initial 11n support for iwn (n, not m)

2015-12-20 Thread Frank Groeneveld


On 12/19/15 13:08, Stefan Sperling wrote:

On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
Here's an updated iwn diff with a better approach for Stuart's fix.

Thanks for helping, Stuart, and to everyone who sent beacons which
allowed us to narrow this problem down to protection settings being
set up the wrong way in iwn_run().


Assuming this fix was in yesterdays snapshot, it fixes my previously 
reported association problems. Thank you!


Frank

Re: initial 11n support for iwn (n, not m)

2015-12-19 Thread Mike

On 12/19/2015 7:08 AM, Stefan Sperling wrote:
> On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
>> With sthen@'s patch I can associate, dhcp, and use net.
> 
> Here's an updated iwn diff with a better approach for Stuart's fix.
> 
> [snip]

I was able to do some limited testing with this patch (a 100MB file copy
from a http server using lynx) and it looks OK here.

hw.version=ThinkPad T400

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO
1T2R, MoW, address 00:26:c6:...

iwn0: flags=208843 mtu
1500
lladdr 00:26:c6:...
priority: 4
groups: wlan
media: IEEE802.11 autoselect (HT-MCS2 mode 11n)
status: active
ieee80211: nwid "Configuration Error" chan 48 bssid b4:75:0e:...
-43dBm wpaprotos wpa1,wpa2 wpaakms 802.1x wpaciphers tkip,ccmp
wpagroupcipher tkip

# dmesg
OpenBSD 5.8-current (GENERIC.MP) #3: Sat Dec 19 09:37:03 EST 2015
root@otest:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4166717440 (3973MB)
avail mem = 4036304896 (3849MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 6475DQ3
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT
TCPA DMAR SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4)
EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3)
EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.38 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 265MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.00 MHz
cpu1:
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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus 5 (EXP3)
acpiprt6 at acpi0: bus 13 (EXP4)
acpiprt7 at acpi0: bus 21 (PCI1)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10),
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4678" serial  1101 type LION oem
"Panasonic"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK docked (15)
cpu0: Enhanced SpeedStep 2261 MHz: speeds: 2267, 2266, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1280x800
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
"Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi,
address 00:22:68:...
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi
azalia0: codecs: Conexant CX20561
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev

Re: initial 11n support for iwn (n, not m)

2015-12-19 Thread Raf Czlonka

On Fri, Dec 18, 2015 at 12:13:49PM GMT, Raf Czlonka wrote:
> On Thu, Dec 17, 2015 at 12:38:59PM GMT, Stuart Henderson wrote:
> 
> > So the only new issue I have with this diff is with manual scans
> > (as I mentioned before, but now with logs) - the scan runs and
> > ifconfig displays the expected output (at the point around where 'scan
> > finished' is logged, marked with > in the paste below), the radio
> > status LED remains flashing (expected as there's nothing to change the
> > LED state until it associates), it keeps logging 'received beacon',
> > and won't reassociate.
> 
> Exactly the same behaviour here on:
> 
> iwn0 at pci3 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 
> 1T2R, MoW

And on another one:

iwn0 at pci1 dev 0 function 0 "Intel WiFi Link 1000" rev 0x00: msi, MIMO 1T2R, 
BGS

> > "ifconfig iwn0 -chan" clears this and lets me re-associate (re-inits
> > the device; ifconfig down+up clears it as well but -chan is less
> > disruptive as dhclient stays running that way). So I do have a usable
> > workaround.
> 
> This fixes it here as well - thanks for the tip Stuart!

On this one, I had to run the command twice - first time it "stuck" and
had to kill it, the second time it worked as above.

> > I'm not quite sure what's different between the automatic scans when
> > looking for a network to associate with, and the manually triggered
> > ones.
> 
> My /etc/hostname.iwn0 runs a script which uses 'scan' and that works
> fine - no idea why manual one is "special".
> 
> Other than that, it seems to be working fine - tested briefly on
> 'eduroam' with Aruba AP 214.
> 
> Regards,
> 
> Raf
> 
> P.S. I've noticed that new snapshots are now built with the patch :^)

Working fine so far - only tested on a home Virgin Media-branded Super
Hub (Netgear) router/AP.

Raf

Re: initial 11n support for iwn (n, not m)

2015-12-19 Thread Stefan Sperling

On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
> With sthen@'s patch I can associate, dhcp, and use net.

Here's an updated iwn diff with a better approach for Stuart's fix.

Thanks for helping, Stuart, and to everyone who sent beacons which
allowed us to narrow this problem down to protection settings being
set up the wrong way in iwn_run().

Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.148
diff -u -p -r1.148 if_iwn.c
--- if_iwn.c25 Nov 2015 03:09:59 -  1.148
+++ if_iwn.c19 Dec 2015 11:02:47 -
@@ -148,7 +148,7 @@ int iwn_newstate(struct ieee80211com *,
 void   iwn_iter_func(void *, struct ieee80211_node *);
 void   iwn_calib_timeout(void *);
 intiwn_ccmp_decap(struct iwn_softc *, struct mbuf *,
-   struct ieee80211_key *);
+   struct ieee80211_node *);
 void   iwn_rx_phy(struct iwn_softc *, struct iwn_rx_desc *,
struct iwn_rx_data *);
 void   iwn_rx_done(struct iwn_softc *, struct iwn_rx_desc *,
@@ -189,7 +189,7 @@ int iwn5000_add_node(struct iwn_softc *
int);
 intiwn_set_link_quality(struct iwn_softc *,
struct ieee80211_node *);
-intiwn_add_broadcast_node(struct iwn_softc *, int);
+intiwn_add_broadcast_node(struct iwn_softc *, int, int);
 void   iwn_updateedca(struct ieee80211com *);
 void   iwn_set_led(struct iwn_softc *, uint8_t, uint8_t, uint8_t);
 intiwn_set_critical_temp(struct iwn_softc *);
@@ -458,6 +458,15 @@ iwn_attach(struct device *parent, struct
IEEE80211_C_PMGT;   /* power saving supported */
 
 #ifndef IEEE80211_NO_HT
+   /* No optional HT features supported for now, */
+   ic->ic_htcaps = 0;
+   ic->ic_htxcaps = 0;
+   ic->ic_txbfcaps = 0;
+   ic->ic_aselcaps = 0;
+#endif
+
+#ifdef notyet
+#ifndef IEEE80211_NO_HT
if (sc->sc_flags & IWN_FLAG_HAS_11N) {
/* Set HT capabilities. */
ic->ic_htcaps =
@@ -475,6 +484,7 @@ iwn_attach(struct device *parent, struct
ic->ic_htcaps |= IEEE80211_HTCAP_SMPS_DIS;
}
 #endif /* !IEEE80211_NO_HT */
+#endif /* notyet */
 
/* Set supported legacy rates. */
ic->ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
@@ -487,10 +497,12 @@ iwn_attach(struct device *parent, struct
if (sc->sc_flags & IWN_FLAG_HAS_11N) {
/* Set supported HT rates. */
ic->ic_sup_mcs[0] = 0xff;   /* MCS 0-7 */
+#ifdef notyet
if (sc->nrxchains > 1)
-   ic->ic_sup_mcs[1] = 0xff;   /* MCS 7-15 */
+   ic->ic_sup_mcs[1] = 0xff;   /* MCS 8-15 */
if (sc->nrxchains > 2)
ic->ic_sup_mcs[2] = 0xff;   /* MCS 16-23 */
+#endif
}
 #endif
 
@@ -515,9 +527,11 @@ iwn_attach(struct device *parent, struct
 #ifndef IEEE80211_NO_HT
ic->ic_ampdu_rx_start = iwn_ampdu_rx_start;
ic->ic_ampdu_rx_stop = iwn_ampdu_rx_stop;
+#ifdef notyet
ic->ic_ampdu_tx_start = iwn_ampdu_tx_start;
ic->ic_ampdu_tx_stop = iwn_ampdu_tx_stop;
 #endif
+#endif
 
/* Override 802.11 state transition machine. */
sc->sc_newstate = ic->ic_newstate;
@@ -1635,6 +1649,11 @@ iwn_read_eeprom_channels(struct iwn_soft
/* Save maximum allowed TX power for this channel. */
sc->maxpwr[chan] = channels[i].maxpwr;
 
+#ifndef IEEE80211_NO_HT
+   if (sc->sc_flags & IWN_FLAG_HAS_11N)
+   ic->ic_channels[chan].ic_flags |= IEEE80211_CHAN_HT;
+#endif
+
DPRINTF(("adding chan %d flags=0x%x maxpwr=%d\n",
chan, channels[i].flags, sc->maxpwr[chan]));
}
@@ -1693,13 +1712,18 @@ iwn_newassoc(struct ieee80211com *ic, st
ieee80211_amrr_node_init(>amrr, >amn);
/* Start at lowest available bit-rate, AMRR will raise. */
ni->ni_txrate = 0;
+#ifndef IEEE80211_NO_HT
+   ni->ni_txmcs = 0;
+#endif
 
for (i = 0; i < ni->ni_rates.rs_nrates; i++) {
rate = ni->ni_rates.rs_rates[i] & IEEE80211_RATE_VAL;
/* Map 802.11 rate to HW rate index. */
-   for (ridx = 0; ridx <= IWN_RIDX_MAX; ridx++)
-   if (iwn_rates[ridx].rate == rate)
+   for (ridx = 0; ridx <= IWN_RIDX_MAX; ridx++) {
+   if (iwn_rates[ridx].plcp != IWN_PLCP_INVALID &&
+   iwn_rates[ridx].rate == rate)
break;
+   }
wn->ridx[i] = ridx;
}
 }
@@ -1716,12 +1740,17 @@ iwn_media_change(struct ifnet *ifp)
if (error != ENETRESET)
return error;
 
+#ifndef IEEE80211_NO_HT
+   if

Re: initial 11n support for iwn (n, not m)

2015-12-19 Thread Dimitris Papastamos

On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote:
> On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote:
> > With sthen@'s patch I can associate, dhcp, and use net.
> 
> Here's an updated iwn diff with a better approach for Stuart's fix.
> 
> Thanks for helping, Stuart, and to everyone who sent beacons which
> allowed us to narrow this problem down to protection settings being
> set up the wrong way in iwn_run().

Thanks, works well on my T420!

iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
MIMO 2T2R, MoW, address a0:88:b4:48:4d:a4

iwn0: flags=8843 mtu 1500
lladdr a0:88:b4:48:4d:a4
priority: 4
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS7 mode 11n)
status: active
ieee80211: nwid ElectricKingdom chan 6 bssid ac:22:0b:32:d5:48
-19dBm wpakey  wpaprotos wpa1,wpa2 wpaakms psk wpaciphers 
tkip,ccmp wpagroupcipher tkip
inet6 fe80::a288:b4ff:fe48:4da4%iwn0 prefixlen 64 scopeid 0x2
inet 10.0.0.3 netmask 0xff00 broadcast 10.0.0.255

Re: initial 11n support for iwn (n, not m)

2015-12-18 Thread Raf Czlonka

On Thu, Dec 17, 2015 at 12:38:59PM GMT, Stuart Henderson wrote:

> So the only new issue I have with this diff is with manual scans
> (as I mentioned before, but now with logs) - the scan runs and
> ifconfig displays the expected output (at the point around where 'scan
> finished' is logged, marked with > in the paste below), the radio
> status LED remains flashing (expected as there's nothing to change the
> LED state until it associates), it keeps logging 'received beacon',
> and won't reassociate.

Exactly the same behaviour here on:

iwn0 at pci3 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R, 
MoW

> "ifconfig iwn0 -chan" clears this and lets me re-associate (re-inits
> the device; ifconfig down+up clears it as well but -chan is less
> disruptive as dhclient stays running that way). So I do have a usable
> workaround.

This fixes it here as well - thanks for the tip Stuart!

> I'm not quite sure what's different between the automatic scans when
> looking for a network to associate with, and the manually triggered
> ones.

My /etc/hostname.iwn0 runs a script which uses 'scan' and that works
fine - no idea why manual one is "special".

Other than that, it seems to be working fine - tested briefly on
'eduroam' with Aruba AP 214.

Regards,

Raf

P.S. I've noticed that new snapshots are now built with the patch :^)

Re: initial 11n support for iwn (n, not m)

2015-12-18 Thread David Hill

On Fri, Dec 18, 2015 at 08:52:07PM +, Stuart Henderson wrote:
> On 2015/12/17 19:43, Frank Groeneveld wrote:
> > iwn0: fatal firmware error
> 
> So this firmware crash...
> 
> > firmware error log:
> >   error type  = "UNKNOWN" (0x14E2)
> >   program counter = 0x00018100
> >   source line = 0x0216
> >   error data  = 0x0028
> >   branch link = 0x000180E2000180E2
> >   interrupt link  = 0xDBEA
> >   time= 3006541902
> 
> I'm seeing the same crash when I associate to a 2GHz channel where
> the AP has set a flag in beacons to warn stations that there are
> non-11n devices associated.
> 
> Around line 4900 in sys/dev/pci/if_iwn.c you have this:
> 
> case IEEE80211_HTPROT_NONE:
> break;
> case IEEE80211_HTPROT_NONMEMBER:
> case IEEE80211_HTPROT_NONHT_MIXED:
> sc->rxon.flags |=
> htole32(IWN_RXON_HT_RXON_HT_MODE_MIXED);
> break;
> 
> Try this as I suspect it might fix your crash (unless Stefan
> comes up with a better change to try first :)
> 
>   case IEEE80211_HTPROT_NONE:
>   break;
>   case IEEE80211_HTPROT_NONMEMBER:
>   case IEEE80211_HTPROT_NONHT_MIXED:
>   if (IEEE80211_IS_CHAN_5GHZ(ni->ni_chan))
>   sc->rxon.flags |=
>   htole32(IWN_RXON_HT_RXON_HT_MODE_MIXED);
>   break;
>

I had the firmware bug on Centrino Ultimate-N 6300:
iwn0: fatal firmware error
firmware error log:
  error type  = "SYSASSERT" (0x0005)
  program counter = 0x00022278
  source line = 0x0218
  error data  = 0x0218000B
  branch link = 0x0002225800022258
  interrupt link  = 0x1532
  time= 2127856977


With sthen@'s patch I can associate, dhcp, and use net.

Nice find!

- David

Re: initial 11n support for iwn (n, not m)

2015-12-18 Thread Stuart Henderson

On 2015/12/17 19:43, Frank Groeneveld wrote:
> iwn0: fatal firmware error

So this firmware crash...

> firmware error log:
>   error type  = "UNKNOWN" (0x14E2)
>   program counter = 0x00018100
>   source line = 0x0216
>   error data  = 0x0028
>   branch link = 0x000180E2000180E2
>   interrupt link  = 0xDBEA
>   time= 3006541902

I'm seeing the same crash when I associate to a 2GHz channel where
the AP has set a flag in beacons to warn stations that there are
non-11n devices associated.

Around line 4900 in sys/dev/pci/if_iwn.c you have this:

case IEEE80211_HTPROT_NONE:
break;
case IEEE80211_HTPROT_NONMEMBER:
case IEEE80211_HTPROT_NONHT_MIXED:
sc->rxon.flags |=
htole32(IWN_RXON_HT_RXON_HT_MODE_MIXED);
break;

Try this as I suspect it might fix your crash (unless Stefan
comes up with a better change to try first :)

case IEEE80211_HTPROT_NONE:
break;
case IEEE80211_HTPROT_NONMEMBER:
case IEEE80211_HTPROT_NONHT_MIXED:
if (IEEE80211_IS_CHAN_5GHZ(ni->ni_chan))
sc->rxon.flags |=
htole32(IWN_RXON_HT_RXON_HT_MODE_MIXED);
break;

Re: initial 11n support for iwn (n, not m)

2015-12-17 Thread Frank Groeneveld


On 12/16/15 15:35, Stefan Sperling wrote:

This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.

It also tweaks replay detection for CCMP encrypted frames, which needed
tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes
this driver was discarding some retransmitted frames for no good reason.

This driver supports a very wide range of hardware so please test this
with as many iwn(4) adapters as possible. If we don't get enough tests
this change may not be able to make the 5.9 release.

Works for me on:
iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, 
MIMO 2T2R, MoW

Please post here or let me know in private which hardware you're testing on.
Thanks.

Note that if you'd like to test monitor mode you'll need to apply
this to a -current source tree from today.


Thanks for you work on this! I've tested it on my laptop and it gives me 
firmware errors. I've attached dmesg from both a the working and the 
patched, non-working kernels. Let me know if you need any other information.


Frank
OpenBSD 5.8-current (GENERIC.MP) #1737: Thu Dec 10 23:29:07 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4157837312 (3965MB)
avail mem = 4027703296 (3841MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba60 (23 entries)
bios0: vendor American Megatrends Inc. version "UX31A.219" date 06/14/2013
bios0: ASUSTeK COMPUTER INC. UX31A
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ECDT MCFG SSDT SSDT SSDT SSDT HPET SSDT SSDT 
SSDT SSDT DMAR MSDM
acpi0: wakeup devices P0P1(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) USB1(S3) 
USB2(S3) USB3(S3) USB4(S3) EHC2(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S4) 
RP01(S4) RP02(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1796.22 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
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 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 MHz
cpu1: 
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 MHz
cpu2: 
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 MHz
cpu3: 
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus -1 (PEG0)
acpiprt3 at acpi0: bus -1 (PEG1)
acpiprt4 at acpi0: bus -1 (PEG2)
acpiprt5 at acpi0: bus -1 (PEG3)
acpiprt6 at acpi0: bus 1 (RP01)
acpiprt7 at acpi0: bus 2 (RP02)
acpiprt8 at acpi0: bus -1 (RP03)
acpiprt9 at acpi0: bus -1 (RP04)
acpiprt10 at acpi0: bus -1 (RP05)
acpiprt11 at acpi0: bus -1 (RP06)
acpiprt12 at acpi0: bus -1 (RP07)
acpiprt13 at acpi0: bus -1 (RP08)
acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu2 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu3 at acpi0: C3(200@87

Re: initial 11n support for iwn (n, not m)

2015-12-16 Thread Stefan Sperling

On Wed, Dec 16, 2015 at 03:35:22PM +0100, Stefan Sperling wrote:
> This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.

I went through my pile of wlan cards and found a few more iwn
devices in there.

Current test stats are:

Tested by myself, working:
iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, 
MIMO 2T2R, MoW
iwn0 at pci6 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO 3T3R, 
MoW, 
iwn0 at pci6 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e: msi, 
MIMO 3T3R, MoW
iwn0 at pci6 dev 0 function 0 "Intel WiFi Link 1000" rev 0x00: msi, MIMO 1T2R, 
BGS

Tested by others, working:
iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
MIMO 2T2R, MoW
iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e: msi, 
MIMO 3T3R, MoW

Tested by others, not working:
firmware SYSASSERT: iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 
6300" rev 0x35: msi, MIMO 3T3R, MoW

Re: initial 11n support for iwn (n, not m)

2015-12-16 Thread Stefan Sperling

On Wed, Dec 16, 2015 at 04:46:19PM +0100, Gregor Best wrote:
> I have done some speed testing,  but with inconclusive results. I used a
> Macbook Pro with  OS X as the  other side, testing was  done with iperf,
> both machines connected to the same WiFi:
> 
> $ iperf -i 2 -c 192.168.178.54
> 
> Client connecting to 192.168.178.54, TCP port 5001
> TCP window size: 17.0 KByte (default)
> 
> [  3] local 192.168.178.49 port 30131 connected with 192.168.178.54 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0- 2.0 sec   768 KBytes  3.15 Mbits/sec
> [  3]  2.0- 4.0 sec   640 KBytes  2.62 Mbits/sec
> [  3]  4.0- 6.0 sec   640 KBytes  2.62 Mbits/sec
> [  3]  6.0- 8.0 sec   512 KBytes  2.10 Mbits/sec
> [  3]  8.0-10.0 sec   640 KBytes  2.62 Mbits/sec
> [  3]  0.0-10.3 sec  3.25 MBytes  2.64 Mbits/sec
> 
> I assume the low  bandwidth is due to the two  thick walls separating my
> laptops and the  access point. Everything else seems to  be fine though.
> I'll  retry the  speed  measurement in  a  few days  when  I'm home  for
> christmas.

Traffic bursts lasting less than 10s are probably too short to trigger
AMRR into raising the data rate all the way up. The initial rate is the
lowest one. The bandwidth values look about right to me, though, at least
for 2Ghz (assuming your AP is not alone somewhere on a remote island).

On 5Ghz you might see more, depending on whether the AP sends aggregated
frames for not. Run 'ifconfig iwn0 debug' and look for lines in dmesg
saying 'received action...' -- these frames are ADDBA and DELBA requests
used to negotiate use of A-MPDUs.

Re: initial 11n support for iwn (n, not m)

2015-12-16 Thread David Hill

On Wed, Dec 16, 2015 at 05:15:27PM +0100, Stefan Sperling wrote:
> On Wed, Dec 16, 2015 at 10:14:49AM -0500, David Hill wrote:
> > Hi Stefan -
> > 
> > Thanks for the 11n work!
> > 
> > Unfortunately, your diff breaks iwn on my machine.
> > 
> > iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x35:
> > msi, MIMO 3T3R, MoW, 
> > 
> > It spews over and over:
> > 
> > iwn0: fatal firmware error
> > firmware error log:
> >   error type  = "SYSASSERT" (0x0005)
> >   program counter = 0x00022278
> >   source line = 0x0218
> >   error data  = 0x0218000B
> >   branch link = 0x0002225800022258
> >   interrupt link  = 0x1532
> >   time= 2127856977
> > driver status:
> >   tx ring  0: qid=0  cur=4   queued=0  
> >   tx ring  1: qid=1  cur=0   queued=0  
> >   tx ring  2: qid=2  cur=0   queued=0  
> >   tx ring  3: qid=3  cur=0   queued=0  
> >   tx ring  4: qid=4  cur=41  queued=0  
> >   tx ring  5: qid=5  cur=0   queued=0  
> >   tx ring  6: qid=6  cur=0   queued=0  
> >   tx ring  7: qid=7  cur=0   queued=0  
> >   tx ring  8: qid=8  cur=0   queued=0  
> >   tx ring  9: qid=9  cur=0   queued=0  
> >   tx ring 10: qid=10 cur=0   queued=0  
> >   tx ring 11: qid=11 cur=0   queued=0  
> >   tx ring 12: qid=12 cur=0   queued=0  
> >   tx ring 13: qid=13 cur=0   queued=0  
> >   tx ring 14: qid=14 cur=0   queued=0  
> >   tx ring 15: qid=15 cur=0   queued=0  
> >   tx ring 16: qid=16 cur=0   queued=0  
> >   tx ring 17: qid=17 cur=0   queued=0  
> >   tx ring 18: qid=18 cur=0   queued=0  
> >   tx ring 19: qid=19 cur=0   queued=0  
> >   rx ring: cur=14
> >   802.11 state 4
> > 
> 
> Thanks for testing!
> 
> I cannot do much based on the information provided.
> Could you recompile with IWM_DEBUG defined, and perhaps place a few
> additional printfs at strategic locations, to figure out which
> firmware command is last sent before the firmware crashes?
> That would help me a great deal.
> 
> If you don't want the firmware to be restarted over and over so it
> won't print these lines repeatedly, disabling the init_task which
> attempts to recover from firmware crashes might help:
> 
>   if (r1 & (IWN_INT_SW_ERR | IWN_INT_HW_ERR)) {
>   printf("%s: fatal firmware error\n", sc->sc_dev.dv_xname);
>   /* Dump firmware error log and stop. */
>   iwn_fatal_intr(sc);
>   iwn_stop(ifp, 1);
>   task_add(systq, >init_task); <-- remove this line
>   return 1;
>   }
>


Little more time to play, but not much. Will play more tonight.

I do not have open wifi to test with, wpakey required.

16:21:14.335908 802.11 flags=0<>: probe response,
caps=2061, ssid (wifi),
rates 1M 2M 5M 11M 6M 9M 12M 18M, ds (chan 11), country 'US ', erp 0x00,
rsn 0x010fac04010fac04010fac02, xrates 24M 36M 48M 54M,
htcaps=<20MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 3839,A-MPDU max 65535,A-MPDU
spacing 8.00us,RxMCS 0x>, 

ifconfig iwn0 up works
ifconfig iwn0 scan works

but as soon as I use nwid/wpakey to associate, it bombs.

...

sending scan command nchan=24
scan finished nchan=24 status=1 chan=165
sending scan command nchan=13
scan finished nchan=13 status=1 chan=13
sending scan command nchan=24
scan finished nchan=24 status=1 chan=165
rxon chan 11 flags 40008025 cck f ofdm 15 
setting TX power
adding broadcast node
timing bintval=400, tstamp=5529864295299, init=306301
iwn_run: htprot = 3
rxon chan 11 flags 44008035 cck f ofdm 15
setting TX power
adding BSS node
setting link quality for node 0 
setting initial differential gains
sending request for statistics
iwn0: fatal firmware error
firmware error log:
  error type  = "SYSASSERT" (0x0005)
  program counter = 0x00022278
  source line = 0x0218
  error data  = 0x0218000B
  branch link = 0x0002225800022258
  interrupt link  = 0x1532
  time= 2241458206
driver status:
  tx ring  0: qid=0  cur=2   queued=0
  tx ring  1: qid=1  cur=0   queued=0
  tx ring  2: qid=2  cur=0   queued=0
  tx ring  3: qid=3  cur=0   queued=0
  tx ring  4: qid=4  cur=63  queued=0
  tx ring  5: qid=5  cur=0   queued=0
  tx ring  6: qid=6  cur=0   queued=0
  tx ring  7: qid=7  cur=0   queued=0
  tx ring  8: qid=8  cur=0   queued=0
  tx ring  9: qid=9  cur=0   queued=0
  tx ring 10: qid=10 cur=0   queued=0
  tx ring 11: qid=11 cur=0   queued=0
  tx ring 12: qid=12 cur=0   queued=0
  tx ring 13: qid=13 cur=0   queued=0
  tx ring 14: qid=14 cur=0   queued=0
  tx ring 15: qid=15 cur=0   queued=0
  tx ring 16: qid=16 cur=0   queued=0
  tx ring 17: qid=17 cur=0   queued=0
  tx ring 18: qid=18 cur=0   queued=0
  tx ring 19: qid=19 cur=0   queued=0
  rx ring: cur=20
  802.11 state 4

Re: initial 11n support for iwn (n, not m)

2015-12-16 Thread David Hill

Hi Stefan -

Thanks for the 11n work!

Unfortunately, your diff breaks iwn on my machine.

iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x35:
msi, MIMO 3T3R, MoW, 

It spews over and over:

iwn0: fatal firmware error
firmware error log:
  error type  = "SYSASSERT" (0x0005)
  program counter = 0x00022278
  source line = 0x0218
  error data  = 0x0218000B
  branch link = 0x0002225800022258
  interrupt link  = 0x1532
  time= 2127856977
driver status:
  tx ring  0: qid=0  cur=4   queued=0  
  tx ring  1: qid=1  cur=0   queued=0  
  tx ring  2: qid=2  cur=0   queued=0  
  tx ring  3: qid=3  cur=0   queued=0  
  tx ring  4: qid=4  cur=41  queued=0  
  tx ring  5: qid=5  cur=0   queued=0  
  tx ring  6: qid=6  cur=0   queued=0  
  tx ring  7: qid=7  cur=0   queued=0  
  tx ring  8: qid=8  cur=0   queued=0  
  tx ring  9: qid=9  cur=0   queued=0  
  tx ring 10: qid=10 cur=0   queued=0  
  tx ring 11: qid=11 cur=0   queued=0  
  tx ring 12: qid=12 cur=0   queued=0  
  tx ring 13: qid=13 cur=0   queued=0  
  tx ring 14: qid=14 cur=0   queued=0  
  tx ring 15: qid=15 cur=0   queued=0  
  tx ring 16: qid=16 cur=0   queued=0  
  tx ring 17: qid=17 cur=0   queued=0  
  tx ring 18: qid=18 cur=0   queued=0  
  tx ring 19: qid=19 cur=0   queued=0  
  rx ring: cur=14
  802.11 state 4

Re: initial 11n support for iwn (n, not m)

2015-12-16 Thread Stefan Sperling

On Wed, Dec 16, 2015 at 10:14:49AM -0500, David Hill wrote:
> Hi Stefan -
> 
> Thanks for the 11n work!
> 
> Unfortunately, your diff breaks iwn on my machine.
> 
> iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x35:
> msi, MIMO 3T3R, MoW, 
> 
> It spews over and over:
> 
> iwn0: fatal firmware error
> firmware error log:
>   error type  = "SYSASSERT" (0x0005)
>   program counter = 0x00022278
>   source line = 0x0218
>   error data  = 0x0218000B
>   branch link = 0x0002225800022258
>   interrupt link  = 0x1532
>   time= 2127856977
> driver status:
>   tx ring  0: qid=0  cur=4   queued=0  
>   tx ring  1: qid=1  cur=0   queued=0  
>   tx ring  2: qid=2  cur=0   queued=0  
>   tx ring  3: qid=3  cur=0   queued=0  
>   tx ring  4: qid=4  cur=41  queued=0  
>   tx ring  5: qid=5  cur=0   queued=0  
>   tx ring  6: qid=6  cur=0   queued=0  
>   tx ring  7: qid=7  cur=0   queued=0  
>   tx ring  8: qid=8  cur=0   queued=0  
>   tx ring  9: qid=9  cur=0   queued=0  
>   tx ring 10: qid=10 cur=0   queued=0  
>   tx ring 11: qid=11 cur=0   queued=0  
>   tx ring 12: qid=12 cur=0   queued=0  
>   tx ring 13: qid=13 cur=0   queued=0  
>   tx ring 14: qid=14 cur=0   queued=0  
>   tx ring 15: qid=15 cur=0   queued=0  
>   tx ring 16: qid=16 cur=0   queued=0  
>   tx ring 17: qid=17 cur=0   queued=0  
>   tx ring 18: qid=18 cur=0   queued=0  
>   tx ring 19: qid=19 cur=0   queued=0  
>   rx ring: cur=14
>   802.11 state 4
> 

Thanks for testing!

I cannot do much based on the information provided.
Could you recompile with IWM_DEBUG defined, and perhaps place a few
additional printfs at strategic locations, to figure out which
firmware command is last sent before the firmware crashes?
That would help me a great deal.

If you don't want the firmware to be restarted over and over so it
won't print these lines repeatedly, disabling the init_task which
attempts to recover from firmware crashes might help:

if (r1 & (IWN_INT_SW_ERR | IWN_INT_HW_ERR)) {
printf("%s: fatal firmware error\n", sc->sc_dev.dv_xname);
/* Dump firmware error log and stop. */
iwn_fatal_intr(sc);
iwn_stop(ifp, 1);
task_add(systq, >init_task); <-- remove this line
return 1;
}

Re: initial 11n support for iwn (n, not m)

2015-12-16 Thread Gregor Best

Hi Stefan,

On Wed, Dec 16, 2015 at 03:35:22PM +0100, Stefan Sperling wrote:
> This diff  adds 11n MCS  0-7 with A-MPDU and  A-MSDU Rx to  the iwn(4)
> driver.
> [...]

Whoo! Thanks a lot for your hard work :)

> [...]
> Please post  here or  let me  know in  private which  hardware you're.
> testing on Thanks.
> [...]

Works for me on:

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R, 
MoW, address 00:22:fa:d0:2f:a0

I have done some speed testing,  but with inconclusive results. I used a
Macbook Pro with  OS X as the  other side, testing was  done with iperf,
both machines connected to the same WiFi:

$ iperf -i 2 -c 192.168.178.54

Client connecting to 192.168.178.54, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 192.168.178.49 port 30131 connected with 192.168.178.54 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0- 2.0 sec   768 KBytes  3.15 Mbits/sec
[  3]  2.0- 4.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  4.0- 6.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  6.0- 8.0 sec   512 KBytes  2.10 Mbits/sec
[  3]  8.0-10.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  0.0-10.3 sec  3.25 MBytes  2.64 Mbits/sec

I assume the low  bandwidth is due to the two  thick walls separating my
laptops and the  access point. Everything else seems to  be fine though.
I'll  retry the  speed  measurement in  a  few days  when  I'm home  for
christmas.

> Note that if you'd like to test monitor mode you'll need to apply this
> to a -current source tree from today.
> [...]

Haven't  tested monitor  mode so  far, except  for the  IFF_PROMISC that
comes with the device being a trunkport. Works fine as far as I can see.

-- 
Gregor
--

BLISS is ignorance.

Re: initial 11n support for iwn (n, not m)

2015-12-16 Thread Christian Weisgerber

On 2015-12-16, David Hill  wrote:

> Thanks for the 11n work!
> Unfortunately, your diff breaks iwn on my machine.
>
> iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x35:
> msi, MIMO 3T3R, MoW, 

That is odd, because it works for me:

iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e:
msi, MIMO 3T3R, MoW,

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

Re: initial 11n support for iwn (n, not m)

21 matches

Site Navigation

Mail list logo

Footer information