At present active scans (which send probe requests, as opposed to
just listening for beacons) are disabled on iwm 9k and iwx. This
was done because firmware misbehaved after association.
zxystd from the OpenIntelWireless project has debugged the issue
and has sent me a patch against OpenBSD which
On Wed, Jan 12, 2022 at 11:30:44AM +0100, Moritz Buhl wrote:
> Hi tech@,
>
> https://github.com/openbsd/src/commit/0ea6bae06233cd25645df14602c3eda6bdff7dca.patch
>
> the patch forgot to add mrep to the info struct, nfsm_dissect could
> pass info.nmi_mrep to m_freem, which is currently
On Mon, Jan 10, 2022 at 04:35:41PM +0100, Tobias Heider wrote:
> On Mon, Jan 10, 2022 at 04:20:36PM +0100, Stefan Sperling wrote:
> > On Mon, Jan 10, 2022 at 03:50:45PM +0100, Tobias Heider wrote:
> > > Makes sense. I also fixed the one in sdmmc_mem_send_cxd_data().
> >
On Mon, Jan 10, 2022 at 03:50:45PM +0100, Tobias Heider wrote:
> Makes sense. I also fixed the one in sdmmc_mem_send_cxd_data().
Doesn't build here, there a few errors like this:
/usr/src/sys/dev/sdmmc/sdmmc_mem.c:483:1: error: unused label 'out' [-Werror,-Wu
nused-label]
I like Visa's idea of
On Mon, Jan 10, 2022 at 01:12:10PM +0100, Tobias Heider wrote:
> sdmmc_mem_send_scr() tries to malloc() with M_NOWAIT and returns 0 on
> error, which leads to sdmmc_mem_sd_init() passing uninitialized stack
> memory to sdmmc_mem_decode_scr().
> The diff below makes sdmmc_mem_send_scr() return
Ping. I have had zero feedback on this so far. Anyone?
On Tue, Jan 04, 2022 at 02:35:52PM +0100, Stefan Sperling wrote:
> The function ieee80211_find_node_for_beacon() was added by reyk on 2005.
> At the time, net80211 nodes were stored in a hash table keyed on hashes
> the node's s
On Sun, Jan 09, 2022 at 05:32:21PM +, Iraklis Karagkiozoglou wrote:
> Hi,
>
> I've added support for AX201 with subsystem id 0x0030 in if_iwx.
>
> I am only loading a different firmware for the specific subsystem id to
> avoid introducing any regressions or bugs.
We are receiving more and
The function ieee80211_find_node_for_beacon() was added by reyk on 2005.
At the time, net80211 nodes were stored in a hash table keyed on hashes
the node's source MAC addresses.
The purpose of ieee80211_find_node_for_beacon() was to avoid storing
duplicate nodes with the same source MAC address in
On Mon, Jan 03, 2022 at 10:19:59PM +1100, Jonathan Gray wrote:
> there are snapshots of some of it on archive.org
> https://web.archive.org/web/20080624074509/http://islsm.org/wiki/doku.php?id=
Unfortunately, the interesting bits, such as archive.org links to
the actual hardware docs on this
On Mon, Jan 03, 2022 at 11:55:08AM +0100, Marcus MERIGHI wrote:
> Hello!
>
> s...@stsp.name (Stefan Sperling), 2022.01.03 (Mon) 11:37 (CET):
> > On Mon, Jan 03, 2022 at 12:20:37PM +1100, Jonathan Gray wrote:
> > > the prism54.org domain is long abandoned
> > >
On Mon, Jan 03, 2022 at 12:20:37PM +1100, Jonathan Gray wrote:
> the prism54.org domain is long abandoned
> don't give any traffic to whoever registered it afterwards
>
ok stsp@
A quick web search suggests that no efforts were made to save the
original content of the site :(
> Index:
On Sun, Dec 05, 2021 at 02:03:29PM +, Mikolaj Kucharski wrote:
> Hi Stefan,
>
> I'm not yet ready to test new diffs, but I was going through old
> wireless stack related emails and was wondering did below patch got
> committed? Per my git / cvs search I don't think so. Is below diff
> still
On Tue, Nov 30, 2021 at 02:31:20PM -0500, Noah Meier wrote:
> Hi Stefan,
>
> Richard Procter offered some kind advice on the ordering of options in the
> man page
> (to be done alphabetically) and commented on an unnecessary cast.
>
> I also believe that I goofed by failing to initalize the
On Wed, Oct 20, 2021 at 10:20:09PM -0400, Noah Meier wrote:
> Hi,
>
> While wireguard interfaces can have a description set by ifconfig, wireguard
> peers currently cannot. I now have a lot of peers and descriptions of them in
> ifconfig would be helpful.
>
> This diff adds a 'wgdesc' option
On Sat, Nov 27, 2021 at 09:57:45AM -0600, Aaron Poffenberger wrote:
> I see two differences. Before the patch, before "deauth" I see "sending
> delba" but not after patching, and before "firmware has detected
> regulatory domain 'US'", but not after.
I decided to try not sending a DELBA because
This patch reworks the steps involved in roaming to a new access
point on iwm(4) and iwx(4) interfaces.
The current implementation suffers from race conditions which can
leave the interface in a state where it gets "stuck". I have seen
this happen on iwm(4) 9560 in particular, while testing the
This patch updates iwx(4) to new firmware images (API version -67).
Intel has published a related security advisory:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00509.html
Make sure to get a fresh kernel from -current sources and update
to iwx-firmware-20211101 with
The iwx(4) driver in -current now contains a workaround for Tx queues
which get stuck while other Tx queues keep working. This condition
now triggers a device timeout on iwx(4) rather than leaving interface
in a semi-operational state.
Here is a corresponding patch for iwm(4).
The Linux driver
On Mon, Nov 08, 2021 at 01:07:58PM +0100, Stefan Sperling wrote:
> The last_rx timestamp which controls timeout of an Rx block ack
> session is not updated when a frame is received.
> This can result in the session timing out too early.
>
> Not a huge deal because the AP will simpl
On Mon, Nov 08, 2021 at 10:59:55AM +0100, Stefan Sperling wrote:
> iwx(4) has an issue which occurs very occasionally for me (every couple
> of days or sometimes even weeks) where ssh(1) fails to connect until the
> interface is reset with ifconfig down/up.
>
> The initial pr
This tid variable is used as an array index and must thus be smaller
than MAX_TID_COUNT (which is 8).
The variable will be set to 8 if the AP wants us to use TID 8 for Rx agg,
which I've never seen happen in practice, though it is possible.
Our driver uses this value as an index into an array of
The iwx Tx ring array is one entry too short due to an off-by-one error.
Fortunately, this bug is harmless. The last Tx agg queue is never used
because ieee80211_classify() only returns TID values in the range 0 - 3.
And iterations over the txq array use nitems() to find the upper bound.
The
On Tue, Nov 09, 2021 at 02:23:09PM +0100, Stefan Sperling wrote:
> On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> > I have tested on a 6205 device. More tests are needed, especially on
> > the old 4965AGN generation because those chips require the driver to
On Tue, Nov 09, 2021 at 08:38:11PM +0100, Jan Stary wrote:
> On Nov 09 00:36:03, h...@stare.cz wrote:
> > As a naive test of speed, I am downloading a 100MB file
> > from a http server just behind the AP with
> > ftp -o /dev/null http://stare.cz/.tmp/file
> > An average of ten runs is 5.31 MB/s
On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> I have tested on a 6205 device. More tests are needed, especially on
> the old 4965AGN generation because those chips require the driver to
> do specific calibration work which newer chips perform in firmware.
> I
The last_rx timestamp which controls timeout of an Rx block ack
session is not updated when a frame is received.
This can result in the session timing out too early.
Not a huge deal because the AP will simply request a new session when
it has more data to send. And many APs do not even enable
The resume code path of iwx(4) was improved during the k2k21 hackathon.
This patch merges the corresponding changes to iwm(4), such that iwm(4)
resumes directly in DVACT_WAKEUP instead of using the init task.
Tested by me on an 8265 device.
ok?
diff 02c3ac519701a4fe198f8ee3de592b34a39ee6f7
iwx(4) has an issue which occurs very occasionally for me (every couple
of days or sometimes even weeks) where ssh(1) fails to connect until the
interface is reset with ifconfig down/up.
The initial protocol exchange with the SSH server succeeds, but as soon
as the client enters interactive state
On Wed, Nov 03, 2021 at 02:47:39PM +0100, Stefan Sperling wrote:
> If channel load is not a reliable indicator I would hope vendors are at
> least able to reliably count and report the number of associated stations?
Here is new patch which makes the following changes relative to the
pr
On Wed, Nov 03, 2021 at 04:03:08PM +0300, Sergey Ryazanov wrote:
> Hello Stefan,
>
> On Sun, Oct 31, 2021 at 9:25 PM Stefan Sperling wrote:
> > Some access points advertise BSS load information in beacons in
> > order to help clients make informed roaming decisions.
> &g
On Tue, Nov 02, 2021 at 05:26:17PM +, Klemens Nanni wrote:
> At least bwfm(4) does not support WEP:
>
> # ifconfig bwfm0 nwkey 12345
> ifconfig: SIOCS80211NWKEY: Operation not supported by device
> # echo $?
> 0
>
> ifconfig(8) must return non-zero in this
On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> This patch adds 802.11n 40MHz support to the iwn(4) driver.
>
> This driver supports many different devices. Please try to be precise
> about which device you have tested so I can maintain a record of our
> test
On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> To check whether your access point uses a 40MHz channel, run this command
> while associated to the access point:
> tcpdump -n -i iwm0 -v -y IEEE802_11_RADIO -s 4096 type mgt and subtype
> beacon
Oops, this should o
This patch adds 802.11n 40MHz support to the iwn(4) driver.
This driver supports many different devices. Please try to be precise
about which device you have tested so I can maintain a record of our
test coverage.
I have tested on a 6205 device. More tests are needed, especially on
the old
Some access points advertise BSS load information in beacons in
order to help clients make informed roaming decisions.
BSS load information includes the number of associated stations,
the channel utilization (this takes other networks on the same
channel into account), and current admission
This patch adds support for 40MHz channels to iwx(4).
Please sync your source tree before attempting to apply this patch.
I have committed some changes to this driver today which this patch
is based on.
Works for me on AX200/AX201. Does anyone else want to do a pre-commit test?
diff
On Fri, Oct 08, 2021 at 12:05:23PM +0200, Stefan Sperling wrote:
> This patch removes code which is only required for running with older
> firmware versions (older than -63). This will make it easier to add
> new features, such as 40MHz support. Some code removed here would
> ot
This patch removes code which is only required for running with older
firmware versions (older than -63). This will make it easier to add
new features, such as 40MHz support. Some code removed here would
otherwise need to be updated as well, which is pointless extra work.
I have tested on
Before roaming to another AP we should explicitly stop Rx BA sessions
by sending the appropriate 'ADD_STA' commands to firmware, in addition
to clearing Rx BA buffers. This is similar to a recent change in iwm(4).
See the iwm patch description for testing instructions:
This patch adds initial support for 40Mhz channels to the iwm driver.
There are a few changes in net80211 to support this feature in RA and
when parsing beacons. The work for net80211 is not yet complete but
more can be done incrementally later. What is missing in particular
is integration with
On Tue, Oct 05, 2021 at 02:19:57PM +0200, Stefan Sperling wrote:
> While debugging iwm roaming issues which are now fixed in -current,
> I noticed a small difference between our driver and the Linux driver:
>
> Set the assoc ID assigned by our AP when updating the firm
AUTH -> AUTH state transitions happen if the access point uses band-steering.
This was originally implemented to fix interop with some Aruba APs.
A recent commit I made to iwm/iwx drivers probably broke this.
Here is a fix.
ok?
diff b1c80baf1b7d4bf6f528498fe67f3d1db4353371 /usr/src
blob -
When roaming between APs, all data in struct net80211_node is replaced
as soon as we have decided to switch to a different AP.
This means that the BSSID of our old AP is no longer stored in ic_bss
once we enter iwm_newstate(). We do however use this address in firmware
commands while tearing
Send a probe request to our new AP when we are about to roam to it.
When the code modified below runs, we have just replaced ic_bss (ni)
with our new AP a few lines above.
Sending a probe request isn't strictly required but it might help to
initialize state in our AP in case our background scan
Make sure to use HT for data frames only in case our Tx rate is fixed.
Non-data frames are not supposed to use HT.
This change applies if the Tx rate has been fixed for testing purposes
with a command such as 'ifconfig iwm0 media HT-MCS13 mode 11n'.
I've only found this by code inspection, not
While debugging iwm roaming issues which are now fixed in -current,
I noticed a small difference between our driver and the Linux driver:
Set the assoc ID assigned by our AP when updating the firmware station
with the ADD_STA command. Not sure if this strictly required but it
doesn't seem to
On Mon, Oct 04, 2021 at 10:45:06AM +0200, Florian Obser wrote:
>
> This works as advertised on:
>
> iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29,
> msix
> iwm0: hw rev 0x320, fw ver 46.6b541b68.0, address 40:74:e0:38:11:11
>
> and
>
> iwm0 at pci2 dev 0 function 0
On Sat, Sep 25, 2021 at 08:26:06PM +0200, Solene Rapenne wrote:
> +void
> +setperf_powersaving(void *v)
> +{
> + static uint64_t *idleticks, *totalticks;
[...]
> +
> + if (!idleticks)
> + if (!(idleticks = mallocarray(ncpusfound, sizeof(*idleticks),
> +
While working on 40MHz support for iwm(4) I noticed that throughput
dropped from 200 Mbit/s to about 2 Mbit/s whenever the laptop roamed
between APs. Sometimes traffic even stalled completely.
The patch below fixes this problem for me.
I used an 8265 device to reproduce the problem and test my
On Sun, Oct 03, 2021 at 09:28:30PM +0200, Mark Kettenis wrote:
> Apparently some athn(4) variants are buggy and may hand us corrupted
> packets. Linux has some workarounds for this and the diff below is a
> (partial) addaptation of those workarounds. It seems the idea is that
> the error bits in
On Tue, Sep 14, 2021 at 09:12:52PM +0200, Stefan Hagen wrote:
> I'm running with this since you posted it. No issues so far.
Thank you!
Some people are seeing occasional hangs. It's been observed that
systat reports no interrupts on iwx0 when this happens. I know that
the Linux driver has
On Sat, Sep 11, 2021 at 02:04:32PM +0200, Stefan Sperling wrote:
> On Fri, Sep 10, 2021 at 06:49:49PM +0200, Stefan Sperling wrote:
> > Here is another attempt at adding Tx aggregation to iwx(4).
> > This patch is based on the latest state in CVS (if_iwx.c r1.107, which
>
On Sat, Sep 11, 2021 at 04:29:58PM +0200, Stefan Hagen wrote:
> Sep 11 15:52:39 x13 /bsd: iwx0: associated with e6:63:da:7e:f8:24 ssid
> "DiscMate" channel 36 start MCS 0 long preamble short slot time HT enabled
> Sep 11 15:52:39 x13 /bsd: iwx0: missed beacon threshold set to 30 beacons,
>
On Fri, Sep 10, 2021 at 06:49:49PM +0200, Stefan Sperling wrote:
> Here is another attempt at adding Tx aggregation to iwx(4).
> This patch is based on the latest state in CVS (if_iwx.c r1.107, which
> I have committed a minute ago). Sync your tree before applying this patch.
>
Here is another attempt at adding Tx aggregation to iwx(4).
This patch is based on the latest state in CVS (if_iwx.c r1.107, which
I have committed a minute ago). Sync your tree before applying this patch.
Compared to previous iterations of this patch, I have fixed bugs which
caused fatal
On Fri, Sep 10, 2021 at 10:59:25AM +0200, Stefan Sperling wrote:
> On Fri, Sep 10, 2021 at 10:58:47AM +0200, Stefan Sperling wrote:
> > All those changes are shown below. My device is still happy with this.
> > I will reply with a new full diff against -current next.
>
> Full
On Fri, Sep 10, 2021 at 10:58:47AM +0200, Stefan Sperling wrote:
> All those changes are shown below. My device is still happy with this.
> I will reply with a new full diff against -current next.
Full diff:
diff c9db663b670f8930f62c8f20c36e84d72697f036 refs/heads/iwx-resume
On Thu, Sep 09, 2021 at 03:15:07PM -0700, Mike Larkin wrote:
> On Wed, Sep 08, 2021 at 03:25:20PM +0200, Stefan Sperling wrote:
> > On Wed, Sep 08, 2021 at 02:19:00PM +0200, Stefan Sperling wrote:
> > > This patch applies on top of all the other iwx(4) diffs I've sent today.
&g
On Wed, Sep 08, 2021 at 02:19:00PM +0200, Stefan Sperling wrote:
> This patch applies on top of all the other iwx(4) diffs I've sent today.
> It makes iwx(4) initialize the device completely in the acpi thread.
>
> We now prepare the device for loading firmware during DVACT_RESUME
This patch applies on top of all the other iwx(4) diffs I've sent today.
It makes iwx(4) initialize the device completely in the acpi thread.
We now prepare the device for loading firmware during DVACT_RESUME,
and load firmware from host memory into the device during DVACT_WAKEUP.
Previously,
Add a missing call to iwx_ctxt_info_free_fw_img() in an error path
of iwx_ctxt_info_init() which should always free on error.
Also, free firmware paging DMA memory in case loading firmware has failed.
If we don't free paging on error we hit KASSERT(dram->paging == NULL)
in iwx_init_fw_sec() once
On Wed, Sep 08, 2021 at 11:45:25AM +0200, Stefan Sperling wrote:
> I will fix the splnet() issue separately later.
And here is the patch for missing splnet() while loading firmware.
ok?
diff 5ebc9004f07f27c14bbae5eb2e8cab3d8cf3446d
a34aaba3c6977adc3012688a6d24ef6d0499df07
b
With 'ifconfig debug' and 11n block ack sessions we see messages such as:
iwm0: sending action to xx:xx:xx:xx:xx:xx
Which is not very informative.
It would be more useful to show the type of action frame being sent.
The patch below implements this for the types we currently care about.
On Tue, Sep 07, 2021 at 07:29:37PM +0200, Martin Pieuchot wrote:
> On 07/09/21(Tue) 18:03, Stefan Sperling wrote:
> > On Tue, Sep 07, 2021 at 05:16:52PM +0200, Martin Pieuchot wrote:
> > > On 07/09/21(Tue) 15:48, Stefan Sperling wrote:
> > > > This patch makes
On Tue, Sep 07, 2021 at 05:16:52PM +0200, Martin Pieuchot wrote:
> On 07/09/21(Tue) 15:48, Stefan Sperling wrote:
> > This patch makes iwx(4) resume reliably for me.
> >
> > There were missing splnet() calls which leads to an obvious race
> > between the interrupt
This patch makes iwx(4) resume reliably for me.
There were missing splnet() calls which leads to an obvious race
between the interrupt handler and the code which triggers firmware
loading and then sleeps to wait for confirmation.
This patch adds the missing splnet().
However, even with splnet()
On Thu, Sep 02, 2021 at 09:32:28PM +0800, Kevin Lo wrote:
> On Thu, Sep 02, 2021 at 02:24:17PM +0200, Stefan Sperling wrote:
> > While review device-specific quirks in this driver I noticed that
> > the xtal latency values we send to the chip do no match those used
> >
This patch fixes suspend/resume with an AX201 device for gnezdo@.
Tests on any iwm/iwx device would be apreciated.
Before testing this make sure to update your tree to -current which contains
a very recent fix for a double-free in the resume path of the iwx driver.
You won't have great results
While review device-specific quirks in this driver I noticed that
the xtal latency values we send to the chip do no match those used
by the Linux driver.
ok?
diff b81ef55c86817a4ccf18086fd9b7dc3ee49ae415 /usr/src (staged changes)
blob - 096caf79896dcd97f16f0744fb8206ad8a12a9d7
blob +
iwm(4) reloads firmware from disk whenever the device is initialized.
This includes suspend/resume, where accessing the disk is not a good idea.
It seems we have been lucky because iwm(4) defers the wakeup step into a
task context, such that disk has resumed when this task gets to run.
But this is
On Wed, Sep 01, 2021 at 01:12:20PM +0200, Stefan Sperling wrote:
> On Wed, Sep 01, 2021 at 01:33:34AM +0200, Alexander Hall wrote:
> > If two files to be compared share the same inode, it should
> > be reasonable to consider them identical.
> >
> > This gives a substan
On Wed, Sep 01, 2021 at 01:33:34AM +0200, Alexander Hall wrote:
> If two files to be compared share the same inode, it should
> be reasonable to consider them identical.
>
> This gives a substantial speedup when comparing directory
> structures with many hardlinked files, e.g. when using
>
On Wed, Aug 25, 2021 at 08:13:26PM +0200, Florian Obser wrote:
> On 2021-08-25 18:02 +01, Stuart Henderson wrote:
> > Trying to announce a network on a wg(4) interface via ospf6d, just
> > using passive to pick up the prefix, i.e.
> >
> > interface wg0 { passive }
> >
> > It's failing with
Detailed firmware error reports from Intel wifi drivers are quite
noisy so it makes sense to hide them by default, especially on
systems running -release.
When Tx agg support was added to iwn and iwm it was important to
see detailed firmware error reports. These were hidden behind the
On Fri, Apr 02, 2021 at 06:26:11PM +0800, zxystd wrote:
> It is not a functionality change. The firmware dma is not actually used and
> it is due to ported from iwm, this patch remove this allocation.
Thanks! I have committed a slightly tweaked version, renaming the final
goto label only. I'm
On Tue, Jul 13, 2021 at 08:20:23PM +0200, Hrvoje Popovski wrote:
> On 30.6.2021. 13:28, Stefan Sperling wrote:
> > On Mon, Jun 21, 2021 at 08:37:11PM +0200, Stefan Sperling wrote:
> >> This patch attempts to implement Tx aggregation support for iwx(4).
> >>
> >>
The sequence numbers for QoS data frames sent with Tx aggregation
are implicitly initialized to 0 when the system boots. From then on
the counters will simply keep incrementing with a wrap after 0xfff.
This isn't a problem with iwn(4) or iwm(4) because we always send the
current value in 'add
On Wed, Jul 28, 2021 at 02:13:41PM +0200, Stefan Sperling wrote:
> On Mon, Jul 26, 2021 at 06:21:46PM +0200, Stefan Sperling wrote:
> > This patch implements support for new iwx(4) -63 firmware images
> > available in the iwx-firmware-20210512 package (via fw_update).
>
On Mon, Jul 26, 2021 at 06:21:46PM +0200, Stefan Sperling wrote:
> This patch implements support for new iwx(4) -63 firmware images
> available in the iwx-firmware-20210512 package (via fw_update).
>
> Please test this patch and report back. If testing works out well
> the
This patch implements support for new iwx(4) -63 firmware images
available in the iwx-firmware-20210512 package (via fw_update).
Please test this patch and report back. If testing works out well
then I will commit these changes to CVS incrementally. Thanks!
For those testing my iwx Tx agg patch:
On Mon, Jul 19, 2021 at 09:20:17PM -0400, Ashton Fagg wrote:
> Found this while poking around - an extra newline in if_iwx.c.
>
> Index: sys/dev/pci/if_iwx.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
> retrieving revision
On Mon, Jul 05, 2021 at 06:36:00PM -0700, Greg Steuck wrote:
> Stefan Sperling writes:
>
> > On Tue, Jul 06, 2021 at 12:31:20AM +0200, Stefan Sperling wrote:
> >> On Mon, Jul 05, 2021 at 02:11:36PM -0700, Greg Steuck wrote:
> >> > Do I need to figure
On Tue, Jul 06, 2021 at 12:31:20AM +0200, Stefan Sperling wrote:
> On Mon, Jul 05, 2021 at 02:11:36PM -0700, Greg Steuck wrote:
> > Do I need to figure out the state machines behind iwx and iee80211 now? :)
>
> This AP seems to use TKIP for the groupcipher and the iwx
> setkey t
On Mon, Jul 05, 2021 at 02:11:36PM -0700, Greg Steuck wrote:
> Do I need to figure out the state machines behind iwx and iee80211 now? :)
This AP seems to use TKIP for the groupcipher and the iwx
setkey task doesn't handle this case properly.
Can you try this?
diff
On Mon, Jul 05, 2021 at 10:20:09AM -0700, Greg Steuck wrote:
> Stefan Sperling writes:
>
> > On Mon, Jul 05, 2021 at 09:35:20AM +0200, Stefan Sperling wrote:
> >> On Sun, Jul 04, 2021 at 07:58:47PM -0700, Greg Steuck wrote:
> >> > I never se
On Mon, Jul 05, 2021 at 09:35:20AM +0200, Stefan Sperling wrote:
> On Sun, Jul 04, 2021 at 07:58:47PM -0700, Greg Steuck wrote:
> > I never see "iwx0: sending action to" after this.
>
> And you still see status: "no network" in ifconfig at this point?
>
On Sun, Jul 04, 2021 at 07:58:47PM -0700, Greg Steuck wrote:
> I stumbled upon a weird hotel WiFi which never gets to a fully running
> link with iwx0. I see ifconfig is stuck with:
>
> iwx0: flags=808847
> mtu 1500
> lladdr xx
> index 1 priority 4 llprio 3
> groups: wlan
Some wifi drivers defer installation of keys into a process context.
There was a noticable race in the past which was fixed thanks to krw@
where link state was set to UP before key installation had completed in
hardware. This race could result in dhclient failing to get a lease.
Other races
On Tue, May 25, 2021 at 03:48:16PM +0200, Stefan Sperling wrote:
> This patch allows iwm(4) to use new firmware images which are part
> of the iwm-20210512 firmware package, available via fw_update (you
> need to run fw_update *before* booting with this patch).
Here is a rebase
On Mon, Jun 21, 2021 at 08:37:11PM +0200, Stefan Sperling wrote:
> This patch attempts to implement Tx aggregation support for iwx(4).
>
> It is not yet ready to be committed because of outstanding problems:
>
> - Under load the firmware throws a fatal firmware error ev
tcpdump -e -v -y IEEE802_11_RADIO currently prints sequence number
and fragment number as a combined decimal value.
This patch makes tcpdump display these values separately which is a lot
easier to follow along as packets scroll by.
ok?
diff 18a81a05d6e3098eadc4b5e23d6656377f87591a /usr/src
According to zxystd from OpenIntelWireless, the following change fixed
fatal firmware errors seen during HT protection updates for them.
I have not seen the issue myself, but I don't think this change can hurt.
If it fixes firmware errors in an edge case, all the better.
This essentially aligns
The mac context task gets triggered by changing parameters in beacons
received from our AP while ic_state indicates that we are in RUN state.
This can happen during regular operation and while a background scan
is in progress.
When a background scan has found a new AP, we trigger a RUN -> AUTH
This patch attempts to implement Tx aggregation support for iwx(4).
It is not yet ready to be committed because of outstanding problems:
- Under load the firmware throws a fatal firmware error every few minutes.
- Starting a background scan under load can cause firmware errors and
might error
I have found the reason for stuck connections over iwm/iwx
which people have been reporting against -current.
My commit which added support for Rx aggregation offload to these
drivers introduced a node leak. In other words, the reference counter
of ic_bss is incremented with every received frame,
On Mon, Jun 14, 2021 at 03:58:39PM +0800, zxystd wrote:
> Hi Stefan,
>
> Did we missed the 'umac_prph_offset' constant value in
> iwm_clear_persistence_bit function? From linux code, it is read_umac_prph,
> not read_prph, so the function should be looks like this:
>
> int
>
On Mon, May 31, 2021 at 02:33:03PM +0300, Reuven Plevinsky wrote:
> Hi,
> Here is my diff:
> https://github.com/reuvenP/src/commit/db909be68a3b03e68787de55d218388f33c4c4c6
Not everyone wants to read diffs in a browser.
Sending your diff inline will work better, like this:
diff --git
Steven observed a panic ("iwm0: mac clock not ready") while testing
the iwm firmware update patch on a 9560 device.
I've also seen this happen one time, at some point during development.
In hindsight it is a bad idea to look at hardware register state here.
The point of iwm_nic_assert_locked() is
This patch allows iwm(4) to use new firmware images which are part
of the iwm-20210512 firmware package, available via fw_update (you
need to run fw_update *before* booting with this patch).
The new firmware images were published right after the fragattacks
embargo period ended. An advisory was
kettenis@ noticed that an athn(4) node cache can contain bogus clients
with MAC addreses that look like bit-flipped versions of MAC addresses
of legitimate clients.
I think this is due to my recent fix to allow block ack requests to
pass through athn(4).
The driver calls ieee80211_find_rxnode()
101 - 200 of 1452 matches
Mail list logo
