Re: userland clock_gettime proof of concept

2020-05-15 Thread Paul Irofti
Here is an updated diff that addresses the following points mentioned by kettenis@: - syscall fallback was implemented from the first version - the low resolution clock argument, I think, was shown not to be a problem - TSC and HPET alternatives were discussed, and if we decide to add

libpcap: allow breaking out of loop when using savefile

2020-05-15 Thread Caspar Schutijser
Hi, Below is a patch that makes breaking out of the loop work when using a savefile. The pcap_breakloop() function was backported from tcpdump.org libpcap to OpenBSD libpcap by djm@ on Nov 18, 2005. The bits to make pcap_breakloop() work were backported to pcap-bpf.c [1] but not to savefile.c

Re: iwx: fix phy context command

2020-05-15 Thread sven falempin
> > # patch -p0 -l < ./patch.diff >> > -- > |-- sys/dev/pci/if_iwx.c > |+++ sys/dev/pci/if_iwx.c > -- > Patching file sys/dev/pci/if_iwx.c using Plan A... > Hunk #1 succeeded at 343. > Hunk #2 succeeded at 3771. > Hunk #3 succeeded at 3810. > Hmm...

Re: iwx: fix phy context command

2020-05-15 Thread sven falempin
On Fri, May 15, 2020 at 9:29 AM Stefan Sperling wrote: > iwx(4) firmware understands two different variants of the "PHY_CONTEXT" > command. Both variants are documented with the same command API version > number, but they use different sizes for an embedded struct that contains > information

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

2020-05-15 Thread Stefan Sperling
On Fri, May 15, 2020 at 11:11:44AM -0400, sven falempin wrote: > Index: if_iwx.c > === > RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v > retrieving revision 1.11 > diff -u -p -r1.11 if_iwx.c > --- if_iwx.c29 Apr 2020 13:13:30 -

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

2020-05-15 Thread sven falempin
On Thu, May 14, 2020 at 5:55 AM Stefan Sperling wrote: > On Wed, May 13, 2020 at 07:55:02PM -0400, sven falempin wrote: > > 'good news' > > > > I build a custom kernel with the DEBUG flag for the driver > > > I 'works' , > > This means that the driver is doing something too fast on your

iwm(4): re-add CCMP hardware offload support

2020-05-15 Thread Stefan Sperling
This has been attempted before, but had to backed out because in some cases firmware was failing to decrypt a subset of received frames, which resulted in packet loss. That was before we updated all iwm(4) devices to newer firmware in the previous release cycle. I hope we won't see such problems

Re: iwn/athn/wpi: fix CCMP replay check with HW crypto

2020-05-15 Thread Solene Rapenne
Le Fri, 15 May 2020 11:02:46 +0200, Stefan Sperling a écrit : > On Fri, May 08, 2020 at 10:53:30AM +0200, Stefan Sperling wrote: > > So the diff below contains just the reordering fix for drivers using > > hardware acceleration for WPA. > > Is there anybody who wants to OK this? > > To

iwx: fix phy context command

2020-05-15 Thread Stefan Sperling
iwx(4) firmware understands two different variants of the "PHY_CONTEXT" command. Both variants are documented with the same command API version number, but they use different sizes for an embedded struct that contains information about channels. Which variant to use depends on whether the

Re: ospfctl json support

2020-05-15 Thread Richard Chivers
Hi, I have now resolved the spacing/tabbing issues I think correctly following style(9), along with a couple of other indent issues. Would appreciate a cursory look at this stage to spot any further common issues. I have read through style(9) and can't spot anything else, but I may be missing

Re: iwn/athn/wpi: fix CCMP replay check with HW crypto

2020-05-15 Thread Stefan Sperling
On Fri, May 08, 2020 at 10:53:30AM +0200, Stefan Sperling wrote: > So the diff below contains just the reordering fix for drivers using > hardware acceleration for WPA. Is there anybody who wants to OK this? To recap: Currently, CCMP replay checking is skipped for aggregated 11n frames on