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.
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(>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
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(>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 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
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: 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);
> }
> }
>
>
>
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=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
