On Thu, Feb 24, 2022 at 11:13:48AM +0100, Claudio Jeker wrote:
> On Thu, Feb 24, 2022 at 07:39:54PM +1000, David Gwynne wrote:
> >
> > here's the diff.
> >
> > Index: if_tun.c
> > ===
> >
On Mon, Feb 21, 2022 at 03:00:01PM +1000, David Gwynne wrote:
> On Sun, Feb 20, 2022 at 10:30:22AM +1000, David Gwynne wrote:
> >
> >
> > > On 20 Feb 2022, at 09:46, David Gwynne wrote:
> > >
> > > On Sat, Feb 19, 2022 at 02:58:08PM -0800, Greg
this lets ifconfig show the MTU on interfaces like nvgre, vxlan, etc.
they currently don't show it because they also implement a bridge ioctl,
so ifconfig thinks they're a bridge.
why ifconfig hides the mtu on bridges looks to be a hold over from when
brconfig was merged into ifconfig. if we dont
On Fri, Feb 11, 2022 at 03:13:25PM +1000, David Gwynne wrote:
> On Fri, Mar 05, 2021 at 05:09:29PM +1000, David Gwynne wrote:
> > On Thu, Mar 04, 2021 at 03:36:19PM +1000, David Gwynne wrote:
> > > as the subject says, this is a rewrite of vxlan(4).
> > >
> &
On Mon, Feb 14, 2022 at 08:34:42AM +, Visa Hankala wrote:
> This makes bpf(4) use knote_modify_fn() and knote_process_fn().
>
> Since the code has only one event function, it makes sense to use it
> directly instead of going through struct filterops f_event pointer.
>
> OK?
ok.
>
> Index:
consistently means we do the check in pf_rule_copyin() so both
DIOCADDRULE and DIOCCHANGERULE have the prio values checked. this in
turn prevents invalid prio values getting set on a rule via
DIOCCHANGERULE, which in turn stops a kassert in the ifq priq code
firing.
i think this fixes
if an open tun (or tap) device is destroyed via ifconfig destroy,
there is a window while the open device is being revoked on the vfs
side that a third thread can come and open it again. this in turn
triggers a kassert in the ifconfig destroy path where it expects the
device to be closed.
i think
On Fri, Mar 05, 2021 at 05:09:29PM +1000, David Gwynne wrote:
> 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
On Wed, Jan 26, 2022 at 01:29:42AM +0100, Alexander Bluhm wrote:
> Hi,
>
> There were some problems with ix(4) and ixl(4) hardware checksumming
> for the output path on strict alignment architectures.
>
> I have merged jan@'s diffs and added some sanity checks and
> workarounds.
>
> - If the
On Mon, Feb 07, 2022 at 02:39:38PM +1000, David Gwynne wrote:
> On Fri, Feb 04, 2022 at 09:29:56PM +1000, David Gwynne wrote:
> > On Fri, Jan 28, 2022 at 05:26:01PM +0100, Alexander Bluhm wrote:
> > > On Wed, Jan 26, 2022 at 11:05:51AM +0100, Claudio Jeker wrote:
> > > &
On Fri, Feb 04, 2022 at 09:29:56PM +1000, David Gwynne wrote:
> On Fri, Jan 28, 2022 at 05:26:01PM +0100, Alexander Bluhm wrote:
> > On Wed, Jan 26, 2022 at 11:05:51AM +0100, Claudio Jeker wrote:
> > > On Wed, Jan 26, 2022 at 01:29:42AM +0100, Alexander Bluhm
ok
On Sat, 5 Feb 2022, 01:08 Claudio Jeker, wrote:
> This is something I wanted to do for a while. Switch from u_intXY_t to
> uintXY_t from stdint.h. The diff is mostly mechanical and was done with
> sed -i 's/u_intX_t/uintX_t/g' but uint8_t changes the tab spacing and so
> I had a look over
On Fri, Feb 04, 2022 at 11:39:56AM +0100, Alexander Bluhm wrote:
> On Fri, Feb 04, 2022 at 07:32:52PM +1000, David Gwynne wrote:
> > as discussed in "m_pullup alingment crash armv7 sparc64", at worst it
> > doesnt hurt to have m_pullup maintain the data alignment of
Ok
On Fri, 4 Feb 2022, 21:19 Claudio Jeker, wrote:
> On illumos sun is defined by some header so better not use sun as a
> variable name. Rename variable to sa_un to reduce hacks in -portable.
>
> --
> :wq Claudio
>
> Index: bgpctl/bgpctl.c
>
On Fri, Jan 28, 2022 at 05:26:01PM +0100, Alexander Bluhm wrote:
> On Wed, Jan 26, 2022 at 11:05:51AM +0100, Claudio Jeker wrote:
> > On Wed, Jan 26, 2022 at 01:29:42AM +0100, Alexander Bluhm wrote:
> > > Hi,
> > >
> > > There were some problems with ix(4) and ixl(4) hardware checksumming
> > >
as discussed in "m_pullup alingment crash armv7 sparc64", at worst it
doesnt hurt to have m_pullup maintain the data alignment of payloads,
and at best it will encourage aligned loads even if the arch allows
unaligned accesses. aligned loads are faster than unaligned.
ok?
Index: uipc_mbuf.c
On Thu, Feb 03, 2022 at 11:39:50PM +0100, Alexander Bluhm wrote:
> On Thu, Feb 03, 2022 at 10:22:46PM +1000, David Gwynne wrote:
> > bpf should know better than this. it has all the information it needs to
> > align the payload properly, it just doesnt make enough of an effort.
On Wed, Feb 02, 2022 at 10:30:24PM +0100, Alexander Bluhm wrote:
> Hi,
>
> With the new m_pullup() code, I see crashes on armv7 and sparc64.
> regress/sbin/slaacd sends some IPv6 ND6 packets over pair(4) from
> scapy. It crashes after m_pullup() in ipv6_check().
>
> run-parse-ra
>
On Sun, Jan 16, 2022 at 06:17:16AM +, Visa Hankala wrote:
> On Sun, Jan 16, 2022 at 02:41:46PM +1000, David Gwynne wrote:
> > if you're in bpfclose or tun/tap close, you're the last one out. this
> > means that there shouldn't be anything else in poll/select/kevent/etc
>
if you're in bpfclose or tun/tap close, you're the last one out. this
means that there shouldn't be anything else in poll/select/kevent/etc
because you're the last one out.
from what i can tell, tun and bpf are the only drivers that do this, and
i dont think they need to.
ok?
Index: bpf.c
and then shift and mask the interesting bits out.
this works on an overdrive 1000, where i discovered that arm64 appears
to have a single instruction for shift/mask.
maybe too much churn to be worth it?
Index: if_msk.c
===
RCS
this is what i want to commit to fix "msk(4) not working with trunk(4)
(Marvell Yukon 88E8042)" as reported on bugs@.
the register that msk_txeof currently uses to figure out where it
should read up to appears to be more a counter than an actual index.
the linux driver doesnt use it though, it
i was trying to understand some packets that tcpdump didnt know about,
and discovered they were EAPOL. turns out EAPOL is a little container
around a bunch of different types of messages including EAP, the
MACsec Key Agreement protocol, and it's own type of capabilities
advertisements.
this
are you able to find a reference for this in any of the current specs? or in
documentation from other vendors?
i've faithfully maintained this behaviour, but the only place i've seen in with
my own eyes is in our code. if we're doing it different to literally everyone
else, then maybe we
On Mon, Nov 15, 2021 at 02:31:42PM +, Klemens Nanni wrote:
> On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote:
> > On 2021/11/15 12:27, Klemens Nanni wrote:
> > > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote:
> > > > I think physical interfaces should come up
On Mon, Nov 15, 2021 at 12:19:48PM +, Klemens Nanni wrote:
> On Mon, Nov 15, 2021 at 02:08:33PM +1000, David Gwynne wrote:
> > The subject line only tells half the story. The other half is that
> > instead of hoping it only identifies Ethernet interfaces it now actu
The subject line only tells half the story. The other half is that
instead of hoping it only identifies Ethernet interfaces it now actually
checks and restricts itself to Ethernet interfaces. I couldn't help
myself.
If it helps my case for this code, I've been using this semantic for a
few years
On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote:
> Practically all interfaces pull itself up when IPs get assigned, but
> vport(4) does not.
Yes, I do (or don't do) this very deliberately when I get the chance.
> This broke IPv4 networking for me on a router I switched from
On Thu, Oct 28, 2021 at 03:43:11PM +0100, Jason McIntyre wrote:
> On Thu, Oct 28, 2021 at 04:53:39PM +1000, David Gwynne wrote:
> >
> >
> > > On 28 Oct 2021, at 15:35, Jason McIntyre wrote:
> > >
> > > On Thu, Oct 28, 2021 at 01:27:17PM +1000, David G
On Thu, Oct 28, 2021 at 04:06:39PM +0100, Stuart Henderson wrote:
> On 2021/10/28 13:11, David Gwynne wrote:
> > On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote:
> > > On 2021/10/27 17:44, David Gwynne wrote:
> > > >
> > > > >
> On 28 Oct 2021, at 15:35, Jason McIntyre wrote:
>
> On Thu, Oct 28, 2021 at 01:27:17PM +1000, David Gwynne wrote:
>>
>>> that strategy does rely on individual driver docs saying upfront that
>>> they can be created though, even if using create is not
On Wed, Oct 27, 2021 at 02:32:31PM +0100, Jason McIntyre wrote:
> On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote:
> > On 2021/10/27 17:44, David Gwynne wrote:
> > >
> > > > benno@ suggested I look at vether(4) to adapt the text related to
> >
On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote:
> On 2021/10/27 17:44, David Gwynne wrote:
> >
> > > benno@ suggested I look at vether(4) to adapt the text related to
> > > bridge(4) but I'm not sure how to rewrite it properly for veb(4).
> >
&g
On Wed, Oct 27, 2021 at 08:34:48AM +0200, Solene Rapenne wrote:
> On Wed, 27 Oct 2021 07:28:32 +1000
> David Gwynne :
>
> > On Tue, Oct 26, 2021 at 09:18:30PM +0200, Solene Rapenne wrote:
> > > I tried to figure out how to use veb interfaces but the man page
> &g
On Tue, Oct 26, 2021 at 09:18:30PM +0200, Solene Rapenne wrote:
> I tried to figure out how to use veb interfaces but the man page
> wasn't obvious in regards to the "vport" thing. It turns out it's
> a kind of interface that can be created with ifconfig.
>
> I think we should make this clearer.
i bought some random usb to rs485 serial adapters so i can talk
modbus to a thing, but then discovered i can't talk to the modbus
thing because uchcom doesn't support configuring parity.
this ports the functionality to support configuring parity and char size
masks from netbsd
lution fixes a DF problem, and makes the no-df option
> superfluous, and works out of the box, we can consider implementing
> it for DF packets.
I'll have to think about that for a bit.
>
> bluhm
>
> On Tue, Aug 31, 2021 at 10:56:34PM +1000, David Gwynne wrote:
> > i am in
i am in an annoying situation where i peer with a campus network on an
ospf link with a 9k mtu, but some corners of that network have layer 2
hops that don't support 9k packets. i sometimes want to tunnel large
(1500 byte) packets to hosts in those corners of the network by
letting the
On Tue, Aug 31, 2021 at 07:33:40AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> On Tue, Aug 31, 2021 at 02:40:57PM +1000, David Gwynne wrote:
> > handling the "no" option with a token, and "yes" via a string made my
> > eye twitch.
> >
&
handling the "no" option with a token, and "yes" via a string made my
eye twitch.
ok? or is the helpful yyerror a nice feature?
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.709
diff -u -p -r1.709
On Thu, Jun 24, 2021 at 09:31:20AM +0200, Alexandr Nedvedicky wrote:
> Hello David,
>
>
> >
> > i think we can get away with not refcounting eb_entry structures at all.
> > either they're in the etherbridge map/table or they're not, and the
> > thing that takes them out of the map while holding
On Sat, Jun 19, 2021 at 12:32:04AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> skip reading if you are not interested in L2 switching combined
> with bluhm's diff [1], which enables parallel forwarding.
>
> Hrvoje gave it a try and soon discovered some panics. Diff below
> fixes a panic
On Wed, Jun 16, 2021 at 02:59:19AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
>
> >
> > as above, copyout with a sleeping lock is fine.
> >
> > the whole point of my change is to give us the ability to lock in the
> > forwarding path separately to locking in the ioctl path. half of that is
>
> On 16 Jun 2021, at 00:39, Martin Pieuchot wrote:
>
> On 15/06/21(Tue) 22:52, David Gwynne wrote:
>> On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
>>> On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
>> [...]
>>>> The in6_ functi
> On 16 Jun 2021, at 01:10, Scott Cheloha wrote:
>
> Hi,
>
> dlg@ just moved nsecuptime() and getnsecuptime() into kern_tc.c.
>
> To tidy it up I'd like to refactor the fraction-to-nanosecond and
> bintime-to-nanosecond conversions into new functions so we only need
> to write them once.
> On 14 Jun 2021, at 19:12, Alexandr Nedvedicky
> wrote:
>
> Hello,
>
> looks good to me. I think this should be committed
> as-is. I have just one question,
>
> On Mon, Jun 14, 2021 at 01:58:06PM +1000, David Gwynne wrote:
>
>> @@ -1931,6 +1933,9
On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote:
> On 10/06/21(Thu) 19:17, Alexander Bluhm wrote:
> > Hi,
> >
> > I have seen this crash trace on a 6.6 based system, but I think the
> > bug exists still in -current. It happened when an ixl(4) interface
> > was removed from
On Tue, Jun 08, 2021 at 06:54:25PM +0200, Alexandr Nedvedicky wrote:
> Hello David,
>
> I'm still not sure if your change is ultimate fix, or just significantly
> minimizes risk of the bug. If I understand things right, the problem we are
> trying to solve:
> DIOCGETSTATES we have in
pfsync deferrals are used so if you have firewalls that could both
process packets, you defer sending the initial packet in state so the
peer can learn about the state before potentially handling packets for
it.
there are three ways that a deferal can end. the preferred one is if a
peer firewall
On Sat, Jun 05, 2021 at 01:09:01PM +0200, Alexandr Nedvedicky wrote:
> Hello David,
>
>
>
> > the scope of the pf locks likely needs reduction anyway. one of my
>
> I agree. pf_lock covers too much in PF currently. it protects,
> all rules, tables and fragment caches.
>
> > production
we have a few places that use a uint64_t with the number of nanosecons
of uptime the machine has. this factors it out to make them a bit more
generally available.
i was going to add yet another one of these to pfsync, but thought it
might be a good idea to factor them out first.
ok?
Index:
On Thu, Jun 03, 2021 at 01:09:48AM +0200, Alexandr Nedvedicky wrote:
> > pf_purge_expired_states(u_int32_t maxcheck)
> > {
>
> > - cur = pf_state_ref(next);
> > + do {
> > + if ((cur->timeout == PFTM_UNLINKED) ||
> > + (pf_state_expires(cur) <= getuptime()))
On Thu, Jun 03, 2021 at 01:09:48AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> looks like my earlier mail got eaten by SPAM filter, let's try again...
>
>
> >
> > moving pf locks to mutexes makes sense to me, but like you say,
> > this will need testing and experimentation. one of the
On Wed, May 19, 2021 at 01:48:26AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> just for the record...
>
>
>
> > > in current tree the ether_input() is protected by NET_LOCK(), which is
> > > grabbed
> > > by caller as a writer. bluhm's diff changes NET_LOCK() readlock, so
> > >
if a bridge checked the ipv4 checksum and it was good, we can avoid
checking it again in ip_input.
ok?
Index: ip_input.c
===
RCS file: /cvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.361
diff -u -p -r1.361 ip_input.c
---
> On 1 Jun 2021, at 04:17, Patrick Wildt wrote:
>
> Hi,
>
> this call to sync the DMA mem wants to sync N - 1 number of prpl
> entries, as the first segment is configured regularly, while the
> addresses for the following segments (if more than 2), are in a
> special DMA memory.
>
> The
> On 1 Jun 2021, at 02:58, Visa Hankala wrote:
>
> This patch enables the pool cache feature on the knote pool to reduce
> the overhead of knote management.
>
> Profiling done by mpi@ and bluhm@ indicate that the potentially needless
> allocation of knotes in kqueue_register() causes
> On 1 Jun 2021, at 04:15, Patrick Wildt wrote:
>
> Hi,
>
> mcx(4) seems to sync the whole mapsize on processing a received packet.
> As far as I know, we usually only sync the actual size that we have
> received. Noticed this when doing bounce buffer tests, seeing that
> it copied a lot
if you're looking at an ip header, it makes sense to do some checks to
make sure that the values and addresses make some sense. the canonical
versions of these checks are in the ipv4 and ipv6 input paths, which
makes sense. when bridge(4) is about to run packets through pf it makes
sure the ip
On Thu, May 06, 2021 at 11:43:55AM -0500, Scott Cheloha wrote:
> On Wed, May 05, 2021 at 11:05:06AM +1000, David Gwynne wrote:
> > On Tue, May 04, 2021 at 11:54:31AM -0500, Scott Cheloha wrote:
> > >
> > > [...]
> > >
> > > Here is where I get
On Tue, May 04, 2021 at 11:54:31AM -0500, Scott Cheloha wrote:
> On Tue, May 04, 2021 at 11:21:27PM +1000, David Gwynne wrote:
> > On Tue, May 04, 2021 at 11:24:05AM +0200, Martin Pieuchot wrote:
> > > On 04/05/21(Tue) 01:10, Scott Cheloha wrote:
> > > > [...]
&
On Tue, May 04, 2021 at 11:24:05AM +0200, Martin Pieuchot wrote:
> On 04/05/21(Tue) 01:10, Scott Cheloha wrote:
> > [...]
> > I want to run softclock() without the kernel lock. The way to go, I
> > think, is to first push the kernel lock down into timeout_run(), and
> > then to remove the kernel
On Wed, Apr 21, 2021 at 01:15:53PM +, Visa Hankala wrote:
> On Wed, Apr 21, 2021 at 11:04:20AM +1000, David Gwynne wrote:
> > On Wed, Apr 21, 2021 at 10:21:32AM +1000, David Gwynne wrote:
> > > if you have a program that uses kq (or libevent) to wait for bytes to
> > &g
On Wed, Apr 21, 2021 at 10:21:32AM +1000, David Gwynne wrote:
> if you have a program that uses kq (or libevent) to wait for bytes to
> read off an idle network interface via /dev/bpf and that interface
> goes away, the program doesnt get woken up. this is because the kq
> read filter
if you have a program that uses kq (or libevent) to wait for bytes to
read off an idle network interface via /dev/bpf and that interface
goes away, the program doesnt get woken up. this is because the kq
read filter in bpf only checks if there ares bytes available. because a
detached interface
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:
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
> 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 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
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
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
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
vision 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 $ */
+/* $OpenBSD$ */
/*
- * Copyright (c) 2013 Reyk
> 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
> 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
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
>
> 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 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
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,
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 al
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
> 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++
> 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
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.c
orage *ss, void *port)
+{
+ struct ether_addr *endpoint = port;
+ struct sockaddr_dl *sdl;
+
+ sdl = (struct sockaddr_dl *)ss;
+ sdl->sdl_len = sizeof(sdl);
+ sdl->sdl_family = AF_LINK;
+ sdl->sdl_index = 0;
+ sdl->sdl_type = IFT_ETHER;
+ sdl->
> 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
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
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.
> > >
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,
>
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
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's
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
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_LOCAL
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
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
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
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
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
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.
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
101 - 200 of 1094 matches
Mail list logo
