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 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
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 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 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
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
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: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 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 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,
> >
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
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 -
@@
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
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
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 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
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
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
> > months
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 personall
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 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
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
> does
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
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 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
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 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
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
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
I've been using this for a week or so now and it's been very boring, which is
an improvement in my experience.
I has my ok if that has any value.
dlg
> On 9 Nov 2020, at 8:16 pm, Claudio Jeker wrote:
>
> Hi bgpd and esp. bgpd-spamd users,
>
> Currently the pftable code does not keep track
On Mon, Oct 19, 2020 at 07:16:46PM +1000, David Gwynne wrote:
> On Mon, Oct 19, 2020 at 10:03:29AM +0100, Stuart Henderson wrote:
> > On 2020/10/19 11:47, David Gwynne wrote:
> > > On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote:
> > > > On 2020/1
On Mon, Oct 19, 2020 at 12:33:25PM +0100, Stuart Henderson wrote:
> On 2020/10/19 19:53, David Gwynne wrote:
> > On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> > > On 2020/10/19 15:35, David Gwynne wrote:
> > > > every few years i try and use
On Mon, Oct 19, 2020 at 12:28:19PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > >
> > > it seems to me 'route-to vs. pfsync' still needs more thought. the
> > > next-hop IP address in route-to may be different for each PF box
> > > linked by pfsync(4). To be honest I have no
On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> On 2020/10/19 15:35, David Gwynne wrote:
> > every few years i try and use route-to in pf, and every time it
> > goes badly. i tried it again last week in a slightly different
> > setting, and actuall
On Mon, Oct 19, 2020 at 09:46:19AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> disclaimer: I have no chance to run pfsync on production, I'm very
> inexperienced with pfsync(4).
i wrote the defer code in pfsync, and i think i wrote the code in
pfsync that calls pf_route badly, so noones
On Mon, Oct 19, 2020 at 10:03:29AM +0100, Stuart Henderson wrote:
> On 2020/10/19 11:47, David Gwynne wrote:
> > On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote:
> > > On 2020/10/18 14:04, David Gwynne wrote:
> > > > the problem i'm hitting is that
every few years i try and use route-to in pf, and every time it
goes badly. i tried it again last week in a slightly different
setting, and actually tried to understand the sharp edges i hit
this time instead of giving up. it turns out there are 2 or 3
different things together that have cause me
On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote:
> On 2020/10/18 14:04, David Gwynne wrote:
> > the problem i'm hitting is that i have a multihomed box where the
> > service it provides listens on an IP address that's assigned to lo1.
> > it's a host ru
this is mostly about discussion at the moment, i'm not tied to this diff
at all.
the problem i'm hitting is that i have a multihomed box where the
service it provides listens on an IP address that's assigned to lo1.
it's a host running a service, it's not a router, so the
net.inet.ip.forwarding
> On 31 Jul 2020, at 17:17, Klemens Nanni wrote:
>
> This diff is to be applied on top of my other diff on tech@ with subject
> "ifconfig: merge switch_status() into bridge_status()".
>
> It hooks completes the output of tpmr intefaces in what I think is the
> simplest and least intrusive
> On 31 Jul 2020, at 14:28, Klemens Nanni wrote:
>
> ifconfig(8) detects switch(4) through its unique SIOCSWSDPID ioctl and
> further does another switch specific ioctl for the default output
> regardless of configuration and/or members:
>
> SIOCSWSDPID struct ifbrparam
>
> On 31 Jul 2020, at 16:36, Klemens Nanni wrote:
>
> On Wed, Jul 29, 2020 at 02:21:42PM +0200, Klemens Nanni wrote:
>> This is to reduce duplicate code and pave the way for a single
>> bridge_status() that covers all bridge like interfaces: bridge(4),
>> switch(4) and tpmr(4).
> A duplicate
ok.
> On 29 Jul 2020, at 11:38, Klemens Nanni wrote:
>
> On Tue, Jul 28, 2020 at 07:09:17PM +0200, Klemens Nanni wrote:
>> bridge_status() and switch_status() do the regular sanity check with
>> SIOCGIFFLAGS, but both functions also call is_switch(), bridge_status()
>> also calls is_bridge().
On Fri, Jun 26, 2020 at 07:55:43AM +0200, Theo Buehler wrote:
> This adds an stoeplitz_random_seed() function that generates a random
> Toeplitz key seed with an invertible matrix T. This is necessary and
> sufficient for the hash to spread out over all 65536 possible values.
>
> While it is
> On 14 Jul 2020, at 4:40 pm, Jonathan Matthew wrote:
>
> mcx(4) is almost ready to enable RSS, except arm64 doesn't yet support
> mapping interrupts to cpus. Until that's in place, here's a diff with the
> missing pieces from the driver in case anyone wants to test. This will
> enable up
this diff is about fixing some semantic issues with the current
interface input handler list processing. i was a bit worried it would
cause a small performance hit, but it seems it has the opposite effect
and is actually slightly faster. so in my opinion it is more correct,
but also improves
> On 10 Jul 2020, at 12:45 am, sven falempin wrote:
>
> On Thu, Jul 9, 2020 at 3:31 AM Klemens Nanni wrote:
>>
>> On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote:
>>> if i accidentally `ifconfig bridge add gre0` instead of egre0, having
>>&g
ok.
so the problem is the older api doenst support the "get phy types" command, or
the sff commands. should we silence the "get phy types" error output? is there
a better errno to use when the sff command isn't supported? should we add
something to the manpage? should that something be "i'm
if i accidentally `ifconfig bridge add gre0` instead of egre0, having
bridge create gre0 and then not like it is not what i expect to happen.
especially when it leaves me with an extra gre0 interface lying around
afterwards.
i can appreciate that this was trying to be helpful when you wanted
to
the code pretty obviously assumes that it only handles Ethernet packets,
so we should restrict it to IF_ETHER type interfaces.
ok?
Index: if_switch.c
===
RCS file: /cvs/src/sys/net/if_switch.c,v
retrieving revision 1.30
diff -u -p
this is a first pass at converting the stats gathering in em(4) to
kstat instead of a disabled printf.
there are some semantic differences. the most obvious is that hardware
counters are not fed into the stacks counters on struct ifnet. i also
don't collect ring based counters (yet).
they look
> On 7 Jul 2020, at 7:57 am, Jesper Wallin wrote:
>
> Hi all,
>
> I received a segmentation fault from dhclient(8) upon boot and decided
> to investigate... My system is running with vm.malloc_conf=CFGJUR and
> figured one of those options was the cause of the crash. I noticed that
> the
On Sun, Jun 21, 2020 at 07:15:15PM -0600, Theo de Raadt wrote:
> In that case you can also delete:
>
> ifconfig.c:#include
indeed i can.
Index: Makefile
===
RCS file: /cvs/src/sbin/ifconfig/Makefile,v
retrieving revision 1.16
diff
libc has undocumented base64 encoding and decoding funtionality. this
cuts ifconfig over to using it instead of the code in libcrypto.
whether the libc functionality should be "blessed" and documented is a
separate issue.
ok?
Index: Makefile
On Sun, Jun 21, 2020 at 12:52:53PM +0200, Matthieu Herrb wrote:
> On Fri, Jun 19, 2020 at 06:46:00PM +1000, Matt Dunwoodie wrote:
> > Hi all,
> >
> > After the previous submission of WireGuard, we've again been through a
> > number of improvements. Thank you everyone for your feedback.
>
> Hi,
>
the network stack doesnt really block timeouts from firing anymore. this
is especially true on MP systems, because timeouts fire on cpu0 and the
nettq thread could be somewhere else entirely. this means network
activity doesn't make the softclock lose ticks, which means we aren't
scaling rx ring
. 11:27, Hrvoje Popovski wrote:
> >>>> On 17.6.2020. 10:36, David Gwynne wrote:
> >>>>> this is an updated version of a diff from christiano haesbaert by way of
> >>>>> mpi@ to enable the use of multiple tx and rx rings with msi-x.
> >>>>>
> >
> On 18 Jun 2020, at 7:49 pm, Theo Buehler wrote:
>
> The same trick as in the previous diff can be used a second time:
> widen the type, accumulate before folding.
>
> I've also shuffled things into an order where the introduction of
> a stoeplitz_hash_n32(scache, n32) suggests itself as a
> On 18 Jun 2020, at 2:34 pm, Theo Buehler wrote:
>
> Now that the calls to stoeplitz_cache_entry() are out of the way,
> we can avoid half of the calculations by merging the computation of
> hi and lo, only spliting at the end. This allows us to leverage
> stoeplitz_hash_n16().
>
> The
> On 18 Jun 2020, at 1:34 am, Theo Buehler wrote:
>
> The next step is to use that we have cached the result of the matrix
> multiplication H * val in stoeplitz_cache_entry(scache, val), so the
> identity (H * x) ^ (H * y) == H * (x ^ y) allows us to push the calls to
> the cache function
this is an updated version of a diff from christiano haesbaert by way of
mpi@ to enable the use of multiple tx and rx rings with msi-x.
the high level description is that that driver checks to see if msix is
available, and if so how many vectors it has. it then gets an intrmap
based on that
> On 17 Jun 2020, at 01:57, Theo Buehler wrote:
>
> The diff below removes some of the unnecessary complications in the
> calculation of the stoeplitz_cache and brings them into a form more
> suitable for mathematical reasoning. I added a somewhat dense comment
> which explains the full
16 Jun 2020 00:13:50 -
@@ -0,0 +1,125 @@
+.\" $OpenBSD$
+.\"
+.\" Copyright (c) 2020 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
+.\&q
> On 13 Jun 2020, at 3:20 pm, Theo Buehler wrote:
>
> On Sat, Jun 13, 2020 at 11:35:42AM +1000, David Gwynne wrote:
>> On Fri, Jun 12, 2020 at 03:37:59PM +0200, Theo Buehler wrote:
>>> I finally found the time to think about the mathematics of this some
>&g
> On 14 Jun 2020, at 10:59 pm, Miod Vallat wrote:
>
>
>>> Others have pointed out off-list that one can use __builtin_popcount(),
>>> but __builtin_parity() is exactly what I want. Is it available on all
>>> architectures?
>>
>> I don't think it is available on gcc 3.x for m88k but someone
On Fri, Jun 12, 2020 at 03:37:59PM +0200, Theo Buehler wrote:
> I finally found the time to think about the mathematics of this some
> more and I'm now convinced that it's a sound construction. I hope that
> one or the other observation below will be useful for you.
Yes, I read everything below
> On 13 Jun 2020, at 6:47 am, Jason McIntyre wrote:
>
> On Fri, Jun 12, 2020 at 09:53:33PM +0300, Vitaliy Makkoveev wrote:
>> Since 6.7-release npppd(8) uses pppac(4) instead of tun(4) but manual
>> page still has the reference to tun(4).
>>
>> Diff below replaced `tun' by `pppac' in
> On 8 Jun 2020, at 9:28 pm, Christian Weisgerber wrote:
>
> powerpc has byte-swapping 16 and 32-bit load/stores and we use those
> in .
>
> Starting with POWER7 (Power ISA v.2.06), there are also corresponding
> 64-bit instructions. Do we want to use those on powerpc64? Or do
> we want to
I was looking for something in a devices VPD info and got this far
before finding out it wasn't there. I'm a bit over it now though.
PCI VPD stuff is weird because the capability doesn't contain the data
itself, it's a register that lets you communicate with whatever is
storing the data on the
this builds on the work mpi has been doing to prepare ix for multiq
operation. the main change is to call if_attach_queues and
if_attach_iqueues to allocate an ifq and ifiq per tx ring and rx
ring respectivly, and then tie them together. ix rx rings deliver
packets into ifiqs, and ifqs push
> On 5 Jun 2020, at 4:33 am, Christian Weisgerber wrote:
>
> Here's a proposal for implementing cpu_rnd_messybits() as a read of
> the cycle counter on alpha, powerpc, and sparc64. Since I don't have
> those archs, the diff is not even compile-tested.
>
> * alpha: RPCC is a 32-bit counter
> On 30 May 2020, at 9:43 pm, Vitaliy Makkoveev
> wrote:
>
>
>> On 30 May 2020, at 09:40, David Gwynne wrote:
>>
>> On Mon, May 25, 2020 at 09:44:22AM +0200, Martin Pieuchot wrote:
>>> On 23/05/20(Sat) 15:38, Vitaliy Makkoveev wrote:
>>>>
On Mon, May 25, 2020 at 09:44:22AM +0200, Martin Pieuchot wrote:
> On 23/05/20(Sat) 15:38, Vitaliy Makkoveev wrote:
> > > On 23 May 2020, at 12:54, Martin Pieuchot wrote:
> > > On 22/05/20(Fri) 13:25, Vitaliy Makkoveev wrote:
> > >> On Fri, May 22, 2020 at 07:
le: share/man/man9/stoeplitz_to_key.9
diff -N share/man/man9/stoeplitz_to_key.9
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man9/stoeplitz_to_key.9 29 May 2020 04:01:26 -
@@ -0,0 +1,126 @@
+.\" $OpenBSD$
+.\"
+.\" Copyright (c) 2020 David Gwynne
+.\"
+.\
On Tue, May 26, 2020 at 05:42:13PM -0600, Jason A. Donenfeld wrote:
> On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote:
> > With regards to your crash, though, that's a bit more puzzling, and
> > I'd be interested to learn more details. Because these structs are
> > already naturally
I just committed this, thank you :)
dlg
> On 16 May 2020, at 05:14, Caspar Schutijser wrote:
>
> Hi,
>
> Below is a patch that makes breaking out of the loop work when using
> a savefile.
>
> The pcap_breakloop() function was backported from tcpdump.org libpcap
> to OpenBSD libpcap by djm@
> On 23 May 2020, at 7:54 am, Christopher Zimmermann wrote:
>
> On Tue, Apr 21, 2020 at 04:12:16PM -0700, Chris Cappuccio wrote:
>> Tom Smyth [tom.sm...@wirelessconnect.eu] wrote:
>>> Hi Chrisz,
>>>
>>> 4 bytes for the vlan header .. have you tried increasing the parent
>>> intetface mtu by
> On 23 May 2020, at 8:44 am, Christopher Zimmermann wrote:
>
> On Sun, Jan 19, 2020 at 01:32:17PM +, Stuart Henderson wrote:
>> On 2020/01/19 00:11, Sebastian Benoit wrote:
>>> chr...@openbsd.org(chr...@openbsd.org) on 2020.01.18 06:18:21 +0100:
>>> > On Wed, Jan 15, 2020 at 12:47:28PM
On Wed, May 20, 2020 at 05:42:35PM +0300, Vitaliy Makkoveev wrote:
> I got splassert with pppx(4) and net/ifq.c rev 1.38 raised by
> NET_ASSERT_LOCKED() in netinet/ip_output.c:113 and underlaying routines.
>
> net/ifq.c rev 1.38 is not in snapshot yet so you need to checkout and
> build kernel to
Generally packets are not transmitted by carp interfaces, but we have a
couple of things at work that mean we do send packets out on them.
Firstly, we have a dhcp relay implementation we run on carp interfaces,
and we sent dhcp replies fast enough to fill up the one slot on the
transmit queue and
> On 20 May 2020, at 1:31 am, Miod Vallat wrote:
>
> There seems to be a logic error in tcpdump's print-gtp.c.
>
> The code is printing some values by passing a pointer to the array of
> strings, and the index within the array, and the routine uses
> sizeof(array) / sizeof(array[0]) to
> On 28 Apr 2020, at 13:31, Todd C. Miller wrote:
>
> On Thu, 02 Apr 2020 16:21:47 -0600, "Todd C. Miller" wrote:
>
>> In vim, the expandtab option expands tabs to spaces in insert mode
>> as well as when shifting and indenting/outdenting. This is very
>> useful when working on a code-base
> On 14 Apr 2020, at 8:15 pm, Remi Locherer wrote:
>
> On Tue, Apr 14, 2020 at 01:49:32PM +1000, David Gwynne wrote:
>>
>>
>>> On 13 Apr 2020, at 19:03, Remi Locherer wrote:
>>>
>>> Hi,
>>>
>>> I recently looked i
> On 13 Apr 2020, at 19:03, Remi Locherer wrote:
>
> Hi,
>
> I recently looked into NHRP (RFC 2332) and noticed that our tcpdump does
> not have a printer for it. So I added support for NHRP to tcpdump.
>
> Initially I was surprised: I expected a simpler protocol! But it is from
> the 90's
> On 10 Mar 2020, at 00:04, Stuart Henderson wrote:
>
> On 2020/03/09 22:50, David Gwynne wrote:
>> this works better on his epyc 2 box, and works right on my epyc 1, esxi
>> on epyc 1, and on an apu1.
>
> Fine on apu2 (GX-412TC) and the old HP microserver (Turi
On Tue, Mar 10, 2020 at 12:03:24AM +0100, Tobias Heider wrote:
> If 'm = ifq->ifq_ops->ifqop_deq_begin(ifq, )' is not NULL
> the loop is exited and an uninitialized 'int error' is returned.
> Several lines below error is checked for '!= 0', so i assume it
> was meant to be initialized to '0'.
>
On Mon, Mar 09, 2020 at 11:56:09PM +0100, Klemens Nanni wrote:
> On Mon, Mar 09, 2020 at 10:33:17PM +0100, Tobias Heider wrote:
> > there seems to be a nullptr dereference in if_hooks_run.
> Did your kernel crash here or did you find reading alone?
>
> > When the inner while loop is exited
On Mon, Mar 09, 2020 at 05:00:37PM +1000, David Gwynne wrote:
> 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 a
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
we (work) use radiusctl as part of a check script with relayd so
we can try and keep a radius service available with some magical
routing and redirect configs.
radiusctl is currently pretty simple and sends a radius request,
and then waits for a reply. however, it does not implement retries
and
> On 25 Jan 2020, at 10:57 am, Mark Kettenis wrote:
>
> David Gwynne schreef op 2020-01-25 01:28:
>>> On 23 Jan 2020, at 10:38 pm, Mark Kettenis wrote:
>>> Martin Pieuchot schreef op 2020-01-23 11:28:
>>>> I'd like to make progress towards interrupting
> On 23 Jan 2020, at 10:38 pm, Mark Kettenis wrote:
>
> Martin Pieuchot schreef op 2020-01-23 11:28:
>> I'd like to make progress towards interrupting multiple CPUs in order to
>> one day make use of multiple queues in some network drivers. The road
>> towards that goal is consequent and I'd
> On 22 Jan 2020, at 8:54 am, Damien Miller wrote:
>
> On Wed, 22 Jan 2020, David Gwynne wrote:
>
>>> Index: sys/kern/kern_pledge.c
>>> ===
>>> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
Has anyone got an opinion on this? I am still interested in doing more
packet capture things on OpenBSD using GRE as a transport, and the idea
of maintaining this out of tree just makes me feel tired.
On Tue, Oct 29, 2019 at 06:34:50PM +1000, David Gwynne wrote:
> i've been toying with this i
claudio and i have been looking at some tun(4) semantics, and want to
move stuff around, but feel constrained because PIPEX has been very
carefully added to tun(4). the PIPEX bits make it hard to rearrange
tun(4), so this moves that functionality out into a separate driver
called pppac(4).
so this should go in and i can keep improving things in the tree?
dlg
> On 6 Dec 2019, at 9:45 pm, Claudio Jeker wrote:
>
> On Fri, Dec 06, 2019 at 12:16:09PM +0100, Sebastian Benoit wrote:
>> David Gwynne(da...@gwynne.id.au) on 2019.12.06 15:14:42 +1000:
>>>
>>&
On Fri, Dec 06, 2019 at 03:14:42PM +1000, David Gwynne wrote:
>
>
> > On 5 Dec 2019, at 21:14, Sebastian Benoit wrote:
> >
> > Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.12.05 09:53:49 +0100:
> >> I would suggest to just pack most of the headers into one g
> On 5 Dec 2019, at 21:14, Sebastian Benoit wrote:
>
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.12.05 09:53:49 +0100:
>> I would suggest to just pack most of the headers into one group of ().
>>
>> IPv4 ttl 1 [tos 0x20] 10.0.127.15 > 10.0.127.1
>> would become
>> IPv4 (ttl 1 tos 0x20)
this is a significant reworking of tcpdump with a couple of goals
twisted together.
it is becoming increasingly common to encapsulate protocols, leading
to situations where you have some kind of ip packet inside another
ip packet. i am arguing our current ip printing code sucks in this
situation
-
+++ print-nsh.c 2 Dec 2019 23:11:06 -
@@ -0,0 +1,308 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2019 David Gwynne
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the abov
201 - 300 of 1094 matches
Mail list logo
