Only bnxt and mcx support 50. Intel chips that do are 800 series, beyond ixl.
On August 11, 2021 5:13:11 p.m. Chris Cappuccio wrote:
ha...@sdf.org [ha...@sdf.org] wrote:
> Hi folks!
>
> I wonder if OBSD supports 50Gbe network cards. And what is the cable
> standard to support such data
Thanks a lot Stuart! Really appreciate your insights.
I've been running some more tests and here are some new results:
1.
Without MAC spoofing and a statically assigned IP address, axe lasted
around twelve days on an AX88772B before throwing the following error:
axe0: watchdog timeout
On 2021-08-11, Julian Smith wrote:
> On Mon, 9 Aug 2021 17:35:36 - (UTC)
> Stuart Henderson wrote:
>
>> On 2021-08-08, Julian Smith wrote:
>> > I've been trying to get a yoctopuce (https://www.yoctopuce.com/) USB
>> > sensor to work on OpenBSD, but have run into problems.
>> >
>> > The
On Mon, 9 Aug 2021 17:35:36 - (UTC)
Stuart Henderson wrote:
> On 2021-08-08, Julian Smith wrote:
> > I've been trying to get a yoctopuce (https://www.yoctopuce.com/) USB
> > sensor to work on OpenBSD, but have run into problems.
> >
> > The sensor has Linux code
> >
Brad Smith [b...@comstyle.com] wrote:
> Only bnxt and mcx support 50. Intel chips that do are 800 series, beyond ixl.
>
Oh and bnxt does support multiple queues I was wrong in that last email.
Hi,
Since the recent Mesa update to 21.1.5 I have been experiencing a partial hang
in X. It is triggered mostly while browsing in qutebrowser (which is the most
graphically intensive program on my desktop). When this happens, the display
freezes but the cursor can be moved and it even changes
ha...@sdf.org [ha...@sdf.org] wrote:
> > Hi folks!
> >
> > I wonder if OBSD supports 50Gbe network cards. And what is the cable
> > standard to support such data transfers ?
> >
> > Thanks.
> >
> > --
> > The lion and the tiger may be more powerful, but the wolves do not perform
> > in the circus
On Wednesday, August 11th, 2021 at 7:57 AM, m brandenberg
wrote:
> Check msg.msg_flags here. I think you will receive a hint.
msg_flags is always zero. Seems okay, after all, the FDs are received correctly.
On Tue, Aug 10, 2021 at 12:13 PM mid wrote:
> On Monday, August 9th, 2021 at 5:36 AM, Philip Guenther <
> guent...@gmail.com> wrote:
>
> > If you're 100% sure you have it right, then it should be easy to provide
> a
> > program that demonstrates
> > 1. passing an fd between processes
> > 2.
On 2021-08-11, Vladimir Nikishkin wrote:
> I do not think my setup is related to "TLS Inspection".
>
> There is no problem connecting to the TLS-enabled backend. The problem
> appears when connecting to the HTTP backend, when, _at the same time_,
> in the same relay there is another redirect to
On 21/08/11 04:34pm, Vladimir Nikishkin wrote:
> I do not think my setup is related to "TLS Inspection".
Apologies, my misunderstanding. I always forget I divert traffic to to
localhost in my setup. Anyway,
> There is no problem connecting to the TLS-enabled backend. The problem
> appears when
I do not think my setup is related to "TLS Inspection".
There is no problem connecting to the TLS-enabled backend. The problem
appears when connecting to the HTTP backend, when, _at the same time_,
in the same relay there is another redirect to the TLS backend.
On Wed, 11 Aug 2021 at 16:15,
On 21/08/11 02:40pm, Vladimir Nikishkin wrote:
> However, if I keep "with tls", the requests to port 81 are going
> encrypted, and are failing with the following message in relayd logs:
> `SSL routines:ST_CONNECT:tlsv1 alert protocol version`,
> `TLS handshake error: handshake failed:`.
What
On Tue, 10 Aug 2021, mid wrote:
len = recvmsg(socket, , 0);
if(len <= 0) {
return -1;
}
Check msg.msg_flags here. I think you will receive a hint.
--
Monty Brandenberg
Hello, everyon
I have a super simple (sanitised) relayd.conf
```
$ext_ip = 192.168.1.1
table { 127.0.0.1 }
table { 127.0.0.1 }
http protocol "p-https" {
tls session tickets
tls keypair domain.example
tls ca file "/etc/ssl/cert.pem"
http websockets
tcp { nodelay, sack, socket buffer 65536,
15 matches
Mail list logo
