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'

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

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: lower retry limit for management frames

The Linux iwlwifi driver uses less retry attempts for management frames, as in the diff below. I think it makes sense to do likewise. Index: if_iwm.c === RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v retrieving revision 1.92 diff -u -p

Re: pf.conf macro with space

On Tue, Jun 21, 2016 at 08:57:44AM -0400, sven falempin wrote: > I have explain the use of spaced macro, > a config file that is self explanatory. I suggest you use underscores instead of spaces in macro names.

Re: pf.conf macro with space

On Tue, Jun 21, 2016 at 01:11:16PM +0200, Henning Brauer wrote: > however, the ruleset in this case does NOT load. > $ echo '"a macro with spaces"="foo"\npass from $a\ macro\ > with\ spaces"' | pfctl -nvf - > a macro with spaces = "foo" > stdin:2: macro 'a' not defined > stdin:2:

Re: pf.conf macro with space

On Tue, Jun 21, 2016 at 10:37:45AM +0200, Henning Brauer wrote: > * Sebastian Benoit [2016-06-21 10:15]: > > same thing without a stupid helper function, pointed out by henning. > > I'm actually not quite sure we need or want this. From my PoV, making > the tools too much of a

Re: pf.conf macro with space

On Tue, Jun 21, 2016 at 10:14:52AM +0200, Sebastian Benoit wrote: > > same thing without a stupid helper function, pointed out by henning. > > diff --git sbin/pfctl/parse.y sbin/pfctl/parse.y > index 934438c..426cd93 100644 > --- sbin/pfctl/parse.y > +++ sbin/pfctl/parse.y > @@ -714,6 +714,10 @@

Re: bgpd logging nexthop valid

On Sun, Jun 19, 2016 at 05:39:53PM +0200, Sebastian Benoit wrote: > i would like to make bgpd a bit more quiet. > > This type of message > > bgpd[59424]: nexthop 1.2.3.4 now valid: via 192.168.0.1 > > happens quite often depending on your upstreams. This makes it a debug > message only. > >

Re: fix iwm association problems

On Mon, Jun 20, 2016 at 12:34:17PM +0200, Stefan Sperling wrote: > I found that my 8260 iwm(4) device has trouble associating to my 5 GHz AP, > which runs OpenBSD with athn(4) in hostap mode. Most of the time it won't > even get a DHCP lease. Some frames it believes it has sent are

fix iwm association problems

I found that my 8260 iwm(4) device has trouble associating to my 5 GHz AP, which runs OpenBSD with athn(4) in hostap mode. Most of the time it won't even get a DHCP lease. Some frames it believes it has sent are not even visible on the air. The iwm driver still has a copy of code from Linux that

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

umb(4) man page tweaks

Some information in the umb(4) man page seems to be outdated (IPV4 gateway handling), or doesn't really belong in a man page ("please hack the driver to add a device to a blacklist"). Also try to shorten the page a bit and move information about troublesome devices to CAVEATS. Index: umb.4

make umb(4) less verbose by default

This diff hides some verbose messages which umb(4) prints by default and shows most of them only with 'ifconfig umb0 debug'. Some of these messages appear during normal operation, even if the umb device isn't used at all, such as: umb0 at uhub0 port 6 configuration 2 interface 12 "Sierra

Re: iwm(4): Add missing iwm_free_rx_ring(). Free nvm_sections[i].data buffers.

On Fri, Jun 10, 2016 at 01:58:50PM +0200, Imre Vadasz wrote: > Hi, > > After parsing the nvm_sections data in iwm_nvm_init(), we can free the > nvm_sections[i].data allocations again. > > In the iwm_attach() failure path, the iwm_free_rx_ring() call for freeing > the rx ring memory was missing.

merge urtwn(4) into rtwn(4)

This (unfortunately rather large) diff merges urtwn(4) into rtwn(4). Removes bloat caused by having 2 separate drivers: ic/rtwn.c | 448 ++ ic/rtwnvar.h | 38 pci/if_rtwn.c | 126 ++- usb/if_urtwn.c | 2378 + 4 files

afterboot(8) ethernet device name

I find le0 and lo0 too close to be easily distinguishable, especially with a small font. This way, the difference should be more obvious. Index: afterboot.8 === RCS file: /cvs/src/share/man/man8/afterboot.8,v retrieving revision

Re: removing wsmouse_input [2]: zts, hilms, uts

On Mon, Jun 06, 2016 at 12:40:24PM +0100, Edd Barrett wrote: > I have a uts. > > I can test later. Am I expecting to see any functional change? No change is expected. It should just work.

fix copy-pasto in netstat

Index: net80211.c === RCS file: /cvs/src/usr.bin/netstat/net80211.c,v retrieving revision 1.15 diff -u -p -r1.15 net80211.c --- net80211.c 28 Apr 2016 14:46:50 - 1.15 +++ net80211.c 29 Apr 2016 16:57:45 - @@ -117,7

Re: removing wsmouse_input [2]: zts, hilms, uts

On Sun, Jun 05, 2016 at 09:55:07AM +0200, Ulf Brosziewski wrote: > ok? Again, I can't test this, but it's ok by me. I like the new wsmouse interface a lot better than the old one. > On 06/01/2016 01:23 AM, Ulf Brosziewski wrote: > > zts, hilms, and uts are the drivers that still use

Re: removing wsmouse_input [1]

On Sun, Jun 05, 2016 at 09:54:55AM +0200, Ulf Brosziewski wrote: > ok? > Looks good, ok by me. I don't think I have any of these devices, though, so I can't test. > On 06/01/2016 01:21 AM, Ulf Brosziewski wrote: > > These diffs adapt various drivers to the new input functions of > > wsmouse,

Re: ospf6d: add format attributes

On Sat, Jun 04, 2016 at 06:51:37PM +0200, Sebastian Benoit wrote: > In ospf6d, add format attributes to the proper functions and then fix the > warning in rde.c > > ok? yup > > diff --git log.h log.h > index 0cc7403..8cccd8f 100644 > --- log.h > +++ log.h > @@ -23,14 +23,22 @@ > > void

Re: ospfd: add format attributes

On Sat, Jun 04, 2016 at 06:45:53PM +0200, Sebastian Benoit wrote: > In ospfd, add format attributes to the proper functions and then fix the > warning in rde.c. > > ok? ok with me > > diff --git log.h log.h > index e0034e8..a682f67 100644 > --- log.h > +++ log.h > @@ -23,13 +23,21 @@ > >

continue merging rtwn and urtwn

Another step on the long road towards merging these drivers. Copy r88e support code into ic/rtwn.c. This can't be tested until the USB driver starts making use of the shared rtwn.c file, but it's pretty straightforward. It turns out some functions won't benefit a lot from merging, mostly where

Re: iwn(4) HT protection updates

On Fri, Jun 03, 2016 at 07:59:22PM +0200, Marcus MERIGHI wrote: > I saved the tcpdump and a more detailed report in case you want it. Thanks for testing! I've committed the change. > after a added urtwn0 (hey, another five-letter device :-). Yeah. I don't really like the name of that driver ;)

iwn(4) HT protection updates

Currently, iwn(4) does not track HT protection changes because the support code was broken and hence disabled. Here's a fixed version which should allow us to enable HT protection updates again. Index: if_iwn.c === RCS file:

Re: MBIM Patch (Round 2)

On Wed, Jun 01, 2016 at 08:35:39PM +0200, Gerhard Roth wrote: > Changing the name from 'mbim' to 'umbim' already took me serveral > hours because a simple sed(1) can't do the job. Don't have that > much lifetime left to go through this boredom once again. I spent many many hours renaming all the

Re: MBIM Patch (Round 2)

On Wed, Jun 01, 2016 at 08:18:13PM +0200, David Coppa wrote: > On Wed, Jun 1, 2016 at 6:11 PM, Stefan Sperling <s...@stsp.name> wrote: > > > I agree. And the driver can keep using the MBIM_ prefix for such macros > > even when we rename it to ubm. > > iirc, the

Re: MBIM Patch (Round 2)

On Wed, Jun 01, 2016 at 08:11:22PM +0200, Gerhard Roth wrote: > On 01.06.2016 17:32, Theo de Raadt wrote: > >>- renamed it from 'mbim' to 'umbim' > >>I tried 'ubm' as proposed by Theo but that felt weird. Esp. > >>when changing the prefixes of macros whose names were > >>

Re: utvfu driver port

On Wed, Jun 01, 2016 at 01:40:14AM -0700, patrick keshishian wrote: > Here it is... Thanks patrick! As far as I can see we don't have a man page for this driver yet. Could you provide one?

Re: ip_output, KERNEL_LOCK and multicast

On Mon, May 30, 2016 at 02:49:11PM +0200, Martin Pieuchot wrote: > Do not grab the KERNEL_LOCK if the source address is already specified. > > Note that the sending path will still be done while holding the > KERNEL_LOCK but it doesn't hurt to get this right. Plus this makes it > similar to

Re: MBIM Patch - Part 1 of 4

On Mon, May 30, 2016 at 09:35:13AM +0200, Gerhard Roth wrote: > Yes mbim does support IPv6, but the code is still missing. > I just don't have a SIM card for a provider that gives me an IPv6 > address. So I could only implement it without testing. Let's just wait until IPv6 arrives in the telco

Re: iwm(4): Add support for Intel Wireless 3165

On Sat, May 28, 2016 at 05:27:28PM +0200, Imre Vadasz wrote: > Hi, > > This adds support for the AC 3165 Intel wireless chipset. > Tested on a HP x2 210 tablet/detachable: > > iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless AC 3165" rev 0x81, msi > iwm0: hw rev 0x210, fw ver 16.242414.0,

Re: iwm(4): The valid_{rx,tx}_ant values only be read from nvm for 8000 family

On Thu, May 26, 2016 at 05:30:07PM +0200, Imre Vadasz wrote: > Hi, > > We only need to set the data->valid_tx_ant and data->valid_rx_ant > values in iwm_parse_nvm_data() for the 8000 family chips. > This matches what iwl_set_radio_cfg() in iwl-nvm-parse.c from Linux's > iwlwifi does. > > Also

Re: MBIM Patch - Part 1 of 4

On Mon, May 23, 2016 at 03:54:36PM +0200, Martin Pieuchot wrote: > I'd like to bikeshed early, we're trying to prefix all new USB driver > name with 'u'. So I'd suggest a rename when this goes in tree. umb(4) ("USB Mobile Broadband") is available.

Re: MBIM Patch - Part 1 of 4

On Mon, May 23, 2016 at 03:37:32PM +0200, Gerhard Roth wrote: > I have this stuff around quite a while now, but since patrick@ asked > me repeatedly, I think it is time to share this now. > > This is a patch that adds support for the "Mobile Broadband Interface > Model" (MBIM) from

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: 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

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

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. >

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

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

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

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

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 >

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

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.

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

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

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. > >

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. > >

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: 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 >

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

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

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: 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

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

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

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

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(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

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

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: 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

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:

ignore QoS "no data" frames for A-MPDU reordering

The current A-MPDU reordering code is being fed with not just QoS data frames but also QoS "no data" frames. Such frames do not contain sequence numbers and our reordering buffer logic will treat them as if they did. QoS frame subtype fields (in binary) and their corresponding names are: 1000

Re: Fix IWM_MAX_CMD_PAYLOAD_SIZE in iwm(4)

On Thu, Jan 14, 2016 at 10:33:53PM +0100, Imre Vadasz wrote: > In iwm(4), IWM_MAX_PAYLOAD_SIZE needs to be at least one byte smaller. > > "IWM_MAX_CMD_PAYLOAD_SIZE + sizeof(struct iwm_cmdheader)" must be smaller > than 4096, otherwise the payload length could get truncated to 0 in this >

11n: keep BlockAck window in check

There are buggy APs which emit sequence numbers like 1889, 2501, 1890, 1891, 1892, ... A jump like this causes the blockack code to move the expected sequence number window forward to 2501 and drop all incoming frames between 1889 and 2501. Eventually the numbers wrap and traffic starts flowing

iwn/iwm: fix ht params passed to firmware

The AP HT parameters we provide to the firmware are still a bit messed up. They are supposed to reflect the AP's capabilities, not our own. So use params from "ni" instead of "ic". In most case we just get lucky and things work regardless, it seems. Add SMPS (MIMO powersave) parameters, too, so

Re: mbtowc(3) errno for incomplete character

On Fri, Feb 05, 2016 at 03:53:44PM +0100, Ingo Schwarze wrote: > Index: mbtowc.c > === > RCS file: /cvs/src/lib/libc/locale/mbtowc.c,v > retrieving revision 1.2 > diff -u -p -r1.2 mbtowc.c > --- mbtowc.c 5 Dec 2012 23:20:00 -

fix iwn ccmp replay detection

iwn currently flags A-MPDU subframes which arrived out of sequence as CCMP replays and drops them. We can't rely on the LAST_RX_AMPDU flag from the last RX PHY notification, it seems. Check for a valid BA agreement instead. Updating the last seen packet number with every out-of-order packet isn't

Re: iwn firmware error

On Fri, Feb 05, 2016 at 01:23:18AM -0500, Michael McConville wrote: > When forcing my laptop to swap, I almost immediately got the following > firmware error. I'm not sure whether this is expected. Restarting the > interface brought things back to normal. > > dmesg follows. Looks like the

iwn: preserve ccmp key across htprot updates

HT protection updates forget about restoring the CCMP key to firmware so WPA breaks when protection mode changes. Index: if_iwn.c === RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v retrieving revision 1.158 diff -u -p -r1.158 if_iwn.c ---

Re: fix ADDBA params in ADDBA requests and responses

On Thu, Feb 04, 2016 at 09:42:03AM +0100, Stefan Sperling wrote: > This fixes up parameters in ADDBA requests and responses. > > Again, the current code is using the wrong bitmask to set the ack > policy bit. IEEE80211_BA_ACK_POLICY is for QoS BlockAck request > and response fr

fix ADDBA params in ADDBA requests and responses

This fixes up parameters in ADDBA requests and responses. Again, the current code is using the wrong bitmask to set the ack policy bit. IEEE80211_BA_ACK_POLICY is for QoS BlockAck request and response frames, not ADDBA request and response frames. It's important to echo back the set of

tcpdump: show 802.11 control frames

Currently, tcpdump displays 802.11 control frames as "type#4" and doesn't give more information than that. This diff makes tcpdump show the subtype of such frames, and pretty-print a few subtypes in verbose mode. There are more subtypes but these can be pretty-printed later. This can be tested

Re: tcpdump: show 802.11 control frames

On Wed, Feb 03, 2016 at 02:05:29PM +0100, Stefan Sperling wrote: > 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, tcpd

Make iwn(4) pass control frames in monitor mode

This allows tcpdump to see all control frames with iwn(4). Index: if_iwn.c === RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v retrieving revision 1.158 diff -u -p -r1.158 if_iwn.c --- if_iwn.c25 Jan 2016 11:27:11 - 1.158 +++

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

Re: sdmmc card detect

On Tue, Feb 02, 2016 at 08:06:11PM +0100, Mark Kettenis wrote: > The Bay Trail SoC SD controller for the SD card slot doesn't use the > Card Detect bit in the standard register. Instead there is a separate > gpio that signals the presence of a card in the slot. The diff below > introduces a

Re: 11n: don't require a BlockAck timeout

On Sun, Jan 31, 2016 at 05:19:42PM +, Stuart Henderson wrote: > Could this capping be an attempt to mitigate DoS from people playing > games with ADDBAs? That kind of attack doesn't make much sense. A lot of stuff in wifi depends on others being cooperative. Far more disruption can already be

Re: tcpdump: decode 802.11 QoS frames correctly

On Sun, Jan 31, 2016 at 03:14:46PM +0100, Mark Kettenis wrote: > I think you should add a TCHECK somewhere at the top for the qos frame > size otherwise this might look beyond the end of the buffer for > specially crafted frames. Oh yes, indeed. Index: print-802_11.c

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

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%

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 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

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

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

<    5   6   7   8   9   10   11   12   13   14   >