tcpdump: decode 802.11 QoS frames correctly

This matters for frames which arrived in A-MPDUs. Before: 12:35:07.726898 802.11: QoS data: 00:1e:52:f1:80:55 sap 00 > 58:94:6b:06:70:04 sap 06 I (s=85,r=85,C) len=82 After: 12:49:08.879003 802.11: QoS data: 10.197.84.33 > 10.0.1.3: icmp: echo reply Index: print-802_11.c

Re: tcpdump: show 802.11 control frames

On Wed, Feb 03, 2016 at 01:36:50PM +0100, Mark Kettenis wrote: > > Date: Wed, 3 Feb 2016 13:27:50 +0100 > > From: Stefan Sperling <s...@stsp.name> > > > > Currently, tcpdump displays 802.11 control frames as "type#4" and > > doesn't give more i

tcpdump: fix infinite loop

Fix an infinite loop when printing a country element in a management frame in case we hit channel Tx power limits we can't pretty-print. Also ensure we consume the last item in this list. Index: print-802_11.c === RCS file:

fix A-MPDU params for iwn/iwm (fixes apple airport AP)

Both drivers forgot to configure some A-MPDU parameters into the firmware and announced the wrong A-MPDU max size in assoc responses. Also announce that we don't support SMPS (signalled in htcaps by a value of 3 rather than zero...) ok? Index: if_iwm.c

11n: don't require a BlockAck timeout

We currently force BlockAck agreements to time out after a certain period of inactivity. Some APs, notably Broadcom-based ones (like Apple Airport) don't cope with this nicely and drop packets while the BA session is reestablished. The result is unusable wifi in 11n mode with such APs (> 50%

11n: fix BA timeout value in ADDBA requests/responses

The ADDBA frames use a timeout value in units of TU (802.11 time unit). ba->ba_timeout_val is in usec and has already been multiplied by TU (e.h. in ieee80211_recv_addba_req()). We need to divide by TU when copying out to the frame. ok? Index: ieee80211_output.c

Re: keep track of HT protection in 11n mode

On Wed, Jan 20, 2016 at 10:16:53PM +0100, Stefan Sperling wrote: > On Wed, Jan 20, 2016 at 10:04:11PM +0100, Stefan Sperling wrote: > > This diff makes us keep track of changes in the network's HT protection > > settings. These settings are advertised in beacons and change dynami

htprot sanity check

Don't try to interpret htprot data if the last beacon didn't contain any such data. In other words, ensure we copied data from the beacon to ni->ni_htop1 before using ni->ni_htop1. Note that read and write of ni->ni_htop1 are not visible in this diff's context, but happen close-by in surrounding

honour ERP protection in 11n mode

ERP (Extended Rate PHY) protection must be honoured in 11n mode on 2 GHz channels. >From an 11b client's point of view, 11n behaves like 11g in terms of frame protection, and we must enable ERP protection in 11n mode if requested by the AP. The drivers already enable ERP protection if

Re: keep track of HT protection in 11n mode

On Wed, Jan 20, 2016 at 10:04:11PM +0100, Stefan Sperling wrote: > This diff makes us keep track of changes in the network's HT protection > settings. These settings are advertised in beacons and change dynamically > based on the nature of clients associated to an AP at a giv

keep track of HT protection in 11n mode

This diff makes us keep track of changes in the network's HT protection settings. These settings are advertised in beacons and change dynamically based on the nature of clients associated to an AP at a given moment. Tracking these changes is rather important. If a non-11n client associates to an

Re: keep track of HT protection in 11n mode

On Thu, Jan 21, 2016 at 01:57:28AM +0100, Stefan Sperling wrote: > On Wed, Jan 20, 2016 at 10:16:53PM +0100, Stefan Sperling wrote: > > On Wed, Jan 20, 2016 at 10:04:11PM +0100, Stefan Sperling wrote: > > > This diff makes us keep track of changes in the network's HT protect

rtwn: check for error during attach

rtwn_attach() may fail due to "unsupported test chip". Unlikely to occur in practice, but still... Index: ic/rtwn.c === RCS file: /cvs/src/sys/dev/ic/rtwn.c,v retrieving revision 1.1 diff -u -p -r1.1 rtwn.c --- ic/rtwn.c 9 Mar 2016

remove useless "abstractions" from urtwn(4)

These function pointers don't provide any benefit. They will just get in the way when we merge this driver with rtwn(4). Tested with: MAC/BB RTL8188CUS, RF 6052 1T1R MAC/BB RTL8188EU, RF 6052 1T1R (URTWN_CHIP_88E) MAC/BB RTL8192CU, RF 6052 2T2R Index: if_urtwn.c

rtwn dma init

The urtwn(4) driver does different things to init dma. So it seems better to move all DMA init code into the bus-specific part of the driver, not just a small part of it. Tested on: MAC/BB RTL8188CE, RF 6052 1T1R Index: ic/rtwn.c

rtwn(4) timeouts

The urtwn(4) driver uses usbd_is_dying() calls in its timeouts. usbd_is_dying() can't be part of the common rtwn(4) driver code once we merge code from urtwn(4). So timeouts must move back to the bus-specific part of the driver. The common driver code now indicates when timeouts must be

Re: net80211: with more if_start()/if_enqueue()!

On Tue, Apr 12, 2016 at 08:34:08AM +0200, Martin Pieuchot wrote: > As reported by jsg@ the wifi stack should use if_start() just like the > rest of the kernel. One of the patterns can even be converted to > if_enqueue(). Note that if_enqueue() checks for a bridge port and, if present, sends

Re: net80211: with more if_start()/if_enqueue()!

On Tue, Apr 12, 2016 at 01:10:33PM +0200, Martin Pieuchot wrote: > What's the use case of bridging wireless interfaces. Does that work? You can have an AP which bridges wifi clients into a LAN: wifi-client ))) athn0(AP)-bridge0-em0 -> LAN Now wifi-client and the LAN can talk on layer 2. I use

Re: Print ifindex in ifconfig(8)

On Tue, Apr 12, 2016 at 12:27:10PM +0100, Stuart Henderson wrote: > On 2016/04/12 13:00, Martin Pieuchot wrote: > > Relying on the "scopeid" field is not a viable long-term solution. I'm > > spending too much time these days trying to figure out which interface > > correspond to which index. > >

vnet(4) memory leak

A sparc64 machine of mine crashes every few weeks because the kernel runs out of memory. The crash usually happens in a malloc call in the vnet(4) ioctl code path. I have a cronjob which downs/up vnet interfaces in case they get stuck in OACTIVE (another bug which, AFAIK, is not solved yet). So

rtwn chip id

The common part of rtwn(4) needs help from attachment drivers to determine the chip type. The PCI/USB driver parts must detect the chip type based on PCI/USB vendor and device IDs. There seems to be no other way of doing this. Even the Linux vendor driver does it this way. The common part is

stop urndis(4) dmesg spam

While tethering to my phone on a train, I'm seeing a lot of these lines in dmesg: urndis0: usb errors on rx: IOERROR urndis0: usb error on tx: IOERROR So many in fact that if I run 'dmesg' that's all I see, over and over. However, network mostly works, and works particularly well given the right

Re: axen improvements

On Sat, Mar 19, 2016 at 05:09:34PM -0400, Brandon Mercer wrote: > I've recently acquired a usb3.0->gigabit ethernet adapter. It did not > attach reliably, pass traffic reliably, and it made my machine panic > when I unplugged it. Takahiro HAYASHI suggested that the reset > code doesn't do anything

remove LOCALECHARSETS from libc

Unused. Index: locale/Makefile.inc === RCS file: /cvs/src/lib/libc/locale/Makefile.inc,v retrieving revision 1.20 diff -u -p -r1.20 Makefile.inc --- locale/Makefile.inc 3 Jul 2015 11:15:19 - 1.20 +++ locale/Makefile.inc 20

Re: A patch for allowing IPv6-only or IPv4-only bridges

On Sun, Mar 20, 2016 at 10:43:43AM +, Stuart Henderson wrote: > While I do see use for this, can people also apply pressure to said > ISP to fix their setup as well please? This is basic routing and really > shouldn't need bridge hacks. People will need better than a single > /64 in order to

remove LOCALECHARSETS from locale(1) Makefile

LOCALE_CHARSETS is unused in locale.c. Index: Makefile === RCS file: /cvs/src/usr.bin/locale/Makefile,v retrieving revision 1.1 diff -u -p -r1.1 Makefile --- Makefile3 Jun 2013 14:27:50 - 1.1 +++ Makefile20 Mar 2016

Re: Remove build machinery for non-UTF-8 charsets

On Fri, Mar 18, 2016 at 01:49:05AM +0100, Jeremie Courreges-Anglas wrote: > > What's the plan regarding this? libc and locale(1) don't use > LOCALE_CHARSETS anymore, we only support UTF-8 and I doubt that we'll > change our mind about that. > > The diff below removes support for non-UTF-8

Re: Scheduler hack for multi-threaded processes

On Sat, Mar 26, 2016 at 05:47:38PM -0600, attila wrote: > Now it will be a challenge to see if I can cvs up, back out the patch > and build a kernel without ringing the bell (100DegC). I freely admit > this is an old, P.O.S. laptop and that there might be some HW issue Did you check for dust in

Re: typo in fseek.3: "prefer seek()" -> "prefer fseek()"

On Sat, Mar 26, 2016 at 11:09:54PM +0100, Theo Buehler wrote: > ok? Yes, makes sense. > Index: lib/libc/stdio/fseek.3 > === > RCS file: /var/cvs/src/lib/libc/stdio/fseek.3,v > retrieving revision 1.17 > diff -u -p -r1.17 fseek.3 >

inline driver-specific definitions in rtwn(4) and urtwn(4)

Jan 1970 00:00:00 - @@ -1,205 +0,0 @@ -/* $OpenBSD: if_rtwnreg.h,v 1.5 2016/03/07 18:05:41 stsp Exp $ */ - -/*- - * Copyright (c) 2010 Damien Bergamini <damien.bergam...@free.fr> - * Copyright (c) 2015 Stefan Sperling <s...@openbsd.org> - * - * Permission to use, copy, modify, and distribut

merge rtwn(4) and urtwn(4) tx/rx descriptors

Merge definitions for TX and RX descriptors to the common header file. The structs have different sizes but all the bit masks can be shared. Again, tested with: MAC/BB RTL8188CUS, RF 6052 1T1R MAC/BB RTL8188EU, RF 6052 1T1R MAC/BB RTL8192CU, RF 6052 2T2R MAC/BB RTL8188CE, RF 6052 1T1R Index:

Re: Speedup sdhc(4)

On Thu, Apr 28, 2016 at 08:30:13PM +0200, Mark Kettenis wrote: > So here are just the bits that add DMA support. Since Theo likes this > so much, I'd like to move forward with this. > > ok? Go for it. Havent' tested it myself but looks good and is a very much needed enhancement. I found one

fix iwn htprot updates

I'm investigating latency issues with 11n block ack on iwn. There's a dedicated command to update RXON flags while associated. Use this command instead of whacking the whole firmware node table and restoring it. The firmware node table contains block ack state and we shouldn't mess with that.

reduce 11n block ack gap timeout

Reduces ping jitter when the block ack window encounters gaps. Index: ieee80211_node.h === RCS file: /cvs/src/sys/net80211/ieee80211_node.h,v retrieving revision 1.59 diff -u -p -r1.59 ieee80211_node.h --- ieee80211_node.h11 Feb

netstat -W counters for 11n

I'd like to add some 802.11n-related counters to netstat -W output. The first diff below is for the kernel, the second for netstat. ok? Index: ieee80211_input.c === RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v retrieving

Re: AMRR improvements for rt2860

On Sun, Apr 24, 2016 at 08:47:46AM +0200, Stefan Sperling wrote: > On Sun, Apr 24, 2016 at 01:25:31PM +0800, Nathanael Rensen wrote: > > The diff below also introduces dedicated timers for AMRR and for scan > > instead of using the RT2860 GP interrupt, which also impro

show HT MCS for 11n APs in ifconfig scan

Copy out some 11n information to net80211 ioctl node records. Use a subset of this info to display the highest AP Rx rate during scan. Since 11n implies support for 11a/b/g rates up to 54Mbit/s, we only show a legacy rate if the AP doesn't support 11n. In theory, 11n rate suport is not

Re: AMRR improvements for rt2860

On Sun, Apr 24, 2016 at 01:25:31PM +0800, Nathanael Rensen wrote: > I have been using an rt2860 hostap for a few years and I have discovered > that AMRR does not work properly for this driver. The symptom is that > some stations get stuck at 1 Mbps and do not progress up to faster rates. > >

net80211: support devices which scan all bands

The new iwm(4) firmware (see [1]) scans 2GHz and 5 GHz bands in one go. [1] http://marc.info/?l=openbsd-tech=146356530605833=2 Our net80211 stack isn't set up to handle this correctly. With the new firmware (and diff from [1]), you'll see no scan results at all if you run: ifconfig iwm0 nwid

Re: Update iwm(4) to newer firmware

On Wed, May 18, 2016 at 11:53:33AM +0200, Stefan Sperling wrote: > Update iwm(4) to firmware version 16.242414.0 (API 16). > New firmware has been available in fw_update(1) for several weeks already. This is an updated diff which includes changes submitted by Imre Vadasz to fix occa

Re: net80211: support devices which scan all bands

On Fri, May 20, 2016 at 12:08:19PM +0200, Mark Kettenis wrote: > > Date: Fri, 20 May 2016 11:19:26 +0200 > > From: Stefan Sperling <s...@stsp.name> > > > > The new iwm(4) firmware (see [1]) scans 2GHz and 5 GHz bands in one go. > > [1] http://marc.in

iwm: rx dma init fix

According to a comment in iwlwifi: * Clearing FH_MEM_RCSR_CHNL0_CONFIG_REG to 0 turns off Rx DMA. * Driver should poll FH_MEM_RSSR_RX_STATUS_REG for * FH_RSSR_CHNL0_RX_STATUS_CHNL_IDLE (bit 24) before continuing. We missed polling this bit in the init code path. Probably harmless, but can be

iwm nitpicks

This diff addresses some of my nitpicks in iwm: Move some declarations to if_iwmreg.h so we can use iwm_phy_db_* prototypes. Remove redundant declaration of iwm_send_phy_db_data(). Remove pointless iwm_fw_alive(); just call iwm_post_alive() directly. Simplify iwm_prepare_card_hw() and

Re: multiple routing tables

On Sat, May 14, 2016 at 10:53:49PM +0200, Piotr Kubaj wrote: > H‌‌i, > > I need help with multiple routing tables, because the tutorials on the > Internet is pretty much scarce. The router is Ubiquiti EdgeRouter Lite > running OpenBSD 5.9. > > > I've got two public IP's attached by DHCP - since

Update iwm(4) to newer firmware

18 May 2016 09:42:53 - @@ -1,7 +1,8 @@ /* $OpenBSD: if_iwm.c,v 1.81 2016/05/18 07:28:01 stsp Exp $*/ /* - * Copyright (c) 2014 genua mbh <i...@genua.de> + * Copyright (c) 2014, 2016 genua gmbh <i...@genua.de> + * Author: Stefan Sperling <s...@openbsd.org>

Re: AMRR improvements for rt2860

On Wed, May 18, 2016 at 06:24:15AM +0800, Nathanael Rensen wrote: > On 27 April 2016 at 17:33, Stefan Sperling <s...@stsp.name> wrote: > > > This version includes minor tweak: When the AP goes down, we don't > > need to send disassoc frames to nodes in COLLECT state. >

Re: fix iwn htprot updates

On Wed, Apr 27, 2016 at 05:53:39PM +0200, Stefan Sperling wrote: > I'm investigating latency issues with 11n block ack on iwn. > > There's a dedicated command to update RXON flags while associated. > Use this command instead of whacking the whole firmware node table >

Intel Wireless 8260 support for iwm(4)

With the iwm(4) firmware update done, we can add support for 8260 devices. These devices are currently showing up in new laptops. The main differences over the 7000 series are the firmware file format, firmware loading process, non-volatile memory on the chip, and, unfortunately, yet another scan

Re: realtek 8179 wireless pci

On Sun, Aug 14, 2016 at 12:40:33AM +, Prabhu Gurumurthy wrote: > I think I might be missing firmware, which might need to be loaded, but > linux-firmare.git has so many firmware, I am lost trying to find the > correct one in that repo and I am lost in firmware.openbsd.org as well. Our rtwn(4)

rtwn: heed rts threshold

The rtwn(4) driver ignores the rts threshold value set by the stack. This fixes it: Index: if_rtwn.c === RCS file: /cvs/src/sys/dev/pci/if_rtwn.c,v retrieving revision 1.22 diff -u -p -r1.22 if_rtwn.c --- if_rtwn.c 17 Jun 2016

urtwn: heed rtsthreshold

Same rts threshold fix as for rtwn(4). Index: if_urtwn.c === RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v retrieving revision 1.65 diff -u -p -r1.65 if_urtwn.c --- if_urtwn.c 17 Jun 2016 10:53:55 - 1.65 +++ if_urtwn.c 20

iwm: disable beacon filter for ERP and HT prot updates

Beacon filter settings in iwm(4) prevent the device from passing beacons to net80211 while associated to an AP. The implication is that net80211 does not see HT protection updates, so it never tells the driver to update HT protection settings. This can cause interference problems. I believe this

iwm: make use of RTS/CTS conditional

Currently, if running in 11n mode, iwm always enables RTS/CTS to protect frames it is sending. To recap what the various HT protection modes are: /* * HT protection modes (see 802.11-2012 8.4.2.59) */ enum ieee80211_htprot { IEEE80211_HTPROT_NONE = 0, /* only 20/40MHz HT STAs

iwn: slow down LED in monitor mode

When I run iwn in monitor mode it flashes its LED like it was trying to give me epileptic seizures. With this diff, it's much less irritating. ok? Index: if_iwn.c === RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v retrieving revision

Re: ral(4) support RT5390 and RT5392

On Mon, Aug 08, 2016 at 11:45:10PM -0400, James Hastings wrote: > Hi all, > > The following patch adds RT5390/RT5392 support to ral(4). > > Ported from FreeBSD r278551 and r36. > > Running smoothly with RT3090 and various RT5390 cards. Thank you for working on this, James. I'll review your

Re: dhclient/bpf.c

On Sat, Jul 23, 2016 at 12:15:59AM +0200, Holger Mikolon wrote: > I played with different bpf filters and came up with the below patch. It > compares the interface's LLADDR with the the respective address in the > bootp structure instead of the ether header. I don't know if this is the > right way

Re: iwm: lower retry limit for management frames

On Wed, Jun 22, 2016 at 03:18:33PM +0200, Stefan Sperling wrote: > The Linux iwlwifi driver uses less retry attempts for management frames, > as in the diff below. I think it makes sense to do likewise. Anybody? This is a pretty low risk change, so I'm just going to go ahead, I guess. >

iwm: fix inverted logic

This code in iwm is supposed to match what Linux does. The Linux code looks like this: if (ieee80211_is_data(fc) && len > mvm->rts_threshold && !is_multicast_ether_addr(ieee80211_get_DA(hdr))) tx_flags |= TX_CMD_FLG_PROT_REQUIRE; Our driver had the 'is data'

iwm: set tx aggregation limit to 1

I'm not sure if this change has any real effect, but as long as we don't support 11n TX aggregation it's probably better to set the firmware's aggregation limit to 1 frame (which means 'no aggregation'). Index: if_iwm.c === RCS file:

show current tx rate for associated nodes

For hostap interfaces, ifconfig scan currently shows the maximum supported Rx Rate or RX MCS of associated stations. E.g. for an iwn(4) device associated to an athn(4) AP in 11g mode, the AP will show 'HT-MCS7' in ifconfig scan: # ifconfig athn0 scan | grep 34:13:e8:d0:60:a9 lladdr

iwm tx rate fixes

iwm(4) should always send multicast frames at the lowest rate. We probably got lucky and frames were still sent at a compatible rate via the LQ retry table. But it is better to have an "IS_MULTICAST" check like other drivers do. On 5GHz, iwm(4) passes the wrong rate to BPF. This is a cosmetic

5GHz vs 2GHz APs

The wireless stack usually runs its scanning loop once per frequency band. It begins with 5GHz so that APs on this band are preferred. Within a band, an AP with the best RSSI (receive signal strength indicator) is chosen, after matching all other desired parameters such as the ESSID etc. I am not

Re: ral(4) support RT5390 and RT5392

On Mon, Aug 08, 2016 at 11:45:10PM -0400, James Hastings wrote: > Hi all, > > The following patch adds RT5390/RT5392 support to ral(4). Your patch can't be applied with patch(1) because directory components are missing on the Index: lines even though modified files are spread across several

Re: ral(4) support RT5390 and RT5392

On Tue, Aug 16, 2016 at 05:34:20PM -0400, James Hastings wrote: > On 8/16/16, Stefan Sperling <s...@stsp.name> wrote: > > > > Your patch can't be applied with patch(1) because directory > > components are missing on the Index: lines even though modified > >

Re: iwm: make use of RTS/CTS conditional

Did anyone test this? On Wed, Jul 20, 2016 at 02:48:02PM +0200, Stefan Sperling wrote: > Currently, if running in 11n mode, iwm always enables RTS/CTS to protect > frames it is sending. > > To recap what the various HT protection modes are: > > /* > * HT protection m

Re: iwm driver in latest snapshot has terrible performance

On Sun, Jul 31, 2016 at 05:26:21PM +0200, Noth wrote: > Now testing with a July 17th kernel, everything works fine at .11n speeds > but the ping goes from 1ms to 100+ms for one packet on average every 50-60 > packets. Can you pin-point the iwm commit which changed this?

net80211: fix bogus rateset in assoc requests in 11b mode

I noticed that an 11a/b ath(4) card, which does not support 11g, includes 11g rates ("xrates") in association requests it sends on 2GHz: 20:55:03.490128 802.11 flags=0<>: association request, \ caps=2041, ssid (stsp.name), \ rates 1M* 2M* 5M 6M 9M 11M 12M 18M,

Re: net80211: fix bogus rateset in assoc requests in 11b mode

On Fri, Feb 03, 2017 at 09:49:21AM +0100, Martin Pieuchot wrote: > On 02/02/17(Thu) 22:14, Stefan Sperling wrote: > > Note that rates get fixed up again after association is confirmed, > > via ieee80211_recv_assoc_resp() -> ieee80211_setup_rates(). > > Which is why 11b clie

11n hostap: send correct edca params to clients

In hostap mode, when copying EDCA parameters into frames we send to clients, we copy EDCA parameters from the "QOS AP" table (ieee80211_qap_edca_table). But values in these frames tell clients what parameters to use themselves. So copy parameters from the "QOS client" table (ieee80211_edca_table)

rtwn: fix hardware admission control config

In my latest commit I enabled "hardware AC queue management" in rtwn. Upon closer investigation, this register works differently. It needs to reflect "ACM" (admission control mandatory) flags which the AP sends to clients in EDCA parameters. There is one such flag per traffic class, and the

Re: iwm(4): Update struct iwm_scan_results_notif. Remove a few old defines.

On Mon, Jan 30, 2017 at 12:07:46PM +0100, Imre Vadász wrote: > Thanks, this patch was trying to remove the struct iwm_scan_complete_notif > definition that was already removed in one of the previous diffs. > fixed patch: Committed. Thank you!

Re: counters api: always use M_COUNTERS

On Tue, Jan 31, 2017 at 01:18:05PM +0100, Jeremie Courreges-Anglas wrote: > > As proposed by mpi@ in > > http://marc.info/?l=openbsd-tech=148585429014645=2 > > I think that choosing a "proper" type doesn't bring much information, > and having one parameter less makes things simpler. mbuf

rtwn: amrr support

:38 - 1.25 +++ pci/if_rtwn.c 31 Jan 2017 15:44:33 - @@ -3,6 +3,7 @@ /*- * Copyright (c) 2010 Damien Bergamini <damien.bergam...@free.fr> * Copyright (c) 2015 Stefan Sperling <s...@openbsd.org> + * Copyright (c) 2015-2016 Andriy Voskoboinyk <a...@free

athn: rate scaling tweak

The athn driver disables multi-rate retries if RTS is used. This is done because of a hardware limitation (see comment in ar5008_tx()). So all attemps to send the frame will use the same data rate. If RTS is not used, the driver will configure the hardware to switch to a lower rate after 2 failed

Re: Xorg vs wifi scanning

On Mon, Feb 06, 2017 at 12:44:52PM +0100, Martin Pieuchot wrote: > On 06/02/17(Mon) 12:39, Theo Buehler wrote: > > This fixes the issue on my iwn0, but re-introduces the problem on my iwm0. > > That means another ioctl(2) triggers the problem with iwm(4). It would > help if you could figure out

11n hostap: enable short slot time

This diff enables short slot time, accidentally left disabled in 11n mode. Short vs. long slot time controls the (very small) amount of time devices spend waiting between frame transmissions. The only wifi devices which do not support short slot time are 11b ones. Index: ieee80211_proto.c

Re: Xorg vs wifi scanning

On Mon, Feb 06, 2017 at 03:54:56PM +0100, Martin Pieuchot wrote: > tb@ found that another code path needs to be unlocked. Diff below does > that. These ioctl(2)s are only messing at the driver level, so it is > safe to drop the NET_LOCK() there as well. > > ok? I am happy with this. OK. And

rtwn: fix iq calibration

FreeBSD committed a couple of interesting things in r307529 https://svnweb.freebsd.org/base?view=revision=r307529 Unfortunately the commit is a giant patch bomb which makes it hard to pick out individual fixes :-( This patch extracts what I believe "fix IQ calibration bug" refers to. The current

Re: iwm: fix a timeout race

On Sat, Jan 21, 2017 at 08:07:53PM +1300, Richard Procter wrote: > Hi, > > On 18/01/2017, Stefan Sperling <s...@stsp.name> wrote: > > I managed to trigger the following uvm fault by continously switching an > > iwm(4) client between two APs on different chan

Re: rtwn: fix iq calibration

On Sun, Jan 22, 2017 at 11:07:00PM +0100, Jeremie Courreges-Anglas wrote: > Stefan Sperling <s...@stsp.name> writes: > > > FreeBSD committed a couple of interesting things in r307529 > > https://svnweb.freebsd.org/base?view=revision=r307529 > > Unfortunately the comm

Re: In amsdu_decap(), check for n->m_pkthdr.len == 0, not n->m_len == 0

On Tue, Jan 24, 2017 at 03:34:59PM +0100, Imre Vadász wrote: > Since m_split() in some cases returns an mbuf chain, where the pkthdr element > contains no data (i.e. m_len == 0), the n->m_len == 0 check in > sys/net80211/ieee80211_input.c in the amsdu_decap() function sometimes > signals the end

Re: ldomctl(8) usage

On Thu, Jan 26, 2017 at 01:37:14PM +, Andrew Grillet wrote: > I am not sure what bikeshedding means in this case (it was all different > when I was at school ;-) http://producingoss.com/en/common-pitfalls.html#bikeshed > However, as an ldomctl user, I would be happier if the usage was

ldomctl(8) usage

I am not sure about the best way to fix this, but ldomctl's usage() is rather bogus. It only mentions some of the supported commands. The diff below adds the missing ones. However, I am tempted to just change all of it to something like this: fprintf(stderr, "usage: ldomctl command

athn rts fix for 11a/b/g clients

An 11n athn hostap will currently apply HT protection (RTS) even when sending frames to a non-11n client which does not need such protection. This is causing unnecessary overhead. It happens because the wrong flag is checked by the driver: IEEE80211_F_HTON tells us if 11n is supported by the

Re: rtwn: correct free size

On Mon, Jan 30, 2017 at 03:28:21PM +0100, Jeremie Courreges-Anglas wrote: > > If fw_loadpage fails, the size passed to free(9) is bogus. Always pass > the size returned by load_firmware instead. I hit this a few days ago, > ok? ok stsp@ > Index: rtwn.c >

rtwn: configure short slot time and short preamble

The rtwn driver never tells hardware about the short slot time and short preamble features enabled by most APs (since 11g). Not sure if not doing so hurts but the linux driver does it. Tested on: 8188CE (PCI) 8192CU (USB) 8188EU (USB) 8188CUS (USB) ok? Index: rtwn.c

net80211: expose edca table

EDCA ("Enhanced distributed channel access") was first introduced in 802.11e and is also part of 802.11n. Essentially, these parameters define how frame transmissions are timed. They are not necessary to operate in pure 11a/b/g networks, but 11n clients will typically pass these parameters to

rtwn: clean up edca code

This cleans up the code which handles EDCA parameters in rtwn/urtwn. The driver now gets its EDCA params from net80211 instead of hardcoding them. There's a bit of a layer violation since the driver writes to ic->ic_edca_ac because net80211 does not fill it in yet. I think net80211 should do

Re: mira sfer overflow panic (was: Re: 11n support for athn(4))

On Thu, Jan 26, 2017 at 10:38:44AM +0100, Stefan Sperling wrote: > On Thu, Jan 26, 2017 at 06:36:06AM +, Peter Kay wrote: > > sfer overflow > > Interesting. This is the first time I've ever seen this panic trigger. > > Can you apply this patch and try to trigger it a

Re: iwn: Centrino Ultimate-N 6300 scans, doesn't dhcp?

On Wed, Jan 25, 2017 at 08:43:11PM -0600, Austin Bentley wrote: > Interesting. It seems that on OpenBSD the reception is quite weak. > I've connected, HOWEVER, I have to be in the same room as my router! > On Linux I can be anywhere in my house. > > I tried disabling powersave (-powersave), and

mira sfer overflow panic (was: Re: 11n support for athn(4))

On Thu, Jan 26, 2017 at 06:36:06AM +, Peter Kay wrote: > sfer overflow Interesting. This is the first time I've ever seen this panic trigger. Can you apply this patch and try to trigger it again? Index: ieee80211_mira.c === RCS

Re: 11n support for athn(4)

On Sun, Jan 29, 2017 at 07:49:56AM +0200, Timo Myyrä wrote: > Hmm, I've been running the 11n for a while and it seems to be a lot slower > than > 11g for me. Just did quick benchmark using tcpbench between OpenBSD hostAP > (athn) and > laptop (iwn). It looks when my athn is in 11n mode I get

Re: iwm(4): Update struct iwm_scan_results_notif. Remove a few old defines.

On Mon, Jan 16, 2017 at 05:26:05PM +0100, Imre Vadász wrote: > Hi, > This patch updates the struct iwm_scan_results_notif to FW Api version 3, > and removes the unused enum iwm_scan_complete_status status codes, as well > as the deprecated/unused struct iwm_scan_complete_notif. > > This

Re: 11n support for athn(4)

On Wed, Jan 18, 2017 at 09:19:28AM +0100, Uwe Werler wrote: > On 16. Jan 17:46:48, Uwe Werler wrote: > > > > Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get > > ~16 MBit. > > > > > > zarathustra:~# tcpbench apu01 > > elapsed_ms bytes mbps bwidth

missing malloc() return check in athn(4)

I added this bug recently... Index: athn.c === RCS file: /cvs/src/sys/dev/ic/athn.c,v retrieving revision 1.95 diff -u -p -r1.95 athn.c --- athn.c 12 Jan 2017 18:06:57 - 1.95 +++ athn.c 17 Jan 2017 19:33:31 -

net80211: enable tkip with 'ifconfig wpaprotos wpa1,wpa2'

The recommended way to enable WPA1/TKIP support is: ifconfig iwm0 wpaprotos wpa1,wpa2 pirofti@ noticed that 'ifconfig iwm0 wpaprotos wpa1,wpa2' is not enough to connect to a WPA1-only AP. A list of pairwise ciphers must also be provided: "ifconfig iwm0 wpaciphers tkip,ccmp" Because I forgot to

iwm: fix a timeout race

I managed to trigger the following uvm fault by continously switching an iwm(4) client between two APs on different channels, i.e. a loop that runs: ifconfig iwm0 chan X; sleep 10; ifconfig iwm chan Y; sleep 10; uvm_fault(0x819614a0, 0x7, 0, 2) -> e kernel: page fault trap, code=0

Re: 11n support for athn(4)

On Tue, Jan 17, 2017 at 10:19:39AM +, Peter Kay wrote: > From: s...@stsp.name > Sent: 17 January 2017 10:00 a.m. > To: syllops...@syllopsium.co.uk > Cc: tech@openbsd.org > Subject: Re: 11n support for athn(4) > > On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote: > >> > >> Three,

Re: 11n support for athn(4)

On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote: > Without more details, all I can do is guess. > I made one guess already (antennas) and sadly I guessed wrong. Another thing where your setup differs from mine is that you are using a device with 3 antennas, whereas my device

Re: 11n support for athn(4)

On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote: > On 16 January 2017 at 23:30, Stefan Sperling <s...@stsp.name> wrote: > > Do you have 2 antennas properly connected to the athn card? > > Three, yes, but note that unless the antennas have been unreasonab

<    1   2   3   4   5   6   7   8   9   10   >