On Tue, Jan 26, 2021 at 08:56:29PM +, Edd Barrett wrote:
> Hi,
>
> I've recently come across a uaudio device which doesn't work in OpenBSD:
>
> uaudio2 at uhub0 port 1 configuration 1 interface 3 "E+ Corp. DAC Audio" rev
> 1.10/0.01 addr 2
> uaudio2: class v1, full-speed, async, channels: 2
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
Hello,
On Wed, Jan 27, 2021 at 04:41:01PM +1000, David Gwynne wrote:
> at the moment if the route is invalid, we drop the packet. this
> generates an icmp error.
>
> ok?
looks good to me.
ok sashan
>
> Index: pf.c
> ===
>
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
On Tue, Jan 26, 2021 at 08:56:29PM +, Edd Barrett wrote:
> Hi,
>
> I've recently come across a uaudio device which doesn't work in OpenBSD:
>
> uaudio2 at uhub0 port 1 configuration 1 interface 3 "E+ Corp. DAC Audio" rev
> 1.10/0.01 addr 2
> uaudio2: class v1, full-speed, async, channels:
On Wed, Jan 27, 2021 at 11:31:27AM +1000, David Gwynne wrote:
> 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
On Sun, Jan 24, 2021 at 9:04 PM Bernhard Voelker
wrote:
>
> An off-tech argument: ask a local plumber if he'd would ever use
> a tee piece instead of a pipe end piece. I guess he would only
> if he wouldn't have anything else at hand.
According to POSIX, tee writes to "zero or more files."[1]
On Wed, Jan 27, 2021 at 11:31:27AM +1000, David Gwynne wrote:
> 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
On Wed, Jan 27, 2021 at 11:14:51AM +1000, David Gwynne wrote:
> 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
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 the pf_pdesc
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 the pf_pdesc
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
Hi Klemens,
Klemens Nanni wrote on Sat, Jan 16, 2021 at 10:31:49AM +0100:
> On rare occasions I'd like to use the following idiom to read manuals in
> browsers, mostly to better readability and navigation of long sections:
>
> MANPAGER=netsurf-gtk3 man -Thtml jq
>
> (jq(1) has lots of
On 1/26/21 12:13 PM, Stuart Henderson wrote:
> On 2021/01/26 11:18, Jordan Geoghegan wrote:
>>
>> On 1/26/21 5:47 AM, Stuart Henderson wrote:
>>> On 2021/01/25 00:53, Sebastian Benoit wrote:
Sebastian Benoit(be...@openbsd.org) on 2021.01.25 00:27:05 +0100:
> Theo de
Hi,
I've recently come across a uaudio device which doesn't work in OpenBSD:
uaudio2 at uhub0 port 1 configuration 1 interface 3 "E+ Corp. DAC Audio" rev
1.10/0.01 addr 2
uaudio2: class v1, full-speed, async, channels: 2 play, 0 rec, 3 ctls
audio3 at uaudio2
When opening the audio device, the
On 2021/01/26 11:18, Jordan Geoghegan wrote:
>
>
> On 1/26/21 5:47 AM, Stuart Henderson wrote:
> > On 2021/01/25 00:53, Sebastian Benoit wrote:
> >> Sebastian Benoit(be...@openbsd.org) on 2021.01.25 00:27:05 +0100:
> >>> Theo de Raadt(dera...@openbsd.org) on 2021.01.24 16:01:32 -0700:
>
On 1/26/21 5:47 AM, Stuart Henderson wrote:
> On 2021/01/25 00:53, Sebastian Benoit wrote:
>> Sebastian Benoit(be...@openbsd.org) on 2021.01.25 00:27:05 +0100:
>>> Theo de Raadt(dera...@openbsd.org) on 2021.01.24 16:01:32 -0700:
Stuart Henderson wrote:
> On 2021/01/24 12:10, Theo
On 2021/01/26 09:29, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > >
> > >
> > > I'm not sure if proposed scenario real. Let's assume there
> > > is a PF box with three NICs running on this awkward set up
> > >
> > > em1 ... 192.168.1.10
> > >
> > > em0
> > >
> > >
On 23/01/21(Sat) 12:22, Denis Fondras wrote:
> Le Sat, Jan 09, 2021 at 06:50:50PM +0100, Denis Fondras a écrit :
> > This diff place the user-set source address outside of struct art_root and
> > make
> > the code more readable (to me).
> >
> > Based on a concept by mpi@
Comments below.
> >
On Tue, Jan 26, 2021 at 05:53:26PM +0100, Klemens Nanni wrote:
> On Tue, Jan 26, 2021 at 05:22:42PM +0100, Florian Obser wrote:
> > On Mon, Jan 25, 2021 at 07:05:40PM +0100, Florian Obser wrote:
> > > Unwind / libunbound goes pretty badly off the rails when an address
> > > family is not
On Tue, Jan 26, 2021 at 05:22:42PM +0100, Florian Obser wrote:
> On Mon, Jan 25, 2021 at 07:05:40PM +0100, Florian Obser wrote:
> > Unwind / libunbound goes pretty badly off the rails when an address
> > family is not available, it still tries to talk to nameservers with an
> > unreachable address
On Mon, Jan 25, 2021 at 07:05:40PM +0100, Florian Obser wrote:
> Unwind / libunbound goes pretty badly off the rails when an address
> family is not available, it still tries to talk to nameservers with an
> unreachable address family.
> I don't think it's libunbound's place to figure this out. It
On Mon, Jan 25, 2021 at 08:56:36PM +0100, Klemens Nanni wrote:
> On Mon, Jan 25, 2021 at 07:05:40PM +0100, Florian Obser wrote:
> > Unwind / libunbound goes pretty badly off the rails when an address
> > family is not available, it still tries to talk to nameservers with an
> > unreachable address
On Mon, Jan 25, 2021 at 11:17:04AM +0100, Martijn van Duren wrote:
> if (argc == 1) {
> - double del = atof(argv[0]);
> - if (del == 0)
> + delay = strtodnum(argv[0], 0, UINT32_MAX / 100, );
> + if (errstr != NULL)
>
On 2021/01/25 00:53, Sebastian Benoit wrote:
> Sebastian Benoit(be...@openbsd.org) on 2021.01.25 00:27:05 +0100:
> > Theo de Raadt(dera...@openbsd.org) on 2021.01.24 16:01:32 -0700:
> > > Stuart Henderson wrote:
> > >
> > > > On 2021/01/24 12:10, Theo de Raadt wrote:
> > > > > I completely
Hello,
On Tue, Jan 26, 2021 at 12:33:25PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> > > But what about dup-to? The packet is duplicated for both directions.
> > > I guess the main use case for dup-to is implementing a monitor port.
> > >
On Tue, Jan 26, 2021 at 12:33:25PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> > > But what about dup-to? The packet is duplicated for both directions.
> > > I guess the main use case for dup-to is implementing a monitor port.
> > > There you
On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> > But what about dup-to? The packet is duplicated for both directions.
> > I guess the main use case for dup-to is implementing a monitor port.
> > There you have to pass packets stateless, otherwise it would not
> > work anyway.
This diff adds initial RTR (RPKI to Router) support to bgpd.
Instead of loading the roa-set table via the configuration bgpd will use
RTR to load the RPKI table from one or multiple RTR servers.
This has the benefit that in large setups only a few systems need to run
rpki-client instead of running
Hello,
On Tue, Jan 26, 2021 at 10:39:30AM +1000, David Gwynne wrote:
> 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/GENERIC 30 Sep 2020 14:51:17 - 1.273
> > > +++
Hello,
> > > goto bad;
> >
> > here we do 'goto bad', which does not call if_put().
>
> yes it does. the whole chunk with the diff applied is:
>
> done:
> if (s->rt != PF_DUPTO)
> pd->m = NULL;
> if_put(ifp);
> rtfree(rt);
>
Hello,
>
> i'll need help with "match on em0 route-to $if_em0_peer". or we can do
> that later separately?
may be can we keep this line in pf_route() untouched at least for now:
6041
6042 if (pd->kif->pfik_ifp != ifp) {
6043 if (pf_test(AF_INET, PF_OUT, ifp, ) !=
Hello,
> >
> >
> > I'm not sure if proposed scenario real. Let's assume there
> > is a PF box with three NICs running on this awkward set up
> >
> > em1 ... 192.168.1.10
> >
> > em0
> >
> > em2 ... 192.168.1.10
> >
> > em0 is attached
34 matches
Mail list logo
