show advertised MTU in slaacctl

2018-07-21 Thread Björn Ketelaars
Now that rad(8) is able to advertise a MTU I think it would be nice to have slaacctl(8) show this advertisement. The patch below touches both sbin/slaacd and usr.sbin/slaacctl. The addition to sbin/slaacd/engine.c makes sure that MTU RA messages are parsed, and that the result is made available. BT

Re: bgpd minor cleanup

2018-07-21 Thread Theo Buehler
On Sat, Jul 21, 2018 at 10:46:00PM +0200, Claudio Jeker wrote: > Fix a printf and change the way data is increased so that at the end of > the function it is not overflowing. In the VPN4 case data is increased by > sizeof(u_int64_t) but later on the data is increased by the full length > which move

Re: dd(1): don't cast malloc(3) size to u_int

2018-07-21 Thread Tobias Stoeckmann
On Fri, Jul 20, 2018 at 06:51:33PM -0500, Scott Cheloha wrote: > tobias@ spotted this one a few months ago when reviewing a different > diff of mine. Yeah, I remember that one. Brings up memories of another diff of that time as well. > ... ok as-is? Yeah, okay by me as well. Tobias

Re: full 'bgpctl show mrt' support

2018-07-21 Thread Sebastian Benoit
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.07.21 22:31:24 +0200: > This adds the missing parser for messages aka updates. > It is reusing some of bgpd's functions which I already moved to util.c for > that and reimplements a few other bits. It also extends the current > attribute printing code

bgpd minor cleanup

2018-07-21 Thread Claudio Jeker
Fix a printf and change the way data is increased so that at the end of the function it is not overflowing. In the VPN4 case data is increased by sizeof(u_int64_t) but later on the data is increased by the full length which moves the pointer beyond the end. Now this is not really a problem since da

Re: bgpd move nexthop into filterstate

2018-07-21 Thread Sebastian Benoit
Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.07.18 21:59:44 +0200: > This is the next small bit of rde rebuilding. > > Move nexthop into struct filterstate (including nexthop flags) and use > them whereever possible. In some places (path_update, softreconfig_out > handler) the nexthop state are

full 'bgpctl show mrt' support

2018-07-21 Thread Claudio Jeker
This adds the missing parser for messages aka updates. It is reusing some of bgpd's functions which I already moved to util.c for that and reimplements a few other bits. It also extends the current attribute printing code to support all attributes even those that are not seen in the ususal show rib

add pledge(2) to quot(8)

2018-07-21 Thread Ricardo Mestre
Hi, This one seems to only need rpath to be able to traverse the filesystem and getpw to figure out who owns what. OK? Index: quot.c === RCS file: /cvs/src/usr.sbin/quot/quot.c,v retrieving revision 1.30 diff -u -p -u -r1.30 quot.c

Re: dd(1): don't cast malloc(3) size to u_int

2018-07-21 Thread Todd C. Miller
On Fri, 20 Jul 2018 18:51:33 -0500, Scott Cheloha wrote: > The block sizes sum to 1 when cast and malloc(3) breaks us off a byte. > read(2) then sees that it would be writing outside the valid address > space and fails. OK millert@ for the fix. > Maybe pedantic, but should we also be checking fo

Re: ffs_write: include vnode type in panic message

2018-07-21 Thread Mark Kettenis
> Date: Sat, 21 Jul 2018 10:08:58 +0200 > From: Anton Lindqvist > > Comments? OK? ok kettenis@ > Index: ffs_vnops.c > === > RCS file: /cvs/src/sys/ufs/ffs/ffs_vnops.c,v > retrieving revision 1.91 > diff -u -p -r1.91 ffs_vnops.c > -

ffs_write: include vnode type in panic message

2018-07-21 Thread Anton Lindqvist
Hi, A minor correction, include the vnode type just like ffs_read() does when it encounters an unsupported type and panics. Comments? OK? Index: ffs_vnops.c === RCS file: /cvs/src/sys/ufs/ffs/ffs_vnops.c,v retrieving revision 1.91 di

Re: dd(1): don't cast malloc(3) size to u_int

2018-07-21 Thread Theo de Raadt
Scott Cheloha wrote: > Fix attached. That looks good, but you bring up good points: > Maybe pedantic, but should we also be checking for addition overflow? OpenBSD > is fine -- those additions will not overflow, as we check prior to this point > that all block sizes are <= SSIZE_MAX. But the