Hi,
I ran into a problem where when using /31 netmasks on point to point
links, I am unable to add a larger summary route that happens to have
the same network address as the /31 link route the box has. It's a
bit hard to explain so hopefully the art below helps.
bsd1
> Date: Sat, 27 Nov 2021 20:28:39 +
> From: Stuart Henderson
>
> I have some amd64 machines which are doing 600+ gettimeofday/second
> at quiet times and way more when they're busy and I'd quite like to
> get them onto userland tsc, however they're dual socket and the skew
> between cores on
Hi Stefan,
* Stefan Sperling wrote:
> 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
I have some amd64 machines which are doing 600+ gettimeofday/second
at quiet times and way more when they're busy and I'd quite like to
get them onto userland tsc, however they're dual socket and the skew
between cores on the different sockets is too great. There's no way to
disable a socket in
While fiddling with ehci.c and fighting with urndis I noticed that most
of the debugging printf's use explicit names, which is inconvenient for
grep'ing. Also, couple of items used wrong function names
(ehci_check_intr instead of ehci_check_qh_intr).
Compilation tested with DIAGNOSTIC and
anyone?
On 2021-11-18 09:02 +01, Florian Obser wrote:
> This is split in two for easier review and I also intend to commit it
> like this.
>
> The first diff shuffles setting of if_index around so that it's
> available in all switch cases and uses it consistently instead of
> ifm->ifm_index.
>
>
On Mon, Nov 22, 2021 at 04:28:54PM +0100, Gerhard Roth wrote:
>
> Your OpenBSD pcap contains not "URB_CONTROL in" packets. Don't know where
> they got lost but since you cannot see any data sent by the function on the
> control pipe, it is almost impossible to do any debugging here. You only see
EVP_CIPHER_CTX will become opaque, so this will need to change.
Allocate ctx once in esp_init() and modify all accesses accordingly.
Two more things:
Fix the error check of EVP_CipherInit() in esp_init(). The return
values are 1 for success and 1 for failure, so the usual OpenSSL idiom
applies.
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
On 2021-11-27 12:44 +0100, Stefan Sperling wrote:
> 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 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
11 matches
Mail list logo