Re: rpki-client: improve the distclean target
On Mon, Dec 09 2019, "Marco d'Itri" wrote: > Without this patch distclean may leave around some *.old files generated > by configure. The portable build system is not used or maintained within the OpenBSD source tree*. You'll be better off reporting this to Kristaps at https://github.com/kristapsdz/rpki-client/ * https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.sbin/rpki-client/Makefile?rev=1.14&content-type=text/plain > --- a/Makefile > +++ b/Makefile > @@ -73,7 +73,7 @@ clean: > rm -f $(BINS) $(ALLOBJS) rpki-client.install.8 > > distclean: clean > - rm -f config.h config.log Makefile.configure > + rm -f config.h config.log config.h.old config.log.old Makefile.configure > > $(ALLOBJS): extern.h config.h -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: ldomctl: status: print started and stopped domains alike
> Date: Mon, 9 Dec 2019 17:52:17 +0100 > From: Klemens Nanni > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > This fixes > > # ldomctl status > primary -running OpenBSD running > 0% > guest1stopped > guest2 ttyV1running OpenBoot Primary Boot Loader > 50% > > to look like > > # ./obj/ldomctl status > primary -running OpenBSD running > 0% > guest1 ttyV0stopped - > 0% > guest2 ttyV1running OpenBoot Primary Boot Loader > 50% > > Diff with -w for easier review. > OK? ok kettenis@ > Index: ldomctl.c > === > RCS file: /cvs/src/usr.sbin/ldomctl/ldomctl.c,v > retrieving revision 1.28 > diff -u -p -w -r1.28 ldomctl.c > --- ldomctl.c 30 Nov 2019 03:30:29 - 1.28 > +++ ldomctl.c 9 Dec 2019 16:47:10 - > @@ -610,9 +610,6 @@ guest_status(int argc, char **argv) > break; > } > > - if (state.state != GUEST_STATE_NORMAL) > - printf("%-16s %-16s\n", guest->name, state_str); > - else { > /* primary has no console */ > if (guest->gid != 0) { > snprintf(console_str, sizeof(console_str), > @@ -620,9 +617,8 @@ guest_status(int argc, char **argv) > } > > printf("%-16s %-8s %-16s %-32s %3.0f%%\n", guest->name, > - console_str, state_str, softstate.soft_state_str, > - utilisation); > - } > + console_str, state_str, state.state == GUEST_STATE_NORMAL ? > + softstate.soft_state_str : "-", utilisation); > } > } > > >
backgrounded ssh, strange terminal behaviour
Not new (it happens in at least 6.6) but I just noticed this. If I run some program via ssh command-line ("ssh localhost sleep 60" is good enough), then put it in the background (^Z bg), the terminal misses about a third of characters typed. typed:123456789012345678901234567890 accepted: 24680246891235780235790 Should this be treated as something more than "don't do that then"?
Re: backgrounded ssh, strange terminal behaviour
On Tue, Dec 10, 2019 at 01:56:29PM +, Stuart Henderson wrote: > Not new (it happens in at least 6.6) but I just noticed this. > > If I run some program via ssh command-line ("ssh localhost sleep 60" > is good enough), then put it in the background (^Z bg), the terminal > misses about a third of characters typed. > > typed:123456789012345678901234567890 > accepted: 24680246891235780235790 > > Should this be treated as something more than "don't do that then"? > AFAKS this only happens when using a mutiplexed (via ContorlMaster) connection. -Otto
ripd: memory leak and double free/use-after-free
Hi, While looking at the code of ripd: I think there are (also) 2 small memleaks in a debug/error path (IMSG_REQUEST_ADD and IMSG_RESPONSE_ADD). It breaks out before adding the struct rip_route as an entry by the add_entry function (which adds it and adds a reference count) in the log_debug block. clang-analyzer also pointed at a double-free and use of free'd data: the function kroute_insert frees kr and returns -1 when struct kroute is duplicate. Patch below (untested): diff --git a/usr.sbin/ripd/kroute.c b/usr.sbin/ripd/kroute.c index 6e7449e0909..71758a75e44 100644 --- a/usr.sbin/ripd/kroute.c +++ b/usr.sbin/ripd/kroute.c @@ -183,8 +183,7 @@ kr_change_fib(struct kroute_node *kr, struct kroute *kroute, int action) if (kroute_insert(kr) == -1) { log_debug("kr_update_fib: cannot insert %s", - inet_ntoa(kr->r.nexthop)); - free(kr); + inet_ntoa(kroute->nexthop)); } } else kr->r.nexthop.s_addr = kroute->nexthop.s_addr; diff --git a/usr.sbin/ripd/ripe.c b/usr.sbin/ripd/ripe.c index d83901e245f..1f6f9b6583f 100644 --- a/usr.sbin/ripd/ripe.c +++ b/usr.sbin/ripd/ripe.c @@ -351,6 +351,7 @@ ripe_dispatch_rde(int fd, short event, void *bula) NULL) { log_debug("unknown neighbor id %u", imsg.hdr.peerid); + free(rr); break; } add_entry(&nbr->rq_list, rr); @@ -396,6 +397,7 @@ ripe_dispatch_rde(int fd, short event, void *bula) if ((nbr = nbr_find_peerid(imsg.hdr.peerid)) == NULL) { log_debug("unknown neighbor id %u", imsg.hdr.peerid); + free(rr); break; } iface = nbr->iface; -- Kind regards, Hiltjo
Re: ospf6d: refactor kernel route message handling
On Mon, Dec 09, 2019 at 07:31:11PM +0100, Denis Fondras wrote: > Give some love to ospf6d. > > The goal is to have ospf6d looks like ospfd, this could be useful to have > changes made in one daemon from one go inside the other. > > I will do it step by step until I get to the point where "ospf6ctl reload" > works. I like this a lot! > First step is to refactor kernel route message handling, no functionnal > change. I tested your diff with the following configuration: -- router-id 192.168.250.7 fib-priority 38 redistribute default redistribute rtlabel toOSPF depend on carp0 area 0 { interface vether0 { metric 55 depend on carp0 } interface iwm0 { passive } } -- Unfortunately redistribute does not work anymore. Remi
Re: ripd: memory leak and double free/use-after-free
On Tue, Dec 10, 2019 at 07:05:27PM +0100, Hiltjo Posthuma wrote: > Hi, > > While looking at the code of ripd: > > I think there are (also) 2 small memleaks in a debug/error path > (IMSG_REQUEST_ADD and IMSG_RESPONSE_ADD). It breaks out before adding the > struct rip_route as an entry by the add_entry function (which adds it and adds > a reference count) in the log_debug block. > > clang-analyzer also pointed at a double-free and use of free'd data: the > function kroute_insert frees kr and returns -1 when struct kroute is > duplicate. > > Patch below (untested): > OK remi@ > > diff --git a/usr.sbin/ripd/kroute.c b/usr.sbin/ripd/kroute.c > index 6e7449e0909..71758a75e44 100644 > --- a/usr.sbin/ripd/kroute.c > +++ b/usr.sbin/ripd/kroute.c > @@ -183,8 +183,7 @@ kr_change_fib(struct kroute_node *kr, struct kroute > *kroute, int action) > > if (kroute_insert(kr) == -1) { > log_debug("kr_update_fib: cannot insert %s", > - inet_ntoa(kr->r.nexthop)); > - free(kr); > + inet_ntoa(kroute->nexthop)); > } > } else > kr->r.nexthop.s_addr = kroute->nexthop.s_addr; > diff --git a/usr.sbin/ripd/ripe.c b/usr.sbin/ripd/ripe.c > index d83901e245f..1f6f9b6583f 100644 > --- a/usr.sbin/ripd/ripe.c > +++ b/usr.sbin/ripd/ripe.c > @@ -351,6 +351,7 @@ ripe_dispatch_rde(int fd, short event, void *bula) > NULL) { > log_debug("unknown neighbor id %u", > imsg.hdr.peerid); > + free(rr); > break; > } > add_entry(&nbr->rq_list, rr); > @@ -396,6 +397,7 @@ ripe_dispatch_rde(int fd, short event, void *bula) > if ((nbr = nbr_find_peerid(imsg.hdr.peerid)) == NULL) { > log_debug("unknown neighbor id %u", > imsg.hdr.peerid); > + free(rr); > break; > } > iface = nbr->iface; > > -- > Kind regards, > Hiltjo >
Re: backgrounded ssh, strange terminal behaviour
On Wed, 11 Dec 2019 at 01:10, Stuart Henderson wrote: > Not new (it happens in at least 6.6) but I just noticed this. > > If I run some program via ssh command-line ("ssh localhost sleep 60" > is good enough), then put it in the background (^Z bg), the terminal > misses about a third of characters typed. > > typed:123456789012345678901234567890 > accepted: 24680246891235780235790 > > Should this be treated as something more than "don't do that then"? > Sounds like a bug. I can reproduce with controlmaster as described by otto but not otherwise. Can you confirm that you are also using controlmaster or are you seeing this in a single process? -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.