patch: make share/mk support for yacc files better behaved
This is a collaboration of sort with FreeBSD.
To me very specific, working on fixing depends made me look at fixing yacc
support, and at the same time, I looked at FreeBSD, and they did this
already (with different code, our share/mk are wildly divergent), so this
comforted me this was doable and probably not too painful.
So far so good. It has surprisingly little impact on base.
I'm currently building xenocara as well, and intend to put this thru
a ports build as well.
What this does:
- change the .y -> .c rule for bsd.prog.mk/bsd.lib.mk (thru bsd.sys.mk)
so that it does .y -> .c/.h, thus changing the name of the generated .h file
- add an explicit dependency (+ the same rule, more or less) in bsd.dep.mk
so that the .c and .h are tied correctly, and so that the .h is cleaned
as well.
What this does not:
- change the default rule in sys.mk for yacc files, because that would break
posix compatibility, and impact way more software we don't have a direct
interest in maintaining.
Impact: surprisingly few programs. A lot of other stuff actually has ad-hoc
rules that could probably be cleansed afterwards.
Considering how much of a headache, having the framework do something sane
by default, even if this involves changing a few files, seems like a good
thing to me...
After running that build, I think it's reaching the stage where I'm actually
asking for review and okays.
Index: games/atc/lex.l
===
RCS file: /build/data/openbsd/cvs/src/games/atc/lex.l,v
retrieving revision 1.4
diff -u -p -r1.4 lex.l
--- games/atc/lex.l 27 Oct 2009 23:59:23 - 1.4
+++ games/atc/lex.l 7 Jul 2017 11:15:08 -
@@ -43,7 +43,7 @@
* For more info on this and all of my stuff, mail edja...@berkeley.edu.
*/
-#include "y.tab.h"
+#include "grammar.h"
extern int line;
Index: sbin/wsconsctl/map_scan.l
===
RCS file: /build/data/openbsd/cvs/src/sbin/wsconsctl/map_scan.l,v
retrieving revision 1.6
diff -u -p -r1.6 map_scan.l
--- sbin/wsconsctl/map_scan.l 19 Nov 2015 19:48:27 - 1.6
+++ sbin/wsconsctl/map_scan.l 7 Jul 2017 11:05:29 -
@@ -39,7 +39,7 @@
#include
#include
#include "wsconsctl.h"
-#include "y.tab.h"
+#include "map_parse.h"
void
map_scan_setinput(char *str)
Index: share/mk/bsd.dep.mk
===
RCS file: /build/data/openbsd/cvs/src/share/mk/bsd.dep.mk,v
retrieving revision 1.20
diff -u -p -r1.20 bsd.dep.mk
--- share/mk/bsd.dep.mk 5 Jul 2017 13:30:01 - 1.20
+++ share/mk/bsd.dep.mk 7 Jul 2017 11:04:37 -
@@ -38,6 +38,17 @@ tags:
${i:R:S/$/.o/} ${i:R:S/$/.po/} ${i:R:S/$/.so/} ${i:R:S/$/.do/}: $i
.endfor
+# give us better rules for yacc
+
+.if ${YFLAGS:M-d}
+# loop may not trigger
+. for f in ${SRCS:M*.y}
+${f:.y=.c} ${f:.y=.h}: $f
+ ${YACC.y} -o ${f:.y=.c} ${.IMPSRC}
+. endfor
+CLEANFILES += ${SRCS:M*.y:.y=.h}
+.endif
+
CLEANFILES += ${DEPS} .depend
BUILDFIRST ?=
Index: share/mk/bsd.sys.mk
===
RCS file: /build/data/openbsd/cvs/src/share/mk/bsd.sys.mk,v
retrieving revision 1.12
diff -u -p -r1.12 bsd.sys.mk
--- share/mk/bsd.sys.mk 5 Jul 2017 13:31:40 - 1.12
+++ share/mk/bsd.sys.mk 7 Jul 2017 10:32:40 -
@@ -10,18 +10,5 @@ CPPFLAGS+= -nostdinc -idirafter ${DESTDI
CXXFLAGS+= -idirafter ${DESTDIR}/usr/include/g++
.endif
-.if defined(PARALLEL)
-# Yacc
-.y:
- ${YACC.y} -b ${.TARGET:R} ${.IMPSRC}
- ${LINK.c} -o ${.TARGET} ${.TARGET:R}.tab.c ${LDLIBS}
- rm -f ${.TARGET:R}.tab.c
.y.c:
- ${YACC.y} -b ${.TARGET:R} ${.IMPSRC}
- mv ${.TARGET:R}.tab.c ${.TARGET}
-.y.o:
- ${YACC.y} -b ${.TARGET:R} ${.IMPSRC}
- ${COMPILE.c} -o ${.TARGET} ${.TARGET:R}.tab.c
- rm -f ${.TARGET:R}.tab.c
- if test -f ${.TARGET:R}.d; then sed -i -e
's,${.TARGET:R}.tab.c,${.IMPSRC},' ${.TARGET:R}.d; fi
-.endif
+ ${YACC.y} -o ${.TARGET} ${.IMPSRC}
Index: usr.bin/m4/Makefile
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/m4/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- usr.bin/m4/Makefile 4 Jul 2017 08:39:57 - 1.15
+++ usr.bin/m4/Makefile 7 Jul 2017 11:13:24 -
@@ -14,11 +14,4 @@ DPADD= ${LIBM} ${LIBUTIL}
SRCS= eval.c expr.c look.c main.c misc.c gnum4.c trace.c tokenizer.l parser.y
MAN= m4.1
-parser.c parser.h: parser.y
- ${YACC} -o parser.c -d ${.ALLSRC}
-
-tokenizer.o: parser.h
-
-CLEANFILES+=parser.c parser.h tokenizer.o
-
.include
Index: usr.bin/rdist/Makefile
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/rdist/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- usr.bin/rdist/Makefile 12 Jul 2014 03:32:00 - 1.19
+++ usr.bin/rdist/Makefile
Re: cwm: remove ssh auto-completion
On Fri, Jul 07, 2017 at 12:44:35PM -0400, Okan Demirmen wrote:
> Hi cwm users,
>
> In converting this to use getline(3) over fgetln(3), I'm asking the question
> if
> this (imho) mis-feature belongs in a window manager. I've hinted at wanting to
> remove it in the past but there was opposition. As a compromise, we could
> just
> leave the 'ssh>' menu available, but it will not be pre-populated (nor
> auto-completed) by what's in ~/.ssh/known_hosts; just type in the
> host/ip/whatever at the menu prompt. cwm(1) does a very rudimentary pass at
> parsing the known_hosts file, and there's no reason to hoist code from ssh(1)
> just to get auto-completion in a window manager menu.
>
> Below is the minimal code part in kbfunc_menu_ssh().
>
> Preferably, I'd like to remove the whole ssh menu, but can live with the below
> if it's useful to others.
>
> Thoughts?
>
> Thanks,
> Okan
Just my opinion, users can already set short aliases in their
.ssh/config files, so having to type in the host manually
shouldn't be too difficult.
I've never used this feature, I also typically don't expect auto
completion from every window manager UI context, unless for cmds
and paths.
-Bryan.
> Index: kbfunc.c
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/kbfunc.c,v
> retrieving revision 1.145
> diff -u -p -r1.145 kbfunc.c
> --- kbfunc.c 9 May 2017 13:40:18 - 1.145
> +++ kbfunc.c 6 Jul 2017 19:36:13 -
> @@ -462,50 +462,16 @@ kbfunc_menu_ssh(void *ctx, struct cargs
> struct cmd_ctx *cmd;
> struct menu *mi;
> struct menu_qmenuq;
> - FILE*fp;
> - char*buf, *lbuf, *p;
> - char hostbuf[HOST_NAME_MAX+1];
> char path[PATH_MAX];
> int l;
> - size_t len;
>
> TAILQ_FOREACH(cmd, &Conf.cmdq, entry) {
> if (strcmp(cmd->name, "term") == 0)
> break;
> }
> - TAILQ_INIT(&menuq);
>
> - if ((fp = fopen(Conf.known_hosts, "r")) == NULL) {
> - warn("%s: %s", __func__, Conf.known_hosts);
> - goto menu;
> - }
> + TAILQ_INIT(&menuq);
>
> - lbuf = NULL;
> - while ((buf = fgetln(fp, &len))) {
> - if (buf[len - 1] == '\n')
> - buf[len - 1] = '\0';
> - else {
> - /* EOF without EOL, copy and add the NUL */
> - lbuf = xmalloc(len + 1);
> - (void)memcpy(lbuf, buf, len);
> - lbuf[len] = '\0';
> - buf = lbuf;
> - }
> - /* skip hashed hosts */
> - if (strncmp(buf, HASH_MARKER, strlen(HASH_MARKER)) == 0)
> - continue;
> - for (p = buf; *p != ',' && *p != ' ' && p != buf + len; p++) {
> - /* do nothing */
> - }
> - /* ignore badness */
> - if (p - buf + 1 > sizeof(hostbuf))
> - continue;
> - (void)strlcpy(hostbuf, buf, p - buf + 1);
> - menuq_add(&menuq, NULL, "%s", hostbuf);
> - }
> - free(lbuf);
> - (void)fclose(fp);
> -menu:
> if ((mi = menu_filter(sc, &menuq, "ssh", NULL, (CWM_MENU_DUMMY),
> search_match_text, search_print_text)) != NULL) {
> if (mi->text[0] == '\0')
cwm: remove ssh auto-completion
Hi cwm users,
In converting this to use getline(3) over fgetln(3), I'm asking the question if
this (imho) mis-feature belongs in a window manager. I've hinted at wanting to
remove it in the past but there was opposition. As a compromise, we could just
leave the 'ssh>' menu available, but it will not be pre-populated (nor
auto-completed) by what's in ~/.ssh/known_hosts; just type in the
host/ip/whatever at the menu prompt. cwm(1) does a very rudimentary pass at
parsing the known_hosts file, and there's no reason to hoist code from ssh(1)
just to get auto-completion in a window manager menu.
Below is the minimal code part in kbfunc_menu_ssh().
Preferably, I'd like to remove the whole ssh menu, but can live with the below
if it's useful to others.
Thoughts?
Thanks,
Okan
Index: kbfunc.c
===
RCS file: /home/open/cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.145
diff -u -p -r1.145 kbfunc.c
--- kbfunc.c9 May 2017 13:40:18 - 1.145
+++ kbfunc.c6 Jul 2017 19:36:13 -
@@ -462,50 +462,16 @@ kbfunc_menu_ssh(void *ctx, struct cargs
struct cmd_ctx *cmd;
struct menu *mi;
struct menu_qmenuq;
- FILE*fp;
- char*buf, *lbuf, *p;
- char hostbuf[HOST_NAME_MAX+1];
char path[PATH_MAX];
int l;
- size_t len;
TAILQ_FOREACH(cmd, &Conf.cmdq, entry) {
if (strcmp(cmd->name, "term") == 0)
break;
}
- TAILQ_INIT(&menuq);
- if ((fp = fopen(Conf.known_hosts, "r")) == NULL) {
- warn("%s: %s", __func__, Conf.known_hosts);
- goto menu;
- }
+ TAILQ_INIT(&menuq);
- lbuf = NULL;
- while ((buf = fgetln(fp, &len))) {
- if (buf[len - 1] == '\n')
- buf[len - 1] = '\0';
- else {
- /* EOF without EOL, copy and add the NUL */
- lbuf = xmalloc(len + 1);
- (void)memcpy(lbuf, buf, len);
- lbuf[len] = '\0';
- buf = lbuf;
- }
- /* skip hashed hosts */
- if (strncmp(buf, HASH_MARKER, strlen(HASH_MARKER)) == 0)
- continue;
- for (p = buf; *p != ',' && *p != ' ' && p != buf + len; p++) {
- /* do nothing */
- }
- /* ignore badness */
- if (p - buf + 1 > sizeof(hostbuf))
- continue;
- (void)strlcpy(hostbuf, buf, p - buf + 1);
- menuq_add(&menuq, NULL, "%s", hostbuf);
- }
- free(lbuf);
- (void)fclose(fp);
-menu:
if ((mi = menu_filter(sc, &menuq, "ssh", NULL, (CWM_MENU_DUMMY),
search_match_text, search_print_text)) != NULL) {
if (mi->text[0] == '\0')
Re: [PATCH] clarify history of htpasswd(1) in its manpage
Hi Raf, Raf Czlonka wrote on Fri, Jul 07, 2017 at 03:30:41AM +0100: > Just gone through htpasswd(1)'s man page and noticed this > in the AUTHORS section: > > Florian Obser implemented htpasswd > from scratch after httpd was removed from OpenBSD base. > > To those not familiar with OpenBSD's release history, this may seem > wrong (after all, httpd *is* in base) or misleading at the very least. > > What do you think about clarifying it ever so slightly? Seems helpful. Committed, thanks! Ingo > Index: usr.bin/htpasswd/htpasswd.1 > === > RCS file: /cvs/src/usr.bin/htpasswd/htpasswd.1,v > retrieving revision 1.7 > diff -u -p -r1.7 htpasswd.1 > --- usr.bin/htpasswd/htpasswd.1 26 Aug 2014 21:50:38 - 1.7 > +++ usr.bin/htpasswd/htpasswd.1 7 Jul 2017 02:24:05 - > @@ -69,6 +69,6 @@ has been available since > .An Florian Obser Aq Mt flor...@openbsd.org > implemented > .Nm > -from scratch after httpd was removed from > +from scratch after Apache httpd was removed from > .Ox > base.
Re: install.sub: Typo/whitespace nit
On Tue, Jul 04, 2017 at 02:14:58AM +0200, Klemens Nanni wrote: > Remove duplicate full stop and add space after function name. committed, thanks
Re: install.sub: Typo/whitespace nit
On Tue, Jul 04, 2017 at 02:14:58AM +0200, Klemens Nanni wrote:
> Remove duplicate full stop and add space after function name.
>
> Feedback/OK?
>
> Index: install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1019
> diff -u -p -r1.1019 install.sub
> --- install.sub 2 Jul 2017 12:45:43 - 1.1019
> +++ install.sub 4 Jul 2017 00:11:59 -
> @@ -275,7 +275,7 @@ diskinfo() {
> _i=${_i##+([[:space:],])}
> _i=${_i%%+([[:space:],])}
>
> - # Extract Network Address Authority information from dmesg..
> + # Extract Network Address Authority information from dmesg.
> _n=$(dmesg | sed -En '/^'$_d' at /h;${g;s/^.*
> ([a-z0-9]+\.[a-zA-Z0-9_]+)$/\1/p;}')
>
> # Extract disk size from disklabel output.
> @@ -2968,7 +2970,7 @@ do_install() {
> finish_up
> }
>
> -do_upgrade(){
> +do_upgrade() {
> # Get $ROOTDISK and $ROOTDEV
> get_rootinfo
OK
[diff] httpd: add tls client certificate verification
Now that libtls supports CRL checking (thanks jsing@ & beck@ for your
help to get that in), let's have another go at adding tls client
verification to httpd.
This diff does just that, with options to verify tls client certs,
optionally with full chain CRL checks.
All the same info is passed through to fastcgi as in httpd diff I
posted here in late May (see also the two related threads on tech@ in
late March / early April), plus a new TLS_VERIFY_MODE to let the fastcgi
responders know how much (if any) client cert checking httpd has done
already (for much the same reason as httpd passes through HTTPS to
fastcgi).
With this diff, httpd is capable of looking after all aspects of tls
client authentication.
Any *authorisation* based on tls client certs beyond a simple "holder
of any trusted, authentic, non-revoked cert can access anything" remains
the province of the fastcgi responders, presumably based on the contents
of TLS_PEER_* (again, see the discussion here in April).
Thoughts?
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.52
diff -u -p -r1.52 config.c
--- usr.sbin/httpd/config.c 28 May 2017 10:37:26 - 1.52
+++ usr.sbin/httpd/config.c 7 Jul 2017 08:24:01 -
@@ -326,6 +326,80 @@ config_settls(struct httpd *env, struct
}
}
+ if (srv_conf->tls_ca_len != 0 &&
+ config_settls_chunk(env, srv, IMSG_CFG_TLS_CA) != 0)
+ return (-1);
+
+ if (srv_conf->tls_crl_len != 0)
+ return config_settls_chunk(env, srv, IMSG_CFG_TLS_CRL);
+
+ return (0);
+}
+
+int
+config_settls_chunk(struct httpd *env, struct server *srv, int cmd)
+{
+ struct privsep *ps = env->sc_ps;
+ struct server_config *srv_conf = &srv->srv_conf;
+ struct tls_config tls;
+ struct iovec iov[2];
+ size_tc, chunk_len, i, sent;
+ size_t *src_len;
+ uint8_t **src;
+ const char * type;
+
+ if ((srv_conf->flags & SRVFLAG_TLS) == 0)
+ return (0);
+ if (cmd == IMSG_CFG_TLS_CA) {
+ if ((srv_conf->tls_client_flags & TLSCLIENTFLAG_VERIFY) == 0)
+ return (0);
+ src_len = &srv_conf->tls_ca_len;
+ src = &srv_conf->tls_ca;
+ type = "ca cert(s)";
+ } else if (cmd == IMSG_CFG_TLS_CRL) {
+ if ((srv_conf->tls_client_flags & TLSCLIENTFLAG_CRL) == 0)
+ return (0);
+ src_len = &srv_conf->tls_crl_len;
+ src = &srv_conf->tls_crl;
+ type = "crl(s)";
+ } else {
+ DPRINTF("%s: server \"%s[%u]\": invalid cmd: %d", __func__,
+ srv_conf->name, srv_conf->id, cmd);
+ return (-1);
+ }
+
+ log_debug("%s: configuring tls %s for %s", __func__, type,
+ srv_conf->name);
+
+ if (*src_len != 0) {
+ DPRINTF("%s: sending %s for \"%s[%u]\" to %s fd %d", __func__,
+ type, srv_conf->name, srv_conf->id,
+ ps->ps_title[PROC_SERVER], srv->srv_s);
+ memset(&tls, 0, sizeof(tls));
+ tls.id = srv_conf->id;
+ tls.tls_src_len = *src_len;
+
+ chunk_len = MAX_IMSGSIZE - (ssize_t)IMSG_HEADER_SIZE -
sizeof(tls);
+ for (sent = 0, i = 1; sent < tls.tls_src_len;
+ sent += chunk_len, i++) {
+ if (tls.tls_src_len - sent < chunk_len)
+ chunk_len = tls.tls_src_len - sent;
+ tls.tls_chunk_off = sent;
+ c = 0;
+ iov[c].iov_base = &tls;
+ iov[c++].iov_len = sizeof(tls);
+ iov[c].iov_base = *src + sent;
+ iov[c++].iov_len = chunk_len;
+
+ if (proc_composev(ps, PROC_SERVER, cmd, iov, c) != 0) {
+ log_warn("%s: failed to compose chunk %lu of "
+ "%s imsg for `%s'", __func__, i, type,
+ srv_conf->name);
+ return (-1);
+ }
+ }
+ }
+
return (0);
}
@@ -644,6 +718,79 @@ config_gettls(struct httpd *env, struct
tls_conf.tls_ocsp_staple_len)) == NULL)
goto fail;
s += tls_conf.tls_ocsp_staple_len;
+ }
+
+ return (0);
+
+ fail:
+ return (-1);
+}
+
+int
+config_gettls_chunk(struct httpd *env, struct imsg *imsg)
+{
+#ifdef DEBUG
+ struct privsep *ps = env->sc_ps;
+#endif
+ struct server_config *srv_conf = NULL;
+ struct tls_config tls_conf;
+ uint8_t
Re: dhcpd: don't reject DHCPINFORM from behind relay
On Thu, Jul 06, 2017 at 11:28:11AM +0200, Landry Breuil wrote: > On Wed, Jul 05, 2017 at 04:37:39PM +0200, Reyk Floeter wrote: > > Hi, > > > > landry@ sees many log messages 'DHCPINFORM from xx but ciaddr yy is > > not consistent with actual address' in a setup where dhcpd runs behind > > dhcrelay. > > > > The code in dhcpd's dhcpinform() seems wrong - it assumes that ciaddr > > (the client IP) is identical to the packet source address and it > > doesn't consider a relay, indicated by giaddr (gateway). > > > > I looked at isc-dhcpd code and, omg my eyes are bleeding, it seems to > > handle DHCPINFORM from relayed clients with giaddr set. > > > > So it seems that dhcpd never accepted DHCPINFORM from clients behind a > > relay, and the diff below changes it and stops the log spam. But it > > also changes behavior, so it needs some testing and maybe feedback > > from DHCP experts (prodding krw). > > I've put this on a 6.1 vm behind a dhcrelay at work, previously the > w7 clients were apparently sending DHCPINFORM every ~10mn, and in bursts: > > Jul 5 14:52:42 oberalp dhcpd[92834]: DHCPINFORM from 172.20.85.254 but > ciaddr 172.20.85.124 is not consistent with actual address > Jul 5 14:52:45 oberalp dhcpd[92834]: DHCPINFORM from 172.20.85.254 but > ciaddr 172.20.85.124 is not consistent with actual address > Jul 5 14:54:11 oberalp last message repeated 2 times > Jul 5 14:55:23 oberalp dhcpd[92834]: DHCPINFORM from 172.20.85.254 but > ciaddr 172.20.85.107 is not consistent with actual address > Jul 5 14:55:26 oberalp dhcpd[92834]: DHCPINFORM from 172.20.85.254 but > ciaddr 172.20.85.107 is not consistent with actual address > Jul 5 14:56:50 oberalp last message repeated 2 times > > With this diff, now the clients still send DHCPINFORM, some every ~10mn, > some every ~30m, still in bursts, and the DHCPACK is sent back: > > Jul 6 11:08:06 oberalp dhcpd[42317]: DHCPACK to 172.20.85.107 > () via 172.20.85.254 > Jul 6 11:08:09 oberalp dhcpd[42317]: DHCPINFORM from 172.20.85.254 > Jul 6 11:08:09 oberalp dhcpd[42317]: DHCPACK to 172.20.85.107 > () via 172.20.85.254 > Jul 6 11:18:13 oberalp dhcpd[42317]: DHCPINFORM from 172.20.85.254 > Jul 6 11:18:13 oberalp dhcpd[42317]: DHCPACK to 172.20.85.107 > () via 172.20.85.254 > Jul 6 11:18:16 oberalp dhcpd[42317]: DHCPINFORM from 172.20.85.254 > Jul 6 11:18:16 oberalp dhcpd[42317]: DHCPACK to 172.20.85.107 > () via 172.20.85.254 > Jul 6 11:19:13 oberalp dhcpd[42317]: DHCPINFORM from 172.20.85.254 > Jul 6 11:19:13 oberalp dhcpd[42317]: DHCPACK to 172.20.85.122 > () via 172.20.85.254 > Jul 6 11:19:16 oberalp dhcpd[42317]: DHCPINFORM from 172.20.85.254 > Jul 6 11:19:16 oberalp dhcpd[42317]: DHCPACK to 172.20.85.122 > () via 172.20.85.254 > Jul 6 11:20:58 oberalp dhcpd[42317]: DHCPINFORM from 172.20.85.254 > Jul 6 11:20:58 oberalp dhcpd[42317]: DHCPACK to 172.20.85.122 > () via 172.20.85.254 > Jul 6 11:21:01 oberalp dhcpd[42317]: DHCPINFORM from 172.20.85.254 > Jul 6 11:21:01 oberalp dhcpd[42317]: DHCPACK to 172.20.85.122 > () via 172.20.85.254 And it seems after a while the win7 clients *finally* stop spamming the server with DHCPINFORM requests. Yay. Maybe that's because of the hack put in dhcpd.conf option autoproxy-script "\\n"; Something else, which i dunno is related to this diff or not - before, a dhcpd was receiving a single DHCPREQUEST (ie i ran dhclient on an openbsd client) and replying to it: Jul 5 14:22:15 oberalp dhcpd[92834]: DHCPREQUEST for 172.20.85.109 from 00:24:e8:3d:46:fe via 172.20.85.254 Jul 5 14:22:15 oberalp dhcpd[92834]: DHCPACK on 172.20.85.109 to 00:24:e8:3d:46:fe via 172.20.85.254 Now, for some linux clients which are re-requesting/renewing a lease, i see two REQUESTS in the log, one logged as coming directly on vio0, and one coming from the dhcrelay gateway: Jul 7 06:16:14 oberalp dhcpd[91347]: DHCPREQUEST for 172.20.85.110 from 00:14:fd:12:96:8e via vio0 Jul 7 06:16:14 oberalp dhcpd[91347]: DHCPACK on 172.20.85.110 to 00:14:fd:12:96:8e via vio0 Jul 7 06:16:14 oberalp dhcpd[91347]: DHCPREQUEST for 172.20.85.110 from 00:14:fd:12:96:8e via 172.20.85.254 Jul 7 06:16:14 oberalp dhcpd[91347]: DHCPACK on 172.20.85.110 to 00:14:fd:12:96:8e via 172.20.85.254 Jul 7 06:51:10 oberalp dhcpd[91347]: DHCPREQUEST for 172.20.85.111 from 00:19:b9:fe:b2:10 via vio0 Jul 7 06:51:10 oberalp dhcpd[91347]: DHCPACK on 172.20.85.111 to 00:19:b9:fe:b2:10 via vio0 Jul 7 06:51:10 oberalp dhcpd[91347]: DHCPREQUEST for 172.20.85.111 from 00:19:b9:fe:b2:10 via 172.20.85.254 Jul 7 06:51:10 oberalp dhcpd[91347]: DHCPACK on 172.20.85.111 to 00:19:b9:fe:b2:10 via 172.20.85.254 Dunno if that's an expected behaviour - and it seems it was already this way before the diff. For a new client using DHCPDISCOVER dhcpd only sees a single discover/offer/request/ack sequence: Jul 7 09:11:27 oberalp dhcpd[91347]: DHCPDISCOVER from 00:50:b6:5c:d9:e8 via 172.20.85.254 Jul 7 09:11:27 oberalp dhcpd[91347]: DHCPOFFER
csh(1): restore tty on SIGINT
Hi,
This one is crucial, aborting loops in csh is done upon receiving
SIGINT. The signal handler will eventually call longjmp() and re-enter
the input loop if all went well. The tty should therefore be restored
prior sending the SIGINT.
Strange behavior discovered by the regress suite.
Comments? OK?
Index: file.c
===
RCS file: /cvs/src/bin/csh/file.c,v
retrieving revision 1.30
diff -u -p -r1.30 file.c
--- file.c 29 Jun 2017 04:23:12 - 1.30
+++ file.c 7 Jul 2017 07:49:15 -
@@ -228,8 +228,11 @@ cl_abort(struct cmdline *cl, int c)
cl_visc(cl, c);
/* Abort while/foreach loop prematurely. */
- if (whyles)
+ if (whyles) {
+ setup_tty(0);
kill(getpid(), SIGINT);
+ /* NOTREACHED */
+ }
cl_putc(cl, '\n');
cl->len = cl->cursor = 0;
