On Sun, Apr 18, 2021 at 09:58:41PM +1000, Ross L Richardson wrote:
> Under "IEEE 802.11 wireless stack improvements and bugfixes:", an item
> appears to have been truncated...
> "Fixed automatic selection of the 11a/b/g/n/ac operating mode when"
>
> Ross
>
>
I've fixed this. Thanks for
My athn RA patch resulted in mixed test reports. People running the
device in client mode were happy all around, while others using the
device as an access point reported mixed results. I have now figured
out what goes wrong in hostap mode.
When auto-selecing a channel an athn(4) access point may
On Wed, Apr 14, 2021 at 11:01:47AM +0200, Ivo Sbalzarini wrote:
> as suggested over at misc@ (thanks, Stuart!), I am sending a
> patch below to add the PCI IDs of the Thunderbolt and WiFi
> devices in Lenovo Thinkpad X1 Extreme Gen 3 laptops, and to
> enable the Intel AX201 wireless LAN in the
Given the recent fixes required for ipw(4), I suspect that iwi(4)
has similar issues and requires the patch below to actually pass
any packets.
While here, add a missing error check in the association sequence.
Could anyone test iwi(4) without this patch to confirm that it is
broken, and again
On Mon, Apr 12, 2021 at 04:29:36PM -0600, Todd C. Miller wrote:
> On Mon, 12 Apr 2021 21:18:41 +0200, Stefan Sperling wrote:
>
> > The problem is that the code scanning a common chunk of lines doesn't
> > account for the possibility that EOF may occur before a final newline.
Josh Rickmar discovered a bug in 'got cherrypick' where an error
was raised even though the merge should have succeeded:
got: unexpected end of file
I have traced this back into OpenBSD's diff3(1) implementation.
With the 3 attached files called a, b, and c (files a and b lack the
On Sat, Apr 03, 2021 at 08:30:14PM +, Mikolaj Kucharski wrote:
> This athn(4) client is probably a red herring. Even after reverting the
> patch I still get significant packet loss. So far I see network issues
> only on that one box.
Thank you for following up on this.
The athn driver does
On Tue, Mar 30, 2021 at 11:06:43PM -0400, Scott Bennett wrote:
> However, my laptop with AR9287 was noticeably worse with this diff (dropped
> pings, stuttering keystrokes in interactive ssh session, estimated 20
> minutes to scp(1) a 20M file...). The combination of apu2 with diff and my
> laptop
On Tue, Mar 30, 2021 at 07:36:28PM +0200, Peter Hessler wrote:
> Been running this for about 24 hours on my x395, seems to be good.
>
> Had only one stuck wifi when first trying it, but I was also stuck on a
> 2.4GHz channel and live in a dense apartment building. Forcing it to
> move to a 5GHz
This patch attempts to add support for receiving A-MSDUs to iwm(4).
If you are using iwm(4) then please run with this patch and let me
know if it causes regressions. Thanks!
ACHTUNG: This patch breaks iwx(4)! Don't use it there! For this reason,
the patch can neither be committed nor be put into
IEEE 802.11 sequence numbers wrap around at 0xfff, not 0x.
ok?
diff 567a54141cb7379326a3670b319b26530610e1e8 /usr/src
blob - a44e88e5d0e94101a1966fc95d2daceba78c7246
file + sys/net80211/ieee80211_input.c
--- sys/net80211/ieee80211_input.c
+++ sys/net80211/ieee80211_input.c
@@ -2056,7 +2056,7
On Thu, Mar 25, 2021 at 11:48:22AM +, Ricardo Mestre wrote:
> Hi,
>
> As the comment already explains `mcs' may come invalid from the the hardware
> and then code uses it as index before actually checking its value. The patch
> below adjusts it so that it's only used after the check.
>
>
On Tue, Mar 23, 2021 at 07:47:08PM +, Mikolaj Kucharski wrote:
> I also have third system, with the same athn(4) card (only mac address
> is different in `dmesg | grep athn` output), but it acts as a Wi-Fi
> client and is connected to OpenBSD athn(4)-based access point from
> my previous email
This switches athn(4) to the new RA Tx rate adaptation module.
Tests on athn(4) PCI devices are welcome.
USB devices don't need to be tested in this case Tx rate adaptation
is taken care of by firmware.
I could only test on AR9285 so far, but the result looks promising.
diff
c].edca_txop = htole16(ac->ac_txoplimit * 32);
}
if (ni->ni_flags & IEEE80211_NODE_QOS)
cmd->qos_flags |= htole32(IWX_MAC_QOS_FLG_UPDATE_EDCA);
> ---Original---
> From: "Stefan Sperling" Date: Thu, Mar 18, 2021 17:07 PM
> To: "zxystd&q
Our iwn(4) driver tries to be a bit smart and clears already acknowledged
frames from Tx aggregation queues, even if those frames are still in the
firmware's current block ack window.
Instead, the driver can simply clear frames before the firmware's BA window.
This matches what the Linux driver
On Thu, Mar 18, 2021 at 11:41:33AM +0800, zxystd wrote:
> The indexes into the ac array in the iwx_mac_ctxt_cmd_common are from the
> iwx_ac enum and not the txfs. The current code therefore puts the edca params
> in the wrong indexes of the array, causing wrong priority for data-streams of
>
While testing my RA patches, I've seen iwn "hang" even though the AP and
iwn client were still exchanging packets at the wifi layer, but the upper
layers IP/UDP/TCP etc. were stuck. I could easily trigger this by running
tcpbench and moving towards the edge of the range of my AP.
Traffic would
On Wed, Mar 10, 2021 at 08:35:37PM -0800, Aaron Miller wrote:
> On Tue, 2021-03-09 at 14:48 +0100, Stefan Sperling wrote:
> > This implements a new rate adaptation module for net80211, called
> > "RA",
> > which resulted from a long discussion and exchanges o
*sc)
sc->calib_cnt = 0;
timeout_add_msec(>calib_to, 500);
- ieee80211_mira_node_init(>mn);
+ ieee80211_ra_node_init(>rn);
/* Link LED always on while associated. */
iwn_set_led(sc, IWN_LED_LINK, 0, 1);
blob - 3af35055a6ea1c3586ad1c56c4e
On Sun, Mar 07, 2021 at 05:14:08PM -0800, Greg Steuck wrote:
> I had an iwx working fine (modulo known issues) for a bit on amd64 current:
>
> iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x00, msix
> iwx0: hw rev 0x350, fw ver 48.1335886879.0, address xxx
>
> Then for no discernible
bioctl(8) only looks at the first character of the -c option argument
and ignores any trailing characters in the argument. Following the
addition of the RAID1C discipline this behaviour can lead to confusion.
This command with a typo ("C1" vs "1C") attempts to create a CRYPTO volume:
# bioctl
decryption
if we're not on an open network)
On Wed, Dec 09, 2020 at 03:34:05PM +0100, Stefan Sperling wrote:
> With A-MSDUs enabled in -current people are seeing a lot of
>
> input packet decapsulations failed
>
> events in netstat -W iwm0.
>
> This fixes the iss
With A-MSDUs enabled in -current people are seeing a lot of
input packet decapsulations failed
events in netstat -W iwm0.
This fixes the issue on iwm 8265 for me. There are between 6 and 8 bytes of
trailing data in the A-MSDU frame buffer. This results in a decap failure
being counted
On Tue, Dec 08, 2020 at 04:49:27PM +0100, Tobias Heider wrote:
> Hi,
>
> here is another diff that should fix associating with
> some APs that currently don't work.
>
> If block ack is active and the first frame got lost,
> subsequent packets are held back until a timeout expires.
> When this
When announcing RSN (WPA2) capabilities in management frames such as
association requests, we currently echo back all RSN (i.e. WPA2)
capabilities which were announced by our peer.
This is bad in case the peer announces features we don't support.
One such feature is Management Frame Protection
On Mon, Dec 07, 2020 at 03:49:20PM +0100, Tobias Heider wrote:
> On Mon, Dec 07, 2020 at 02:33:10PM +0100, Stefan Sperling wrote:
> > On Mon, Dec 07, 2020 at 01:31:09PM +0100, Tobias Heider wrote:
> > > Some APs request a BA agreement and continue to send QOS packets
>
On Mon, Dec 07, 2020 at 03:32:48PM +0100, Tobias Heider wrote:
> Hi,
>
> this is an iwx(4) port of the iwm(4) fix by Christian Erhardt
> which I sent in a previous mail:
> https://marc.info/?l=openbsd-tech=160733342209497=2
>
> I don't have a iwx(4) card to test this, but the diff to iwm(4) is
On Mon, Dec 07, 2020 at 02:36:05PM +0100, Tobias Heider wrote:
> Hi,
>
> our net80211 gapwait accounting implementation seems to have several
> problems:
> - If we lose packets with serial numbers 0 und 2 but receive the
> packet with serial number 1, the first gap wait timeout will
> skip
On Mon, Dec 07, 2020 at 01:31:09PM +0100, Tobias Heider wrote:
> Some APs request a BA agreement and continue to send QOS packets
> for the same tid (with normal ack policy). Currently, these packets
> make it to the higher layers without going through BA reordering or the
> BA buffer. This
On Mon, Dec 07, 2020 at 10:28:59AM +0100, Tobias Heider wrote:
> Hi,
>
> In iwm_rx_pkt() the calculation of "remain" seems to be wrong if
> there are three or more MPDUs in one packet.
> "remain" is initialized with the output buffer size.
> Each time an MPDU is found in the packet remain is
On Wed, Nov 11, 2020 at 09:16:16PM +0100, Matej Nanut wrote:
> Hello,
>
> I've applied your diff and dhclient now works on my athn0 interface,
> where it didn't work before.
>
> The symptom was that it did get a link, but couldn't get a lease.
>
> Thanks. Matej
Thank you for confirming. I
Similar to the urtwn(4) WPA1/TKIP fix I have just committed, there's
a bug in athn(4) where the value of ni_rsncipher is used to guide the
hardware- vs. software-crypto decision for multicast frames, not just
for unicast frames as was intended.
This means multicast frames could fail to decrypt if
On Mon, Oct 19, 2020 at 10:06:52PM +0200, Christian Weisgerber wrote:
> [Picking this up again after a month:]
>
> Our basename(3) and dirname(3) take a const argument:
>
> char*basename(const char *);
> char*dirname(const char *);
>
> POSIX says otherwise...
>
> char
On Sun, Sep 06, 2020 at 05:19:46PM +0530, Neeraj Pal wrote:
> Hi there,
>
> I have found that the crash is still observed which had already been
> discussed, here,
> https://marc.info/?l=openbsd-tech=143662082630187=2 on -current
> and also on 6.7
>
> also verified that the patch
>
On Thu, Sep 03, 2020 at 07:15:23AM +0200, Claudio Jeker wrote:
> On Thu, Sep 03, 2020 at 06:34:38AM +0200, Bjorn Ketelaars wrote:
> > The diff below should fix this. At least I'm able to build a kernel
> > (amd64 only), which doesn't explode when actually using it.
>
> This is probably not
On Wed, Sep 02, 2020 at 04:41:49PM +0200, Klemens Nanni wrote:
> They way strides work is everything but intuitive and the manual doesn't
> really help; I've had multiple hackers/users ask me how to use them.
>
> `vcpu 8' assigns eight virtual CPUs to a domain.
>
> `vcpu 8:2' allocates eight
The Rx block ack session counter is not reset when an iwm/iwx interface
disassociates from the AP or is put down via ifconfig.
This can lead to new Rx block ack session being refused upon re-association.
Found by zxystd from the OpenIntelWireless project (drivers for macOS).
The firmware
On Sat, Aug 15, 2020 at 02:56:25PM +0200, Mark Kettenis wrote:
> This diff makes sdmmc(4) print ddr52 and hs200 capabilities, making it
> possible to see whether a controller supports these high-speed eMMC
> modes.
>
> ok?
ok stsp@
> Index: dev/sdmmc/sdmmc.c
>
On Tue, Aug 11, 2020 at 05:46:05PM -0500, Abel Abraham Camarillo Ojeda wrote:
> Hi to all,
>
> (unsure if this if for tech@ or misc@)
>
> I'm using wireguard interfaces but I see that no matter what
> domain I put the interface:
>
> # ifconfig wg0 rdomain X
>
> It always listens in rdomain 0
On Fri, Jul 17, 2020 at 12:50:04PM +0200, Holger Mikolon wrote:
> I came across this by reading the code if_iwn.c and DPRINTFs on
> a kernel with IWN_DEBUG.
>
> IWN_LSB() returns an index starting with 1, however the arrays used
> later on (noise and gain in iwn5000_set_gains()) start with 0. The
On Fri, Jul 17, 2020 at 03:59:38PM +0200, Stefan Sperling wrote:
> While measuring Tx performance at a fixed Tx rate with iwm(4) I observed
> unexpected dips in throughput measured by tcpbench. These dips coincided
> with one or more gap timeouts shown in 'netstat -W iwm0', such as:
&
While measuring Tx performance at a fixed Tx rate with iwm(4) I observed
unexpected dips in throughput measured by tcpbench. These dips coincided
with one or more gap timeouts shown in 'netstat -W iwm0', such as:
77 input block ack window gaps timed out
Which means lost frames on the
There's a logic bug in iwn(4) which means that automatic rate control
for A-MPDU runs while a fixed Tx MCS is configured with a command like
"ifconfig iwn0 media HT-MCS10 mode 11n".
The intention was of course the inverse: Use automatic rate control if
the Tx MCS is not fixed (i.e. if
Make iwn_ampdu_tx_done() record an ACK for the frame for which the hardware
triggered the Tx completion interrupt, instead of the frame with the starting
sequence number (SSN) of the firmware's block ack window. The frame at SSN
is unrelated and may not even have been transmitted yet.
ok?
diff
When a wifi interface acts as a client, ifconfig will currently display
the default value 'ccmp' for the wpagroupcipher parameter, even while
associated to a WPA2 access point which uses TKIP as the group cipher
for WPA1 compatibility.
This patch updates the variable which gets copied out when
This patch adds support for 11n Tx aggregation to iwm(4).
Please help with testing if you can by running the patch and using wifi
as usual. Nothing should change, except that Tx speed may potentially
improve. If you have time to run before/after performance measurements with
tcpbench or such,
On Mon, Jun 22, 2020 at 12:37:03PM +0200, Hrvoje Popovski wrote:
> for some reason i couldn't reproduce panic if i compile kernel with
> WITNESS and after that with or without your "if.c if_wg.c" commit
The bug might not trigger if your ifconfig binary and kernel out of sync.
But that's just
Fix length specification for 2GHz band information element (IE) data in
the iwx(4) probe request template. The value that was being written
previously is too short so some IEs weren't included in the probe
request frame.
The active scanning code path is currently disabled in-tree, so this
fixes a
Do not copy an SSID into the probe request template because hardware
will add the SSID by itself.
I have verified that probe requests transmitted by the device still
look good and contain the SSID configured by ifconfig.
Note that the in-tree driver does not send probe requests right now
because
This fixes a wrong unconditional write to a field of the scan command.
The scan command struct is a hell of a union of structs which represent
different versions of the scan command. This coding style makes it easy to
write to a wrong offset by accident. I intend to eventually clean this up
but
iwx(4) hardware can monitor device temperature and notify the driver when
a critical temperature has been reached.
This patch enables the mechanism. The driver will now turn the device off
and print a message to dmesg if the firmware signals critical temperature.
Comments in Linux source code
This patch implements WPA2 (CCMP) crypto offload for iwx(4).
The patch will only work on top of an up-to-date tree. Note that I just
committed another patch (Tx rate selection offload) to CVS which is
required in order to test this CCMP offload patch.
ok?
diff
Intel has moved Tx rate selection code from the Linux iwlwifi driver into
ax200 device firmware. There is code in iwlwifi/mvm/rs.c which should more
or less match what the firmware is doing, given how the firmware API works.
Equivalent functionality is offered by AMRR/MiRA in our kernel.
During
On Thu, Jun 11, 2020 at 11:00:30AM +0200, Mark Kettenis wrote:
> > Date: Thu, 11 Jun 2020 10:48:09 +0200
> > From: Stefan Sperling
> >
> > I spotted this while working on iwx(4).
> >
> > Setting up ic_myaddr when we're about to scan for APs is rather lat
I spotted this while working on iwx(4).
Setting up ic_myaddr when we're about to scan for APs is rather late in
the game. All these drivers are already setting up ic_myaddr during the
device initialization phase, long before they get here.
This seems to be a copy-paste error in iwn(4)
Increase iwx(4) firmware command queue size.
Otherwise, the firmware will eventually send spurious "command done"
notifications for commands which were completed successfully earlier
(which looks like a ring overflow) and then crash with a fatal error.
This is required to get -48 firmware to
Firmware loading code inherited from iwm(4) loads firmware twice:
Once to load the 'INIT' (boot) device firmware, and a second time
to load the RT (run-time) device firmware. Both of these firmware
images are part of the single firmware file in /etc/firmware.
With iwx(4) devices only a single
(This patch depends on the iwx NVM parser patch which I just sent
out previously. This patch won't apply otherwise.)
iwx(4) devices have a hardware component that can detect which country
it is running in. The firmware will then inform the driver about the
auto-detected regulatory domain.
The iwx(4) firmware offers a command which reads data stored in non-volative
memory of the device. Currently the driver still parses this data directly
with a parser inherited from iwm(4). Use the command instead, which matches
what Linux does on this hardware and is future-proof.
The old parser
On Fri, May 22, 2020 at 01:48:28PM -0400, sven falempin wrote:
> After a few days ... (free size too small 288 < 1024 /2 )
>
> Maybe this can help make the driver better.
>
> printf '%x\n' $((0x350+0xf7)) ; grep -A2 'if_iwx.c:515' /tmp/iwx.dis
> 447
> /usr/src/sys/dev/pci/if_iwx.c:515
>
When enabling Tx queues in iwx_enable_data_tx_queues() the driver computes
the Tx queue index as:
int qid = ac + IWX_DQA_AUX_QUEUE + 1;
with:
#define IWX_DQA_AUX_QUEUE 1
In iwx_tx(), we use a different way of computing the Tx queue index,
which is a leftover from
Going back over the full list of commands the Linux driver sends to an
ax200 device when it connects to an access point, I have noticed some
that are missing from our driver.
One of those is the SOC_CONFIGURATION command which provides some low-level
details about the hardware device to firmware.
The iwx(4) driver intends to disable bluetooth. The command we send to the
firmware says "wifi only", but also enables a bluetooth module. This seems
to work as intended but is ambiguous. Linux also leaves all modules disabled
in wifi-only mode. So do not enable any BT modules in the BT_COEX
When moving from AUTH state to INIT or SCAN state the iwx(4) driver
performs the following two steps:
1. Remove the formerly chosen access point from the firmware's station table
2. Flush firmware Tx queues
This order of operations was inherited from iwm(4) where it works fine.
But iwx(4)
The iwx(4) binding command can fail with 5 Ghz channels.
Some firmware versions don't expect LMAC_5G_INDEX in the binding command.
I have no idea what "CDB" stands for, but this check matches what the
Linux driver does and makes the command work on -48 firmware.
The Linux driver actually checks
I have started looking into updating iwx(4) to newer firmware.
This newer firmware is not working yet but I already have a few simple
changes which could be reviewed and committed. This is the first one:
Newer iwx(4) firmware versions will require a larger beacon filter command.
The extra fields
On Sun, May 17, 2020 at 04:45:44PM +0200, Matthias Schmidt wrote:
> I have your diff running since yesterday and noticed no regression.
>
> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
> iwm0: hw rev 0x230, fw ver 34.0.1
>
> Cheers
>
> Matthias
Great,
On Sat, May 16, 2020 at 05:41:43PM +0200, Stefan Sperling wrote:
> On Fri, May 15, 2020 at 05:02:28PM +0200, Stefan Sperling wrote:
> > This has been attempted before, but had to backed out because in some
> > cases firmware was failing to decrypt a subset of received frames, whi
On Fri, May 15, 2020 at 05:02:28PM +0200, Stefan Sperling wrote:
> This has been attempted before, but had to backed out because in some
> cases firmware was failing to decrypt a subset of received frames, which
> resulted in packet loss.
>
> That was before we updated all iwm(4) d
On Fri, May 15, 2020 at 02:21:48PM -0400, sven falempin wrote:
> OK Fri May 15 13:37:31 EDT 2020
> OK Fri May 15 13:38:10 EDT 2020
> OK Fri May 15 13:38:49 EDT 2020
> OK Fri May 15 13:39:28 EDT 2020
> OK Fri May 15 13:40:07 EDT 2020
> FAILED Fri May 15 13:40:50 EDT 2020
> OK Fri May 15 13:41:29
On Fri, May 15, 2020 at 11:11:44AM -0400, sven falempin wrote:
> Index: if_iwx.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 if_iwx.c
> --- if_iwx.c29 Apr 2020 13:13:30 -
This has been attempted before, but had to backed out because in some
cases firmware was failing to decrypt a subset of received frames, which
resulted in packet loss.
That was before we updated all iwm(4) devices to newer firmware in the
previous release cycle. I hope we won't see such problems
iwx(4) firmware understands two different variants of the "PHY_CONTEXT"
command. Both variants are documented with the same command API version
number, but they use different sizes for an embedded struct that contains
information about channels.
Which variant to use depends on whether the
On Fri, May 08, 2020 at 10:53:30AM +0200, Stefan Sperling wrote:
> So the diff below contains just the reordering fix for drivers using
> hardware acceleration for WPA.
Is there anybody who wants to OK this?
To recap:
Currently, CCMP replay checking is skipped for aggregated 11n
The capablities info field in an association request contains an ESS bit
which is set if the sender is an access point (there are other cases but
they don't matter for us; see 802.11-2012 8.4.1.4 if you are interested).
This bit is set when OpenBSD clients send an association request to an AP.
On Wed, May 13, 2020 at 07:55:02PM -0400, sven falempin wrote:
> 'good news'
>
> I build a custom kernel with the DEBUG flag for the driver
> I 'works' ,
This means that the driver is doing something too fast on your hardware,
and some miscommunication happens with the card as a result.
One
On Sun, May 10, 2020 at 04:17:46PM -0400, sven falempin wrote:
> On Sun, May 10, 2020 at 4:51 AM Stefan Sperling wrote:
>
> > On Sat, May 09, 2020 at 04:23:08PM -0400, sven falempin wrote:
> > > "no config, interface is down", Did not do anything special,
>
On Sat, May 09, 2020 at 04:23:08PM -0400, sven falempin wrote:
> "no config, interface is down", Did not do anything special,
> upgrade => Plug card => boot => crash
> I tested with the intel firmware it does the same.
I'm sorry, but there is really not enough information in your messages
that
On Fri, May 08, 2020 at 11:51:50AM -0400, sven falempin wrote:
> I upgraded to 6.7 - beta a tftp server i use
>
> Not much to report as the device is basic but i wanted to test some wifi on
> it.
>
> iwx0 at pci8 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix
>
> The firmware crashes at
On Fri, May 01, 2020 at 06:05:47PM +0200, Stefan Sperling wrote:
> The following diff moves the Packet Number check out of affected drivers
> into ieee80211_inputm() so the check can be performed after frames have
> been re-ordered.
Here is a new version of this diff.
I realized I made
For some reason, changes I made to iwn(4) in the commit quoted below
have caused connections to get stuck on some APs during Tx bursts.
This does not occur with every type of AP. It was observed on an Apple
Airport Extreme 6th gen, and on a b-box 3V+ (Sagemcom Mac address).
The patch below
On Fri, May 01, 2020 at 08:06:05PM +, Kevin Chadwick wrote:
> On 2020-05-01 16:05, Stefan Sperling wrote:
> > The CCMP header contains a nonce,
> > which is incremented by the transmitter whenever it encrypts a new frame.
>
> I assume there isn't opportunity to set t
This diff needs testing in particular on: athn(4), iwn(4), wpi(4)
I have tested on iwn(4) and athn(4) so far.
Testing with other drivers would be good, too, to ensure that no
regressions are introduced for the software crypto case.
Drivers which offload CCMP decryption to hardware contain a check
I have seen a kernel panic with iwn(4) due to a divide by zero on
this line in ieee80211_mira.c's ieee80211_mira_update_stats():
sfer /= (mn->txfail + 1) * mn->frames;
We ended up in mira_choose() via iwn_rx_compressed_ba().
The following patch prevents the problem.
ok?
diff
We currently do not support 11n mode on devices which do not have all
antenna ports connected. So if e.g. an athn(4) card is installed into
an APU or Alix, we require that users plug pigtails into all antenna
connectors on the card, and mount a corresponding number of antennas
on the case. Given
Anyone?
On Wed, Apr 22, 2020 at 07:28:02PM +0200, Stefan Sperling wrote:
> We currently configure interrupt mitigation for Rx, but not for Tx.
>
> And there is also a global Tx/Rx interrupt limit which can be configured
> via the MIRT register. Setting this could prevent Tx/Rx inte
On Fri, Apr 24, 2020 at 03:31:12PM +0200, Stefan Sperling wrote:
> On Wed, Apr 22, 2020 at 07:37:10PM +0200, Stefan Sperling wrote:
> > This makes athn(4) offload CCMP encryption and decryption to hardware.
> > CCMP is used with WPA2, so this reduces CPU load on WPA
On Wed, Apr 22, 2020 at 07:37:10PM +0200, Stefan Sperling wrote:
> This makes athn(4) offload CCMP encryption and decryption to hardware.
> CCMP is used with WPA2, so this reduces CPU load on WPA2 networks only.
>
> The WPA1 (TKIP) and WEP ciphers remain in software because thi
I have observed a uvm fault in ieee80211_mira_probe_timeout_up() while
testing with iwm(4) and tcpbench:
void
ieee80211_mira_probe_timeout_up(void *arg)
{
struct ieee80211_mira_node *mn = arg;
int s;
s = splnet();
This makes athn(4) offload CCMP encryption and decryption to hardware.
CCMP is used with WPA2, so this reduces CPU load on WPA2 networks only.
The WPA1 (TKIP) and WEP ciphers remain in software because this simplifies
the driver. TKIP in particular is a annoying to deal with on this hardware.
Old
We currently configure interrupt mitigation for Rx, but not for Tx.
And there is also a global Tx/Rx interrupt limit which can be configured
via the MIRT register. Setting this could prevent Tx/Rx interrupt storms.
This change doesn't really buy us anything during regular use of the
device, but
On Sun, Apr 19, 2020 at 03:00:59PM -0600, Theo de Raadt wrote:
> % man -k sdio
> amlmmc(4) - Amlogic MMC/SD/SDIO controller
> dwmmc(4) - Synopsis DesignWare MMC/SD/SDIO controller
> ommmc(4/armv7) - MMC/SD/SDIO controller
>
>
> Oh, so it only works on those 3 controllers?
Fine. I'll commit my
On Sun, Apr 19, 2020 at 10:46:28PM +0200, Mark Kettenis wrote:
> > Date: Sun, 19 Apr 2020 22:24:31 +0200
> > From: Stefan Sperling
> >
> > We really should be documenting supported wifi chipsets to help users
> > find devices that will work with OpenBSD.
&
We really should be documenting supported wifi chipsets to help users
find devices that will work with OpenBSD.
The bwfm(4) man page leaves such questions entirely open at present.
The diff below intends to fill that gap by adding table which lists
supported devices. The table includes chipset
On Fri, Apr 17, 2020 at 06:30:22PM +0200, Stefan Sperling wrote:
> On Fri, Apr 17, 2020 at 04:03:30PM +0200, Stefan Sperling wrote:
> > In particular, this fixes wrong assumptions about what the data in the
> > firmware's "compressed block ack" notifications
On Fri, Apr 17, 2020 at 04:03:30PM +0200, Stefan Sperling wrote:
> In particular, this fixes wrong assumptions about what the data in the
> firmware's "compressed block ack" notifications is supposed to represent,
> and actually pieces information about individual subframes of
On Fri, Apr 17, 2020 at 03:05:06PM +0200, Ingo Schwarze wrote:
> Naively, it does seem like it would make sense to have "locale -m"
> print a list of possible output values of "locale chardef", so i'm
> not opposed to adding "US-ASCII" to it. But that doesn't appear to
> be how it works
This applies on top of a previous diff I sent, the one to make use of
the entire firmware retry table.
Recently I have spent a good amount of time trying to reverse-engineer
the sparsely documented behaviour of both iwn(4) and iwm(4) firmware with
respect to Tx aggregation. For details, see my
This adapts the use of the firmware multi-rate retry table to always
make use of all available slots.
The table specifies 16 Tx rates the firmware can use, one per Tx attempt.
For example, on a 5 GHz channel the current code fills this table with
static values like this:
MCS-7 MCS-6 MCS-5
1 - 100 of 1238 matches
Mail list logo
