On Mon, Jan 04, 2021 at 11:42:59PM +0100, Martin Vahlensieck wrote:
> Hi there
>
> I guess this should only be one one.
>
> Best,
>
> Martin
>
fixed, thanks.
jmc
> Index: man/EVP_DigestInit.3
> ===
> RCS file:
Ping.
I'm hoping someone can review the diff adding -p to pr(1).
On Fri, Dec 11, 2020 at 9:54 PM Andras Farkas wrote:
>
> Hi!
>
> After seeing the diff for cat -n earlier today, and just browsing Unix
> stuff on my own, I noticed OpenBSD's pr(1) command has no -p option
> despite pr.1 stating:
>
Hello,
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 and let the packet go
Hi there
I guess this should only be one one.
Best,
Martin
Index: man/EVP_DigestInit.3
===
RCS file: /cvs/src/lib/libcrypto/man/EVP_DigestInit.3,v
retrieving revision 1.19
diff -u -p -r1.19 EVP_DigestInit.3
---
On Mon, Jan 04, 2021 at 08:48:55PM +0100, Otto Moerbeek wrote:
> On Mon, Jan 04, 2021 at 05:50:53PM +0100, Otto Moerbeek wrote:
>
> > tOn Mon, Jan 04, 2021 at 01:42:48PM +0100, Theo Buehler wrote:
> >
> > > > > + return log_sockaddr(addr2sa(addr, 0, ), len);
> > > >
> > > > Perhaps
On Mon, Jan 04, 2021 at 05:50:53PM +0100, Otto Moerbeek wrote:
> tOn Mon, Jan 04, 2021 at 01:42:48PM +0100, Theo Buehler wrote:
>
> > > > + return log_sockaddr(addr2sa(addr, 0, ), len);
> > >
> > > Perhaps I haven't yet had enough coffee this year, but I'm unsure
> > > whether it
On Mon, Jan 04, 2021 at 06:03:46PM +0100, Mark Kettenis wrote:
> > Date: Sun, 3 Jan 2021 13:47:45 +0100
> > From: Otto Moerbeek
> >
> > On Thu, Dec 31, 2020 at 05:54:06PM +0100, Alexander Bluhm wrote:
> >
> > > On Tue, Dec 29, 2020 at 04:07:19PM +0100, Otto Moerbeek wrote:
> > > > This workds
So this is probably a sensible next step to cleanup log_addr() a bit more.
Teach addr2sa() how to convert the VPN addresses into sockaddrs. The rd
and labelstack still needs to be handled by the caller.
OK?
--
:wq Claudio
Index: util.c
On Mon, Jan 04, 2021 at 01:42:48PM +0100, Theo Buehler wrote:
> > > + return log_sockaddr(addr2sa(addr, 0, ), len);
> >
> > Perhaps I haven't yet had enough coffee this year, but I'm unsure
> > whether it is actually guaranteed that addr2sa() is called before the
> > second len in this
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 and let the packet go through without running it through the
> a lot of the state handling, which includes
In order to get trap support back into relayd libagentx needs to get
notify support. Here's my interpretation on the matter. Relayd itself
still needs a proper NOTIFICATION-TYPE definition before that can be
implemented, but that shouldn't stop this diff.
I already have an OK rob@, but additional
Hello,
> My diff removes the kif here ...
>
> > > > - if (rv == 0) {
> > > > - s->rt_kif = r->route.kif;
> > > > + if (rv == 0)
> > > > s->natrule.ptr = r;
> > > > - }
>
> ... and the {}.
>
> Anyway, it should not be commited without the
> Date: Sun, 3 Jan 2021 13:47:45 +0100
> From: Otto Moerbeek
>
> On Thu, Dec 31, 2020 at 05:54:06PM +0100, Alexander Bluhm wrote:
>
> > On Tue, Dec 29, 2020 at 04:07:19PM +0100, Otto Moerbeek wrote:
> > > This workds better, checking the flags does not work if the thread is
> > > already on the
tOn Mon, Jan 04, 2021 at 01:42:48PM +0100, Theo Buehler wrote:
> > > + return log_sockaddr(addr2sa(addr, 0, ), len);
> >
> > Perhaps I haven't yet had enough coffee this year, but I'm unsure
> > whether it is actually guaranteed that addr2sa() is called before the
> > second len in this
Le Mon, Jan 04, 2021 at 05:04:51PM +0100, Claudio Jeker a écrit :
> bgpd will get a new process for RTR handling. Because of this it makes
> sense to cleanup the startup code a bit and not use flags to indicate
> which process to run but instead use the enum bgpd_process.
> Additionally change the
On Mon, Jan 04, 2021 at 04:32:45PM +0100, Alexandr Nedvedicky wrote:
> so either rt_kif must stay for a while, or your new diff (rebased on top
> of
> stuff committed already) must be expanded by the nit pick I've sent.
The diff I sent contains this bit. I still think the merge bug is
bgpd will get a new process for RTR handling. Because of this it makes
sense to cleanup the startup code a bit and not use flags to indicate
which process to run but instead use the enum bgpd_process.
Additionally change the PFD_PIPE_ROUTE to PFD_PIPE_RDE. The latter is less
confusing since there
Hello,
I'm sorry I was not clear enough in my earlier email.
On Mon, Jan 04, 2021 at 03:56:45PM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 03:26:15PM +0100, Alexandr Nedvedicky wrote:
> > you refactoring diff requires a minor finishing touch to keep the
> > stuff compiling:
>
> Did
On Mon, Jan 04, 2021 at 03:26:15PM +0100, Alexandr Nedvedicky wrote:
> you refactoring diff requires a minor finishing touch to keep the
> stuff compiling:
Did I commit something that does not compile? I just made cvs
update on another machine. There it worked.
The rt_kif in pf_state still
Hello,
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
Hello,
On Mon, Jan 04, 2021 at 11:21:50PM +1000, David Gwynne wrote:
> 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
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 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 after merge.
bluhm
Index: net/if_pfsync.c
> 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
OK
On Mon, Jan 04, 2021 at 10:46:39AM +0100, Claudio Jeker wrote:
> In bgpd most prefixes and addresses are stored as struct bgpd_addr. When
> it is printed it uses inet_ntop() which is not ideal since it does not
> handle IPv6 scoped_id. Instead convert to a struct sockaddr and use
>
> > + return log_sockaddr(addr2sa(addr, 0, ), len);
>
> Perhaps I haven't yet had enough coffee this year, but I'm unsure
> whether it is actually guaranteed that addr2sa() is called before the
> second len in this line is passed to log_sockaddr().
Answering my own question: C99 and
On Mon, Jan 04, 2021 at 01:46:43AM +0100, Klemens Nanni wrote:
> On Tue, Dec 29, 2020 at 11:18:26PM +0100, Claudio Jeker wrote:
> > Generally I would prefer to go for direct dispatch and not use netisr.
> > This removes a queue and a scheduling point and should help reduce the
> > latency in
Still ok by me.
> On 4 Jan 2021, at 03:46, Klemens Nanni wrote:
>
> On Tue, Dec 29, 2020 at 11:18:26PM +0100, Claudio Jeker wrote:
>> Generally I would prefer to go for direct dispatch and not use netisr.
>> This removes a queue and a scheduling point and should help reduce the
>> latency in
One month has passed, this is just a friendly ping...
Marcus
mcmer-open...@tor.at (Marcus MERIGHI), 2020.12.04 (Fri) 14:18 (CET):
> This patch wasn't commited and not discussed (publicly).
>
> It lets me use relayd as a front-end to the mattermost-server.
>
> @franz: Thank you!
>
>
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 there's some bs nexthop@interface syntax. my counter argument
> is that the
On Mon, Jan 04, 2021 at 12:23:35PM +0100, Claudio Jeker wrote:
> On Mon, Jan 04, 2021 at 12:09:46PM +0100, Theo Buehler wrote:
> > Pointed out by llvm scan-build. mrt_config is much larger (> 10x). As
> > far as I can tell, this isn't bad. It just overallocates and copies a
> > lot of zeroes
On 2021/01/04 09:57, Martijn van Duren wrote:
> Thanks for the feedback, it's always nice to get some background
> information on old standards. However, this change is specifically for
> SNMP, which does not use this part of BER/ASN1 as far as I could find.
> I'm not going to remove it from ber.c
On Mon, Jan 04, 2021 at 12:09:46PM +0100, Theo Buehler wrote:
> Pointed out by llvm scan-build. mrt_config is much larger (> 10x). As
> far as I can tell, this isn't bad. It just overallocates and copies a
> lot of zeroes thanks to the calloc() in parse.y.
>
> Perhaps it would be better to use
On Mon, Jan 04, 2021 at 10:46:39AM +0100, Claudio Jeker wrote:
> In bgpd most prefixes and addresses are stored as struct bgpd_addr. When
> it is printed it uses inet_ntop() which is not ideal since it does not
> handle IPv6 scoped_id. Instead convert to a struct sockaddr and use
> log_sockaddr()
Pointed out by llvm scan-build. mrt_config is much larger (> 10x). As
far as I can tell, this isn't bad. It just overallocates and copies a
lot of zeroes thanks to the calloc() in parse.y.
Perhaps it would be better to use sizeof(*xm) instead.
Regress passes with the Makefile diff at the end (is
This adjusts the roa_cmp() function to result in the same order on big and
little endian systems. This should help with regress tests where the order
matters.
I also change the prefixset_cmp function to use memcmp for both IPv4 and
IPv6 addresses.
OK?
--
:wq Claudio
Index: config.c
Hello,
>
> the stack should provide it on a 4 byte boundary, but it has uint64_t
> members. however, it is also __packed, so the compiler makes no
> assumptions about alignment.
>
> > Is there anything else that can be split out easily?
>
> let's put this in and then i'll have a look. ok by
In bgpd most prefixes and addresses are stored as struct bgpd_addr. When
it is printed it uses inet_ntop() which is not ideal since it does not
handle IPv6 scoped_id. Instead convert to a struct sockaddr and use
log_sockaddr() which in turn uses getnameinfo.
Ideally the same should be done for
By no means an official OK, but would love to see this in relayd!
Mischa
> On 3 Jan 2021, at 11:40, Denis Fondras wrote:
>
> Le Fri, Dec 11, 2020 at 10:53:56AM +, Olivier Cherrier a écrit :
>>
>> Hello tech@,
>>
>> Is there any interest for this feature to be commited?
>> I find it
On Mon, 2021-01-04 at 08:15 +0100, Rob Schmersel wrote:
> On Sun, 03 Jan 2021 21:59:57 +0100
> Martijn van Duren wrote:
>
> > ping
> >
> > On Mon, 2020-12-14 at 12:13 +0100, Martijn van Duren wrote:
> > > I can't find any reference in RFC2578 for a boolean type, nor have I
> > > seen it in the
Hello,
There are various program, especially the one written with GNU grep in
mind, that expects various flags that grep in base doesn't have. While
some of the flags (like --color) can be easily worked out (i.e. by
patching/customising these programs) one thing that it isn't easily
workable is
On Sun, 03 Jan 2021 21:59:57 +0100
Martijn van Duren wrote:
> ping
>
> On Mon, 2020-12-14 at 12:13 +0100, Martijn van Duren wrote:
> > I can't find any reference in RFC2578 for a boolean type, nor have I
> > seen it in the wild and the TruthValue diff I just committed give
> > me a strong
42 matches
Mail list logo
