an mbuf timestamp is set by hw when a packet is rxed, and is then used
by the socket layer and things like ntpd, but is also used by bpf when
it provides packet timestamps.
the timestamp is only valid on rxed packets though. when they leave the
stack they should not be used anymore. on the way out
On Wed, Oct 07, 2020 at 10:44:15PM +0200, Jan Klemkow wrote:
> Hi,
>
> The name of the macro MCLGETI obsolete. It was made to use a network
> interface pointer inside. But, now it is just used to define a special
> length and the interface pointer is discarded.
>
> Thus, the following diff rena
On Fri, Dec 11, 2020 at 05:37:57PM +, Visa Hankala wrote:
> This patch extends struct klist with a callback descriptor and
> an argument. The main purpose of this is to let the kqueue subsystem
> assert when a klist should be locked, and operate the klist lock
> in klist_invalidate().
i've alw
ok
> On 17 Dec 2020, at 04:22, Scott Cheloha wrote:
>
> On Thu, Dec 03, 2020 at 09:59:11PM -0600, Scott Cheloha wrote:
>> Hi,
>>
>> tht(4) is another driver still using tsleep(9).
>>
>> It uses it to spin while it waits for the card to load the firmware.
>> Then it uses it to spin for up to 2
On Sat, Dec 26, 2020 at 04:48:23PM -0600, Scott Cheloha wrote:
> Now that we've removed bd_rdStart from the bpf_d struct, removing
> ticks from bpf(4) itself is straightforward.
>
> - bd_rtout becomes a timespec; update bpfioctl() accordingly.
> Cap it at MAXTSLP nanoseconds to avoid arithmetic
now that bpf read timeouts are only handled on the bpfread() side,
there's a simplification that can be made in bpf_catchpacket. the chunk
in bpf_catchpacket that rotates the buffers when one gets full already
does a wakeup, so we don't have to check if we have any waiting readers
and wake them up
On Sun, Nov 29, 2020 at 08:30:23PM +0100, Pierre Emeriaud wrote:
> Le sam. 28 nov. 2020 ?? 21:46, Jason McIntyre a ??crit :
> > > > > +.Bd -literal
> > > > add "-offset indent" to match the other examples
> > > Done, although I copied this block from gre example, so there's
> > > another occurrenc
On Mon, Dec 28, 2020 at 02:45:06PM +1000, David Gwynne wrote:
> now that bpf read timeouts are only handled on the bpfread() side,
> there's a simplification that can be made in bpf_catchpacket. the chunk
> in bpf_catchpacket that rotates the buffers when one gets full already
>
On Mon, Dec 28, 2020 at 06:56:08PM -0600, Scott Cheloha wrote:
> On Mon, Dec 28, 2020 at 10:49:59AM +1000, David Gwynne wrote:
> > On Sat, Dec 26, 2020 at 04:48:23PM -0600, Scott Cheloha wrote:
> > > Now that we've removed bd_rdStart from the bpf_d struct, removing
> &g
if stoeplitz is enabled by a driver (eg, ix, mcx, etc), this uses it in
the tcp code to set the flowid on packets. this encourages both the tx
and rx side of a tcp connection to get processed in the same places.
ok?
Index: netinet/in_pcb.c
=
On Tue, Oct 20, 2020 at 09:27:09AM +1000, David Gwynne wrote:
>
> i am feeling very warm and fuzzy about this diff at the moment.
We've been running this diff in production for the last couple of
months, and it's been solid for us so far. Ignoring the fixes for
crashes, I pers
On Sun, Jan 03, 2021 at 06:56:20PM +0100, Alexander Bluhm wrote:
> On Sun, Jan 03, 2021 at 02:00:00PM +1000, David Gwynne wrote:
> > On Tue, Oct 20, 2020 at 09:27:09AM +1000, David Gwynne wrote:
> > We've been running this diff in production for the last couple of
> > m
On Mon, Jan 04, 2021 at 12:58:17AM +0100, Alexander Bluhm wrote:
> On Sun, Jan 03, 2021 at 06:56:20PM +0100, Alexander Bluhm wrote:
> > I am currently running a full regress to find more fallout.
>
> These regress tests fail:
>
> sys/net/pf_forward
> sys/net/pf_fragment
> sbin/pfctl
>
> The firs
> On 4 Jan 2021, at 9:27 pm, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
> there is one more thing, which just came up on my mind.
>
>
>>
>> so i want to change route-to in pfctl so it takes a nexthop instead
>> of an interface. you could argue that pf already lets you do this,
>> because t
On Mon, Jan 04, 2021 at 01:57:24PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 11:46:16AM +0100, Alexandr Nedvedicky wrote:
> > > let's put this in and then i'll have a look. ok by me.
> > bluhm's diff is fine with me.
>
> Refactoring is commited, here is the remaining kernel diff
On Mon, Jan 04, 2021 at 06:37:54PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 11:21:50PM +1000, David Gwynne wrote:
> > this chunk pops out as a standalone change.
> >
> > having pf_find_state() return PF_PASS here means the callers short
> > circuit an
bpf should be showing what will be or has been on the wire, which is
what the ether_vtag in the mbuf has. the prio is either about to be
decoded from the tag on the wya into the stack, or has been encoded by
vlan(4) on the way out of the stack.
ok?
Index: bpf.c
===
vfs does it for us.
ok?
Index: bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.202
diff -u -p -r1.202 bpf.c
--- bpf.c 17 Jan 2021 02:27:29 - 1.202
+++ bpf.c 19 Jan 2021 00:10:22 -
@@ -379,7
I tried this diff, and it broke the ability to use dynamic addresses.
ie, the following rules should work:
pass in on gre52 inet proto icmp route-to (gre49:peer)
pass in on vmx0 inet proto icmp route-to (gre:peer)
however, other forms of dynamic interface addresses should fail. or do
we want to s
On Fri, Jan 08, 2021 at 04:43:39PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> >
> > revision 1.294
> > date: 2003/01/02 01:56:56; author: dhartmei; state: Exp; lines: +27 -49;
> > When route-to/reply-to is used in combination with address translation,
> > pf_
> On 25 Jan 2021, at 10:43, Alexandr Nedvedicky
> wrote:
>
> hello,
>
> On Fri, Jan 22, 2021 at 05:32:47PM +1000, David Gwynne wrote:
>> I tried this diff, and it broke the ability to use dynamic addresses.
>> ie, the following rules should work:
>>
On Mon, Jan 25, 2021 at 02:50:12AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> >
> > ok. i don't know how to split up the rest of the change though.
> >
> > here's an updated diff that includes the rest of the kernel changes and
> > the pfctl and pf.conf tweaks.
> >
> > it's probably useful
On Mon, Jan 25, 2021 at 01:11:35PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > >
> > > I understand that simple is better here, so I won't object
> > > if we will lean towards simplified model above. However I still
> > > would like to share my view on current PF.
> > >
> > >
On Mon, Jan 25, 2021 at 02:30:46PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
...
> >
> > i dont understand the kif lifetimes though. can we just point a
> > pdesc at an arbitrary kif or do we need ot reference count?
> >
>
> as long as we don't release NET_LOCK() (or PF_LOCK() in near
On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote:
> Hi,
>
> Some personal thoughts. I am happy when pf route-to gets simpler.
> Especially I have never understood what this address@interface
> syntax is used for.
even after staring at it for so long, i still don't get it. i do thi
On Mon, Jan 25, 2021 at 04:19:11PM +0100, Alexander Bluhm wrote:
> On Fri, Jan 22, 2021 at 06:07:59PM +1000, David Gwynne wrote:
> > --- sys/conf/GENERIC30 Sep 2020 14:51:17 - 1.273
> > +++ sys/conf/GENERIC22 Jan 2021 07:33:30 -
> > @@ -82,6 +
On Mon, Jan 25, 2021 at 06:17:02PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> pf_route() might leak a refence to ifp.
oh no :(
> > Index: sys/net/pf.c
> > ===
> > RCS file: /cvs/src/sys/net/pf.c,v
> > retrieving revision 1.1101
On Mon, Jan 25, 2021 at 05:38:40PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote:
> > Hi,
> >
> > Some personal thoughts. I am happy when pf route-to gets simpler.
> > Especially I have never understood what this address@interfa
when pf_route (and pf_route6) are supposed to handle forwarding the
packet (ie, for route-to or reply-to rules), they take the mbuf
away from the calling code path. this is done by clearing the mbuf
pointer in the pf_pdesc struct. it doesn't do this for dup-to rules
though.
at the moment pf_route
On Wed, Jan 27, 2021 at 11:13:12AM +1000, David Gwynne wrote:
> when pf_route (and pf_route6) are supposed to handle forwarding the
> packet (ie, for route-to or reply-to rules), they take the mbuf
> away from the calling code path. this is done by clearing the mbuf
> pointer in
this was discussed as part of the big route-to issues thread. i think
it's easy to break out and handle separately now.
the diff does what the subject line says. it seems to work as expected
for me. i don't see weird state issues anymore when i dup my ssh session
out over a tunnel interface.
sash
at the moment if the route is invalid, we drop the packet. this
generates an icmp error.
ok?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1103
diff -u -p -r1.1103 pf.c
--- pf.c27 Jan 2021 04:46:21 -
some of the discussion around dup-to made me think that a diff we
have here at work might be more broadly useful.
we run a box here with a bunch of ethernet ports plugged into span
ports on switches. basically every packet going to our firewalls gets
duplicated to this host. we then have code that
calling if_output with a route to a local IP is confusing, and I'm not
sure it makes sense anyway.
this treats a an RTF_LOCAL route like an invalid round and drops the
packet.
ok?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
re
i think these code chunks are around the wrong way.
pfsync may want to defer the transmission of a packet. it does this so
it can try and get a state over to a peer firewall before a host may
send a reply to the peer, which would get dropped cos there's no
matching state.
i think the once rule pr
On Thu, Jan 28, 2021 at 08:15:06AM +0100, Claudio Jeker wrote:
> On Thu, Jan 28, 2021 at 09:57:33AM +1000, David Gwynne wrote:
> > calling if_output with a route to a local IP is confusing, and I'm not
> > sure it makes sense anyway.
> >
> > this treats a an RTF_L
this is the diff from the "pf route-to issues" thread, but on it's own.
the summary of why i wanted to do this is:
- route-to, reply-to, and dup-to do not work with pfsync
this is because the information about where to route-to is stored in
rules, and it is hard to have a ruleset synced 100%
On Thu, Jan 28, 2021 at 08:09:36PM +0100, Alexander Bluhm wrote:
> On Thu, Jan 28, 2021 at 09:57:33AM +1000, David Gwynne wrote:
> > calling if_output with a route to a local IP is confusing, and I'm not
> > sure it makes sense anyway.
> >
> > this treats a an RTF_L
this is part of a high level discussion about when pf runs against a
packet. the options are:
1. pf runs when a packet goes over an interface
or
2. pf runs when a packet enters or leaves the network stack.
for normal packet handling there isn't a difference between these
options. in the routing c
On Tue, Feb 02, 2021 at 11:30:12AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Tue, Feb 02, 2021 at 02:52:52PM +1000, David Gwynne wrote:
> >
> > however, like most things relating to route-to/reply-to/dup-to, im
> > pretty sure at this point it'
On Fri, Jan 29, 2021 at 03:23:31PM +0100, Alexander Bluhm wrote:
> On Fri, Jan 29, 2021 at 10:53:09AM +1000, David Gwynne wrote:
> > > Are you sure that it does not break any use case? I have seen so
> > > much strange stuff. What is the advantage?
> >
> > The c
refcnt_init starts counting at 1, while the existing code starts at 0. Do
the crashes stop because we never fully release all the references and
never free it now?
On Sat, 6 Feb 2021, 10:55 Alexander Bluhm, wrote:
> Hi,
>
> When I replace the ++ and -- of ifg_refcnt with an atomic operation,
> i
On Sun, Feb 07, 2021 at 06:27:24PM +0100, Christopher Zimmermann wrote:
> On Sun, Feb 07, 2021 at 04:20:26PM +, Stuart Henderson wrote:
> > On 2021/02/07 17:04, Christopher Zimmermann wrote:
> > > Hi,
> > >
> > > a year ago I added support for our pf tables to the unbound ipset module.
> > > U
On Sun, Feb 07, 2021 at 06:55:37PM +0100, Sebastian Benoit wrote:
> David Gwynne(da...@gwynne.id.au) on 2021.01.27 17:13:09 +1000:
> > some of the discussion around dup-to made me think that a diff we
> > have here at work might be more broadly useful.
> >
> > we run
> On 15 Feb 2021, at 07:54, Mark Kettenis wrote:
>
> One of the aspects of device access is whether CPU writes to a device
> are posted or non-posted. For non-posted writes, the CPU will wait
> for the device to acknowledge that the write has performed. If the
> device sits on a bus far away
oid *port)
+{
+ struct ether_addr *endpoint = port;
+
+ pool_put(&bpe_endpoint_pool, endpoint);
+}
+
+static size_t
+bpe_eb_port_ifname(void *arg, char *dst, size_t len, void *port)
{
- return memcmp(&a->be_c_da, &b->be_c_da, sizeof(a->be_c_da));
+ struct
if you have multiple links to the same destination, this will let you
use them via route-to/reply-to/dup-to.
ok?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1110
diff -u -p -r1.1110 pf.c
--- pf.c12
> On 16 Feb 2021, at 06:01, Mark Kettenis wrote:
>
>> Date: Mon, 15 Feb 2021 01:19:29 +0100
>> From: Patrick Wildt
>>
>> Am Mon, Feb 15, 2021 at 09:55:56AM +1000 schrieb David Gwynne:
>>>
>>>
>>>> On 15 Feb 2021, at 07:54, M
> On 22 Feb 2021, at 12:46 am, Vitaliy Makkoveev wrote:
>
> Hello.
>
>
>> +ifp->if_ioctl = veb_ioctl;
>> +ifp->if_input = veb_input;
>> +//ifp->if_rtrequest = veb_rtrequest;
>> +ifp->if_output = veb_output;
>> +ifp->if_enqueue = veb_enqueue;
>
> Could you replace c++ sty
i'm not a fan of having to cast to caddr_t when we have modern
inventions like void *s we can take advantage of.
ok?
Index: share/man/man9/mbuf.9
===
RCS file: /cvs/src/share/man/man9/mbuf.9,v
retrieving revision 1.120
diff -u -p -r1
On Tue, Feb 23, 2021 at 01:09:06PM +0100, Alexander Bluhm wrote:
> On Tue, Feb 23, 2021 at 07:31:30PM +1000, David Gwynne wrote:
> > i'm not a fan of having to cast to caddr_t when we have modern
> > inventions like void *s we can take advantage of.
>
> Shoud you remove
ok
> On 25 Feb 2021, at 02:34, Jan Klemkow wrote:
>
> Hi,
>
> While attaching the following disks, the nvme driver runs into a NULL
> dereference in nvme_scsi_capacity16() and nvme_scsi_capacity().
>
> nvme0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev
> 0x00: msix, NVM
i think this is enough to let vmd wire guests up to veb interfaces.
please remember that veb is not the same as bridge, so some care
has to be taken when replacing bridge with veb. the biggest difference
to note is that if you want the host to talk layer 3 (ie, ip, dhcp,
etc) with the guests, the
> On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote:
>
> On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote:
>> i think this is enough to let vmd wire guests up to veb interfaces.
> But please update vm.conf(5) to mention veb(4) and vport(4) in as well
> SWITC
I like it. I would like it more if you named the mbuf list variable "fml".
ok by me.
> On 26 Feb 2021, at 9:08 pm, Alexander Bluhm wrote:
>
> Hi,
>
> I always bothered me that ip_fragment() and ip6_fragment() behave
> sligtly differently. Unify them and use an mlist to simplify the
> fragment
> On 27 Feb 2021, at 9:57 am, Mike Larkin wrote:
>
> On Sat, Feb 27, 2021 at 09:44:03AM +1000, David Gwynne wrote:
>>
>>
>>> On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote:
>>>
>>> On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wr
> On 27 Feb 2021, at 10:11, Klemens Nanni wrote:
>
> On Sat, Feb 27, 2021 at 09:44:03AM +1000, David Gwynne wrote:
>>
>>
>>> On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote:
>>>
>>> On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wr
cvs/src/sys/net/if_vxlan.c,v
retrieving revision 1.82
diff -u -p -r1.82 if_vxlan.c
--- net/if_vxlan.c 25 Feb 2021 02:48:21 - 1.82
+++ net/if_vxlan.c 4 Mar 2021 04:32:03 -
@@ -1,7 +1,7 @@
-/* $OpenBSD: if_vxlan.c,v 1.82 2021/02/25 02:48:21 dlg Exp $ */
+/* $Open
this applies the tricks with addresses from veb and etherbridge
code to the normal ethernet input processing. it seems to make
things a bit faster. some tests have shown a 15% improvement in
forwarding performance with this diff.
ive been running with it for the last week on sparc64 and amd64
with
this passes the destination ethernet address from the network packet
as a uint64_t from ether_input into carp_input, so it can use it
to see if a carp interface should take the packet.
it's been working on amd64 and sparc64. anyone else want to try?
Index: netinet/ip_carp.c
==
On Thu, Mar 04, 2021 at 03:36:19PM +1000, David Gwynne wrote:
> as the subject says, this is a rewrite of vxlan(4).
>
> vxlan(4) relies on bridge(4) to implement learning, but i want to be
> able to remove bridge(4) one day. while working on veb(4), i wrote
> the guts of a
ok.
> On 5 Mar 2021, at 9:05 pm, Jan Klemkow wrote:
>
> Hi,
>
> this diff adds the missing PCI classes Accelerator and Instrumentation.
> Thus, we can replace a few unknown in its output:
>
> - 0x0008: Class: 13 (unknown), Subclass: 00 (unknown),
> + 0x0008: Class: 13 Instrumentati
> On 10 Mar 2021, at 23:07, Klemens Nanni wrote:
>
> On Tue, Mar 09, 2021 at 08:48:14PM +0100, Klemens Nanni wrote:
>> Simple addition of VEB right before BRIDGE.
> New diff sorting the section alphabetically between UMB and VLAN,
> thanks jmc.
>
>> All text is copied from other already exist
> On 11 Mar 2021, at 8:06 pm, Klemens Nanni wrote:
>
> On Thu, Mar 11, 2021 at 01:46:34PM +1000, David Gwynne wrote:
>
>>> +.It Cm link0
>>> +Disable the filtering of 802.1Q VLAN and QinQ SVLAN packets.
>>> +.It Cm -link0
>>> +Enable the
On Sun, Mar 21, 2021 at 04:24:24PM +0100, Jurjen Oskam wrote:
> Hi,
>
> When trying out veb(4), I ran into a situation where TCP sessions across a
> veb(4) bridge stalled while the exact same config using bridge(4) worked fine.
>
> After some investigation, it seems that veb(4) adds an FCS to the
this follows the more standard order for fitting a packet onto a tx
ring. it also uses the more modern m_defrag pattern for heavily
fragmented packets.
Works For Me(tm).
ok?
Index: if_pcn.c
===
RCS file: /cvs/src/sys/dev/pci/if_pcn.
On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> diskless(8) just needs tftpd(8) to deliver files, none of the possibly
> untrusted clients are supposed to ever write anything.
>
> Either way, even when run without -c, a single file writable by _tftpd
> might be enough for a malici
On Tue, Oct 04, 2022 at 09:43:40AM +, Klemens Nanni wrote:
> On Tue, Oct 04, 2022 at 09:24:04AM +, Klemens Nanni wrote:
> > On Mon, Oct 03, 2022 at 06:43:26PM -0600, Theo de Raadt wrote:
> > > David Gwynne wrote:
> > >
> > > > On Sun, Oct 02, 2022 a
usbdevs has "?" in the optstring is passes to getopt, but doesn't handle
it specially. this is unnecessarily different to everything else in the
tree, so i want to remove it. ok?
Index: usbdevs.c
===
RCS file: /cvs/src/usr.sbin/usbdev
On Fri, Nov 04, 2022 at 03:40:04PM +0100, Claudio Jeker wrote:
> So mpe(4) is a special device. It is a point-to-multipoint interface that
> does not do multicast. So setting IFF_MULTICAST on the interface is not
> correct but IPv6 depends on it because neighbor discovery.
>
> Now there is no neig
this is a small chunk to help sashan@ out with some of the pf ioctl work
he is doing.
he is looking at allocating config over multiple ioctls, and would like
to be able to throw it away in situations like if the userland program
creating the state goes away. with the current vnode and device speci
On Tue, Jun 07, 2022 at 04:58:24PM +1000, David Gwynne wrote:
> the main change here is to move pf_purge out from under the kernel lock.
>
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holding
&g
i'm hacking on pfsync(4) at the moment, and i wasted way too much time
wondering how i broke the pfsync ioctls after i didn't the pfsync_status
output. turns out if you don't have a sync interface set, it skips
output.
i think it's useful to show that the sync interface is not set, so i
came up wi
I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
waiting for cpus to run that aren't running cos we haven't finished booting yet.
I'll back it out and fix it up when I'm actually awake.
dlg
> On 10 Nov 2022, at 6:28 am, Hrvoje Popovski wrote:
>
> Hi all,
>
> I've ch
On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
> I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
> waiting for cpus to run that aren't running cos we haven't finished booting
> yet.
>
> I'll back it out and fix it up when
> On 10 Nov 2022, at 10:56 pm, Claudio Jeker wrote:
>
> On Fri, Nov 04, 2022 at 03:40:04PM +0100, Claudio Jeker wrote:
>> So mpe(4) is a special device. It is a point-to-multipoint interface that
>> does not do multicast. So setting IFF_MULTICAST on the interface is not
>> correct but IPv6 dep
Yes please. ok dlg@.
> On 10 Nov 2022, at 10:10 pm, Alexandr Nedvedicky wrote:
>
> Hello,
>
> David (dlg@) asked me to shrink the scope of the change. The new diff
> introduces a mutex to pf_state and adjust pf_detach_state() to utilize the
> newly introduced mutex. I've also added annotation
On Thu, Nov 10, 2022 at 09:04:22PM +1000, David Gwynne wrote:
> On Thu, Nov 10, 2022 at 08:10:35AM +1000, David Gwynne wrote:
> > I know what this is. The barrier at the end of if_idxmap_alloc is sleeping
> > waiting for cpus to run that aren't running cos we haven't
ok
> On 11 Nov 2022, at 7:31 pm, Alexandr Nedvedicky wrote:
>
> Hello,
>
> Diff below changes KASSERT() to if (). We have to prevent
> packets to insert state to snapshot queue multiple times.
> Hrvoje@ can trigger situation where state updates to pfsync
> peer are more frequent than we are abl
:12:34 reyk Exp $ */
+
+/*
+ * Copyright (c) 2017 David Gwynne
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE
this is ok by me, obviously.
On Sun, Nov 20, 2022 at 06:18:55PM -0600, Scott Cheloha wrote:
> Hi,
>
> systat(1)'s vmstat view should not use statclock() ticks to count
> elapsed time. First, ticks are very low resolution and they aren't
> always of equal length. Second, we're counting the ticks
> On 22 Nov 2022, at 16:13, Andrew Hewus Fresh wrote:
>
> On Mon, Nov 21, 2022 at 04:56:07PM +0100, Martijn van Duren wrote:
>> On Sun, 2022-11-20 at 19:35 -0700, Theo de Raadt wrote:
>>> Steve Litt wrote:
>>>
Vitaliy Makkoveev said on Mon, 21 Nov 2022 03:48:21 +0300
>> On 20
> On 22 Nov 2022, at 18:49, Alexandr Nedvedicky wrote:
>
> Hello,
>
> this change is required to unhook pf(4) from NET_LOCK().
> therefore I'd like to get it in.
ok dlg@
>
> On Mon, Nov 07, 2022 at 04:51:59AM +1000, David Gwynne wrote:
>>
>>
im ok with this, but you need sashan@ to ok it too. he's been working up to
this anyway.
dlg
> On 24 Nov 2022, at 06:18, Vitaliy Makkoveev wrote:
>
> On Wed, Nov 23, 2022 at 02:59:05PM -0500, David Hill wrote:
>> Hello -
>>
>> I am seeing splasserts on boot (before kern.splassert=2 can be set
On Tue, May 30, 2023 at 09:08:45PM +0200, Alexander Bluhm wrote:
> Hi,
>
> Currently packets sent over loopback interface get their checksum
> calculated twice. In the output path it is set and during TCP/IP
> input it is calculated again to be compared with the previous value.
>
> This can be a
> On 2 Jun 2023, at 19:51, Alexander Bluhm wrote:
>
> On Wed, May 31, 2023 at 09:36:22AM +1000, David Gwynne wrote:
>> we could export these csum flags as part of the bpf header so we can
>> teach tcpdump to shut up in this situation.
>
> Linux does not do that a
> On 7 Jun 2023, at 06:33, Vitaliy Makkoveev wrote:
>
>> On 6 Jun 2023, at 20:29, Alexander Bluhm wrote:
>>
>> On Tue, Jun 06, 2023 at 05:54:31PM +0300, Vitaliy Makkoveev wrote:
>>> On Tue, Jun 06, 2023 at 02:31:52PM +0200, Alexander Bluhm wrote:
Hi,
I would suggest to rename
makes sense to me, ok.
maybe it's time to re-evaluate siphash?
> On 23 Jun 2023, at 05:50, Alexander Bluhm wrote:
>
> Hi,
>
> I am working on a diff to run UDP input in parallel. Btrace kstack
> analysis shows that SIP hash for PCB lookup is quite expensive.
> When running in parallel we get
On Mon, Jun 26, 2023 at 01:16:40AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> The new code looks much better. It's huge leap forward. I don't mind if this
> big diff will get committed. Hrvoje did test the whole diff. Trying to split
> it
> to smaller changes might bring in code which is not
On Sun, Jul 02, 2023 at 12:44:17PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> On Thu, Jun 29, 2023 at 01:48:27PM +1000, David Gwynne wrote:
> > On Mon, Jun 26, 2023 at 01:16:40AM +0200, Alexandr Nedvedicky wrote:
> >
> > > net/if_pfsync.c
> > &g
pto: ifnet
pseudo-device trunk: ifnet, ether, ifmedia
@@ -1006,6 +1007,7 @@ file uvm/uvm_vnode.c
# IPv6
file net/if_gif.c gif needs-count
+file net/if_sec.c sec needs-count
file netinet/ip_ecn.c
file netinet6/
i'll fix this before i enable sec(4) in GENERIC. thanks for reading it.
cheers,
dlg
On Tue, 4 Jul 2023 at 20:04, Vitaliy Makkoveev wrote:
> On Tue, Jul 04, 2023 at 03:26:30PM +1000, David Gwynne wrote:
> > tl;dr: this adds sec(4) p2p ip interfaces. Traffic in and out of these
>
BPF_DIRECTION_OUT);
> +#endif
> error = ipsp_process_packet(m, tdb,
> m->m_pkthdr.ph_family, /* already tunnelled? */ 0);
> if (error != 0)
>
> On Tue, 4 Jul 2023 at 14:33, David Gwynne wrote:
> &g
mac-sha2-256 enc aes-256 group modp3072 \
> srcid $h_self \
> ikelifetime 28800 \
> lifetime 3600 \
> psk $h_s2s1_key \
> iface sec0
>
> In any case, IKEv1 worked fine! I plan to test this with Azure next
> since they're the second
On Mon, Aug 07, 2023 at 05:36:27PM +0200, Tobias Heider wrote:
> On Mon, Aug 07, 2023 at 02:22:23PM +1000, David Gwynne wrote:
> > tobhe@ wrote the iked bits, so he'll commit them when he's ready.
> >
> > your config looks pretty much the same as mine except y
there are links between the pcb/socket layer and pf as an optimisation,
and links on mbufs between both sides of a forwarded connection.
these links let pf skip an rb tree lookup for outgoing packets.
right now these links are between pf_state_key structs, which are the
things that contain the act
umb(4) is a hardware p2p driver, it just has ip coming in, so we can do
the same thing we do for the address family and input processing as
other p2p interfaces.
the short packet check that umb_input does is already done by the ip
stacks, so we're not losing anything.
i havent got a umb(4), so i
> On 5 Oct 2023, at 21:50, Vitaliy Makkoveev wrote:
>
> Otherwise `if_snd' could still contain packets. If any of them has
> associated data with bumped reference counter, the corresponding
> refcnt_finalize() will sleep forever. I don't think we need to
> transmit these packets when interface
> On 14 Oct 2023, at 23:18, Claudio Jeker wrote:
>
> On Sat, Oct 14, 2023 at 11:07:11AM +0200, Wouter Prins wrote:
>> hello list,
>>
>> Was wondering if the veb interface is supported as a bridge for pseudowires?
>> The manpage doesn't mention anything about the type of
>> bridge interface re
ive been running multi-cpu/core openbsd VMs on esxi on top of amd
epyc cpus, and have noticed for a long time now that for some reason
openbsd decides that all the virtual cpus are threads on the one core.
this is annoying, cos setting hw.smt=1 feels dirty and wrong.
i spent the weekend figuring t
1 - 100 of 1149 matches
Mail list logo
