On Mon, May 09, 2022 at 08:17:35PM +, molotov31337 wrote:
> I recently picked up a Panda Wireless PAU06 and got it working, can this be
> committed?
> Here is the cvs diff
Committed, thanks!
> Index: usbdevs
> ===
> RCS file:
As noticed by jsg@ and kevlo@ we use a bad MAC address on AX210 devices.
Patch below fixes the issue on AX210, and still works on AX200.
The old way of reading the MAC no longer works on AX210; apparently this
new way of reading the MAC was introduced in the 9k hw generation but the
old way was
This patch adds support for AX210/AX211 devices to iwx(4).
While this patch attempts to make a couple of devices work which
are part of this device family, so far only one specific AX210
device has been tested:
iwx0 at pci4 dev 0 function 0 "Intel Wi-Fi 6 AX210" rev 0x1a, msix
iwx0: hw rev
On Sun, May 08, 2022 at 12:29:57AM -0400, Farhan Khan wrote:
> On May 6, 2022 4:37:48 AM EDT, Stefan Sperling wrote:
> >On Thu, May 05, 2022 at 01:19:08PM -0400, Farhan Khan wrote:
> >> Hi all,
> >>
> >> Summary Question:
> >>
> >> Broadly
On Thu, May 05, 2022 at 01:19:08PM -0400, Farhan Khan wrote:
> Hi all,
>
> Summary Question:
>
> Broadly, I am trying to understand where a interrupt callback is specified if
> not already specified by usbd_open_pipe_intr(9). Specifically, for the
> athn(4)
> driver, I am trying to understand
On Sat, Apr 09, 2022 at 05:46:29PM +0200, Sven Wolf wrote:
> Hi Stefan,
>
> thanks for your effort.
> I've successfully tested your latest patch.
> I also got the sw_hw_rev:
>
> sc_hw_rev=354
Thank you! Now everything makes sense :)
On Sat, Apr 09, 2022 at 04:53:50PM +0200, Stefan Sperling wrote:
> On Sat, Apr 09, 2022 at 04:52:12PM +0200, Stefan Sperling wrote:
> > On Sat, Apr 09, 2022 at 04:29:42PM +0200, Stefan Sperling wrote:
> > > As sthen points out, please show sc_hw_rev without any of its bit
On Sat, Apr 09, 2022 at 04:52:12PM +0200, Stefan Sperling wrote:
> On Sat, Apr 09, 2022 at 04:29:42PM +0200, Stefan Sperling wrote:
> > As sthen points out, please show sc_hw_rev without any of its bits
> > masked out, with a patch like this:
>
> Nevermind, I found a bug i
On Sat, Apr 09, 2022 at 04:29:42PM +0200, Stefan Sperling wrote:
> As sthen points out, please show sc_hw_rev without any of its bits
> masked out, with a patch like this:
Nevermind, I found a bug in my patch which most certainly
breaks your device.
Please try this on top of the patch I se
On Sat, Apr 09, 2022 at 03:28:14PM +0200, Stefan Sperling wrote:
> On Sat, Apr 09, 2022 at 12:47:56PM +0200, Sven Wolf wrote:
> > Hi Stefan,
> >
> > sorry, I'm not sure how I can get the sc_hw_rev value.
> > Hopefully this is the requested value:
> >
> > i
On Sat, Apr 09, 2022 at 12:47:56PM +0200, Sven Wolf wrote:
> Hi Stefan,
>
> sorry, I'm not sure how I can get the sc_hw_rev value.
> Hopefully this is the requested value:
>
> iwx0: hw rev 0x350, fw ver 67.8f59b80b.0
This is not the "QuZ" (0x354) hardware revision.
However, Linux obviously
On Sat, Apr 09, 2022 at 03:26:03AM +0200, stolen data wrote:
> It's been great seeing iwm/iwn/iwx/athn getting a lot of updates lately. I
> wonder if there's any work planned for getting 11n support to some of the
> older but still capable Realtek chipsets in ral(4)?
>
> I have a spare
_INTEL_WL_22500_8:
> if (sc->sc_hw_rev != IWX_CSR_HW_REV_TYPE_QUZ)
Thanks Sven!
What is the value of sc_hw_rev on this 0x4df0 device?
> sc->sc_fwname = IWX_QU_B_HR_B_FW;
> else
> --- 9859,9864
>
>
> Thanks,
>
On Tue, Jan 11, 2022 at 10:33:39PM +, Iraklis Karagkiozoglou wrote:
> Hello Stefan,
>
> I tried to port the firmware detection and config values
> from iwlwifi.
>
> On iwx_cfg_trans_params and iwx_cfg structs I ported only
> the fields iwx_attach was setting based on the iwx_device.
>
>
On Thu, Mar 31, 2022 at 09:41:09PM +0800, Kevin Lo wrote:
> This diff adds preliminary support for RTL8156B to ure(4) and
> bug fixes for RTL8153/RTL8156.
>
> Tested:
> ure0 at uhub0 port 12 configuration 1 interface 0 "Realtek USB 10/100/1G/2.5G
> LAN" rev 3.20/31.00 addr 3
> ure0: RTL8156B
On Sun, Mar 20, 2022 at 05:00:13PM -0600, Thomas Frohwein wrote:
> I updated the diff for the controller with your diff. Below is the
> complete diff for all the files involved. I tested it again with my
> controller and sdl-jstest (in ports); it continues to work as intended.
>
> ok?
Thanks! Ok
This patch fixes a couple of issues in the VHT rate adaptation code,
and with the data which iwm(4) is feeding into it.
Testing 11ac mode from a distance to my AP, I found that iwm(4) tends
to pick a Tx rate which is too high, resulting in too much of a drop
in throughput.
With this patch,
On Fri, Jan 15, 2021 at 06:32:04AM -0700, Thomas Frohwein wrote:
> @@ -557,6 +571,23 @@ uhidev_open(struct uhidev *scd)
> DPRINTF(("uhidev_open: couldn't allocate owxfer\n"));
> error = ENOMEM;
> goto out3;
> + }
> +
> +
Both iwm and iwx are currently writing VHT capabilities into
the "common" secion of the firmware's probe request frame template.
This "common" section is used on both 2GHz and 5GHz bands.
Announcing VHT capabilities on 2GHz makes no sense.
Move them into the 5GHz-only section.
ok?
diff
On Sat, Mar 19, 2022 at 05:32:48PM +0100, Stefan Sperling wrote:
> The net80211 input routine expects that ic->ic_bss->ni_chan will always
> correspond to the channel which is currently being scanned. This dates
> back to older devices which are manually tuned to the next channel
The net80211 input routine expects that ic->ic_bss->ni_chan will always
correspond to the channel which is currently being scanned. This dates
back to older devices which are manually tuned to the next channel by the
driver during SCAN->SCAN state transitions. And this must of course be
kept
On Fri, Mar 18, 2022 at 11:36:50AM +0100, Stefan Sperling wrote:
> On Fri, Mar 18, 2022 at 05:25:42AM +0100, Landry Breuil wrote:
> > interestingly, when associated over ac to the livebox the background
> > scans only shows the 5ghz channels from both APs, but when im associated
&g
Fix number 1:
During network selection (for 'ifconfig join'), give APs which support
11n and 11ac a higher score. VHT implies HT, so 11ac networks receive
2 additional points while 11n-only networks receive one additional point.
Fix number 2:
During AP selection within a given network, we would
I botched the logic used by a check in iwm_vht_single_rate_control().
ok?
diff 15b71cdf8530b1f64fb85d50873b1ff1fad3f0e8 /usr/src
blob - 2c01f718d47acb01a227795fef659ef353f5c7f6
file + sys/dev/pci/if_iwm.c
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -5550,7 +5550,7 @@
On Wed, Mar 16, 2022 at 10:03:36PM +0100, Stefan Sperling wrote:
> On Wed, Mar 16, 2022 at 08:46:01PM +0100, Jeremie Courreges-Anglas wrote:
> > On Mon, Mar 14 2022, Stefan Sperling wrote:
> > > It is currently impossible to use more than one iwm or iwx interface
> > >
On Fri, Mar 18, 2022 at 01:39:01PM +0100, Marcus MERIGHI wrote:
> Hello,
>
> s...@stsp.name (Stefan Sperling), 2022.03.17 (Thu) 21:09 (CET):
> > On Thu, Mar 17, 2022 at 07:02:06PM +0100, Marcus MERIGHI wrote:
> > > s...@stsp.name (Stefan Sperling), 202
On Fri, Mar 18, 2022 at 05:25:42AM +0100, Landry Breuil wrote:
> interestingly, when associated over ac to the livebox the background
> scans only shows the 5ghz channels from both APs, but when im associated
> to my regular AP the background scans shows both 2ghz and 5ghz chans.
> not sure that
On Thu, Mar 17, 2022 at 02:43:14PM -0700, Mike Larkin wrote:
> On Wed, Mar 16, 2022 at 11:17:47PM +0100, Stefan Sperling wrote:
> > On Wed, Mar 16, 2022 at 04:11:41PM +0100, Stefan Sperling wrote:
> > > This patch adds initial 11ac support to the iwm(4) driver.
> > &
On Thu, Mar 17, 2022 at 07:02:06PM +0100, Marcus MERIGHI wrote:
> Hello!
>
> Thanks for your work on this!
>
> s...@stsp.name (Stefan Sperling), 2022.03.16 (Wed) 16:11 (CET):
> > This patch adds initial 11ac support to the iwm(4) driver.
> > It allows use of
On Thu, Mar 17, 2022 at 01:07:42AM +, Stuart Henderson wrote:
> 802.11 flags=0<>: beacon, ...
> 191:12 0xb109cb33aaff1806aaff1806, 192:5 0x00aaff,
Now is probably a good time to start pretty-printing these fields in tcpdump.
ok?
diff 140ae54c8a573c04824dd96957ebff4e069b2dfd /usr/src
On Wed, Mar 16, 2022 at 04:11:41PM +0100, Stefan Sperling wrote:
> This patch adds initial 11ac support to the iwm(4) driver.
> It allows use of 80 MHz channels and VHT MCS.
Updated patch. Fixes a fatal firmware error on devices which
do not support MIMO, such as the 3160.
diff refs/heads/
On Wed, Mar 16, 2022 at 08:46:01PM +0100, Jeremie Courreges-Anglas wrote:
> On Mon, Mar 14 2022, Stefan Sperling wrote:
> > It is currently impossible to use more than one iwm or iwx interface
> > in a system because I don't understand C.
> >
> > Trying to bring up
This patch adds initial 11ac support to the iwm(4) driver.
It allows use of 80 MHz channels and VHT MCS.
In net80211 I added a new rate control module to support VHT rates, as
a new file called ieee80211_ra_vht.c, derived from ieee80211_ra.c which
we use in 11n mode. The task of this code is to
It is currently impossible to use more than one iwm or iwx interface
in a system because I don't understand C.
Trying to bring up an uninitialized interface anyway results in a
kernel panic ("bogus channel pointer" from net80211), so prevent
the device from being used in case we never managed to
On Thu, Mar 10, 2022 at 01:56:19PM -0500, Dave Voutila wrote:
>
> Stefan Sperling writes:
>
> > On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
> >> Unless anyone else finds a problem, this patch can be considered ready
> >> for review and co
On Thu, Mar 10, 2022 at 12:25:17PM +0100, Stefan Sperling wrote:
> Unless anyone else finds a problem, this patch can be considered ready
> for review and commit.
Of course, I forgot to apply my sysassert fix to the second phy context
command function... Fixed here.
diff refs/heads/maste
On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote:
> This patch adds initial 11ac support to the iwx(4) driver.
> This means that 80MHz channels can be used. No other 11ac features
> are enabled yet.
>
> This is not yet a patch which could be committed. Apart from
On Wed, Mar 09, 2022 at 07:16:41PM +0300, Mikhail wrote:
> On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote:
> > /*
> > + * Install received VHT caps information in the node's state block.
> > + */
> > +void
> > +ieee80211_setup_vhtcaps(struct
This patch adds initial 11ac support to the iwx(4) driver.
This means that 80MHz channels can be used. No other 11ac features
are enabled yet.
This is not yet a patch which could be committed. Apart from debug
prints which need to go, there is a known issue found by dv@ where
this patch causes a
On Tue, Mar 08, 2022 at 02:38:39PM -0700, Theo de Raadt wrote:
> Stefan Sperling wrote:
> > In this case it is not ifconfig, but netstat -W iwm0.
> > Which is a debugging tool, like netstat -s.
>
> We don't care when netstat breaks
Alright, then this diff is indeed not necessary.
On Tue, Mar 08, 2022 at 12:58:27PM -0700, Theo de Raadt wrote:
> Claudio Jeker wrote:
>
> > Honestly I think this is overkill. There is no stat struct where we do
> > this dance. It is accepted that netstat needs to keep in sync for these
> > structs to work. Why is it necessary to disconnect
On Tue, Mar 08, 2022 at 03:55:48PM +0100, Stefan Sperling wrote:
> On Mon, Mar 07, 2022 at 03:04:06PM -0700, Theo de Raadt wrote:
> > > For now, the structs are identical so the code copying data out is
> > > kept simple.
> >
> > I think this is unwise, and yo
On Mon, Mar 07, 2022 at 03:04:06PM -0700, Theo de Raadt wrote:
> > For now, the structs are identical so the code copying data out is
> > kept simple.
>
> I think this is unwise, and you should write the field-by-field copying
> function at the same time, otherwise this is just asking for
There is another net80211 ioctl which shares a struct between kernel
and userland: struct ieee80211_stats shown by the netstat -W command.
While it is trivial to recompile netstat when this struct is changed,
giving the kernel a separate struct type would allow us to add, change,
or remove
The net80211 ioctl which ifconfig is using to obtain a list of all
supported channels is using a struct name that belongs to the kernel.
Fix this by renaming struct ieee80211_channel to struct ieee80211_chaninfo
in ieee80211_ioctl.h. The way this is done here keeps both old and new
ifconfig
On Tue, Mar 01, 2022 at 10:41:14AM +, Stuart Henderson wrote:
> Probably best to wait a bit for other feedback, but: OK sthen
Ok from me, too. Some of my subnets are routed to me via OpenVPN so
I will be forced to keep using it for the foreseeable future.
I have $openvpn_port variables in
On Mon, Feb 21, 2022 at 10:20:17AM +0100, Marc Espie wrote:
> On Mon, Feb 21, 2022 at 05:36:16PM +0900, Yuichiro NAITO wrote:
> > Of course, all programs compiled without '-pg' work fine for me.
> > I found this issue when I profile my application with gprof(1).
> > For example, following example
On Tue, Jan 25, 2022 at 11:22:45AM +0100, Mark Kettenis wrote:
> > The KASSERT triggers but for the wrong reason: We don't have outstanding
> > tasks, we have a bad reference counter. Only setting the ref counter to 1 if
> > we are about to launch a task during resume should fix it, and this
On Tue, Jan 25, 2022 at 09:32:21AM +0100, Mark Kettenis wrote:
> Happened again while still on a Jan 16 snapshot kernel. So it is not
> related to that diff.
>
> Here is the panic message and backtrace:
>
> panic: kernel diagnostic assertion "sc->task_refs.refs == 0" failed: file
>
On Sun, Jan 16, 2022 at 07:38:11PM +0100, Mark Kettenis wrote:
> > Date: Sun, 16 Jan 2022 19:28:06 +0100
> > From: Stefan Sperling
> >
> > On Sun, Jan 16, 2022 at 03:50:55PM +0100, Mark Kettenis wrote:
> > > However, running this diff I had a problem after resu
On Sun, Jan 16, 2022 at 03:50:55PM +0100, Mark Kettenis wrote:
> However, running this diff I had a problem after resuming my laptop
> twice. After resume the interface didn't work and I found the
> following in dmesg:
>
> iwm0: could not initialize hardware
>
> I tried to reset the interface by
On Sun, Jan 16, 2022 at 05:51:03PM +0300, Alex Beakes wrote:
> FreeBSD has tested iwlwifi with Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420.
> Wifi 6E, ty-a0-gf-a0-63.ucode.
>
> Is there a way of implementing this and making the wifi module work.
>
> https://wiki.freebsd.org/WiFi/Iwlwifi
I will
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),
> +
1 - 100 of 1407 matches
Mail list logo
