fix compilation failure when sr_debug is defined.
Hello,
following small patch fixes compilation failure when SR_DEBUG is defined in
softraidvar.h which results in definition of DPRINTF which results in error
about already defined macro in machdep.c
Index: arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.248
diff -u -p -u -r1.248 machdep.c
--- arch/amd64/amd64/machdep.c 12 Jul 2018 14:11:11 - 1.248
+++ arch/amd64/amd64/machdep.c 18 Jul 2018 22:52:40 -
@@ -142,9 +142,11 @@ extern int db_console;
#endif
/* #define MACHDEP_DEBUG */
-
#ifdef MACHDEP_DEBUG
-#define DPRINTF(x...) do { printf(x); } while(0)
+#ifdef DPRINTF
+#undef DPRINTF
+#endif
+##define DPRINTF(x...) do { printf(x); } while(0)
#else
#define DPRINTF(x...)
#endif /* MACHDEP_DEBUG */
Re: call for testing: rad(8) - a rtadvd(8) replacement
On 7/18/2018 2:54 AM, Florian Obser wrote:
> During g2k18 I commited rad(8).
>
> [snip]
I had a chance to do a couple simple tests with rad(8) in my test
environment.
# cat rad.conf
interface em0 {
prefix fdcf:b715:2f4d:100::/64
prefix 2001:DB8:2f4d:100::/64
dns {
resolver fdcf:b715:2f4d:1::3
}
}
I used a FreeBSD client on em0.
I verified that each prefix in the rad.conf was assigned to the client,
and the DNS resolver made it into /etc/resolv.conf on the client.
So far, it looks good. And I do like the new syntax! :)
Thanks.
bgpd move nexthop into filterstate
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 folded back into the rde_aspath.
This also fixes a possible crash when it comes to nexthop filtering.
--
:wq Claudio
? obj
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.394
diff -u -p -r1.394 rde.c
--- rde.c 16 Jul 2018 09:09:20 - 1.394
+++ rde.c 18 Jul 2018 19:52:26 -
@@ -998,7 +998,7 @@ rde_update_dispatch(struct imsg *imsg)
imsg->hdr.len - IMSG_HEADER_SIZE - 4 - withdrawn_len - attrpath_len;
bzero(, sizeof(mpa));
- rde_filterstate_prep(, NULL);
+ rde_filterstate_prep(, NULL, NULL);
if (attrpath_len != 0) { /* 0 = no NLRI information in this message */
/* parse path attributes */
while (len > 0) {
@@ -1221,14 +1221,9 @@ rde_update_dispatch(struct imsg *imsg)
goto done;
}
- /*
-* this works because asp is not linked.
-* But first unlock the previously locked nexthop.
-*/
- if (state.aspath.nexthop) {
- (void)nexthop_put(state.aspath.nexthop);
- state.aspath.nexthop = NULL;
- }
+ /* unlock the previously locked nexthop, it is no longer used */
+ (void)nexthop_put(state.nexthop);
+ state.nexthop = NULL;
if ((pos = rde_get_mp_nexthop(mpp, mplen, aid, )) == -1) {
log_peer_warnx(>conf, "bad nlri prefix");
rde_update_err(peer, ERR_UPDATE, ERR_UPD_OPTATTR,
@@ -1318,13 +1313,13 @@ rde_update_update(struct rde_peer *peer,
for (i = RIB_LOC_START; i < rib_size; i++) {
if (*ribs[i].name == '\0')
break;
- rde_filterstate_prep(, >aspath);
+ rde_filterstate_prep(, >aspath, in->nexthop);
/* input filter */
action = rde_filter(ribs[i].in_rules, peer, p, );
if (action == ACTION_ALLOW) {
rde_update_log("update", i, peer,
- >exit_nexthop, prefix,
+ >exit_nexthop, prefix,
prefixlen);
path_update([i].rib, peer, , prefix,
prefixlen, 0);
@@ -1499,7 +1494,8 @@ bad_flags:
op, len);
return (-1);
}
- a->nexthop = nexthop_get();
+ nexthop_put(state->nexthop);/* just to be sure */
+ state->nexthop = nexthop_get();
break;
case ATTR_MED:
if (attr_len != 4)
@@ -1832,7 +1828,8 @@ rde_get_mp_nexthop(u_char *data, u_int16
return (-1);
}
- state->aspath.nexthop = nexthop_get();
+ nexthop_put(state->nexthop);/* just to be sure */
+ state->nexthop = nexthop_get();
/* ignore reserved (old SNPA) field as per RFC4760 */
totlen += nhlen + 1;
@@ -2251,7 +2248,7 @@ rde_dump_filterout(struct rde_peer *peer
if (up_test_update(peer, p) != 1)
return;
- rde_filterstate_prep(, prefix_aspath(p));
+ rde_filterstate_prep(, prefix_aspath(p), prefix_nexthop(p));
a = rde_filter(out_rules, peer, p, );
if (a == ACTION_ALLOW)
@@ -3006,7 +3003,7 @@ rde_softreconfig_in(struct rib_entry *re
asp = prefix_aspath(p);
peer = asp->peer;
- rde_filterstate_prep(, asp);
+ rde_filterstate_prep(, asp, prefix_nexthop(p));
action = rde_filter(rib->in_rules, peer, p, );
if (action == ACTION_ALLOW) {
@@ -3044,8 +3041,8 @@ rde_softreconfig_out(struct rib_entry *r
if (up_test_update(peer, p) != 1)
return;
- rde_filterstate_prep(, prefix_aspath(p));
- rde_filterstate_prep(, prefix_aspath(p));
+ rde_filterstate_prep(, prefix_aspath(p), prefix_nexthop(p));
+ rde_filterstate_prep(, prefix_aspath(p), prefix_nexthop(p));
oa = rde_filter(out_rules_tmp, peer, p, );
na = rde_filter(out_rules, peer, p, );
@@ -3054,14 +3051,23 @@ rde_softreconfig_out(struct rib_entry *r
/* nothing todo */
if (oa == ACTION_DENY && na == ACTION_ALLOW) {
/* send update */
- up_generate(peer, , , pt->prefixlen);
+ up_generate(peer, , , pt->prefixlen);
} else if (oa == ACTION_ALLOW && na == ACTION_DENY) {
/* send withdraw */
up_generate(peer, NULL, , pt->prefixlen);
} else if (oa == ACTION_ALLOW && na
Re: call for testing: rad(8) - a rtadvd(8) replacement
On Wed, Jul 18, 2018 at 08:54:51AM +0200, Florian Obser wrote: | During g2k18 I commited rad(8). | | The latest amd64 and i386 snapshots should contain it with enough | features to replace rtadvd(8). If you are using rtadvd(8) I'd | appreciate if you could switch to rad(8) and report back if any | features are missing. | | The plan is to unhook rtadvd(8) from the build sooner rather than | later and to ship 6.4 with rad(8) only. | | If you are running rtadvd(8) with out any configuration and only have | rtadvd_flags=em1 the /etc/rad.conf file will be | | ---8<--- | interface em0 | ---8<--- | | Once that is inplace disable rtadvd and enable rad: | | # rcctl stop rtadvd | # rcctl disable rtadvd | # rcctl enable rad | # rcctl start rad | | see man rad.conf for documentation on the config file format. Good | news: it's no longer termcap based! Works well. Love the configuration format, although I never did have any special or interesting config for rtadvd: [root@tuna] # grep -e rad -e rtadvd /etc/rc.conf.local /var/backups/etc_rc.conf.local.current /etc/rc.conf.local:rad_flags= /var/backups/etc_rc.conf.local.current:rtadvd_flags="em1 em2 em3" [root@tuna] # cat /etc/rad.conf interface em1 interface em2 interface em3 Seems to work as advertised just fine. I do see the logging bits Sebastien already mentioned, but that will disappear with the next snapshot upgrade as I see you've already committed some fixes. Thanks for working on this Florian .. it's pretty rad! Cheers, Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: join(1): use getline instead of fgetln
On Wed, 18 Jul 2018 19:07:21 +0200, Ingo Schwarze wrote: > I think it's more elegant to just break; when getline() returns -1, > you already have the free() at the end: > > if ((len = getline(, , F->fp)) == -1) > break; > > But you get to choose the colour of the bikeshed, OK either way. Good idea. I made that change and committed. - todd
Re: join(1): use getline instead of fgetln
Hi Todd,
Todd C. Miller wrote on Tue, Jul 17, 2018 at 01:38:14PM -0600:
> On Tue, 17 Jul 2018 13:21:31 -0600, "Todd C. Miller" wrote:
>> It probably makes more sense to do the newline check (and decrement
>> len if one is present) before newsize is computed. Then you would
>> need to unconditionally NUL-terminate lp->line.
> Perhaps something like this.
OK schwarze@
I think it's more elegant to just break; when getline() returns -1,
you already have the free() at the end:
if ((len = getline(, , F->fp)) == -1)
break;
But you get to choose the colour of the bikeshed, OK either way.
Yours,
Ingo
> Index: usr.bin/join/join.c
> ===
> RCS file: /cvs/src/usr.bin/join/join.c,v
> retrieving revision 1.27
> diff -u -p -u -r1.27 join.c
> --- usr.bin/join/join.c 9 Oct 2015 01:37:07 - 1.27
> +++ usr.bin/join/join.c 17 Jul 2018 19:33:38 -
> @@ -298,9 +298,10 @@ void
> slurpit(INPUT *F)
> {
> LINE *lp, *lastlp, tmp;
> - size_t len;
> + ssize_t len;
> + size_t linesize;
> u_long cnt;
> - char *bp, *fieldp;
> + char *bp, *fieldp, *line;
> long fpos;
> /*
>* Read all of the lines from an input file that have the same
> @@ -308,6 +309,8 @@ slurpit(INPUT *F)
>*/
>
> F->setcnt = 0;
> + line = NULL;
> + linesize = 0;
> for (lastlp = NULL; ; ++F->setcnt, lastlp = lp) {
> /*
>* If we're out of space to hold line structures, allocate
> @@ -343,13 +346,19 @@ slurpit(INPUT *F)
> F->pushbool = 0;
> continue;
> }
> - if ((bp = fgetln(F->fp, )) == NULL)
> + if ((len = getline(, , F->fp)) == -1) {
> + free(line);
> return;
> + }
> /*
>* we depend on knowing on what field we are, one safe way is
>* the file position.
> */
> fpos = ftell(F->fp) - len;
> +
> + /* Remove trailing newline, if it exists, and copy line. */
> + if (line[len - 1] == '\n')
> + len--;
> if (lp->linealloc <= len + 1) {
> char *p;
> u_long newsize = lp->linealloc +
> @@ -360,17 +369,13 @@ slurpit(INPUT *F)
> lp->linealloc = newsize;
> }
> F->setusedc++;
> - memmove(lp->line, bp, len);
> + memcpy(lp->line, line, len);
> + lp->line[len] = '\0';
> lp->fpos = fpos;
> - /* Replace trailing newline, if it exists. */
> - if (bp[len - 1] == '\n')
> - lp->line[len - 1] = '\0';
> - else
> - lp->line[len] = '\0';
> - bp = lp->line;
>
> /* Split the line into fields, allocate space as necessary. */
> lp->fieldcnt = 0;
> + bp = lp->line;
> while ((fieldp = strsep(, tabchar)) != NULL) {
> if (spans && *fieldp == '\0')
> continue;
> @@ -393,6 +398,7 @@ slurpit(INPUT *F)
> break;
> }
> }
> + free(line);
> }
>
> int
Re: document tls_peer_ocsp_result(3)
On Wed, Jul 18, 2018 at 03:49:56PM +0200, Theo Buehler wrote: > The manual currently contains mentions of tls_peer_ocsp_result_msg(3), > which doesn't exist. > > I renamed these to tls_peer_ocsp_result(3) and made a stab at > documenting lines 89-96 of tls_ocsp.c, the only place which sets the > string `result_msg' that is later returned by tls_peer_ocsp_result(3). > I refrained from giving detailed references to the relevant RFCs, > as these are already given a few lines above. > reads fine to me. jmc > Index: lib/libtls/man/tls_ocsp_process_response.3 > === > RCS file: /var/cvs/src/lib/libtls/man/tls_ocsp_process_response.3,v > retrieving revision 1.4 > diff -u -p -r1.4 tls_ocsp_process_response.3 > --- lib/libtls/man/tls_ocsp_process_response.329 Jan 2017 18:00:21 > - 1.4 > +++ lib/libtls/man/tls_ocsp_process_response.318 Jul 2018 13:40:55 > - > @@ -23,7 +23,7 @@ > .Nm tls_peer_ocsp_crl_reason , > .Nm tls_peer_ocsp_next_update , > .Nm tls_peer_ocsp_response_status , > -.Nm tls_peer_ocsp_result_msg , > +.Nm tls_peer_ocsp_result , > .Nm tls_peer_ocsp_revocation_time , > .Nm tls_peer_ocsp_this_update , > .Nm tls_peer_ocsp_url > @@ -45,7 +45,7 @@ > .Ft int > .Fn tls_peer_ocsp_response_status "struct tls *ctx" > .Ft const char * > -.Fn tls_peer_ocsp_result_msg "struct tls *ctx" > +.Fn tls_peer_ocsp_result "struct tls *ctx" > .Ft time_t > .Fn tls_peer_ocsp_revocation_time "struct tls *ctx" > .Ft time_t > @@ -86,7 +86,13 @@ returns the OCSP next update time. > .Fn tls_peer_ocsp_response_status > returns the OCSP response status as per RFC 6960 section 2.3. > .Pp > -.\" XXX Fn tls_peer_ocsp_result_msg does what? > +.Fn tls_peer_ocsp_result > +returns a string indicating the OCSP status. > +If the OCSP response was successful and the OCSP certificate was not > +revoked, the string indicates the OCSP certificate status. > +Otherwise, the string indicates > +the OCSP certificate revocation reason or the OCSP error. > +.Pp > .Fn tls_peer_ocsp_revocation_time > returns the OCSP revocation time. > .Pp > @@ -139,7 +145,7 @@ and > .Fn tls_peer_ocsp_this_update > return a time in epoch-seconds on success or -1 on error. > .Pp > -.Fn tls_peer_ocsp_result_msg > +.Fn tls_peer_ocsp_result > and > .Fn tls_peer_ocsp_url > return >
unveil: return EPERM when locked
Hi, The unveil man page stands that unveil will return EPERM when locked: EPERM An attempt to add permission to flags was made, or path was not accessible, or unveil was called after it was locked The lock is sets when unveil(NULL, NULL) is called. The syscall will set `p->p_p->ps_uvdone=1`, and further call to unveil(2) will be refused. Currently, the syscall returns EINVAL in such case. So make it return what the documentation said, as it is the more obvious. While here, few style correction in return statements. Thanks. -- Sebastien Marie Index: kern/vfs_syscalls.c === RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.294 diff -u -p -r1.294 vfs_syscalls.c --- kern/vfs_syscalls.c 13 Jul 2018 09:36:00 - 1.294 +++ kern/vfs_syscalls.c 18 Jul 2018 13:47:12 - @@ -897,21 +897,21 @@ sys_unveil(struct proc *p, void *v, regi } if (p->p_p->ps_uvdone != 0) - return EINVAL; + return (EPERM); error = copyinstr(SCARG(uap, flags), cflags, sizeof(cflags), NULL); if (error) - return(error); + return (error); error = copyinstr(SCARG(uap, path), pathname, sizeof(pathname), ); if (error) - return(error); + return (error); #ifdef KTRACE if (KTRPOINT(p, KTR_STRUCT)) ktrstruct(p, "unveil", cflags, strlen(cflags)); #endif if (pathlen < 2) - return EINVAL; + return (EINVAL); /* XXX unveil is disabled but returns sucess for now */ return 0; @@ -929,7 +929,7 @@ sys_unveil(struct proc *p, void *v, regi /* * XXX Any access to the file or directory will allow us to -* pledge path it +* unveil it */ if ((nd.ni_vp && (VOP_ACCESS(nd.ni_vp, VREAD, p->p_ucred, p) == 0 ||
document tls_peer_ocsp_result(3)
The manual currently contains mentions of tls_peer_ocsp_result_msg(3), which doesn't exist. I renamed these to tls_peer_ocsp_result(3) and made a stab at documenting lines 89-96 of tls_ocsp.c, the only place which sets the string `result_msg' that is later returned by tls_peer_ocsp_result(3). I refrained from giving detailed references to the relevant RFCs, as these are already given a few lines above. Index: lib/libtls/man/tls_ocsp_process_response.3 === RCS file: /var/cvs/src/lib/libtls/man/tls_ocsp_process_response.3,v retrieving revision 1.4 diff -u -p -r1.4 tls_ocsp_process_response.3 --- lib/libtls/man/tls_ocsp_process_response.3 29 Jan 2017 18:00:21 - 1.4 +++ lib/libtls/man/tls_ocsp_process_response.3 18 Jul 2018 13:40:55 - @@ -23,7 +23,7 @@ .Nm tls_peer_ocsp_crl_reason , .Nm tls_peer_ocsp_next_update , .Nm tls_peer_ocsp_response_status , -.Nm tls_peer_ocsp_result_msg , +.Nm tls_peer_ocsp_result , .Nm tls_peer_ocsp_revocation_time , .Nm tls_peer_ocsp_this_update , .Nm tls_peer_ocsp_url @@ -45,7 +45,7 @@ .Ft int .Fn tls_peer_ocsp_response_status "struct tls *ctx" .Ft const char * -.Fn tls_peer_ocsp_result_msg "struct tls *ctx" +.Fn tls_peer_ocsp_result "struct tls *ctx" .Ft time_t .Fn tls_peer_ocsp_revocation_time "struct tls *ctx" .Ft time_t @@ -86,7 +86,13 @@ returns the OCSP next update time. .Fn tls_peer_ocsp_response_status returns the OCSP response status as per RFC 6960 section 2.3. .Pp -.\" XXX Fn tls_peer_ocsp_result_msg does what? +.Fn tls_peer_ocsp_result +returns a string indicating the OCSP status. +If the OCSP response was successful and the OCSP certificate was not +revoked, the string indicates the OCSP certificate status. +Otherwise, the string indicates +the OCSP certificate revocation reason or the OCSP error. +.Pp .Fn tls_peer_ocsp_revocation_time returns the OCSP revocation time. .Pp @@ -139,7 +145,7 @@ and .Fn tls_peer_ocsp_this_update return a time in epoch-seconds on success or -1 on error. .Pp -.Fn tls_peer_ocsp_result_msg +.Fn tls_peer_ocsp_result and .Fn tls_peer_ocsp_url return
Re: unveil(2) for spamlogd(8)
On Wed, Jul 18, 2018 at 12:59:12PM +0100, Ricardo Mestre wrote:
> Hi,
>
> Are there any brave souls out there with unveil(2) enabled already?
>
> If yes please test this diff for spamlogd(8) which seems to only need rw
> access to the file PATH_SPAMD_DB and nothing else.
>
> Not asking for OKs yet, but if the code pattern is correct can I start looking
> at other programs?
mostly about the code pattern.
first, I didn't know all arcane of unveil, so I could be wrong at some
point. hearing from beck@ would help too :)
- pledge and unveil
I think, if possible, you should configure unveil(2) before calling
pledge(2). This way, you don't have to let the "unveil" promise
allowed.
- locking unveil
You should call unveil(NULL, NULL) when all your unveil(2) stuff is
done: this way, you would lock further unveil addition. But with
pledge(2) call after, any unveil(2) call would abort the program
anyway (with no "unveil" promise).
>
> Index: spamlogd.c
> ===
> RCS file: /cvs/src/libexec/spamlogd/spamlogd.c,v
> retrieving revision 1.27
> diff -u -p -u -r1.27 spamlogd.c
> --- spamlogd.c16 Mar 2016 14:47:04 - 1.27
> +++ spamlogd.c18 Jul 2018 11:46:59 -
> @@ -376,12 +376,15 @@ main(int argc, char **argv)
> }
>
> if (syncsend) {
> - if (pledge("stdio rpath wpath inet flock", NULL) == -1)
> + if (pledge("stdio rpath wpath inet flock unveil", NULL) == -1)
> err(1, "pledge");
> } else {
> - if (pledge("stdio rpath wpath flock", NULL) == -1)
> + if (pledge("stdio rpath wpath flock unveil", NULL) == -1)
> err(1, "pledge");
> }
> +
> + if (unveil(PATH_SPAMD_DB, "rw") == -1)
> + err(1, "unveil");
>
> pcap_loop(hpcap, -1, phandler, NULL);
>
>
Thanks.
--
Sebastien Marie
Re: unveil(2) for spamlogd(8)
Hi Robert, Good catch! I just tested it and it still works, trying to open another file after the pledge even with rpath/wpath promises the file won't be seen. So in this case the unveil promise can be removed since it's no longer needed. Thank you! On 14:58 Wed 18 Jul , Robert Nagy wrote: > Hi > > I think you should call unveil before pledge, so that you don't > need to pledge unveil. > This will prevent futher calls to unveil. >
softraid offline
Hi All, Rebooting after a dbb prompt, which I was unfortunately unable to capture, the softraid configuration seemed to have been damaged. root@j6:~ # dmesg | grep softraid softraid0 at root scsibus5 at softraid0: 256 targets softraid0: trying to bring up sd8 degraded softraid0: sd8 was not shutdown properly softraid0: sd8 is offline, will not be brought online root@j6:~ # bioctl -d sd8 bioctl: Can't locate sd8 device via /dev/bio root@j6:~ # bioctl -c 5 -l /dev/sd3a,/dev/sd4a,/dev/sd5a,/dev/sd6a softraid0 softraid0: trying to bring up sd8 degraded softraid0: sd8 was not shutdown properly softraid0: sd8 is offline, will not be brought online root@j6:~ # bioctl -R /dev/sd3a sd8 bioctl: Can't locate sd8 device via /dev/bio All the /dev/sd8* are there. So it looks like I am stuck with schroedingers softraid. It's both there and not there. Anybody some pointers on how to get it back or to remove it completely? Thanx! Mischa
Re: unveil(2) for spamlogd(8)
Hi
I think you should call unveil before pledge, so that you don't
need to pledge unveil.
This will prevent futher calls to unveil.
On 18/07/18 12:59 +0100, Ricardo Mestre wrote:
> Hi,
>
> Are there any brave souls out there with unveil(2) enabled already?
>
> If yes please test this diff for spamlogd(8) which seems to only need rw
> access to the file PATH_SPAMD_DB and nothing else.
>
> Not asking for OKs yet, but if the code pattern is correct can I start looking
> at other programs?
>
> Sorry for my earlier email, my clock was WAY off.
>
> Index: spamlogd.c
> ===
> RCS file: /cvs/src/libexec/spamlogd/spamlogd.c,v
> retrieving revision 1.27
> diff -u -p -u -r1.27 spamlogd.c
> --- spamlogd.c16 Mar 2016 14:47:04 - 1.27
> +++ spamlogd.c18 Jul 2018 11:46:59 -
> @@ -376,12 +376,15 @@ main(int argc, char **argv)
> }
>
> if (syncsend) {
> - if (pledge("stdio rpath wpath inet flock", NULL) == -1)
> + if (pledge("stdio rpath wpath inet flock unveil", NULL) == -1)
> err(1, "pledge");
> } else {
> - if (pledge("stdio rpath wpath flock", NULL) == -1)
> + if (pledge("stdio rpath wpath flock unveil", NULL) == -1)
> err(1, "pledge");
> }
> +
> + if (unveil(PATH_SPAMD_DB, "rw") == -1)
> + err(1, "unveil");
>
> pcap_loop(hpcap, -1, phandler, NULL);
>
>
unveil(2) for spamlogd(8)
Hi,
Are there any brave souls out there with unveil(2) enabled already?
If yes please test this diff for spamlogd(8) which seems to only need rw
access to the file PATH_SPAMD_DB and nothing else.
Not asking for OKs yet, but if the code pattern is correct can I start looking
at other programs?
Sorry for my earlier email, my clock was WAY off.
Index: spamlogd.c
===
RCS file: /cvs/src/libexec/spamlogd/spamlogd.c,v
retrieving revision 1.27
diff -u -p -u -r1.27 spamlogd.c
--- spamlogd.c 16 Mar 2016 14:47:04 - 1.27
+++ spamlogd.c 18 Jul 2018 11:46:59 -
@@ -376,12 +376,15 @@ main(int argc, char **argv)
}
if (syncsend) {
- if (pledge("stdio rpath wpath inet flock", NULL) == -1)
+ if (pledge("stdio rpath wpath inet flock unveil", NULL) == -1)
err(1, "pledge");
} else {
- if (pledge("stdio rpath wpath flock", NULL) == -1)
+ if (pledge("stdio rpath wpath flock unveil", NULL) == -1)
err(1, "pledge");
}
+
+ if (unveil(PATH_SPAMD_DB, "rw") == -1)
+ err(1, "unveil");
pcap_loop(hpcap, -1, phandler, NULL);
slaacd(8): handle duplicate addresses
Handle duplicate address detection failures.
We get notified when duplication is detected on the route socket. For
privacy addresses simply generate a new random address. If we have
soii enabled increase the dad counter on the prefix and generate a new
address. For eui64 addresses nothing can be done.
OK?
diff --git engine.c engine.c
index 961e1b115b6..326529caefc 100644
--- engine.c
+++ engine.c
@@ -106,6 +106,7 @@ enum proposal_state {
PROPOSAL_CONFIGURED,
PROPOSAL_NEARLY_EXPIRED,
PROPOSAL_WITHDRAWN,
+ PROPOSAL_DUPLICATED,
};
const char* proposal_state_name[] = {
@@ -114,6 +115,7 @@ const char* proposal_state_name[] = {
"CONFIGURED",
"NEARLY_EXPIRED",
"WITHDRAWN",
+ "DUPLICATED",
};
const char* rpref_name[] = {
@@ -130,6 +132,7 @@ struct radv_prefix {
int autonomous;
uint32_tvltime;
uint32_tpltime;
+ int dad_counter;
};
struct radv_rdns {
@@ -261,11 +264,10 @@ struct dfr_proposal *find_dfr_proposal_by_id(struct
slaacd_iface *,
int64_t);
struct dfr_proposal*find_dfr_proposal_by_gw(struct slaacd_iface *,
struct sockaddr_in6 *);
-voidfind_prefix(struct slaacd_iface *, struct
-address_proposal *, struct radv **, struct
-radv_prefix **);
+struct radv_prefix *find_prefix(struct radv *, struct radv_prefix *);
int engine_imsg_compose_main(int, pid_t, void *, uint16_t);
uint32_treal_lifetime(struct timespec *, uint32_t);
+voidmerge_dad_couters(struct radv *, struct radv *);
struct imsgev *iev_frontend;
struct imsgev *iev_main;
@@ -392,6 +394,8 @@ engine_dispatch_frontend(int fd, short event, void *bula)
struct dfr_proposal *dfr_proposal = NULL;
struct imsg_del_addr del_addr;
struct imsg_del_routedel_route;
+ struct imsg_dup_addr dup_addr;
+ struct timeval tv;
ssize_t n;
int shut = 0;
#ifndefSMALL
@@ -546,6 +550,31 @@ engine_dispatch_frontend(int fd, short event, void *bula)
start_probe(iface);
}
break;
+ case IMSG_DUP_ADDRESS:
+ if (imsg.hdr.len != IMSG_HEADER_SIZE +
+ sizeof(dup_addr))
+ fatal("%s: IMSG_DUP_ADDRESS wrong length: %d",
+ __func__, imsg.hdr.len);
+ memcpy(_addr, imsg.data, sizeof(dup_addr));
+ iface = get_slaacd_iface_by_id(dup_addr.if_index);
+ if (iface == NULL) {
+ log_debug("IMSG_DUP_ADDRESS: unknown interface"
+ ", ignoring");
+ break;
+ }
+
+ addr_proposal = find_address_proposal_by_addr(iface,
+ _addr.addr);
+
+ if (addr_proposal) {
+ /* XXX should we inform netcfgd? */
+ addr_proposal->state = PROPOSAL_DUPLICATED;
+ tv.tv_sec = 0;
+ tv.tv_usec = arc4random_uniform(100);
+ addr_proposal->next_timeout = 0;
+ evtimer_add(_proposal->timer, );
+ }
+ break;
default:
log_debug("%s: unexpected imsg %d", __func__,
imsg.hdr.type);
@@ -1261,7 +1290,6 @@ gen_addr(struct slaacd_iface *iface, struct radv_prefix
*prefix, struct
{
SHA2_CTX ctx;
struct in6_addr iid;
- int dad_counter = 0; /* XXX not used */
int i;
u_int8_t digest[SHA512_DIGEST_LENGTH];
@@ -1293,7 +1321,8 @@ gen_addr(struct slaacd_iface *iface, struct radv_prefix
*prefix, struct
sizeof(prefix->prefix));
SHA512Update(, >hw_address,
sizeof(iface->hw_address));
- SHA512Update(, _counter, sizeof(dad_counter));
+ SHA512Update(, >dad_counter,
+ sizeof(prefix->dad_counter));
SHA512Update(, addr_proposal->soiikey,
sizeof(addr_proposal->soiikey));
SHA512Final(digest, );
@@ -1601,13 +1630,16 @@ void update_iface_ra(struct slaacd_iface *iface, struct
radv *ra)
struct address_proposal *addr_proposal;
struct dfr_proposal *dfr_proposal, *tmp;
uint32_t remaining_lifetime;
- int
unveil(2) for spamlogd(8)
Hi,
Are there any brave souls out there with unveil(2) enabled already?
If yes please test this diff for spamlogd(8) which seems to only need rw
access to the file PATH_SPAMD_DB and nothing else.
Not asking for OKs yet, but if the code pattern is correct can I start looking
at other programs?
Index: spamlogd.c
===
RCS file: /cvs/src/libexec/spamlogd/spamlogd.c,v
retrieving revision 1.27
diff -u -p -u -r1.27 spamlogd.c
--- spamlogd.c 16 Mar 2016 14:47:04 - 1.27
+++ spamlogd.c 18 Jul 2018 11:46:59 -
@@ -376,12 +376,15 @@ main(int argc, char **argv)
}
if (syncsend) {
- if (pledge("stdio rpath wpath inet flock", NULL) == -1)
+ if (pledge("stdio rpath wpath inet flock unveil", NULL) == -1)
err(1, "pledge");
} else {
- if (pledge("stdio rpath wpath flock", NULL) == -1)
+ if (pledge("stdio rpath wpath flock unveil", NULL) == -1)
err(1, "pledge");
}
+
+ if (unveil(PATH_SPAMD_DB, "rw") == -1)
+ err(1, "unveil");
pcap_loop(hpcap, -1, phandler, NULL);
Re: call for testing: rad(8) - a rtadvd(8) replacement
On Wed, Jul 18, 2018 at 11:03:46AM +0200, Sebastien Marie wrote:
> On Wed, Jul 18, 2018 at 08:54:51AM +0200, Florian Obser wrote:
> > During g2k18 I commited rad(8).
> >
> > The latest amd64 and i386 snapshots should contain it with enough
> > features to replace rtadvd(8). If you are using rtadvd(8) I'd
> > appreciate if you could switch to rad(8) and report back if any
> > features are missing.
> >
> > The plan is to unhook rtadvd(8) from the build sooner rather than
> > later and to ship 6.4 with rad(8) only.
> >
>
> Hi,
>
> I switched my gateway to use rad instead of rtadvd.
thank you for testing!
>
> So, some questions :-)
>
> First the topology:
> - internet connection on pppoe0
> - 2 lan interfaces with ipv6: vlan92 and vlan110
>
> I obtain ipv6 on pppoe0 with DHCPv6-PD.
>
> My upstream send me also router-advertisement on this interface.
>
> tcpdump output:
> fe80::2a6f:7fff:fe0e:ae80 > ff02::1: icmp6: router
> advertisement(chlim=64, O, pref=medium, router_ltime=1800, reachable_time=0,
> retrans_time=0)(mtu: mtu=1492)(rdnss: lifetime=400s,
> addr=:::::1, addr=:::::1) [icmp6 cksum ok]
> [class 0xe0] (len 64, hlim 255)
>
>
> On the gateway, I use the following rad.conf file:
>
> interface vlan92 {
> dns {
> resolver ":::XX5c:cabe:19ff:fee2:2ced"
> }
> }
>
> interface vlan110 {
> dns {
> resolver ":::XX6e:cabe:19ff:fee2:2ced"
> }
> }
>
>
> $ ifconfig vlan92
> vlan92: flags=8943 mtu 1500
> lladdr c8:be:19:e2:2c:ed
> index 16 priority 0 llprio 3
> encap: vnetid 92 parent re0
> groups: vlan
> media: Ethernet autoselect (1000baseT full-duplex)
> status: active
> inet 192.168.92.2 netmask 0xff00 broadcast 192.168.92.255
> inet6 fe80::7f08:c8d1:d9fd:1581%vlan92 prefixlen 64 scopeid 0x10
> inet6 :::XX5c:cabe:19ff:fee2:2ced prefixlen 64
> inet6 :::XX5c::1 prefixlen 64 pltime 599160 vltime 2586360
>
> For now, it works well. But I see the following in syslog:
>
> Jul 18 10:28:05 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
> Jul 18 10:28:06 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::7f08:c8d1:d9fd:1581 on vlan110 # from itself
> Jul 18 10:29:24 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
> Jul 18 10:31:12 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::f280:16b4:9c3b:5f8f on vlan92
> Jul 18 10:32:19 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
> Jul 18 10:33:33 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
> Jul 18 10:35:28 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
> Jul 18 10:36:49 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::7f08:c8d1:d9fd:1581 on vlan110 # from itself
> Jul 18 10:38:04 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
> Jul 18 10:40:08 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
> Jul 18 10:40:47 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
> Jul 18 10:41:58 alf rad[86733]: RA or RS with hop limit of 255 from
> fe80::61fd:ac94:2a15:bd0b on vlan92
I just switched the log_warnx to log_debug, that was an oversight on
my part, this is mostly normal operation
>
> rad(8) seems to log RA/RS from all interfaces:
> - from interface not configured for being managed by itself, like pppoe0
> - from interface managed by itself and RA sent by itself (shouldn't it
> know it sent it ?)
Yes, and it should not receive them. I believe this is the
IPV6_MULTICAST_LOOP socketopt missing on the icmp6 socket.
I'll probably fix it this evening.
> - from interface managed by itself and RA/RS sent by someone else
>
> I am unsure about the purpose of this log: it seems to be an
> unconditional log on RA/RS reception.
>
> It could have value for RA/RS where it isn't sent by rad(8) itself, and
> if it is on some configured interface for rad(8). For others cases, I am
> unsure.
rad(8) receiving RAs on all interfaces is for future work. As said
above, it doesn't need to see it's own RAs, but all the others.
Router advertisement messages are supposed to contain all prefixes
this router knows about. Hosts can form addresses from some of these
prefixes (iff the A flag is set) or add more specific routes for
others.
Let's assume a slightly different topology. Assume
Re: call for testing: rad(8) - a rtadvd(8) replacement
On Wed, Jul 18, 2018 at 08:54:51AM +0200, Florian Obser wrote:
> During g2k18 I commited rad(8).
>
> The latest amd64 and i386 snapshots should contain it with enough
> features to replace rtadvd(8). If you are using rtadvd(8) I'd
> appreciate if you could switch to rad(8) and report back if any
> features are missing.
>
> The plan is to unhook rtadvd(8) from the build sooner rather than
> later and to ship 6.4 with rad(8) only.
>
Hi,
I switched my gateway to use rad instead of rtadvd.
So, some questions :-)
First the topology:
- internet connection on pppoe0
- 2 lan interfaces with ipv6: vlan92 and vlan110
I obtain ipv6 on pppoe0 with DHCPv6-PD.
My upstream send me also router-advertisement on this interface.
tcpdump output:
fe80::2a6f:7fff:fe0e:ae80 > ff02::1: icmp6: router
advertisement(chlim=64, O, pref=medium, router_ltime=1800, reachable_time=0,
retrans_time=0)(mtu: mtu=1492)(rdnss: lifetime=400s,
addr=:::::1, addr=:::::1) [icmp6 cksum ok]
[class 0xe0] (len 64, hlim 255)
On the gateway, I use the following rad.conf file:
interface vlan92 {
dns {
resolver ":::XX5c:cabe:19ff:fee2:2ced"
}
}
interface vlan110 {
dns {
resolver ":::XX6e:cabe:19ff:fee2:2ced"
}
}
$ ifconfig vlan92
vlan92: flags=8943 mtu 1500
lladdr c8:be:19:e2:2c:ed
index 16 priority 0 llprio 3
encap: vnetid 92 parent re0
groups: vlan
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.92.2 netmask 0xff00 broadcast 192.168.92.255
inet6 fe80::7f08:c8d1:d9fd:1581%vlan92 prefixlen 64 scopeid 0x10
inet6 :::XX5c:cabe:19ff:fee2:2ced prefixlen 64
inet6 :::XX5c::1 prefixlen 64 pltime 599160 vltime 2586360
For now, it works well. But I see the following in syslog:
Jul 18 10:28:05 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
Jul 18 10:28:06 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::7f08:c8d1:d9fd:1581 on vlan110# from itself
Jul 18 10:29:24 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:31:12 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::f280:16b4:9c3b:5f8f on vlan92
Jul 18 10:32:19 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:33:33 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
Jul 18 10:35:28 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:36:49 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::7f08:c8d1:d9fd:1581 on vlan110# from itself
Jul 18 10:38:04 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:40:08 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::7f08:c8d1:d9fd:1581 on vlan92 # from itself
Jul 18 10:40:47 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::2a6f:7fff:fe0e:ae80 on pppoe0 # not managed interface
Jul 18 10:41:58 alf rad[86733]: RA or RS with hop limit of 255 from
fe80::61fd:ac94:2a15:bd0b on vlan92
rad(8) seems to log RA/RS from all interfaces:
- from interface not configured for being managed by itself, like pppoe0
- from interface managed by itself and RA sent by itself (shouldn't it
know it sent it ?)
- from interface managed by itself and RA/RS sent by someone else
I am unsure about the purpose of this log: it seems to be an
unconditional log on RA/RS reception.
It could have value for RA/RS where it isn't sent by rad(8) itself, and
if it is on some configured interface for rad(8). For others cases, I am
unsure.
Thanks for the clarification.
--
Sebastien Marie
call for testing: rad(8) - a rtadvd(8) replacement
During g2k18 I commited rad(8). The latest amd64 and i386 snapshots should contain it with enough features to replace rtadvd(8). If you are using rtadvd(8) I'd appreciate if you could switch to rad(8) and report back if any features are missing. The plan is to unhook rtadvd(8) from the build sooner rather than later and to ship 6.4 with rad(8) only. If you are running rtadvd(8) with out any configuration and only have rtadvd_flags=em1 the /etc/rad.conf file will be ---8<--- interface em0 ---8<--- Once that is inplace disable rtadvd and enable rad: # rcctl stop rtadvd # rcctl disable rtadvd # rcctl enable rad # rcctl start rad see man rad.conf for documentation on the config file format. Good news: it's no longer termcap based! Thanks! -- I'm not entirely sure you are real.
