Re: Remove unused vars from if_urtwn.c

On Sun, Sep 13, 2015 at 05:31:10PM -0400, Michael McConville wrote: > Index: if_urtwn.c > === > RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v > retrieving revision 1.51 > diff -u -p -r1.51 if_urtwn.c > --- if_urtwn.c10 Sep 2015

Re: rc script for ftp-proxy with v6

On Sat, Sep 12, 2015 at 02:29:32PM +0200, Mike Belopuhov wrote: > On 12 September 2015 at 14:20, Stuart Henderson wrote: > > ftp-proxy can only open one listening socket, so to use it with > > both IPv4 and IPv6, two instances are required. Now that rc.subr > > does exact

iwm(4) newstate task (again)

This is yet another attempt at improving the iwm(4) newstate task. The goal is to simplify things by only queuing one state transition at a time. The newstate task now always transitions to the most recently requested state, rather than hopping along with every request. This allows us get rid of

Re: iwm(4) newstate task (again)

On Sun, Sep 27, 2015 at 08:00:19PM +0200, Stefan Sperling wrote: > This is yet another attempt at improving the iwm(4) newstate task. This diff has been working nicely for me, with many suspend/resume cycles. Never had a problem connecting to several wifis. Any objections? Any Oks? > Th

if_type for dvmrpd

As done for bgpd recently, rename if_mediatype to if_type. Rationale: if_type values come from the IFT_ namespace in if_types.h, not from the IFM_ namespace from if_media.h. This change prevents confusion between uint8_t interface types and uint64_t media types. Remove get_ifms_type() from

ifmedia64 / if_type for ospf[6]d

As done for bgpd recently, rename media_type to if_type. Rationale: if_type values come from the IFT_ namespace in if_types.h, not from the IFM_ namespace in if_media.h. This change prevents confusion between uint8_t interface types and uint64_t media types. This touches OSPF for IPv4 and for

ifmedia64 / if_type for ripd

As done for bgpd recently, rename media_type to if_type. Rationale: if_type values come from the IFT_ namespace in if_types.h, not from the IFM_ namespace in if_media.h. This change prevents confusion between uint8_t interface types and uint64_t media types. Some ifmedia64 fixes here as well.

Re: iwm(4) and lladdr

On Mon, Sep 28, 2015 at 01:02:24PM +0200, Martin Pieuchot wrote: > It seems to me that the recent iwm(4)/if_setlladdr() fix applies to > more (if not all) wireless drivers since the stack keeps its own > copy of the lladdr. Does the diff below make sense? > > I'd also suggest to stop abusing

remove unused(?) #includes from snmpd

I was looking for ifmedia bits to fix in here, but found nothing except a few unused if_media.h includes. Turns out snmpd compiles (on i386) without warnings with a lot less headers included. Is this a safe change? I've left sys/types.h alone since I guess removing it might break builds using

Re: remove unused(?) #includes from snmpd

On Sat, Sep 26, 2015 at 03:29:07PM -0400, Michael McConville wrote: > I see some preproc conditions in usr.sbin/snmpctl/snmpclient.c. I only > bothered to check the first two. Are you sure they still compile in all > circumstances? If I understand correctly, compiling without warning only >

ifmedia64 / if_type for ldpd

As done for bgpd recently, rename media_type to if_type. Rationale: if_type values come from the IFT_ namespace in if_types.h, not from the IFM_ namespace in if_media.h. This change prevents confusion between uint8_t interface types and uint64_t media types. In this daemon, confusion has already

Re: remove unused(?) #includes from snmpd

On Sat, Sep 26, 2015 at 03:51:25PM -0400, Michael McConville wrote: > Stefan Sperling wrote: > > On Sat, Sep 26, 2015 at 03:29:07PM -0400, Michael McConville wrote: > > > I see some preproc conditions in usr.sbin/snmpctl/snmpclient.c. I > > > only bothered to check

Re: lighter sleep

On Sun, Sep 20, 2015 at 09:40:05PM -0600, Bob Beck wrote: > I concur, I don't want to see a plethora of "isnumber" > "ismaybeanumber" bullshit in the tree that > do the same thing "isdigit" does.. if for whatever reason we want > isdigit to be more efficient because > the most important thing I

iwm(4) rx reset fix

Properly reset the RX ring by clearing RX buffer status exposed to hardware. Found by Matthew Dillon while porting FreeBSD's iwm(4) to Dragonfly. ok? Index: if_iwm.c === RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v retrieving revision

iwm(4) bssid addr fix

Adrian Chadd noted that Linux iwlwifi sends the broadcast address to the firmware when not associated, rather than zeros. ok? Index: if_iwm.c === RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v retrieving revision 1.46 diff -u -p -r1.46

Re: lighter sleep

On Mon, Sep 21, 2015 at 01:25:04PM -0400, Ted Unangst wrote: > Stefan Sperling wrote: > > > > Just remove the setlocale() call to leave sleep(1) in the default "C" > > locale. > > here's a diff that does that. you're right, there's no need to rewrite ctype

iwm association fix

While debugging my 802.11n code I got tired of iwm randomly failing to associate or even getting into a state where I had to reboot to get it to work again. In case it got hung, the newstate task was sleeping in "iwmauth" and never woke up, which made me revisit how this driver transitions to

Re: ip6 fragment nibble

On Thu, Dec 03, 2015 at 06:48:28AM -0500, Ted Unangst wrote: > Cleaner this way I think. > ok > > Index: frag6.c > === > RCS file: /cvs/src/sys/netinet6/frag6.c,v > retrieving revision 1.65 > diff -u -p -r1.65 frag6.c > ---

Re: [patch] fix urtw on big-endian CPU (PPC)

On Mon, Dec 07, 2015 at 09:31:11PM +0100, Cédric TESSIER wrote: > Hi, > > I'm bringing my old Mac Mini G4 back to life, and I had an issue with a > wireless dongle (RTL8187 rev 0x04, RFv2). > > urtw interface was available, but wasn't working at all. > > Investigations highlighted an endianness

Re: Pull tmpfs fix from NetBSD

On Fri, Dec 11, 2015 at 04:47:16PM -0500, Michael McConville wrote: > Stefan Sperling wrote: > > On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote: > > > Bob Beck wrote: > > > > Stability before performance. Tmpfs does not have the former yet.

Re: initial 802.11n implementation

Here's an updated diff, which applies to -current, for testing. I'll spend some time tomorrow splitting this up into smaller chunks for review with explanations of the changes. No known problems exist with this diff. Please test anywhere, even without iwm(4). Thanks. Index: dev/pci/if_iwm.c

Re: Pull tmpfs fix from NetBSD

On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote: > Bob Beck wrote: > > Stability before performance. Tmpfs does not have the former yet. > > ok mmcc@ for your PR_ZERO diff, as long as there's a comment added about > the performance impact and the potential to back out in the

Re: initial 802.11n implementation

On Sat, Dec 12, 2015 at 12:09:17AM +0100, Stefan Sperling wrote: > Here's an updated diff, which applies to -current, for testing. > I'll spend some time tomorrow splitting this up into smaller > chunks for review with explanations of the changes. > > No known problems exist

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

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 de

11n ifmedia monitor mode

11n ifmedia doesn't pick up monitor mode correctly. ok? Index: ieee80211.c === RCS file: /cvs/src/sys/net80211/ieee80211.c,v retrieving revision 1.51 diff -u -p -r1.51 ieee80211.c --- ieee80211.c 27 Nov 2015 04:03:45 - 1.51

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

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 >

11n support for iwm(4)

All my outstanding 11n changes for net80211 have been committed. What's left now is adding 11n support to device drivers. This is my current 11n diff for the iwm(4) driver. Supports HT MCS 0-7 (theoretical limit 65 Mbit/s) and reception of A-MSDU and A-MPDU aggregated frames. Changes from the

11n: finish A-MPDU Rx path

This patch completes net80211 support for receiving A-MPDUs. This is a required feature of 11n. Technically, sending A-MPDUS is required, too, but since we're not trying to get certified by the Wifi Alliance we can postpone this until later. Devices we interoperate with won't care if we don't

Re: initial 802.11n implementation

On Sat, Dec 12, 2015 at 11:56:47AM +0100, Martin Pieuchot wrote: > On 12/12/15(Sat) 00:19, Stefan Sperling wrote: > > Index: net80211/ieee80211_input.c > > === > > RCS file: /cvs/src/sys/net80211/ieee80211_inp

11n: HT negotiation fixes

Some APs will not negotiate 11n (aka HT) if the vendor-specific WME (Wireless Multimedia Extensions) info element is missing in probe and association requests. WME info essentially tells the other end that we're QoS capable, which is a requirement for 11n (e.g. A-MPDUs are sent in QoS data

11n: Finish A-MSDU receive

A-MSDU frames are aggregates which contain MSDUs (ethernet frames) as subframes, rather than MPDUs (802.11 frames) as A-MPDUs do. Each subframe has a header containing sender and target MAC address and the subframe's length. For a visual illustration, see

Re: 11n: Finish A-MSDU receive

On Sat, Dec 12, 2015 at 03:08:00PM +0100, Mark Kettenis wrote: > > @@ -1072,6 +1079,10 @@ ieee80211_amsdu_decap(struct ieee80211co > > } > > ieee80211_deliver_data(ic, m, ni); > > > > + if (n->m_len == 0) { > > + m_freem(n); > > +

scan regression fixes

This should fix the infinite scanning loops people have been reporting with 11n-enabled iwn(4), as well as the issue where clients associating to 11g APs end up in 11b mode and can't use OFDM data rates. ok? Index: ieee80211.c ===

Re: preparing multitouch support - request for tests

On Wed, Dec 16, 2015 at 12:55:03PM +, Tati Chevron wrote: > Sorry to be negative, but I just don't see the perceived value in this. You wouldn't want to use OpenBSD on a trouchscreen computer if you had one? Where windows can be moved or resized depending on how many fingers you use to touch

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

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.

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

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

Re: preparing multitouch support - request for tests

On Wed, Dec 16, 2015 at 04:11:21PM +, Tati Chevron wrote: > >So I believe this work is important. > > I think it's much more important to look at the impact on existing use cases, > before making changes and introducing a lot of new code that the end user > can't easily disable, and

Re: rate selection fixes for iwm and iwn

New diff which applies to -current after IEEE80211_NO_HT removal commit. Index: if_iwm.c === RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v retrieving revision 1.72 diff -u -p -r1.72 if_iwm.c --- if_iwm.c5 Jan 2016 18:41:15 -

fix iwn firmware error during init

I've run into an issue where iwn(4) fails to init the hardware. Running 'ifconfig iwn0 scan' resulted in: setting configuration iwn0: fatal firmware error firmware error log: error type = "SYSASSERT" (0x0005) program counter = 0x00022088 source line = 0x00A4 error data

Re: rate selection fixes for iwm and iwn

On Tue, Jan 05, 2016 at 11:11:32PM +0100, Mark Kettenis wrote: > > Date: Tue, 5 Jan 2016 15:06:00 +0100 > > From: Stefan Sperling <s...@stsp.name> > > The problem I'd like to fix is that in 11n mode iwn's table currently > > contains MCS 7 to 0, but no legacy r

Re: ifconfig format bug

On Wed, Jan 06, 2016 at 01:59:41PM -0500, Ted Unangst wrote: > ifconfig.c: In function 'print_media_word': > ifconfig.c:2776: error: format '%d' expects type > 'int', but argument 2 has type 'long long unsigned int' > > maybe a cast to int is ok? but if there's no harm in printing the > whole

initialize A-MPDU params in htcap element

I forgot about initializing the A-MPDU parameters field in HT capability elements. This field specifies the max size of A-MPDU, and the spacing of A-MPDU subframes. Spacing is currently set to zero which means 'no restricition', but intel wireless devices need at least 4 microseconds of slack

APs for 80211n development

80211n hacking requires access to a wide variety of access points. So, time to ask the community to help provide pre-configured APs for this: - Please send me the specific model name first, so that I can avoid duplication, and I'll reply with a shipping address. - Please pre-configure them as

Re: scan regression fixes

On Fri, Dec 18, 2015 at 03:16:52PM +0100, David Coppa wrote: > On Thu, Dec 17, 2015 at 10:34 PM, Stefan Sperling <s...@stsp.name> wrote: > > On Thu, Dec 17, 2015 at 08:13:03PM +0100, Stefan Sperling wrote: > >> This should fix the infinite scanning loops people have been

Re: [patch] fix urtw on big-endian CPU (PPC)

On Mon, Dec 07, 2015 at 11:02:51PM +0100, Stefan Sperling wrote: > On Mon, Dec 07, 2015 at 09:31:11PM +0100, Cédric TESSIER wrote: > > Hi, > > > > I'm bringing my old Mac Mini G4 back to life, and I had an issue with a > > wireless dongle (RTL8187 rev 0x04, RFv

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

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

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

Re: remove net80211 turbo mode

On Mon, Jan 11, 2016 at 11:11:08AM +0100, Mark Kettenis wrote: > Agreed. I don't have any working ath(4) hardware to test this. This > diff introduces some long (>80 characters) lines; you might want to > fix that before you commit it. Sure, I will fix the long lines. I'm building a release

remove net80211 turbo mode

This diff removes turbo mode, which is a proprietary extension offered by Atheros devices of the ath(4) 11a/b/g generation. This seems to be a channel bonding technique, similar to 11n 40 MHz channels but not interoperable with 11n. I'd like to remove this because the implementation looks

Re: fix iwn firmware error during init

On Sat, Jan 09, 2016 at 10:25:45PM +0100, Stefan Sperling wrote: > I've run into an issue where iwn(4) fails to init the hardware. > > Running 'ifconfig iwn0 scan' resulted in: > > setting configuration > iwn0: fatal firmware error > firmware error log: > erro

ifconfig mode subcommand

Do not require users to type 'media autoselect mode ...' if all they want is to force a particular operating mode. This allows 11n support to be disabled by typing short commands like: ifconfig iwn0 mode 11a ifconfig iwn0 mode 11g ifconfig iwn0 mode 11b The new -mode command restores the

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

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

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,

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

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.

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

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

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

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

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

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

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

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.

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

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

acpithinkpad tablet dock/undock events

Add events which occur when docking/undocking a tablet observed on the Helix 2. Index: acpithinkpad.c === RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v retrieving revision 1.50 diff -u -p -r1.50 acpithinkpad.c --- acpithinkpad.c

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

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

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 -

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

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

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

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

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