On Sat, Aug 04, 2018 at 09:12:27PM +0200, Sebastian Benoit wrote:
> Hi,
>
> with this diff,
>
> ifconfig join
>
> will print the list of networks that are configured for autojoin.
>
> $ ifconfig iwm0 join
> iwm0: flags=208843 mtu 1500
> lladdr a4:7f:da:a4:d7:c1
> index 1 pri
On Mon, Aug 06, 2018 at 11:42:51AM +0200, Florian Obser wrote:
> I don't understand why we have a limit on the join list.
The ioctl interface is easier to deal with if the max size is known in
advance. The recalloc dance in benno's diff isn't actually necessary
(nevermind that it's still enforcing
No functional change.
Drop ieee80211_add_ess's nwid parameter. Read nwid and length from the ic.
The intention is to make it more obvious what the current implementation
is doing. Our long-term goal should be to pass essid/essid-length/crypto
params in one pass but the current WPA ioctl interface
Aruba 105 APs announce a mandatory Rx MCS set in association responses.
Specifically, they claim to require that all clients support MCS 0-31.
This seems very wrong, and I believe it's a bug in this brand of APs.
Because our Intel drivers only do MCS 0-16, and the AP tells us that
we're required t
On Wed, Aug 08, 2018 at 04:40:48PM +0800, Kevin Lo wrote:
> ok?
>
OK with me. Don't forget to run 'make' in dev/pci as well
to regen the pci device table C files :)
> Index: sys/dev/pci/if_rtwn.c
> ===
> RCS file: /cvs/src/sys/dev/p
iwm switches the current BSS channel for each input frame.
The reason for this is that with most of our drivers the
net80211 stack zaps through all channels one-by-one during
scans, and hence expects the BSS channel to match the
currently scanned channel.
However, iwm offloads scans to the firmwa
Some access points have a feature called "band steering" where they
will try to push clients from 2 GHz channels to 5 GHz channels.
Such APs keep track of probe-requests from the same client on
different bands. If a client sends probe-requests on both 2 GHz
and 5GHz channels, and then attempts to a
On Fri, Aug 24, 2018 at 11:57:54AM +0100, Ricardo Mestre wrote:
> Hi,
>
> Similar to the patch I just sent for smsc(4) this one also has a misplaced
> parenthesis in an if-clause. NetBSD fixed this on rev 1.13.
>
> OK?
ok
> Index: if_upgt.c
>
On Sat, Sep 01, 2018 at 06:41:43PM +0800, Michael Mikonos wrote:
> Hello,
>
> smtp_client_state() and smtp_client_response() both do
>
> switch (proto->state) ...
>
> but smtp_client_state() doesn't print the id of the bad state
> in the default case. This patch makes the fatalx() message
On Thu, Aug 30, 2018 at 09:02:22PM +0200, Martijn van Duren wrote:
> Hello tech@,
>
> Don't know if this is too much magic numbers for copy_file, but this
> "fixes" the case where we print the verbose line, even if we don't copy
> it. This doesn't not happen in mv or rm.
>
> Note that the curre
On Fri, Aug 31, 2018 at 09:40:19AM +0200, Martijn van Duren wrote:
> Hello tech@,
>
> While working on fixing the -iv behaviour yesterday I noticed that the
> -i verification isn't implemented for the special copies and thus
> allowing to overwrite a file.
> I did some archaeology and found it w
On Fri, Aug 31, 2018 at 09:42:08AM +0200, Martijn van Duren wrote:
> part 2
>
> OK?
ok stsp@
>
> martijn@
>
> diff --git cp.c cp.c
> index 321e82f..fbf924c 100644
> --- cp.c
> +++ cp.c
> @@ -395,9 +395,9 @@ copy(char *argv[], enum op type, int fts_options)
>
> switch (curr->fts
On Fri, Aug 31, 2018 at 09:43:03AM +0200, Martijn van Duren wrote:
> part 3
>
> OK?
ok stsp@
>
> martijn@
>
> diff --git cp.c cp.c
> index fbf924c..2ccef08 100644
> --- cp.c
> +++ cp.c
> @@ -434,7 +434,7 @@ copy(char *argv[], enum op type, int fts_options)
> !
On Fri, Sep 07, 2018 at 12:40:49AM +0800, Michael Mikonos wrote:
> Hello,
>
> The umidi(4) driver has three different endpoint allocation
> functions, which are called by alloc_all_endpoints(). The
> initial jack count can be moved here because it is zero
> no matter which allocation function is u
On Fri, Aug 31, 2018 at 09:40:19AM +0200, Martijn van Duren wrote:
> 1) Implements the copy_overwrite function so we can reuse it in all
> functions.
> 2) Add the copy_overwrite function to copy_{link,fifo,special}
> 3) Change dne variable to exists for copy_file to be consistent with
> the naming
On Tue, Sep 11, 2018 at 12:01:28AM +0200, Alexander Bluhm wrote:
> Hi,
>
> I don't see any use for the INPCBHASH() macros. Just expand them.
>
> ok?
ok.
Pretty pointless indeed.
>
> bluhm
>
> Index: netinet/in_pcb.c
> ===
> RCS
On Sun, Oct 07, 2018 at 09:43:05AM +0200, Giovanni Bechis wrote:
> Hi,
> after setting LC_ALL=en_US.UTF-8 on my env locate.mklocatedb seems broken,
> resetting LC_ALL=C is a workaround.
>
> $ export LC_ALL=en_US.UTF-8
> $ doas /usr/libexec/locate.updatedb
> sort: Illegal byte sequence
> locate.mkl
On Sun, Oct 21, 2018 at 08:25:02AM +0200, def...@posteo.de wrote:
> Hi
>
> Any updates?
I still want to do some testing at my end with ath hardware I have.
So please just wait.
On Sun, Oct 21, 2018 at 09:46:20AM +0200, Stefan Sperling wrote:
> On Sun, Oct 21, 2018 at 08:25:02AM +0200, def...@posteo.de wrote:
> > Hi
> >
> > Any updates?
>
> I still want to do some testing at my end with ath hardware I have.
> So please just wait.
>
Every time we settle for the same AP after a background scan,
a timeout value is increased to avoid repeated background scans
in situations where no better AP is available.
The backoff currently increments in steps of half a second.
This causes very frequent background scans for a few minutes
afte
On Fri, Nov 30, 2018 at 01:49:56PM +0100, Benjamin Baier wrote:
> Hi
>
> There is a leak of *arg in
> dev/usb/if_athn_usb.c:athn_usb_newauth() line 1263
> since Rev. 1.49
> Because athn_usb_do_async() memcpy's the argument anyway.
>
> Found with llvm/scan-build.
>
> Instead of adding free(arg)
On Wed, Dec 05, 2018 at 07:55:07PM +0100, Benjamin Baier wrote:
> Finally got a usb athn device. I can confirm that this codepath is hit
> in hostap mode and the device still works with the patch.
>
> athn0 at uhub4 port 2 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev
> 2.00/1.08 addr 3
>
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
> &g
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 workaro
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
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 fix
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),
> + M_DEVBU
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
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 hurt.
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 be
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 wa
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 thing
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 - 8bf122
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 firmware statio
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 if
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:
https://marc.info/?l=openbsd-
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 AX200/AX
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
> otherwis
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 bc49c35a84a
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 capaci
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 4965AG
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
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 cov
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 ca
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 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
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
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
d18b
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 sess
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 susp
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 wit
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
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 poss
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
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 protoco
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
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 app
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
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 dr
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 it
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 to
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 mute
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 re
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: share/man/
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 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 page,
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 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 mo
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
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 ENOM
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 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 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 uninitializ
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 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 like
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 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 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
> "/usr/src/sy
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 ifc
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 53
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 ic->ic_fixed_
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 receiv
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',
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 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 (d
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
> ===
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 associat
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 VCP
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 correct
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&m=143662082630187&w=2 on -current
> and also on 6.7
>
> also verified that the patch
> (https://m
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 *basename(ch
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 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 have
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 reduc
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 results
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 ser
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&m=160733342209497&w=2
>
> I don't have a iwx(4) card to test this, but the diff to iwm(4) i
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
> >
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 (MF
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 tim
201 - 300 of 1524 matches
Mail list logo
