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 wh
pass 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
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 -cC
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
s;
- data->txrate = ni->ni_txrate;
data->ampdu_txmcs = ni->ni_txmcs; /* updated upon Tx interrupt */
DPRINTFN(4, ("sending data: qid=%d idx=%d len=%d nsegs=%d\n",
@@ -5649,7 +5592,7 @@ iwn_run(struct iwn_softc *sc)
sc->calib_cnt = 0;
timeout_add_msec(&s
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
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 reco
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
> diffe
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 do
cmd->ac[ucode_ac].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
&g
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 c6a6a64b49f2287751632
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
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.
>
> Repo
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
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 s
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 c
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 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 ha
On Sat, Jul 16, 2022 at 08:26:49AM +0200, Stefan Hagen wrote:
> Hi,
>
> This is a workaround taken from Linux to mitigate sporadic cursor jumps
> due to a firmware bug. Known affected laptops are:
>
> - Lenovo Thinkpad X13 Gen1 (AMD version)
> - Lenovo Thinkpad T14s (AMD version)
> - Lenovo A475
On Mon, Aug 01, 2022 at 03:38:59PM +0200, Omar Polo wrote:
> there's an edge case in locate_hunk with empty files; if `first_guess'
> is zero then main() assumes that locate_hunk has failed and aborts the
> patch operation. Instead, make sure to return 1 (the line number) so
> that the patch opera
On Mon, Aug 01, 2022 at 12:48:16PM +0200, Omar Polo wrote:
> i was looking for a different issue in patch when i found this.
> patch(1) fails to recognize the reversal application of a patch that
> creates a file (this is test t3).
>
> since an empty context always matches, the idea is to run the
This adds support for booting from RAID 1C volumes on amd64.
Only boot-loader changes are needed. Both installboot(8) and
the kernel already do what is required to make this work.
I have tested with biosboot in vmm. The changes involved are trivial,
and I am modifying copies of the same code acros
On Fri, Aug 12, 2022 at 02:28:30PM +0200, Erling Westenvik wrote:
> On Thu, Aug 04, 2022 at 07:26:23PM +0200, Stefan Sperling wrote:
> > This adds support for booting from RAID 1C volumes on amd64.
>
> This is so cool and I can't wait to get a chance to try it out!
>
>
On Fri, Aug 12, 2022 at 03:20:40PM +0200, Stefan Sperling wrote:
> I am currently trying to find time in order to test my patch on
> real hardware. Any additional testing would be very welcome.
I found time :)
Tested on real hardware with 4 disks.
Both biosboot and UEFI boot are work
On Fri, Aug 12, 2022 at 07:28:57PM +0200, Stefan Sperling wrote:
> On Fri, Aug 12, 2022 at 03:20:40PM +0200, Stefan Sperling wrote:
> > I am currently trying to find time in order to test my patch on
> > real hardware. Any additional testing would be very welcome.
>
> I foun
On Thu, Aug 11, 2022 at 03:51:17PM +, Klemens Nanni wrote:
> Booting off softraid on arm64 is supported but installboot(8) has no
> softraid(4) support on arm64.
>
> This means installboot always copies the single bootstrap efiboot on the
> root volume and completely ignores softraid chunks, s
On Fri, Aug 12, 2022 at 09:41:59AM +, Klemens Nanni wrote:
> Here's the adapted diff for arm64 minus manual bits to avoid churn for
> now.
>
> installboot(8) needs softraid(4) support (see my diff on tech@), but
> besides that, root on passphrase 1C softraid on arm64 works as expected:
>
>
Use raid1c-specific meta-data while looking for a key disk that
belongs to a RAID 1C volume.
By dumb luck this is only a cosmetic issue, because struct layout
happens to put the field in the same place.
ok?
diff a87e94ce1617958c99b63ed0a056e46650a27375
ba39970f6365aeeb1b486101f6573c60b7f88573
On Thu, Sep 01, 2022 at 08:31:04PM +, Klemens Nanni wrote:
> This is practically the same diff we already landed for arm64.
>
> The kernel already supports booting off 1C and with tech@'s
> "installboot: sparc64: fix -r on multi-chunk softraid chunk" diff the
> install process will no longer f
On Fri, Oct 21, 2022 at 06:46:14PM +0100, Jason McIntyre wrote:
> pluggable?
It really is a very machine-specific question. It depends
on how the manufaturer decided to connect devices to the
mainboard, which is not always possible to tell from the
perspective of software which runs on the machine
On Tue, Jun 27, 2023 at 10:55:04AM +0200, Reyk Floeter wrote:
> Hi,
>
> the following diff adds the Intel Wi-Fi 6 0x51f1 device, found in a
> new Thinkpad X1 Carbon Gen 11.
>
> iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX211" rev 0x01, msix
> iwx0: hw rev 0x370, fw 77.f92b5fed.0, pnvm e4a4953
On Fri, Jul 07, 2023 at 12:26:16PM +0200, Tobias Heider wrote:
> For bigger changesets I have started experimenting with using got.
> I don't like to have the whole tree on disk twice so I keep my got and CVS
> checkouts in the same directory.
Curious. I am not sure how well that will work in prac
On Fri, Jul 14, 2023 at 02:45:09PM +0800, Kevin Lo wrote:
> In rtwn_tx(), check if the OWN bit of Tx instead of Rx is set.
> Luckily, definitions of R92C_TXDW0_OWN and R92C_RXDW0_OWN are the same.
>
> ok?
ok stsp
> Index: sys/dev/pci/if_rtwn.c
> ==
When I updated iwx to -77 firmware I made a mistake in setting up
the new version of the scan command, in the particular case of
starting a background scan.
One part of the command says that active scan should be used.
"Active scan" means the device will send probe requests containing a
desired SS
On Wed, Aug 30, 2023 at 11:07:17PM +, Peter Stuge wrote:
> Stefan Sperling wrote:
> > "Active scan" means the device will send probe requests containing a
> > desired SSID, soliciting immediate probe responses from APs which
> > announce the desired SSID.
>
On Sat, Sep 02, 2023 at 12:59:51PM +0200, Peter Hessler wrote:
> I just upgraded to -current and didn't have this patch in for a little
> bit, and woof that was super noticable. Still works for my big VM host.
>
> OK
No issues here either with just one VM running for testing some
software, so mo
On Thu, Sep 21, 2023 at 01:25:01PM +0200, Walter Alejandro Iglesias wrote:
> I corrected many of the things you pointed me, but not all. The
> function I use to check utf8 is mine, I use it in a pair of little
> programs which I've *hardly* checked for memory leacks. I know my
> function looks BI
On Sun, Sep 24, 2023 at 07:06:35AM +0200, Walter Alejandro Iglesias wrote:
> Hi Ingo,
>
> On Thu, Sep 21, 2023 at 03:04:24PM +0200, Ingo Schwarze wrote:
> > In general, the tool for checking the validity of UTF-8 strings
> > is a simple loop around mblen(3) if you want to report the precise
> > po
ixl
+# Intel Elkhart Lake Ethernet
+attach dwqe at pci with dwqe_pci
+file dev/pci/if_dwqe_pci.c dwqe_pci
+
# Neterion Xframe 10 Gigabit ethernet
device xge: ether, ifnet, ifmedia
attach xge at pci
blob - /dev/null
blob + 101b5670451611858f70b95a1082442b47056600 (mode
On Tue, Oct 10, 2023 at 08:41:37PM +0200, Mark Kettenis wrote:
> So the GMAC_VERSION #define is simply wrong. We should commit the
> diff attached and drop the sc_core stuff you added below.
That means all our supported chips are GMAC4 and later? Good to know.
> > + switch (PCI_PRODUCT(pa->pa
On Tue, Oct 10, 2023 at 11:41:39PM +0200, Mark Kettenis wrote:
> The firmware for the BCM4388 has yet another version of the "escan"
> command. But we can treat it the same as v2 since it just added a new
> parameter in place of some padding. We just set that new parameter to
> zero, which doesn'
v/pci/if_dwqe_pci.c dwqe_pci
+
# Neterion Xframe 10 Gigabit ethernet
device xge: ether, ifnet, ifmedia
attach xge at pci
blob - /dev/null
blob + d157f116c025d882f1ec8df84b4c3deca3ca340f (mode 644)
--- /dev/null
+++ sys/dev/pci/if_dwqe_pci.c
@@ -0,0 +1,154 @@
+/* $OpenBSD$ */
+
+/*
+ * Co
On Wed, Oct 11, 2023 at 10:27:24AM +0200, Stefan Sperling wrote:
> On Tue, Oct 10, 2023 at 09:06:59PM +0200, Mark Kettenis wrote:
> > > OK for your diff. Please put it in and I'll rebase on top.
> >
> > done
>
> Thanks. Here is a rebased version. Re-tested
On Wed, Oct 11, 2023 at 02:05:52PM +0200, Stefan Sperling wrote:
> Anyway, here is an eephy(4) diff to enable/disable delays on the 88E1512.
That diff wasn't quite right. The register offset should be 0x21,
and Linux configures delays every time after link auto-negotiation.
I am still u
Long story short: If you can test the diff below on iwn(4) (n, not m),
on a WPA2 network in 11n mode, then please do.
QoS wifi frames are generally used for two different things:
traffic prioritization, and A-MPDU frame aggregation.
Actual QoS is all about traffic prioritization, e.g. for lower
802.11 frame sequence numbers are in the range 0x0 - 0xfff.
Don't let internal representations of sequence numbers grow beyond 0xfff.
ok?
diff 582540bcd55abf4efa3abe8c23ebc7f3c247245d
ba499e0f51b139f9ad6d4b4ea18cbf56bd93
blob - 808b6e1f46b777ea408561c0fbf511e79d477c54
blob + 6c8057426973640
On Mon, Mar 16, 2020 at 09:29:43AM +0100, Jasper Lievisse Adriaanse wrote:
> Hi,
>
> The type of brightness and video_output is uint32_t; therefore it
> can never be less than 0 (which is what HCI_LCD_BRIGHTNESS_MIN and
> HCI_VIDEO_OUTPUT_CYCLE_MIN are defined to). So trim the checks by
> removig
On Thu, Mar 26, 2020 at 01:03:26AM +0100, Tobias Heider wrote:
> sr_block_get() returns dma_alloc(length, PR_NOWAIT | PR_ZERO) which may be
> NULL if the memory pool is depleted.
> The result is used as 'dst' argument to memcpy() in the following call to
> sr_raid5_regenerate(), resulting in a poss
I noticed that iwm's firmware skips MIMO rates on Tx and sends frames
at the lowest fallback rate instead.
This is not visible in ifconfig or even net80211. Everything there
indicates that we were using some MCS >= 8 and all was good.
But tcpbench is much slower than it should be, and monitor mod
The "link quality" (LQ) command for iwm firmware is used to tell the
firmware about our Tx rate selection decisions, among other things.
The driver currently avoids sending this command directly from interrupt
context. Instead it schedules a task which will send the command.
The driver usually de
While working on iwm Tx aggregation and revisiting some parts of MiRA,
I have noticed a rate-control problem in iwm and iwx (this also affects
iwn, but I am leaving that for later since iwn already does Tx aggregation
and requires a more elaborate fix).
Rate control algorithms will choose a Tx rat
On Thu, Apr 02, 2020 at 03:52:11PM +0200, Stefan Sperling wrote:
> While working on iwm Tx aggregation and revisiting some parts of MiRA,
> I have noticed a rate-control problem in iwm and iwx (this also affects
> iwn, but I am leaving that for later since iwn already does Tx aggregat
On Mon, Apr 06, 2020 at 05:02:00PM +0200, Stefan Sperling wrote:
> On Thu, Apr 02, 2020 at 03:52:11PM +0200, Stefan Sperling wrote:
> > While working on iwm Tx aggregation and revisiting some parts of MiRA,
> > I have noticed a rate-control problem in iwm and iwx (this also affects
On Mon, Apr 06, 2020 at 02:03:36PM -0500, Scott Cheloha wrote:
> Ticks to seconds. Trivial.
>
> ok?
ok stsp@
> Index: if_wi.c
> ===
> RCS file: /cvs/src/sys/dev/ic/if_wi.c,v
> retrieving revision 1.171
> diff -u -p -r1.171 if_wi.c
I've noticed that wireless interfaces in 11n mode show a "media:" line
in ifconfig such as this while a background scan is in progress:
media: IEEE802.11 autoselect (OFDM6)
What is expected is a line showing active 11n mode, such as:
media: IEEE802.11 autoselect (HT-MCS0 mode 11n)
This happen
On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote:
> > The idea was to have /var/www/tmp created by default, but with
> > www:www ownership.
> Create the directory. Now as a user, completely fill it.
The proposal is to create tmp with www:www ownership, writable only for
that user,
On Tue, Apr 07, 2020 at 09:51:15AM -0600, Theo de Raadt wrote:
> Stefan Sperling wrote:
>
> > On Tue, Apr 07, 2020 at 09:37:02AM -0600, Theo de Raadt wrote:
> > > > The idea was to have /var/www/tmp created by default, but with
> > > > www:www ownership.
>
On Tue, Apr 07, 2020 at 05:05:08PM +0100, Stuart Henderson wrote:
> On 2020/04/07 18:01, Stefan Sperling wrote:
> > Yes, absolutely correct. Logs or tempfiles filling up /var are a problem,
> > and in the gotweb application Tracey and I created it is indeed possible
> > fo
On Tue, Apr 07, 2020 at 06:13:12PM +0200, Stefan Sperling wrote:
> For temp stuff we really need a separate space that can just be wiped
> without consequences when it has run full.
The way Got internally provides access to files in /tmp for every helper
process is to pass one or more ope
This seems to be a more accurate interpretation of the MiRA paper (a link
to paper can be found at the top of the ieee80211_mira.h header file).
I see a slight stabilization of Tx throughput with the change.
MiRA's rate probe interval is computed based on the number of frames sent,
and perhaps los
This diff skips MiRA's event-based probing trigger if we're already
at the minimum or maximum rate of our current rateset.
As of this commit on March 5:
https://marc.info/?l=openbsd-cvs&m=158340898502913&w=2
if we're beginning a probe because of a throughput measurement change event
we cancel the
Since my recent commit to fix Tx reporting in iwn(4) I have observed a
continously rising CCMP decryption error counter in 'netstat -W athn0'
while running tcpbench from iwn(4) towards an athn(4) hostap.
Eventually iwn(4) will send a frame which pushes the CCMP packet number
(a nonce used to detec
This change affects MIMO-capable drivers: iwm(4), iwx(4), and athn(4)
Prevent MiRA from jumping from very high to very low rates while
switching ratesets when probing.
MiRA does multi-phase probing where it first probes within the current
rateset (e.g. MCS 8-15 aka MIMO2) and then switches to ano
On Thu, Apr 16, 2020 at 09:35:18PM +0200, Ingo Schwarze wrote:
>$ locale -m
> UTF-8
>$ locale charmap
> UTF-8
>$ LC_ALL=C locale charmap
> US-ASCII
>$ LC_ALL=POSIX locale charmap
> US-ASCII
I am OK with your diff, and noticed a separate issue with -m which
is exposed by thi
Make iwn(4) put the correct traffic identifier (TID) into the Tx command
when sending block ack request (BAR) frames.
This is not critical but occasionally I have seen the firmware send a
BAR frame with a bogus TID value, which the receiver will simply discard.
Writing the correct TID into the Tx
This diff works around FIFO_UNDERRUN (0x84) Tx errors being reported
by iwn(4) firmware. When this error occurs, it tends to occur multiple
times in a row. Affected frames are lost and never get transmitted, and
traffic stalls for a while. This affects tcpbench very visibly.
I don't understand wha
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 MCS-4
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 com
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 elsewhere,
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 subframe
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 is
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 nam
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.
> &
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 fi
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 d
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
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();
mn->probe_timer_expired[IEEE80211_MIRA_PROBE_TO_UP]
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 this simp
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 WPA2 networks onl
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
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 ha
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 618f51c546
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
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
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 revert
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
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 s
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 wo
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 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 way
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.
Thi
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 fra
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 firmware
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 a
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 -
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 EDT
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 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, which
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, tha
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 f
1 - 100 of 1524 matches
Mail list logo
