On Tue, Jan 10, 2017 at 08:34:32PM -0500, Brandon Mercer wrote:
> I've thrown this on my apu2 and done some tests with my ipad, android
> phones and some openbsd laptops. Streamed 1080p from youtube works on
> one device but when I try with 2x it starts to buffer a bit.
>
> Tested on 2.4Ghz:
>
On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> This diff adds 11n support to the athn(4) driver.
> Requires -current net80211 code from today.
A better diff which fixes several bugs.
Most notably this should fix a crash in hostap mode triggered by clients
joining and l
When a HT node leaves or reassociates as a non-HT node,
clear HT capabilities stored in its node cache object.
A node may switch from 11n mode to 11a/b/g mode.
If we don't clear HT capabilities from the cache the node will
be mistaken as 11n-capable after reassociation.
Index: ieee80211_input.c
Currently, an athn(4) hostap in 11n mode sending data a fame
looks something like this:
AP: RTS
client: CTS
AP: RTS
client: CTS
AP: RTS
client: CTS
AP: RTS
client: CTS
AP: RTS
client: CTS
AP: data
client: ACK
The problem seems to be that while we're sending EDCA
On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote:
> For Linux clients a fix for WME params is needed which I also posted to tech@.
That fix is now committed.
This diff adds 11n support to the athn(4) driver.
Requires -current net80211 code from today.
Tested in hostap mode and client mode with:
athn0 at pci1 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, adddress xx:xx:xx:xx:xx:xx
And in client mode
Linux clients won't use 11n with an AP unless the AP provides WME parameters.
This is the reverse of the problem we had when Linux APs did not want
to use 11n with OpenBSD clients who did not send a wme info element in
association requests.
Tested with 11n-enabled athn(4) OpenBSD hostap and an
This diff cannot be tested yet -- I'm looking for OKs only :-)
Manage the HT protection setting if acting as hostap with 11n enabled.
For now we flip-flop only between non-member protection and non-HT protection.
Running a HT network without protection would require monitoring environmental
I've received reports from various folks over the last year where iwm
would print messages like these while various ifconfig commands are used:
iwm0: could not initiate scan
iwm0: device timeout
I found this also happens on one of my machines during bsd.rd upgrades.
While the upgrade script
On Tue, Jan 03, 2017 at 05:26:04PM +0100, Leo Unglaub wrote:
> Hey tech@
> i wanted to upgrade to the latest snapshot (as i always do, every week) but
> since you added the HTTPS support to the installer i am unable to boot my
> system or the install.fs from a flash drive.
>
> I get to the MBR
On Mon, Dec 26, 2016 at 12:50:31PM +0100, Mark Kettenis wrote:
> > Date: Mon, 26 Dec 2016 09:13:50 +0100
> > From: Stefan Sperling <s...@stsp.name>
> >
> > I do not see a good reason for using multiple custom task queues
> > in this driver, and at the s
On Tue, Dec 27, 2016 at 12:31:36PM +0100, Gregor Best wrote:
> On Tue, Dec 27, 2016 at 01:00:54AM +0100, Gregor Best wrote:
> > On Mon, Dec 26, 2016 at 08:44:47PM +0100, Stefan Sperling wrote:
> > > [...]
> > > E.g. at 33C3 there are APs with: RxMCS 0xf8f8f80
Even though the 11n standard mandates MCS 0-15 for APs, some APs have config
knobs which disable a subset of MCS, and some admins do touch these knobs.
E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800
The diff below makes OpenBSD clients work in 11n mode on such networks
by relaxing
I do not see a good reason for using multiple custom task queues
in this driver, and at the same time it is using systq for tasks.
This moves all tasks to one custom queue to make things consistent.
Except I'm leaving the init_task on systq because this task is kind
of special (e.g. it might be
On Fri, Dec 23, 2016 at 11:06:34PM +0100, Jeremie Courreges-Anglas wrote:
> Same diff for ospf6d, ok?
Yes. OK.
> Index: printconf.c
> ===
> RCS file: /d/cvs/src/usr.sbin/ospf6d/printconf.c,v
> retrieving revision 1.4
> diff -u -p
On Fri, Dec 23, 2016 at 09:41:07PM +0100, Mark Kettenis wrote:
> Here clang complains about an implicit enum conversion.
>
> Diff below fixes this by simply using the appropriate ieee80211 enum
> in the HAL_OPMODE typedef and defining HAL_M_XXX as aliases for
> IEEE80211_M_XXX. This matches what
On Fri, Dec 23, 2016 at 06:51:48PM +0100, Mark Kettenis wrote:
> Clang warns about static inline functions that aren't used. There are
> a couple of those in iwn(4) and wpi(4) that are only used if the debug
> code is enabled. The diff below wraps them inside the proper #define.
>
> ok?
ok
When I kill pppd, running on top of umsm(4), I see the following splasserts:
umsm0 at uhub1 port 1 configuration 1 interface 0 "HUAWEI Technologies HUAWEI
Mobile Modem" rev 1.10/0.00 addr 2
umsm0: umass only mode. need to reattach
umsm0 detached
umsm0 at uhub1 port 1 configuration 1 interface 0
Some additional stack traces which run through nd6:
splassert: sowakeup: want 1 have 0
Starting stack trace...
sowakeup(1,0,d09d8d63,d09c8abf,d03cfbb0) at sowakeup+0x43
sowakeup(d95478ec,d954793c,d09d8be1,d378a4a0,d41150e0) at sowakeup+0x43
sorwakeup(d95478ec,d0b57b50,d94bd000,0,2) at
Getting a lot of these with 'dhclient iwm0'.
splassert: sowakeup: want 1 have 0
Starting stack trace...
sowakeup(1,0,d09d8d63,d09c8abf,d03cfbb0) at sowakeup+0x43
sowakeup(d90431fc,d9043288,d09d8bd7,d3be1c00,d978ad00,f61cbd78,d978ad00,d03e5d6f,d90431fc)
at sowakeup+0x43
On Wed, Dec 21, 2016 at 10:01:28PM -0500, Lawrence Teo wrote:
> In 2014, mpi@ substituted n_time, n_long, and n_short with their equivalent
> u_int_* types throughout the network stack to remove the dependency on
> :
>
> http://marc.info/?l=openbsd-tech=140523875001860=2
>
> As mentioned in his
On Sun, Dec 18, 2016 at 10:40:47PM +0100, Alexander Bluhm wrote:
> The mess made me send an incorrect diff. In case that both if_ioctl()
> and rt_ifa_addlocal() fail, we could still end in an inconsistent
> sate.
>
> I think this is better. Still ok?
Yes, it's fine.
> bluhm
>
> Index:
On Sun, Dec 18, 2016 at 12:06:04PM +0100, Claudio Jeker wrote:
> > > Index: usr.sbin/tcpdump/print-802_11.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
> > > retrieving revision 1.35
> > > diff -u -p -r1.35
Anybody?
Did I write too much of a wall of text to explain the diff?
In that case, just read the diff. It should make sense.
On Sun, Dec 11, 2016 at 04:38:44PM +0100, Stefan Sperling wrote:
> This diff makes 'tcpdump -i iwn0 -y IEEE802_11_RADIO' show the
> correct mode for a channel in 11
On Sat, Dec 17, 2016 at 02:33:37AM +0100, Alexander Bluhm wrote:
> Hi,
>
> If rt_ifa_addlocal() in in_ifinit() fails, the address has been
> added to the interface address list, but the local route is missing.
> This inconsistency can result in a panic later.
>
> panic: kernel diagnostic
On Mon, Dec 12, 2016 at 10:53:42AM +0100, Martin Pieuchot wrote:
> This is a just a cosmetic fix. Currently the netmask of flushed routes
> is not printed correctly. The diff below fixes that.
>
> ok?
ok stsp@
>
> Index: route.c
>
On Mon, Dec 12, 2016 at 01:02:55PM +1000, David Gwynne wrote:
> gre can do more things than tcpdump currently thinks it can.
>
> specifically, gre can be carried by ipv6, and it can encapsulate
> more than just ip and ppp packets.
>
> as such, this tells tcpdump to look at gre inside ipv6
This diff makes 'tcpdump -i iwn0 -y IEEE802_11_RADIO' show the
correct mode for a channel in 11n mode.
Before:
After:
Unfortunately this requires a kernel tweak because the kernel must
be more careful about the channel flags it passes to userland.
Channels exist in the 11b/g (2GHz) and 11a
The net80211 stack and iwm(4) driver now support MIMO in -current.
In my own testing, things work just fine. But I have gotten used
to breaking other people's wifi without being aware of it.
So please test -current and let me know about any regressions.
Because iwm(4) devices have 2 antennas MCS
On Sat, Dec 10, 2016 at 12:32:56AM +0100, Patrick Wildt wrote:
> Hi,
>
> I have an IPsec setup that uses IPv6 with IPsec udpencap. In udpencap
> the "next protocol" field is set to UDP. After decapsulation that
> field is set to "IPIP". Unfortunately the udp decapsulation always
> uses the
I have noticed that mira will choose rates which result in a substantial
number of Tx retries, almost 50% or so even for normal 64 byte ping packets.
The diff below makes retry-heavy rates less attractive which makes the
number of retried frames shrink significantly.
The highest rate shown by
Setting the HT_PROT flag in the MAC context command forces all data frames
to be preceded by an RTS frame. There's not much wrong with RTS expect that
it slows our transmit speed down, so we should not enable it unnecessarily.
Because we do not support 40 MHz channels yet we do not need to enable
On Fri, Dec 09, 2016 at 09:53:39AM +0100, Michal Mazurek wrote:
> It might be worth explaining how to load firmware during a fresh
> install, and warn about the dangers of mounting over /mnt. This
> functionality was introduced in 4.4.
>
> While getting online for an install is not really
On Thu, Nov 17, 2016 at 02:58:21PM +0100, Stefan Sperling wrote:
> This change allows iwm(4) users to see which rates they're sending and
> receiving packets at (kinda useful for debugging rate scaling issues).
This is a follow-up fix to the diff quoted below (since committed).
Don't stri
On Thu, Dec 01, 2016 at 07:48:07PM +0100, Stefan Sperling wrote:
> This diff adds mira support to the iwn(4) driver.
>
> I have tested this with:
> iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R
> When reporting test results please mentio
This diff adds mira support to the iwn(4) driver.
I have tested this with:
iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R
When reporting test results please mention which device was tested.
There's a little hack for 4965 hardware because it does not report the
I think "delete" is too strong a word and confusing in the context
of hard disks. What really happens is that the volume is "detached"
and can be reattached later (either manually with bioctl(8), or it
will auto-assemble).
ok?
Index: bioctl.8
On Fri, Nov 25, 2016 at 02:07:30PM +0100, Leo Unglaub wrote:
> Maybe it would be a good idea to put that directly in the installer. Because
> more and more people are going to have to use GPT and stuff in the future.
Yes it would be a good idea. I agree. But code doesn't write itself. ;)
On Fri, Nov 25, 2016 at 12:45:27PM +0100, Leo Unglaub wrote:
> Hey,
>
> On 11/25/16 10:53, Stefan Sperling wrote:
> > It is certainly possible. I have a laptop booting UEFI with softraid
> > crypto and keydisk. Granted, that was installed over a year ago and
> > on
On Fri, Nov 25, 2016 at 12:50:25AM +0100, Leo Unglaub wrote:
> Hey,
> i am trying to install OpenBSD on a Raid1 created by softraid0. My drives
> are sd0 and sd1. The created raid1 is sd3. The install works fine until
> OpenBSD tryes to write the bootblocks. But it fails with the error message:
>
On Sun, Nov 20, 2016 at 11:43:54PM +0100, Stefan Sperling wrote:
> Linux uses 60 retries for Block Ack Requests, which makes some sense (they
> are not sent often, but usually periodically, and are used to negotiate an
> agreement to set up and use block ack).
Oops, sorry, I confused
On Sun, Nov 20, 2016 at 04:54:58PM +0100, Mark Kettenis wrote:
> > Date: Sat, 19 Nov 2016 18:11:23 +0100
> > From: Stefan Sperling <s...@stsp.name>
> >
> > The RTS retry limit we inherited from Linux seems insanely high.
> >
> > It seems to be the
On Sat, Oct 29, 2016 at 01:13:47PM +0200, Stefan Sperling wrote:
> On Sat, Oct 08, 2016 at 07:34:55PM +0200, Mark Kettenis wrote:
> > > The addition might need to be tested on a 1TR1 and 2T3R setups. I can
> > > test the latter, but I have no hardware to test the former.
>
ok?
Index: print-802_11.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
retrieving revision 1.34
diff -u -p -r1.34 print-802_11.c
--- print-802_11.c 8 Oct 2016 14:45:11 - 1.34
+++ print-802_11.c 19 Nov
The RTS retry limit we inherited from Linux seems insanely high.
It seems to be the cause for "bursty" pings and high latency for
smaller packets while larger packets from TCP streams are stuck
in the Tx queue:
64 bytes from 192.168.1.12: icmp_seq=84 ttl=251 time=380.203 ms
64 bytes from
We inherited a bug(?) from Linux where the iwm driver adds all mandatory
OFDM rates (up to 24Mbit/s) to the ACK rate set if the AP does not
advertise _any_ basic OFDM rates. This kills traffic at the edge of
the WLAN cell because e.g. RTS is sent at 24Mbit/s instead of 6Mbit/s
and rarely gets
On Fri, Nov 18, 2016 at 03:01:34PM +0100, Stefan Sperling wrote:
> On Fri, Nov 18, 2016 at 02:37:18PM +0100, Stefan Sperling wrote:
> > While playing around with rate scaling, and testing behaviour when
> > increasing the distance to the AP, I noticed that a lot of successfully
>
On Fri, Nov 18, 2016 at 02:37:18PM +0100, Stefan Sperling wrote:
> While playing around with rate scaling, and testing behaviour when
> increasing the distance to the AP, I noticed that a lot of successfully
> received frames end up getting stuck or discarded in the block ack
>
While playing around with rate scaling, and testing behaviour when
increasing the distance to the AP, I noticed that a lot of successfully
received frames end up getting stuck or discarded in the block ack
buffer logic.
In this situation, I see icmp echo replies arrive in the output
of tcpdump -i
This change allows iwm(4) users to see which rates they're sending and
receiving packets at (kinda useful for debugging rate scaling issues).
To see rates in tcpdump you need to use -y and -v options.
For example: tcpdump -i iwm0 -y IEEE802_11_RADIO -v type data
Writing to a pcap file and then
The global host_interrupt_operation_mode variable can be represented
as a flag. This is just a cosmetic change.
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.146
diff -u -p -r1.146 if_iwm.c
---
On Tue, Oct 11, 2016 at 04:50:09PM +0200, Stefan Sperling wrote:
> On Tue, Oct 11, 2016 at 04:29:24PM +0200, Imre Vadasz wrote:
> > Hi,
> >
> > The sc->sc_uc.uc_intr flag isn't getting reset to 0 in
> > iwm_load_firmware_8000(), so the
> > /* wait for th
On Sat, Oct 08, 2016 at 07:34:55PM +0200, Mark Kettenis wrote:
> > The addition might need to be tested on a 1TR1 and 2T3R setups. I can
> > test the latter, but I have no hardware to test the former.
>
> FWIW, this seems to cause no regressions on:
>
> iwn0 at pci2 dev 0 function 0 "Intel WiFi
This is similar to a recent change in iwm, but it only affects 11n mode
in this driver.
The condition being removed below was added by me before the RTS threshold
was enabled in net80211. So now we should not need it anymore and removing
it might actually improve things by removing RTS overhead
On Wed, Oct 19, 2016 at 02:04:44PM +0200, Jan Stary wrote:
> Since I have applied this patch (dmesg below),
> I haven't seen the errors I was seeing before
> (don't know if it's related).
Good, I've committed this. I haven't seen any downside either.
Thank you for testing.
On Tue, Oct 11, 2016 at 11:32:27PM +0200, Jan Stary wrote:
> On Oct 06 12:46:21, s...@stsp.name wrote:
> > Disable the detailed fatal firmware error log in iwn(4) by default.
>
> These are my iwm errors of today
> on a Dell Latitude E5570.
> I sure don't know what to do with them,
> but I'm glad
On Tue, Oct 11, 2016 at 04:29:24PM +0200, Imre Vadasz wrote:
> Hi,
>
> The sc->sc_uc.uc_intr flag isn't getting reset to 0 in
> iwm_load_firmware_8000(), so the
> /* wait for the firmware to load */
> for (w = 0; !sc->sc_uc.uc_intr && w < 10; w++) {
> err =
On Fri, Oct 07, 2016 at 03:28:19PM +0200, Stefan Sperling wrote:
> Currently tcpdump shows "0 Mbit/s" for any frame sent with 11n HT MCS.
> To make progress easier, I'd like to see which MCS are used on the air,
> by any device.
>
> The change below matches what FreeBSD
Currently tcpdump shows "0 Mbit/s" for any frame sent with 11n HT MCS.
To make progress easier, I'd like to see which MCS are used on the air,
by any device.
The change below matches what FreeBSD did to pass an MCS index via radiotap.
This simply writes the MCS index into a previously unused
Imre Vadasz pointed out that rate sets managed by net80211 are sorted
by effective data rate speed, while the iwm_rates array sorts CCK rates
(1 - 11 Mbit/s) before OFDM rates (6Mbit/s - 54Mbit/s).
rate set (11g): 1, 2, 5.5, 6, 9, 11, 12, 18, 24, 36, 54
iwm_rates: 1, 2, 5.5, 11, 6, 9, 12,
On Thu, Oct 06, 2016 at 06:51:04PM +0200, Stefan Sperling wrote:
> athn(4) has a hack which disables lower Tx retry rates if RTS is used.
>
> I don't understand why this was added. Perhaps the assumption was
> that RTS will prevent transmission failures outright.
I believe I've foun
athn(4) has a hack which disables lower Tx retry rates if RTS is used.
I don't understand why this was added. Perhaps the assumption was
that RTS will prevent transmission failures outright. However, not
letting the hardware retry at lower rates seems to hurt at least my
athn-based AP a little.
Stop using RTS for every data frame sent by iwm(4).
RTS adds unneccessary overhead if small data frames are sent.
The USE_RTS flag in iwm's LQ command enables RTS unconditionally, so only
set it while the AP is enforcing protection. The flag will be kept up-to-date
as a side effect of
On Thu, Oct 06, 2016 at 10:49:21AM +0200, Imre Vadasz wrote:
> Hi,
> This patch improves the error handling iwm_rx_addbuf(), specifically in
> out-of-memory and mbuf exhaustion cases.
>
> Keep an additional/spare bus_dmamap_t object around to make error handling
> for bus_dmamap_load_mbuf()
Disable the detailed fatal firmware error log in iwn(4) by default.
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.172
diff -u -p -r1.172 if_iwn.c
--- if_iwn.c5 Sep 2016 08:18:18 -
I don't think any normal human being understands the lines
printed by the wpi(4) driver after 'fatal firmware error'.
wpi0: fatal firmware error
firmware error log (count=1):
error type = "UNKNOWN" (0x0013)
error data = 0x0070
branch link = 0x08B60274
interrupt
It looks like iwm firmware does not like a MAC context which does not
specify the AP's BSSID.
The driver currently adds such a context when initializing the hardware
for the first time after boot (with the BSSID set to all zeros, I also tried
a broadcast address and that doesn't work either).
On Wed, Sep 21, 2016 at 12:04:18PM +0200, Stefan Sperling wrote:
> Here's another update which fixes the data rates ACKs are sent at.
> This helps block ack with multiple associated clients.
>
> There still seems to be an occasional problem during the initial association
On Wed, Sep 21, 2016 at 12:04:45AM +0200, Stefan Sperling wrote:
> On Tue, Sep 20, 2016 at 02:35:18AM +0200, Stefan Sperling wrote:
> > I'd like to know if this diff helps with iwm(4) performance issues
> > some people have been reporting.
> >
> > This is not done
On Tue, Sep 20, 2016 at 02:35:18AM +0200, Stefan Sperling wrote:
> I'd like to know if this diff helps with iwm(4) performance issues
> some people have been reporting.
>
> This is not done yet and some details don't really make sense, especially
> the #if 0 hiding of what should
When processing an ADDBA request, iwm(4) runs a task which sends a
command to the firmware and waits for confirmation. This command can
fail and there's currently no way we can recover from such an error.
With the diff below, drivers can return EBUSY from their ic_ampdu_rx_start()
handler which
Parse the DTIM count and period advertised in beacons and store them
in the node structure. This should be useful for iwm(4) in the future.
The TIM IE is documented in 802.11-2012 section "8.4.2.7 TIM element".
ok?
There used to be code in iwm(4) which read these values from the ic
I'd like to know if this diff helps with iwm(4) performance issues
some people have been reporting.
This is not done yet and some details don't really make sense, especially
the #if 0 hiding of what should be correct code -- yet, enabling that code
makes the problem come back.
But hopefully this
This removes unnecessary fluff from the AUX STA code and simplifies error
handling around iwm_send_cmd_pdu_status() calls. While at it I spotted an
uninitalized 'status' variable in iwm_add_int_sta_common() (note how
iwm_send_cmd_pdu_status() won't always initialize *status).
Index: if_iwm.c
Replace the ioctl tsleep/wakeup BUSY flag dance with an rwlock.
ok?
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.124
diff -u -p -r1.124 if_iwm.c
--- if_iwm.c4 Sep 2016 17:01:59 -
This gets rid of almost all the silly enums in iwm's header file.
Replace them with #define to better match the style of other drivers.
No functional change intended. This conversion was semi-automatic
and additional eyeballing is very much appreciated.
Index: if_iwm.c
This diff enables the short guard interval (SGI) feature of 802.11n.
In theory this should raise the max data rate from 65Mbit/s to 72Mbit/s.
To check if your AP supports SGI, associate to your AP and then run:
tcpdump -n -i iwn0 -s 1500 -y IEEE802_11_RADIO -v type mgt subtype beacon
and look
This diff enables the short guard interval (SGI) feature of 802.11n.
In theory this should raise the max data rate from 65Mbit/s to 72Mbit/s.
To check if your AP supports SGI, associate to your AP and then run:
tcpdump -n -i iwm0 -s 1500 -y IEEE802_11_RADIO -v type mgt subtype beacon
and look
This diff makes tcpdump display details of association requests.
These are interesting because clients announce HT capabilities there.
We can share some printing code with beacons.
Use with something like tcpdump -s 1500 -v -y IEEE802_11_RADIO -i iwn0
Index: print-802_11.c
On Thu, Sep 01, 2016 at 11:26:10AM +0200, Imre Vadasz wrote:
> Hi,
> The iwm_firmware_load_chunk() function returns the value of the
> uninitialized int error variable, when the "while (!sc->sc_fw_chunk_done)"
> loop terminates immediately. I saw this happen repeatedly in the init
> firmware
This makes ifconfig display baudrates defined in ifmedia.h tables.
Before (prints media subtype):
$ ifconfig iwn0 | grep media:
media: IEEE802.11 autoselect (OFDM6 mode 11a)
$ ifconfig em0 | grep media:
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
After
'instance' is the name of an ifconfig subcommand related to ifmedia
so the name of the setinstance() function is slightly confusing.
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.327
diff
ifconfig scan displays RSSI (received signal strength indicator) values.
If the driver sets ic->ic_max_rssi the value is displayed as a percentage
of ic_max_rssi. Otherwise ifconfig displays the value as dBm.
The problem in the dBm case is that many drivers end up reporting a positive
value. The
On Sat, Aug 27, 2016 at 07:34:53PM +0200, Ingo Schwarze wrote:
> Hi Todd,
>
> Todd C. Miller wrote on Sat, Aug 27, 2016 at 10:28:14AM -0600:
>
> > Now that we have a handy size_t scratch variable,
> > we can use it to store the return value of mbrtowc()
> > instead of storing it in an int.
Did anyone test this?
On Wed, Jul 20, 2016 at 02:48:02PM +0200, Stefan Sperling wrote:
> Currently, if running in 11n mode, iwm always enables RTS/CTS to protect
> frames it is sending.
>
> To recap what the various HT protection modes are:
>
> /*
> * HT protection m
On Sun, Jul 31, 2016 at 05:26:21PM +0200, Noth wrote:
> Now testing with a July 17th kernel, everything works fine at .11n speeds
> but the ping goes from 1ms to 100+ms for one packet on average every 50-60
> packets.
Can you pin-point the iwm commit which changed this?
On Tue, Aug 16, 2016 at 05:34:20PM -0400, James Hastings wrote:
> On 8/16/16, Stefan Sperling <s...@stsp.name> wrote:
> >
> > Your patch can't be applied with patch(1) because directory
> > components are missing on the Index: lines even though modified
> >
If the stack demands protection by setting the USEPROT flag then set
the corresponding bit in the Tx command regardless of frame length.
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.98
diff -u
On Tue, Aug 16, 2016 at 11:31:07AM +0100, Stuart Henderson wrote:
> On 2016/08/15 14:46, Stefan Sperling wrote:
> > The wireless stack usually runs its scanning loop once per frequency band.
> > It begins with 5GHz so that APs on this band are preferred. Within a band,
> > an
On Mon, Aug 08, 2016 at 11:45:10PM -0400, James Hastings wrote:
> Hi all,
>
> The following patch adds RT5390/RT5392 support to ral(4).
Your patch can't be applied with patch(1) because directory
components are missing on the Index: lines even though modified
files are spread across several
The wireless stack usually runs its scanning loop once per frequency band.
It begins with 5GHz so that APs on this band are preferred. Within a band,
an AP with the best RSSI (receive signal strength indicator) is chosen,
after matching all other desired parameters such as the ESSID etc.
I am not
On Sun, Aug 14, 2016 at 12:40:33AM +, Prabhu Gurumurthy wrote:
> I think I might be missing firmware, which might need to be loaded, but
> linux-firmare.git has so many firmware, I am lost trying to find the
> correct one in that repo and I am lost in firmware.openbsd.org as well.
Our rtwn(4)
On Mon, Aug 08, 2016 at 11:45:10PM -0400, James Hastings wrote:
> Hi all,
>
> The following patch adds RT5390/RT5392 support to ral(4).
>
> Ported from FreeBSD r278551 and r36.
>
> Running smoothly with RT3090 and various RT5390 cards.
Thank you for working on this, James.
I'll review your
On Sat, Jul 23, 2016 at 12:15:59AM +0200, Holger Mikolon wrote:
> I played with different bpf filters and came up with the below patch. It
> compares the interface's LLADDR with the the respective address in the
> bootp structure instead of the ether header. I don't know if this is the
> right way
Same rts threshold fix as for rtwn(4).
Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.65
diff -u -p -r1.65 if_urtwn.c
--- if_urtwn.c 17 Jun 2016 10:53:55 - 1.65
+++ if_urtwn.c 20
The rtwn(4) driver ignores the rts threshold value set by the stack.
This fixes it:
Index: if_rtwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_rtwn.c,v
retrieving revision 1.22
diff -u -p -r1.22 if_rtwn.c
--- if_rtwn.c 17 Jun 2016
When I run iwn in monitor mode it flashes its LED like it
was trying to give me epileptic seizures.
With this diff, it's much less irritating.
ok?
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision
Currently, if running in 11n mode, iwm always enables RTS/CTS to protect
frames it is sending.
To recap what the various HT protection modes are:
/*
* HT protection modes (see 802.11-2012 8.4.2.59)
*/
enum ieee80211_htprot {
IEEE80211_HTPROT_NONE = 0, /* only 20/40MHz HT STAs
Beacon filter settings in iwm(4) prevent the device from passing
beacons to net80211 while associated to an AP. The implication is
that net80211 does not see HT protection updates, so it never tells
the driver to update HT protection settings.
This can cause interference problems.
I believe this
I'm not sure if this change has any real effect, but as long as we don't
support 11n TX aggregation it's probably better to set the firmware's
aggregation limit to 1 frame (which means 'no aggregation').
Index: if_iwm.c
===
RCS file:
801 - 900 of 1452 matches
Mail list logo
