Re: iwn: improve processing of block ack notifications

On Fri, Apr 17, 2020 at 06:30:22PM +0200, Stefan Sperling wrote: > On Fri, Apr 17, 2020 at 04:03:30PM +0200, Stefan Sperling wrote: > > In particular, this fixes wrong assumptions about what the data in the > > firmware's "compressed block ack" notifications is supposed to represent, > > and

Re: iwn: improve processing of block ack notifications

On Fri, Apr 17, 2020 at 04:03:30PM +0200, Stefan Sperling wrote: > In particular, this fixes wrong assumptions about what the data in the > firmware's "compressed block ack" notifications is supposed to represent, > and actually pieces information about individual subframes of aggregated > frames

Re: suggest to run rpki-client hourly

Todd C. Miller wrote: > On Thu, 16 Apr 2020 17:18:15 -0600, "Theo de Raadt" wrote: > > > I agree we should try 1 hour. > > > > > +#~ * * * * -s -n rpki-client -v && bgpctl > > > reload > > > > I would prefer if you use -ns rather than the two seperate options. >

Re: implement locale(1) charmap argument

On Fri, Apr 17, 2020 at 03:05:06PM +0200, Ingo Schwarze wrote: > Naively, it does seem like it would make sense to have "locale -m" > print a list of possible output values of "locale chardef", so i'm > not opposed to adding "US-ASCII" to it. But that doesn't appear to > be how it works

iwn: improve processing of block ack notifications

This applies on top of a previous diff I sent, the one to make use of the entire firmware retry table. Recently I have spent a good amount of time trying to reverse-engineer the sparsely documented behaviour of both iwn(4) and iwm(4) firmware with respect to Tx aggregation. For details, see my

iwn(4): always traverse the entire multi-rate retry table

This adapts the use of the firmware multi-rate retry table to always make use of all available slots. The table specifies 16 Tx rates the firmware can use, one per Tx attempt. For example, on a 5 GHz channel the current code fills this table with static values like this: MCS-7 MCS-6 MCS-5

iwn: work around fifo underrun Tx errors

This diff works around FIFO_UNDERRUN (0x84) Tx errors being reported by iwn(4) firmware. When this error occurs, it tends to occur multiple times in a row. Affected frames are lost and never get transmitted, and traffic stalls for a while. This affects tcpbench very visibly. I don't understand

Re: suggest to run rpki-client hourly

On Thu, 16 Apr 2020 17:18:15 -0600, "Theo de Raadt" wrote: > I agree we should try 1 hour. > > > +#~ * * * * -s -n rpki-client -v && bgpctl reload > > I would prefer if you use -ns rather than the two seperate options. The option parsing doesn't currently support bundling

iwn(4): TID fix for block ack request frames

Make iwn(4) put the correct traffic identifier (TID) into the Tx command when sending block ack request (BAR) frames. This is not critical but occasionally I have seen the firmware send a BAR frame with a bogus TID value, which the receiver will simply discard. Writing the correct TID into the Tx

Re: implement locale(1) charmap argument

Hi Stefan and Todd, Stefan Sperling wrote on Fri, Apr 17, 2020 at 08:55:29AM +0200: > On Thu, Apr 16, 2020 at 09:35:18PM +0200, Ingo Schwarze wrote: >>$ locale -m >> UTF-8 >>$ locale charmap >> UTF-8 >>$ LC_ALL=C locale charmap >> US-ASCII >>$ LC_ALL=POSIX locale charmap >>

Re: implement locale(1) charmap argument

On Thu, Apr 16, 2020 at 09:35:18PM +0200, Ingo Schwarze wrote: >$ locale -m > UTF-8 >$ locale charmap > UTF-8 >$ LC_ALL=C locale charmap > US-ASCII >$ LC_ALL=POSIX locale charmap > US-ASCII I am OK with your diff, and noticed a separate issue with -m which is exposed by

Re: suggest to run rpki-client hourly

On Thu, Apr 16, 2020 at 05:18:15PM -0600, Theo de Raadt wrote: > Job Snijders wrote: > > > In cases where rpki-client for some reason ends up taking longer than an > > hour, the next execution attempt of the command will be skipped. Better > > to just try again an hour later, this helps avoid