Hi,
The TUNNEL in the man ifconfig(8) is described as follows:
TUNNEL
tunneldomain rtable
^^here
Use routing table rtable instead of the default table. The
^^here
tunnel does not need to terminate in the
> On 14 Jul 2022, at 05:51, Visa Hankala wrote:
>
> On Thu, Jul 14, 2022 at 04:39:33AM +0300, Vitaliy Makkoveev wrote:
>> It looks like sometimes the `unp_conn' doesn't reloaded in
>> the "unp->unp_conn != unp2" check, and READ_ONCE() should prevent this.
>
> Are you sure about the
On Thu, Jul 14, 2022 at 04:39:33AM +0300, Vitaliy Makkoveev wrote:
> It looks like sometimes the `unp_conn' doesn't reloaded in
> the "unp->unp_conn != unp2" check, and READ_ONCE() should prevent this.
Are you sure about the non-reloading of unp->unp_conn? I did a quick
look in the compiled
It looks like sometimes the `unp_conn' doesn't reloaded in
the "unp->unp_conn != unp2" check, and READ_ONCE() should prevent this.
unp_solock_peer(struct socket *so)
{
struct unpcb *unp, *unp2;
struct socket *so2;
unp = so->so_pcb;
again:
if ((unp2 =
Christian Weisgerber wrote:
> Scott Cheloha:
>
> > > kern.timecounter.tick=1
> > > kern.timecounter.timestepwarnings=0
> > > kern.timecounter.hardware=i8254
> > > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000)
> > > acpitimer0(1000)
> >
> > This is expected behavior with the
On Wed, Jul 13, 2022 at 05:43:59PM +0100, Stuart Henderson wrote:
> >
> > Not sure how to handle long output in different way. If you don't
> > specify wgdesc to the ifconfig, the diff doesn't change anything and
> > ifconfig(8) output is exactly the same. If you don't find this feature
> >
On 2022/07/13 16:18, Mikolaj Kucharski wrote:
> On Wed, Jul 13, 2022 at 10:02:30AM -0600, Theo de Raadt wrote:
> > Mikolaj Kucharski wrote:
> >
> > > I took the libery and refreshed the patch. What I did so far:
> > >
> > > - compiled GENERIC.MP on amd64
> > > - compiled new ifconfig, same arch
On Wed, Jul 13, 2022 at 10:02:30AM -0600, Theo de Raadt wrote:
> Mikolaj Kucharski wrote:
>
> > I took the libery and refreshed the patch. What I did so far:
> >
> > - compiled GENERIC.MP on amd64
> > - compiled new ifconfig, same arch
> > - booted up new bsd.mp with the patch
> > - when wgdesc
Mikolaj Kucharski wrote:
> I took the libery and refreshed the patch. What I did so far:
>
> - compiled GENERIC.MP on amd64
> - compiled new ifconfig, same arch
> - booted up new bsd.mp with the patch
> - when wgdesc is not set, pre-patch ifconfig seems to work
> - when with new ifconfig I set
On Wed, Jul 13, 2022 at 03:37:05PM +, Mikolaj Kucharski wrote:
> Example from running -current:
>
> pce-0067# ifconfig.new wg0
> wg0: flags=80c3 mtu 1420
> index 8 priority 0 llprio 3
> wgport 51820
> wgpubkey qcb...
> wgpeer klM...
>
I took the libery and refreshed the patch. What I did so far:
- compiled GENERIC.MP on amd64
- compiled new ifconfig, same arch
- booted up new bsd.mp with the patch
- when wgdesc is not set, pre-patch ifconfig seems to work
- when with new ifconfig I set wgdesc, old ifconfig wg segfaults
On Wed, Jul 13, 2022 at 02:18:53PM +0200, Otto Moerbeek wrote:
> Hi,
>
> after a prompt from stsp@ and florian@, reporting that newfs_msdos
> fails when given an $duid.i argument, I set down to see what could be
> going on. My test using an USB stick failed to reprdouce the problem.
> Then I
On Wed, Jul 13, 2022 at 02:18:53PM +0200, Otto Moerbeek wrote:
> Hi,
>
> after a prompt from stsp@ and florian@, reporting that newfs_msdos
> fails when given an $duid.i argument, I set down to see what could be
> going on. My test using an USB stick failed to reprdouce the problem.
> Then I
Hi,
after a prompt from stsp@ and florian@, reporting that newfs_msdos
fails when given an $duid.i argument, I set down to see what could be
going on. My test using an USB stick failed to reprdouce the problem.
Then I started using a vnd, and that shows the issue (once in a
while). The feeling is
Hi,
I'm sorry I didn't test this, as I don't have -current OpenBSD on all my
machines, but I do have one WireGuard gateway running -stable with few
peers:
# ifconfig wg | grep -cw wgpeer
25
I would love to have this merged into main repo, as it would make my
life a tiny bit easier to see which
Use per-session `pxs_mtx' mutex(9) to protect session context. Except
MPPE encryption, PPPOE sessions are mostly immutable, so no lock
required for that case.
Global pipex(4) data is already protected by `pipex_list_mtx', so
pipex(4) doesn't rely on netlock anymore. Netlock could be also removed
> Date: Tue, 12 Jul 2022 20:03:15 +0200
> From: Denis Fondras
>
> Le Wed, Jul 06, 2022 at 10:45:39PM +0200, Mark Kettenis a écrit :
> > Now that the kernel supports the extended BOOTARG_CONSDEV struct and
> > snaps with that change are out there, here is the diff that changes
> > the amd64
> I'm suggesting you a diff against master of the implementation of the
> Baillie-PSW algorithm for primality testing.
The revised version of this is now committed. Many thanks again for your
work!
https://marc.info/?l=openbsd-cvs=165769382419130=2
18 matches
Mail list logo
