Re: sppp(4)/pppoe(4) dynamic address hack

On Mon, Jun 12, 2017 at 02:59:46PM +0100, Stuart Henderson wrote: > This seems the "least worst" option to me. (It's still racy, the > connection could come up and change the dest before the route is > added, so route addition would fail as we now require a "correct" > address on the p-p route

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 06:14:02PM +0200, Martin Pieuchot wrote: > There's no need to fix the routing table, we could something like: > > - if (hisaddr == 1) { > + if (hisaddr < 10) { > > Now I think you have a good point that using a flag is better than a > magic

Re: [PATCH] re: disable PCIe ASPM and ECPM (CLKREQ)

On Sat, Jun 10, 2017 at 11:06:43PM +0800, Kevin Lo wrote: > On Wed, May 17, 2017 at 03:58:16PM +0800, Kevin Lo wrote: > > > > >From FreeBSD (r227593, r307982): > > More and more RealTek controllers started to implement EEE feature. > > Vendor driver seems to load a kind of firmware for EEE with >

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 04:14:16PM +0200, Martin Pieuchot wrote: > If there's a real need for such arguments, because somebody use pppoe(4) > with static IP/route then why not. But that's not what you said. What > you said is that the current hack of 0.0.0.0+0.0.0.1 is broken. Static IP/route

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 11:47:27AM +0200, Martin Pieuchot wrote: > On 10/06/17(Sat) 08:35, Stefan Sperling wrote: > > On Fri, Jun 09, 2017 at 05:37:44PM +0100, Jason McIntyre wrote: > > > why do you have to specify 0.0.0.0 *and* dynaddr? > > [...] > > Regardless,

Re: sppp(4)/pppoe(4) dynamic address hack

On Sat, Jun 10, 2017 at 08:35:13AM +0100, Jason McIntyre wrote: > thanks. the ifconfig.8 bits look good, but i think you should also > change the examples given in pppoe(4) to show the updated syntax, to > prepare folks. > > actually i think it would be better to discuss the deprecated stuff > in

Re: sppp(4)/pppoe(4) dynamic address hack

On Fri, Jun 09, 2017 at 06:33:46PM +0200, Stefan Sperling wrote: > This diff changes the way dynamic addresses are configured in sppp(4). I was asked in private whether we could avoid a flag day which makes it inconvenient to upgrade remote boxes only reachable over pppoe(4). I see no h

Re: sppp(4)/pppoe(4) dynamic address hack

On Fri, Jun 09, 2017 at 10:36:45PM +0200, Christian Weisgerber wrote: > The example in the pppoe(4) man page also includes > > !/sbin/route add default -ifp pppoe0 0.0.0.1 > > to specify the default route. What happens to that? Good question. It raises an interesting point: Setting a

Re: sppp(4)/pppoe(4) dynamic address hack

On Fri, Jun 09, 2017 at 05:37:44PM +0100, Jason McIntyre wrote: > why do you have to specify 0.0.0.0 *and* dynaddr? If there is no address on the interface, the code in sppp_set_ip_addrs() loops over an empty interface address list and hence does nothing. IPCP will still negotiate an address but

sppp(4)/pppoe(4) dynamic address hack

Currently, sppp(4) interfaces use a destination address of 0.0.0.1 to indicate that the destination address should be assigned by the peer: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev em0 authproto pap \ authname 'testcaller' authkey 'donttell' up

fix missed beacon handling bugs in iwn(4) and iwm(4)

Prevent both drivers from sending additional probe requests while we're already waiting for some response from the AP. Check the ic_mgt_timer for this purpose. Fixes misbehaviour when hardware sends many "missed beacon" interrupts. We ended up flooding the AP with probe requests because the

Re: efiboot serial console support

On Tue, May 30, 2017 at 02:31:48PM +0200, YASUOKA Masahiko wrote: > + status = EFI_CALL(BS->LocateHandle, ByProtocol, _guid, 0, , 0); > + if (status == EFI_BUFFER_TOO_SMALL) { > + handles = alloc(sz); > + status = EFI_CALL(BS->LocateHandle, ByProtocol, _guid, > +

Re: beacon miss threshold

On Wed, May 31, 2017 at 01:25:36PM +0200, Mark Kettenis wrote: > > Date: Wed, 31 May 2017 11:53:19 +0200 > > From: Stefan Sperling <s...@stsp.name> > > > > On Wed, May 31, 2017 at 11:23:07AM +0200, Mark Kettenis wrote: > > > Is the beacon interval

Re: beacon miss threshold

On Wed, May 31, 2017 at 11:23:07AM +0200, Mark Kettenis wrote: > Is the beacon interval always the same for all modes/hardware? It is defined by the AP. The value (in TU) is sent to clients in beacons: # tcpdump -n -i iwn0 -y IEEE802_11_RADIO -vv 11:50:23.170309 802.11 flags=0<>: beacon,

beacon miss threshold

The net80211 stack currently provides a 'beacon miss timeout' value (in ms) which specifies how much time may elapse without beacons before drivers begin searching for a new AP. Drivers convert this timeout value into the amount of beacons they're allowed to miss. Having the stack provide this

iwm: add support for missed beacons notification

This adds support for iwm firmware's missed beacon notification. With this, the driver will notice "dead air" when a laptop moves too far away from the AP. It will automatically try to connect to another AP that is closer, or again to the same AP when it moves back in range. ok? Index: if_iwm.c

Re: 802.11 multicast frames and the basic rate set

On Tue, May 30, 2017 at 11:03:09AM +0200, Stefan Sperling wrote: > ok? Always wait for the second diff! In the previous version I missed an indirection via wn->ridx[]. wrong: rinfo = _rates[ieee80211_min_basic_rate(ic)] correct: rinfo = _rates[wn->ridx[ieee80211_min_basic_rate(ic)]];

802.11 multicast frames and the basic rate set

Many of our drivers hardcode multicast frames to 1 Mbit/s on 2 GHz. This assumes 11b interop, which is mandatory for all 2GHz PHYs and thus generally works. However, access points may modify the networks' basic rate set such that it differs from the mandatory PHY rate set. (Standard laywers may

iwm scan abort

If net80211 is not in SCAN state anymore at the point in time where the device tells us it is done scanning, do nothing instead of proceeding to select an AP anyway and eventually sending some commands that will just confuse the firmware. This might silence some error messages people have seen

Re: dsdt: redundant assignment

On Sun, May 28, 2017 at 10:25:14AM +0200, Anton Lindqvist wrote: > Digging through some old diffs. Any ok's for this one? ok stsp@ > Tested on amd64. > > Index: dsdt.c > === > RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v > retrieving

Re: git patches

On Fri, May 26, 2017 at 06:55:34AM -0400, Ted Unangst wrote: > what if we special case these special diffs? they are easily detectable, and > patch can fix them on the fly. of course, only do this when no -p option is > used to preserve patch's smarts about auto detecting directories. Fine with

Re: athn: fix ar9380 receive code

On Wed, May 24, 2017 at 10:11:21AM +0800, Kevin Lo wrote: > My AR9380 adapter arrived, but I hit a kernel panic on amd64: Which PCI product ID does this card have? > athn0 at pci2 dev 0 function 0 "Atheros AR9300" rev 0x01: apic 1 int 17 > > uvm_fault(0x81858d20,

Re: athn: fix ar9380 receive code

On Thu, May 18, 2017 at 01:19:18PM +0800, Kevin Lo wrote: > On Thu, May 18, 2017 at 02:40:49AM +0200, Stefan Sperling wrote: > > athn0 at pci1 dev 0 function 0 "Atheros AR9300" rev 0x01: apic 2 int 16 > > athn0: AR9380 rev 3 (3T3R), ROM rev 0, address xx:xx:xx:xx:xx:xx

athn: fix ar9380 receive code

AR9380 devices are currently not supported by our athn(4). There is code for them in the driver, but this code does not work yet. This diff makes monitor mode work with an AR9380 device I have lying around. athn0 at pci1 dev 0 function 0 "Atheros AR9300" rev 0x01: apic 2 int 16 athn0: AR9380 rev

fix uvm fault in athn_clock_rate

I got this uvm fault after typing 'ifconfig athn0 mediaopt monitor' after boot, as the first ifconfig command to the athn driver. Fix below. Note that IEEE80211_CHAN_ANYC is 0x (in %rax). uvm_fault(0xff011c437e00, 0x10002, 0, 1) -> e kernel: page fault trap, code=0 Stopped at

iwm: remove a firmware loading hack

It looks like we can get rid of the DELAY() hack in the firmware loader for 8000 family devices. I don't see any problems with this diff on my 8260 device. I suppose the underlying problem was fixed in if_iwm.c r1.146. Add some additional error checking while here. OK? Index: if_iwm.c

Re: DDB causing lost keystrokes on Dell iDRAC console (not inside ddb)

On Wed, May 17, 2017 at 08:59:39AM -0400, Alan McKay wrote: > Looks like this never got a response and we are seeing the same issue. > > OpenBSD 6.0, Dell 330, iDRAC 8, trying to get a console with the > iDRAC. Works great with Linux or ESXi on the box, but OpenBSD does > not work. There is

Re: rasops: fix virtual console initialization

On Sun, May 14, 2017 at 08:44:54PM -0500, joshua stein wrote: > Only copy the console buffer contents to a rasops virtual console if > it's the first one (visible). > > Otherwise all of the other virtual consoles initialize with the > trailing end of the kernel messages and then getty writes over

Re: Correct capable baseband in dmesg for RTL8188E chips

On Mon, May 08, 2017 at 05:35:26PM +0100, Ricardo Mestre wrote: > Hi tech@ > > During stsp@'s effort to merge rtwn(4) and urtwn(4), more specifically since > r1.6 of /cvs/src/sys/dev/ic/rtwn.c, my urtwn(4) device started showing in > dmesg > with a capable baseband of 0T0R (only noticed it

Re: fix iwm command wait vs interface reset

On Mon, May 08, 2017 at 03:54:38PM +0200, Mark Kettenis wrote: > > Date: Mon, 8 May 2017 15:36:11 +0200 > > From: Stefan Sperling <s...@stsp.name> > > > > In iwm_send_cmd(), look at the generation counter instead of the STOPPED > > flag > > to determin

fix iwm command wait vs interface reset

In iwm_send_cmd(), look at the generation counter instead of the STOPPED flag to determine whether the interface was reset while we were sleeping. The flag will be set if the interface is still down when the task wakes up, but the interface could already be up again in which case the flag will be

iwm nic lock improvements

The 7000 generation of iwm hawrdware requires that the driver sets a bit in the CSR_GP_CNTRL register before accessing most other registers or sending commands to the firmware. The device will keep paying attention while this bit is set. In the driver, the act of setting this bit is referred to as

iwm firmware rate table fixes

This fixes issues with iwm(4) firmware's retry rate table. For a HT node ni_txrate is always zero and we should be using ni_txmcs instead. Simplify the if-else logic to make sure of that. The mimo delimiter in the link quality command was never set. I don't know how important this is. But Linux

Re: Fix umb(4) on big-endian machines

On Wed, May 03, 2017 at 10:12:04AM +0200, Gerhard Roth wrote: > Hi, > > all MBIM values are in litte-endian encoding but somewhere in the fine > print it reads that "the addresses will be in network byte order". > > So applying letoh32() on addresses is just plain wrong. On little-endian >

Re: Switch IEEE802.11 crypto to the new AES

On Tue, May 02, 2017 at 01:53:33PM +0200, Mike Belopuhov wrote: > OK? ok

Re: Convert CMAC and Key Wrap regress tests over to the new AES

On Tue, May 02, 2017 at 01:56:37PM +0200, Mike Belopuhov wrote: > OK? ok

fix unreliable association to hidden SSIDs

The SSID element in beacons contains a length followed by the SSID value. If an AP is configured to hide its SSID it sends a non-zero length SSID which contains only zeroes: tcpdump: listening on iwm0, link-type IEEE802_11_RADIO 15:53:46.250095 802.11 flags=0<>: beacon, \

Re: Ldomctl interrupt boot

On Sun, Apr 23, 2017 at 02:14:51PM +0100, Andrew Grillet wrote: > Hi > > I have a T2000 running OpenBSD 6.0, with five guest domains. > > Primary and some guests are working. I am attempting to install the OS in > the remaining guests. In the process of installing the OS on vdisk0 of a > guest,

iwm(4) monitor mode

This diff adds monitor mode to iwm(4) (man page changes not included). It requires the multi-frame interrupt support diff I just sent earlier. Otherwise plenty of "unhandled firmware response" shows up in dmesg. Index: if_iwm.c ===

iwm(4) multi-frame interrupt support

iwm(4) currently sets the SINGLE_FRAME_MSK bit of the Rx config register. This bit tells the firmware that the driver wants one interrupt per frame, i.e. it prevents the firmware from placing more than one frame into the 4k RX buffer. Frames can contain firmware command responses and actual 802.11

Re: umb: aggregate packets on tx

On Sat, Apr 15, 2017 at 11:21:41PM +0200, Alexander Bluhm wrote: > On Mon, Feb 20, 2017 at 04:35:10PM +0100, Gerhard Roth wrote: > > On Mon, 12 Dec 2016 14:50:50 +0100 Gerhard Roth > > wrote: > > > The current umb(4) implementation needs one USB transfer for every packet >

Re: Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver

On Thu, Mar 23, 2017 at 07:42:13PM +0300, Denis wrote: > Having trouble with TP-LINK AC600 Archer T2UH based on Ralink's MT7650 > chipset with run driver on OpenBSD 6.0-stable with all the latest source > tree patches installed. Our run(4) driver does not yet support this chipset. Additional

Re: Atheros AR9280+AR7010 USB stick don't work in BSS mode but Host AP

On Thu, Mar 23, 2017 at 07:56:08PM +0300, Denis wrote: > Have Atheros AR9280+AR7010 USB stick athn(4). > Long ago I tested it with OpenBSD 5.6 in Host AP mode 5GHz band, it does > not work as AP but successful in BSS in both supported bands. > > On OpenBSD 6.0 situation is different. It is

ifconfig magic number

Replace a magic number with the corresponding macro. Index: ifconfig.c === RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.339 diff -u -p -r1.339 ifconfig.c --- ifconfig.c 12 Mar 2017 03:18:57 - 1.339

wpa key vs wep key

I see no reason to leave WEP enabled if a WPA key is set, and leaving WPA enabled when a WEP key is set. Several cases of "my wifi suddenly stopped working" turned out to be due to stale WEP keys interfering with WPA. I think it is better to let the kernel handle this transition instead of

Re: fix ifconfig scan confusing WEP and WPA

On Sat, Mar 11, 2017 at 09:55:15AM +0900, Stefan Sperling wrote: > While a wifi interface is configured to use WEP 'ifconfig scan' will > mistakenly show all WPA APs as WEP ones. Fix below. > > This is a small ABI change in struct ieee80211_nodereq. My diff has been committed but

Re: dynamic RTS threshold in 11n mode

On Sat, Mar 11, 2017 at 08:55:54AM +0900, Stefan Sperling wrote: > On Sat, Mar 04, 2017 at 10:04:51PM +0100, Stefan Sperling wrote: > > This diff makes the RTS threshold dynamic in 11n mode. > > It flips the RTS threshold between DEFAULT (512 bytes) and MAX (the > >

pledge vs. sockopt IP_HDRINCL

pledge() currently forbids IP_HDRINCL in setsockopt(). If I allow it in "inet", I can pledge /usr/ports/net/mtr (a traceroute tool) to "stdio rpath inet dns tty". Is this safe? Should I require something else than "inet"? Index: kern_pledge.c

fix ifconfig scan confusing WEP and WPA

While a wifi interface is configured to use WEP 'ifconfig scan' will mistakenly show all WPA APs as WEP ones. Fix below. This is a small ABI change in struct ieee80211_nodereq. Index: sys/net80211/ieee80211_ioctl.c === RCS file:

Re: dynamic RTS threshold in 11n mode

On Sat, Mar 04, 2017 at 10:04:51PM +0100, Stefan Sperling wrote: > This diff makes the RTS threshold dynamic in 11n mode. > It flips the RTS threshold between DEFAULT (512 bytes) and MAX (the > maximum size of a non-aggregated 802.11 frame). Things have been working fine for me with

Re: pfsync if_get conversion

On Thu, Mar 09, 2017 at 12:42:43PM +0100, Martin Pieuchot wrote: > On 09/03/17(Thu) 08:48, Stefan Sperling wrote: > > This diff converts a struct ifnet pointer in pfsync's softc into an > > ifindex with corresponding if_get()/if_put() calls. > > This avoid the panic but

pfsync if_get conversion

This diff converts a struct ifnet pointer in pfsync's softc into an ifindex with corresponding if_get()/if_put() calls. Seems to still work fine and fixes the following panic reported by double-p: ifconfig pfsync0 syncdev vlan5 up ifconfig vlan5 destroy ifconfig pfsync0 destroy -> crash because

Re: 11n support for athn(4)

On Tue, Mar 07, 2017 at 07:12:43AM +0200, Timo Myyrä wrote: > I didn't think it would improve things yet but I had the antenna so I'd figure > I'd stick it in the AP while I'm tweaking it anyway. > > Speaking of 5Ghz, my AP uses athn chipset AR9280 which seems to support 2.4Ghz > and 5Ghz. Can I

Re: 11n support for athn(4)

On Mon, Mar 06, 2017 at 07:36:21AM +0200, Timo Myyrä wrote: > Did some tcpbench testing and got following results: > Each test run with: tcpbench -s || tcpbench -t 15 commands. > Host AP: apu 2b4 with athn, client = thinkpad t430s with iwn (OpenBSD) > > channel 9 running old snapshot etc: > 11n

Re: 11n support for athn(4)

On Tue, Jan 31, 2017 at 07:10:04AM +0200, Timo Myyrä wrote: > 11g: Client->AP: ~15Mbps, AP->Client: ~5Mbps > 11n: Client->AP: ~3Mbps, AP->Client: ~5Mbps I just committed a change which makes RTS optional in 11n mode. The AP starts out with RTS enabled. Every 30 seconds the AP checks for the

11n hostap: make HT protection dynamic

OpenBSD 11n APs currently enforce HT protection (RTS) for all frames. This made the initial 11n hostap implementation easier for me. Sending RTS frames implies unnecessary overhead for data frames. HT protection is only required if any non-HT devices (11a/b/g) are around. Our node cache contains

OpenBSD errata, Mar 1, 2017

A man-in-the-middle vulnerability has been found in OpenBSD's wireless stack. A malicious access point can trick an OpenBSD client using WPA1 or WPA2 into connecting to this malicious AP instead of the desired AP. When this attack is used successfully the OpenBSD client will send and accept

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

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

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

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,

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

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

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

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!

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

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

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

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 >

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

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

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

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: iwm: fix a timeout race

Anyone? This could crash all your iwm(4) machines any time you run ifconfig... On Tue, Jan 17, 2017 at 08:22:27PM +0100, Stefan Sperling wrote: > 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 tha

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

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

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 -

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

Re: 11n support for athn(4)

On Mon, Jan 16, 2017 at 07:18:04PM +, Peter Kay wrote: > I'm still having issues with this. > > When the access point wedges, it seems to affect my Android phone more > than the iwn laptop. ifconfig athn0 down up does resolve the problem > in the short term. Do you have 2 antennas properly

Re: 11n support for athn(4)

On Sun, Jan 15, 2017 at 10:31:29PM +, Olivier Cherrier wrote: > On Mon, Jan 09, 2017 at 01:54:55PM +0100, s...@stsp.name wrote: > > Date: Mon, 9 Jan 2017 13:54:55 +0100 > > From: Stefan Sperling <s...@stsp.name> > > To: tech@openbsd.org > > Subject: 11n support

Re: 11n support for athn(4)

On Sat, Jan 14, 2017 at 12:42:09PM +, Peter Kay wrote: > On 14 January 2017 at 12:02, Stefan Sperling <s...@stsp.name> wrote: > > On Sat, Jan 14, 2017 at 11:31:00AM +, Peter Kay wrote: > >> On 14 January 2017 at 11:23, Stefan Sperling <s...@stsp.name> wrote:

Re: 11n support for athn(4)

On Sat, Jan 14, 2017 at 11:31:00AM +, Peter Kay wrote: > On 14 January 2017 at 11:23, Stefan Sperling <s...@stsp.name> wrote: > > On Sat, Jan 14, 2017 at 11:03:24AM +, Peter Kay wrote: > >> On 12 January 2017 at 15:06, Stefan Sperling <s...@stsp.name> wrote: &

Re: 11n support for athn(4)

On Sat, Jan 14, 2017 at 11:03:24AM +, Peter Kay wrote: > On 12 January 2017 at 15:06, Stefan Sperling <s...@stsp.name> wrote: > > On Tue, Jan 10, 2017 at 12:27:47AM +0100, Stefan Sperling wrote: > >> On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote: &

Re: 11n support for athn(4)

On Tue, Jan 10, 2017 at 12:27:47AM +0100, Stefan Sperling wrote: > On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote: > > This diff adds 11n support to the athn(4) driver. > > Requires -current net80211 code from today. > > A better diff which fixes several bu

Re: 11n support for athn(4)

On Thu, Jan 12, 2017 at 06:19:06AM +, Peter Kay wrote: > OK, got it working. Pulled the kernel sources direct from cvs without > pre-loading and it compiled. Thank you for testing! > Haven't had time for a proper test, but there are a couple of points. > > Hardware MAC AR5416 rev 2, RF

Re: 11n support for athn(4)

On Wed, Jan 11, 2017 at 10:00:50PM +, Peter Kay wrote: > On 9 January 2017 at 23:27, Stefan Sperling <s...@stsp.name> wrote: > > On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote: > >> This diff adds 11n support to the athn(4) driver. > >> Req

<    3   4   5   6   7   8   9   10   11   12   >