re(4) hardware has some useful counters that are worth looking at:
dlg@router ~$ kstat re-stats
re0:0:re-stats:0
TxOk: 12697 packets
RxOk: 22919 packets
TxEr: 0 packets
RxEr: 0 packets
MissPkt: 0 packets
FAE: 8371 packets
On Fri, Apr 22, 2022 at 12:28:21AM +0200, Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2022.04.20 15:12:57 +0200:
> > On Wed, Apr 20, 2022 at 03:00:15PM +0200, Theo Buehler wrote:
> > > Found this when looking at the timezone issue a couple of weeks back and
> > > then forgo
Claudio Jeker(cje...@diehard.n-r-g.com) on 2022.04.20 15:12:57 +0200:
> On Wed, Apr 20, 2022 at 03:00:15PM +0200, Theo Buehler wrote:
> > Found this when looking at the timezone issue a couple of weeks back and
> > then forgot about it:
> >
> > This setenv() + localtime() looks like a hack to me a
I still think it is worth to have refcount debugging in generic
kernel dt(4). Having tools is easier than first adding printf to
hunt a bug. I see no downside.
ok?
bluhm
Index: dev/dt/dt_prov_static.c
===
RCS file: /data/mirror/op
> Date: Thu, 21 Apr 2022 22:17:31 +0200
> From: Alexander Bluhm
>
> On Mon, Apr 18, 2022 at 08:33:06AM +, Visa Hankala wrote:
> > I think the sanest solution is to add the release and acquire barriers
> > in refcnt_rele().
>
> Getting memory barriers right is too complicated for developers
>
On Mon, Apr 18, 2022 at 08:33:06AM +, Visa Hankala wrote:
> I think the sanest solution is to add the release and acquire barriers
> in refcnt_rele().
Getting memory barriers right is too complicated for developers
doing MP stuff. The existing locking and refcount primitives have
to implement
On 2022-04-21 21:10 +02, Alexander Bluhm wrote:
> On Thu, Apr 21, 2022 at 08:56:07PM +0200, Otto Moerbeek wrote:
>> > Currently it allows all options. Should I make it specific to
>> > router alert with IGMP or ICMP6?
>>
>> To me it looks like the icmp6 case already is limited to MLD?
>
> The qu
On Thu, Apr 21, 2022 at 08:56:07PM +0200, Otto Moerbeek wrote:
> > Currently it allows all options. Should I make it specific to
> > router alert with IGMP or ICMP6?
>
> To me it looks like the icmp6 case already is limited to MLD?
The question is the other way around. My current diff allows an
On Thu, Apr 21, 2022 at 07:08:38PM +0200, Alexander Bluhm wrote:
> Hi,
>
> IGMP and ICMP6 for multicast packets have router alert options.
> Per default pf drops all IP packets with options. Usually people
> ask what is wrong until someone points out that they have to use a
> pf rule with allow-
On Thu, Apr 21, 2022 at 11:07:50AM -0600, Todd C. Miller wrote:
> On Thu, 21 Apr 2022 09:35:44 -0700, Jeremy Mates wrote:
>
> > The cause is an unguarded use of the NULL output pointer. I am pretty
> > sure an .exrc cannot cause this condition (map rhs requires
> > something, not nothing) only rec
Hi,
IGMP and ICMP6 for multicast packets have router alert options.
Per default pf drops all IP packets with options. Usually people
ask what is wrong until someone points out that they have to use a
pf rule with allow-opts.
As this is normal behavior and our kernel generates such packets,
the p
On Thu, 21 Apr 2022 09:35:44 -0700, Jeremy Mates wrote:
> The cause is an unguarded use of the NULL output pointer. I am pretty
> sure an .exrc cannot cause this condition (map rhs requires
> something, not nothing) only recompiling with a NULL output string
> for some command.
>
> One fix is to g
One may wish to disable the arrow keys in vi(1), because it is cold and
the jacket will sometimes brush up against said keys, causing unexpected
cursor motions. This may be done by modifying cl/cl_term.c to set
"kcud1" and friends to use NULL for the output string, plus some obvious
tkp->output str
On Wed, Apr 20, 2022 at 08:12:51PM +0200, Alexander Bluhm wrote:
> mvs@ reminded me of a crash I have seen in December. Route timers
> are not MP safe, but I think this can be fixed with a mutex. The
> idea is to protect the global lists with a mutex and move the rttimer
> into a temporary list.
On Fri, Apr 08, 2022 at 12:56:12PM +0200, Alexander Bluhm wrote:
> Hi,
>
> I now the right time to commit the parallel forwarding diff?
>
> Known limitiations are:
> - Hrvoje has seen a crash with both pfsync and ipsec on his production
> machine. But he cannot reproduce it in his lab.
> - TCP
On Thu, Apr 21, 2022 at 03:25:03PM +0200, Alexander Bluhm wrote:
> Hi,
>
> As claudio@ wants to refactor router timer before making them MP
> safe, I would like to protect them with kernel lock. It should fix
> this panic.
>
> https://marc.info/?l=openbsd-tech&m=164038527425440&w=2
>
> I hope t
Hi,
As claudio@ wants to refactor router timer before making them MP
safe, I would like to protect them with kernel lock. It should fix
this panic.
https://marc.info/?l=openbsd-tech&m=164038527425440&w=2
I hope this is the final step before running IP forwarding in
parallel.
ok?
bluhm
Index:
Hello,
On Thu, Apr 21, 2022 at 02:42:45PM +0200, Alexander Bluhm wrote:
> On Wed, Apr 20, 2022 at 11:22:27PM +0200, Alexandr Nedvedicky wrote:
> > updated diff is below
>
> OK bluhm@
>
> You have to merge again, as I removed #ifdef PFSYNC_DEBUG and added
> a #ifdef DIAGNOSTIC. Sorry.
>
th
On Wed, Apr 20, 2022 at 11:22:27PM +0200, Alexandr Nedvedicky wrote:
> updated diff is below
OK bluhm@
You have to merge again, as I removed #ifdef PFSYNC_DEBUG and added
a #ifdef DIAGNOSTIC. Sorry.
> 8<---8<---8<--8<
> diff --git a/sys/ne
On Thu, Apr 21, 2022 at 02:15:14PM +0200, Claudio Jeker wrote:
> On Thu, Apr 21, 2022 at 02:08:01PM +0200, Theo Buehler wrote:
> > On Thu, Apr 21, 2022 at 01:14:31PM +0200, Claudio Jeker wrote:
> > > So here is the cleanup of filemode.c and also a bit of cleanup in parse.c
> > > This should also fi
On Thu, Apr 21, 2022 at 02:08:01PM +0200, Theo Buehler wrote:
> On Thu, Apr 21, 2022 at 01:14:31PM +0200, Claudio Jeker wrote:
> > So here is the cleanup of filemode.c and also a bit of cleanup in parse.c
> > This should also fix a few bugs in parse_load_certchain() (mainly
> > memleaks).
>
> A co
On Thu, Apr 21, 2022 at 01:14:31PM +0200, Claudio Jeker wrote:
> So here is the cleanup of filemode.c and also a bit of cleanup in parse.c
> This should also fix a few bugs in parse_load_certchain() (mainly
> memleaks).
A couple of suggestions for parse_load_certchain() below.
ok
>
> --
> :wq
So here is the cleanup of filemode.c and also a bit of cleanup in parse.c
This should also fix a few bugs in parse_load_certchain() (mainly
memleaks).
--
:wq Claudio
Index: cert.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/cert.c,v
On Wed, Apr 20, 2022 at 08:12:51PM +0200, Alexander Bluhm wrote:
> Hi,
>
> mvs@ reminded me of a crash I have seen in December. Route timers
> are not MP safe, but I think this can be fixed with a mutex. The
> idea is to protect the global lists with a mutex and move the rttimer
> into a tempora
On 20.4.2022. 23:22, Alexandr Nedvedicky wrote:
> Hello,
>
> On Wed, Apr 20, 2022 at 03:43:06PM +0200, Alexander Bluhm wrote:
>> On Sat, Apr 09, 2022 at 01:51:05AM +0200, Alexandr Nedvedicky wrote:
>>> updated diff is below.
>> I am not sure what Hrvoje actually did test and what not. My
>> impre
On 20.4.2022. 20:12, Alexander Bluhm wrote:
> Hi,
>
> mvs@ reminded me of a crash I have seen in December. Route timers
> are not MP safe, but I think this can be fixed with a mutex. The
> idea is to protect the global lists with a mutex and move the rttimer
> into a temporary list. Then the ca
> Date: Thu, 21 Apr 2022 11:49:45 +1000
> From: Jonathan Gray
>
> On Wed, Apr 20, 2022 at 05:17:58PM -0500, joshua stein wrote:
> > xenodm supports login_fbtab(3) to chown devices but it currently
> > doesn't do anything because /etc/fbtab does not list /dev/ttyC4. It
> > uses the GiveConsole
27 matches
Mail list logo
