Re: uhidpp(4): logitech hid++ device driver
On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > Hi, > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > Regarding the dmesg (on below) I can see it gets attached correctly to > uhiddp0 but doesn't report battery levels. Here's the line from dmesg: > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device 2 keyboard > "K750" serial xx-xx-xx-xx. > And corresponding sysctl values: > hw.sensors.uhidpp0.raw0=unknown (battery levels) > hw.sensors.uhidpp0.raw1=unknown (battery levels) > hw.sensors.uhidpp0.percent0=unknown (battery level) > hw.sensors.uhidpp0.percent1=unknown (battery level) > > Not sure if censoring of serial has any value, though. Glad to see it attaches fine to a receiver with more than one device paired. I only have one device myself and have therefore never been enable to verify this. Could you enable UHIDPP_DEBUG and send me the output? > On Ubuntu battery levels are detected correctly so I could probably > take a USB dump with Wireshark and compare the differences. Taking a USB dump on your Linux machine would be very helpful.
disklabel: pointer deref fix
Fix a pointer dereference in disklabel(8).
This looks like somebody wrote *s[0] in place of (*s)[0].
Which in this case happens to be equivalent, but it still looks
wrong.
OK?
Index: sbin/disklabel/editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.363
diff -u -p -U6 -r1.363 editor.c
--- sbin/disklabel/editor.c 19 Nov 2019 06:20:37 - 1.363
+++ sbin/disklabel/editor.c 29 Jan 2021 23:50:24 -
@@ -2374,22 +2374,22 @@ char *
get_token(char **s, size_t *len)
{
char*p, *r;
size_t tlen = 0;
p = *s;
- while (*len > 0 && !isspace((u_char)*s[0])) {
+ while (*len > 0 && !isspace((u_char)**s)) {
(*s)++;
(*len)--;
tlen++;
}
if (tlen == 0)
return (NULL);
/* eat whitespace */
- while (*len > 0 && isspace((u_char)*s[0])) {
+ while (*len > 0 && isspace((u_char)**s)) {
(*s)++;
(*len)--;
}
if ((r = strndup(p, tlen)) == NULL)
err(1, NULL);
--
Christian "naddy" Weisgerber na...@mips.inka.de
sed: make use of getline(3)
Replace fgetln(3) with getline(3) in sed.
The mf_fgets() part is from Johann Oskarsson for Illumos/FreeBSD.
Passes our sed regression tests.
OK?
Index: usr.bin/sed/main.c
===
RCS file: /cvs/src/usr.bin/sed/main.c,v
retrieving revision 1.41
diff -u -p -r1.41 main.c
--- usr.bin/sed/main.c 13 Oct 2020 06:07:54 - 1.41
+++ usr.bin/sed/main.c 29 Jan 2021 23:12:23 -
@@ -252,15 +252,9 @@ again:
goto again;
}
case ST_FILE:
- if ((p = fgetln(f, )) != NULL) {
+ if (getline(outbuf, outsize, f) != -1) {
+ p = *outbuf;
linenum++;
- if (len >= *outsize) {
- free(*outbuf);
- *outsize = ROUNDLEN(len + 1);
- *outbuf = xmalloc(*outsize);
- }
- memcpy(*outbuf, p, len);
- (*outbuf)[len] = '\0';
if (linenum == 1 && p[0] == '#' && p[1] == 'n')
nflag = 1;
return (*outbuf);
@@ -344,7 +338,8 @@ mf_fgets(SPACE *sp, enum e_spflag spflag
struct stat sb;
size_t len;
char dirbuf[PATH_MAX];
- char *p;
+ static char *p;
+ static size_t psize;
int c, fd;
static int firstfile;
@@ -429,13 +424,13 @@ mf_fgets(SPACE *sp, enum e_spflag spflag
* We are here only when infile is open and we still have something
* to read from it.
*
-* Use fgetln so that we can handle essentially infinite input data.
-* Can't use the pointer into the stdio buffer as the process space
-* because the ungetc() can cause it to move.
+* Use getline() so that we can handle essentially infinite input
+* data. The p and psize are static so each invocation gives
+* getline() the same buffer which is expanded as needed.
*/
- p = fgetln(infile, );
- if (ferror(infile))
- error(FATAL, "%s: %s", fname, strerror(errno ? errno : EIO));
+ len = getline(, , infile);
+ if ((ssize_t)len == -1)
+ error(FATAL, "%s: %s", fname, strerror(errno));
if (len != 0 && p[len - 1] == '\n') {
sp->append_newline = 1;
len--;
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: ftp: make use of getline(3)
Hiltjo Posthuma:
> > @@ -75,19 +74,8 @@ cookie_load(void)
> > if (fp == NULL)
> > err(1, "cannot open cookie file %s", cookiefile);
> > date = time(NULL);
> > - lbuf = NULL;
> > - while ((line = fgetln(fp, )) != NULL) {
> > - if (line[len - 1] == '\n') {
> > - line[len - 1] = '\0';
> > - --len;
> > - } else {
> > - if ((lbuf = malloc(len + 1)) == NULL)
> > - err(1, NULL);
> > - memcpy(lbuf, line, len);
> > - lbuf[len] = '\0';
> > - line = lbuf;
> > - }
> > - line[strcspn(line, "\r")] = '\0';
> > + while (getline(, , fp) != -1) {
> > + line[strcspn(line, "\r\n")] = '\0';
> >
>
> getline returns the number of characters read including the delimeter. This
> size could be used to '\0' terminate the string instead of a strcspn() call.
A strcspn() call is already there.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: ftp: make use of getline(3)
On Fri, Jan 29, 2021 at 07:22:11PM +0100, Christian Weisgerber wrote:
> Make use of getline(3) in ftp(1).
>
> Replace fparseln(3) with getline(3). This removes the only use
> of libutil.a(fparseln.o) from the ramdisk.
> Replace a complicated fgetln(3) idiom with the much simpler getline(3).
>
> OK?
>
> Index: distrib/special/ftp/Makefile
> ===
> RCS file: /cvs/src/distrib/special/ftp/Makefile,v
> retrieving revision 1.14
> diff -u -p -r1.14 Makefile
> --- distrib/special/ftp/Makefile 16 May 2019 12:44:17 - 1.14
> +++ distrib/special/ftp/Makefile 29 Jan 2021 18:05:46 -
> @@ -6,7 +6,4 @@ PROG= ftp
> SRCS=fetch.c ftp.c main.c small.c util.c
> .PATH: ${.CURDIR}/../../../usr.bin/ftp
>
> -LDADD+= -lutil
> -DPADD+= ${LIBUTIL}
> -
> .include
> Index: usr.bin/ftp/Makefile
> ===
> RCS file: /cvs/src/usr.bin/ftp/Makefile,v
> retrieving revision 1.34
> diff -u -p -r1.34 Makefile
> --- usr.bin/ftp/Makefile 27 Jan 2021 22:27:41 - 1.34
> +++ usr.bin/ftp/Makefile 29 Jan 2021 17:57:31 -
> @@ -8,8 +8,8 @@ PROG= ftp
> SRCS=cmds.c cmdtab.c complete.c cookie.c domacro.c fetch.c ftp.c \
> list.c main.c ruserpass.c small.c stringlist.c util.c
>
> -LDADD+= -ledit -lcurses -lutil -ltls -lssl -lcrypto
> -DPADD+= ${LIBEDIT} ${LIBCURSES} ${LIBUTIL} ${LIBTLS} ${LIBSSL}
> ${LIBCRYPTO}
> +LDADD+= -ledit -lcurses -ltls -lssl -lcrypto
> +DPADD+= ${LIBEDIT} ${LIBCURSES} ${LIBTLS} ${LIBSSL} ${LIBCRYPTO}
>
> #COPTS+= -Wall -Wconversion -Wstrict-prototypes -Wmissing-prototypes
>
> Index: usr.bin/ftp/cookie.c
> ===
> RCS file: /cvs/src/usr.bin/ftp/cookie.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 cookie.c
> --- usr.bin/ftp/cookie.c 16 May 2019 12:44:17 - 1.9
> +++ usr.bin/ftp/cookie.c 29 Jan 2021 16:07:56 -
> @@ -58,10 +58,9 @@ void
> cookie_load(void)
> {
> field_t field;
> - size_t len;
> time_t date;
> - char*line;
> - char*lbuf;
> + char*line = NULL;
> + size_t linesize = 0;
> char*param;
> const char *estr;
> FILE*fp;
> @@ -75,19 +74,8 @@ cookie_load(void)
> if (fp == NULL)
> err(1, "cannot open cookie file %s", cookiefile);
> date = time(NULL);
> - lbuf = NULL;
> - while ((line = fgetln(fp, )) != NULL) {
> - if (line[len - 1] == '\n') {
> - line[len - 1] = '\0';
> - --len;
> - } else {
> - if ((lbuf = malloc(len + 1)) == NULL)
> - err(1, NULL);
> - memcpy(lbuf, line, len);
> - lbuf[len] = '\0';
> - line = lbuf;
> - }
> - line[strcspn(line, "\r")] = '\0';
> + while (getline(, , fp) != -1) {
> + line[strcspn(line, "\r\n")] = '\0';
>
getline returns the number of characters read including the delimeter. This
size could be used to '\0' terminate the string instead of a strcspn() call.
> line += strspn(line, " \t");
> if ((*line == '#') || (*line == '\0')) {
> @@ -172,7 +160,7 @@ cookie_load(void)
> } else
> TAILQ_INSERT_TAIL(, ck, entry);
> }
> - free(lbuf);
> + free(line);
> fclose(fp);
> }
>
> Index: usr.bin/ftp/fetch.c
> ===
> RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
> retrieving revision 1.199
> diff -u -p -r1.199 fetch.c
> --- usr.bin/ftp/fetch.c 1 Jan 2021 17:39:54 - 1.199
> +++ usr.bin/ftp/fetch.c 29 Jan 2021 17:57:58 -
> @@ -56,7 +56,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #ifndef NOSSL
> @@ -75,7 +74,6 @@ static void aborthttp(int);
> static char hextochar(const char *);
> static char *urldecode(const char *);
> static char *recode_credentials(const char *_userinfo);
> -static char *ftp_readline(FILE *, size_t *);
> static void ftp_close(FILE **, struct tls **, int *);
> static const char *sockerror(struct tls *);
> #ifdef SMALL
> @@ -329,6 +327,7 @@ url_get(const char *origline, const char
> off_t hashbytes;
> const char *errstr;
> ssize_t len, wlen;
> + size_t bufsize;
> char *proxyhost = NULL;
> #ifndef NOSSL
> char *sslpath = NULL, *sslhost = NULL;
> @@ -790,12 +789,13 @@ noslash:
> free(buf);
> #endif /* !NOSSL */
> buf = NULL;
> + bufsize = 0;
>
> if (fflush(fin) == EOF) {
> warnx("Writing HTTP request: %s", sockerror(tls));
> goto cleanup_url_get;
> }
> - if ((buf =
Re: uhidpp(4): logitech hid++ device driver
Hi, I have a bit oldish Logitech M705 mouse, bought around 2010-2011. Regarding the dmesg (on below) I can see it gets attached correctly to uhiddp0 but doesn't report battery levels. Here's the line from dmesg: uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device 2 keyboard "K750" serial xx-xx-xx-xx. And corresponding sysctl values: hw.sensors.uhidpp0.raw0=unknown (battery levels) hw.sensors.uhidpp0.raw1=unknown (battery levels) hw.sensors.uhidpp0.percent0=unknown (battery level) hw.sensors.uhidpp0.percent1=unknown (battery level) Not sure if censoring of serial has any value, though. On Ubuntu battery levels are detected correctly so I could probably take a USB dump with Wireshark and compare the differences. And here's sysctl.sensors & dmesg differences (before <-> after the patch): --- sysctl_before.txt Fri Jan 29 21:31:44 2021 +++ sysctl_after.txtFri Jan 29 21:34:50 2021 @@ -5,39 +5,43 @@ hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:c01774372c2b714a hw.diskcount=1 -hw.sensors.cpu0.temp0=54.00 degC +hw.sensors.cpu0.temp0=50.00 degC hw.sensors.acpibtn0.indicator0=On (lid open) hw.sensors.acpibat0.volt0=11.10 VDC (voltage) hw.sensors.acpibat0.volt1=12.38 VDC (current voltage) hw.sensors.acpibat0.power0=0.00 W (rate) -hw.sensors.acpibat0.watthour0=15.64 Wh (last full capacity) +hw.sensors.acpibat0.watthour0=15.62 Wh (last full capacity) hw.sensors.acpibat0.watthour1=0.78 Wh (warning capacity) hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat0.watthour3=15.62 Wh (remaining capacity), OK hw.sensors.acpibat0.watthour4=23.20 Wh (design capacity) -hw.sensors.acpibat0.raw0=0 (battery idle), OK +hw.sensors.acpibat0.raw0=0 (battery full), OK hw.sensors.acpibat1.volt0=11.10 VDC (voltage) hw.sensors.acpibat1.volt1=12.32 VDC (current voltage) hw.sensors.acpibat1.power0=0.00 W (rate) -hw.sensors.acpibat1.watthour0=16.53 Wh (last full capacity) +hw.sensors.acpibat1.watthour0=16.52 Wh (last full capacity) hw.sensors.acpibat1.watthour1=0.83 Wh (warning capacity) hw.sensors.acpibat1.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat1.watthour3=16.52 Wh (remaining capacity), OK hw.sensors.acpibat1.watthour4=23.20 Wh (design capacity) -hw.sensors.acpibat1.raw0=0 (battery idle), OK +hw.sensors.acpibat1.raw0=0 (battery full), OK hw.sensors.acpiac0.indicator0=On (power supply) -hw.sensors.acpithinkpad0.temp0=55.00 degC -hw.sensors.acpithinkpad0.temp1=55.00 degC -hw.sensors.acpithinkpad0.temp2=55.00 degC -hw.sensors.acpithinkpad0.temp3=55.00 degC -hw.sensors.acpithinkpad0.temp4=55.00 degC -hw.sensors.acpithinkpad0.temp5=55.00 degC -hw.sensors.acpithinkpad0.temp6=55.00 degC -hw.sensors.acpithinkpad0.temp7=55.00 degC -hw.sensors.acpithinkpad0.fan0=4112 RPM +hw.sensors.acpithinkpad0.temp0=51.00 degC +hw.sensors.acpithinkpad0.temp1=51.00 degC +hw.sensors.acpithinkpad0.temp2=51.00 degC +hw.sensors.acpithinkpad0.temp3=51.00 degC +hw.sensors.acpithinkpad0.temp4=51.00 degC +hw.sensors.acpithinkpad0.temp5=51.00 degC +hw.sensors.acpithinkpad0.temp6=51.00 degC +hw.sensors.acpithinkpad0.temp7=51.00 degC +hw.sensors.acpithinkpad0.fan0=3659 RPM hw.sensors.acpithinkpad0.indicator0=Off (port replicator), UNKNOWN -hw.sensors.acpitz0.temp0=55.00 degC (zone temperature) -hw.sensors.pchtemp0.temp0=62.50 degC +hw.sensors.acpitz0.temp0=51.00 degC (zone temperature) +hw.sensors.pchtemp0.temp0=58.00 degC +hw.sensors.uhidpp0.raw0=unknown (battery levels) +hw.sensors.uhidpp0.raw1=unknown (battery levels) +hw.sensors.uhidpp0.percent0=unknown (battery level) +hw.sensors.uhidpp0.percent1=unknown (battery level) hw.cpuspeed=500 hw.setperf=0 hw.vendor=LENOVO @@ -46,7 +50,7 @@ hw.version=ThinkPad X250 hw.serialno=PC031KCD hw.uuid=816b2e2f-d253-cb11-9791-8821c15b5a68 hw.physmem=8277995520 -hw.usermem=8233095168 +hw.usermem=8221360128 hw.ncpufound=2 hw.allowpowerdown=1 hw.perfpolicy=auto And: --- dmesg_before.txt2021-01-29 21:38:10.0 +0200 +++ dmesg_after.txt 2021-01-29 22:03:30.341216215 +0200 @@ -1,7 +1,7 @@ -OpenBSD 6.8-current (GENERIC.MP) #301: Fri Jan 29 02:04:27 MST 2021 - dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP +OpenBSD 6.8-current (GENERIC.MP) #0: Fri Jan 29 21:30:07 EET 2021 +wee...@weezel.lan:/obsd_src/sys/arch/amd64/compile/GENERIC.MP real mem = 8277995520 (7894MB) -avail mem = 8011780096 (7640MB) +avail mem = 8011751424 (7640MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets @@ -18,7 +18,7 @@ acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) -cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.55 MHz, 06-3d-04 +cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.63 MHz, 06-3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36 ,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAI T,DS-
Re: uhidpp(4): logitech hid++ device driver
On Fri, Jan 29, 2021 at 07:23:37PM +0200, Ville Valkonen wrote: > Hello Anton, > > either I failed to use git or then files have changed since the first patch: > $ git apply -p0 --check hid_plusplus.patch > error: patch failed: share/man/man4/Makefile:83 > error: share/man/man4/Makefile: patch does not apply > error: patch failed: share/man/man4/uhidev.4:40 > error: share/man/man4/uhidev.4: patch does not apply > error: patch failed: share/man/man4/usb.4:255 > error: share/man/man4/usb.4: patch does not apply > error: patch failed: sys/arch/amd64/conf/GENERIC:288 > error: sys/arch/amd64/conf/GENERIC: patch does not apply > error: patch failed: sys/dev/usb/uhidev.c:950 > error: sys/dev/usb/uhidev.c: patch does not apply > error: sys/dev/usb/uhidpp.c: already exists in working directory > > Running that on root of src. A quick peek on sys/dev/usb/uhidev.c file > shows that it has been modified on 25th of Jan so I'd guess the patch > needs to be updated. > > Thanks in advance! Been thinking to have a look on that protocol but > since I am no HW hacker I've postponed that for years :) Rebased diff, should apply using either git-apply or patch. diff --git share/man/man4/Makefile share/man/man4/Makefile index 70e62135237..f893825ceb9 100644 --- share/man/man4/Makefile +++ share/man/man4/Makefile @@ -83,8 +83,8 @@ MAN= aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ - uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \ - ujoy.4 uk.4 ukbd.4 \ + uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ + uipaq.4 ujoy.4 uk.4 ukbd.4 ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \ ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \ uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \ diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 index 06911ddef29..aa1efbea710 100644 --- share/man/man4/uhidev.4 +++ share/man/man4/uhidev.4 @@ -40,6 +40,7 @@ .Cd "ucycom* at uhidev?" .Cd "ugold* at uhidev?" .Cd "uhid*at uhidev?" +.Cd "uhidpp* at uhidev?" .Cd "ujoy*at uhidev?" .Cd "ukbd*at uhidev?" .Cd "ums* at uhidev?" @@ -74,6 +75,7 @@ only dispatches data to them based on the report id. .Xr ucycom 4 , .Xr ugold 4 , .Xr uhid 4 , +.Xr uhidpp 4 , .Xr ujoy 4 , .Xr ukbd 4 , .Xr ums 4 , diff --git share/man/man4/uhidpp.4 share/man/man4/uhidpp.4 new file mode 100644 index 000..4c78380c35b --- /dev/null +++ share/man/man4/uhidpp.4 @@ -0,0 +1,48 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2021 Anton Lindqvsit +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate$ +.Dt UHIDPP 4 +.Os +.Sh NAME +.Nm uhidpp +.Nd Logitech HID++ devices +.Sh SYNOPSIS +.Cd "uhidpp* at uhidev?" +.Sh DESCRIPTION +The +.Nm +driver provides support for Logitech HID++ devices. +It exposes a collection of battery sensor values which are made available +through the +.Xr sysctl 8 +interface. +.Sh SEE ALSO +.Xr intro 4 , +.Xr uhidev 4 , +.Xr usb 4 , +.Xr sensorsd 8 , +.Xr sysctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 6.9 . +.Sh AUTHORS +The +.Nm +driver was written by +.An Anton Lindqvist Aq Mt an...@opensd.org . diff --git share/man/man4/usb.4 share/man/man4/usb.4 index 8b9e3ffdc3c..245d01cdef4 100644 --- share/man/man4/usb.4 +++ share/man/man4/usb.4 @@ -255,6 +255,8 @@ TEMPer gold HID thermometer and hygrometer Generic driver for Human Interface Devices .It Xr uhidev 4 Base driver for all Human Interface Devices +.It Xr uhidpp 4 +Logitech HID++ devices .It Xr ujoy 4 USB joysticks/gamecontrollers .It Xr ukbd 4 diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC index ffa1b4a497c..643e6bd0ba1 100644 --- sys/arch/amd64/conf/GENERIC +++ sys/arch/amd64/conf/GENERIC @@ -289,6 +289,7 @@ fido* at uhidev? # FIDO/U2F security key support ujoy* at uhidev? # USB joystick/gamecontroller support upd* at uhidev? # USB Power Devices sensors umstc* at uhidev? # Microsoft Surface Type Cover +uhidpp*at
ftp: make use of getline(3)
Make use of getline(3) in ftp(1).
Replace fparseln(3) with getline(3). This removes the only use
of libutil.a(fparseln.o) from the ramdisk.
Replace a complicated fgetln(3) idiom with the much simpler getline(3).
OK?
Index: distrib/special/ftp/Makefile
===
RCS file: /cvs/src/distrib/special/ftp/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- distrib/special/ftp/Makefile16 May 2019 12:44:17 - 1.14
+++ distrib/special/ftp/Makefile29 Jan 2021 18:05:46 -
@@ -6,7 +6,4 @@ PROG= ftp
SRCS= fetch.c ftp.c main.c small.c util.c
.PATH: ${.CURDIR}/../../../usr.bin/ftp
-LDADD+=-lutil
-DPADD+=${LIBUTIL}
-
.include
Index: usr.bin/ftp/Makefile
===
RCS file: /cvs/src/usr.bin/ftp/Makefile,v
retrieving revision 1.34
diff -u -p -r1.34 Makefile
--- usr.bin/ftp/Makefile27 Jan 2021 22:27:41 - 1.34
+++ usr.bin/ftp/Makefile29 Jan 2021 17:57:31 -
@@ -8,8 +8,8 @@ PROG= ftp
SRCS= cmds.c cmdtab.c complete.c cookie.c domacro.c fetch.c ftp.c \
list.c main.c ruserpass.c small.c stringlist.c util.c
-LDADD+=-ledit -lcurses -lutil -ltls -lssl -lcrypto
-DPADD+=${LIBEDIT} ${LIBCURSES} ${LIBUTIL} ${LIBTLS} ${LIBSSL}
${LIBCRYPTO}
+LDADD+=-ledit -lcurses -ltls -lssl -lcrypto
+DPADD+=${LIBEDIT} ${LIBCURSES} ${LIBTLS} ${LIBSSL} ${LIBCRYPTO}
#COPTS+= -Wall -Wconversion -Wstrict-prototypes -Wmissing-prototypes
Index: usr.bin/ftp/cookie.c
===
RCS file: /cvs/src/usr.bin/ftp/cookie.c,v
retrieving revision 1.9
diff -u -p -r1.9 cookie.c
--- usr.bin/ftp/cookie.c16 May 2019 12:44:17 - 1.9
+++ usr.bin/ftp/cookie.c29 Jan 2021 16:07:56 -
@@ -58,10 +58,9 @@ void
cookie_load(void)
{
field_t field;
- size_t len;
time_t date;
- char*line;
- char*lbuf;
+ char*line = NULL;
+ size_t linesize = 0;
char*param;
const char *estr;
FILE*fp;
@@ -75,19 +74,8 @@ cookie_load(void)
if (fp == NULL)
err(1, "cannot open cookie file %s", cookiefile);
date = time(NULL);
- lbuf = NULL;
- while ((line = fgetln(fp, )) != NULL) {
- if (line[len - 1] == '\n') {
- line[len - 1] = '\0';
- --len;
- } else {
- if ((lbuf = malloc(len + 1)) == NULL)
- err(1, NULL);
- memcpy(lbuf, line, len);
- lbuf[len] = '\0';
- line = lbuf;
- }
- line[strcspn(line, "\r")] = '\0';
+ while (getline(, , fp) != -1) {
+ line[strcspn(line, "\r\n")] = '\0';
line += strspn(line, " \t");
if ((*line == '#') || (*line == '\0')) {
@@ -172,7 +160,7 @@ cookie_load(void)
} else
TAILQ_INSERT_TAIL(, ck, entry);
}
- free(lbuf);
+ free(line);
fclose(fp);
}
Index: usr.bin/ftp/fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.199
diff -u -p -r1.199 fetch.c
--- usr.bin/ftp/fetch.c 1 Jan 2021 17:39:54 - 1.199
+++ usr.bin/ftp/fetch.c 29 Jan 2021 17:57:58 -
@@ -56,7 +56,6 @@
#include
#include
#include
-#include
#include
#ifndef NOSSL
@@ -75,7 +74,6 @@ static void aborthttp(int);
static charhextochar(const char *);
static char*urldecode(const char *);
static char*recode_credentials(const char *_userinfo);
-static char*ftp_readline(FILE *, size_t *);
static voidftp_close(FILE **, struct tls **, int *);
static const char *sockerror(struct tls *);
#ifdef SMALL
@@ -329,6 +327,7 @@ url_get(const char *origline, const char
off_t hashbytes;
const char *errstr;
ssize_t len, wlen;
+ size_t bufsize;
char *proxyhost = NULL;
#ifndef NOSSL
char *sslpath = NULL, *sslhost = NULL;
@@ -790,12 +789,13 @@ noslash:
free(buf);
#endif /* !NOSSL */
buf = NULL;
+ bufsize = 0;
if (fflush(fin) == EOF) {
warnx("Writing HTTP request: %s", sockerror(tls));
goto cleanup_url_get;
}
- if ((buf = ftp_readline(fin, )) == NULL) {
+ if ((len = getline(, , fin)) == -1) {
warnx("Receiving HTTP reply: %s", sockerror(tls));
goto cleanup_url_get;
}
@@ -867,11 +867,10 @@ noslash:
/*
* Read the rest of the header.
*/
- free(buf);
filesize = -1;
for (;;) {
- if ((buf =
Re: unwind(8): open DNSSEC trustanchor late
On Fri, Jan 29, 2021 at 04:52:40PM +0100, Florian Obser wrote: > Re-try to open DNSSEC trust anchor file if /var is not mounted yet. > With this we are able to start unwind before the network is up and > partitions are mounted. OK kn
Re: unwind(8): use SO_BINDANY
On Fri, Jan 29, 2021 at 06:29:52PM +0100, Florian Obser wrote:
> Hold off on this for now, claudio pointed out that I might not be
> supposed to use SO_BINDANY like this.
I checked the code and I think using SO_BINDANY should be OK. Still not
sure if unwind can bind(2) before any interface is configured.
> On Fri, Jan 29, 2021 at 04:51:46PM +0100, Florian Obser wrote:
> > I want to start unwind earlier, around the time when slaacd comes up,
> > the network is not up at that point. Set SO_BINDANY to be able to
> > already bind upd/53 and tcp/53 on localhost.
> > This will make integration with dhclient easier (I hope).
> >
> > diff --git unwind.c unwind.c
> > index 00c600560e4..9bfc4dcf3b8 100644
> > --- unwind.c
> > +++ unwind.c
> > @@ -746,6 +746,9 @@ open_ports(void)
> > if (setsockopt(udp4sock, SOL_SOCKET, SO_SNDBUF, ,
> > sizeof(bsize)) == -1)
> > log_warn("setting SO_SNDBUF on socket");
> > + if (setsockopt(udp4sock, SOL_SOCKET, SO_BINDANY, ,
> > + sizeof(opt)) == -1)
> > + log_warn("setting SO_BINDANY on socket");
> > if (bind(udp4sock, res0->ai_addr, res0->ai_addrlen)
> > == -1) {
> > close(udp4sock);
> > @@ -767,6 +770,9 @@ open_ports(void)
> > if (setsockopt(udp6sock, SOL_SOCKET, SO_SNDBUF, ,
> > sizeof(bsize)) == -1)
> > log_warn("setting SO_SNDBUF on socket");
> > + if (setsockopt(udp6sock, SOL_SOCKET, SO_BINDANY, ,
> > + sizeof(opt)) == -1)
> > + log_warn("setting SO_BINDANY on socket");
> > if (bind(udp6sock, res0->ai_addr, res0->ai_addrlen)
> > == -1) {
> > close(udp6sock);
> > @@ -791,6 +797,9 @@ open_ports(void)
> > if (setsockopt(tcp4sock, SOL_SOCKET, SO_SNDBUF, ,
> > sizeof(bsize)) == -1)
> > log_warn("setting SO_SNDBUF on socket");
> > + if (setsockopt(tcp4sock, SOL_SOCKET, SO_BINDANY, ,
> > + sizeof(opt)) == -1)
> > + log_warn("setting SO_BINDANY on socket");
> > if (bind(tcp4sock, res0->ai_addr, res0->ai_addrlen)
> > == -1) {
> > close(tcp4sock);
> > @@ -817,6 +826,9 @@ open_ports(void)
> > if (setsockopt(tcp6sock, SOL_SOCKET, SO_SNDBUF, ,
> > sizeof(bsize)) == -1)
> > log_warn("setting SO_SNDBUF on socket");
> > + if (setsockopt(tcp6sock, SOL_SOCKET, SO_BINDANY, ,
> > + sizeof(opt)) == -1)
> > + log_warn("setting SO_BINDANY on socket");
> > if (bind(tcp6sock, res0->ai_addr, res0->ai_addrlen)
> > == -1) {
> > close(tcp6sock);
> >
> >
> > --
> > I'm not entirely sure you are real.
> >
>
> --
> I'm not entirely sure you are real.
>
--
:wq Claudio
Re: unwind(8): use SO_BINDANY
Hold off on this for now, claudio pointed out that I might not be
supposed to use SO_BINDANY like this.
On Fri, Jan 29, 2021 at 04:51:46PM +0100, Florian Obser wrote:
> I want to start unwind earlier, around the time when slaacd comes up,
> the network is not up at that point. Set SO_BINDANY to be able to
> already bind upd/53 and tcp/53 on localhost.
> This will make integration with dhclient easier (I hope).
>
> diff --git unwind.c unwind.c
> index 00c600560e4..9bfc4dcf3b8 100644
> --- unwind.c
> +++ unwind.c
> @@ -746,6 +746,9 @@ open_ports(void)
> if (setsockopt(udp4sock, SOL_SOCKET, SO_SNDBUF, ,
> sizeof(bsize)) == -1)
> log_warn("setting SO_SNDBUF on socket");
> + if (setsockopt(udp4sock, SOL_SOCKET, SO_BINDANY, ,
> + sizeof(opt)) == -1)
> + log_warn("setting SO_BINDANY on socket");
> if (bind(udp4sock, res0->ai_addr, res0->ai_addrlen)
> == -1) {
> close(udp4sock);
> @@ -767,6 +770,9 @@ open_ports(void)
> if (setsockopt(udp6sock, SOL_SOCKET, SO_SNDBUF, ,
> sizeof(bsize)) == -1)
> log_warn("setting SO_SNDBUF on socket");
> + if (setsockopt(udp6sock, SOL_SOCKET, SO_BINDANY, ,
> + sizeof(opt)) == -1)
> + log_warn("setting SO_BINDANY on socket");
> if (bind(udp6sock, res0->ai_addr, res0->ai_addrlen)
> == -1) {
> close(udp6sock);
> @@ -791,6 +797,9 @@ open_ports(void)
> if (setsockopt(tcp4sock, SOL_SOCKET, SO_SNDBUF, ,
> sizeof(bsize)) == -1)
> log_warn("setting SO_SNDBUF on socket");
> + if (setsockopt(tcp4sock, SOL_SOCKET, SO_BINDANY, ,
> + sizeof(opt)) == -1)
> + log_warn("setting SO_BINDANY on socket");
> if (bind(tcp4sock, res0->ai_addr, res0->ai_addrlen)
> == -1) {
> close(tcp4sock);
> @@ -817,6 +826,9 @@ open_ports(void)
> if (setsockopt(tcp6sock, SOL_SOCKET, SO_SNDBUF, ,
> sizeof(bsize)) == -1)
> log_warn("setting SO_SNDBUF on socket");
> + if (setsockopt(tcp6sock, SOL_SOCKET, SO_BINDANY, ,
> + sizeof(opt)) == -1)
> + log_warn("setting SO_BINDANY on socket");
> if (bind(tcp6sock, res0->ai_addr, res0->ai_addrlen)
> == -1) {
> close(tcp6sock);
>
>
> --
> I'm not entirely sure you are real.
>
--
I'm not entirely sure you are real.
Re: unwind(8): recheck on libunbound config changes
On Fri, Jan 29, 2021 at 04:48:53PM +0100, Florian Obser wrote: > Some libunbound configuration changes can change the quality of a > resolver so we have to schedule a re-check. OK kn
Re: uhidpp(4): logitech hid++ device driver
Hello Anton, either I failed to use git or then files have changed since the first patch: $ git apply -p0 --check hid_plusplus.patch error: patch failed: share/man/man4/Makefile:83 error: share/man/man4/Makefile: patch does not apply error: patch failed: share/man/man4/uhidev.4:40 error: share/man/man4/uhidev.4: patch does not apply error: patch failed: share/man/man4/usb.4:255 error: share/man/man4/usb.4: patch does not apply error: patch failed: sys/arch/amd64/conf/GENERIC:288 error: sys/arch/amd64/conf/GENERIC: patch does not apply error: patch failed: sys/dev/usb/uhidev.c:950 error: sys/dev/usb/uhidev.c: patch does not apply error: sys/dev/usb/uhidpp.c: already exists in working directory Running that on root of src. A quick peek on sys/dev/usb/uhidev.c file shows that it has been modified on 25th of Jan so I'd guess the patch needs to be updated. Thanks in advance! Been thinking to have a look on that protocol but since I am no HW hacker I've postponed that for years :) -- Kind regards, Ville On Fri, 29 Jan 2021 at 09:21, Anton Lindqvist wrote: > > Ping > > On Fri, Jan 22, 2021 at 08:18:51AM +0100, Anton Lindqvist wrote: > > Hi, > > Here's a new driver for Logitech HID++ devices, currently limited to > > exposing battery sensors. Here's an example using a Logitech M330 mouse: > > > > $ dmesg | grep uhidpp > > uhidpp0 at uhidev1 device 1 mouse "B330/M330/M3" serial c7-2f-a8-33 > > $ sysctl hw.sensors.uhidpp0 > > hw.sensors.uhidpp0.raw0=2 (battery levels) > > hw.sensors.uhidpp0.percent0=70.00% (battery level), OK > > > > The raw0 sensor reflects number of available battery levels, the > > resolution on this device is not great... > > > > Most of the code is derived from the hid-logitech-hidpp Linux driver. > > Some assorted notes: > > > > * In order to communicate with the device inside the attach routine, I > > had to wire up the interrupt handler as this by default is done first > > once the same attach routine has returned. Hence the introduction of > > uhidev_set_intr(). If this is an acceptable approach, this can go in > > as a separate commit. > > > > * I kept using the `return -errno' convention from the Linux driver in > > order to distingush errors from the hardware, which are always > > positive. > > > > I you happen to have a Logitech HID++ device and run into any > > problem(s), please enable UHIDPP_DEBUG and send me the output. > > > > Comments? OK? > > > > diff --git share/man/man4/Makefile share/man/man4/Makefile > > index 02af7a47a44..74a4e17d7dc 100644 > > --- share/man/man4/Makefile > > +++ share/man/man4/Makefile > > @@ -83,8 +83,8 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > > txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ > > ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > > udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ > > - uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \ > > - uk.4 ukbd.4 \ > > + uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ > > + uipaq.4 uk.4 ukbd.4 \ > > ukphy.4 ulpt.4 umass.4 umb.4 umbg.4 umcs.4 umct.4 umidi.4 umodem.4 \ > > ums.4 umsm.4 umstc.4 umt.4 unix.4 uonerng.4 uow.4 uoaklux.4 uoakrh.4 \ > > uoakv.4 upd.4 upgt.4 upl.4 uplcom.4 ural.4 ure.4 url.4 urlphy.4 \ > > diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 > > index f0a6776a27b..d264935a65c 100644 > > --- share/man/man4/uhidev.4 > > +++ share/man/man4/uhidev.4 > > @@ -40,6 +40,7 @@ > > .Cd "ucycom* at uhidev?" > > .Cd "ugold* at uhidev?" > > .Cd "uhid*at uhidev?" > > +.Cd "uhidpp* at uhidev?" > > .Cd "ukbd*at uhidev?" > > .Cd "ums* at uhidev?" > > .Cd "umstc* at uhidev?" > > @@ -73,6 +74,7 @@ only dispatches data to them based on the report id. > > .Xr ucycom 4 , > > .Xr ugold 4 , > > .Xr uhid 4 , > > +.Xr uhidpp 4 , > > .Xr ukbd 4 , > > .Xr ums 4 , > > .Xr umstc 4 , > > diff --git share/man/man4/uhidpp.4 share/man/man4/uhidpp.4 > > new file mode 100644 > > index 000..4c78380c35b > > --- /dev/null > > +++ share/man/man4/uhidpp.4 > > @@ -0,0 +1,48 @@ > > +.\" $OpenBSD$ > > +.\" > > +.\" Copyright (c) 2021 Anton Lindqvsit > > +.\" > > +.\" Permission to use, copy, modify, and distribute this software for any > > +.\" purpose with or without fee is hereby granted, provided that the above > > +.\" copyright notice and this permission notice appear in all copies. > > +.\" > > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL > > WARRANTIES > > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > > +.\" OR IN CONNECTION
IPsec IPv6 Path MTU discovery
Hi,
This fixes path MTU discovery for ESP tunneled in IPv6. In IPv6
we always want short TCP segments or fragments encapsulated in ESP
instead off fragmented ESP packets.
ok?
bluhm
Index: netinet/ip_output.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.361
diff -u -p -r1.361 ip_output.c
--- netinet/ip_output.c 16 Jan 2021 07:58:12 - 1.361
+++ netinet/ip_output.c 29 Jan 2021 16:05:32 -
@@ -625,6 +625,9 @@ ip_output_ipsec_send(struct tdb *tdb, st
m_freem(m);
return EMSGSIZE;
}
+ /* propagate IP_DF for v4-over-v6 */
+ if (ip_mtudisc && ip->ip_off & htons(IP_DF))
+ SET(m->m_pkthdr.csum_flags, M_IPV6_DF_OUT);
/*
* Clear these -- they'll be set in the recursive invocation
Index: netinet6/ip6_output.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/ip6_output.c,v
retrieving revision 1.249
diff -u -p -r1.249 ip6_output.c
--- netinet6/ip6_output.c 11 Jan 2021 13:28:54 - 1.249
+++ netinet6/ip6_output.c 28 Jan 2021 18:53:24 -
@@ -681,6 +681,10 @@ reroute:
else
dontfrag = 0;
if (dontfrag && tlen > ifp->if_mtu) { /* case 2-b */
+#ifdef IPSEC
+ if (ip_mtudisc)
+ ipsec_adjust_mtu(m, mtu);
+#endif
error = EMSGSIZE;
goto bad;
}
@@ -2854,6 +2858,9 @@ ip6_output_ipsec_send(struct tdb *tdb, s
m_freem(m);
return EMSGSIZE;
}
+ /* propagate don't fragment for v6-over-v6 */
+ if (ip_mtudisc)
+ SET(m->m_pkthdr.csum_flags, M_IPV6_DF_OUT);
/*
* Clear these -- they'll be set in the recursive invocation
Re: rc(8): start unwind earlier
On Fri, Jan 29, 2021 at 04:56:47PM +0100, Antoine Jacoutot wrote: > On Fri, Jan 29, 2021 at 04:53:34PM +0100, Florian Obser wrote: > > Start unwind earlier. > > > > OK? > > > > diff --git rc rc > > index 94465add54f..7b5f835f0af 100644 > > --- rc > > +++ rc > > @@ -442,6 +442,7 @@ fill_baddynamic tcp > > sysctl_conf > > > > start_daemon slaacd >/dev/null 2>&1 > > +start_daemon unwind >/dev/null 2>&1 > > you could do it all in 1 line :-) > start_daemon slaacd unwind >/dev/null 2>&1 thanks, fixed in my tree. > > > > > echo 'starting network' > > > > @@ -454,8 +455,6 @@ sh /etc/netstart > > mount -s /usr >/dev/null 2>&1 > > mount -s /var >/dev/null 2>&1 > > > > -start_daemon unwind >/dev/null 2>&1 > > - > > # Load pf rules and bring up pfsync interface. > > if [[ $pf != NO ]]; then > > if [[ -f /etc/pf.conf ]]; then > > > > > > -- > > I'm not entirely sure you are real. > > > > -- > Antoine > -- I'm not entirely sure you are real.
Re: rc(8): start unwind earlier
On Fri, Jan 29, 2021 at 04:53:34PM +0100, Florian Obser wrote: > Start unwind earlier. > > OK? > > diff --git rc rc > index 94465add54f..7b5f835f0af 100644 > --- rc > +++ rc > @@ -442,6 +442,7 @@ fill_baddynamic tcp > sysctl_conf > > start_daemon slaacd >/dev/null 2>&1 > +start_daemon unwind >/dev/null 2>&1 you could do it all in 1 line :-) start_daemon slaacd unwind >/dev/null 2>&1 > > echo 'starting network' > > @@ -454,8 +455,6 @@ sh /etc/netstart > mount -s /usr >/dev/null 2>&1 > mount -s /var >/dev/null 2>&1 > > -start_daemon unwind >/dev/null 2>&1 > - > # Load pf rules and bring up pfsync interface. > if [[ $pf != NO ]]; then > if [[ -f /etc/pf.conf ]]; then > > > -- > I'm not entirely sure you are real. > -- Antoine
rc(8): start unwind earlier
Start unwind earlier. OK? diff --git rc rc index 94465add54f..7b5f835f0af 100644 --- rc +++ rc @@ -442,6 +442,7 @@ fill_baddynamic tcp sysctl_conf start_daemon slaacd >/dev/null 2>&1 +start_daemon unwind >/dev/null 2>&1 echo 'starting network' @@ -454,8 +455,6 @@ sh /etc/netstart mount -s /usr >/dev/null 2>&1 mount -s /var >/dev/null 2>&1 -start_daemon unwind >/dev/null 2>&1 - # Load pf rules and bring up pfsync interface. if [[ $pf != NO ]]; then if [[ -f /etc/pf.conf ]]; then -- I'm not entirely sure you are real.
unwind(8): use SO_BINDANY
I want to start unwind earlier, around the time when slaacd comes up,
the network is not up at that point. Set SO_BINDANY to be able to
already bind upd/53 and tcp/53 on localhost.
This will make integration with dhclient easier (I hope).
diff --git unwind.c unwind.c
index 00c600560e4..9bfc4dcf3b8 100644
--- unwind.c
+++ unwind.c
@@ -746,6 +746,9 @@ open_ports(void)
if (setsockopt(udp4sock, SOL_SOCKET, SO_SNDBUF, ,
sizeof(bsize)) == -1)
log_warn("setting SO_SNDBUF on socket");
+ if (setsockopt(udp4sock, SOL_SOCKET, SO_BINDANY, ,
+ sizeof(opt)) == -1)
+ log_warn("setting SO_BINDANY on socket");
if (bind(udp4sock, res0->ai_addr, res0->ai_addrlen)
== -1) {
close(udp4sock);
@@ -767,6 +770,9 @@ open_ports(void)
if (setsockopt(udp6sock, SOL_SOCKET, SO_SNDBUF, ,
sizeof(bsize)) == -1)
log_warn("setting SO_SNDBUF on socket");
+ if (setsockopt(udp6sock, SOL_SOCKET, SO_BINDANY, ,
+ sizeof(opt)) == -1)
+ log_warn("setting SO_BINDANY on socket");
if (bind(udp6sock, res0->ai_addr, res0->ai_addrlen)
== -1) {
close(udp6sock);
@@ -791,6 +797,9 @@ open_ports(void)
if (setsockopt(tcp4sock, SOL_SOCKET, SO_SNDBUF, ,
sizeof(bsize)) == -1)
log_warn("setting SO_SNDBUF on socket");
+ if (setsockopt(tcp4sock, SOL_SOCKET, SO_BINDANY, ,
+ sizeof(opt)) == -1)
+ log_warn("setting SO_BINDANY on socket");
if (bind(tcp4sock, res0->ai_addr, res0->ai_addrlen)
== -1) {
close(tcp4sock);
@@ -817,6 +826,9 @@ open_ports(void)
if (setsockopt(tcp6sock, SOL_SOCKET, SO_SNDBUF, ,
sizeof(bsize)) == -1)
log_warn("setting SO_SNDBUF on socket");
+ if (setsockopt(tcp6sock, SOL_SOCKET, SO_BINDANY, ,
+ sizeof(opt)) == -1)
+ log_warn("setting SO_BINDANY on socket");
if (bind(tcp6sock, res0->ai_addr, res0->ai_addrlen)
== -1) {
close(tcp6sock);
--
I'm not entirely sure you are real.
unwind(8): recheck on libunbound config changes
Some libunbound configuration changes can change the quality of a
resolver so we have to schedule a re-check.
OK?
diff --git resolver.c resolver.c
index feeb6c2f27a..006632e0303 100644
--- resolver.c
+++ resolver.c
@@ -175,7 +175,7 @@ void replace_forwarders(struct
uw_forwarder_head *,
voidresolver_ref(struct uw_resolver *);
voidresolver_unref(struct uw_resolver *);
int resolver_cmp(const void *, const void *);
-voidrestart_ub_resolvers(void);
+voidrestart_ub_resolvers(int);
voidshow_status(pid_t);
voidshow_autoconf(pid_t);
voidshow_mem(pid_t);
@@ -501,7 +501,7 @@ resolver_dispatch_frontend(int fd, short event, void *bula)
memcpy(, imsg.data, sizeof(verbose));
if (log_getdebug() && (log_getverbose() & OPT_VERBOSE3)
!= (verbose & OPT_VERBOSE3))
- restart_ub_resolvers();
+ restart_ub_resolvers(0);
log_setverbose(verbose);
break;
case IMSG_QUERY:
@@ -545,7 +545,7 @@ resolver_dispatch_frontend(int fd, short event, void *bula)
break;
case IMSG_NEW_TAS_DONE:
if (merge_tas(_trust_anchors, _anchors))
- restart_ub_resolvers();
+ restart_ub_resolvers(1);
break;
case IMSG_NETWORK_CHANGED:
clock_gettime(CLOCK_MONOTONIC, _network_change);
@@ -577,7 +577,7 @@ resolver_dispatch_frontend(int fd, short event, void *bula)
sizeof(new_available_afs));
if (new_available_afs != available_afs) {
available_afs = new_available_afs;
- restart_ub_resolvers();
+ restart_ub_resolvers(1);
}
break;
default:
@@ -1754,14 +1754,20 @@ resolver_cmp(const void *_a, const void *_b)
}
void
-restart_ub_resolvers(void)
+restart_ub_resolvers(int recheck)
{
- int i;
+ int i;
+ enum uw_resolver_state state;
- for (i = 0; i < UW_RES_NONE; i++)
- if (i != UW_RES_ASR)
- new_resolver(i, resolvers[i] != NULL ?
- resolvers[i]->state : UNKNOWN);
+ for (i = 0; i < UW_RES_NONE; i++) {
+ if (i == UW_RES_ASR)
+ continue;
+ if (recheck || resolvers[i] == NULL)
+ state = UNKNOWN;
+ else
+ state = resolvers[i]->state;
+ new_resolver(i, state);
+ }
}
void
--
I'm not entirely sure you are real.
Re: sndiod: Move controls out of the device structure, please test & review
On Fri, Jan 29, 2021 at 12:42:37PM +0100, Alexandre Ratchov wrote:
> Moving to a global server-wide controls list is necessary to expose
> controls that are not associated to a particular device (ex. a device
> selector).
>
> The current hack to use the device-side sioctl_desc->addr variable as
> client-side key can't work anymore. So, we use a unique dynamically
> allocated ctl->addr key; this is which much cleaner. A new "scope"
> enum (with two "void *" arguments) is used to determine what the
> control does control. This adds a lot of flexibility and allows to
> easily add new control types that are not associated to devices.
>
> The diff touches many parts of the code and is quite big. Please test
> and report regressions.
>
Thanks for the feedback, new diff below. It fixes a server crash when
a client issues an invalid request.
Index: dev.c
===
RCS file: /cvs/src/usr.bin/sndiod/dev.c,v
retrieving revision 1.89
diff -u -p -u -p -r1.89 dev.c
--- dev.c 29 Jan 2021 11:38:23 - 1.89
+++ dev.c 29 Jan 2021 15:15:38 -
@@ -106,6 +106,7 @@ struct slotops zomb_slotops = {
zomb_exit
};
+struct ctl *ctl_list = NULL;
struct dev *dev_list = NULL;
unsigned int dev_sndnum = 0;
@@ -370,12 +371,14 @@ dev_midi_master(struct dev *d)
master = d->master;
else {
master = 0;
- for (c = d->ctl_list; c != NULL; c = c->next) {
+ for (c = ctl_list; c != NULL; c = c->next) {
if (c->type != CTL_NUM ||
- strcmp(c->group, "") != 0 ||
+ strcmp(c->group, d->name) != 0 ||
strcmp(c->node0.name, "output") != 0 ||
strcmp(c->func, "level") != 0)
continue;
+ if (c->u.any.arg0 != d)
+ continue;
v = (c->curval * 127 + c->maxval / 2) / c->maxval;
if (master < v)
master = v;
@@ -465,7 +468,7 @@ dev_midi_omsg(void *arg, unsigned char *
slot_array[chan].opt->dev != d)
return;
slot_setvol(slot_array + chan, msg[2]);
- dev_onval(d, CTLADDR_SLOT_LEVEL(chan), msg[2]);
+ ctl_onval(CTL_SLOT_LEVEL, slot_array + chan, NULL, msg[2]);
return;
}
x = (struct sysex *)msg;
@@ -479,7 +482,7 @@ dev_midi_omsg(void *arg, unsigned char *
if (len == SYSEX_SIZE(master)) {
dev_master(d, x->u.master.coarse);
if (d->master_enabled) {
- dev_onval(d, CTLADDR_MASTER,
+ ctl_onval(CTL_DEV_MASTER, d, NULL,
x->u.master.coarse);
}
}
@@ -1005,14 +1008,16 @@ dev_master(struct dev *d, unsigned int m
if (d->mode & MODE_PLAY)
dev_mix_adjvol(d);
} else {
- for (c = d->ctl_list; c != NULL; c = c->next) {
+ for (c = ctl_list; c != NULL; c = c->next) {
+ if (c->scope != CTL_HW || c->u.hw.dev != d)
+ continue;
if (c->type != CTL_NUM ||
- strcmp(c->group, "") != 0 ||
+ strcmp(c->group, d->name) != 0 ||
strcmp(c->node0.name, "output") != 0 ||
strcmp(c->func, "level") != 0)
continue;
v = (master * c->maxval + 64) / 127;
- dev_setctl(d, c->addr, v);
+ ctl_setval(c, v);
}
}
}
@@ -1070,7 +1075,7 @@ dev_new(char *path, struct aparams *par,
d->master = MIDI_MAXCTL;
d->mtc.origin = 0;
d->tstate = MMC_STOP;
- d->ctl_list = NULL;
+ snprintf(d->name, CTL_NAMEMAX, "%u", d->num);
d->next = dev_list;
dev_list = d;
return d;
@@ -1208,10 +1213,8 @@ dev_allocbufs(struct dev *d)
int
dev_open(struct dev *d)
{
- int i;
char name[CTL_NAMEMAX];
struct dev_alt *a;
- struct slot *s;
d->master_enabled = 0;
d->mode = d->reqmode;
@@ -1235,23 +1238,12 @@ dev_open(struct dev *d)
if (!dev_allocbufs(d))
return 0;
- for (i = 0, s = slot_array; i < DEV_NSLOT; i++, s++) {
- if (s->opt == NULL || s->opt->dev != d || s->name[0] == 0)
- continue;
- slot_ctlname(s, name, CTL_NAMEMAX);
- dev_addctl(d, "app", CTL_NUM,
- CTLADDR_SLOT_LEVEL(i),
- name, -1, "level",
-
Re: execve -1 errno 12 Cannot allocate memory
> Date: Fri, 29 Jan 2021 09:48:42 -0500 > From: Philippe Meunier > > Philippe Meunier wrote: > >Is there some kind of limitation on the size of an ELF executable that can > >be executed on i386? I mean, in addition to the limits in /etc/login.conf? > > When using readelf(1) on the chrome executable from > chromium-81.0.4044.138.tgz from OpenBSD 6.7-release i386 packages, I get: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf > Al > [...] > [15] .text PROGBITS0230d000 230d000 7bda799 00 AX 0 0 > 64 > > 7bda799 is 129869721 which is 123.8 MB. > > On the chrome executable from chromium-85.0.4183.121.tgz from OpenBSD > 6.8-release i386 packages, I get: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf > Al > [...] > [15] .text PROGBITS02412c00 2411c00 83b048b 00 AX 0 0 > 64 > > 83b048b is 138085515 which is 131.7 MB. > > Is there somewhere a 128 MB limit for ELF sections on i386, or something > along those lines? sys/arch/i386/include/vmparam.h has: #define MAXTSIZ (128*1024*1024) /* max text size */
Re: execve -1 errno 12 Cannot allocate memory
On Fri, Jan 29, 2021 at 09:48:42AM -0500, Philippe Meunier wrote: > Philippe Meunier wrote: > >Is there some kind of limitation on the size of an ELF executable that can > >be executed on i386? I mean, in addition to the limits in /etc/login.conf? > > When using readelf(1) on the chrome executable from > chromium-81.0.4044.138.tgz from OpenBSD 6.7-release i386 packages, I get: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf > Al > [...] > [15] .text PROGBITS0230d000 230d000 7bda799 00 AX 0 0 > 64 > > 7bda799 is 129869721 which is 123.8 MB. > > On the chrome executable from chromium-85.0.4183.121.tgz from OpenBSD > 6.8-release i386 packages, I get: > > Section Headers: > [Nr] Name TypeAddr OffSize ES Flg Lk Inf > Al > [...] > [15] .text PROGBITS02412c00 2411c00 83b048b 00 AX 0 0 > 64 > > 83b048b is 138085515 which is 131.7 MB. > > Is there somewhere a 128 MB limit for ELF sections on i386, or something > along those lines? > > Philippe MAXTSIZ is 128 MB on i386 see sys/arch/i386/include/vmparam.h
Re: execve -1 errno 12 Cannot allocate memory
Philippe Meunier wrote: >Is there some kind of limitation on the size of an ELF executable that can >be executed on i386? I mean, in addition to the limits in /etc/login.conf? When using readelf(1) on the chrome executable from chromium-81.0.4044.138.tgz from OpenBSD 6.7-release i386 packages, I get: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [...] [15] .text PROGBITS0230d000 230d000 7bda799 00 AX 0 0 64 7bda799 is 129869721 which is 123.8 MB. On the chrome executable from chromium-85.0.4183.121.tgz from OpenBSD 6.8-release i386 packages, I get: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [...] [15] .text PROGBITS02412c00 2411c00 83b048b 00 AX 0 0 64 83b048b is 138085515 which is 131.7 MB. Is there somewhere a 128 MB limit for ELF sections on i386, or something along those lines? Philippe
execve -1 errno 12 Cannot allocate memory
Hello, Is there some kind of limitation on the size of an ELF executable that can be executed on i386? I mean, in addition to the limits in /etc/login.conf? Here's why I'm asking: $ uname -a OpenBSD t43.my.domain 6.8 GENERIC#4 i386 $ cat /etc/login.conf [...] default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\ :umask=022:\ :datasize-max=infinity:\ :datasize-cur=infinity:\ :memoryuse-max=infinity:\ :memoryuse-cur=infinity:\ :memorylocked-max=infinity:\ :memorylocked-cur=infinity:\ :vmemoryuse-max=infinity:\ :vmemoryuse-cur=infinity:\ :maxproc-max=256:\ :maxproc-cur=128:\ :openfiles-max=1024:\ :openfiles-cur=512:\ :stacksize-max=infinity:\ :stacksize-cur=infinity:\ :localcipher=blowfish,a:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: [...] (/etc/login.conf is that way just for testing purposes...) $ ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 3145728 stack(kbytes)32768 lockedmem(kbytes)unlimited memory(kbytes) unlimited nofiles(descriptors) 512 processes128 $ /usr/local/chrome/chrome /bin/ksh: /usr/local/chrome/chrome: Cannot allocate memory $ ktrace -d -i /usr/local/chrome/chrome ktrace: exec of '/usr/local/chrome/chrome' failed: Cannot allocate memory $ kdump -X 23578 ktrace RET ktrace 0 23578 ktrace CALL execve(0xcf7ebfc1,0xcf7ebf10,0xcf7ebf18) 23578 ktrace NAMI "/usr/local/chrome/chrome" 23578 ktrace RET execve -1 errno 12 Cannot allocate memory 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL write(2,0xcf7eb818,0x8) 23578 ktrace GIO fd 2 wrote 8 bytes : 6b 74 72 61 63 65 3a 20 ktrace: 23578 ktrace RET write 8 23578 ktrace CALL write(2,0xcf7eb838,0x29) 23578 ktrace GIO fd 2 wrote 41 bytes : 65 78 65 63 20 6f 66 20 27 2f 75 73 72 2f 6c 6f exec of '/usr/lo 0010: 63 61 6c 2f 63 68 72 6f 6d 65 2f 63 68 72 6f 6d cal/chrome/chrom 0020: 65 27 20 66 61 69 6c 65 64 e' failed 23578 ktrace RET write 41/0x29 23578 ktrace CALL write(2,0xcf7eb820,0x2) 23578 ktrace GIO fd 2 wrote 2 bytes : 3a 20: 23578 ktrace RET write 2 23578 ktrace CALL write(2,0xcf7eb818,0x17) 23578 ktrace GIO fd 2 wrote 23 bytes : 43 61 6e 6e 6f 74 20 61 6c 6c 6f 63 61 74 65 20 Cannot allocate 0010: 6d 65 6d 6f 72 79 0a memory. 23578 ktrace RET write 23/0x17 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x3) 23578 ktrace RET mprotect 0 23578 ktrace CALL mprotect(0x58b08000,0x1000,0x1) 23578 ktrace RET mprotect 0 23578 ktrace CALL munmap(0x58b08000,0x1000) 23578 ktrace RET munmap 0 23578 ktrace CALL exit(1) $ file /usr/local/chrome/chrome /usr/local/chrome/chrome: ELF 32-bit LSB shared object, Intel 80386, version 1 $ ls -l /usr/local/chrome/chrome -rwxr-xr-x 1 root bin 179649140 Oct 2 12:45 /usr/local/chrome/chrome It looks like execve simply refuses to execute that file but I cannot find which limit is being hit. The next biggest executable I can find on my system is /usr/bin/cc which is 62177052 bytes on the hard disk, and I have no problem executing it. This is using OpenBSD 6.8-release (with syspatches applied; dmesg below). I just upgraded from 6.7-release which is when I found out about this problem with chrome. On 6.7 I had datasize-max, datasize-cur, and memoryuse set to 1024M in /etc/login.conf and never had any problem using chrome. Any idea what the problem might be? Best, Philippe OpenBSD 6.8 (GENERIC) #4: Mon Jan 11 10:34:49 MST 2021 r...@syspatch-68-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 1063600128 (1014MB) avail mem = 1027911680 (980MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 05/29/07, BIOS32 rev. 0 @ 0xfd740, SMBIOS rev. 2.33 @ 0xe0010 (64 entries) bios0: vendor IBM version "70ET69WW (1.29 )" date 05/29/2007 bios0: IBM 1875E5U acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG BOOT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB3(S3) USB7(S3) AC9M(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT
Re: have pf_route bail out if it resolves a route with RTF_LOCAL set
On Fri, Jan 29, 2021 at 10:53:09AM +1000, David Gwynne wrote: > > Are you sure that it does not break any use case? I have seen so > > much strange stuff. What is the advantage? > > The current behaviour is lucky at best, and quirky at worst. Usually I > would agree with you that breaking stuff isn't great, even if it's > wrong, but while I'm changing how route-to etc works I think it's > a good chance to clean up some of these edge cases. I have been developping products based on pf edge cases for 15 years. I don't know which dragons are in our codebase. This should not prevent improvements in OpenBSD. I am just asking not to remove anything just because we currently don't know, how it can be used. Changing syntax like address@interface can easily be adpted. Slight semantic changes may cause debugging sessions on productive customer systems. And then we might need a quick new solution for a previously existing feature. So please be careful. bluhm
Improving the syspatch(8) and sysupgrade(8) test for the invoking user's privileges
Hi,
I noticed the syspatch(8) and sysupgrade(8) ksh scripts test if the
invoking user has the right privileges i.e. (($(id -u) != 0))
The test for the effective user ID number can be bypassed in
syspatch(8) and sysupgrade(8) by sh e.g.
$ id -u
1000
$ sh /usr/sbin/sysupgrade -s
/usr/sbin/sysupgrade[90]: 1000: not found
install: /home/_sysupgrade: Permission denied
$ sh /usr/sbin/syspatch -r
[snip]
/usr/sbin/syspatch[280]: 1000: not found
Reverting patch 012_carp
[snip]
The syspatch(8) and sysupgrade(8) test for the EUID number could be
improved by adding "set +o sh" (see netstart(8)) or by using the
"[[expression]]" test (see sysmerge(8)) or "[expression]" test (see
rcctl(8)) instead of "((expression))" e.g. [ "$(id -u)" -ne 0 ]
Moreover, other scripts could benefit from the addition of the
above-mentioned test for the EUID number e.g. daily(8), weekly(8), and
monthly(8) which are intended to run as root e.g.
$ id -u
1000
$ sh /etc/weekly
install: /var/log/INS@FJvExvWnUh: Permission denied
[snip]
[1] http://man.openbsd.org/ksh#__
[2] http://man.openbsd.org/ksh#test~2
[3] http://man.openbsd.org/ksh#Strict_Bourne_shell_mode
Index: syspatch.sh
===
RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
retrieving revision 1.167
diff -u -p -r1.167 syspatch.sh
--- syspatch.sh 7 Dec 2020 21:19:28 - 1.167
+++ syspatch.sh 29 Jan 2021 08:04:08 -
@@ -276,7 +276,7 @@ set -A _KERNV -- $(sysctl -n kern.versio
((${#_KERNV[*]} > 1)) && err "Unsupported release: ${_KERNV[0]}${_KERNV[1]}"
[[ $@ == @(|-[[:alpha:]]) ]] || usage; [[ $@ == @(|-(c|R|r)) ]] &&
- (($(id -u) != 0)) && err "need root privileges"
+ [ "$(id -u)" -ne 0 ] && err "need root privileges"
[[ $@ == @(|-(R|r)) ]] && pgrep -qxf '/bin/ksh .*reorder_kernel' &&
err "cannot apply patches while reorder_kernel is running"
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.44
diff -u -p -r1.44 sysupgrade.sh
--- sysupgrade.sh 22 Oct 2020 07:19:42 - 1.44
+++ sysupgrade.sh 29 Jan 2021 07:53:31 -
@@ -89,7 +89,7 @@ while getopts fknrs arg; do
esac
done
-(($(id -u) != 0)) && err "need root privileges"
+[ "$(id -u)" -ne 0 ] && err "need root privileges"
if $RELEASE && $SNAP; then
usage
Index: daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.95
diff -u -p -r1.95 daily
--- daily 20 Oct 2020 22:42:29 - 1.95
+++ daily 29 Jan 2021 08:08:44 -
@@ -9,6 +9,7 @@ umask 022
PARTOUT=/var/log/daily.part
MAINOUT=/var/log/daily.out
+[ "$(id -u)" -ne 0 ] && echo "${0##*/}: need root privileges" && exit 1
install -o 0 -g 0 -m 600/dev/null $PARTOUT
install -o 0 -g 0 -m 600 -b /dev/null $MAINOUT
sndiod: Move controls out of the device structure, please test & review
Moving to a global server-wide controls list is necessary to expose
controls that are not associated to a particular device (ex. a device
selector).
The current hack to use the device-side sioctl_desc->addr variable as
client-side key can't work anymore. So, we use a unique dynamically
allocated ctl->addr key; this is which much cleaner. A new "scope"
enum (with two "void *" arguments) is used to determine what the
control does control. This adds a lot of flexibility and allows to
easily add new control types that are not associated to devices.
The diff touches many parts of the code and is quite big. Please test
and report regressions.
Besides that no behavior change.
OK?
Index: dev.c
===
RCS file: /cvs/src/usr.bin/sndiod/dev.c,v
retrieving revision 1.89
diff -u -p -u -p -r1.89 dev.c
--- dev.c 29 Jan 2021 11:38:23 - 1.89
+++ dev.c 29 Jan 2021 11:39:08 -
@@ -106,6 +106,7 @@ struct slotops zomb_slotops = {
zomb_exit
};
+struct ctl *ctl_list = NULL;
struct dev *dev_list = NULL;
unsigned int dev_sndnum = 0;
@@ -370,12 +371,14 @@ dev_midi_master(struct dev *d)
master = d->master;
else {
master = 0;
- for (c = d->ctl_list; c != NULL; c = c->next) {
+ for (c = ctl_list; c != NULL; c = c->next) {
if (c->type != CTL_NUM ||
- strcmp(c->group, "") != 0 ||
+ strcmp(c->group, d->name) != 0 ||
strcmp(c->node0.name, "output") != 0 ||
strcmp(c->func, "level") != 0)
continue;
+ if (c->u.any.arg0 != d)
+ continue;
v = (c->curval * 127 + c->maxval / 2) / c->maxval;
if (master < v)
master = v;
@@ -465,7 +468,7 @@ dev_midi_omsg(void *arg, unsigned char *
slot_array[chan].opt->dev != d)
return;
slot_setvol(slot_array + chan, msg[2]);
- dev_onval(d, CTLADDR_SLOT_LEVEL(chan), msg[2]);
+ ctl_onval(CTL_SLOT_LEVEL, slot_array + chan, NULL, msg[2]);
return;
}
x = (struct sysex *)msg;
@@ -479,7 +482,7 @@ dev_midi_omsg(void *arg, unsigned char *
if (len == SYSEX_SIZE(master)) {
dev_master(d, x->u.master.coarse);
if (d->master_enabled) {
- dev_onval(d, CTLADDR_MASTER,
+ ctl_onval(CTL_DEV_MASTER, d, NULL,
x->u.master.coarse);
}
}
@@ -1005,14 +1008,16 @@ dev_master(struct dev *d, unsigned int m
if (d->mode & MODE_PLAY)
dev_mix_adjvol(d);
} else {
- for (c = d->ctl_list; c != NULL; c = c->next) {
+ for (c = ctl_list; c != NULL; c = c->next) {
+ if (c->scope != CTL_HW || c->u.hw.dev != d)
+ continue;
if (c->type != CTL_NUM ||
- strcmp(c->group, "") != 0 ||
+ strcmp(c->group, d->name) != 0 ||
strcmp(c->node0.name, "output") != 0 ||
strcmp(c->func, "level") != 0)
continue;
v = (master * c->maxval + 64) / 127;
- dev_setctl(d, c->addr, v);
+ ctl_setval(c, v);
}
}
}
@@ -1070,7 +1075,7 @@ dev_new(char *path, struct aparams *par,
d->master = MIDI_MAXCTL;
d->mtc.origin = 0;
d->tstate = MMC_STOP;
- d->ctl_list = NULL;
+ snprintf(d->name, CTL_NAMEMAX, "%u", d->num);
d->next = dev_list;
dev_list = d;
return d;
@@ -1208,10 +1213,8 @@ dev_allocbufs(struct dev *d)
int
dev_open(struct dev *d)
{
- int i;
char name[CTL_NAMEMAX];
struct dev_alt *a;
- struct slot *s;
d->master_enabled = 0;
d->mode = d->reqmode;
@@ -1235,23 +1238,12 @@ dev_open(struct dev *d)
if (!dev_allocbufs(d))
return 0;
- for (i = 0, s = slot_array; i < DEV_NSLOT; i++, s++) {
- if (s->opt == NULL || s->opt->dev != d || s->name[0] == 0)
- continue;
- slot_ctlname(s, name, CTL_NAMEMAX);
- dev_addctl(d, "app", CTL_NUM,
- CTLADDR_SLOT_LEVEL(i),
- name, -1, "level",
- NULL, -1, 127, s->vol);
- }
-
/* if there are multiple alt devs, add server.device knob */
if (d->alt_list->next != NULL) {
npppd(8)/pppac(4): remove dummy TUNSIFMODE ioctl(2) call
Since OpenBSD 6.7 npppd(8) can't work over tun(4) anymore. I propose to
remove dummy TUNSIFMODE ioctl(2) call.
Index: sys/net/if_pppx.c
===
RCS file: /cvs/src/sys/net/if_pppx.c,v
retrieving revision 1.106
diff -u -p -r1.106 if_pppx.c
--- sys/net/if_pppx.c 25 Dec 2020 12:59:53 - 1.106
+++ sys/net/if_pppx.c 29 Jan 2021 11:10:40 -
@@ -920,12 +920,6 @@ pppx_if_ioctl(struct ifnet *ifp, u_long
RBT_GENERATE(pppx_ifs, pppx_if, pxi_entry, pppx_if_cmp);
/*
- * pppac(4) - PPP Access Concentrator interface
- */
-
-#include
-
-/*
* Locks used to protect struct members and global data
* I immutable after creation
* K kernel lock
@@ -1188,9 +1182,6 @@ pppacioctl(dev_t dev, u_long cmd, caddr_
NET_LOCK();
switch (cmd) {
- case TUNSIFMODE: /* make npppd happy */
- break;
-
case FIONBIO:
break;
case FIONREAD:
Index: usr.sbin/npppd/npppd/npppd_iface.c
===
RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd_iface.c,v
retrieving revision 1.14
diff -u -p -r1.14 npppd_iface.c
--- usr.sbin/npppd/npppd/npppd_iface.c 2 Jan 2021 13:15:15 - 1.14
+++ usr.sbin/npppd/npppd/npppd_iface.c 29 Jan 2021 11:10:41 -
@@ -275,7 +275,6 @@ npppd_iface_reinit(npppd_iface *_this, s
int
npppd_iface_start(npppd_iface *_this)
{
- int x;
charbuf[PATH_MAX];
NPPPD_IFACE_ASSERT(_this != NULL);
@@ -285,16 +284,6 @@ npppd_iface_start(npppd_iface *_this)
if ((_this->devf = priv_open(buf, O_RDWR | O_NONBLOCK)) < 0) {
npppd_iface_log(_this, LOG_ERR, "open(%s) failed: %m", buf);
goto fail;
- }
-
- if (_this->using_pppx == 0) {
- x = IFF_BROADCAST;
- if (ioctl(_this->devf, TUNSIFMODE, ) != 0) {
- npppd_iface_log(_this, LOG_ERR,
- "ioctl(TUNSIFMODE=IFF_BROADCAST) failed "
- "in %s(): %m", __func__);
- goto fail;
- }
}
event_set(&_this->ev, _this->devf, EV_READ | EV_PERSIST,
Re: Improving the syspatch(8) and sysupgrade(8) test for the invoking user's privileges
On Fri, Jan 29, 2021 at 03:31:10AM -0500, Horia Racoviceanu wrote:
> Hi,
>
> I noticed the syspatch(8) and sysupgrade(8) ksh scripts test if the
> invoking user has the right privileges i.e. (($(id -u) != 0))
>
> The test for the effective user ID number can be bypassed in
> syspatch(8) and sysupgrade(8) by sh e.g.
> $ id -u
> 1000
> $ sh /usr/sbin/sysupgrade -s
> /usr/sbin/sysupgrade[90]: 1000: not found
> install: /home/_sysupgrade: Permission denied
> $ sh /usr/sbin/syspatch -r
> [snip]
> /usr/sbin/syspatch[280]: 1000: not found
> Reverting patch 012_carp
> [snip]
>
> The syspatch(8) and sysupgrade(8) test for the EUID number could be
> improved by adding "set +o sh" (see netstart(8)) or by using the
> "[[expression]]" test (see sysmerge(8)) or "[expression]" test (see
> rcctl(8)) instead of "((expression))" e.g. [ "$(id -u)" -ne 0 ]
>
> Moreover, other scripts could benefit from the addition of the
> above-mentioned test for the EUID number e.g. daily(8), weekly(8), and
> monthly(8) which are intended to run as root e.g.
> $ id -u
> 1000
> $ sh /etc/weekly
> install: /var/log/INS@FJvExvWnUh: Permission denied
> [snip]
But these are ksh(1) scripts, not strict sh(1); so they are not meant to be run
with "sh syspatch".
Like you wouldn't run them with python or perl.
> [1] http://man.openbsd.org/ksh#__
> [2] http://man.openbsd.org/ksh#test~2
> [3] http://man.openbsd.org/ksh#Strict_Bourne_shell_mode
> Index: syspatch.sh
> ===
> RCS file: /cvs/src/usr.sbin/syspatch/syspatch.sh,v
> retrieving revision 1.167
> diff -u -p -r1.167 syspatch.sh
> --- syspatch.sh 7 Dec 2020 21:19:28 - 1.167
> +++ syspatch.sh 29 Jan 2021 08:04:08 -
> @@ -276,7 +276,7 @@ set -A _KERNV -- $(sysctl -n kern.versio
> ((${#_KERNV[*]} > 1)) && err "Unsupported release: ${_KERNV[0]}${_KERNV[1]}"
>
> [[ $@ == @(|-[[:alpha:]]) ]] || usage; [[ $@ == @(|-(c|R|r)) ]] &&
> - (($(id -u) != 0)) && err "need root privileges"
> + [ "$(id -u)" -ne 0 ] && err "need root privileges"
> [[ $@ == @(|-(R|r)) ]] && pgrep -qxf '/bin/ksh .*reorder_kernel' &&
> err "cannot apply patches while reorder_kernel is running"
>
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.44
> diff -u -p -r1.44 sysupgrade.sh
> --- sysupgrade.sh 22 Oct 2020 07:19:42 - 1.44
> +++ sysupgrade.sh 29 Jan 2021 07:53:31 -
> @@ -89,7 +89,7 @@ while getopts fknrs arg; do
> esac
> done
>
> -(($(id -u) != 0)) && err "need root privileges"
> +[ "$(id -u)" -ne 0 ] && err "need root privileges"
>
> if $RELEASE && $SNAP; then
> usage
> Index: daily
> ===
> RCS file: /cvs/src/etc/daily,v
> retrieving revision 1.95
> diff -u -p -r1.95 daily
> --- daily 20 Oct 2020 22:42:29 - 1.95
> +++ daily 29 Jan 2021 08:08:44 -
> @@ -9,6 +9,7 @@ umask 022
>
> PARTOUT=/var/log/daily.part
> MAINOUT=/var/log/daily.out
> +[ "$(id -u)" -ne 0 ] && echo "${0##*/}: need root privileges" && exit 1
> install -o 0 -g 0 -m 600/dev/null $PARTOUT
> install -o 0 -g 0 -m 600 -b /dev/null $MAINOUT
>
--
Antoine
makemap(8): Parse aliases similar to expand_line
Hi
While browsing the smtpd(8) source I discovered that makemap(8) uses
strsep(3) to split the alias lines at commas. This is different from
other code which uses expand_line (which uses expand_line_split). This
leads to contrived alias lines such as
martin: "/usr/local/bin/weird_mda abc,def", alias2
to fail, because it splits at the comma in double quotes and then fails
in text_to_expandnode. smtpd(8) on the other hand is fine with the
alias file. Probably an example working with makemap(8) but not
smtpd(8) can be found as well. I think makemap(8) should accept the
same as the other code so I made the make_aliases function more similar
to expand_line. I am not calling expand_line directly to avoid needing
to handle a struct expand around. So expand_line_split has to be
public. With the changes the text argument to make_aliases can be
const.
I only tested with the alias config in base and my contrived example
lines.
What do you think? Is it a problem makemap(8) only works with lines of
less than LINE_MAX now?
Thanks!
Best,
Martin
diff 36c339f786087486bbdf963db577d740fedf8e93
blob - 99b25d51f5e35902fe1fe2fb25f16c008d389f58
file + expand.c
--- expand.c
+++ expand.c
@@ -185,7 +185,7 @@ expand_cmp(struct expandnode *e1, struct expandnode *e
return (0);
}
-static int
+int
expand_line_split(char **line, char **ret)
{
static char buffer[LINE_MAX];
blob - e2a9e465b13bb4b93c69fa45ff397ea16bfd998b
file + makemap.c
--- makemap.c
+++ makemap.c
@@ -49,7 +49,7 @@ static int parse_entry(DB *, int *, char *, size_t, s
static int parse_mapentry(DB *, int *, char *, size_t, size_t);
static int parse_setentry(DB *, int *, char *, size_t, size_t);
static int make_plain(DBT *, char *);
-static int make_aliases(DBT *, char *);
+static int make_aliases(DBT *, const char *);
static char*conf_aliases(char *);
static int dump_db(const char *, DBTYPE);
@@ -407,35 +407,36 @@ make_plain(DBT *val, char *text)
}
static int
-make_aliases(DBT *val, char *text)
+make_aliases(DBT *val, const char *text)
{
struct expandnode xn;
- char *subrcpt;
- char *origtext;
+ charbuffer[LINE_MAX];
+ char *p, *subrcpt;
+ int ret;
val->data = NULL;
val->size = 0;
- origtext = xstrdup(text);
+ memset(buffer, 0, sizeof buffer);
+ if (strlcpy(buffer, text, sizeof buffer) >= sizeof buffer)
+ return 0;
- while ((subrcpt = strsep(, ",")) != NULL) {
- /* subrcpt: strip initial and trailing whitespace. */
+ p = buffer;
+ while ((ret = expand_line_split(, )) > 0) {
subrcpt = strip(subrcpt);
- if (*subrcpt == '\0')
- goto error;
-
+ if (subrcpt[0] == '\0')
+ continue;
if (!text_to_expandnode(, subrcpt))
- goto error;
+ return 0;
}
+
+ /* expand_line_split() returned < 0 */
+ if (ret < 0)
+ return 0;
- val->data = origtext;
- val->size = strlen(origtext) + 1;
+ val->data = xstrdup(text);
+ val->size = strlen(text) + 1;
return (val->size);
-
-error:
- free(origtext);
-
- return 0;
}
static char *
blob - 487573da170bed884e34b15f85142110d28897b5
file + smtpd.h
--- smtpd.h
+++ smtpd.h
@@ -1338,6 +1338,7 @@ void expand_insert(struct expand *, struct expandnode
struct expandnode *expand_lookup(struct expand *, struct expandnode *);
void expand_clear(struct expand *);
void expand_free(struct expand *);
+int expand_line_split(char **, char **);
int expand_line(struct expand *, const char *, int);
int expand_to_text(struct expand *, char *, size_t);
RB_PROTOTYPE(expandtree, expandnode, nodes, expand_cmp);
