Re: diff: tcp ack improvement
On Tue, Jan 05, 2021 at 10:30:33AM +0100, Claudio Jeker wrote: > On Tue, Jan 05, 2021 at 10:16:04AM +0100, Jan Klemkow wrote: > > On Wed, Dec 23, 2020 at 11:59:13AM +, Stuart Henderson wrote: > > > On 2020/12/17 20:50, Jan Klemkow wrote: > > > > ping > > > > > > > > On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote: > > > > > bluhm and I make some network performance measurements and kernel > > > > > profiling. > > > > > > I've been running this on my workstation since you sent it out - lots > > > of long-running ssh connections, hourly reposync, daily rsync of base > > > snapshots. > > > > > > I don't know enough about TCP stack behaviour to really give a meaningful > > > OK, but certainly not seeing any problems with it. > > > > Thanks, Stuart. Has someone else tested this diff? Or, are there some > > opinions or objections about it? Even bike-shedding is welcome :-) > > From my memory TCP uses the ACKs on startup to increase the send window > and so your diff could slow down the initial startup. Not sure if that > matters actually. It can have some impact if userland reads in big blocks > at infrequent intervals since then the ACK clock slows down. > > I guess to get converage it would be best to commit this and then monitor > the lists for possible slowdowns. It there a way to commit this, or to test the diff in snapshots? bye, Jan > > > > > Setup:Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> > > > > > Linux (iperf) > > > > > > > > > > We figured out, that the kernel uses a huge amount of processing time > > > > > for sending ACKs to the sender on the receiving interface. After > > > > > receiving a data segment, we send our two ACK. The first one in > > > > > tcp_input() direct after receiving. The second ACK is send out, after > > > > > the userland or the sosplice task read some data out of the socket > > > > > buffer. > > > > > > > > > > The fist ACK in tcp_input() is called after receiving every other data > > > > > segment like it is discribed in RFC1122: > > > > > > > > > > 4.2.3.2 When to Send an ACK Segment > > > > > A TCP SHOULD implement a delayed ACK, but an ACK should > > > > > not be excessively delayed; in particular, the delay > > > > > MUST be less than 0.5 seconds, and in a stream of > > > > > full-sized segments there SHOULD be an ACK for at least > > > > > every second segment. > > > > > > > > > > This advice is based on the paper "Congestion Avoidance and Control": > > > > > > > > > > 4 THE GATEWAY SIDE OF CONGESTION CONTROL > > > > > The 8 KBps senders were talking to 4.3+BSD receivers > > > > > which would delay an ack for atmost one packet (because > > > > > of an ack’s clock’ role, the authors believe that the > > > > > minimum ack frequency should be every other packet). > > > > > > > > > > Sending the first ACK (on every other packet) coasts us too much > > > > > processing time. Thus, we run into a full socket buffer earlier. The > > > > > first ACK just acknowledges the received data, but does not update the > > > > > window. The second ACK, caused by the socket buffer reader, also > > > > > acknowledges the data and also updates the window. So, the second > > > > > ACK, > > > > > is much more worth for a fast packet processing than the fist one. > > > > > > > > > > The performance improvement is between 33% with splicing and 20% > > > > > without > > > > > splice: > > > > > > > > > > splicingrelaying > > > > > > > > > > current 3.1 GBit/s 2.6 GBit/s > > > > > w/o first ack 4.1 GBit/s 3.1 GBit/s > > > > > > > > > > As far as I understand the implementation of other operating systems: > > > > > Linux has implement a custom TCP_QUICKACK socket option, to turn this > > > > > kind of feature on and off. FreeBSD and NetBSD sill depend on it, > > > > > when > > > > >
Re: diff: tcp ack improvement
On Wed, Dec 23, 2020 at 11:59:13AM +, Stuart Henderson wrote:
> On 2020/12/17 20:50, Jan Klemkow wrote:
> > ping
> >
> > On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> > > bluhm and I make some network performance measurements and kernel
> > > profiling.
>
> I've been running this on my workstation since you sent it out - lots
> of long-running ssh connections, hourly reposync, daily rsync of base
> snapshots.
>
> I don't know enough about TCP stack behaviour to really give a meaningful
> OK, but certainly not seeing any problems with it.
Thanks, Stuart. Has someone else tested this diff? Or, are there some
opinions or objections about it? Even bike-shedding is welcome :-)
Thanks,
Jan
> > > Setup:Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)
> > >
> > > We figured out, that the kernel uses a huge amount of processing time
> > > for sending ACKs to the sender on the receiving interface. After
> > > receiving a data segment, we send our two ACK. The first one in
> > > tcp_input() direct after receiving. The second ACK is send out, after
> > > the userland or the sosplice task read some data out of the socket
> > > buffer.
> > >
> > > The fist ACK in tcp_input() is called after receiving every other data
> > > segment like it is discribed in RFC1122:
> > >
> > > 4.2.3.2 When to Send an ACK Segment
> > > A TCP SHOULD implement a delayed ACK, but an ACK should
> > > not be excessively delayed; in particular, the delay
> > > MUST be less than 0.5 seconds, and in a stream of
> > > full-sized segments there SHOULD be an ACK for at least
> > > every second segment.
> > >
> > > This advice is based on the paper "Congestion Avoidance and Control":
> > >
> > > 4 THE GATEWAY SIDE OF CONGESTION CONTROL
> > > The 8 KBps senders were talking to 4.3+BSD receivers
> > > which would delay an ack for atmost one packet (because
> > > of an ack’s clock’ role, the authors believe that the
> > > minimum ack frequency should be every other packet).
> > >
> > > Sending the first ACK (on every other packet) coasts us too much
> > > processing time. Thus, we run into a full socket buffer earlier. The
> > > first ACK just acknowledges the received data, but does not update the
> > > window. The second ACK, caused by the socket buffer reader, also
> > > acknowledges the data and also updates the window. So, the second ACK,
> > > is much more worth for a fast packet processing than the fist one.
> > >
> > > The performance improvement is between 33% with splicing and 20% without
> > > splice:
> > >
> > > splicingrelaying
> > >
> > > current 3.1 GBit/s 2.6 GBit/s
> > > w/o first ack 4.1 GBit/s 3.1 GBit/s
> > >
> > > As far as I understand the implementation of other operating systems:
> > > Linux has implement a custom TCP_QUICKACK socket option, to turn this
> > > kind of feature on and off. FreeBSD and NetBSD sill depend on it, when
> > > using the New Reno implementation.
> > >
> > > The following diff turns off the direct ACK on every other segment. We
> > > are running this diff in production on our own machines at genua and on
> > > our products for several month, now. We don't noticed any problems,
> > > even with interactive network sessions (ssh) nor with bulk traffic.
> > >
> > > Another solution could be a sysctl(3) or an additional socket option,
> > > similar to Linux, to control this behavior per socket or system wide.
> > > Also, a counter to ACK every 3rd, 4th... data segment could beat the
> > > problem.
> > >
> > > bye,
> > > Jan
> > >
> > > Index: netinet/tcp_input.c
> > > ===
> > > RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> > > retrieving revision 1.365
> > > diff -u -p -r1.365 tcp_input.c
> > > --- netinet/tcp_input.c 19 Jun 2020 22:47:22 - 1.365
> > > +++ netinet/tcp_input.c 5 Nov 2020 23:00:34 -
> > > @@ -165,8 +165,8 @@ do { \
> > > #endif
> > >
> > > /*
> > > - * Macro to compute ACK transmission behavior. Delay the ACK unless
> > > - * we have already delayed an ACK (must send a
Re: remove double call of ttyopen()
On Mon, Dec 28, 2020 at 07:59:23PM +0100, Klemens Nanni wrote: > On Mon, Dec 28, 2020 at 03:49:35PM +0100, Jan Klemkow wrote: > > The following diff removes useless double calls of ttyopen. l_open is > > a pointer to ttyopen(). All other serial drivers also just use l_open, > > as it is the general API for this. > I'm not familiar with the subsystem/API, but one thing looks off to me. > > > Index: dev/pci/cz.c > > === > > RCS file: /cvs/src/sys/dev/pci/cz.c,v > > retrieving revision 1.24 > > diff -u -p -r1.24 cz.c > > --- dev/pci/cz.c21 May 2020 09:31:59 - 1.24 > > +++ dev/pci/cz.c28 Dec 2020 14:41:30 - > > @@ -1034,10 +1034,6 @@ czttyopen(dev_t dev, int flags, int mode > > > > splx(s); > > > > - error = ttyopen(CZTTY_DIALOUT(dev), tp, p); > > - if (error) > > - goto bad; > > - > > error = (*linesw[tp->t_line].l_open)(dev, tp, p); > > Is `CZTTY_DIALOUT(dev)' the same as `dev'? No, is not the same in all cases. The macro converts cuaXX to corresponding ttyXX. But, it doesn't matter, would be overwritten by l_open anyway: ... tp->t_dev = device; ... > Either way, the `CZTTY_DIALOUT' macro becomes unused with this diff. The updated diff below also removes the dead CZTTY_DIALOUT macro. OK? Thanks, Jan Index: arch/luna88k/dev/siotty.c === RCS file: /cvs/src/sys/arch/luna88k/dev/siotty.c,v retrieving revision 1.23 diff -u -p -r1.23 siotty.c --- arch/luna88k/dev/siotty.c 25 Feb 2019 11:29:30 - 1.23 +++ arch/luna88k/dev/siotty.c 28 Dec 2020 14:40:29 - @@ -503,9 +503,6 @@ sioopen(dev_t dev, int flag, int mode, s splx(s); } - error = ttyopen(dev, tp, p); - if (error > 0) - return error; return (*linesw[tp->t_line].l_open)(dev, tp, p); } Index: arch/sh/dev/scif.c === RCS file: /cvs/src/sys/arch/sh/dev/scif.c,v retrieving revision 1.19 diff -u -p -r1.19 scif.c --- arch/sh/dev/scif.c 19 Feb 2018 08:59:52 - 1.19 +++ arch/sh/dev/scif.c 28 Dec 2020 14:41:05 - @@ -756,10 +756,6 @@ scifopen(dev_t dev, int flag, int mode, splx(s); - error = ttyopen(dev, tp, p); - if (error) - goto bad; - error = (*linesw[tp->t_line].l_open)(dev, tp, p); if (error) goto bad; Index: dev/pci/cz.c === RCS file: /cvs/src/sys/dev/pci/cz.c,v retrieving revision 1.24 diff -u -p -r1.24 cz.c --- dev/pci/cz.c21 May 2020 09:31:59 - 1.24 +++ dev/pci/cz.c29 Dec 2020 00:48:52 - @@ -835,7 +835,6 @@ cz_wait_pci_doorbell(struct cz_softc *cz #define CZTTYDIALOUT_MASK 0x80 -#defineCZTTY_DIALOUT(dev) (minor((dev)) & CZTTYDIALOUT_MASK) #defineCZTTY_CZ(sc)((sc)->sc_parent) #defineCZTTY_SOFTC(dev)cztty_getttysoftc(dev) @@ -1033,10 +1032,6 @@ czttyopen(dev_t dev, int flags, int mode } splx(s); - - error = ttyopen(CZTTY_DIALOUT(dev), tp, p); - if (error) - goto bad; error = (*linesw[tp->t_line].l_open)(dev, tp, p); if (error)
remove double call of ttyopen()
Hi, The following diff removes useless double calls of ttyopen. l_open is a pointer to ttyopen(). All other serial drivers also just use l_open, as it is the general API for this. OK? Bye, Jan Index: arch/luna88k/dev/siotty.c === RCS file: /cvs/src/sys/arch/luna88k/dev/siotty.c,v retrieving revision 1.23 diff -u -p -r1.23 siotty.c --- arch/luna88k/dev/siotty.c 25 Feb 2019 11:29:30 - 1.23 +++ arch/luna88k/dev/siotty.c 28 Dec 2020 14:40:29 - @@ -503,9 +503,6 @@ sioopen(dev_t dev, int flag, int mode, s splx(s); } - error = ttyopen(dev, tp, p); - if (error > 0) - return error; return (*linesw[tp->t_line].l_open)(dev, tp, p); } Index: arch/sh/dev/scif.c === RCS file: /cvs/src/sys/arch/sh/dev/scif.c,v retrieving revision 1.19 diff -u -p -r1.19 scif.c --- arch/sh/dev/scif.c 19 Feb 2018 08:59:52 - 1.19 +++ arch/sh/dev/scif.c 28 Dec 2020 14:41:05 - @@ -756,10 +756,6 @@ scifopen(dev_t dev, int flag, int mode, splx(s); - error = ttyopen(dev, tp, p); - if (error) - goto bad; - error = (*linesw[tp->t_line].l_open)(dev, tp, p); if (error) goto bad; Index: dev/pci/cz.c === RCS file: /cvs/src/sys/dev/pci/cz.c,v retrieving revision 1.24 diff -u -p -r1.24 cz.c --- dev/pci/cz.c21 May 2020 09:31:59 - 1.24 +++ dev/pci/cz.c28 Dec 2020 14:41:30 - @@ -1034,10 +1034,6 @@ czttyopen(dev_t dev, int flags, int mode splx(s); - error = ttyopen(CZTTY_DIALOUT(dev), tp, p); - if (error) - goto bad; - error = (*linesw[tp->t_line].l_open)(dev, tp, p); if (error) goto bad;
Re: diff: tcp ack improvement
ping
On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> Hi,
>
> bluhm and I make some network performance measurements and kernel
> profiling.
>
> Setup:Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)
>
> We figured out, that the kernel uses a huge amount of processing time
> for sending ACKs to the sender on the receiving interface. After
> receiving a data segment, we send our two ACK. The first one in
> tcp_input() direct after receiving. The second ACK is send out, after
> the userland or the sosplice task read some data out of the socket
> buffer.
>
> The fist ACK in tcp_input() is called after receiving every other data
> segment like it is discribed in RFC1122:
>
> 4.2.3.2 When to Send an ACK Segment
> A TCP SHOULD implement a delayed ACK, but an ACK should
> not be excessively delayed; in particular, the delay
> MUST be less than 0.5 seconds, and in a stream of
> full-sized segments there SHOULD be an ACK for at least
> every second segment.
>
> This advice is based on the paper "Congestion Avoidance and Control":
>
> 4 THE GATEWAY SIDE OF CONGESTION CONTROL
> The 8 KBps senders were talking to 4.3+BSD receivers
> which would delay an ack for atmost one packet (because
> of an ack’s clock’ role, the authors believe that the
> minimum ack frequency should be every other packet).
>
> Sending the first ACK (on every other packet) coasts us too much
> processing time. Thus, we run into a full socket buffer earlier. The
> first ACK just acknowledges the received data, but does not update the
> window. The second ACK, caused by the socket buffer reader, also
> acknowledges the data and also updates the window. So, the second ACK,
> is much more worth for a fast packet processing than the fist one.
>
> The performance improvement is between 33% with splicing and 20% without
> splice:
>
> splicingrelaying
>
> current 3.1 GBit/s 2.6 GBit/s
> w/o first ack 4.1 GBit/s 3.1 GBit/s
>
> As far as I understand the implementation of other operating systems:
> Linux has implement a custom TCP_QUICKACK socket option, to turn this
> kind of feature on and off. FreeBSD and NetBSD sill depend on it, when
> using the New Reno implementation.
>
> The following diff turns off the direct ACK on every other segment. We
> are running this diff in production on our own machines at genua and on
> our products for several month, now. We don't noticed any problems,
> even with interactive network sessions (ssh) nor with bulk traffic.
>
> Another solution could be a sysctl(3) or an additional socket option,
> similar to Linux, to control this behavior per socket or system wide.
> Also, a counter to ACK every 3rd, 4th... data segment could beat the
> problem.
>
> bye,
> Jan
>
> Index: netinet/tcp_input.c
> ===
> RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> retrieving revision 1.365
> diff -u -p -r1.365 tcp_input.c
> --- netinet/tcp_input.c 19 Jun 2020 22:47:22 - 1.365
> +++ netinet/tcp_input.c 5 Nov 2020 23:00:34 -
> @@ -165,8 +165,8 @@ do { \
> #endif
>
> /*
> - * Macro to compute ACK transmission behavior. Delay the ACK unless
> - * we have already delayed an ACK (must send an ACK every two segments).
> + * Macro to compute ACK transmission behavior. Delay the ACK until
> + * a read from the socket buffer or the delayed ACK timer causes one.
> * We also ACK immediately if we received a PUSH and the ACK-on-PUSH
> * option is enabled or when the packet is coming from a loopback
> * interface.
> @@ -176,8 +176,7 @@ do { \
> struct ifnet *ifp = NULL; \
> if (m && (m->m_flags & M_PKTHDR)) \
> ifp = if_get(m->m_pkthdr.ph_ifidx); \
> - if (TCP_TIMER_ISARMED(tp, TCPT_DELACK) || \
> - (tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> + if ((tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> (ifp && (ifp->if_flags & IFF_LOOPBACK))) \
> tp->t_flags |= TF_ACKNOW; \
> else \
>
Re: rc.d(8) for tcpbench
On Tue, Dec 15, 2020 at 10:59:50PM +, Stuart Henderson wrote: > On 2020/12/15 23:07, Jan Klemkow wrote: > > for frequent performance test it would be nice to just start tcpbench > > as a regular service. tcpbench gets an extra user and group with this > > diff and is already pledged to "stdio". Thus, there should be no > > security risk to do this even in hostile environments. > > "io" is just for client, for server it's: > > $ ps -O pledge -ax|grep [t]cpb > 43696 stdio,inet,unix pf > I+p 0:00.00 tcpbench -s Oh yes, sorry, I missed that by looking over the source too quickly. > > diff -u -p -r1.104 master.passwd > > --- etc/master.passwd 24 Apr 2020 14:57:31 - 1.104 > > +++ etc/master.passwd 15 Dec 2020 21:25:17 - > > @@ -62,4 +62,5 @@ _ftp_proxy:*:109:109::0:0:ftp proxy daem > > _sndiop:*:110:110::0:0:sndio privileged user:/var/empty:/sbin/nologin > > _syspatch:*:112:112::0:0:syspatch unprivileged > > user:/var/empty:/sbin/nologin > > _slaacd:*:115:115::0:0:SLAAC Daemon:/var/empty:/sbin/nologin > > +_tcpbench:*:116:116::0:0:tcpbench unprivileged > > user:/var/empty:/sbin/nologin > > nobody:*:32767:32767::0:0:Unprivileged user:/nonexistent:/sbin/nologin > > no need to grow the "used system uid" space, 111 is available and was > taken for less than a day so it's unlikely anyone would even need to > merge passwd/group files. or maybe a lower one is better, I don't know > if there's a particular numbering plan for these.. Sure, I will fix that, if this thing has a future. > > Index: etc/rc.d/tcpbench > > === > > RCS file: etc/rc.d/tcpbench > > diff -N etc/rc.d/tcpbench > > --- /dev/null 1 Jan 1970 00:00:00 - > > +++ etc/rc.d/tcpbench 15 Dec 2020 20:30:18 - > > @@ -0,0 +1,12 @@ > > +#!/bin/ksh > > + > > +daemon="/usr/bin/tcpbench" > > +daemon_flags="-s" > > +daemon_user=_tcpbench > > + > > +. /etc/rc.d/rc.subr > > + > > +rc_reload=NO > > +rc_bg=YES > > + > > +rc_cmd $1 > > > > I am not a big fan of this to be honest. tcpbench is written more as a > test tool than a network daemon. For starters, the spew on the console > when it's active is not very nice. As I described in answer to Theo, its seems to be easier this way, if you and to script its. Or, you want to test the quality of link to different locations frequently.
Re: rc.d(8) for tcpbench
On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote: > Jan Klemkow wrote: > > > for frequent performance test it would be nice to just start tcpbench > > as a regular service. tcpbench gets an extra user and group with this > > diff and is already pledged to "stdio". Thus, there should be no > > security risk to do this even in hostile environments. > > You're kidding me. If someone starts this in a hostile environment, their > network/host will be flattened. You are right, someone can use this, to flood a link. But, you can flood someones link with traffic anyway, as botnets do it, or? > I find it difficult to believe there is any environment where someone > wants tcpbench running *all the time*. Sure, its not ideal to run this on public interfaces. I just want to say, its unlikely that someone will take over you system via bugs in this daemon, in my opinion. As it has similar mitigation techniques as our other daemons. I run this daemon in permanent tests setups and on links to different locations. Its easier to use rcctl enable/start then to deal with background sessions on remote machines in shell scripts. Do you think its OK to make a port out of this rc-script for this purpose?
rc.d(8) for tcpbench
Hi,
for frequent performance test it would be nice to just start tcpbench
as a regular service. tcpbench gets an extra user and group with this
diff and is already pledged to "stdio". Thus, there should be no
security risk to do this even in hostile environments.
OK?
bye,
Jan
Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.480
diff -u -p -r1.480 Makefile
--- etc/Makefile13 Sep 2020 11:29:52 - 1.480
+++ etc/Makefile15 Dec 2020 21:05:07 -
@@ -64,7 +64,7 @@ RCDAEMONS=amd apmd bgpd bootparamd cron
lpd mopd mountd mrouted nfsd npppd nsd ntpd ospf6d ospfd \
pflogd portmap rad radiusd rarpd rbootd relayd ripd route6d \
sasyncd sensorsd slowcgi slaacd smtpd sndiod snmpd spamd \
- spamlogd sshd statd switchd syslogd tftpd tftpproxy unbound \
+ spamlogd sshd statd switchd syslogd tcpbench tftpd tftpproxy unbound \
unwind vmd watchdogd wsmoused xenodm ypbind ypldap ypserv
MISETS=base${OSrev}.tgz comp${OSrev}.tgz man${OSrev}.tgz
game${OSrev}.tgz
Index: etc/group
===
RCS file: /cvs/src/etc/group,v
retrieving revision 1.94
diff -u -p -r1.94 group
--- etc/group 28 Jan 2020 16:51:03 - 1.94
+++ etc/group 15 Dec 2020 20:48:07 -
@@ -79,6 +79,7 @@ _ftp_proxy:*:109:
_sndiop:*:110:
_syspatch:*:112:
_slaacd:*:115:
+_tcpbench:*:116:
dialer:*:117:
nogroup:*:32766:
nobody:*:32767:
Index: etc/master.passwd
===
RCS file: /cvs/src/etc/master.passwd,v
retrieving revision 1.104
diff -u -p -r1.104 master.passwd
--- etc/master.passwd 24 Apr 2020 14:57:31 - 1.104
+++ etc/master.passwd 15 Dec 2020 21:25:17 -
@@ -62,4 +62,5 @@ _ftp_proxy:*:109:109::0:0:ftp proxy daem
_sndiop:*:110:110::0:0:sndio privileged user:/var/empty:/sbin/nologin
_syspatch:*:112:112::0:0:syspatch unprivileged user:/var/empty:/sbin/nologin
_slaacd:*:115:115::0:0:SLAAC Daemon:/var/empty:/sbin/nologin
+_tcpbench:*:116:116::0:0:tcpbench unprivileged user:/var/empty:/sbin/nologin
nobody:*:32767:32767::0:0:Unprivileged user:/nonexistent:/sbin/nologin
Index: etc/rc.conf
===
RCS file: /cvs/src/etc/rc.conf,v
retrieving revision 1.220
diff -u -p -r1.220 rc.conf
--- etc/rc.conf 24 Jan 2020 06:17:37 - 1.220
+++ etc/rc.conf 15 Dec 2020 20:32:46 -
@@ -65,6 +65,7 @@ spamlogd_flags= # use eg. "-i interface
sshd_flags=
switchd_flags=NO
syslogd_flags= # add more flags, e.g. "-u -a /chroot/dev/log"
+tcpbench_flags=NO
tftpd_flags=NO
tftpproxy_flags=NO
unbound_flags=NO
Index: etc/mail/aliases
===
RCS file: /cvs/src/etc/mail/aliases,v
retrieving revision 1.68
diff -u -p -r1.68 aliases
--- etc/mail/aliases24 Jan 2020 06:17:37 - 1.68
+++ etc/mail/aliases15 Dec 2020 20:48:31 -
@@ -79,6 +79,7 @@ _ftp_proxy: /dev/null
_sndiop: /dev/null
_syspatch: /dev/null
_slaacd: /dev/null
+_tcpbench: /dev/null
sshd: /dev/null
# Well-known aliases -- these should be filled in!
Index: etc/rc.d/tcpbench
===
RCS file: etc/rc.d/tcpbench
diff -N etc/rc.d/tcpbench
--- /dev/null 1 Jan 1970 00:00:00 -
+++ etc/rc.d/tcpbench 15 Dec 2020 20:30:18 -
@@ -0,0 +1,12 @@
+#!/bin/ksh
+
+daemon="/usr/bin/tcpbench"
+daemon_flags="-s"
+daemon_user=_tcpbench
+
+. /etc/rc.d/rc.subr
+
+rc_reload=NO
+rc_bg=YES
+
+rc_cmd $1
diff: mbuf-chains for tcp/ip/ether_ouput
Hi,
I took on old idea and diff [1] from bluhm and finished it for the IPv4
case.
This change uses mbuf chains in tcp/ip/ether_output instead of single
mbufs. This approach takes lesser processing power per packets, which
we want to send out. In several code path it optimises the
processing because we just have to look at the first mbuf of a chain.
In other cases we process several packets in a row for one step, which
saves context switches between functions.
Thus, we gain an performance improvement of around 36% with relayd(8).
The measurements were made with iperf and with 30 streams:
2823.0 MBit/s current
3844.4 MBit/s current + mbuf-chaining diff below
ip6_output() is not implemented yet. I would do that in a followup diff
later, if this one is successful.
I tested the diff on amd64 in several testing environments without any
problem.
Whats your opinion about this change?
bye,
Jan
[1]: https://github.com/bluhm/sys/tree/tcp-outlist
Index: net/fq_codel.c
===
RCS file: /cvs/src/sys/net/fq_codel.c,v
retrieving revision 1.14
diff -u -p -r1.14 fq_codel.c
--- net/fq_codel.c 10 Dec 2020 06:53:38 - 1.14
+++ net/fq_codel.c 15 Dec 2020 09:37:36 -
@@ -138,6 +138,7 @@ void fqcodel_purge(struct fqcodel *, s
static const struct ifq_ops fqcodel_ops = {
fqcodel_idx,
fqcodel_if_enq,
+ NULL,
fqcodel_if_deq_begin,
fqcodel_if_deq_commit,
fqcodel_if_purge,
Index: net/hfsc.c
===
RCS file: /cvs/src/sys/net/hfsc.c,v
retrieving revision 1.48
diff -u -p -r1.48 hfsc.c
--- net/hfsc.c 22 Oct 2018 23:44:53 - 1.48
+++ net/hfsc.c 15 Dec 2020 09:37:36 -
@@ -270,6 +270,7 @@ void hfsc_free(unsigned int, void *);
const struct ifq_ops hfsc_ops = {
hfsc_idx,
hfsc_enq,
+ NULL,
hfsc_deq_begin,
hfsc_deq_commit,
hfsc_purge,
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.620
diff -u -p -r1.620 if.c
--- net/if.c3 Oct 2020 00:23:55 - 1.620
+++ net/if.c15 Dec 2020 09:37:36 -
@@ -633,6 +633,8 @@ if_attach_common(struct ifnet *ifp)
ifp->if_rtrequest = if_rtrequest_dummy;
if (ifp->if_enqueue == NULL)
ifp->if_enqueue = if_enqueue_ifq;
+ if (ifp->if_enqueue_ml == NULL)
+ ifp->if_enqueue_ml = if_enqueue_ifq_ml;
ifp->if_llprio = IFQ_DEFPRIO;
}
@@ -682,35 +684,72 @@ if_qstart_compat(struct ifqueue *ifq)
int
if_enqueue(struct ifnet *ifp, struct mbuf *m)
{
+ struct mbuf_list ml = MBUF_LIST_INITIALIZER();
+
+ ml_enqueue(, m);
+ return (if_enqueue_ml(ifp, ));
+}
+
+int
+if_enqueue_ml(struct ifnet *ifp, struct mbuf_list *ml)
+{
+ int error;
+ struct mbuf *m;
+
+ while ((m = ml_dequeue(ml)) != NULL) {
#if NPF > 0
- if (m->m_pkthdr.pf.delay > 0)
- return (pf_delay_pkt(m, ifp->if_index));
+ if (m->m_pkthdr.pf.delay > 0) {
+ error = pf_delay_pkt(m, ifp->if_index);
+ if (error != 0)
+ goto bad;
+ continue;
+ }
#endif
#if NBRIDGE > 0
- if (ifp->if_bridgeidx && (m->m_flags & M_PROTO1) == 0) {
- int error;
-
- error = bridge_enqueue(ifp, m);
- return (error);
- }
+ if (ifp->if_bridgeidx && (m->m_flags & M_PROTO1) == 0) {
+ error = bridge_enqueue(ifp, m);
+ if (error != 0)
+ goto bad;
+ continue;
+ }
#endif
#if NPF > 0
- pf_pkt_addr_changed(m);
+ pf_pkt_addr_changed(m);
#endif /* NPF > 0 */
- return ((*ifp->if_enqueue)(ifp, m));
+ error = (*ifp->if_enqueue)(ifp, m);
+ if (error != 0)
+ goto bad;
+ }
+
+ return 0;
+ bad:
+ ml_purge(ml);
+ return error;
}
int
if_enqueue_ifq(struct ifnet *ifp, struct mbuf *m)
{
+ struct mbuf_list ml = MBUF_LIST_INITIALIZER();
+
+ ml_enqueue(, m);
+ return (if_enqueue_ifq_ml(ifp, ));
+}
+
+int
+if_enqueue_ifq_ml(struct ifnet *ifp, struct mbuf_list *ml)
+{
struct ifqueue *ifq = >if_snd;
int error;
if (ifp->if_nifqs > 1) {
unsigned int idx;
+ struct mbuf *m;
+
+ m = MBUF_LIST_FIRST(ml);
/*
* use the operations on the first ifq to pick which of
@@ -721,13 +760,16 @@ if_enqueue_ifq(struct ifnet *ifp, struct
ifq = ifp->if_ifqs[idx];
}
- error = ifq_enqueue(ifq, m);
- if (error)
- return (error);
+
diff: cleanup type handling
Hi,
The type of the local variable hash in pf_map_addr() has right length
but the wrong type. This diff uses the correct type and removes the
useless casts. Both functions uses hash as pf_addr, so no cast is
needed.
OK?
bye,
Jan
Index: net/pf_lb.c
===
RCS file: /cvs/src/sys/net/pf_lb.c,v
retrieving revision 1.67
diff -u -p -r1.67 pf_lb.c
--- net/pf_lb.c 29 Jul 2020 02:32:13 - 1.67
+++ net/pf_lb.c 12 Dec 2020 13:06:49 -
@@ -349,7 +349,7 @@ pf_map_addr(sa_family_t af, struct pf_ru
struct pf_addr *naddr, struct pf_addr *init_addr, struct pf_src_node **sns,
struct pf_pool *rpool, enum pf_sn_types type)
{
- unsigned charhash[16];
+ struct pf_addr hash;
struct pf_addr faddr;
struct pf_addr *raddr = >addr.v.a.addr;
struct pf_addr *rmask = >addr.v.a.mask;
@@ -460,8 +460,7 @@ pf_map_addr(sa_family_t af, struct pf_ru
}
break;
case PF_POOL_SRCHASH:
- hashidx =
- pf_hash(saddr, (struct pf_addr *), >key, af);
+ hashidx = pf_hash(saddr, , >key, af);
if (rpool->addr.type == PF_ADDR_TABLE ||
rpool->addr.type == PF_ADDR_DYNIFTL) {
@@ -483,8 +482,7 @@ pf_map_addr(sa_family_t af, struct pf_ru
return (1);
pf_addrcpy(naddr, >counter, af);
} else {
- pf_poolmask(naddr, raddr, rmask,
- (struct pf_addr *), af);
+ pf_poolmask(naddr, raddr, rmask, , af);
}
break;
case PF_POOL_ROUNDROBIN:
diff: replace useless use of MCLGETL with MCLGET
Hi,
The use of MCLGETL with the default length MCLBYTES is useless. Thus,
this diff removes '(void)' from the MCLGET macro as it is in the MCLGETL
and replaces all uses of MCLGETL with MCLBYTES by MCLGET.
OK?
bye,
Jan
Index: arch/octeon/dev/if_ogx.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/if_ogx.c,v
retrieving revision 1.3
diff -u -p -r1.3 if_ogx.c
--- arch/octeon/dev/if_ogx.c12 Dec 2020 11:48:52 - 1.3
+++ arch/octeon/dev/if_ogx.c12 Dec 2020 12:58:31 -
@@ -1147,7 +1147,7 @@ ogx_load_mbufs(struct ogx_softc *sc, uns
paddr_t pktbuf;
for ( ; n > 0; n--) {
- m = MCLGETL(NULL, M_NOWAIT, MCLBYTES);
+ m = MCLGET(NULL, M_NOWAIT);
if (m == NULL)
break;
Index: dev/fdt/if_dwge.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwge.c,v
retrieving revision 1.7
diff -u -p -r1.7 if_dwge.c
--- dev/fdt/if_dwge.c 12 Dec 2020 11:48:52 - 1.7
+++ dev/fdt/if_dwge.c 12 Dec 2020 12:58:31 -
@@ -1283,7 +1283,7 @@ dwge_alloc_mbuf(struct dwge_softc *sc, b
{
struct mbuf *m = NULL;
- m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+ m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/fdt/if_dwxe.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwxe.c,v
retrieving revision 1.18
diff -u -p -r1.18 if_dwxe.c
--- dev/fdt/if_dwxe.c 12 Dec 2020 11:48:52 - 1.18
+++ dev/fdt/if_dwxe.c 12 Dec 2020 12:58:31 -
@@ -1342,7 +1342,7 @@ dwxe_alloc_mbuf(struct dwxe_softc *sc, b
{
struct mbuf *m = NULL;
- m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+ m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/fdt/if_fec.c
===
RCS file: /cvs/src/sys/dev/fdt/if_fec.c,v
retrieving revision 1.11
diff -u -p -r1.11 if_fec.c
--- dev/fdt/if_fec.c12 Dec 2020 11:48:52 - 1.11
+++ dev/fdt/if_fec.c12 Dec 2020 12:58:31 -
@@ -1298,7 +1298,7 @@ fec_alloc_mbuf(struct fec_softc *sc, bus
{
struct mbuf *m = NULL;
- m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+ m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/fdt/if_mvneta.c
===
RCS file: /cvs/src/sys/dev/fdt/if_mvneta.c,v
retrieving revision 1.16
diff -u -p -r1.16 if_mvneta.c
--- dev/fdt/if_mvneta.c 12 Dec 2020 11:48:52 - 1.16
+++ dev/fdt/if_mvneta.c 12 Dec 2020 12:58:31 -
@@ -1654,7 +1654,7 @@ mvneta_alloc_mbuf(struct mvneta_softc *s
{
struct mbuf *m = NULL;
- m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+ m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/fdt/if_mvpp.c
===
RCS file: /cvs/src/sys/dev/fdt/if_mvpp.c,v
retrieving revision 1.44
diff -u -p -r1.44 if_mvpp.c
--- dev/fdt/if_mvpp.c 12 Dec 2020 11:48:52 - 1.44
+++ dev/fdt/if_mvpp.c 12 Dec 2020 12:58:31 -
@@ -3124,7 +3124,7 @@ mvpp2_alloc_mbuf(struct mvpp2_softc *sc,
{
struct mbuf *m = NULL;
- m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+ m = MCLGET(NULL, M_DONTWAIT);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: dev/ic/bcmgenet.c
===
RCS file: /cvs/src/sys/dev/ic/bcmgenet.c,v
retrieving revision 1.4
diff -u -p -r1.4 bcmgenet.c
--- dev/ic/bcmgenet.c 12 Dec 2020 11:48:52 - 1.4
+++ dev/ic/bcmgenet.c 12 Dec 2020 12:58:31 -
@@ -300,7 +300,7 @@ genet_alloc_mbufcl(struct genet_softc *s
{
struct mbuf *m;
- m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+ m = MCLGET(NULL, M_DONTWAIT);
if (m != NULL)
m->m_pkthdr.len = m->m_len = m->m_ext.ext_size;
Index: dev/ic/elink3.c
===
RCS file: /cvs/src/sys/dev/ic/elink3.c,v
retrieving revision 1.98
diff -u -p -r1.98 elink3.c
--- dev/ic/elink3.c 12 Dec 2020 11:48:52 - 1.98
+++ dev/ic/elink3.c 12 Dec 2020 12:58:31 -
@@ -1343,7 +1343,7 @@ epget(struct ep_softc *sc, int totlen)
m = sc->mb[sc->next_mb];
sc->mb[sc->next_mb] = NULL;
if (m == NULL) {
- m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
+ m = MCLGET(NULL, M_DONTWAIT);
/* If the queue is no longer full, refill. */
if (!timeout_pending(>sc_epmbuffill_tmo))
Re: FT232H variant in uftdi(4)
On Wed, Dec 09, 2020 at 09:11:35AM +0100, Jan Klemkow wrote: > On Tue, Dec 08, 2020 at 09:03:53PM -0300, Daniel Bolgheroni wrote: > > I have a FT232H variant (marked FT232HQ, 0403:6014) which works with > > uftdi(4). > > > > Still related to uftdi(4), sys/dev/usb/ftdi.c has a comment saying uftdi(4) > > does not support multiple serial ports because ucom(4), but I'm able to use > > both ucom(4) in parallel from the same FT2232H (dual). > > Hi Daniel, > > How does your device attach? Could you send a dmesg with your device attached? sorry, for the noise. > Thanks, > Jan > > > diff --git a/sys/dev/usb/uftdi.c b/sys/dev/usb/uftdi.c > > index fb7b8ae8621..80eb3f2c928 100644 > > --- a/sys/dev/usb/uftdi.c > > +++ b/sys/dev/usb/uftdi.c > > @@ -34,11 +34,6 @@ > > * FTDI FT8U100AX serial adapter driver > > */ > > > > -/* > > - * XXX This driver will not support multiple serial ports. > > - * XXX The ucom layer needs to be extended first. > > - */
Re: FT232H variant in uftdi(4)
On Tue, Dec 08, 2020 at 09:03:53PM -0300, Daniel Bolgheroni wrote: > I have a FT232H variant (marked FT232HQ, 0403:6014) which works with uftdi(4). > > Still related to uftdi(4), sys/dev/usb/ftdi.c has a comment saying uftdi(4) > does not support multiple serial ports because ucom(4), but I'm able to use > both ucom(4) in parallel from the same FT2232H (dual). Hi Daniel, How does your device attach? Could you send with your device attached? Thanks, Jan > diff --git a/sys/dev/usb/uftdi.c b/sys/dev/usb/uftdi.c > index fb7b8ae8621..80eb3f2c928 100644 > --- a/sys/dev/usb/uftdi.c > +++ b/sys/dev/usb/uftdi.c > @@ -34,11 +34,6 @@ > * FTDI FT8U100AX serial adapter driver > */ > > -/* > - * XXX This driver will not support multiple serial ports. > - * XXX The ucom layer needs to be extended first. > - */
Re: diff: tcp ack improvement
On Fri, Nov 06, 2020 at 08:03:36AM +0100, Otto Moerbeek wrote:
> On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote:
> > bluhm and I make some network performance measurements and kernel
> > profiling.
> >
> > Setup: Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)
> >
> > We figured out, that the kernel uses a huge amount of processing time
> > for sending ACKs to the sender on the receiving interface. After
> > receiving a data segment, we send our two ACK. The first one in
> > tcp_input() direct after receiving. The second ACK is send out, after
> > the userland or the sosplice task read some data out of the socket
> > buffer.
> >
> > The fist ACK in tcp_input() is called after receiving every other data
> > segment like it is discribed in RFC1122:
> >
> > 4.2.3.2 When to Send an ACK Segment
> > A TCP SHOULD implement a delayed ACK, but an ACK should
> > not be excessively delayed; in particular, the delay
> > MUST be less than 0.5 seconds, and in a stream of
> > full-sized segments there SHOULD be an ACK for at least
> > every second segment.
> >
> > This advice is based on the paper "Congestion Avoidance and Control":
> >
> > 4 THE GATEWAY SIDE OF CONGESTION CONTROL
> > The 8 KBps senders were talking to 4.3+BSD receivers
> > which would delay an ack for atmost one packet (because
> > of an ack’s clock’ role, the authors believe that the
> > minimum ack frequency should be every other packet).
> >
> > Sending the first ACK (on every other packet) coasts us too much
> > processing time. Thus, we run into a full socket buffer earlier. The
> > first ACK just acknowledges the received data, but does not update the
> > window. The second ACK, caused by the socket buffer reader, also
> > acknowledges the data and also updates the window. So, the second ACK,
> > is much more worth for a fast packet processing than the fist one.
> >
> > The performance improvement is between 33% with splicing and 20% without
> > splice:
> >
> > splicingrelaying
> >
> > current 3.1 GBit/s 2.6 GBit/s
> > w/o first ack 4.1 GBit/s 3.1 GBit/s
> >
> > As far as I understand the implementation of other operating systems:
> > Linux has implement a custom TCP_QUICKACK socket option, to turn this
> > kind of feature on and off. FreeBSD and NetBSD sill depend on it, when
> > using the New Reno implementation.
> >
> > The following diff turns off the direct ACK on every other segment. We
> > are running this diff in production on our own machines at genua and on
> > our products for several month, now. We don't noticed any problems,
> > even with interactive network sessions (ssh) nor with bulk traffic.
> >
> > Another solution could be a sysctl(3) or an additional socket option,
> > similar to Linux, to control this behavior per socket or system wide.
> > Also, a counter to ACK every 3rd, 4th... data segment could beat the
> > problem.
>
> I am wondering if you also looked at another scenario: the process
> reading the soecket is sleeping so the receive buffer fills up without
> any acks being sent. Won't that lead to a lot of retransmissions
> containing data?
No, an ACK will always send out after the delayed ACK timer is
triggered. So, its shouldn't be a problem, when nobody on the system
reads from the socket buffer.
> > Index: netinet/tcp_input.c
> > ===
> > RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> > retrieving revision 1.365
> > diff -u -p -r1.365 tcp_input.c
> > --- netinet/tcp_input.c 19 Jun 2020 22:47:22 - 1.365
> > +++ netinet/tcp_input.c 5 Nov 2020 23:00:34 -
> > @@ -165,8 +165,8 @@ do { \
> > #endif
> >
> > /*
> > - * Macro to compute ACK transmission behavior. Delay the ACK unless
> > - * we have already delayed an ACK (must send an ACK every two segments).
> > + * Macro to compute ACK transmission behavior. Delay the ACK until
> > + * a read from the socket buffer or the delayed ACK timer causes one.
> > * We also ACK immediately if we received a PUSH and the ACK-on-PUSH
> > * option is enabled or when the packet is coming from a loopback
> > * interface.
> > @@ -176,8 +176,7 @@ do { \
> > struct ifnet *ifp = NULL; \
> > if (m && (m->m_flags & M_PKTHDR)) \
> > ifp = if_get(m->m_pkthdr.ph_ifidx); \
> > - if (TCP_TIMER_ISARMED(tp, TCPT_DELACK) || \
> > - (tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> > + if ((tcp_ack_on_push && (tiflags) & TH_PUSH) || \
> > (ifp && (ifp->if_flags & IFF_LOOPBACK))) \
> > tp->t_flags |= TF_ACKNOW; \
> > else \
> >
>
diff: tcp ack improvement
Hi,
bluhm and I make some network performance measurements and kernel
profiling.
Setup: Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf)
We figured out, that the kernel uses a huge amount of processing time
for sending ACKs to the sender on the receiving interface. After
receiving a data segment, we send our two ACK. The first one in
tcp_input() direct after receiving. The second ACK is send out, after
the userland or the sosplice task read some data out of the socket
buffer.
The fist ACK in tcp_input() is called after receiving every other data
segment like it is discribed in RFC1122:
4.2.3.2 When to Send an ACK Segment
A TCP SHOULD implement a delayed ACK, but an ACK should
not be excessively delayed; in particular, the delay
MUST be less than 0.5 seconds, and in a stream of
full-sized segments there SHOULD be an ACK for at least
every second segment.
This advice is based on the paper "Congestion Avoidance and Control":
4 THE GATEWAY SIDE OF CONGESTION CONTROL
The 8 KBps senders were talking to 4.3+BSD receivers
which would delay an ack for atmost one packet (because
of an ack’s clock’ role, the authors believe that the
minimum ack frequency should be every other packet).
Sending the first ACK (on every other packet) coasts us too much
processing time. Thus, we run into a full socket buffer earlier. The
first ACK just acknowledges the received data, but does not update the
window. The second ACK, caused by the socket buffer reader, also
acknowledges the data and also updates the window. So, the second ACK,
is much more worth for a fast packet processing than the fist one.
The performance improvement is between 33% with splicing and 20% without
splice:
splicingrelaying
current 3.1 GBit/s 2.6 GBit/s
w/o first ack 4.1 GBit/s 3.1 GBit/s
As far as I understand the implementation of other operating systems:
Linux has implement a custom TCP_QUICKACK socket option, to turn this
kind of feature on and off. FreeBSD and NetBSD sill depend on it, when
using the New Reno implementation.
The following diff turns off the direct ACK on every other segment. We
are running this diff in production on our own machines at genua and on
our products for several month, now. We don't noticed any problems,
even with interactive network sessions (ssh) nor with bulk traffic.
Another solution could be a sysctl(3) or an additional socket option,
similar to Linux, to control this behavior per socket or system wide.
Also, a counter to ACK every 3rd, 4th... data segment could beat the
problem.
bye,
Jan
Index: netinet/tcp_input.c
===
RCS file: /cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.365
diff -u -p -r1.365 tcp_input.c
--- netinet/tcp_input.c 19 Jun 2020 22:47:22 - 1.365
+++ netinet/tcp_input.c 5 Nov 2020 23:00:34 -
@@ -165,8 +165,8 @@ do { \
#endif
/*
- * Macro to compute ACK transmission behavior. Delay the ACK unless
- * we have already delayed an ACK (must send an ACK every two segments).
+ * Macro to compute ACK transmission behavior. Delay the ACK until
+ * a read from the socket buffer or the delayed ACK timer causes one.
* We also ACK immediately if we received a PUSH and the ACK-on-PUSH
* option is enabled or when the packet is coming from a loopback
* interface.
@@ -176,8 +176,7 @@ do { \
struct ifnet *ifp = NULL; \
if (m && (m->m_flags & M_PKTHDR)) \
ifp = if_get(m->m_pkthdr.ph_ifidx); \
- if (TCP_TIMER_ISARMED(tp, TCPT_DELACK) || \
- (tcp_ack_on_push && (tiflags) & TH_PUSH) || \
+ if ((tcp_ack_on_push && (tiflags) & TH_PUSH) || \
(ifp && (ifp->if_flags & IFF_LOOPBACK))) \
tp->t_flags |= TF_ACKNOW; \
else \
diff: refactor MCLGETI() macro
Hi,
The name of the macro MCLGETI obsolete. It was made to use a network
interface pointer inside. But, now it is just used to define a special
length and the interface pointer is discarded.
Thus, the following diff renames the macro to MCLGETL and removes the
dead parameter ifp.
OK?
Bye,
Jan
Index: share/man/man9/mbuf.9
===
RCS file: /cvs/src/share/man/man9/mbuf.9,v
retrieving revision 1.119
diff -u -p -r1.119 mbuf.9
--- share/man/man9/mbuf.9 8 Aug 2020 07:42:31 - 1.119
+++ share/man/man9/mbuf.9 7 Oct 2020 19:24:48 -
@@ -58,7 +58,7 @@
.Nm m_devget ,
.Nm m_apply ,
.Nm MCLGET ,
-.Nm MCLGETI ,
+.Nm MCLGETL ,
.Nm MEXTADD ,
.Nm m_align ,
.Nm M_READONLY ,
@@ -126,7 +126,7 @@
"int (*func)(caddr_t, caddr_t, unsigned int)" "caddr_t fstate"
.Fn MCLGET "struct mbuf *m" "int how"
.Ft struct mbuf *
-.Fn MCLGETI "struct mbuf *m" "int how" "struct ifnet *ifp" "int len"
+.Fn MCLGETL "struct mbuf *m" "int how" "int len"
.Fn MEXTADD "struct mbuf *m" "caddr_t buf" "u_int size" "int flags" \
"void (*free)(caddr_t, u_int, void *)" "void *arg"
.Ft void
@@ -721,7 +721,7 @@ See
.Fn m_get
for a description of
.Fa how .
-.It Fn MCLGETI "struct mbuf *m" "int how" "struct ifnet *ifp" "int len"
+.It Fn MCLGETL "struct mbuf *m" "int how" "int len"
If
.Fa m
is NULL, allocate it.
Index: sys/arch/octeon/dev/if_cnmac.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/if_cnmac.c,v
retrieving revision 1.79
diff -u -p -r1.79 if_cnmac.c
--- sys/arch/octeon/dev/if_cnmac.c 4 Sep 2020 15:18:05 - 1.79
+++ sys/arch/octeon/dev/if_cnmac.c 7 Oct 2020 19:27:08 -
@@ -1106,7 +1106,7 @@ cnmac_mbuf_alloc(int n)
paddr_t pktbuf;
while (n > 0) {
- m = MCLGETI(NULL, M_NOWAIT, NULL,
+ m = MCLGETL(NULL, M_NOWAIT,
OCTEON_POOL_SIZE_PKT + CACHELINESIZE);
if (m == NULL || !ISSET(m->m_flags, M_EXT)) {
m_freem(m);
Index: sys/arch/octeon/dev/if_ogx.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/if_ogx.c,v
retrieving revision 1.2
diff -u -p -r1.2 if_ogx.c
--- sys/arch/octeon/dev/if_ogx.c9 Sep 2020 15:53:25 - 1.2
+++ sys/arch/octeon/dev/if_ogx.c7 Oct 2020 19:27:25 -
@@ -1147,7 +1147,7 @@ ogx_load_mbufs(struct ogx_softc *sc, uns
paddr_t pktbuf;
for ( ; n > 0; n--) {
- m = MCLGETI(NULL, M_NOWAIT, NULL, MCLBYTES);
+ m = MCLGETL(NULL, M_NOWAIT, MCLBYTES);
if (m == NULL)
break;
Index: sys/arch/sparc64/dev/vnet.c
===
RCS file: /cvs/src/sys/arch/sparc64/dev/vnet.c,v
retrieving revision 1.62
diff -u -p -r1.62 vnet.c
--- sys/arch/sparc64/dev/vnet.c 10 Jul 2020 13:26:36 - 1.62
+++ sys/arch/sparc64/dev/vnet.c 7 Oct 2020 19:27:41 -
@@ -834,7 +834,7 @@ vnet_rx_vio_dring_data(struct vnet_softc
goto skip;
}
- m = MCLGETI(NULL, M_DONTWAIT, NULL, desc.nbytes);
+ m = MCLGETL(NULL, M_DONTWAIT, desc.nbytes);
if (!m)
break;
m->m_len = m->m_pkthdr.len = desc.nbytes;
Index: sys/dev/fdt/if_dwge.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwge.c,v
retrieving revision 1.6
diff -u -p -r1.6 if_dwge.c
--- sys/dev/fdt/if_dwge.c 13 Sep 2020 01:54:05 - 1.6
+++ sys/dev/fdt/if_dwge.c 7 Oct 2020 19:28:00 -
@@ -1283,7 +1283,7 @@ dwge_alloc_mbuf(struct dwge_softc *sc, b
{
struct mbuf *m = NULL;
- m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+ m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: sys/dev/fdt/if_dwxe.c
===
RCS file: /cvs/src/sys/dev/fdt/if_dwxe.c,v
retrieving revision 1.17
diff -u -p -r1.17 if_dwxe.c
--- sys/dev/fdt/if_dwxe.c 10 Jul 2020 13:26:36 - 1.17
+++ sys/dev/fdt/if_dwxe.c 7 Oct 2020 19:28:28 -
@@ -1342,7 +1342,7 @@ dwxe_alloc_mbuf(struct dwxe_softc *sc, b
{
struct mbuf *m = NULL;
- m = MCLGETI(NULL, M_DONTWAIT, NULL, MCLBYTES);
+ m = MCLGETL(NULL, M_DONTWAIT, MCLBYTES);
if (!m)
return (NULL);
m->m_len = m->m_pkthdr.len = MCLBYTES;
Index: sys/dev/fdt/if_fec.c
===
RCS file: /cvs/src/sys/dev/fdt/if_fec.c,v
retrieving revision 1.10
diff -u -p -r1.10 if_fec.c
--- sys/dev/fdt/if_fec.c10 Jul 2020 13:26:36 - 1.10
+++ sys/dev/fdt/if_fec.c7
diff: remove dead code in a{rm,md}64/a{rm,md}/conf.c
Hi,
the cdev_joy_init makro is just used in i386.
OK?
Bye,
Jan
Index: amd64/amd64/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v
retrieving revision 1.71
diff -u -p -r1.71 conf.c
--- amd64/amd64/conf.c 6 Jul 2020 04:32:25 - 1.71
+++ amd64/amd64/conf.c 7 Oct 2020 13:10:57 -
@@ -75,13 +75,6 @@ struct bdevswbdevsw[] =
};
intnblkdev = nitems(bdevsw);
-/* open, close, read, ioctl */
-#define cdev_joy_init(c,n) { \
- dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
- (dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
- (dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
-
/* open, close, ioctl */
#define cdev_ocis_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), (dev_type_read((*))) enodev, \
Index: arm64/arm64/conf.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/conf.c,v
retrieving revision 1.15
diff -u -p -r1.15 conf.c
--- arm64/arm64/conf.c 6 Jul 2020 04:32:25 - 1.15
+++ arm64/arm64/conf.c 7 Oct 2020 13:10:57 -
@@ -72,13 +72,6 @@ struct bdevswbdevsw[] =
};
intnblkdev = nitems(bdevsw);
-/* open, close, read, ioctl */
-#define cdev_joy_init(c,n) { \
- dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
- (dev_type_write((*))) enodev, dev_init(c,n,ioctl), \
- (dev_type_stop((*))) enodev, 0, seltrue, \
- (dev_type_mmap((*))) enodev, 0, 0, seltrue_kqfilter }
-
/* open, close, ioctl, select -- XXX should be a generic device */
#define cdev_ocis_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), (dev_type_read((*))) enodev, \
new: rp(4): RocketPort multi serial port pci card driver
Hi,
The following diff contains a port of the FreeBSD driver for RocketPort PCI
cards. The tty interface works with getty(8) and the cua part with cu for
outbound connections. Some issues are still in, which I could not figure out
yet. I worked on this driver for one and half year now, and think it ready to
get in.
I've done a lot of clean up of the original FreeBSD code. Because there is no
specification available, I kept most of the comments. I also switched the
original polling mode, which is used in the FreeBSD and Linux version of the
driver to an interrupt driven mode.
This is my first major work in the driver section. I'm sure that I may miss
something. So, even nitpicks are welcome :-)
OK?
Thanks,
Jan
Index: share/man/man4/rp.4
===
RCS file: share/man/man4/rp.4
diff -N share/man/man4/rp.4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man4/rp.4 2 Oct 2020 17:50:01 -
@@ -0,0 +1,54 @@
+.\" $OpenBSD$
+.\"
+.\" Copyright (c) 2020 Jan Klemkow
+.\"
+.\" 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: October 3 2020 $
+.Dt RP 4
+.Os
+.Sh NAME
+.Nm rp
+.Nd Comtrol RocketPort Intelligent Serial Port Cards device driver
+.Sh SYNOPSIS
+.Cd "rp* at pci?"
+.Sh DESCRIPTION
+This driver provides an interface to RocketPort multiport serial boards.
+.Pp
+The device minor numbers for this driver are encoded as follows:
+.Bd -literal
+d c c u u u u u- bits in the minor device number
+
+bitsmeaning
+---
+u physical serial line (i.e., unit) to use
+ 0-7 on a 8Y, 0-15 on a 16Y
+
+cc card number
+
+d dial-out flag
+.Ed
+.Sh SEE ALSO
+.Xr com 4 ,
+.Xr cy 4 ,
+.Xr intro 4 ,
+.Xr pci 4 ,
+.Xr termios 4 ,
+.Xr tty 4
+.Sh AUTHORS
+This driver was written under contract for Comtrol Corporation by
+.An Theodore Ts'o Aq Mt ty...@mit.edu .
+It was ported to OpenBSD by
+.An Jan Klemkow Aq Mt j.klem...@wemelug.de .
+.Sh BUGS
+Modem control does not work properly.
Index: sys/arch/amd64/amd64/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/conf.c,v
retrieving revision 1.71
diff -u -p -r1.71 conf.c
--- sys/arch/amd64/amd64/conf.c 6 Jul 2020 04:32:25 - 1.71
+++ sys/arch/amd64/amd64/conf.c 2 Oct 2020 17:08:36 -
@@ -75,6 +75,12 @@ struct bdevswbdevsw[] =
};
intnblkdev = nitems(bdevsw);
+/* open, close, read, write, ioctl, tty, mmap */
+#define cdev_pc_init(c,n) { \
+ dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
+ dev_init(c,n,write), dev_init(c,n,ioctl), dev_init(c,n,stop), \
+ dev_init(c,n,tty), ttselect, dev_init(c,n,mmap), D_TTY }
+
/* open, close, read, ioctl */
#define cdev_joy_init(c,n) { \
dev_init(c,n,open), dev_init(c,n,close), dev_init(c,n,read), \
@@ -132,6 +138,8 @@ cdev_decl(lms);
#include "opms.h"
cdev_decl(pms);
#endif
+#include "rp.h"
+cdev_decl(rp);
#include "cy.h"
cdev_decl(cy);
#include "tun.h"
@@ -222,7 +230,7 @@ struct cdevsw cdevsw[] =
cdev_notdef(), /* 31 */
cdev_notdef(), /* 32 */
cdev_notdef(), /* 33 */
- cdev_notdef(), /* 34 */
+ cdev_tty_init(NRP,rp), /* 34: Comtrol RocketPort serial port */
cdev_notdef(), /* 35: Microsoft mouse */
cdev_notdef(), /* 36: Logitech mouse */
cdev_notdef(), /* 37: Extended PS/2 mouse */
Index: sys/arch/amd64/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.493
diff -u -p -r1.493 GENERIC
--- sys/arch/amd64/conf/GENERIC 15 Sep 2020 18:31:14 - 1.493
+++ sys/arch/amd64/conf/GENERIC 2 Oct 2020 17:08:39 -
@@ -399,6 +399,7 @@ com*at puc?
# options CY_HW_RTS
#cy* at pci? # PCI cyclom serial card
#cz* at pci? # Cyclades-Z multi-port serial boards
+rp*at pci?
fix: ospf6d(8): wrong intra area announcement
Hi,
The new intra area db entry has to be saved into the tree before
orig_intra_area_prefix_lsas() is called. If not, the ospf6d will not
announce the new intra area db for a newly learned link from another
ospf router of the broadcast domain.
This bug is triggered, if you add new addresses an ospf interface while
the ospf6d is already running as a backup designated router. The
opposite designated ospf6d will get your new link announcement and
return an old intra area db without the new address.
Beside of the fix, the diff removes redundant code. I made the same
diff for the ospfd to keep code in sync and remove redundant code there,
too. ospfd does not have the bug explained above, as far as I know.
Both regression tests passes with this diff.
OK?
Bye,
Jan
Index: ospf6d/rde_lsdb.c
===
RCS file: /cvs//src/usr.sbin/ospf6d/rde_lsdb.c,v
retrieving revision 1.45
diff -u -p -r1.45 rde_lsdb.c
--- ospf6d/rde_lsdb.c 21 Aug 2020 10:17:35 - 1.45
+++ ospf6d/rde_lsdb.c 1 Oct 2020 23:09:38 -
@@ -467,6 +467,7 @@ lsa_add(struct rde_nbr *nbr, struct lsa
struct lsa_tree *tree;
struct vertex *new, *old;
struct timeval tv, now, res;
+ int update = 1;
if (LSA_IS_SCOPE_AS(ntohs(lsa->hdr.type)))
tree = _tree;
@@ -495,16 +496,13 @@ lsa_add(struct rde_nbr *nbr, struct lsa
fatal("lsa_add");
return (1);
}
- if (!lsa_equal(new->lsa, old->lsa)) {
- if (ntohs(lsa->hdr.type) == LSA_TYPE_LINK)
- orig_intra_area_prefix_lsas(nbr->area);
- if (ntohs(lsa->hdr.type) != LSA_TYPE_EXTERNAL)
- nbr->area->dirty = 1;
- start_spf_timer();
- }
+ if (lsa_equal(new->lsa, old->lsa))
+ update = 0;
vertex_free(old);
RB_INSERT(lsa_tree, tree, new);
- } else {
+ }
+
+ if (update) {
if (ntohs(lsa->hdr.type) == LSA_TYPE_LINK)
orig_intra_area_prefix_lsas(nbr->area);
if (ntohs(lsa->hdr.type) != LSA_TYPE_EXTERNAL)
Index: ospfd/rde_lsdb.c
===
RCS file: /cvs//src/usr.sbin/ospfd/rde_lsdb.c,v
retrieving revision 1.50
diff -u -p -r1.50 rde_lsdb.c
--- ospfd/rde_lsdb.c22 Nov 2015 13:09:10 - 1.50
+++ ospfd/rde_lsdb.c1 Oct 2020 23:06:57 -
@@ -383,6 +383,7 @@ lsa_add(struct rde_nbr *nbr, struct lsa
struct lsa_tree *tree;
struct vertex *new, *old;
struct timeval tv, now, res;
+ int update = 1;
if (lsa->hdr.type == LSA_TYPE_EXTERNAL ||
lsa->hdr.type == LSA_TYPE_AS_OPAQ)
@@ -410,15 +411,13 @@ lsa_add(struct rde_nbr *nbr, struct lsa
fatal("lsa_add");
return (1);
}
- if (!lsa_equal(new->lsa, old->lsa)) {
- if (lsa->hdr.type != LSA_TYPE_EXTERNAL &&
- lsa->hdr.type != LSA_TYPE_AS_OPAQ)
- nbr->area->dirty = 1;
- start_spf_timer();
- }
+ if (lsa_equal(new->lsa, old->lsa))
+ update = 0;
vertex_free(old);
RB_INSERT(lsa_tree, tree, new);
- } else {
+ }
+
+ if (update) {
if (lsa->hdr.type != LSA_TYPE_EXTERNAL &&
lsa->hdr.type != LSA_TYPE_AS_OPAQ)
nbr->area->dirty = 1;
Re: snmpd(8) Remove struct listen_sock
On Sun, Aug 09, 2020 at 04:10:13PM +0200, Martijn van Duren wrote:
> I still want to move udp/tcp handling out of snmpe, so that there's
> better layering, but my previous diff never got any response and might
> do with some more polishing.
>
> For now, lets remove listen_sock from snmpd, since there's a 1:1
> correlation with struct address. This saves a couple of callocs during
> startup and 18 LoC.
>
> OK?
OK jan@
> martijn@
>
> Index: parse.y
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
> retrieving revision 1.58
> diff -u -p -r1.58 parse.y
> --- parse.y 30 Jun 2020 17:11:49 - 1.58
> +++ parse.y 9 Aug 2020 14:08:18 -
> @@ -997,7 +997,6 @@ parse_config(const char *filename, u_int
> conf->sc_flags = flags;
> conf->sc_confpath = filename;
> TAILQ_INIT(>sc_addresses);
> - TAILQ_INIT(>sc_sockets);
> strlcpy(conf->sc_rdcommunity, "public", SNMPD_MAXCOMMUNITYLEN);
> strlcpy(conf->sc_rwcommunity, "private", SNMPD_MAXCOMMUNITYLEN);
> strlcpy(conf->sc_trcommunity, "public", SNMPD_MAXCOMMUNITYLEN);
> Index: snmpd.h
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
> retrieving revision 1.88
> diff -u -p -r1.88 snmpd.h
> --- snmpd.h 8 Aug 2020 13:39:57 - 1.88
> +++ snmpd.h 9 Aug 2020 14:08:18 -
> @@ -482,6 +482,9 @@ struct address {
> struct sockaddr_storage ss;
> in_port_tport;
> int ipproto;
> + int fd;
> + struct event ev;
> + struct event evt;
>
> TAILQ_ENTRY(address) entry;
>
> @@ -492,15 +495,6 @@ struct address {
> };
> TAILQ_HEAD(addresslist, address);
>
> -struct listen_sock {
> - int s_fd;
> - int s_ipproto;
> - struct events_ev;
> - struct events_evt;
> - TAILQ_ENTRY(listen_sock)entry;
> -};
> -TAILQ_HEAD(socklist, listen_sock);
> -
> enum usmauth {
> AUTH_NONE = 0,
> AUTH_MD5, /* HMAC-MD5-96, RFC3414 */
> @@ -545,7 +539,6 @@ struct snmpd {
>
> const char *sc_confpath;
> struct addresslist sc_addresses;
> - struct socklist sc_sockets;
> struct timeval sc_starttime;
> u_int32_tsc_engine_boots;
>
> Index: snmpe.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 snmpe.c
> --- snmpe.c 8 Aug 2020 13:39:57 - 1.63
> +++ snmpe.c 9 Aug 2020 14:08:18 -
> @@ -68,7 +68,6 @@ snmpe(struct privsep *ps, struct privsep
> {
> struct snmpd*env = ps->ps_env;
> struct address *h;
> - struct listen_sock *so;
> #ifdef DEBUG
> char buf[BUFSIZ];
> struct oid *oid;
> @@ -82,14 +81,9 @@ snmpe(struct privsep *ps, struct privsep
> #endif
>
> /* bind SNMP UDP/TCP sockets */
> - TAILQ_FOREACH(h, >sc_addresses, entry) {
> - if ((so = calloc(1, sizeof(*so))) == NULL)
> - fatal("snmpe: %s", __func__);
> - if ((so->s_fd = snmpe_bind(h)) == -1)
> + TAILQ_FOREACH(h, >sc_addresses, entry)
> + if ((h->fd = snmpe_bind(h)) == -1)
> fatal("snmpe: failed to bind SNMP socket");
> - so->s_ipproto = h->ipproto;
> - TAILQ_INSERT_TAIL(>sc_sockets, so, entry);
> - }
>
> proc_run(ps, p, procs, nitems(procs), snmpe_init, NULL);
> }
> @@ -99,7 +93,7 @@ void
> snmpe_init(struct privsep *ps, struct privsep_proc *p, void *arg)
> {
> struct snmpd*env = ps->ps_env;
> - struct listen_sock *so;
> + struct address *h;
>
> kr_init();
> trap_init();
> @@ -107,17 +101,17 @@ snmpe_init(struct privsep *ps, struct pr
> usm_generate_keys();
>
> /* listen for incoming SNMP UDP/TCP messages */
> - TAILQ_FOREACH(so, >sc_sockets, entry) {
> - if (so->s_ipproto == IPPROTO_TCP) {
> - if (listen(so->s_fd, 5) < 0)
> + TAILQ_FOREACH(h, >sc_addresses, entry) {
> + if (h->ipproto == IPPROTO_TCP) {
> + if (listen(h->fd, 5) < 0)
> fatalx("snmpe: failed to listen on socket");
> - event_set(>s_ev, so->s_fd, EV_READ, snmpe_acceptcb,
> so);
> - evtimer_set(>s_evt, snmpe_acceptcb, so);
> + event_set(>ev, h->fd, EV_READ, snmpe_acceptcb, h);
> + evtimer_set(>evt, snmpe_acceptcb, h);
> } else {
> - event_set(>s_ev, so->s_fd, EV_READ|EV_PERSIST,
> + event_set(>ev, h->fd,
diff: simplify ospf6d code
Hi,
The following diff simplifies a switch case statement with no functional
change.
In case of IMSG_CTL_SHOW_DATABASE duplicated code is removed. This part
of the code is now the same as in ospfd.
In case of IMSG_CTL_SHOW_DB_INTRA the code was also duplicated and due
to a missing continue the v->type variable was double check.
OK?
bye,
Jan
Index: rde_lsdb.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/rde_lsdb.c,v
retrieving revision 1.43
diff -u -p -r1.43 rde_lsdb.c
--- rde_lsdb.c 17 Feb 2020 08:12:22 - 1.43
+++ rde_lsdb.c 21 Aug 2020 07:52:15 -
@@ -763,9 +763,7 @@ lsa_dump(struct lsa_tree *tree, int imsg
lsa_age(v);
switch (imsg_type) {
case IMSG_CTL_SHOW_DATABASE:
- rde_imsg_compose_ospfe(IMSG_CTL_SHOW_DATABASE, 0, pid,
- >lsa->hdr, ntohs(v->lsa->hdr.len));
- continue;
+ break;
case IMSG_CTL_SHOW_DB_SELF:
if (v->lsa->hdr.adv_rtr == rde_router_id())
break;
@@ -787,8 +785,6 @@ lsa_dump(struct lsa_tree *tree, int imsg
break;
continue;
case IMSG_CTL_SHOW_DB_INTRA:
- if (v->type == LSA_TYPE_INTRA_A_PREFIX)
- break;
case IMSG_CTL_SHOW_DB_SUM:
if (v->type == LSA_TYPE_INTER_A_PREFIX)
break;
diff: uvm: fix unitialized var and simplify code in km_alloc()
Hi,
The function km_alloc() returns the uninitialized local variable sva if
pgl is empty. It seems to be not possible in the current condition of
the code, but I'm not sure if this is guaranteed. Thus, I would prefer
to initialize sva with zero.
It also seems to be unnecessary to loop over the whole pagelist to find
the first element. The marco pmap_map_direct() just does some
calculations and the value of va is discarded.
I build and run the code on amd64 without any issue and regress/sys/uvm
also doesn't show any problems with that diff.
OK?
bye,
Jan
Index: uvm/uvm_km.c
===
RCS file: /cvs/src/sys/uvm/uvm_km.c,v
retrieving revision 1.136
diff -u -p -r1.136 uvm_km.c
--- uvm/uvm_km.c18 Feb 2020 12:13:40 - 1.136
+++ uvm/uvm_km.c20 May 2020 06:17:41 -
@@ -816,7 +816,7 @@ km_alloc(size_t sz, const struct kmem_va
paddr_t pla_align;
int pla_flags;
int pla_maxseg;
- vaddr_t va, sva;
+ vaddr_t va, sva = 0;
KASSERT(sz == round_page(sz));
@@ -851,11 +851,8 @@ km_alloc(size_t sz, const struct kmem_va
* allocations.
*/
if (kv->kv_singlepage || kp->kp_maxseg == 1) {
- TAILQ_FOREACH(pg, , pageq) {
- va = pmap_map_direct(pg);
- if (pg == TAILQ_FIRST())
- sva = va;
- }
+ if ((pg = TAILQ_FIRST()) != NULL)
+ sva = pmap_map_direct(pg);
return ((void *)sva);
}
#endif
Re: diff: em(4) deadlock fix
On Fri, May 08, 2020 at 04:36:28PM +0200, Mark Kettenis wrote: > > Date: Fri, 8 May 2020 15:39:26 +0200 > > From: Jan Klemkow > > On Mon, Apr 27, 2020 at 10:42:52AM +0200, Martin Pieuchot wrote: > > > So the current logic assumes that as long as the ring contains descriptors > > > em_rxrefill() failures aren't fatal and it is not necessary to schedule a > > > refill. Why? > > > > I'm not sure. I just figured out, what I described below. > > > > > Unless we understand this it is difficult to reason about a fix. Have > > > you looked at other drivers, is it a common pattern? > > > > Drivers like iavf(4) and ixl(4) just set the timeout when the alive > > (if_rxr_inuse returns) counter is 0. Other drivers like ix(4) and > > bnx(4) call the timeout, when refill was not possible. > > > > I adjust the patch to the behavior of ix(4). (see below). > > > > > > In my case, the function em_rxeof is unable to pull the last one or two > > > > mbufs from the receive ring, because the descriptor status hasn't set > > > > the "descriptor done" flag (E1000_RXD_STAT_DD). Thus, the ring has one > > > > or two remaining mbufs, and the timeout to put new ones in is never set. > > > > When new mbufs are available later, the em driver stays in that > > > > situation. > > > > > > Are you saying there's always some descriptor on the ring? Did you > > > investigate why? > > > > Yes, with printf-debugging: I see that we return from em_rxeof() > > because the status bit E1000_RXD_STAT_DD is not set. And systat(8) > > shows one or two remaining mbufs in the ALIVE column. > > > > > > The diff always sets the timeout to put new mbufs in the receive ring, > > > > when it has lesser mbufs then the "low water mark". > > > > > > This changes the logic explained above. With it the fatal condition > > > changes from 0 to `lwm'. Another possible fix would be to always > > > schedule a timeout as soon as em_rxrefill() fails. > > > > I adjusted the patch to this behavior, as I mentioned above. > > > > > I'm not advocating for a particular change, I'm suggesting we understand > > > the current logic and its implications. > > > > The logic looks to me like: The NIC should first fill the last mbuf > > (descriptor), then we set a timeout to refill new mbufs (descriptors). > > It seems to me, that one or two mbufs maybe some kind of small to > > operate correctly?! > > > > But, as far as I understand the documentation of Intel, It should be > > find to deal with such a low amount of mbufs. I couldn't find any text > > that said, the firmware needs a minimum amount of DMA memory. > > Sorry, I was going to reply earlier to this mail thread. > > As far as I know, OpenBSD is the only OS that tries to run with > partially filled rings. When we started doing this we quickly found > out that there was hardware out there that didn't work with only a > single descriptor on the Rx ring. This is why we introduced the low > water mark. Should I make similar diffs for drivers that check for 0 descriptors as well? > I'm not certain if we ever found this documented unambiguously the the > hardware documentation available to us. But there certainly are hints > that indicate that descriptors are read a full cache-line at a time. > And if the descrioptor size is 16 bytes, you need 4 descriptors to > fill a 64-byte cache line. Good to know. > So what you were proposing in your first diff makes sense. It maight > make sense to introduce a function to check the limit though, perhaps > something like if_rxr_needfill() that returns true if the number of > descriptors on the ring is below the low water mark. What do you think of this diff, OK? Thanks, Jan Index: share/man/man9/if_rxr_init.9 === RCS file: /cvs/src/share/man/man9/if_rxr_init.9,v retrieving revision 1.7 diff -u -p -r1.7 if_rxr_init.9 --- share/man/man9/if_rxr_init.917 Nov 2017 03:51:32 - 1.7 +++ share/man/man9/if_rxr_init.99 May 2020 06:40:46 - @@ -35,6 +35,8 @@ .Fn if_rxr_put "struct if_rxring *rxr" "unsigned int n" .Ft void .Fn if_rxr_livelocked "struct if_rxring *rxr" +.Ft int +.Fn if_rxr_needrefill "struct if_rxring *rxr" .Ft unsigned int .Fn if_rxr_inuse "struct if_rxring *rxr" .Ft unsigned int @@ -88,6 +90,10 @@ receive descriptor slots to the ring. .Fn if_rxr_livelocked can signal that that receive ring is generating too much load. .Pp +.Fn if
Re: diff: em(4) deadlock fix
On Mon, Apr 27, 2020 at 10:42:52AM +0200, Martin Pieuchot wrote: > On 21/04/20(Tue) 15:54, Jan Klemkow wrote: > > The following diff fixes a deadlock in em(4) when system runs out of > > mbuf(9)s. > > > > Tested with current on amd64 with: > > em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x05: msi, mac 0x1e phy > > 0xb, address d0:50:99:c1:67:94 > > > > When the system runs out of mbufs, the receive ring of the em-NIC also > > run out of mbufs. If the driver puts an mbuf from the NICs receive ring > > with em_rxeof, it calls em_rxrefill to refill the ring. If its not > > possible to refill the ring and the receive ring is empty, it sets a > > timer to retry refilling later till new mbufs are available. > > So the current logic assumes that as long as the ring contains descriptors > em_rxrefill() failures aren't fatal and it is not necessary to schedule a > refill. Why? I'm not sure. I just figured out, what I described below. > Unless we understand this it is difficult to reason about a fix. Have > you looked at other drivers, is it a common pattern? Drivers like iavf(4) and ixl(4) just set the timeout when the alive (if_rxr_inuse returns) counter is 0. Other drivers like ix(4) and bnx(4) call the timeout, when refill was not possible. I adjust the patch to the behavior of ix(4). (see below). > > In my case, the function em_rxeof is unable to pull the last one or two > > mbufs from the receive ring, because the descriptor status hasn't set > > the "descriptor done" flag (E1000_RXD_STAT_DD). Thus, the ring has one > > or two remaining mbufs, and the timeout to put new ones in is never set. > > When new mbufs are available later, the em driver stays in that > > situation. > > Are you saying there's always some descriptor on the ring? Did you > investigate why? Yes, with printf-debugging: I see that we return from em_rxeof() because the status bit E1000_RXD_STAT_DD is not set. And systat(8) shows one or two remaining mbufs in the ALIVE column. > > The diff always sets the timeout to put new mbufs in the receive ring, > > when it has lesser mbufs then the "low water mark". > > This changes the logic explained above. With it the fatal condition > changes from 0 to `lwm'. Another possible fix would be to always > schedule a timeout as soon as em_rxrefill() fails. I adjusted the patch to this behavior, as I mentioned above. > I'm not advocating for a particular change, I'm suggesting we understand > the current logic and its implications. The logic looks to me like: The NIC should first fill the last mbuf (descriptor), then we set a timeout to refill new mbufs (descriptors). It seems to me, that one or two mbufs maybe some kind of small to operate correctly?! But, as far as I understand the documentation of Intel, It should be find to deal with such a low amount of mbufs. I couldn't find any text that said, the firmware needs a minimum amount of DMA memory. > This bugs reminds me of sthen@'s change to be able to stability use NFS > on a port machine. I wonder if they have something in common. > > > A side effect is: when the mbufs in use (alive) are below then the "low > > water mark", the "current water mark" raises up to value of the "high > > water mark". When new mbufs are available the number of mbufs in use > > also raises to that value. Because, the "current water mark" just sinks > > during net livelocks. Thanks, Jan Index: dev/pci/if_em.c === RCS file: /cvs/src/sys/dev/pci/if_em.c,v retrieving revision 1.351 diff -u -p -r1.351 if_em.c --- dev/pci/if_em.c 26 Apr 2020 20:49:56 - 1.351 +++ dev/pci/if_em.c 8 May 2020 08:49:40 - @@ -2833,7 +2833,7 @@ em_rxrefill(void *arg) if (em_rxfill(que)) E1000_WRITE_REG(>hw, RDT(que->me), que->rx.sc_rx_desc_head); - else if (if_rxr_inuse(>rx.sc_rx_ring) == 0) + else timeout_add(>rx_refill, 1); }
Re: patch: Enable dock audio on Thinkpad dock (Thinkpad L460)
On Thu, Apr 16, 2020 at 05:59:44PM -0500, Abel Abraham Camarillo Ojeda wrote: > On Tuesday, February 11, 2020, Abel Abraham Camarillo Ojeda > wrote: > > On Wednesday, January 8, 2020, Abel Abraham Camarillo Ojeda > > wrote: > >> On Mon, Dec 30, 2019 at 1:24 PM Abel Abraham Camarillo Ojeda > >> wrote: > >> > >>> The following enables audio via the dock station port in my > >>> thinkpad L460. But, anyone knows if its possible to automatically > >>> disable the laptop speaker when I plug in the audio port in the > >>> dock? it doesn't appear to have a *_sense, ideas? > >>> > >>> this also enables the annoying beep (echo -e "\a"; in console) > >>> > >>> patch inline and attached: > >> Hi, comments, oks? > > Anyone? > Hi, any ok, comments? Hi Abel, Thanks for your diff. Please add an applicable diff inline in your mail next time and don't attach it. I can't test the diff with the right hardware. But, the patch applies, builds and doesn't break audio on my ThinkPad X1C6. The diff also looks fine for me. bye, Jan Index: azalia_codec.c === RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v retrieving revision 1.178 diff -u -p -r1.178 azalia_codec.c --- azalia_codec.c 14 Oct 2019 02:04:35 - 1.178 +++ azalia_codec.c 27 Apr 2020 07:42:45 - @@ -159,6 +159,17 @@ azalia_codec_init_vtbl(codec_t *this) this->subid == 0x503c17aa) this->qrks |= AZ_QRK_WID_TPDOCK2; break; + case 0x10ec0293: + this->name = "Realtek ALC293"; + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D; + + /* +* Enable dock audio on Thinkpad docks +* 0x17aa : 0x5051 = Thinkpad L460 +*/ + if (this->subid == 0x505117aa) + this->qrks |= AZ_QRK_WID_TPDOCK2; + break; case 0x10ec0298: this->name = "Realtek ALC298"; if (this->subid == 0x320019e5 ||
diff: em(4) deadlock fix
Hi,
The following diff fixes a deadlock in em(4) when system runs out of
mbuf(9)s.
Tested with current on amd64 with:
em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x05: msi, mac 0x1e phy 0xb,
address d0:50:99:c1:67:94
When the system runs out of mbufs, the receive ring of the em-NIC also
run out of mbufs. If the driver puts an mbuf from the NICs receive ring
with em_rxeof, it calls em_rxrefill to refill the ring. If its not
possible to refill the ring and the receive ring is empty, it sets a
timer to retry refilling later till new mbufs are available.
In my case, the function em_rxeof is unable to pull the last one or two
mbufs from the receive ring, because the descriptor status hasn't set
the "descriptor done" flag (E1000_RXD_STAT_DD). Thus, the ring has one
or two remaining mbufs, and the timeout to put new ones in is never set.
When new mbufs are available later, the em driver stays in that
situation.
The diff always sets the timeout to put new mbufs in the receive ring,
when it has lesser mbufs then the "low water mark".
A side effect is: when the mbufs in use (alive) are below then the "low
water mark", the "current water mark" raises up to value of the "high
water mark". When new mbufs are available the number of mbufs in use
also raises to that value. Because, the "current water mark" just sinks
during net livelocks.
I'm sure this path is not the best solution. Maybe someone else has a
better idea to avoid that situation?!
Bye,
Jan
Index: dev/pci/if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.349
diff -u -p -r1.349 if_em.c
--- dev/pci/if_em.c 24 Mar 2020 09:30:06 - 1.349
+++ dev/pci/if_em.c 21 Apr 2020 12:02:28 -
@@ -2809,7 +2809,8 @@ em_rxrefill(void *arg)
if (em_rxfill(que))
E1000_WRITE_REG(>hw, RDT(que->me), que->rx.sc_rx_desc_head);
- else if (if_rxr_inuse(>rx.sc_rx_ring) == 0)
+ else if (if_rxr_inuse(>rx.sc_rx_ring) <
+ if_rxr_lwm(>rx.sc_rx_ring))
timeout_add(>rx_refill, 1);
}
Index: net/if_var.h
===
RCS file: /cvs/src/sys/net/if_var.h,v
retrieving revision 1.104
diff -u -p -r1.104 if_var.h
--- net/if_var.h12 Apr 2020 07:02:43 - 1.104
+++ net/if_var.h21 Apr 2020 11:58:17 -
@@ -389,6 +389,7 @@ u_int if_rxr_get(struct if_rxring *, u_i
#define if_rxr_put(_r, _c) do { (_r)->rxr_alive -= (_c); } while (0)
#define if_rxr_inuse(_r) ((_r)->rxr_alive)
#define if_rxr_cwm(_r) ((_r)->rxr_cwm)
+#define if_rxr_lwm(_r) ((_r)->rxr_lwm)
intif_rxr_info_ioctl(struct if_rxrinfo *, u_int, struct if_rxring_info *);
intif_rxr_ioctl(struct if_rxrinfo *, const char *, u_int,
Re: snmpd(8): fix use of uninitialized pointer
On Tue, Mar 10, 2020 at 06:25:10PM +0100, Martijn van Duren wrote:
> So I did some last minute testing of my own and apparently I misread.
> A varbindlist means a new sequence of varbinds, while the code assumes
> a list of varbinds.
>
> Code below actually works and also gives the additional varbinds to
> the trap handle "command".
>
> Now actually asking for OKs. :-)
OK jan@
> On 3/10/20 1:43 PM, Jan Klemkow wrote:
> > On Tue, Mar 10, 2020 at 01:13:46PM +0100, Martijn van Duren wrote:
> >> On 3/10/20 10:21 AM, Jan Klemkow wrote:
> >>> On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote:
> >>>> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a
> >>>> varbindlist.
> >>>>
> >>>> Could you test the diff below?
> >>>
> >>> Is also OK for me and the current call path seems to be clean.
> >>> But, shouldn't we set iter to NULL anyway?
> >>
> >> If we state that traphandler_parse must initialize *vbinds, then not
> >> setting it allows us to differentiate between undefined behaviour
> >> (initialized to garbage) and no varbindlist. The first one will only
> >> show its head if someone screws up a refactor.
> >> But if you feel strongly about it we can initialize it.
> >
> > I don't feel strong about it. Commit your change and I fine with it.
> >
> > OK jan@
> >
> >>>> On 3/9/20 11:38 PM, Jan Klemkow wrote:
> >>>>> Hi,
> >>>>>
> >>>>> The following diff fixes the use of the uninitialized pointer iter
> >>>>> in trapcmd_exec().
> >>>>>
> >>>>> iter is just initialized in traphandler_parse() if vers is SNMP_V2. In
> >>>>> all other cases iter stays uninitialized and may dereferenced in
> >>>>> trapcmd_exec().
> >>>>>
> >>>>> OK?
> >>>>>
> >>>>> bye,
> >>>>> Jan
>
> Index: traphandler.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/traphandler.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 traphandler.c
> --- traphandler.c 24 Oct 2019 12:39:27 - 1.15
> +++ traphandler.c 10 Mar 2020 17:23:51 -
> @@ -232,10 +232,13 @@ traphandler_parse(char *buf, size_t n, s
>
> switch (vers) {
> case SNMP_V1:
> - if (ober_scanf_elements(elm, "{oSddd",
> - trapoid, , , uptime) == -1)
> + if (ober_scanf_elements(elm, "{oSddde",
> + trapoid, , , uptime, ) == -1)
> goto done;
> traphandler_v1translate(trapoid, gtype, etype);
> + if (elm->be_type != BER_TYPE_SEQUENCE)
> + goto done;
> + *vbinds = elm->be_sub;
> break;
>
> case SNMP_V2:
>
Re: snmpd(8): fix use of uninitialized pointer
On Tue, Mar 10, 2020 at 01:13:46PM +0100, Martijn van Duren wrote: > On 3/10/20 10:21 AM, Jan Klemkow wrote: > > On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote: > >> Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a > >> varbindlist. > >> > >> Could you test the diff below? > > > > Is also OK for me and the current call path seems to be clean. > > But, shouldn't we set iter to NULL anyway? > > If we state that traphandler_parse must initialize *vbinds, then not > setting it allows us to differentiate between undefined behaviour > (initialized to garbage) and no varbindlist. The first one will only > show its head if someone screws up a refactor. > But if you feel strongly about it we can initialize it. I don't feel strong about it. Commit your change and I fine with it. OK jan@ > >> On 3/9/20 11:38 PM, Jan Klemkow wrote: > >>> Hi, > >>> > >>> The following diff fixes the use of the uninitialized pointer iter > >>> in trapcmd_exec(). > >>> > >>> iter is just initialized in traphandler_parse() if vers is SNMP_V2. In > >>> all other cases iter stays uninitialized and may dereferenced in > >>> trapcmd_exec(). > >>> > >>> OK? > >>> > >>> bye, > >>> Jan > >>> > >> > >> Index: traphandler.c > >> === > >> RCS file: /cvs/src/usr.sbin/snmpd/traphandler.c,v > >> retrieving revision 1.15 > >> diff -u -p -r1.15 traphandler.c > >> --- traphandler.c 24 Oct 2019 12:39:27 - 1.15 > >> +++ traphandler.c 9 Mar 2020 23:26:56 - > >> @@ -236,6 +236,8 @@ traphandler_parse(char *buf, size_t n, s > >>trapoid, , , uptime) == -1) > >>goto done; > >>traphandler_v1translate(trapoid, gtype, etype); > >> + *vbinds = > >> + elm->be_sub->be_next->be_next->be_next->be_next->be_next; > >>break; > >> > >>case SNMP_V2: > >> >
Re: snmpd(8): fix use of uninitialized pointer
On Tue, Mar 10, 2020 at 12:27:20AM +0100, Martijn van Duren wrote: > Looking at RFC1157 section 4.1.6, an snmpv1 trap should also contain a > varbindlist. > > Could you test the diff below? Is also OK for me and the current call path seems to be clean. But, shouldn't we set iter to NULL anyway? bye, Jan > On 3/9/20 11:38 PM, Jan Klemkow wrote: > > Hi, > > > > The following diff fixes the use of the uninitialized pointer iter > > in trapcmd_exec(). > > > > iter is just initialized in traphandler_parse() if vers is SNMP_V2. In > > all other cases iter stays uninitialized and may dereferenced in > > trapcmd_exec(). > > > > OK? > > > > bye, > > Jan > > > > Index: traphandler.c > === > RCS file: /cvs/src/usr.sbin/snmpd/traphandler.c,v > retrieving revision 1.15 > diff -u -p -r1.15 traphandler.c > --- traphandler.c 24 Oct 2019 12:39:27 - 1.15 > +++ traphandler.c 9 Mar 2020 23:26:56 - > @@ -236,6 +236,8 @@ traphandler_parse(char *buf, size_t n, s > trapoid, , , uptime) == -1) > goto done; > traphandler_v1translate(trapoid, gtype, etype); > + *vbinds = > + elm->be_sub->be_next->be_next->be_next->be_next->be_next; > break; > > case SNMP_V2: >
snmpd(8): fix use of uninitialized pointer
Hi, The following diff fixes the use of the uninitialized pointer iter in trapcmd_exec(). iter is just initialized in traphandler_parse() if vers is SNMP_V2. In all other cases iter stays uninitialized and may dereferenced in trapcmd_exec(). OK? bye, Jan Index: traphandler.c === RCS file: /cvs/src/usr.sbin/snmpd/traphandler.c,v retrieving revision 1.15 diff -u -p -r1.15 traphandler.c --- traphandler.c 24 Oct 2019 12:39:27 - 1.15 +++ traphandler.c 9 Mar 2020 21:59:56 - @@ -305,7 +305,7 @@ traphandler_fork_handler(struct privsep_ struct sockaddr *sa; char*buf; ssize_t n; - struct ber_element *req, *iter; + struct ber_element *req, *iter = NULL; struct trapcmd *cmd; struct ber_oid trapoid; u_intuptime;
Re: diff: simplify globbing in ftpd(8)
On Mon, Jan 13, 2020 at 10:30:11AM -0700, Todd C. Miller wrote:
> On Mon, 13 Jan 2020 13:45:55 +0100, Jan Klemkow wrote:
>
> > This diff simplifies globbing for the ftpd(8) ls and stat command. And
> > it avoids to glob for the parameters "-lgA".
> >
> > Due, we just pass a single string to the ftpd_ls() function, we don't
> > need to provide infrastructure for a dynamic list of arguments.
>
> This conflicts with the diff to support NLIST arguments from SASANO
> Takayoshi. I think we can support this by adding a flag to ftpd_ls()
> that indicates whether it is a long list or not.
Here is an improved version of the diff, but as I explaind here [1]
without argument injection. I stopped argument injection by adding
"--" before client paramenters for ls(1).
[1]: https://marc.info/?l=openbsd-tech=157900764005335=2
OK?
Thanks,
Jan
Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.20
diff -u -p -r1.20 extern.h
--- extern.h8 May 2019 23:56:48 - 1.20
+++ extern.h13 Jan 2020 11:03:39 -
@@ -68,7 +68,7 @@ void delete(char *);
void dologout(int);
void fatal(char *);
intftpd_pclose(FILE *, pid_t);
-FILE *ftpd_ls(char *, char *, pid_t *);
+FILE *ftpd_ls(const char *, pid_t *);
int get_line(char *, int, FILE *);
void ftpdlogwtmp(char *, char *, char *);
void lreply(int, const char *, ...);
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.228
diff -u -p -r1.228 ftpd.c
--- ftpd.c 3 Jul 2019 03:24:04 - 1.228
+++ ftpd.c 13 Jan 2020 11:15:31 -
@@ -1124,7 +1124,7 @@ retrieve(enum ret_cmd cmd, char *name)
fin = fopen(name, "r");
st.st_size = 0;
} else {
- fin = ftpd_ls("-lgA", name, );
+ fin = ftpd_ls(name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
@@ -1730,7 +1730,7 @@ statfilecmd(char *filename)
int c;
int atstart;
pid_t pid;
- fin = ftpd_ls("-lgA", filename, );
+ fin = ftpd_ls(filename, );
if (fin == NULL) {
reply(451, "Local resource failure");
return;
Index: popen.c
===
RCS file: /cvs/src/libexec/ftpd/popen.c,v
retrieving revision 1.28
diff -u -p -r1.28 popen.c
--- popen.c 28 Jun 2019 13:32:53 - 1.28
+++ popen.c 14 Jan 2020 18:54:52 -
@@ -60,51 +60,45 @@
#define MAX_GARGV 1000
FILE *
-ftpd_ls(char *arg, char *path, pid_t *pidptr)
+ftpd_ls(const char *path, pid_t *pidptr)
{
char *cp;
FILE *iop;
- int argc = 0, gargc, pdes[2];
+ int argc = 0, pdes[2];
pid_t pid;
- char **pop, *argv[MAX_ARGV], *gargv[MAX_GARGV];
+ char **pop, *argv[MAX_ARGV];
if (pipe(pdes) == -1)
return (NULL);
/* break up string into pieces */
argv[argc++] = "/bin/ls";
- if (arg != NULL)
- argv[argc++] = arg;
- if (path != NULL)
- argv[argc++] = path;
- argv[argc] = NULL;
- argv[MAX_ARGV-1] = NULL;
+ argv[argc++] = "-lgA";
+ argv[argc++] = "--";
- /* glob each piece */
- gargv[0] = argv[0];
- for (gargc = argc = 1; argv[argc]; argc++) {
+ /* glob that path */
+ if (path != NULL) {
glob_t gl;
memset(, 0, sizeof(gl));
- if (glob(argv[argc],
+ if (glob(path,
GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE|GLOB_LIMIT,
NULL, )) {
- if (gargc < MAX_GARGV-1) {
- gargv[gargc++] = strdup(argv[argc]);
- if (gargv[gargc -1] == NULL)
- fatal ("Out of memory.");
- }
+ argv[argc++] = strdup(path);
+ if (argv[argc -1] == NULL)
+ fatal ("Out of memory.");
} else if (gl.gl_pathc > 0) {
- for (pop = gl.gl_pathv; *pop && gargc < MAX_GARGV-1;
pop++) {
- gargv[gargc++] = strdup(*pop);
- if (gargv[gargc - 1] == NULL)
+ for (pop = gl.gl_pathv; *pop && argc < MAX_GARGV-1;
pop++) {
+ argv[argc++] = strdup(*pop);
+ if (argv[argc - 1] == NULL)
fatal ("Out of memory.");
}
}
Re: [PATCH] src/libexec/ftpd: fix nlist with -option does not work
On Mon, Nov 18, 2019 at 02:56:46PM +0900, SASANO Takayoshi wrote: > At least OpenBSD-6.5 and 6.6's ftpd does not work NLIST command with > any -option like this. > > > ftp> nlist > 150 Opening ASCII mode data connection for 'file list'. > uaa > _sysupgrade > 226 Transfer complete. > ftp> nlist -LF > 550 -LF: No such file or directory. > ftp> > > > Here is the remedy, ok? I don't like the idea to let the client call custom options of ls(1). It seems to be secure, but no one knows what options will implemented in ls(1) in the future. Also the FTP RFC does not mention custom options, as far as I can see. It's just possible to do that, because traditional ftp daemons (like ours) call ls(1). I'm more interested in avoiding option insertion by put a "--" before the clients parameters. bye, Jan
Re: diff: simplify globbing in ftpd(8)
On Mon, Jan 13, 2020 at 10:30:11AM -0700, Todd C. Miller wrote: > On Mon, 13 Jan 2020 13:45:55 +0100, Jan Klemkow wrote: > > This diff simplifies globbing for the ftpd(8) ls and stat command. And > > it avoids to glob for the parameters "-lgA". > > > > Due, we just pass a single string to the ftpd_ls() function, we don't > > need to provide infrastructure for a dynamic list of arguments. > > This conflicts with the diff to support NLIST arguments from SASANO > Takayoshi. I think we can support this by adding a flag to ftpd_ls() > that indicates whether it is a long list or not. Oh, I missed that. And will it checkout first. Thanks.
diff: simplify globbing in ftpd(8)
Hi,
This diff simplifies globbing for the ftpd(8) ls and stat command. And
it avoids to glob for the parameters "-lgA".
Due, we just pass a single string to the ftpd_ls() function, we don't
need to provide infrastructure for a dynamic list of arguments.
Tested it manually and by regression test.
OK?
Bye,
Jan
Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.20
diff -u -p -r1.20 extern.h
--- extern.h8 May 2019 23:56:48 - 1.20
+++ extern.h13 Jan 2020 11:03:39 -
@@ -68,7 +68,7 @@ void delete(char *);
void dologout(int);
void fatal(char *);
intftpd_pclose(FILE *, pid_t);
-FILE *ftpd_ls(char *, char *, pid_t *);
+FILE *ftpd_ls(const char *, pid_t *);
int get_line(char *, int, FILE *);
void ftpdlogwtmp(char *, char *, char *);
void lreply(int, const char *, ...);
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.228
diff -u -p -r1.228 ftpd.c
--- ftpd.c 3 Jul 2019 03:24:04 - 1.228
+++ ftpd.c 13 Jan 2020 11:15:31 -
@@ -1124,7 +1124,7 @@ retrieve(enum ret_cmd cmd, char *name)
fin = fopen(name, "r");
st.st_size = 0;
} else {
- fin = ftpd_ls("-lgA", name, );
+ fin = ftpd_ls(name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
@@ -1730,7 +1730,7 @@ statfilecmd(char *filename)
int c;
int atstart;
pid_t pid;
- fin = ftpd_ls("-lgA", filename, );
+ fin = ftpd_ls(filename, );
if (fin == NULL) {
reply(451, "Local resource failure");
return;
Index: popen.c
===
RCS file: /cvs/src/libexec/ftpd/popen.c,v
retrieving revision 1.28
diff -u -p -r1.28 popen.c
--- popen.c 28 Jun 2019 13:32:53 - 1.28
+++ popen.c 13 Jan 2020 12:07:14 -
@@ -60,51 +60,44 @@
#define MAX_GARGV 1000
FILE *
-ftpd_ls(char *arg, char *path, pid_t *pidptr)
+ftpd_ls(const char *path, pid_t *pidptr)
{
char *cp;
FILE *iop;
- int argc = 0, gargc, pdes[2];
+ int argc = 0, pdes[2];
pid_t pid;
- char **pop, *argv[MAX_ARGV], *gargv[MAX_GARGV];
+ char **pop, *argv[MAX_ARGV];
if (pipe(pdes) == -1)
return (NULL);
/* break up string into pieces */
argv[argc++] = "/bin/ls";
- if (arg != NULL)
- argv[argc++] = arg;
- if (path != NULL)
- argv[argc++] = path;
- argv[argc] = NULL;
- argv[MAX_ARGV-1] = NULL;
+ argv[argc++] = "-lgA";
- /* glob each piece */
- gargv[0] = argv[0];
- for (gargc = argc = 1; argv[argc]; argc++) {
+ /* glob that path */
+ if (path != NULL) {
glob_t gl;
memset(, 0, sizeof(gl));
- if (glob(argv[argc],
+ if (glob(path,
GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE|GLOB_LIMIT,
NULL, )) {
- if (gargc < MAX_GARGV-1) {
- gargv[gargc++] = strdup(argv[argc]);
- if (gargv[gargc -1] == NULL)
- fatal ("Out of memory.");
- }
+ argv[argc++] = strdup(path);
+ if (argv[argc -1] == NULL)
+ fatal ("Out of memory.");
} else if (gl.gl_pathc > 0) {
- for (pop = gl.gl_pathv; *pop && gargc < MAX_GARGV-1;
pop++) {
- gargv[gargc++] = strdup(*pop);
- if (gargv[gargc - 1] == NULL)
+ for (pop = gl.gl_pathv; *pop && argc < MAX_GARGV-1;
pop++) {
+ argv[argc++] = strdup(*pop);
+ if (argv[argc - 1] == NULL)
fatal ("Out of memory.");
}
}
globfree();
}
- gargv[gargc] = NULL;
+ argv[argc] = NULL;
+ argv[MAX_ARGV-1] = NULL;
iop = NULL;
@@ -128,15 +121,15 @@ ftpd_ls(char *arg, char *path, pid_t *pi
/* reset getopt for ls_main */
optreset = optind = 1;
- exit(ls_main(gargc, gargv));
+ exit(ls_main(argc, argv));
}
/* parent; assume fdopen can't fail... */
iop = fdopen(pdes[0], "r");
(void)close(pdes[1]);
*pidptr = pid;
-pfree: for (argc = 1; gargv[argc] != NULL; argc++)
- free(gargv[argc]);
+pfree: for (argc = 2; argv[argc] != NULL; argc++)
+ free(argv[argc]);
return (iop);
}
signature.asc
Description:
Re: Add sizes for free() in clct(4)
On Fri, Dec 20, 2019 at 05:26:56PM +0100, Frederic Cambus wrote:
> Here is a diff to add sizes for free() in clct(4).
>
> Similar diff to the ones previously sent for other audio drivers.
>
> Comments? OK?
OK jan@
> Index: sys/dev/pci/cs4281.c
> ===
> RCS file: /cvs/src/sys/dev/pci/cs4281.c,v
> retrieving revision 1.36
> diff -u -p -r1.36 cs4281.c
> --- sys/dev/pci/cs4281.c 19 Sep 2016 06:46:44 - 1.36
> +++ sys/dev/pci/cs4281.c 20 Dec 2019 15:56:40 -
> @@ -1187,7 +1187,7 @@ cs4281_malloc(void *addr, int direction,
> error = cs4281_allocmem(sc, size, pool, flags, p);
>
> if (error) {
> - free(p, pool, 0);
> + free(p, pool, sizeof(*p));
> return (0);
> }
>
> @@ -1212,7 +1212,7 @@ cs4281_free(void *addr, void *ptr, int p
> bus_dmamem_unmap(sc->sc_dmatag, p->addr, p->size);
> bus_dmamem_free(sc->sc_dmatag, p->segs, p->nsegs);
> *pp = p->next;
> - free(p, pool, 0);
> + free(p, pool, sizeof(*p));
> return;
> }
> }
>
Re: ublink(4), led(4) and ledctl(1)
On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote:
Nice project. If this makes it into the tree then I could rewrite [1].
[1]: https://github.com/younix/g403led
> And I don't often do userland tools, so feel free to
> let me know how to improve it.
> ...
> +int
> +main(int argc, char **argv)
> +{
> ...
> + exit(0);
> +}
I think its better to return 0 in main() instead of calling the libc
function exit(3).
> ... and also there are no manpages yet.
Below is an example for ledctl.8.
Thanks,
Jan
.\" $OpenBSD$
.\"
.\" Copyright (c) 2019 Jan Klemkow
.\"
.\" 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: December 14 2019 $
.Dt LEDCTL 8
.Os
.Sh NAME
.Nm ledctl
.Nd sets the colors of LEDs
.Sh SYNOPSIS
.Nm
.Op Fl f Ar device
.Op Fl n Ar led
.Op Ar on|off|rgb
.Sh DESCRIPTION
The
.Nm
utility turns LEDs
.Ar on ,
.Ar off
or set their color state.
The color value
.Ar rgb
has to be in hex format.
The parameters
.Ar on
and
.Ar off
are shortcuts for the color values 0xff and 0x00.
.Pp
The options are as follows:
.Bl -tag -width Ds
.It Fl f Ar device
.Nm
uses
the device file
.Ar device .
Default is
.Pa /dev/led0 .
.It Fl n Ar led
A
.Xr led 4
device may consists of multiple LEDs.
Sets
.Ar led
to the index of the right LED.
Default is 0.
.El
.Sh FILES
.Pa /dev/led0
.Sh EXIT STATUS
.Ex -std
.Sh EXAMPLES
Sets the first LED of
.Pa /dev/led0
to red:
.Bd -literal -offset indent
$ ledctl 0xff
.Ed
.Pp
Sets the second LED of
.Pa /dev/led0
to green:
.Bd -literal -offset indent
$ ledctl -n 1 0x00ff00
.Ed
.Pp
Sets the first LED of
.Pa /dev/led2
to blue:
.Bd -literal -offset indent
$ ledctl -f /dev/led2 0xff
.Ed
.\".Sh SEE ALSO
.\".Xr led 4
.Sh AUTHORS
The
.Nm
program was written by
.An Patrick Wildt Aq Mt patr...@blueri.se .
signature.asc
Description: PGP signature
Re: diff: simplify MGETHDR error handling in tcp_output
Hi Lucas,
On Wed, Nov 06, 2019 at 08:28:43PM +, Lucas wrote:
> Jan Klemkow wrote:
> > the following diff simplifies the error handling of MGETHDR() in
> > tcp_output(). Jumps earlier to out, prevents a double check of NULL and
> > makes the code more readable.
> >
> > OK?
> >
> > Bye,
> > Jan
> >
> > Index: netinet/tcp_output.c
> > ===
> > RCS file: /cvs/src/sys/netinet/tcp_output.c,v
> > retrieving revision 1.128
> > diff -u -p -r1.128 tcp_output.c
> > --- netinet/tcp_output.c10 Nov 2018 18:40:34 - 1.128
> > +++ netinet/tcp_output.c6 Nov 2019 14:34:40 -
> > @@ -652,17 +652,17 @@ send:
> > m->m_data -= hdrlen;
> > #else
> > MGETHDR(m, M_DONTWAIT, MT_HEADER);
> > - if (m != NULL && max_linkhdr + hdrlen > MHLEN) {
> > + if (m == NULL) {
> > + error = ENOBUFS;
> > + goto out;
> > + }
> > + if (max_linkhdr + hdrlen > MHLEN) {
> > MCLGET(m, M_DONTWAIT);
> > if ((m->m_flags & M_EXT) == 0) {
> > m_freem(m);
> > m = NULL;
> > }
> > }
> > - if (m == NULL) {
> > - error = ENOBUFS;
> > - goto out;
> > - }
> > m->m_data += max_linkhdr;
> > m->m_len = hdrlen;
>
> I might be missing something, but m can be NULL here, if (m->m_flags &
> M_EXT) == 0.
Yes, you are right. I missed that.
Thank,
Jan
Re: [patch] ftp: improve SMALL and NOSSL #ifdefs
Hi Hiltjo,
On Wed, Nov 06, 2019 at 07:53:02PM +0100, Hiltjo Posthuma wrote:
> The below patch fixes the #ifndef's for usr.bin/ftp so any combination of
> SMALL
> and NOSSL will compile again.
Diff looks good for me and works in all ifdef combinations without any
warning or error.
OK jan@
Thanks,
Jan
> diff --git usr.bin/ftp/fetch.c usr.bin/ftp/fetch.c
> index 4c7e14b04bd..15927471f1a 100644
> --- usr.bin/ftp/fetch.c
> +++ usr.bin/ftp/fetch.c
> @@ -201,14 +201,14 @@ url_get(const char *origline, const char *proxyenv,
> const char *outfile, int las
> char *proxyhost = NULL;
> #ifndef NOSSL
> char *sslpath = NULL, *sslhost = NULL;
> - char *full_host = NULL;
> - const char *scheme;
> int ishttpurl = 0, ishttpsurl = 0;
> #endif /* !NOSSL */
> #ifndef SMALL
> + char *full_host = NULL;
> + const char *scheme;
> char *locbase;
> struct addrinfo *ares = NULL;
> -#endif
> +#endif /* !SMALL */
> struct tls *tls = NULL;
> int status;
> int save_errno;
> @@ -221,8 +221,10 @@ url_get(const char *origline, const char *proxyenv,
> const char *outfile, int las
> errx(1, "Can't allocate memory to parse URL");
> if (strncasecmp(newline, HTTP_URL, sizeof(HTTP_URL) - 1) == 0) {
> host = newline + sizeof(HTTP_URL) - 1;
> -#ifndef SMALL
> +#ifndef NOSSL
> ishttpurl = 1;
> +#endif /* !NOSSL */
> +#ifndef SMALL
> scheme = HTTP_URL;
> #endif /* !SMALL */
> } else if (strncasecmp(newline, FTP_URL, sizeof(FTP_URL) - 1) == 0) {
> @@ -234,13 +236,17 @@ url_get(const char *origline, const char *proxyenv,
> const char *outfile, int las
> } else if (strncasecmp(newline, FILE_URL, sizeof(FILE_URL) - 1) == 0) {
> host = newline + sizeof(FILE_URL) - 1;
> isfileurl = 1;
> -#ifndef NOSSL
> +#ifndef SMALL
> scheme = FILE_URL;
> +#endif /* !SMALL */
> +#ifndef NOSSL
> } else if (strncasecmp(newline, HTTPS_URL, sizeof(HTTPS_URL) - 1) == 0)
> {
> host = newline + sizeof(HTTPS_URL) - 1;
> ishttpsurl = 1;
> - scheme = HTTPS_URL;
> #endif /* !NOSSL */
> +#ifndef SMALL
> + scheme = HTTPS_URL;
> +#endif /* !SMALL */
> } else
> errx(1, "url_get: Invalid URL '%s'", newline);
>
> @@ -1066,8 +1072,10 @@ improper:
> warnx("Improper response from %s", host);
>
> cleanup_url_get:
> -#ifndef NOSSL
> +#ifndef SMALL
> free(full_host);
> +#endif /* !SMALL */
> +#ifndef NOSSL
> free(sslhost);
> #endif /* !NOSSL */
> ftp_close(, , );
diff: simplify MGETHDR error handling in tcp_output
Hi,
the following diff simplifies the error handling of MGETHDR() in
tcp_output(). Jumps earlier to out, prevents a double check of NULL and
makes the code more readable.
OK?
Bye,
Jan
Index: netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.128
diff -u -p -r1.128 tcp_output.c
--- netinet/tcp_output.c10 Nov 2018 18:40:34 - 1.128
+++ netinet/tcp_output.c6 Nov 2019 14:34:40 -
@@ -652,17 +652,17 @@ send:
m->m_data -= hdrlen;
#else
MGETHDR(m, M_DONTWAIT, MT_HEADER);
- if (m != NULL && max_linkhdr + hdrlen > MHLEN) {
+ if (m == NULL) {
+ error = ENOBUFS;
+ goto out;
+ }
+ if (max_linkhdr + hdrlen > MHLEN) {
MCLGET(m, M_DONTWAIT);
if ((m->m_flags & M_EXT) == 0) {
m_freem(m);
m = NULL;
}
}
- if (m == NULL) {
- error = ENOBUFS;
- goto out;
- }
m->m_data += max_linkhdr;
m->m_len = hdrlen;
if (len <= m_trailingspace(m)) {
@@ -701,16 +701,16 @@ send:
tcpstat_inc(tcps_sndwinup);
MGETHDR(m, M_DONTWAIT, MT_HEADER);
- if (m != NULL && max_linkhdr + hdrlen > MHLEN) {
+ if (m == NULL) {
+ error = ENOBUFS;
+ goto out;
+ }
+ if (max_linkhdr + hdrlen > MHLEN) {
MCLGET(m, M_DONTWAIT);
if ((m->m_flags & M_EXT) == 0) {
m_freem(m);
m = NULL;
}
- }
- if (m == NULL) {
- error = ENOBUFS;
- goto out;
}
m->m_data += max_linkhdr;
m->m_len = hdrlen;
Re: iwm: support dynamic queue allocation (DQA)
On Mon, Oct 14, 2019 at 01:51:02PM +0200, Stefan Sperling wrote: > I have successfully tested this diff on 8265 with our current firmware > image (22.361476.0) as well as a newer -22 firmware image (22.391740.0, > which is *not* in fw_update yet). I have also tested 7265 successfully. Also works for me with 8265 and firmware 22.361476.0 bye, Jan
Re: net80211: increase background scan backoff timer
On Mon, Oct 14, 2019 at 02:22:24PM +0200, Stefan Sperling wrote:
> Is anyone running this already? OK?
I run the diff without any noticeable problems.
Run this with iwm and wpa-enterprise.
iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
Seems to work for me.
bye,
Jan
> On Mon, Oct 07, 2019 at 04:41:37PM +0200, Stefan Sperling wrote:
> > Frequent background scans are known to cause packet loss with
> > some types of APs (e.g. old Apple APs and some Android phones).
> >
> > There is already a heuristic to make bgscans less frequent if we
> > keep choosing the same AP. However, the current backoff interval
> > keeps increasing in tiny steps of 500ms, so problems caused by
> > background scans remain noticable for some time after association
> > to a problematic AP.
> >
> > This diff increases the hgscan backoff timer such that the interval
> > keeps doubling each time we choose the same AP again. I hope this will
> > help in situations where a single AP is used and frequent bgscans are
> > causing trouble.
> >
> > diff e17574f85785da4fa4073c8b9a00d8d738f3298f
> > c6d97512c3c477464b2407c31d85add72ed1df9f
> > blob - 313d7249f09646a2eeabc21e9e760c9debcdf790
> > blob + dde43eda321beaa949255c143b249339c39f027c
> > --- sys/net80211/ieee80211_node.c
> > +++ sys/net80211/ieee80211_node.c
> > @@ -1421,8 +1421,12 @@ ieee80211_end_scan(struct ifnet *ifp)
> > * and make background scans less frequent.
> > */
> > if (selbs == curbs) {
> > - if (ic->ic_bgscan_fail < IEEE80211_BGSCAN_FAIL_MAX)
> > - ic->ic_bgscan_fail++;
> > + if (ic->ic_bgscan_fail < IEEE80211_BGSCAN_FAIL_MAX) {
> > + if (ic->ic_bgscan_fail <= 0)
> > + ic->ic_bgscan_fail = 1;
> > + else
> > + ic->ic_bgscan_fail *= 2;
> > + }
> > ic->ic_flags &= ~IEEE80211_F_BGSCAN;
> > return;
> > }
> > blob - 0f2072288232ac276c2979b799b03c37e0ca8032
> > blob + b475001b14ddb11c5c1713d072358ef2b9e2736d
> > --- sys/net80211/ieee80211_var.h
> > +++ sys/net80211/ieee80211_var.h
> > @@ -62,7 +62,7 @@
> > #define IEEE80211_RSSI_THRES_RATIO_2GHZ60 /* in percent */
> > #define IEEE80211_RSSI_THRES_RATIO_5GHZ50 /* in percent */
> >
> > -#define IEEE80211_BGSCAN_FAIL_MAX 360 /* units of 500 msec */
> > +#define IEEE80211_BGSCAN_FAIL_MAX 512 /* units of 500 msec */
> >
> > enum ieee80211_phytype {
> > IEEE80211_T_DS, /* direct sequence spread spectrum */
> >
>
fix: build of aac(4)
Hi,
aac(4) doesn't build in the current status. The following diff fixes
compile errors. Also, with the AAC_DEBUG option. I removed the
prototypes of the inline functions in aacvar.h because of a K style
compile error and that the prototypes are directly followed by their
implementation.
ok?
Bye,
Jan
Index: dev/ic/aac.c
===
RCS file: /mount/openbsd/cvs/src/sys/dev/ic/aac.c,v
retrieving revision 1.70
diff -u -p -r1.70 aac.c
--- dev/ic/aac.c11 Apr 2017 14:43:49 - 1.70
+++ dev/ic/aac.c5 Oct 2019 11:06:18 -
@@ -2129,7 +2129,7 @@ aac_internal_cache_cmd(struct scsi_xfer
struct scsi_read_cap_data rcd;
u_int8_t target = link->target;
- AAC_DPRINTF(AAC_D_CMD, ("aac_internal_cache_cmd: ",
+ AAC_DPRINTF(AAC_D_CMD, ("%s: aac_internal_cache_cmd: ",
sc->aac_dev.dv_xname));
switch (xs->cmd->opcode) {
@@ -2277,7 +2277,7 @@ aac_scsi_cmd(struct scsi_xfer *xs)
blockcnt = _2btol(rwb->length);
}
- AAC_DPRINTF(AAC_D_CMD, ("blkno=%d bcount=%d ",
+ AAC_DPRINTF(AAC_D_CMD, ("opcode=%d blkno=%d bcount=%d ",
xs->cmd->opcode, blockno, blockcnt));
if (blockno >= sc->aac_hdr[target].hd_size ||
Index: dev/ic/aacvar.h
===
RCS file: /mount/openbsd/cvs/src/sys/dev/ic/aacvar.h,v
retrieving revision 1.13
diff -u -p -r1.13 aacvar.h
--- dev/ic/aacvar.h 1 Apr 2016 04:16:27 - 1.13
+++ dev/ic/aacvar.h 5 Oct 2019 15:01:12 -
@@ -429,11 +429,6 @@ intaac_attach(struct aac_softc *);
intaac_intr(void *);
/* These all require correctly aligned buffers */
-static __inline__ void aac_enc16(u_int8_t *, u_int16_t);
-static __inline__ void aac_enc32(u_int8_t *, u_int32_t);
-static __inline__ u_int16_t aac_dec16(u_int8_t *);
-static __inline__ u_int32_t aac_dec32(u_int8_t *);
-
static __inline__ void
aac_enc16(addr, value)
u_int8_t *addr;
Re: system boot hang due to inteldrm(4)
On Tue, Oct 01, 2019 at 11:34:09AM +1000, Jonathan Gray wrote: > On Tue, Oct 01, 2019 at 12:27:48AM +0200, Jan Klemkow wrote: > > After updating my router to current, the systems hangs during the boot. > > Maybe its caused by the "invalid EDID"?! The System boots up normaly > > and doesn't hang, if I disable inteldrm(4) in UKC. > > > > Is this issue known? Or, witch additional debug information should I > > provide to help fixing this bug? Hi Jonathan, > Building a kernel with 'option DRMDEBUG' will give more information. See the log below: > Is the machine hooked up to a kvm or monitor? No KVM and no monitor. Just serial access. > What Lanner model is this? "gbXSo" doesn't help. Lanner LEC-7233 Thanks, Jan Kernel boot messages with DRMDEBUG enabled: The last part seems to repeat endlessly?! [ using 2760504 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.6-beta (GENERIC.MP) #102: Wed Oct 2 09:10:14 CEST 2019 you...@fabien.klemkow.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2024398848 (1930MB) avail mem = 1950064640 (1859MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeca50 (49 entries) bios0: vendor American Megatrends Inc. version "5.6.5" date 01/05/2017 bios0: Lanner Electronics gbXSo acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT LPIT MCFG HPET SSDT SSDT SSDT UEFI acpi0: wakeup devices EHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) BRCM(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.69 MHz, 06-37-08 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,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache tsc_timecounter_init: TSC skew=0 observed drift=0 cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) TSC skew=0 cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08 cpu1: 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,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache tsc_timecounter_init: TSC skew=0 observed drift=0 cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP02) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus 1 (RP01) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PLPE acpipwrres1 at acpi0: PLPE acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1 acpipwrres3 at acpi0: CLK0, resource for CAM1 acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2 acpipwrres5 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 90 degC "INT3396" at acpi0 not configured acpicmos0 at acpi0 acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001 "DMA0F28" at acpi0 not configured acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB "BCM2E1A" at acpi0 not configured "BCM4752" at acpi0 not configured "AUTH2750" at acpi0 not configured "INTCF0B" at acpi0 not configured "INTCF1A" at acpi0 not configured "INTCF1C" at acpi0 not configured "SMO91D0" at acpi0 not configured "MSFT0002" at acpi0 not configured "INT33BD" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: using VERW MDS workaround cpu0: Enhanced SpeedStep 1583 MHz: speeds: 1577, 1494, 1411, 1328, 1245, 1162, 1079, 996, 913, 830, 747, 664, 581, 498 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e inteldrm0 at pci0 dev 2 func
system boot hang due to inteldrm(4)
Hi, After updating my router to current, the systems hangs during the boot. Maybe its caused by the "invalid EDID"?! The System boots up normaly and doesn't hang, if I disable inteldrm(4) in UKC. Is this issue known? Or, witch additional debug information should I provide to help fixing this bug? Thanks, Jan [ using 2744944 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.6-beta (GENERIC.MP) #328: Thu Sep 26 21:37:06 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2024398848 (1930MB) avail mem = 1950400512 (1860MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xeca50 (49 entries) bios0: vendor American Megatrends Inc. version "5.6.5" date 01/05/2017 bios0: Lanner Electronics gbXSo acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT LPIT MCFG HPET SSDT SSDT SSDT UEFI acpi0: wakeup devices EHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) BRCM(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.59 MHz, 06-37-08 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,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache tsc_timecounter_init: TSC skew=0 observed drift=0 cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) TSC skew=0 cpu1: Intel(R) Celeron(R) CPU N2807 @ 1.58GHz, 1583.34 MHz, 06-37-08 cpu1: 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,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache tsc_timecounter_init: TSC skew=0 observed drift=0 cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP02) acpiprt2 at acpi0: bus 3 (RP03) acpiprt3 at acpi0: bus 4 (RP04) acpiprt4 at acpi0: bus 1 (RP01) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PLPE acpipwrres1 at acpi0: PLPE acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1 acpipwrres3 at acpi0: CLK0, resource for CAM1 acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2 acpipwrres5 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 90 degC "INT3396" at acpi0 not configured acpicmos0 at acpi0 acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001 "DMA0F28" at acpi0 not configured acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB "BCM2E1A" at acpi0 not configured "BCM4752" at acpi0 not configured "AUTH2750" at acpi0 not configured "INTCF0B" at acpi0 not configured "INTCF1A" at acpi0 not configured "INTCF1C" at acpi0 not configured "SMO91D0" at acpi0 not configured "MSFT0002" at acpi0 not configured "INT33BD" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: using VERW MDS workaround cpu0: Enhanced SpeedStep 1583 MHz: speeds: 1577, 1494, 1411, 1328, 1245, 1162, 1079, 996, 913, 830, 747, 664, 581, 498 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e inteldrm0 at pci0 dev 2 function 0 "Intel Bay Trail Video" rev 0x0e drm0 at inteldrm0 inteldrm0: msi ahci0 at pci0 dev 19 function 0 "Intel Bay Trail AHCI" rev 0x0e: msi, AHCI 1.3 ahci0: port 0: 3.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: naa.524693f2ca20f959 sd0: 7641MB, 512 bytes/sector, 15649200 sectors, thin "Intel Bay Trail TXE" rev 0x0e at pci0 dev 26 function 0 not configured azalia0 at pci0 dev 27 function 0 "Intel Bay Trail HD Audio" rev 0x0e: msi azalia0: no supported codecs ppb0 at pci0 dev 28 function 0 "Intel Bay Trail PCIE" rev 0x0e: msi pci1 at ppb0 bus 1 bwfm0 at pci1 dev 0 function 0 "Broadcom BCM4350" rev 0x08: msi ppb1 at pci0 dev 28 function 1 "Intel Bay Trail PCIE" rev 0x0e: msi pci2
Re: ix(4): enable checksum offload
On 9.9.2013. 22:07, Mike Belopuhov wrote: > On 9 September 2013 21:48, Brad Smith wrote: > > Here is a diff to enable the checksum offload support for ix(4). > > > > Looking for any testing. > > > > last time i checked this broke ospf traffic. please make sure at least > ip/tcp, ip/udp, ip/icmp, ip/ip, ip/gre, ip/esp, ip/ah and ip/ospf work fine > with this. With checksum offloading enabled on the ix(4) I got ~20% performance improvement with relayd(8) using socket splicing. I think its worth to enable this feature by default. I also did my homework and tested all requested protocols: IPv4IPv64over6 6over4 ip/tcp check check ip/udp check check ip/icmp check check ip/ip check check check check ip/gre check check check check ip/esp check check ip/ospf check check nfs v2 check - nfs v3 check - I used the following card for testing: ix0 at pci3 dev 0 function 0 "Intel 82599" rev 0x01: msi, address xx:xx:xx:xx:xx:xx Looking for further testing or any OK? Bye, Jan Index: sys/dev/pci/if_ix.c === RCS file: /cvs/src/sys/dev/pci/if_ix.c,v retrieving revision 1.157 diff -u -p -r1.157 if_ix.c --- sys/dev/pci/if_ix.c 10 Apr 2019 09:55:02 - 1.157 +++ sys/dev/pci/if_ix.c 27 Jul 2019 19:50:04 - @@ -1678,9 +1678,7 @@ ixgbe_setup_interface(struct ix_softc *s ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING; #endif -#ifdef IX_CSUM_OFFLOAD ifp->if_capabilities |= IFCAP_CSUM_TCPv4 | IFCAP_CSUM_UDPv4; -#endif /* * Specify the media types supported by this sc and register
Re: fix: NULL dereference in bios(4)
On Tue, Jul 23, 2019 at 10:05:58PM +1000, Jonathan Gray wrote:
> On Mon, Jul 22, 2019 at 10:03:38AM +0200, Jan Klemkow wrote:
> > On Sat, Jul 20, 2019 at 07:16:05PM +1000, Jonathan Gray wrote:
> > > On Fri, Jul 19, 2019 at 02:15:03PM +0200, Jan Klemkow wrote:
> > > > On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote:
> > > > > On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote:
> > > > > > fixstring() can return NULL and it does on one of my machines.
> > > > > > Here is s fix that checks for NULL and return an empty string.
> > > > > >
> > > > > > ok?
> > > > >
> > > > > If it returns NULL shouldn't the strlcpy and printf both be skipped?
> > > >
> > > > I was unsure about this.
> > > >
> > > > > You've also not included the i386 portion of this.
> > > >
> > > > I missed that.
> > > >
> > > > The diff below addresses all issues.
> > > >
> > > > ok?
> > >
> > > What argument does fixstring have in this case?
> >
> > Ten spaces (10x 0x20).
> >
> > > Does you dmesg not include a date in the 'bios0' line?
> >
> > no.
> >
> > > I was considering making this a pointer/dynamically allocated so it can
> > > be NULL. If there is no valid date it should probably be NULL.
Ahh, sorry. I don't get your suggestion on the first read.
> how about this?
Yes, this solution is fine for me and works on my hardware.
Thanks and OK,
Jan
> Index: amd64/amd64/bios.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 bios.c
> --- amd64/amd64/bios.c15 Jul 2019 00:35:10 - 1.38
> +++ amd64/amd64/bios.c23 Jul 2019 12:00:27 -
> @@ -92,6 +92,7 @@ bios_attach(struct device *parent, struc
> u_int8_t *p;
> int smbiosrev = 0;
> struct smbhdr *hdr = NULL;
> + char *sminfop;
>
> if (bios_efiinfo != NULL && bios_efiinfo->config_smbios != 0)
> hdr = smbios_find(PMAP_DIRECT_MAP(
> @@ -144,9 +145,13 @@ bios_attach(struct device *parent, struc
> fixstring(scratch));
> if ((smbios_get_string(, sb->release,
> scratch, sizeof(scratch))) != NULL) {
> - strlcpy(smbios_bios_date, fixstring(scratch),
> - sizeof(smbios_bios_date));
> - printf(" date %s", fixstring(scratch));
> + sminfop = fixstring(scratch);
> + if (sminfop != NULL) {
> + strlcpy(smbios_bios_date,
> + sminfop,
> + sizeof(smbios_bios_date));
> + printf(" date %s", sminfop);
> + }
> }
> }
>
> Index: i386/i386/bios.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
> retrieving revision 1.121
> diff -u -p -r1.121 bios.c
> --- i386/i386/bios.c 15 Jul 2019 00:35:10 - 1.121
> +++ i386/i386/bios.c 23 Jul 2019 12:00:51 -
> @@ -245,6 +245,7 @@ biosattach(struct device *parent, struct
> for (va = ISA_HOLE_VADDR(SMBIOS_START);
> va < (u_int8_t *)ISA_HOLE_VADDR(SMBIOS_END); va+= 16) {
> struct smbhdr *sh = (struct smbhdr *)va;
> + char *sminfop;
> u_int8_t chksum;
> vaddr_t eva;
> paddr_t pa, end;
> @@ -308,10 +309,13 @@ biosattach(struct device *parent, struct
> fixstring(scratch));
> if ((smbios_get_string(, sb->release,
> scratch, sizeof(scratch))) != NULL) {
> - strlcpy(smbios_bios_date,
> - fixstring(scratch),
> - sizeof(smbios_bios_date));
> - printf(" date %s", fixstring(scratch));
> + sminfop = fixstring(scratch);
> + if (sminfop != NULL) {
> + strlcpy(smbios_bios_date,
> + sminfop,
> + sizeof(smbios_bios_date));
> + printf(" date %s", sminfop);
> + }
> }
> }
> smbios_info(sc->sc_dev.dv_xname);
Re: fix: NULL dereference in bios(4)
On Sat, Jul 20, 2019 at 07:16:05PM +1000, Jonathan Gray wrote:
> On Fri, Jul 19, 2019 at 02:15:03PM +0200, Jan Klemkow wrote:
> > On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote:
> > > On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote:
> > > > fixstring() can return NULL and it does on one of my machines.
> > > > Here is s fix that checks for NULL and return an empty string.
> > > >
> > > > ok?
> > >
> > > If it returns NULL shouldn't the strlcpy and printf both be skipped?
> >
> > I was unsure about this.
> >
> > > You've also not included the i386 portion of this.
> >
> > I missed that.
> >
> > The diff below addresses all issues.
> >
> > ok?
>
> What argument does fixstring have in this case?
Ten spaces (10x 0x20).
> Does you dmesg not include a date in the 'bios0' line?
no.
> I was considering making this a pointer/dynamically allocated so it can
> be NULL. If there is no valid date it should probably be NULL.
>
> >
> > Thanks,
> > Jan
> >
> > Index: arch/amd64/amd64/bios.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
> > retrieving revision 1.38
> > diff -u -p -r1.38 bios.c
> > --- arch/amd64/amd64/bios.c 15 Jul 2019 00:35:10 - 1.38
> > +++ arch/amd64/amd64/bios.c 19 Jul 2019 11:45:11 -
> > @@ -144,9 +144,11 @@ bios_attach(struct device *parent, struc
> > fixstring(scratch));
> > if ((smbios_get_string(, sb->release,
> > scratch, sizeof(scratch))) != NULL) {
> > - strlcpy(smbios_bios_date, fixstring(scratch),
> > + char *s = fixstring(scratch) == NULL ? "" :
> > + fixstring(scratch);
> > + strlcpy(smbios_bios_date, s,
> > sizeof(smbios_bios_date));
> > - printf(" date %s", fixstring(scratch));
> > + printf(" date %s", s);
> > }
> > }
> >
> > Index: arch/i386/i386/bios.c
> > ===
> > RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
> > retrieving revision 1.121
> > diff -u -p -r1.121 bios.c
> > --- arch/i386/i386/bios.c 15 Jul 2019 00:35:10 - 1.121
> > +++ arch/i386/i386/bios.c 19 Jul 2019 11:58:57 -
> > @@ -308,10 +308,11 @@ biosattach(struct device *parent, struct
> > fixstring(scratch));
> > if ((smbios_get_string(, sb->release,
> > scratch, sizeof(scratch))) != NULL) {
> > - strlcpy(smbios_bios_date,
> > - fixstring(scratch),
> > + char *s = fixstring(scratch) == NULL ?
> > + "" : fixstring(scratch);
> > + strlcpy(smbios_bios_date, s,
> > sizeof(smbios_bios_date));
> > - printf(" date %s", fixstring(scratch));
> > + printf(" date %s", s);
> > }
> > }
> > smbios_info(sc->sc_dev.dv_xname);
> >
Re: fix: NULL dereference in bios(4)
On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote:
> On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote:
> > Hi,
> >
> > fixstring() can return NULL and it does on one of my machines.
> > Here is s fix that checks for NULL and return an empty string.
> >
> > ok?
>
> If it returns NULL shouldn't the strlcpy and printf both be skipped?
I was unsure about this.
> You've also not included the i386 portion of this.
I missed that.
The diff below addresses all issues.
ok?
Thanks,
Jan
Index: arch/amd64/amd64/bios.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
retrieving revision 1.38
diff -u -p -r1.38 bios.c
--- arch/amd64/amd64/bios.c 15 Jul 2019 00:35:10 - 1.38
+++ arch/amd64/amd64/bios.c 19 Jul 2019 11:45:11 -
@@ -144,9 +144,11 @@ bios_attach(struct device *parent, struc
fixstring(scratch));
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
- strlcpy(smbios_bios_date, fixstring(scratch),
+ char *s = fixstring(scratch) == NULL ? "" :
+ fixstring(scratch);
+ strlcpy(smbios_bios_date, s,
sizeof(smbios_bios_date));
- printf(" date %s", fixstring(scratch));
+ printf(" date %s", s);
}
}
Index: arch/i386/i386/bios.c
===
RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
retrieving revision 1.121
diff -u -p -r1.121 bios.c
--- arch/i386/i386/bios.c 15 Jul 2019 00:35:10 - 1.121
+++ arch/i386/i386/bios.c 19 Jul 2019 11:58:57 -
@@ -308,10 +308,11 @@ biosattach(struct device *parent, struct
fixstring(scratch));
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
- strlcpy(smbios_bios_date,
- fixstring(scratch),
+ char *s = fixstring(scratch) == NULL ?
+ "" : fixstring(scratch);
+ strlcpy(smbios_bios_date, s,
sizeof(smbios_bios_date));
- printf(" date %s", fixstring(scratch));
+ printf(" date %s", s);
}
}
smbios_info(sc->sc_dev.dv_xname);
fix: NULL dereference in bios(4)
Hi,
fixstring() can return NULL and it does on one of my machines.
Here is s fix that checks for NULL and return an empty string.
ok?
bye,
Jan
Index: arch/amd64/amd64/bios.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
retrieving revision 1.38
diff -u -p -r1.38 bios.c
--- arch/amd64/amd64/bios.c 15 Jul 2019 00:35:10 - 1.38
+++ arch/amd64/amd64/bios.c 19 Jul 2019 08:56:27 -
@@ -144,7 +144,9 @@ bios_attach(struct device *parent, struc
fixstring(scratch));
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
- strlcpy(smbios_bios_date, fixstring(scratch),
+ strlcpy(smbios_bios_date,
+ fixstring(scratch) == NULL ? "" :
+ fixstring(scratch),
sizeof(smbios_bios_date));
printf(" date %s", fixstring(scratch));
}
Re: wsfont & free(9) sizes
On Wed, Jul 10, 2019 at 12:59:41PM -0300, Martin Pieuchot wrote:
> Some free(9) sizes & fix to make wsfont_remove() compile. This function
> is #ifndef for the moment. That's mainly for coherency and to reduce
> grep noise.
>
> ok?
ok jan
> Index: dev/wsfont/wsfont.c
> ===
> RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v
> retrieving revision 1.55
> diff -u -p -u -1 -0 -r1.55 wsfont.c
> --- dev/wsfont/wsfont.c 9 Jan 2019 11:23:32 - 1.55
> +++ dev/wsfont/wsfont.c 23 Jun 2019 00:17:43 -
> @@ -346,23 +346,23 @@ wsfont_rotate_ccw(struct wsdisplay_font
> }
>
> struct wsdisplay_font *
> wsfont_rotate_internal(struct wsdisplay_font *font, int ccw)
> {
> int newstride;
> struct wsdisplay_font *newfont;
> char *newbits;
>
> /* Duplicate the existing font... */
> - newfont = malloc(sizeof *font, M_DEVBUF, M_WAITOK);
> + newfont = malloc(sizeof(*newfont), M_DEVBUF, M_WAITOK);
>
> - bcopy(font, newfont, sizeof *font);
> + bcopy(font, newfont, sizeof(*font));
> newfont->cookie = NULL;
>
> /* Allocate a buffer big enough for the rotated font. */
> newstride = (font->fontheight + 7) / 8;
> newbits = mallocarray(font->numchars, newstride * font->fontwidth,
> M_DEVBUF, M_WAITOK | M_ZERO);
>
> if (ccw)
> wsfont_rotate_ccw(font, newbits, newstride);
> else
> @@ -374,22 +374,22 @@ wsfont_rotate_internal(struct wsdisplay_
> newfont->stride = newstride;
> newfont->fontwidth = font->fontheight;
> newfont->fontheight = font->fontwidth;
>
> if (wsfont_add(newfont, 0) != 0) {
> /*
>* If we seem to have rotated this font already, drop the
>* new one...
>*/
> free(newbits, M_DEVBUF,
> - font->numchars * newstride * font->fontwidth);
> - free(newfont, M_DEVBUF, sizeof *font);
> + newfont->numchars * newfont->stride * newfont->fontwidth);
> + free(newfont, M_DEVBUF, sizeof(*newfont));
> newfont = NULL;
> }
>
> return (newfont);
> }
>
> int
> wsfont_rotate(int cookie, int ccw)
> {
> int s, ncookie;
> @@ -499,33 +499,32 @@ wsfont_add(struct wsdisplay_font *font,
> }
>
> TAILQ_FOREACH(ent, , chain)
> fontc++;
>
> if (fontc >= WSDISPLAY_MAXFONTCOUNT) {
> splx(s);
> return (-1);
> }
>
> - ent = (struct font *)malloc(sizeof *ent, M_DEVBUF, M_WAITOK);
> + ent = malloc(sizeof(*ent), M_DEVBUF, M_WAITOK);
>
> ent->lockcount = 0;
> ent->flg = 0;
> ent->cookie = cookiegen++;
>
> /*
>* If we are coming from a WSDISPLAYIO_LDFONT ioctl, we need to
>* make a copy of the wsdisplay_font struct, but not of font->bits.
>*/
> if (copy) {
> - ent->font = (struct wsdisplay_font *)malloc(sizeof *ent->font,
> - M_DEVBUF, M_WAITOK);
> + ent->font = malloc(sizeof(*ent->font), M_DEVBUF, M_WAITOK);
> memcpy(ent->font, font, sizeof(*ent->font));
> ent->flg = 0;
> } else {
> ent->font = font;
> ent->flg = WSFONT_STATIC;
> }
>
> /* Now link into the list and return */
> TAILQ_INSERT_TAIL(, ent, chain);
> splx(s);
> @@ -549,27 +548,31 @@ wsfont_remove(int cookie)
> return (-1);
> }
>
> if ((ent->flg & WSFONT_BUILTIN) != 0 || ent->lockcount != 0) {
> splx(s);
> return (-1);
> }
>
> /* Don't free statically allocated font data */
> if ((ent->flg & WSFONT_STATIC) != 0) {
> - free(ent->font->data, M_DEVBUF, 0);
> - free(ent->font, M_DEVBUF, 0);
> + struct wsdisplay_font *font = ent->font;
> +
> + free(font->data, M_DEVBUF,
> + font->numchars * font->stride * font->fontwidth);
> + free(font, M_DEVBUF, sizeof(*font));
> + ent->font = NULL;
> }
>
> /* Remove from list, free entry */
> - TAILQ_REMOVE(, ent, chain);
> - free(ent, M_DEVBUF, 0);
> + TAILQ_REMOVE(, ent, chain);
> + free(ent, M_DEVBUF, sizeof(*ent));
> splx(s);
> return (0);
> }
> #endif
>
> /*
> * Lock a given font and return new lockcount. This fails if the cookie
> * is invalid, or if the font is already locked and the bit/byte order
> * requested by the caller differs.
> */
>
Re: uvideo(4): *ALL*
Hi Patrick,
I tested all you patches with my integrated uvideo(4) device.
...
uvideo0 at uhub0 port 8 configuration 1 interface 0 "SunplusIT Inc Integrated
Camera" rev 2.01/54.20 addr 9
video0 at uvideo0
...
addr 09: 5986:2115 SunplusIT Inc, Integrated Camera
high speed, power 500 mA, config 1, rev 54.20
driver: uvideo0
My device don't need your patches to work, but at least they doesn't
break it :) Your diffs looks ok for me, but I'm not a USB expert.
Just a nitpick:
There is a spacing mistake in the definition of the new macro
UVIDEO_FORMAT_GUID_KSMEDIA_L8_IR and in the two above. We may fix them
while here?!
Bye,
Jan
Index: uvideo.h
===
RCS file: /cvs/src/sys/dev/usb/uvideo.h,v
retrieving revision 1.57
diff -u -p -r1.57 uvideo.h
--- uvideo.h9 Jul 2015 14:58:32 - 1.57
+++ uvideo.h8 Jul 2019 20:08:07 -
@@ -302,11 +302,15 @@ struct usb_video_probe_commit {
#defineUVIDEO_FORMAT_GUID_NV12 { \
0x4e, 0x56, 0x31, 0x32, 0x00, 0x00, 0x10, 0x00,\
-0x80, 0x00, 0x00, 0xaa, 0x00, 0x38,0x9b, 0x71 }
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
#defineUVIDEO_FORMAT_GUID_UYVY { \
0x55, 0x59, 0x56, 0x59, 0x00, 0x00, 0x10, 0x00,\
-0x80, 0x00, 0x00, 0xaa, 0x00, 0x38,0x9b, 0x71 }
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
+
+#defineUVIDEO_FORMAT_GUID_KSMEDIA_L8_IR{ \
+0x32, 0x00, 0x00, 0x00, 0x02, 0x00, 0x10, 0x00,\
+0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71 }
/*
* USB Video Payload MJPEG
Re: sparc64 ldomctl(8) fix
On Sat, Jul 06, 2019 at 12:59:55AM +0200, Mark Kettenis wrote:
> The diff below fixes interction between ldomctl(8) and the firmware on
> a SPARC T4 system that I have access to. To make sure that this
> doesn't break other machines it would be good if people could test
> this on a few more ldoms-capable sparc64 machines. To test just build
> ldomctl with this patch, install it and run "ldomctl list":
>
> # cd /usr/src/usr.sbin/ldomctl
> # make obj
> # make
> # make install
> # ldomctl list
Tested on:
hw.model=SUNW,UltraSPARC-T2 (rev 0.0) @ 1415.103 MHz
hw.product=SUNW,SPARC-Enterprise-T5220
# ldomctl list
factory-default
openbsd [current]
Works fine for me.
bye,
Jan
> Index: usr.sbin/ldomctl/mdstore.c
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/mdstore.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 mdstore.c
> --- usr.sbin/ldomctl/mdstore.c15 Sep 2018 13:20:16 - 1.8
> +++ usr.sbin/ldomctl/mdstore.c5 Jul 2019 22:54:01 -
> @@ -55,6 +55,7 @@ struct mdstore_msg {
> uint64_tsvc_handle;
> uint64_treqnum;
> uint16_tcommand;
> + uint8_t reserved[6];
> } __packed;
>
> struct mdstore_begin_end_req {
> @@ -104,7 +105,7 @@ struct mdstore_sel_del_req {
> uint64_tsvc_handle;
> uint64_treqnum;
> uint16_tcommand;
> - uint16_treserved;
> + uint8_t reserved[2];
> uint32_tnamelen;
> charname[1];
> } __packed;
>
Re: free() sizes for ahc(4)
On Tue, May 14, 2019 at 10:35:22AM +, Miod Vallat wrote:
> Note ahc_set_name() gets invoked with the dv_xname field of a struct
> device, so it's not a good idea to free anything, should it be invoked
> more than once.
>
> Tested on:
> ahc0 at pci0 dev 1 function 0 "Adaptec AIC-7880" rev 0x00: irq 8
> ahc0: Host Adapter Bios disabled. Using default SCSI device parameters
> scsibus0 at ahc0: 16 targets, initiator 7
> sd0 at scsibus0 targ 1 lun 0: SCSI3 0/direct
> fixed serial.SGI_IBM_DNES-318350Y_AK0T7943
> sd0: 17364MB, 512 bytes/sector, 35563040 sectors
> cd0 at scsibus0 targ 4 lun 0: SCSI2 5/cdrom
> removable
> ahc1 at pci0 dev 2 function 0 "Adaptec AIC-7880" rev 0x00: irq 9
> ahc1: Host Adapter Bios disabled. Using default SCSI device parameters
> scsibus1 at ahc1: 16 targets, initiator 7
OK Jan
> Index: dev/ic/aic7xxx.c
> ===
> RCS file: /OpenBSD/src/sys/dev/ic/aic7xxx.c,v
> retrieving revision 1.93
> diff -u -p -u -p -r1.93 aic7xxx.c
> --- dev/ic/aic7xxx.c 12 Dec 2017 12:33:36 - 1.93
> +++ dev/ic/aic7xxx.c 14 May 2019 10:28:10 -
> @@ -1688,7 +1688,7 @@ ahc_free_tstate(struct ahc_softc *ahc, u
> scsi_id += 8;
> tstate = ahc->enabled_targets[scsi_id];
> if (tstate != NULL)
> - free(tstate, M_DEVBUF, 0);
> + free(tstate, M_DEVBUF, sizeof(*tstate));
> ahc->enabled_targets[scsi_id] = NULL;
> }
> #endif
> @@ -3957,8 +3957,6 @@ ahc_set_unit(struct ahc_softc *ahc, int
> void
> ahc_set_name(struct ahc_softc *ahc, char *name)
> {
> - if (ahc->name != NULL)
> - free(ahc->name, M_DEVBUF, 0);
> ahc->name = name;
> }
>
> @@ -3997,21 +3995,21 @@ ahc_free(struct ahc_softc *ahc)
> lstate = tstate->enabled_luns[j];
> if (lstate != NULL) {
> /*xpt_free_path(lstate->path);*/
> - free(lstate, M_DEVBUF, 0);
> + free(lstate, M_DEVBUF, sizeof(*lstate));
> }
> }
> #endif
> - free(tstate, M_DEVBUF, 0);
> + free(tstate, M_DEVBUF, sizeof(*tstate));
> }
> }
> #ifdef AHC_TARGET_MODE
> if (ahc->black_hole != NULL) {
> /*xpt_free_path(ahc->black_hole->path);*/
> - free(ahc->black_hole, M_DEVBUF, 0);
> + free(ahc->black_hole, M_DEVBUF, sizeof(*ahc->black_hole));
> }
> #endif
> if (ahc->seep_config != NULL)
> - free(ahc->seep_config, M_DEVBUF, 0);
> + free(ahc->seep_config, M_DEVBUF, sizeof(*ahc->seep_config));
> return;
> }
>
> @@ -4329,7 +4327,7 @@ ahc_fini_scbdata(struct ahc_softc *ahc)
> ahc_freedmamem(ahc->parent_dmat, PAGE_SIZE,
> sg_map->sg_dmamap, (caddr_t)sg_map->sg_vaddr,
> _map->sg_dmasegs, sg_map->sg_nseg);
> - free(sg_map, M_DEVBUF, 0);
> + free(sg_map, M_DEVBUF, sizeof(*sg_map));
> }
> }
> /*FALLTHROUGH*/
> @@ -4350,8 +4348,10 @@ ahc_fini_scbdata(struct ahc_softc *ahc)
> case 0:
> break;
> }
> - if (scb_data->scbarray != NULL)
> - free(scb_data->scbarray, M_DEVBUF, 0);
> + if (scb_data->scbarray != NULL) {
> + free(scb_data->scbarray, M_DEVBUF,
> + AHC_SCB_MAX_ALLOC * sizeof(struct scb));
> + }
> }
>
> void
> @@ -4383,7 +4383,7 @@ ahc_alloc_scbs(struct ahc_softc *ahc)
>(caddr_t *)_map->sg_vaddr, _map->sg_physaddr,
>_map->sg_dmasegs, _map->sg_nseg,
> ahc_name(ahc),
>"SG space") < 0) {
> - free(sg_map, M_DEVBUF, 0);
> + free(sg_map, M_DEVBUF, sizeof(*sg_map));
> return;
> }
>
> @@ -6859,7 +6859,7 @@ ahc_handle_en_lun(struct ahc_softc *ahc,
>xpt_path_target_id(ccb->ccb_h.path),
>xpt_path_lun_id(ccb->ccb_h.path));
> if (status != CAM_REQ_CMP) {
> - free(lstate, M_DEVBUF, 0);
> + free(lstate, M_DEVBUF, sizeof(*lstate));
> xpt_print_path(ccb->ccb_h.path);
> printf("Couldn't allocate path\n");
> ccb->ccb_h.status = CAM_RESRC_UNAVAIL;
> @@ -6980,7 +6980,7 @@ ahc_handle_en_lun(struct ahc_softc *ahc,
> xpt_print_path(ccb->ccb_h.path);
> printf("Target mode disabled\n");
> xpt_free_path(lstate->path);
> - free(lstate, M_DEVBUF, 0);
> + free(lstate, M_DEVBUF, sizeof(*lstate));
>
> ahc_pause(ahc);
> /* Can we clean up the target too? */
> Index:
Re: softraid(4): fix wrong malloc size and zero sized free calls
On Mon, May 13, 2019 at 07:25:37PM -0400, Ted Unangst wrote:
> Jan Klemkow wrote:
> > The diff mainly add sizes to free(9) calls. But, while here fix a
> > malloc(9) call with the wrong size in sr_ioctl_installboot().
> > omi->omi_som is allocated with size of struct sr_meta_crypto, but used
> > as struct sr_meta_boot later.
> >
> > One free(9) with size zero left over in sr_discipline_free(). As, the
> > allocated size of sd->sd_vol.sv_chunks is not ascertainable here without
> > larger changes.
> >
> > Build and run the kernel for testing.
>
> The change in installboot for the size is suspicious. I would leave that out.
> Especially if you haven't tested installboot to a crypto softraid. :)
Here is a diff with just the fixed free sizes. Malloc size fix comes
separately.
OK?
Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.392
diff -u -p -r1.392 softraid.c
--- dev/softraid.c 2 May 2018 02:24:55 - 1.392
+++ dev/softraid.c 14 May 2019 05:13:02 -
@@ -1470,28 +1470,29 @@ unwind:
for (bc1 = SLIST_FIRST(>sbv_chunks); bc1 != NULL;
bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF,
+ sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
- free(bv1, M_DEVBUF, 0);
+ free(bv1, M_DEVBUF, sizeof(*bv1));
}
/* Free keydisks chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
/* Free unallocated chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
while (!SLIST_EMPTY()) {
sdk = SLIST_FIRST();
SLIST_REMOVE_HEAD(, sdk_link);
- free(sdk, M_DEVBUF, 0);
+ free(sdk, M_DEVBUF, sizeof(*sdk));
}
free(devs, M_DEVBUF, BIOC_CRMAXLEN * sizeof(dev_t));
@@ -1751,7 +1752,7 @@ sr_hotplug_unregister(struct sr_discipli
if (mhe != NULL) {
SLIST_REMOVE(_hotplug_callbacks, mhe,
sr_hotplug_list, shl_link);
- free(mhe, M_DEVBUF, 0);
+ free(mhe, M_DEVBUF, sizeof(*mhe));
}
}
@@ -1953,7 +1954,7 @@ sr_ccb_free(struct sr_discipline *sd)
while ((ccb = TAILQ_FIRST(>sd_ccb_freeq)) != NULL)
TAILQ_REMOVE(>sd_ccb_freeq, ccb, ccb_link);
- free(sd->sd_ccb, M_DEVBUF, 0);
+ free(sd->sd_ccb, M_DEVBUF, sizeof(*sd->sd_ccb));
}
struct sr_ccb *
@@ -2132,7 +2133,7 @@ sr_wu_free(struct sr_discipline *sd)
while ((wu = TAILQ_FIRST(>sd_wu)) != NULL) {
TAILQ_REMOVE(>sd_wu, wu, swu_next);
- free(wu, M_DEVBUF, 0);
+ free(wu, M_DEVBUF, sizeof(*wu));
}
}
@@ -2966,13 +2967,14 @@ sr_hotspare(struct sr_softc *sc, dev_t d
goto done;
fail:
- free(hotspare, M_DEVBUF, 0);
+ free(hotspare, M_DEVBUF, sizeof(*hotspare));
done:
if (sd)
- free(sd->sd_vol.sv_chunks, M_DEVBUF, 0);
- free(sd, M_DEVBUF, 0);
- free(sm, M_DEVBUF, 0);
+ free(sd->sd_vol.sv_chunks, M_DEVBUF,
+ sizeof(sd->sd_vol.sv_chunks));
+ free(sd, M_DEVBUF, sizeof(*sd));
+ free(sm, M_DEVBUF, sizeof(*sm));
if (open) {
VOP_CLOSE(vn, FREAD | FWRITE, NOCRED, curproc);
vput(vn);
@@ -3079,7 +3081,7 @@ sr_hotspare_rebuild(struct sr_discipline
/* Remove hotspare from available list. */
sc->sc_hotspare_no--;
SLIST_REMOVE(cl, hotspare, sr_chunk, src_link);
- free(hotspare, M_DEVBUF, 0);
+ free(hotspare, M_DEVBUF, sizeof(*hotspare));
}
rw_exit_write(>sc_lock);
@@ -3375,7 +3377,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
>sd_meta->ssdi.ssd_uuid);
sr_error(sc, &q
softraid(4): fix wrong malloc size and zero sized free calls
Hi,
The diff mainly add sizes to free(9) calls. But, while here fix a
malloc(9) call with the wrong size in sr_ioctl_installboot().
omi->omi_som is allocated with size of struct sr_meta_crypto, but used
as struct sr_meta_boot later.
One free(9) with size zero left over in sr_discipline_free(). As, the
allocated size of sd->sd_vol.sv_chunks is not ascertainable here without
larger changes.
Build and run the kernel for testing.
OK?
Bye,
Jan
Index: dev/softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.392
diff -u -p -r1.392 softraid.c
--- dev/softraid.c 2 May 2018 02:24:55 - 1.392
+++ dev/softraid.c 13 May 2019 22:40:04 -
@@ -1470,28 +1470,29 @@ unwind:
for (bc1 = SLIST_FIRST(>sbv_chunks); bc1 != NULL;
bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF,
+ sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
- free(bv1, M_DEVBUF, 0);
+ free(bv1, M_DEVBUF, sizeof(*bv1));
}
/* Free keydisks chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
/* Free unallocated chunks. */
for (bc1 = SLIST_FIRST(); bc1 != NULL; bc1 = bc2) {
bc2 = SLIST_NEXT(bc1, sbc_link);
- free(bc1->sbc_metadata, M_DEVBUF, 0);
- free(bc1, M_DEVBUF, 0);
+ free(bc1->sbc_metadata, M_DEVBUF, sizeof(*bc1->sbc_metadata));
+ free(bc1, M_DEVBUF, sizeof(*bc1));
}
while (!SLIST_EMPTY()) {
sdk = SLIST_FIRST();
SLIST_REMOVE_HEAD(, sdk_link);
- free(sdk, M_DEVBUF, 0);
+ free(sdk, M_DEVBUF, sizeof(*sdk));
}
free(devs, M_DEVBUF, BIOC_CRMAXLEN * sizeof(dev_t));
@@ -1751,7 +1752,7 @@ sr_hotplug_unregister(struct sr_discipli
if (mhe != NULL) {
SLIST_REMOVE(_hotplug_callbacks, mhe,
sr_hotplug_list, shl_link);
- free(mhe, M_DEVBUF, 0);
+ free(mhe, M_DEVBUF, sizeof(*mhe));
}
}
@@ -1953,7 +1954,7 @@ sr_ccb_free(struct sr_discipline *sd)
while ((ccb = TAILQ_FIRST(>sd_ccb_freeq)) != NULL)
TAILQ_REMOVE(>sd_ccb_freeq, ccb, ccb_link);
- free(sd->sd_ccb, M_DEVBUF, 0);
+ free(sd->sd_ccb, M_DEVBUF, sizeof(*sd->sd_ccb));
}
struct sr_ccb *
@@ -2132,7 +2133,7 @@ sr_wu_free(struct sr_discipline *sd)
while ((wu = TAILQ_FIRST(>sd_wu)) != NULL) {
TAILQ_REMOVE(>sd_wu, wu, swu_next);
- free(wu, M_DEVBUF, 0);
+ free(wu, M_DEVBUF, sizeof(*wu));
}
}
@@ -2966,13 +2967,14 @@ sr_hotspare(struct sr_softc *sc, dev_t d
goto done;
fail:
- free(hotspare, M_DEVBUF, 0);
+ free(hotspare, M_DEVBUF, sizeof(*hotspare));
done:
if (sd)
- free(sd->sd_vol.sv_chunks, M_DEVBUF, 0);
- free(sd, M_DEVBUF, 0);
- free(sm, M_DEVBUF, 0);
+ free(sd->sd_vol.sv_chunks, M_DEVBUF,
+ sizeof(sd->sd_vol.sv_chunks));
+ free(sd, M_DEVBUF, sizeof(*sd));
+ free(sm, M_DEVBUF, sizeof(*sm));
if (open) {
VOP_CLOSE(vn, FREAD | FWRITE, NOCRED, curproc);
vput(vn);
@@ -3079,7 +3081,7 @@ sr_hotspare_rebuild(struct sr_discipline
/* Remove hotspare from available list. */
sc->sc_hotspare_no--;
SLIST_REMOVE(cl, hotspare, sr_chunk, src_link);
- free(hotspare, M_DEVBUF, 0);
+ free(hotspare, M_DEVBUF, sizeof(*hotspare));
}
rw_exit_write(>sc_lock);
@@ -3375,7 +3377,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
>sd_meta->ssdi.ssd_uuid);
sr_error(sc, "disk %s is currently in use; "
"cannot force create", uuid);
- free(uuid, M_DEVBUF, 0);
+ free(uuid, M_DEVBUF, 37);
goto unwind;
}
@@ -3439,7 +3441,7 @@ sr_ioctl_createraid(struct sr_softc *sc,
if (sr_already_assembled(sd)) {
uuid = sr_uuid_format(>sd_meta->ssdi.ssd_uuid);
sr_error(sc, "disk %s already
enable cy(4) by default on amd64
Hi, I use tree cy(4) cards on amd64 for several releases. Its totally stable and works fine beside known bugs already mentioned in the manpage. Thus, I would prefer to enabled it by default in amd64 as it is in i386. Bye, Jan Index: arch/amd64/conf/GENERIC === RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.471 diff -u -p -r1.471 GENERIC --- arch/amd64/conf/GENERIC 8 May 2019 23:54:39 - 1.471 +++ arch/amd64/conf/GENERIC 13 May 2019 05:13:47 - @@ -382,7 +382,7 @@ com*at pcmcia? # PCMCIA modems/serial com* at puc? # options CY_HW_RTS -#cy* at pci? # PCI cyclom serial card +cy*at pci? # PCI cyclom serial card #cz* at pci? # Cyclades-Z multi-port serial boards lpt0 at isa? port 0x378 irq 7# standard PC parallel ports
sv(4): fix free with zero size
Hi,
The following diff fixes "free with zero size" in sv(4). Builds and
stats the kernel with sv at pci and audio at sv enabled.
bye,
Jan
Index: dev/pci/sv.c
===
RCS file: /cvs/src/sys/dev/pci/sv.c,v
retrieving revision 1.34
diff -u -p -r1.34 sv.c
--- dev/pci/sv.c19 Sep 2016 06:46:44 - 1.34
+++ dev/pci/sv.c13 May 2019 04:33:56 -
@@ -1286,7 +1286,7 @@ sv_malloc(void *addr, int direction, siz
return (0);
error = sv_allocmem(sc, size, 16, p);
if (error) {
-free(p, pool, 0);
+free(p, pool, sizeof(*p));
return (0);
}
p->next = sc->sc_dmas;
@@ -1304,7 +1304,7 @@ sv_free(void *addr, void *ptr, int pool)
if (KERNADDR(*p) == ptr) {
sv_freemem(sc, *p);
*p = (*p)->next;
-free(*p, pool, 0);
+free(*p, pool, sizeof(**p));
return;
}
}
Re: ftpd(8): rm dead code and simplifies popen clone
On Wed, May 08, 2019 at 07:10:37PM -0400, Ted Unangst wrote:
> Jan Klemkow wrote:
> > - * Special version of popen which avoids call to shell. This ensures noone
> > + * Special version of popen which avoids call to shell. This ensures none
>
> If we don't like noone, the correct spelling is no one.
>
> Rest of the diff seems like a good improvement.
fixed.
Thanks,
Jan
Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.19
diff -u -p -r1.19 extern.h
--- extern.h4 Oct 2015 11:58:09 - 1.19
+++ extern.h8 May 2019 20:02:23 -
@@ -68,7 +68,7 @@ void delete(char *);
void dologout(int);
void fatal(char *);
intftpd_pclose(FILE *, pid_t);
-FILE *ftpd_popen(char *, char *, pid_t *);
+FILE *ftpd_ls(char *, char *, pid_t *);
int get_line(char *, int, FILE *);
void ftpdlogwtmp(char *, char *, char *);
void lreply(int, const char *, ...);
@@ -89,7 +89,8 @@ void renamecmd(char *, char *);
char *renamefrom(char *);
void reply(int, const char *, ...);
void reply_r(int, const char *, ...);
-void retrieve(char *, char *);
+enum ret_cmd { RET_FILE, RET_LIST };
+void retrieve(enum ret_cmd, char *);
void send_file_list(char *);
void setproctitle(const char *, ...);
void statcmd(void);
Index: ftpcmd.y
===
RCS file: /cvs/src/libexec/ftpd/ftpcmd.y,v
retrieving revision 1.66
diff -u -p -r1.66 ftpcmd.y
--- ftpcmd.y27 Apr 2017 13:30:54 - 1.66
+++ ftpcmd.y8 May 2019 20:03:29 -
@@ -342,7 +342,7 @@ cmd
| RETR check_login SP pathname CRLF
{
if ($2 && $4 != NULL)
- retrieve(NULL, $4);
+ retrieve(RET_FILE, $4);
if ($4 != NULL)
free($4);
}
@@ -374,12 +374,12 @@ cmd
| LIST check_login CRLF
{
if ($2)
- retrieve("/bin/ls -lgA", "");
+ retrieve(RET_LIST, NULL);
}
| LIST check_login SP pathname CRLF
{
if ($2 && $4 != NULL)
- retrieve("/bin/ls -lgA %s", $4);
+ retrieve(RET_LIST, $4);
if ($4 != NULL)
free($4);
}
Index: ftpd.8
===
RCS file: /cvs/src/libexec/ftpd/ftpd.8,v
retrieving revision 1.75
diff -u -p -r1.75 ftpd.8
--- ftpd.8 25 Oct 2015 23:10:53 - 1.75
+++ ftpd.8 8 May 2019 20:08:15 -
@@ -385,15 +385,6 @@ subtree be constructed with care, follow
Make the home directory owned by
.Dq root
and unwritable by anyone (mode 555).
-.It Pa ~ftp/bin
-Make this directory owned by
-.Dq root
-and unwritable by anyone (mode 511).
-This directory is optional unless you have commands you wish
-the anonymous FTP user to be able to run (the
-.Xr ls 1
-command exists as a built-in).
-Any programs in this directory should be mode 111 (executable only).
.It Pa ~ftp/etc
Make this directory owned by
.Dq root
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.225
diff -u -p -r1.225 ftpd.c
--- ftpd.c 11 Dec 2018 18:19:55 - 1.225
+++ ftpd.c 8 May 2019 22:45:07 -
@@ -1113,36 +1113,32 @@ bad:
}
void
-retrieve(char *cmd, char *name)
+retrieve(enum ret_cmd cmd, char *name)
{
FILE *fin, *dout;
struct stat st;
pid_t pid;
time_t start;
- if (cmd == NULL) {
+ if (cmd == RET_FILE) {
fin = fopen(name, "r");
st.st_size = 0;
} else {
- char line[BUFSIZ];
-
- (void) snprintf(line, sizeof(line), cmd, name);
- name = line;
- fin = ftpd_popen(line, "r", );
+ fin = ftpd_ls("-lgA", name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
if (fin == NULL) {
if (errno != 0) {
perror_reply(550, name);
- if (cmd == NULL) {
+ if (cmd == RET_FILE) {
LOGCMD("get", name);
}
}
return;
}
byte_count = -1;
- if (cmd == NULL &&
+ if (cmd == RET_FILE &&
(fstat(fileno(fin), ) < 0 || !S_ISREG(st.st_mode))) {
reply(550, "%s: not a plain file.", name);
goto done;
@@ -1175,
ftpd(8): rm dead code and simplifies popen clone
Hi,
This diff removes dead code from ftpd(8). In the past ftpd executes
ls(1) for directory listings. But, quite a while now It justs calls the
main function of the linked in ls(1) directly. The code path to the
main function of ls(1) as well as the read-only mode are hard coded in
the current version of ftpd. All callers of ftpd_popen() calls it with
"/bin/ls" as program path. The diff below renames ftpd_popen() to
ftpd_ls() and simplifies the function. Also, the manpage section to
"~ftp/bin" is removed, because ftpd is not able to exec other programs.
I don't know if its usual?! But, I used an enum to signal file transfer
or listing for the retrieve function. The code seems to be more
readable for for me.
bye,
Jan
Index: extern.h
===
RCS file: /cvs/src/libexec/ftpd/extern.h,v
retrieving revision 1.19
diff -u -p -r1.19 extern.h
--- extern.h4 Oct 2015 11:58:09 - 1.19
+++ extern.h8 May 2019 20:02:23 -
@@ -68,7 +68,7 @@ void delete(char *);
void dologout(int);
void fatal(char *);
intftpd_pclose(FILE *, pid_t);
-FILE *ftpd_popen(char *, char *, pid_t *);
+FILE *ftpd_ls(char *, char *, pid_t *);
int get_line(char *, int, FILE *);
void ftpdlogwtmp(char *, char *, char *);
void lreply(int, const char *, ...);
@@ -89,7 +89,8 @@ void renamecmd(char *, char *);
char *renamefrom(char *);
void reply(int, const char *, ...);
void reply_r(int, const char *, ...);
-void retrieve(char *, char *);
+enum ret_cmd { RET_FILE, RET_LIST };
+void retrieve(enum ret_cmd, char *);
void send_file_list(char *);
void setproctitle(const char *, ...);
void statcmd(void);
Index: ftpcmd.y
===
RCS file: /cvs/src/libexec/ftpd/ftpcmd.y,v
retrieving revision 1.66
diff -u -p -r1.66 ftpcmd.y
--- ftpcmd.y27 Apr 2017 13:30:54 - 1.66
+++ ftpcmd.y8 May 2019 20:03:29 -
@@ -342,7 +342,7 @@ cmd
| RETR check_login SP pathname CRLF
{
if ($2 && $4 != NULL)
- retrieve(NULL, $4);
+ retrieve(RET_FILE, $4);
if ($4 != NULL)
free($4);
}
@@ -374,12 +374,12 @@ cmd
| LIST check_login CRLF
{
if ($2)
- retrieve("/bin/ls -lgA", "");
+ retrieve(RET_LIST, NULL);
}
| LIST check_login SP pathname CRLF
{
if ($2 && $4 != NULL)
- retrieve("/bin/ls -lgA %s", $4);
+ retrieve(RET_LIST, $4);
if ($4 != NULL)
free($4);
}
Index: ftpd.8
===
RCS file: /cvs/src/libexec/ftpd/ftpd.8,v
retrieving revision 1.75
diff -u -p -r1.75 ftpd.8
--- ftpd.8 25 Oct 2015 23:10:53 - 1.75
+++ ftpd.8 8 May 2019 20:08:15 -
@@ -385,15 +385,6 @@ subtree be constructed with care, follow
Make the home directory owned by
.Dq root
and unwritable by anyone (mode 555).
-.It Pa ~ftp/bin
-Make this directory owned by
-.Dq root
-and unwritable by anyone (mode 511).
-This directory is optional unless you have commands you wish
-the anonymous FTP user to be able to run (the
-.Xr ls 1
-command exists as a built-in).
-Any programs in this directory should be mode 111 (executable only).
.It Pa ~ftp/etc
Make this directory owned by
.Dq root
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.225
diff -u -p -r1.225 ftpd.c
--- ftpd.c 11 Dec 2018 18:19:55 - 1.225
+++ ftpd.c 8 May 2019 22:45:07 -
@@ -1113,36 +1113,32 @@ bad:
}
void
-retrieve(char *cmd, char *name)
+retrieve(enum ret_cmd cmd, char *name)
{
FILE *fin, *dout;
struct stat st;
pid_t pid;
time_t start;
- if (cmd == NULL) {
+ if (cmd == RET_FILE) {
fin = fopen(name, "r");
st.st_size = 0;
} else {
- char line[BUFSIZ];
-
- (void) snprintf(line, sizeof(line), cmd, name);
- name = line;
- fin = ftpd_popen(line, "r", );
+ fin = ftpd_ls("-lgA", name, );
st.st_size = -1;
st.st_blksize = BUFSIZ;
}
if (fin == NULL) {
if (errno != 0) {
perror_reply(550, name);
- if (cmd == NULL) {
+ if (cmd == RET_FILE) {
LOGCMD("get", name);
}
}
return;
}
byte_count = -1;
- if (cmd ==
diff: reboot(8): document the -l option
Hi,
The following diff adds missing documentation for the -l option of
reboot(8) as its done in NetBSD.
Bye,
Jan
Index: reboot.8
===
RCS file: /cvs/src/sbin/reboot/reboot.8,v
retrieving revision 1.50
diff -u -p -r1.50 reboot.8
--- reboot.83 Sep 2016 14:25:05 - 1.50
+++ reboot.825 Mar 2019 14:12:48 -
@@ -30,7 +30,7 @@
.\"
.\"@(#)reboot.88.1 (Berkeley) 6/9/93
.\"
-.Dd $Mdocdate: September 3 2016 $
+.Dd $Mdocdate: March 25 2019 $
.Dt REBOOT 8
.Os
.Sh NAME
@@ -39,9 +39,9 @@
.Nd stopping and restarting the system
.Sh SYNOPSIS
.Nm halt
-.Op Fl dnpq
+.Op Fl dlnpq
.Nm reboot
-.Op Fl dnq
+.Op Fl dlnq
.Sh DESCRIPTION
The
.Nm halt
@@ -70,6 +70,10 @@ capturing the state of a corrupted or mi
See
.Xr savecore 8
for information on how to recover this dump.
+.It Fl l
+Suppress sending a message via
+.Xr syslog 3
+before halting or restarting.
.It Fl n
Prevent file system cache from being flushed.
This option should probably not be used.
Index: reboot.c
===
RCS file: /cvs/src/sbin/reboot/reboot.c,v
retrieving revision 1.38
diff -u -p -r1.38 reboot.c
--- reboot.c22 Aug 2017 00:30:16 - 1.38
+++ reboot.c25 Mar 2019 14:03:43 -
@@ -94,7 +94,7 @@ main(int argc, char *argv[])
case 'd':
howto |= RB_DUMP;
break;
- case 'l': /* Undocumented; used by shutdown. */
+ case 'l':
lflag = 1;
break;
case 'n':
@@ -272,7 +272,7 @@ restart:
void
usage(void)
{
- fprintf(stderr, "usage: %s [-dn%sq]\n", __progname,
+ fprintf(stderr, "usage: %s [-dln%sq]\n", __progname,
dohalt ? "p" : "");
exit(1);
}
diff: add support for ANT-USBStick2 to uscom(4)
Hi,
The diff below adds support for the Dynastream "ANT USBStick2" to
uscom(4). The device attached with the following message:
uscom0 at uhub0 port 2 configuration 1 interface 0 "Dynastream Innovations ANT
USBStick2" rev 2.00/1.00 addr 2
ucom0 at uscom0 portno 0
Additionally, I tested the device with the command:
# cu -l /dev/cuaU0 | od -h
... a4 01 ae 00 0b ...
It returns a valid ANT binary error message.
Bye,
Jan
Index: dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.694
diff -u -p -r1.694 usbdevs
--- dev/usb/usbdevs 14 Jan 2019 03:28:03 - 1.694
+++ dev/usb/usbdevs 22 Feb 2019 17:54:59 -
@@ -1640,6 +1640,7 @@ product DVICO RT3070 0xb307 RT3070
product DYNASTREAM ANTDEVBOARD 0x1003 ANT dev board
product DYNASTREAM ANT2USB 0x1004 ANT2USB
product DYNASTREAM ANTDEVBOARD20x1006 ANT dev board
+product DYNASTREAM ANTUSB2 0x1008 ANTUSB-2 Stick
product DYNASTREAM ANTUSBM 0x1009 ANTUSB-m Stick
/* EasyDisk products */
Index: dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.706
diff -u -p -r1.706 usbdevs.h
--- dev/usb/usbdevs.h 14 Jan 2019 03:28:51 - 1.706
+++ dev/usb/usbdevs.h 22 Feb 2019 18:05:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.706 2019/01/14 03:28:51 jmatthew Exp $ */
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -1647,6 +1647,7 @@
#defineUSB_PRODUCT_DYNASTREAM_ANTDEVBOARD 0x1003 /* ANT
dev board */
#defineUSB_PRODUCT_DYNASTREAM_ANT2USB 0x1004 /* ANT2USB */
#defineUSB_PRODUCT_DYNASTREAM_ANTDEVBOARD2 0x1006 /* ANT
dev board */
+#defineUSB_PRODUCT_DYNASTREAM_ANTUSB2 0x1008 /* ANTUSB-2
Stick */
#defineUSB_PRODUCT_DYNASTREAM_ANTUSBM 0x1009 /* ANTUSB-m
Stick */
/* EasyDisk products */
Index: dev/usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.700
diff -u -p -r1.700 usbdevs_data.h
--- dev/usb/usbdevs_data.h 14 Jan 2019 03:28:51 - 1.700
+++ dev/usb/usbdevs_data.h 22 Feb 2019 18:05:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.700 2019/01/14 03:28:51 jmatthew Exp $
*/
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -2876,6 +2876,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTDEVBOARD2,
"ANT dev board",
+ },
+ {
+ USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTUSB2,
+ "ANTUSB-2 Stick",
},
{
USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTUSBM,
Index: dev/usb/uscom.c
===
RCS file: /cvs/src/sys/dev/usb/uscom.c,v
retrieving revision 1.6
diff -u -p -r1.6 uscom.c
--- dev/usb/uscom.c 22 Aug 2018 15:32:49 - 1.6
+++ dev/usb/uscom.c 22 Feb 2019 17:55:44 -
@@ -53,6 +53,7 @@ struct ucom_methods uscom_methods = {
static const struct usb_devno uscom_devs[] = {
{ USB_VENDOR_HP,USB_PRODUCT_HP_HPX9GP },
+ { USB_VENDOR_DYNASTREAM,USB_PRODUCT_DYNASTREAM_ANTUSB2 },
{ USB_VENDOR_DYNASTREAM,USB_PRODUCT_DYNASTREAM_ANTUSBM }
};
diff: add missing bit description for pkthdr_pf.flags
Hi,
The following diff adds the description of the second bit of the struct
pkthdr_pf field flags.
bye,
Jan
Index: sys/sys/mbuf.h
===
RCS file: /cvs/src/sys/sys/mbuf.h,v
retrieving revision 1.241
diff -u -p -r1.241 mbuf.h
--- sys/sys/mbuf.h 7 Dec 2018 08:37:24 - 1.241
+++ sys/sys/mbuf.h 8 Feb 2019 16:25:12 -
@@ -119,8 +119,8 @@ struct pkthdr_pf {
#ifdef _KERNEL
#define MPF_BITS \
-("\20\1GENERATED\3TRANSLATE_LOCALHOST\4DIVERTED\5DIVERTED_PACKET" \
-"\6REROUTE\7REFRAGMENTED\10PROCESSED")
+("\20\1GENERATED\2SYNCOOKIE_RECREATED\3TRANSLATE_LOCALHOST\4DIVERTED" \
+"\5DIVERTED_PACKET\6REROUTE\7REFRAGMENTED\10PROCESSED")
#endif
/* record/packet header in first mbuf of chain; valid if M_PKTHDR set */
snmpd: dup open ttys to /dev/null in demons mode
Hi,
This diff is similar to bluhm@'s fix for httpd and relayd, but for snmpd.
> During the fork+exec implementation, daemon(3) was moved after
> proc_init(). As a consequence httpd(8) and relayd(8) child processes
> do not detach from the terminal anymore. Dup /dev/null to the stdio
> file descriptors in the children.
bye,
Jan
Index: proc.c
===
RCS file: /cvs/src/usr.sbin/snmpd/proc.c,v
retrieving revision 1.25
diff -u -p -r1.25 proc.c
--- proc.c 5 Aug 2018 09:33:13 - 1.25
+++ proc.c 8 Jan 2019 00:29:29 -
@@ -29,13 +29,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include "snmpd.h"
-voidproc_exec(struct privsep *, struct privsep_proc *, unsigned int,
+voidproc_exec(struct privsep *, struct privsep_proc *, unsigned int, int,
int, char **);
voidproc_setup(struct privsep *, struct privsep_proc *, unsigned int);
voidproc_open(struct privsep *, int, int);
@@ -80,7 +81,7 @@ proc_getid(struct privsep_proc *procs, u
void
proc_exec(struct privsep *ps, struct privsep_proc *procs, unsigned int nproc,
-int argc, char **argv)
+int debug, int argc, char **argv)
{
unsigned int proc, nargc, i, proc_i;
char**nargv;
@@ -141,6 +142,16 @@ proc_exec(struct privsep *ps, struct pri
} else if (fcntl(fd, F_SETFD, 0) == -1)
fatal("fcntl");
+ /* Daemons detach from terminal. */
+ if (!debug && (fd =
+ open(_PATH_DEVNULL, O_RDWR, 0)) != -1) {
+ (void)dup2(fd, STDIN_FILENO);
+ (void)dup2(fd, STDOUT_FILENO);
+ (void)dup2(fd, STDERR_FILENO);
+ if (fd > 2)
+ (void)close(fd);
+ }
+
execvp(argv[0], nargv);
fatal("%s: execvp", __func__);
break;
@@ -191,7 +202,7 @@ proc_connect(struct privsep *ps)
void
proc_init(struct privsep *ps, struct privsep_proc *procs, unsigned int nproc,
-int argc, char **argv, enum privsep_procid proc_id)
+int debug, int argc, char **argv, enum privsep_procid proc_id)
{
struct privsep_proc *p = NULL;
struct privsep_pipes*pa, *pb;
@@ -231,7 +242,7 @@ proc_init(struct privsep *ps, struct pri
}
/* Engage! */
- proc_exec(ps, procs, nproc, argc, argv);
+ proc_exec(ps, procs, nproc, debug, argc, argv);
return;
}
Index: snmpd.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.c,v
retrieving revision 1.40
diff -u -p -r1.40 snmpd.c
--- snmpd.c 5 Nov 2018 11:59:05 - 1.40
+++ snmpd.c 8 Jan 2019 00:29:02 -
@@ -230,7 +230,7 @@ main(int argc, char *argv[])
pf_init();
snmpd_generate_engineid(env);
- proc_init(ps, procs, nitems(procs), argc0, argv0, proc_id);
+ proc_init(ps, procs, nitems(procs), debug, argc0, argv0, proc_id);
if (!debug && daemon(0, 0) == -1)
err(1, "failed to daemonize");
Index: snmpd.h
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v
retrieving revision 1.80
diff -u -p -r1.80 snmpd.h
--- snmpd.h 5 Aug 2018 09:33:13 - 1.80
+++ snmpd.h 8 Jan 2019 00:25:01 -
@@ -762,7 +762,7 @@ void usm_make_report(struct snmp_messa
/* proc.c */
enum privsep_procid
proc_getid(struct privsep_proc *, unsigned int, const char *);
-voidproc_init(struct privsep *, struct privsep_proc *, unsigned int,
+voidproc_init(struct privsep *, struct privsep_proc *, unsigned int, int,
int, char **, enum privsep_procid);
voidproc_kill(struct privsep *);
voidproc_connect(struct privsep *);
diff: new PCI Vendor and Product ID for RocketPort serial card
Hi,
the following diff adds the PCI vendor and product ID for a PCI
multiport serial card.
dmesg shows the device as:
"Comtrol Corporation RocketPort PCI 16-port Serial" rev 0x01 at pci1 dev
1 function 0 not configured
bye,
Jan
Index: pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1874
diff -u -p -r1.1874 pcidevs
--- pci/pcidevs 5 Jan 2019 11:49:41 - 1.1874
+++ pci/pcidevs 7 Jan 2019 20:23:36 -
@@ -194,6 +194,7 @@ vendor AD 0x11d4 Analog Devices
vendor ZORAN 0x11de Zoran
vendor PIJNENBURG 0x11e3 Pijnenburg
vendor COMPEX 0x11f6 Compex
+vendor COMCORP 0x11fe Comtrol Corporation
vendor CYCLADES0x120e Cyclades
vendor ESSENTIAL 0x120f Essential Communications
vendor O2MICRO 0x1217 O2 Micro
@@ -2423,6 +2424,9 @@ product COMPAQ NF3P_BNC 0xf150 NetFlex
product COMPEX COMPEXE 0x1401 Compexe
product COMPEX RL100ATX0x2011 RL100-ATX 10/100
product COMPEX 98713 0x9881 PMAC 98713
+
+/* Comtrol Corporation */
+product COMCORP ROCKETPORT_16 0x0009 RocketPort PCI 16-port Serial
/* Conexant products */
product CONEXANT 56K_WINMODEM 0x1033 56k Winmodem
Index: pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1867
diff -u -p -r1.1867 pcidevs.h
--- pci/pcidevs.h 5 Jan 2019 11:50:32 - 1.1867
+++ pci/pcidevs.h 7 Jan 2019 20:23:37 -
@@ -199,6 +199,7 @@
#definePCI_VENDOR_ZORAN0x11de /* Zoran */
#definePCI_VENDOR_PIJNENBURG 0x11e3 /* Pijnenburg */
#definePCI_VENDOR_COMPEX 0x11f6 /* Compex */
+#definePCI_VENDOR_COMCORP 0x11fe /* Comtrol Corporation
*/
#definePCI_VENDOR_CYCLADES 0x120e /* Cyclades */
#definePCI_VENDOR_ESSENTIAL0x120f /* Essential
Communications */
#definePCI_VENDOR_O2MICRO 0x1217 /* O2 Micro */
@@ -2428,6 +2429,9 @@
#definePCI_PRODUCT_COMPEX_COMPEXE 0x1401 /* Compexe */
#definePCI_PRODUCT_COMPEX_RL100ATX 0x2011 /* RL100-ATX
10/100 */
#definePCI_PRODUCT_COMPEX_987130x9881 /* PMAC 98713 */
+
+/* Comtrol Corporation */
+#definePCI_PRODUCT_COMCORP_ROCKETPORT_16 0x0009 /*
RocketPort PCI 16-port Serial */
/* Conexant products */
#definePCI_PRODUCT_CONEXANT_56K_WINMODEM 0x1033 /* 56k
Winmodem */
Index: pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1862
diff -u -p -r1.1862 pcidevs_data.h
--- pci/pcidevs_data.h 5 Jan 2019 11:50:32 - 1.1862
+++ pci/pcidevs_data.h 7 Jan 2019 20:23:37 -
@@ -7680,6 +7680,10 @@ static const struct pci_known_product pc
"PMAC 98713",
},
{
+ PCI_VENDOR_COMCORP, PCI_PRODUCT_COMCORP_ROCKETPORT_16,
+ "RocketPort PCI 16-port Serial",
+ },
+ {
PCI_VENDOR_CONEXANT, PCI_PRODUCT_CONEXANT_56K_WINMODEM,
"56k Winmodem",
},
@@ -28734,6 +28738,10 @@ static const struct pci_known_vendor pci
{
PCI_VENDOR_COMPEX,
"Compex",
+ },
+ {
+ PCI_VENDOR_COMCORP,
+ "Comtrol Corporation",
},
{
PCI_VENDOR_CYCLADES,
diff: fix missing include guard in dev/biovar.h
Hi, I run into double definition problems because of a missing include guard in dev/biovar.h. The diff below should fix that issue. Bye, Jan Index: sys/dev/biovar.h === RCS file: /cvs/src/sys/dev/biovar.h,v retrieving revision 1.45 diff -u -p -r1.45 biovar.h --- sys/dev/biovar.h14 Aug 2016 04:08:03 - 1.45 +++ sys/dev/biovar.h19 Dec 2018 18:00:36 - @@ -26,6 +26,9 @@ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ +#ifndef _DEV_BIOVAR_H_ +#define _DEV_BIOVAR_H_ + /* * Devices getting ioctls through this interface should use ioctl class 'B' * and command numbers starting from 32, lower ones are reserved for generic @@ -305,3 +308,4 @@ voidbio_info(struct bio_status *, int, void bio_warn(struct bio_status *, int, const char *, ...); void bio_error(struct bio_status *, int, const char *, ...); #endif +#endif /* _DEV_BIOVAR_H_ */
Re: diff: ftpd(8): fix for sign-compare compiler warnings
On Tue, Nov 27, 2018 at 09:03:15AM +0100, Theo Buehler wrote:
> On Sun, Nov 25, 2018 at 12:32:23AM +0100, Jan Klemkow wrote:
> > This diff fixes some -Wsign-compare compiler warnings in ftpd(8) by
> > using the right types for 'i' and 'len'. One warning is left, but I
> > don't see that it's fixable without suppressing the warning by a cast of
> > len to size_t. And casting might be controversial in this case?!
>
> The diff looks correct to me. If anyone wants to commit
>
> ok tb
>
> > /usr/src/libexec/ftpd/ftpd.c:2781:11: warning: comparison of integers of
> > different signs: 'int' and
> > 'unsigned long' [-Wsign-compare]
> > if (len >= sizeof(buf) || len == -1) {
> > ~~~ ^ ~~~
>
> This test is the wrong way around: compare CAVEATS in snprintf(3).
I missed that. The following diff fixes that, but doesn't include
a cast.
> There's a ton of unchecked snprintfs in this code. Did you take a look
> at those?
Yes, I noticed that. I may change that in a later diff.
Thanks,
Jan
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.223
diff -u -p -r1.223 ftpd.c
--- ftpd.c 3 Sep 2016 15:00:48 - 1.223
+++ ftpd.c 6 Dec 2018 18:19:21 -
@@ -390,10 +390,10 @@ main(int argc, char *argv[])
endpwent();
if (daemon_mode) {
- int *fds, i, fd;
+ int *fds, fd;
struct pollfd *pfds;
struct addrinfo hints, *res, *res0;
- nfds_t n;
+ nfds_t n, i;
/*
* Detach from parent.
@@ -1809,8 +1809,8 @@ statcmd(void)
ispassive++;
goto printaddr;
} else if (usedefault == 0) {
- size_t alen;
- int af, i;
+ size_t alen, i;
+ int af;
su = (union sockunion *)_dest;
printaddr:
@@ -2545,7 +2545,8 @@ guniquefd(char *local, char **nam)
{
static char new[PATH_MAX];
struct stat st;
- int count, len, fd;
+ size_t len;
+ int count, fd;
char *cp;
cp = strrchr(local, '/');
@@ -2777,7 +2778,7 @@ logxfer(char *name, off_t size, time_t s
((guest) ? "*" : pw->pw_name), dhostname);
free(vpw);
- if (len >= sizeof(buf) || len == -1) {
+ if (len == -1 || len >= sizeof(buf)) {
if ((len = strlen(buf)) == 0)
return; /* should not happen */
buf[len - 1] = '\n';
diff: ftpd(8): fix for sign-compare compiler warnings
Hi,
This diff fixes some -Wsign-compare compiler warnings in ftpd(8) by
using the right types for 'i' and 'len'. One warning is left, but I
don't see that it's fixable without suppressing the warning by a cast of
len to size_t. And casting might be controversial in this case?!
/usr/src/libexec/ftpd/ftpd.c:2781:11: warning: comparison of integers of
different signs: 'int' and
'unsigned long' [-Wsign-compare]
if (len >= sizeof(buf) || len == -1) {
~~~ ^ ~~~
Bye,
Jan
Index: ftpd.c
===
RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
retrieving revision 1.223
diff -u -p -r1.223 ftpd.c
--- ftpd.c 3 Sep 2016 15:00:48 - 1.223
+++ ftpd.c 24 Nov 2018 22:26:02 -
@@ -390,10 +390,10 @@ main(int argc, char *argv[])
endpwent();
if (daemon_mode) {
- int *fds, i, fd;
+ int *fds, fd;
struct pollfd *pfds;
struct addrinfo hints, *res, *res0;
- nfds_t n;
+ nfds_t n, i;
/*
* Detach from parent.
@@ -1809,8 +1809,8 @@ statcmd(void)
ispassive++;
goto printaddr;
} else if (usedefault == 0) {
- size_t alen;
- int af, i;
+ size_t alen, i;
+ int af;
su = (union sockunion *)_dest;
printaddr:
@@ -2545,7 +2545,8 @@ guniquefd(char *local, char **nam)
{
static char new[PATH_MAX];
struct stat st;
- int count, len, fd;
+ size_t len;
+ int count, fd;
char *cp;
cp = strrchr(local, '/');
Re: diff: Fix send(2) EACCES mistake
On Sat, Nov 10, 2018 at 11:22:48AM +0100, Claudio Jeker wrote:
> On Fri, Nov 09, 2018 at 03:49:32PM -0700, Alexander Bluhm wrote:
> > On Fri, Nov 09, 2018 at 09:03:20PM +0100, Jan Klemkow wrote:
> > > On Fri, Nov 09, 2018 at 12:36:20PM -0700, Alexander Bluhm wrote:
> > > > On Fri, Nov 09, 2018 at 08:24:47PM +0100, Jan Klemkow wrote:
> > > > > Perfect, I also think its more intuitive to get a "permission denied"
> > > > > in case of a pf(4) block then a "Host is unreachable". The diff below
> > > > > corrects kernel and extents the manpage for pf(4) blocks.
> > > >
> > > > Don't forget divert_output() and rip_output().
> > >
> > > You are right, I missed that. Fix below.
> >
> > code is OK bluhm@
>
> Also OK claudio@
>
> > > --- lib/libc/sys/send.2 5 Oct 2017 12:30:16 - 1.32
> > > +++ lib/libc/sys/send.2 9 Nov 2018 19:06:47 -
> > > @@ -162,7 +162,9 @@ The output queue for a network interface
> > > This generally indicates that the interface has stopped sending,
> > > but may be caused by transient congestion.
> > > .It Bq Er EACCES
> > > -The
> > > +The connection was blocked by
> > > +.Xr pf 4 ,
> > > +or
> > > .Dv SO_BROADCAST
> > > option is not set on the socket, and a broadcast address
> > > was given as the destination.
> >
> > I have seen man pages that have multiple entries of the errno,
> > instead of the "or" for different reasons in the text.
> >
> > +.It Bq Er EACCES
> > +The connection was blocked by
> > +.Xr pf 4 .
> > .It Bq Er EACCES
> > The
> > .Dv SO_BROADCAST
> > option is not set on the socket, and a broadcast address
> > was given as the destination.
> >
> > What is our style here?
>
> This is something for jmc@ to decided. I'm happy with both versions.
Diff with fixed manpage from jmc.
Thanks,
Jan
Index: sys/netinet/ip_divert.c
===
RCS file: /cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.59
diff -u -p -r1.59 ip_divert.c
--- sys/netinet/ip_divert.c 4 Oct 2018 17:33:41 - 1.59
+++ sys/netinet/ip_divert.c 9 Nov 2018 19:48:25 -
@@ -157,8 +157,6 @@ divert_output(struct inpcb *inp, struct
error = ip_output(m, NULL, >inp_route,
IP_ALLOWBROADCAST | IP_RAWOUTPUT, NULL, NULL, 0);
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
}
divstat_inc(divs_opackets);
Index: sys/netinet/raw_ip.c
===
RCS file: /cvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.114
diff -u -p -r1.114 raw_ip.c
--- sys/netinet/raw_ip.c4 Oct 2018 17:33:41 - 1.114
+++ sys/netinet/raw_ip.c9 Nov 2018 19:46:33 -
@@ -292,8 +292,6 @@ rip_output(struct mbuf *m, struct socket
error = ip_output(m, inp->inp_options, >inp_route, flags,
inp->inp_moptions, inp, 0);
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
return (error);
}
Index: sys/netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.127
diff -u -p -r1.127 tcp_output.c
--- sys/netinet/tcp_output.c9 Nov 2018 14:14:31 - 1.127
+++ sys/netinet/tcp_output.c9 Nov 2018 18:53:02 -
@@ -1084,8 +1084,6 @@ out:
tcp_mtudisc(tp->t_inpcb, -1);
return (0);
}
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
if ((error == EHOSTUNREACH || error == ENETDOWN) &&
TCPS_HAVERCVDSYN(tp->t_state)) {
tp->t_softerror = error;
Index: sys/netinet/udp_usrreq.c
===
RCS file: /cvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.253
diff -u -p -r1.253 udp_usrreq.c
--- sys/netinet/udp_usrreq.c4 Oct 2018 17:33:41 - 1.253
+++ sys/netinet/udp_usrreq.c9 Nov 2018 18:52:08 -
@@ -1004,8 +1004,6 @@ udp_output(struct inpcb *inp, struct mbu
error = ip_output(m, inp->inp_options, >inp_route,
(inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
inp, ipsecflowinfo);
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
bail:
m_fr
Re: diff: Fix send(2) EACCES mistake
On Fri, Nov 09, 2018 at 12:36:20PM -0700, Alexander Bluhm wrote:
> On Fri, Nov 09, 2018 at 08:24:47PM +0100, Jan Klemkow wrote:
> > Perfect, I also think its more intuitive to get a "permission denied"
> > in case of a pf(4) block then a "Host is unreachable". The diff below
> > corrects kernel and extents the manpage for pf(4) blocks.
>
> Don't forget divert_output() and rip_output().
You are right, I missed that. Fix below.
Thanks,
Jan
Index: sys/netinet/ip_divert.c
===
RCS file: /cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.59
diff -u -p -r1.59 ip_divert.c
--- sys/netinet/ip_divert.c 4 Oct 2018 17:33:41 - 1.59
+++ sys/netinet/ip_divert.c 9 Nov 2018 19:48:25 -
@@ -157,8 +157,6 @@ divert_output(struct inpcb *inp, struct
error = ip_output(m, NULL, >inp_route,
IP_ALLOWBROADCAST | IP_RAWOUTPUT, NULL, NULL, 0);
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
}
divstat_inc(divs_opackets);
Index: sys/netinet/raw_ip.c
===
RCS file: /cvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.114
diff -u -p -r1.114 raw_ip.c
--- sys/netinet/raw_ip.c4 Oct 2018 17:33:41 - 1.114
+++ sys/netinet/raw_ip.c9 Nov 2018 19:46:33 -
@@ -292,8 +292,6 @@ rip_output(struct mbuf *m, struct socket
error = ip_output(m, inp->inp_options, >inp_route, flags,
inp->inp_moptions, inp, 0);
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
return (error);
}
Index: sys/netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.127
diff -u -p -r1.127 tcp_output.c
--- sys/netinet/tcp_output.c9 Nov 2018 14:14:31 - 1.127
+++ sys/netinet/tcp_output.c9 Nov 2018 18:53:02 -
@@ -1084,8 +1084,6 @@ out:
tcp_mtudisc(tp->t_inpcb, -1);
return (0);
}
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
if ((error == EHOSTUNREACH || error == ENETDOWN) &&
TCPS_HAVERCVDSYN(tp->t_state)) {
tp->t_softerror = error;
Index: sys/netinet/udp_usrreq.c
===
RCS file: /cvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.253
diff -u -p -r1.253 udp_usrreq.c
--- sys/netinet/udp_usrreq.c4 Oct 2018 17:33:41 - 1.253
+++ sys/netinet/udp_usrreq.c9 Nov 2018 18:52:08 -
@@ -1004,8 +1004,6 @@ udp_output(struct inpcb *inp, struct mbu
error = ip_output(m, inp->inp_options, >inp_route,
(inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
inp, ipsecflowinfo);
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
bail:
m_freem(control);
Index: lib/libc/sys/send.2
===
RCS file: /cvs/src/lib/libc/sys/send.2,v
retrieving revision 1.32
diff -u -p -r1.32 send.2
--- lib/libc/sys/send.2 5 Oct 2017 12:30:16 - 1.32
+++ lib/libc/sys/send.2 9 Nov 2018 19:06:47 -
@@ -162,7 +162,9 @@ The output queue for a network interface
This generally indicates that the interface has stopped sending,
but may be caused by transient congestion.
.It Bq Er EACCES
-The
+The connection was blocked by
+.Xr pf 4 ,
+or
.Dv SO_BROADCAST
option is not set on the socket, and a broadcast address
was given as the destination.
Re: diff: Fix send(2) EACCES mistake
On Fri, Nov 09, 2018 at 06:57:16PM +0100, Claudio Jeker wrote:
> On Fri, Nov 09, 2018 at 06:09:34PM +0100, Jan Klemkow wrote:
> > I printed the code path below to make it easier to review the diff.
> > While I was following the code path again, I found an inconsistency
> > between udp_output() and upd6_output(). Just upd_output() turns EACCES
> > to EHOSTUNREACH, udp6_output does not. The Diff below fixes udp6_output
> > and rounds up the sendto(2) manpage.
> >
> > Reviewer guide from sendto(2) to EHOSTUNREACH:
> >
> > sys_sendto() -> sendit() -> sosend() ---+
> > |
> > +--+
> > |
> > +-> udp_usrreq() -> udp_output():
> > | ...
> > | error = ip_output(m, inp->inp_options, >inp_route,
> > | (inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
> > | inp, ipsecflowinfo);
> > | if (error == EACCES)/* translate pf(4) error for userland */
> > | error = EHOSTUNREACH;
> > | ...
> > |
> > +-> udp_usrreq() -> udp6_output():
> > | ...
> > | error = ip6_output(m, optp, >inp_route6,
> > | flags, in6p->inp_moptions6, in6p);
> > | if (error == EACCES)/* translate pf(4) error for userland */
> > | error = EHOSTUNREACH;
> > | ...
> > |
> > +-> tcp_usrreq() -> tcp_output():
> > ...
> > error = ip_output(m, tp->t_inpcb->inp_options,
> > tp->t_inpcb->inp_route,
> > ip_mtudisc ? IP_MTUDISC : 0), NULL, tp->t_inpcb, 0);
> > ...
> > error = ip6_output(m, tp->t_inpcb->inp_outputopts6,
> > >t_inpcb->inp_route6,
> > 0, NULL, tp->t_inpcb);
> > ...
> > if (error == EACCES)/* translate pf(4) error for userland */
> > error = EHOSTUNREACH;
> > ...
> >
>
> I really don't like this translation and therefor change of semantics of
> an old documented errno code.
>
> If I remember correctly this was added because of the fear that EACCES was
> not properly handled when used with write(2) since it is not documented
> there but neither is EHOSTUNREACH.
>
> I would prefer to remove this errno translation magic for pf(4) in the
> midlayer of the network code. As shown it is always prone for errors.
Hi Claudio,
Perfect, I also think its more intuitive to get a "permission denied"
in case of a pf(4) block then a "Host is unreachable". The diff below
corrects kernel and extents the manpage for pf(4) blocks.
Thanks,
Jan
Index: sys/netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.127
diff -u -p -r1.127 tcp_output.c
--- sys/netinet/tcp_output.c9 Nov 2018 14:14:31 - 1.127
+++ sys/netinet/tcp_output.c9 Nov 2018 18:53:02 -
@@ -1084,8 +1084,6 @@ out:
tcp_mtudisc(tp->t_inpcb, -1);
return (0);
}
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
if ((error == EHOSTUNREACH || error == ENETDOWN) &&
TCPS_HAVERCVDSYN(tp->t_state)) {
tp->t_softerror = error;
Index: sys/netinet/udp_usrreq.c
===
RCS file: /cvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.253
diff -u -p -r1.253 udp_usrreq.c
--- sys/netinet/udp_usrreq.c4 Oct 2018 17:33:41 - 1.253
+++ sys/netinet/udp_usrreq.c9 Nov 2018 18:52:08 -
@@ -1004,8 +1004,6 @@ udp_output(struct inpcb *inp, struct mbu
error = ip_output(m, inp->inp_options, >inp_route,
(inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions,
inp, ipsecflowinfo);
- if (error == EACCES)/* translate pf(4) error for userland */
- error = EHOSTUNREACH;
bail:
m_freem(control);
Index: lib/libc/sys//send.2
===
RCS file: /cvs/src/lib/libc/sys/send.2,v
retrieving revision 1.32
diff -u -p -r1.32 send.2
--- lib/libc/sys//send.25 Oct 2017 12:30:16 - 1.32
+++ lib/libc/sys//send.29 Nov 2018 19:06:47 -
@@ -162,7 +162,9 @@ The output queue for a network interface
This generally indicates that the interface has stopped sending,
but may be caused by transient congestion.
.It Bq Er EACCES
-The
+The connection was blocked by
+.Xr pf 4 ,
+or
.Dv SO_BROADCAST
option is not set on the socket, and a broadcast address
was given as the destination.
Re: diff: Fix send(2) EACCES mistake
On Tue, Oct 30, 2018 at 07:13:24AM +, Jason McIntyre wrote: > On Mon, Oct 29, 2018 at 11:55:52PM +0100, Jan Klemkow wrote: > > On Sun, Oct 28, 2018 at 10:58:34PM +, Jason McIntyre wrote: > > > On Sun, Oct 28, 2018 at 09:40:33PM +0100, Jan Klemkow wrote: > > > > Unlike the manpage saids or one might think , sendto(2) sets errno to > > > > EHOSTUNREACH instead of EACCES in cases of blocking by pf(4) or not > > > > enabled broadcasts. Finally I ran into both cases and think, its time > > > > to fix this issue. The diff suggests a new explanation that should > > > > cover all error cases. > > > > > > > > Index: /usr/src/lib/libc/sys/send.2 > > > > === > > > > RCS file: /cvs/src/lib/libc/sys/send.2,v > > > > retrieving revision 1.32 > > > > diff -u -p -r1.32 send.2 > > > > --- /usr/src/lib/libc/sys/send.25 Oct 2017 12:30:16 - > > > > 1.32 > > > > +++ /usr/src/lib/libc/sys/send.228 Oct 2018 20:16:20 - > > > > @@ -161,13 +161,13 @@ The operation may succeed when buffers b > > > > The output queue for a network interface was full. > > > > This generally indicates that the interface has stopped sending, > > > > but may be caused by transient congestion. > > > > -.It Bq Er EACCES > > > > -The > > > > -.Dv SO_BROADCAST > > > > -option is not set on the socket, and a broadcast address > > > > -was given as the destination. > > > > .It Bq Er EHOSTUNREACH > > > > -The destination address specified an unreachable host. > > > > +The destination address specified an host that is unreachable, > > > > > > unless you're going for humour, "a host" rather than "an host". > > > > > > i can;t comment on the accuracy, but the rest of the diff reads ok. > > > > No humour (here in Germany), just a spelling mistakes :-) > > Fixed version below. > > morning. > > to be fair, some people do still unambiguously use "an" before h* words. > so as such it is not wrong (i think). still, our pages do not use that format. > > anyway, enough of the small stuff. who wants to review this page and > actually ok or nok it? Hi, I printed the code path below to make it easier to review the diff. While I was following the code path again, I found an inconsistency between udp_output() and upd6_output(). Just upd_output() turns EACCES to EHOSTUNREACH, udp6_output does not. The Diff below fixes udp6_output and rounds up the sendto(2) manpage. Bye, Jan Reviewer guide from sendto(2) to EHOSTUNREACH: sys_sendto() -> sendit() -> sosend() ---+ | +--+ | +-> udp_usrreq() -> udp_output(): | ... | error = ip_output(m, inp->inp_options, >inp_route, | (inp->inp_socket->so_options & SO_BROADCAST), inp->inp_moptions, | inp, ipsecflowinfo); | if (error == EACCES)/* translate pf(4) error for userland */ | error = EHOSTUNREACH; | ... | +-> udp_usrreq() -> udp6_output(): | ... | error = ip6_output(m, optp, >inp_route6, | flags, in6p->inp_moptions6, in6p); | if (error == EACCES)/* translate pf(4) error for userland */ | error = EHOSTUNREACH; | ... | +-> tcp_usrreq() -> tcp_output(): ... error = ip_output(m, tp->t_inpcb->inp_options, tp->t_inpcb->inp_route, ip_mtudisc ? IP_MTUDISC : 0), NULL, tp->t_inpcb, 0); ... error = ip6_output(m, tp->t_inpcb->inp_outputopts6, >t_inpcb->inp_route6, 0, NULL, tp->t_inpcb); ... if (error == EACCES)/* translate pf(4) error for userland */ error = EHOSTUNREACH; ... Index: sys/netinet6/udp6_output.c === RCS file: /cvs/src/sys/netinet6/udp6_output.c,v retrieving revision 1.56 diff -u -p -r1.56 udp6_output.c --- sys/netinet6/udp6_output.c 13 Sep 2018 19:53:58 - 1.56 +++ sys/netinet6/udp6_output.c 9 Nov 2018 16:31:21 - @@ -235,6 +235,8 @@ udp6_output(struct inpcb *in6p, struct m error = ip6_output(m, optp, >inp_route6, flags, in6p->inp_moptions6, in6p); + if (error == EACCES)/* translate pf(4) error for userland */ + error = EHOSTUNREACH; goto releaseopt; release: Index: /usr/src/lib/libc/sys/send.2 =
Re: diff: Fix send(2) EACCES mistake
On Sun, Oct 28, 2018 at 10:58:34PM +, Jason McIntyre wrote: > On Sun, Oct 28, 2018 at 09:40:33PM +0100, Jan Klemkow wrote: > > Unlike the manpage saids or one might think , sendto(2) sets errno to > > EHOSTUNREACH instead of EACCES in cases of blocking by pf(4) or not > > enabled broadcasts. Finally I ran into both cases and think, its time > > to fix this issue. The diff suggests a new explanation that should > > cover all error cases. > > > > Index: /usr/src/lib/libc/sys/send.2 > > === > > RCS file: /cvs/src/lib/libc/sys/send.2,v > > retrieving revision 1.32 > > diff -u -p -r1.32 send.2 > > --- /usr/src/lib/libc/sys/send.25 Oct 2017 12:30:16 - 1.32 > > +++ /usr/src/lib/libc/sys/send.228 Oct 2018 20:16:20 - > > @@ -161,13 +161,13 @@ The operation may succeed when buffers b > > The output queue for a network interface was full. > > This generally indicates that the interface has stopped sending, > > but may be caused by transient congestion. > > -.It Bq Er EACCES > > -The > > -.Dv SO_BROADCAST > > -option is not set on the socket, and a broadcast address > > -was given as the destination. > > .It Bq Er EHOSTUNREACH > > -The destination address specified an unreachable host. > > +The destination address specified an host that is unreachable, > > unless you're going for humour, "a host" rather than "an host". > > i can;t comment on the accuracy, but the rest of the diff reads ok. No humour (here in Germany), just a spelling mistakes :-) Fixed version below. Thanks, Jan Index: /usr/src/lib/libc/sys/send.2 === RCS file: /cvs/src/lib/libc/sys/send.2,v retrieving revision 1.32 diff -u -p -r1.32 send.2 --- /usr/src/lib/libc/sys/send.25 Oct 2017 12:30:16 - 1.32 +++ /usr/src/lib/libc/sys/send.229 Oct 2018 22:48:24 - @@ -161,13 +161,13 @@ The operation may succeed when buffers b The output queue for a network interface was full. This generally indicates that the interface has stopped sending, but may be caused by transient congestion. -.It Bq Er EACCES -The -.Dv SO_BROADCAST -option is not set on the socket, and a broadcast address -was given as the destination. .It Bq Er EHOSTUNREACH -The destination address specified an unreachable host. +The destination address specified a host that is unreachable, +blocked by +.Xr pf 4 +or is broadcast communication which was not enabled +via the socket option +.Dv SO_BROADCAST . .It Bq Er EINVAL The .Fa flags
diff: Fix send(2) EACCES mistake
Hi, Unlike the manpage saids or one might think , sendto(2) sets errno to EHOSTUNREACH instead of EACCES in cases of blocking by pf(4) or not enabled broadcasts. Finally I ran into both cases and think, its time to fix this issue. The diff suggests a new explanation that should cover all error cases. Bye, Jan Index: /usr/src/lib/libc/sys/send.2 === RCS file: /cvs/src/lib/libc/sys/send.2,v retrieving revision 1.32 diff -u -p -r1.32 send.2 --- /usr/src/lib/libc/sys/send.25 Oct 2017 12:30:16 - 1.32 +++ /usr/src/lib/libc/sys/send.228 Oct 2018 20:16:20 - @@ -161,13 +161,13 @@ The operation may succeed when buffers b The output queue for a network interface was full. This generally indicates that the interface has stopped sending, but may be caused by transient congestion. -.It Bq Er EACCES -The -.Dv SO_BROADCAST -option is not set on the socket, and a broadcast address -was given as the destination. .It Bq Er EHOSTUNREACH -The destination address specified an unreachable host. +The destination address specified an host that is unreachable, +blocked by +.Xr pf 4 +or is broadcast communication which was not enabled +via the socket option +.Dv SO_BROADCAST . .It Bq Er EINVAL The .Fa flags
Re: inteldrm(4): uvm write-combining support
On Sat, Oct 27, 2018 at 12:31:48PM +0200, Mark Kettenis wrote:
> > Date: Sat, 27 Oct 2018 17:16:57 +1100
> > From: Jonathan Gray
> >
> > On Fri, Oct 26, 2018 at 09:47:51PM +0200, Mark Kettenis wrote:
> > > Diff below adds support to uvm to create wtite-combining mappings and
> > > uses this to implement support for the I915_MMAP_WC flag in
> > > inteldrm(4). With this diff I can re-enable support for the
> > > I915_PARAM_MMAP_VERSION.
> > >
> > > Please test.
> >
> > Defining PMAP_WC like that in uvm headers will make
> > pgprot_writecombine() in dev/pci/drm/drm_linux.h take the wrong path
> > on archs without PMAP_WC.
> >
> > static inline pgprot_t
> > pgprot_writecombine(pgprot_t prot)
> > {
> > #ifdef PMAP_WC
> > return prot | PMAP_WC;
> > #else
> > return prot | PMAP_NOCACHE;
> > #endif
> > }
> >
> > Should it instead be #if defined(PMAP_WC) && PMAP_WC > 0
> > or just #if PMAP_WC > 0 here?
>
> Good catch. Maybe at some point we should revisit the naming of these
> flags and make them more uniform across architectures. Write-combing
> is a bit of an x86-specific thing, but other architectures have
> similar concepts.
>
> I went with #if PMAP_WC != 0 and did the same for PMAP_DEVICE.
Works for me, so far. But, I don't know how to test, or if its relevant
for my hardware?! Are there aeny edge cases I can test?
Bye,
Jan
OpenBSD 6.4-current (GENERIC.MP) #25: Sun Oct 28 15:41:05 CET 2018
you...@fabien.klemkow.net:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8451149824 (8059MB)
avail mem = 8185753600 (7806MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xca63b000 (63 entries)
bios0: vendor LENOVO version "N23ET55W (1.30 )" date 08/31/2018
bios0: LENOVO 20KHS08H00
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT
SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 POAT DMAR NHLT
ASF! FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4)
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1397.33 MHz, 06-8e-09
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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1148.48 MHz, 06-8e-09
cpu1:
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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1097.44 MHz, 06-8e-09
cpu2:
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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1097.44 MHz, 06-8e-09
cpu3:
Re: Add acpipci(4) on amd64
Hi Mark, On Tue, Oct 23, 2018 at 07:32:16PM +0200, Mark Kettenis wrote: > > Date: Tue, 23 Oct 2018 18:40:42 +0200 > > From: Jan Klemkow > > On Mon, Oct 22, 2018 at 09:45:06PM +0200, Mark Kettenis wrote: > > > Diff below adds an acpipci(4) driver on amd64. For now the main > > > purpose of this driver is to make the PCI-specific _OSC calls to > > > advertise the functionality we support. Most notably this advertises > > > support for PCIE native hotplug as we have some indications that this > > > will help Thunderbolt 3 support on some machines. > > > > > > I'd like to see this tested on a wide range of amd64 hardware, but > > > especially on laptops. Please reply with a diff of your dmesg before > > > and after. Make sure you run make config before building a new kernel. > > > > Tested with ThinkPad X1 Carbon 6th Gen under OpenBSD/amd64-current. It > > is tested with Thunderbold 3 enabled in BIOS. > > Bingo! > > Just to be sure, both dmesg's were made with the same BIOS > configuration and no devices connected to Thunderbolt 3 at boot? Yes, same BIOS option and no devices attached for both dmesgs . But, I have changed the BIOS option them. When "Thunderbolt 3" is enabled and the machine resumes from suspend (S3), than the acpi0 kernel thread takes 80-90% CPU usage till reboot. Tomorrow, I will see if could get a thunderbolt device for testing. FYI, with "Thunderbolt 3" disabled the dmesg looks like the ThinkPad X1 Carbon 5th Gen. dmesgs from the other testers. See below for a full dmesg listing with your diff and "Thunderbolt 3" enabled. Thanks, Jan --- dmesg.boot_before_hack Tue Oct 23 15:24:35 2018 +++ dmesg.boot_after_hack Tue Oct 23 15:24:58 2018 @@ -1,4 +1,4 @@ -OpenBSD 6.4-current (GENERIC.MP) #22: Tue Oct 23 15:04:51 CEST 2018 +OpenBSD 6.4-current (GENERIC.MP) #23: Tue Oct 23 15:16:49 CEST 2018 you...@fabien.klemkow.net:/sys/arch/amd64/compile/GENERIC.MP real mem = 8451149824 (8059MB) avail mem = 8185741312 (7806MB) @@ -24,7 +24,7 @@ cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) -cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1155.00 MHz, 06-8e-09 +cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1156.38 MHz, 06-8e-09 cpu1: 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 @@ -73,6 +73,7 @@ acpicpu3 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHC_ acpitz0 at acpi0: critical temperature is 128 degC +acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpithinkpad0 at acpi0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model "01AV430" serial 585 type LiP oem "SMP" Full dmegs listing: OpenBSD 6.4-current (GENERIC.MP) #23: Tue Oct 23 15:16:49 CEST 2018 you...@fabien.klemkow.net:/sys/arch/amd64/compile/GENERIC.MP real mem = 8451149824 (8059MB) avail mem = 8185741312 (7806MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xca63b000 (63 entries) bios0: vendor LENOVO version "N23ET55W (1.30 )" date 08/31/2018 bios0: LENOVO 20KHS08H00 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 POAT DMAR NHLT ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1397.33 MHz, 06-8e-09 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XS
Re: Add acpipci(4) on amd64
Hi Mark, On Mon, Oct 22, 2018 at 09:45:06PM +0200, Mark Kettenis wrote: > Diff below adds an acpipci(4) driver on amd64. For now the main > purpose of this driver is to make the PCI-specific _OSC calls to > advertise the functionality we support. Most notably this advertises > support for PCIE native hotplug as we have some indications that this > will help Thunderbolt 3 support on some machines. > > I'd like to see this tested on a wide range of amd64 hardware, but > especially on laptops. Please reply with a diff of your dmesg before > and after. Make sure you run make config before building a new kernel. Tested with ThinkPad X1 Carbon 6th Gen under OpenBSD/amd64-current. It is tested with Thunderbold 3 enabled in BIOS. Bye, Jan --- dmesg.boot_before_nohackTue Oct 23 18:00:39 2018 +++ dmesg.boot_after_nohack Tue Oct 23 16:43:35 2018 @@ -1,7 +1,7 @@ -OpenBSD 6.4-current (GENERIC.MP) #22: Tue Oct 23 15:04:51 CEST 2018 +OpenBSD 6.4-current (GENERIC.MP) #23: Tue Oct 23 15:16:49 CEST 2018 you...@fabien.klemkow.net:/sys/arch/amd64/compile/GENERIC.MP real mem = 8451149824 (8059MB) -avail mem = 8185745408 (7806MB) +avail mem = 8185741312 (7806MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root @@ -16,7 +16,7 @@ acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) -cpu0: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1394.63 MHz, 06-8e-09 +cpu0: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1397.33 MHz, 06-8e-09 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 @@ -24,7 +24,7 @@ cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) -cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1158.97 MHz, 06-8e-09 +cpu1: Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz, 1144.60 MHz, 06-8e-09 cpu1: 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 @@ -74,6 +74,7 @@ acpipwrres0 at acpi0: PUBS, resource for XHC_ acpipwrres1 at acpi0: PXP_, resource for RP09 acpitz0 at acpi0: critical temperature is 128 degC +acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpithinkpad0 at acpi0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model "01AV430" serial 585 type LiP oem "SMP" @@ -91,7 +92,7 @@ "USBC000" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout at acpivideo0 not configured -cpu0: Enhanced SpeedStep 1394 MHz: speeds: 2601, 2600, 2500, 2400, 2200, 2000, 1900, 1700, 1500, 1400, 1200, 1100, 800, 700, 600, 400 MHz +cpu0: Enhanced SpeedStep 1397 MHz: speeds: 2601, 2600, 2500, 2400, 2200, 2000, 1900, 1700, 1500, 1400, 1200, 1100, 800, 700, 600, 400 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 7G Host" rev 0x02 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 620" rev 0x02 @@ -122,6 +123,20 @@ sd0: 244198MB, 512 bytes/sector, 500118192 sectors ppb2 at pci0 dev 29 function 0 "Intel 100 Series PCIE" rev 0xf1: msi pci3 at ppb2 bus 5 +ppb3 at pci3 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02 +pci4 at ppb3 bus 6 +ppb4 at pci4 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi +pci5 at ppb4 bus 7 +"Intel JHL6540 Thunderbolt" rev 0x02 at pci5 dev 0 function 0 not configured +ppb5 at pci4 dev 1 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi +pci6 at ppb5 bus 8 +ppb6 at pci4 dev 2 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi +pci7 at ppb6 bus 59 +xhci1 at pci7 dev 0 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi, xHCI 1.16 +usb1 at xhci1: USB revision 3.0 +uhub1 at usb1 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 +ppb7 at pci4 dev 4 function 0 "Intel JHL6540 Thunderbolt" rev 0x02: msi +pci8 at ppb7 bus 60 pcib0 at pci0 dev 31 function 0 "Intel 200 Series LPC" rev 0x21 "Intel 100 Series PMC" rev 0x21 at pci0 dev 31 function 2 not configured azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev
diff: ndp(8): hostname lookup via /etc/ethers
Hi,
The following diff adds the option -e to ndp(8), which resolved printed
hostnames via /etc/ethers. You are able to recognise hosts with IPv6
auto privacy extension addresses on local IPv6 routers. Also hosts
inside of a yp(8) domain are able to lookup their neighbors via the
shared /etc/ethers database. (Yes, I run a yp domain :-)
This helps me, to keep track of known and unknown IPv6 hosts in my
network.
The ndp(8) implementations of FreeBSD, NetBSD and Linux don't have an
option named -e or a feature like this. Thus, there shouldn't be any
problem or misbehavior by existing scripts around ndp(8) with this new
option.
What's your opinion about this feature?
Bye,
Jan
Index: ndp.8
===
RCS file: /cvs/src/usr.sbin/ndp/ndp.8,v
retrieving revision 1.45
diff -u -p -r1.45 ndp.8
--- ndp.8 9 Aug 2017 14:36:00 - 1.45
+++ ndp.8 22 Oct 2018 21:32:46 -
@@ -36,7 +36,7 @@
.Nd control/diagnose IPv6 Neighbor Discovery Protocol (NDP)
.Sh SYNOPSIS
.Nm ndp
-.Op Fl acnt
+.Op Fl acent
.Op Fl A Ar wait
.Op Fl d Ar hostname
.Op Fl f Ar filename
@@ -112,6 +112,12 @@ the node has sent during the current sta
Erase all the NDP entries.
.It Fl d Ar hostname
Delete the specified NDP entry.
+.It Fl e
+Use the mappings of ethernet addresses in
+.Pa /etc/ethers
+to resolve hostnames.
+This is useful to resolve hostnames of privacy externsion addresses on local
+routers.
.It Fl f Ar filename
Parse entries from
.Ar file
Index: ndp.c
===
RCS file: /cvs/src/usr.sbin/ndp/ndp.c,v
retrieving revision 1.90
diff -u -p -r1.90 ndp.c
--- ndp.c 13 Jul 2018 09:03:44 - 1.90
+++ ndp.c 22 Oct 2018 21:38:54 -
@@ -86,6 +86,7 @@
#include
#include
+#include
#include
#include
@@ -110,6 +111,7 @@
((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long))
static pid_t pid;
+static int eflag;
static int nflag;
static int tflag;
static int32_t thiszone; /* time difference with gmt */
@@ -148,7 +150,7 @@ main(int argc, char *argv[])
pid = getpid();
thiszone = gmt2local(0);
rdomain = getrtable();
- while ((ch = getopt(argc, argv, "acd:f:i:nstA:V:")) != -1) {
+ while ((ch = getopt(argc, argv, "acd:ef:i:nstA:V:")) != -1) {
switch (ch) {
case 'a':
case 'c':
@@ -173,6 +175,9 @@ main(int argc, char *argv[])
mode = ch;
arg = optarg;
break;
+ case 'e':
+ eflag = 1;
+ break;
case 'n':
nflag = 1;
break;
@@ -612,6 +617,17 @@ again:;
delete(host_buf);
continue;
}
+
+ if (eflag && sdl->sdl_alen) {
+ u_char *cp = (u_char *)LLADDR(sdl);
+ struct ether_addr eaddr;
+ char nhost[NI_MAXHOST];
+
+ memcpy(eaddr.ether_addr_octet, cp, ETHER_ADDR_LEN);
+ if (ether_ntohost(nhost, ) == 0)
+ strlcpy(host_buf, nhost, sizeof(host_buf));
+ }
+
gettimeofday(, 0);
if (tflag)
ts_print();
@@ -753,7 +769,7 @@ ndp_ether_aton(char *a, u_char *n)
void
usage(void)
{
- printf("usage: ndp [-acnt] ");
+ printf("usage: ndp [-acent] ");
printf("[-A wait] [-d hostname] [-f filename] [-i interface]\n");
printf("\t[-s nodename ether_addr [temp] [proxy]] ");
printf("[-V rdomain] [hostname]\n");
fix: unveil(2) error handling
Hi, I found a little bug in the unveil(2) error handling. After blocking unveil(2) by unveil(NULL, NULL), an additional unveil(2) call sets errno to EINVAL instead of EPERM as the manpage saids: EPERM An attempt to increase permissions was made, or the path was not accessible, or unveil was called after locking. bye, Jan Index: kern/vfs_syscalls.c === RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.304 diff -u -p -r1.304 vfs_syscalls.c --- kern/vfs_syscalls.c 20 Aug 2018 16:00:22 - 1.304 +++ kern/vfs_syscalls.c 30 Aug 2018 20:04:48 - @@ -899,7 +899,7 @@ sys_unveil(struct proc *p, void *v, regi } if (p->p_p->ps_uvdone != 0) - return EINVAL; + return EPERM; error = copyinstr(SCARG(uap, permissions), permissions, sizeof(permissions), NULL);
diff: add USB ANT-m Stick via uscom(4)
Hi, the following diff adds support for an USB ANT+ receiver which is used to communicate with wireless fitness tracking devices. The USB device appears as a serial interface. I just add the device ID to the existing uscom(4) driver and enabled it in GENERIC. I don't know why it was deactivated. But, I tested the uscom(4) driver with my ANT device with OpenBSD-current on amd64, i386, macppc and sparc64. The device attache with this message: uscom0 at uhub0 port 1 configuration 1 interface 0 "Dynastream Innovations ANT USB-m Stick" rev 2.00/1.00 addr 2 ucom0 at uscom0 portno 0 It works well on every tested architecture. I got a valid binary error message from the ANT device by the following test command: # cu -l /dev/cuaU0 | od -h ... a4 01 ae 00 0b ... Did I test enough to enable this driver by default in GENERIC? Or did I miss something else? bye, Jan Index: share/man/man4/uscom.4 === RCS file: /cvs/src/share/man/man4/uscom.4,v retrieving revision 1.2 diff -u -p -r1.2 uscom.4 --- share/man/man4/uscom.4 25 Mar 2014 07:10:34 - 1.2 +++ share/man/man4/uscom.4 9 Aug 2018 18:24:50 - @@ -34,6 +34,7 @@ driver: .Bd -literal -offset indent HP 39G HP 49G +Dynastream ANT USB-m Stick .Ed .Sh SEE ALSO .Xr tty 4 , Index: sys/arch/amd64/conf/GENERIC === RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.457 diff -u -p -r1.457 GENERIC --- sys/arch/amd64/conf/GENERIC 3 Aug 2018 01:50:14 - 1.457 +++ sys/arch/amd64/conf/GENERIC 9 Aug 2018 18:22:33 - @@ -230,6 +230,8 @@ umct* at uhub?# MCT USB-RS232 serial a ucom* at umct? uslcom*at uhub?# Silicon Laboratories CP210x serial ucom* at uslcom? +uscom* at uhub?# Simple USB serial adapters +ucom* at uscom? uark* at uhub?# Arkmicro ARK3116 serial ucom* at uark? moscom*at uhub?# MosChip MCS7703 serial Index: sys/arch/i386/conf/GENERIC === RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v retrieving revision 1.833 diff -u -p -r1.833 GENERIC --- sys/arch/i386/conf/GENERIC 3 Aug 2018 01:50:14 - 1.833 +++ sys/arch/i386/conf/GENERIC 9 Aug 2018 18:22:33 - @@ -246,6 +246,8 @@ umct* at uhub?# MCT USB-RS232 serial a ucom* at umct? uslcom*at uhub?# Silicon Laboratories CP210x serial ucom* at uslcom? +uscom* at uhub?# Simple USB serial adapters +ucom* at uscom? uark* at uhub?# Arkmicro ARK3116 serial ucom* at uark? moscom*at uhub?# MosChip MCS7703 serial Index: sys/arch/macppc/conf/GENERIC === RCS file: /cvs/src/sys/arch/macppc/conf/GENERIC,v retrieving revision 1.264 diff -u -p -r1.264 GENERIC --- sys/arch/macppc/conf/GENERIC14 Feb 2018 23:51:49 - 1.264 +++ sys/arch/macppc/conf/GENERIC9 Aug 2018 18:22:33 - @@ -223,6 +223,8 @@ umct* at uhub?# MCT USB-RS232 serial a ucom* at umct? uslcom*at uhub?# Silicon Laboratories CP210x serial ucom* at uslcom? +uscom* at uhub?# Simple USB serial adapters +ucom* at uscom? uark* at uhub?# Arkmicro ARK3116 serial ucom* at uark? moscom*at uhub?# MosChip MCS7703 serial Index: sys/arch/sparc64/conf/GENERIC === RCS file: /cvs/src/sys/arch/sparc64/conf/GENERIC,v retrieving revision 1.307 diff -u -p -r1.307 GENERIC --- sys/arch/sparc64/conf/GENERIC 28 Aug 2017 19:32:53 - 1.307 +++ sys/arch/sparc64/conf/GENERIC 9 Aug 2018 18:22:33 - @@ -193,6 +193,8 @@ umct* at uhub?# MCT USB-RS232 serial a ucom* at umct? uslcom*at uhub?# Silicon Laboratories CP210x serial ucom* at uslcom? +uscom* at uhub?# Simple USB serial adapters +ucom* at uscom? uark* at uhub?# Arkmicro ARK3116 serial ucom* at uark? uipaq* at uhub?# iPAQ serial adapter Index: sys/dev/usb/usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.690 diff -u -p -r1.690 usbdevs --- sys/dev/usb/usbdevs 19 Jul 2018 17:33:26 - 1.690 +++ sys/dev/usb/usbdevs 9 Aug 2018 18:22:33 - @@ -1638,6 +1638,7 @@ product DVICO RT3070 0xb307 RT3070 product DYNASTREAM ANTDEVBOARD 0x1003 ANT dev board product DYNASTREAM ANT2USB 0x1004 ANT2USB product DYNASTREAM ANTDEVBOARD20x1006 ANT dev board +product DYNASTREAM ANTUSBM 0x1009 ANTUSB-m Stick /* EasyDisk products */ product EASYDISK EASYDISK 0x0005
Re: diff: add if group table to snmpd
On Mon, May 14, 2018 at 09:21:13PM +0200, Jan Klemkow wrote:
> On Mon, May 14, 2018 at 06:53:20PM +0100, Stuart Henderson wrote:
> > On 2018/05/14 17:59, Jan Klemkow wrote:
> > > The following diff adds an interface group table to the OpenBSD MIBs and
> > > the OpenSNMPd. The new snmp table helps to keep track of the demote
> > > values of more complex carp setups. To iterate directly through all
> > > interface groups, the diff has to extent ioctl interface by a new
> > > command SIOCGIFGLIST.
> > >
> > > This new interface could also be used to extent ifconfig(8), in a later
> > > diff, to list all interface groups with there demote counter.
> > >
> > > I tested this diff with snmpctl(8) from base and snmpwalk from
> > > net/net-snmp under current amd64.
>
> > This seems a reasonable thing to report on and I didn't spot any code
> > problems yet, one thing with the MIB file though:
>
> > > Index: share/snmp/OPENBSD-CARP-MIB.txt
> > > ===
> > > RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
> > > retrieving revision 1.3
> > > diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
> > > --- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 -
> > > 1.3
> > > +++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 14:53:02 -
> > > @@ -41,7 +41,7 @@ carpMIBObjects MODULE-IDENTITY
> > > "
> > > DESCRIPTION "The MIB module for gathering information about
> > >Common Address Redundancy Protocol (CARP) interfaces."
> > > -REVISION "20120131Z"
> > > +REVISION "20180514Z"
> > > DESCRIPTION "Add the OPENBSD-CARP-MIB to snmpd."
> > > ::= { openBSD 6 }
> >
> > This section is meant to be a sort of changelog; please add a new
> > REVISION/DESCRIPTION rather than changing the existing one. (Also check
> > that smilint is happy).
>
> Thanks for the hint. I fixed the changelog and some other issues
> pointed by smilint.
This is the merged version of the diff:
Thanks,
Jan
Index: share/snmp/OPENBSD-CARP-MIB.txt
===
RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
retrieving revision 1.3
diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
--- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 - 1.3
+++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 18:58:59 -
@@ -32,7 +32,7 @@ IMPORTS
FROM SNMPv2-CONF;
carpMIBObjects MODULE-IDENTITY
-LAST-UPDATED "20120131Z"
+LAST-UPDATED "20180514Z"
ORGANIZATION "OpenBSD"
CONTACT-INFO "
Author: Joel Knight
@@ -41,6 +41,8 @@ carpMIBObjects MODULE-IDENTITY
"
DESCRIPTION "The MIB module for gathering information about
Common Address Redundancy Protocol (CARP) interfaces."
+REVISION "20180514Z"
+DESCRIPTION "Add the carpGroupTable to OPENBSD-CARP-MIB."
REVISION "20120131Z"
DESCRIPTION "Add the OPENBSD-CARP-MIB to snmpd."
::= { openBSD 6 }
@@ -174,6 +176,58 @@ carpIfState OBJECT-TYPE
DESCRIPTION
"Indicates the operational state of the CARP interface."
::= { carpIfEntry 7 }
+
+
+-- carpGroup
+
+carpGroupTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF CarpGroupEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A list of interface groups."
+ ::= { carpMIBObjects 4 }
+
+carpGroupEntry OBJECT-TYPE
+ SYNTAX CarpGroupEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry containing management information applicable to a
+ particular interface group."
+ INDEX { carpGroupIndex }
+ ::= { carpGroupTable 1 }
+
+CarpGroupEntry ::=
+ SEQUENCE {
+ carpGroupIndex Integer32,
+ carpGroupName OCTET STRING,
+ carpGroupDemote Integer32
+ }
+
+carpGroupIndex OBJECT-TYPE
+ SYNTAX Integer32 (1..2147483647)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The demote value of the interface group."
+ ::= { carpGroupEntry 1 }
+
+carpGroupName OBJECT-TYPE
+ SYNTAX OCTET STRING
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The name of the interface group."
+ ::= { carpGroupEntry 2 }
+
+c
Re: [patch] httpd: add tls client certificate authentication
Hi Jack,
On Wed, May 16, 2018 at 05:32:56PM +0930, Jack Burton wrote:
> I figured that if we can agree on this much, so httpd can be used for
> the authentication-only case (which is all non-fastcgi sites would want)
> straight away, that's be a good first step -- then we can come back and
> argue the toss over how much client cert data is necessary/sufficient
> to pass through for authorisation/accounting purposes.
I agree with you. Lets commit this first step.
I tested your diff on current amd64 and sparc64 with an own PKI [1] and
the firefox browser. Every thing works for me. I also looked down your
source code which also seams fine to me.
I tested the optional and non-optional "client ca" configuration, as
well as the revocation and the fastcgi environment feature on both
architectures. Everything works so far.
Hopefully, it will committed this time! :-)
Thanks!
Jan
[1]: https://github.com/younix/ca
> There's also a trivial regression test (unchanged from last year), which
> I'll post again separately next.
>
>
> Index: config.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/config.c,v
> retrieving revision 1.53
> diff -u -p -r1.53 config.c
> --- config.c 19 Jul 2017 17:36:25 - 1.53
> +++ config.c 16 May 2018 07:59:10 -
> @@ -304,10 +304,18 @@ config_setserver_tls(struct httpd *env,
>
> log_debug("%s: configuring tls for %s", __func__, srv_conf->name);
>
> + if (config_settls(env, srv, TLS_CFG_CA, "ca", srv_conf->tls_ca,
> + srv_conf->tls_ca_len) != 0)
> + return (-1);
> +
> if (config_settls(env, srv, TLS_CFG_CERT, "cert", srv_conf->tls_cert,
> srv_conf->tls_cert_len) != 0)
> return (-1);
>
> + if (config_settls(env, srv, TLS_CFG_CRL, "crl", srv_conf->tls_crl,
> + srv_conf->tls_crl_len) != 0)
> + return (-1);
> +
> if (config_settls(env, srv, TLS_CFG_KEY, "key", srv_conf->tls_key,
> srv_conf->tls_key_len) != 0)
> return (-1);
> @@ -431,6 +439,7 @@ config_getserver_config(struct httpd *en
>
> f = SRVFLAG_TLS;
> srv_conf->flags |= parent->flags & f;
> + srv_conf->tls_flags = parent->tls_flags;
>
> f = SRVFLAG_ACCESS_LOG;
> if ((srv_conf->flags & f) == 0) {
> @@ -655,9 +664,21 @@ config_getserver_tls(struct httpd *env,
> }
>
> switch (tls_conf.tls_type) {
> + case TLS_CFG_CA:
> + if (config_gettls(env, srv_conf, _conf, "ca", p, len,
> + _conf->tls_ca, _conf->tls_ca_len) != 0)
> + goto fail;
> + break;
> +
> case TLS_CFG_CERT:
> if (config_gettls(env, srv_conf, _conf, "cert", p, len,
> _conf->tls_cert, _conf->tls_cert_len) != 0)
> + goto fail;
> + break;
> +
> + case TLS_CFG_CRL:
> + if (config_gettls(env, srv_conf, _conf, "crl", p, len,
> + _conf->tls_crl, _conf->tls_crl_len) != 0)
> goto fail;
> break;
>
> Index: httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.90
> diff -u -p -r1.90 httpd.conf.5
> --- httpd.conf.5 11 Apr 2018 15:50:46 - 1.90
> +++ httpd.conf.5 16 May 2018 07:59:10 -
> @@ -342,6 +342,10 @@ The revision of the HTTP specification u
> .It Ic SERVER_SOFTWARE
> The server software name of
> .Xr httpd 8 .
> +.It Ic TLS_PEER_VERIFY
> +A variable that is set to a comma separated list of TLS client verification
> +features in use
> +.Pq omitted when TLS client verification is not in use .
> .El
> .It Ic hsts Oo Ar option Oc
> Enable HTTP Strict Transport Security.
> @@ -526,6 +530,23 @@ will be used (strong crypto cipher suite
> See the CIPHERS section of
> .Xr openssl 1
> for information about SSL/TLS cipher suites and preference lists.
> +.It Ic client ca Ar cafile Oo Ic crl Ar crlfile Oc Op Ic optional
> +Require
> +.Po
> +or, if
> +.Ic optional
> +is specified, request but do not require
> +.Pc
> +TLS client certificates whose authenticity can be verified
> +against the CA certificate(s) in
> +.Ar cafile
> +in order to proceed beyond the TLS handshake.
> +With
> +.Ic crl
> +specified, additionally require that no certificate in the client chain be
> +listed as revoked in the CRL(s) in
> +.Ar crlfile .
> +CA certificates and CRLs should be PEM encoded.
> .It Ic dhe Ar params
> Specify the DHE parameters to use for DHE cipher suites.
> Valid parameter values are none, legacy and auto.
> Index: httpd.h
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
> retrieving revision 1.136
> diff -u -p -r1.136 httpd.h
> --- httpd.h 11 Apr 2018 15:50:46 - 1.136
> +++ httpd.h 16 May 2018 07:59:10
Re: diff: add if group table to snmpd
Hi Stuart,
On Mon, May 14, 2018 at 06:53:20PM +0100, Stuart Henderson wrote:
> On 2018/05/14 17:59, Jan Klemkow wrote:
> > The following diff adds an interface group table to the OpenBSD MIBs and
> > the OpenSNMPd. The new snmp table helps to keep track of the demote
> > values of more complex carp setups. To iterate directly through all
> > interface groups, the diff has to extent ioctl interface by a new
> > command SIOCGIFGLIST.
> >
> > This new interface could also be used to extent ifconfig(8), in a later
> > diff, to list all interface groups with there demote counter.
> >
> > I tested this diff with snmpctl(8) from base and snmpwalk from
> > net/net-snmp under current amd64.
> This seems a reasonable thing to report on and I didn't spot any code
> problems yet, one thing with the MIB file though:
> > Index: share/snmp/OPENBSD-CARP-MIB.txt
> > ===
> > RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
> > --- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 - 1.3
> > +++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 14:53:02 -
> > @@ -41,7 +41,7 @@ carpMIBObjects MODULE-IDENTITY
> > "
> > DESCRIPTION "The MIB module for gathering information about
> > Common Address Redundancy Protocol (CARP) interfaces."
> > -REVISION "20120131Z"
> > +REVISION "20180514Z"
> > DESCRIPTION "Add the OPENBSD-CARP-MIB to snmpd."
> > ::= { openBSD 6 }
>
> This section is meant to be a sort of changelog; please add a new
> REVISION/DESCRIPTION rather than changing the existing one. (Also check
> that smilint is happy).
Thanks for the hint. I fixed the changelog and some other issues
pointed by smilint.
Thanks,
Jan
Index: share/snmp/OPENBSD-CARP-MIB.txt
===
RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
retrieving revision 1.3
diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
--- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 - 1.3
+++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 18:58:59 -
@@ -32,7 +32,7 @@ IMPORTS
FROM SNMPv2-CONF;
carpMIBObjects MODULE-IDENTITY
-LAST-UPDATED "20120131Z"
+LAST-UPDATED "20180514Z"
ORGANIZATION "OpenBSD"
CONTACT-INFO "
Author: Joel Knight
@@ -41,6 +41,8 @@ carpMIBObjects MODULE-IDENTITY
"
DESCRIPTION "The MIB module for gathering information about
Common Address Redundancy Protocol (CARP) interfaces."
+REVISION "20180514Z"
+DESCRIPTION "Add the carpGroupTable to OPENBSD-CARP-MIB."
REVISION "20120131Z"
DESCRIPTION "Add the OPENBSD-CARP-MIB to snmpd."
::= { openBSD 6 }
@@ -174,6 +176,58 @@ carpIfState OBJECT-TYPE
DESCRIPTION
"Indicates the operational state of the CARP interface."
::= { carpIfEntry 7 }
+
+
+-- carpGroup
+
+carpGroupTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF CarpGroupEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A list of interface groups."
+ ::= { carpMIBObjects 4 }
+
+carpGroupEntry OBJECT-TYPE
+ SYNTAX CarpGroupEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry containing management information applicable to a
+ particular interface group."
+ INDEX { carpGroupIndex }
+ ::= { carpGroupTable 1 }
+
+CarpGroupEntry ::=
+ SEQUENCE {
+ carpGroupIndex Integer32,
+ carpGroupName OCTET STRING,
+ carpGroupDemote Integer32
+ }
+
+carpGroupIndex OBJECT-TYPE
+ SYNTAX Integer32 (1..2147483647)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The demote value of the interface group."
+ ::= { carpGroupEntry 1 }
+
+carpGroupName OBJECT-TYPE
+ SYNTAX OCTET STRING
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The name of the interface group."
+ ::= { carpGroupEntry 2 }
+
+carpGroupDemote OBJECT-TYPE
+ SYNTAX Integer32 (1..2147483647)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The demote value of the interface group."
+ ::= { carpGroupEntry 3 }
-- carpStats
Index: sys/net/if.c
=
diff: add if group table to snmpd
Hi,
The following diff adds an interface group table to the OpenBSD MIBs and
the OpenSNMPd. The new snmp table helps to keep track of the demote
values of more complex carp setups. To iterate directly through all
interface groups, the diff has to extent ioctl interface by a new
command SIOCGIFGLIST.
This new interface could also be used to extent ifconfig(8), in a later
diff, to list all interface groups with there demote counter.
I tested this diff with snmpctl(8) from base and snmpwalk from
net/net-snmp under current amd64.
Bye,
Jan
Index: share/snmp/OPENBSD-CARP-MIB.txt
===
RCS file: /cvs//src/share/snmp/OPENBSD-CARP-MIB.txt,v
retrieving revision 1.3
diff -u -p -r1.3 OPENBSD-CARP-MIB.txt
--- share/snmp/OPENBSD-CARP-MIB.txt 28 Sep 2012 09:21:48 - 1.3
+++ share/snmp/OPENBSD-CARP-MIB.txt 14 May 2018 14:53:02 -
@@ -32,7 +32,7 @@ IMPORTS
FROM SNMPv2-CONF;
carpMIBObjects MODULE-IDENTITY
-LAST-UPDATED "20120131Z"
+LAST-UPDATED "20180514Z"
ORGANIZATION "OpenBSD"
CONTACT-INFO "
Author: Joel Knight
@@ -41,7 +41,7 @@ carpMIBObjects MODULE-IDENTITY
"
DESCRIPTION "The MIB module for gathering information about
Common Address Redundancy Protocol (CARP) interfaces."
-REVISION "20120131Z"
+REVISION "20180514Z"
DESCRIPTION "Add the OPENBSD-CARP-MIB to snmpd."
::= { openBSD 6 }
@@ -51,6 +51,7 @@ carpMIBObjects MODULE-IDENTITY
carpSysctl OBJECT IDENTIFIER ::= { carpMIBObjects 1 }
carpIf OBJECT IDENTIFIER ::= { carpMIBObjects 2 }
carpStats OBJECT IDENTIFIER ::= { carpMIBObjects 3 }
+carpGroupTable OBJECT IDENTIFIER ::= { carpMIBObjects 4 }
-- carpSysctl
@@ -174,6 +175,49 @@ carpIfState OBJECT-TYPE
DESCRIPTION
"Indicates the operational state of the CARP interface."
::= { carpIfEntry 7 }
+
+
+-- carpGroup
+
+carpGroupTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF CarpGroupEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A list of interface groups."
+ ::= { carpMIBObjects 4 }
+
+carpGroupEntry OBJECT-TYPE
+ SYNTAX CarpGroupEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry containing management information applicable to a
+ particular interface group."
+ INDEX { carpGroupIndex }
+ ::= { carpGroupTable 1 }
+
+CarpGroupEntry ::=
+ SEQUENCE {
+ carpGroupName OCTET STRING,
+ carpGroupDemote Integer32
+ }
+
+carpGroupName OBJECT-TYPE
+ SYNTAX OCTET STRING
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The name of the interface group."
+ ::= { carpIfEntry 1 }
+
+carpGroupDemote OBJECT-TYPE
+ SYNTAX Integer32 (1..2147483647)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The demote value of the interface group."
+ ::= { carpIfEntry 2 }
-- carpStats
Index: sys/net/if.c
===
RCS file: /cvs//src/sys/net/if.c,v
retrieving revision 1.551
diff -u -p -r1.551 if.c
--- sys/net/if.c28 Apr 2018 15:44:59 - 1.551
+++ sys/net/if.c9 May 2018 08:16:33 -
@@ -145,6 +145,7 @@ int if_getgroup(caddr_t, struct ifnet *)
intif_getgroupmembers(caddr_t);
intif_getgroupattribs(caddr_t);
intif_setgroupattribs(caddr_t);
+intif_getgrouplist(caddr_t);
void if_linkstate(struct ifnet *);
void if_linkstate_task(void *);
@@ -1838,6 +1839,7 @@ ifioctl(struct socket *so, u_long cmd, c
case SIOCIFGCLONERS:
case SIOCGIFGMEMB:
case SIOCGIFGATTR:
+ case SIOCGIFGLIST:
case SIOCGIFFLAGS:
case SIOCGIFXFLAGS:
case SIOCGIFMETRIC:
@@ -2178,6 +2180,11 @@ ifioctl_get(u_long cmd, caddr_t data)
error = if_getgroupattribs(data);
NET_RUNLOCK();
return (error);
+ case SIOCGIFGLIST:
+ NET_RLOCK();
+ error = if_getgrouplist(data);
+ NET_RUNLOCK();
+ return (error);
}
ifp = ifunit(ifr->ifr_name);
@@ -2609,6 +2616,41 @@ if_setgroupattribs(caddr_t data)
TAILQ_FOREACH(ifgm, >ifg_members, ifgm_next)
ifgm->ifgm_ifp->if_ioctl(ifgm->ifgm_ifp, SIOCSIFGATTR, data);
+
+ return (0);
+}
+
+/*
+ * Stores all groups in memory pointed to by data
+ */
+int
+if_getgrouplist(caddr_t data)
+{
+ struct ifgroupreq *ifgr = (struct ifgroupreq *)data;
+ struct ifg_group*ifg;
+ struct ifg_req ifgrq, *ifgp;
+ int len,
Re: diff: cu(1): add secure kiosk mode + stricter pledge
On Sat, Dec 02, 2017 at 08:37:34PM +0100, Jan Klemkow wrote:
> On Sat, Dec 02, 2017 at 08:17:15PM +0100, Jan Klemkow wrote:
> > On Fri, Dec 01, 2017 at 04:17:42PM -0700, Theo de Raadt wrote:
> > > So two comments: Calling this thing by the right name (escape),
> > > would allow you to search other programs which have similar functions,
> > > see if someone did it before, and match the behaviour / option.
> >
> > Yes, the term "kiosk mode" is not that common in unix environments.
> > So, I changed it to "restricted mode" as it is used in ksh(1).
I forget to change the usage from "-k" to "-r".
Hopefully this is the final version:
Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c 5 Oct 2015 23:15:31 - 1.15
+++ command.c 2 Dec 2017 19:30:52 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+ if (restricted) {
+ cu_warnx("~C command is not allowed in restricted
mode");
+ break;
+ }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+ if (restricted) {
+ cu_warnx("~R command is not allowed in restricted
mode");
+ break;
+ }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+ if (restricted) {
+ cu_warnx("~X command is not allowed in restricted
mode");
+ break;
+ }
send_xmodem();
break;
case '$':
+ if (restricted) {
+ cu_warnx("~$ command is not allowed in restricted
mode");
+ break;
+ }
pipe_command();
break;
case '>':
+ if (restricted) {
+ cu_warnx("~> command is not allowed in restricted
mode");
+ break;
+ }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 - 1.15
+++ cu.12 Dec 2017 18:06:25 -
@@ -35,7 +35,7 @@
.Nd serial terminal emulator
.Sh SYNOPSIS
.Nm
-.Op Fl d
+.Op Fl dr
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
.Nm
@@ -55,6 +55,11 @@ The options are as follows:
Specify that the line is directly connected and
.Nm
should not allow the driver to block waiting for a carrier to be detected.
+.It Fl r
+Starts
+.Nm
+in restricted mode.
+This prevents all local filesystem operations and command executions.
.It Fl l Ar line
Specify the line to use.
Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
The command string sent to the local
.Ux
system is processed by the shell.
+This command is not allowed in restricted mode.
.It Ic ~#
Send a
.Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
1 \*(Lt-\*(Gt remote tty out
2 \*(Lt-\*(Gt local tty stderr
.Ed
+.Pp
+This command is not allowed in restricted mode.
.It Ic ~D
Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in restricted mode.
.It Ic ~R
Record all output from the remote system to a file.
If the given file already exists, it is appended to.
If no file is specified, any existing recording is stopped.
+This command is not allowed in restricted mode.
.It Ic ~S
Change the speed of the connection.
.It Ic ~X
Send a file with the XMODEM protocol.
+This command is not allowed in restricted mode.
.It Ic ~?
Get a summary of the tilde escapes.
.El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 - 1.25
+++ cu.c3 Dec 2017 10:15:30 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
int is_direct = -1;
+int restricted = 0;
const char *line_path = NULL;
int line_speed = -1;
int line_fd;
@@ -66,7 +67,7 @@ void try_remote(const char *, const cha
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-d] [-l line] [-s speed
Re: diff: cu(1): add secure kiosk mode + stricter pledge
On Sat, Dec 02, 2017 at 08:17:15PM +0100, Jan Klemkow wrote:
> On Fri, Dec 01, 2017 at 04:17:42PM -0700, Theo de Raadt wrote:
> > So two comments: Calling this thing by the right name (escape),
> > would allow you to search other programs which have similar functions,
> > see if someone did it before, and match the behaviour / option.
>
> Yes, the term "kiosk mode" is not that common in unix environments.
> So, I changed it to "restricted mode" as it is used in ksh(1).
Sorry for the noise. I forget to change the warning messages. I also
changed the variable r_flag to "restricted" as it is used in the source
of ksh(1), too.
This version should be fine:
Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c 5 Oct 2015 23:15:31 - 1.15
+++ command.c 2 Dec 2017 19:30:52 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+ if (restricted) {
+ cu_warnx("~C command is not allowed in restricted
mode");
+ break;
+ }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+ if (restricted) {
+ cu_warnx("~R command is not allowed in restricted
mode");
+ break;
+ }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+ if (restricted) {
+ cu_warnx("~X command is not allowed in restricted
mode");
+ break;
+ }
send_xmodem();
break;
case '$':
+ if (restricted) {
+ cu_warnx("~$ command is not allowed in restricted
mode");
+ break;
+ }
pipe_command();
break;
case '>':
+ if (restricted) {
+ cu_warnx("~> command is not allowed in restricted
mode");
+ break;
+ }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 - 1.15
+++ cu.12 Dec 2017 18:06:25 -
@@ -35,7 +35,7 @@
.Nd serial terminal emulator
.Sh SYNOPSIS
.Nm
-.Op Fl d
+.Op Fl dr
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
.Nm
@@ -55,6 +55,11 @@ The options are as follows:
Specify that the line is directly connected and
.Nm
should not allow the driver to block waiting for a carrier to be detected.
+.It Fl r
+Starts
+.Nm
+in restricted mode.
+This prevents all local filesystem operations and command executions.
.It Fl l Ar line
Specify the line to use.
Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
The command string sent to the local
.Ux
system is processed by the shell.
+This command is not allowed in restricted mode.
.It Ic ~#
Send a
.Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
1 \*(Lt-\*(Gt remote tty out
2 \*(Lt-\*(Gt local tty stderr
.Ed
+.Pp
+This command is not allowed in restricted mode.
.It Ic ~D
Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in restricted mode.
.It Ic ~R
Record all output from the remote system to a file.
If the given file already exists, it is appended to.
If no file is specified, any existing recording is stopped.
+This command is not allowed in restricted mode.
.It Ic ~S
Change the speed of the connection.
.It Ic ~X
Send a file with the XMODEM protocol.
+This command is not allowed in restricted mode.
.It Ic ~?
Get a summary of the tilde escapes.
.El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 - 1.25
+++ cu.c2 Dec 2017 19:28:52 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
int is_direct = -1;
+int restricted = 0;
const char *line_path = NULL;
int line_speed = -1;
int line_fd;
@@ -66,7 +67,7 @@ void try_remote(const char *, const cha
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-d] [-l line]
Re: diff: cu(1): add secure kiosk mode + stricter pledge
On Fri, Dec 01, 2017 at 04:17:42PM -0700, Theo de Raadt wrote:
> > The diff adds the option -k (for kiosk mode)
>
> Congratulations, you win some sort of prize. That is the worst-named
> option I have seen in more than a decade.
Thanks. :-)
> Good idea though, but I think we have better getopt interfaces for
> blocking escapes in other commands. ssh has to do this, and I suspect
> a few other commands do also.
>
> So two comments: Calling this thing by the right name (escape),
> would allow you to search other programs which have similar functions,
> see if someone did it before, and match the behaviour / option.
Yes, the term "kiosk mode" is not that common in unix environments.
So, I changed it to "restricted mode" as it is used in ksh(1).
Thanks,
Jan
Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c 5 Oct 2015 23:15:31 - 1.15
+++ command.c 2 Dec 2017 18:02:20 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+ if (r_flag) {
+ cu_warnx("~C command is not allowed in kiosk mode");
+ break;
+ }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+ if (r_flag) {
+ cu_warnx("~R command is not allowed in kiosk mode");
+ break;
+ }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+ if (r_flag) {
+ cu_warnx("~X command is not allowed in kiosk mode");
+ break;
+ }
send_xmodem();
break;
case '$':
+ if (r_flag) {
+ cu_warnx("~$ command is not allowed in kiosk mode");
+ break;
+ }
pipe_command();
break;
case '>':
+ if (r_flag) {
+ cu_warnx("~> command is not allowed in kiosk mode");
+ break;
+ }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 - 1.15
+++ cu.12 Dec 2017 18:06:25 -
@@ -35,7 +35,7 @@
.Nd serial terminal emulator
.Sh SYNOPSIS
.Nm
-.Op Fl d
+.Op Fl dr
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
.Nm
@@ -55,6 +55,11 @@ The options are as follows:
Specify that the line is directly connected and
.Nm
should not allow the driver to block waiting for a carrier to be detected.
+.It Fl r
+Starts
+.Nm
+in restricted mode.
+This prevents all local filesystem operations and command executions.
.It Fl l Ar line
Specify the line to use.
Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
The command string sent to the local
.Ux
system is processed by the shell.
+This command is not allowed in restricted mode.
.It Ic ~#
Send a
.Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
1 \*(Lt-\*(Gt remote tty out
2 \*(Lt-\*(Gt local tty stderr
.Ed
+.Pp
+This command is not allowed in restricted mode.
.It Ic ~D
Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in restricted mode.
.It Ic ~R
Record all output from the remote system to a file.
If the given file already exists, it is appended to.
If no file is specified, any existing recording is stopped.
+This command is not allowed in restricted mode.
.It Ic ~S
Change the speed of the connection.
.It Ic ~X
Send a file with the XMODEM protocol.
+This command is not allowed in restricted mode.
.It Ic ~?
Get a summary of the tilde escapes.
.El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 - 1.25
+++ cu.c2 Dec 2017 18:02:06 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
int is_direct = -1;
+int r_flag = 0;
const char *line_path = NULL;
int line_speed = -1;
int line_fd;
@@ -66,7 +67,7 @@ void try_remote(const char *, const cha
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-d] [-l line] [-s speed | -speed]\n",
+ fprintf(stderr, "usage: %s [-dk] [-l line] [-s speed
diff: cu(1): add secure kiosk mode + stricter pledge
Hi,
I run cu(1) as ssh forced command for other users on my machine.
This allows them to reach the serial port of their machines over mine.
To prevent them of doing filesystem operations or further command
executions I implement this diff.
The diff adds the option -k (for kiosk mode) to cu(1) and reduces the
pledge string from "stdio rpath wpath cpath getpw proc exec tty" to
"stdio tty". If a user still tries to type a forbidden command, he gets
a warning message.
I successfully tested all escape command with and without the -k option.
Bye,
Jan
Index: command.c
===
RCS file: /cvs/src/usr.bin/cu/command.c,v
retrieving revision 1.15
diff -u -p -r1.15 command.c
--- command.c 5 Oct 2015 23:15:31 - 1.15
+++ command.c 1 Dec 2017 22:10:17 -
@@ -233,6 +233,10 @@ do_command(char c)
set_termios();
break;
case 'C':
+ if (k_flag) {
+ cu_warnx("~C command is not allowed in kiosk mode");
+ break;
+ }
connect_command();
break;
case 'D':
@@ -241,18 +245,34 @@ do_command(char c)
ioctl(line_fd, TIOCSDTR, NULL);
break;
case 'R':
+ if (k_flag) {
+ cu_warnx("~R command is not allowed in kiosk mode");
+ break;
+ }
start_record();
break;
case 'S':
set_speed();
break;
case 'X':
+ if (k_flag) {
+ cu_warnx("~X command is not allowed in kiosk mode");
+ break;
+ }
send_xmodem();
break;
case '$':
+ if (k_flag) {
+ cu_warnx("~$ command is not allowed in kiosk mode");
+ break;
+ }
pipe_command();
break;
case '>':
+ if (k_flag) {
+ cu_warnx("~> command is not allowed in kiosk mode");
+ break;
+ }
send_file();
break;
case '#':
Index: cu.1
===
RCS file: /cvs/src/usr.bin/cu/cu.1,v
retrieving revision 1.15
diff -u -p -r1.15 cu.1
--- cu.118 May 2015 09:35:05 - 1.15
+++ cu.11 Dec 2017 22:36:32 -
@@ -35,7 +35,7 @@
.Nd serial terminal emulator
.Sh SYNOPSIS
.Nm
-.Op Fl d
+.Op Fl dk
.Op Fl l Ar line
.Op Fl s Ar speed | Fl Ar speed
.Nm
@@ -55,6 +55,11 @@ The options are as follows:
Specify that the line is directly connected and
.Nm
should not allow the driver to block waiting for a carrier to be detected.
+.It Fl k
+Starts
+.Nm
+in kiosk mode.
+This prevents all local filesystem operations and command executions.
.It Fl l Ar line
Specify the line to use.
Either of the forms like
@@ -114,6 +119,7 @@ process to the remote host.
The command string sent to the local
.Ux
system is processed by the shell.
+This command is not allowed in kiosk mode.
.It Ic ~#
Send a
.Dv BREAK
@@ -132,16 +138,21 @@ file descriptors:
1 \*(Lt-\*(Gt remote tty out
2 \*(Lt-\*(Gt local tty stderr
.Ed
+.Pp
+This command is not allowed in kiosk mode.
.It Ic ~D
Deassert the data terminal ready (DTR) line briefly.
+This command is not allowed in kiosk mode.
.It Ic ~R
Record all output from the remote system to a file.
If the given file already exists, it is appended to.
If no file is specified, any existing recording is stopped.
+This command is not allowed in kiosk mode.
.It Ic ~S
Change the speed of the connection.
.It Ic ~X
Send a file with the XMODEM protocol.
+This command is not allowed in kiosk mode.
.It Ic ~?
Get a summary of the tilde escapes.
.El
Index: cu.c
===
RCS file: /cvs/src/usr.bin/cu/cu.c,v
retrieving revision 1.25
diff -u -p -r1.25 cu.c
--- cu.c22 Aug 2017 16:32:37 - 1.25
+++ cu.c1 Dec 2017 23:02:23 -
@@ -42,6 +42,7 @@ struct termios saved_tio;
struct bufferevent *input_ev;
struct bufferevent *output_ev;
int is_direct = -1;
+int k_flag = 0;
const char *line_path = NULL;
int line_speed = -1;
int line_fd;
@@ -66,7 +67,7 @@ void try_remote(const char *, const cha
__dead void
usage(void)
{
- fprintf(stderr, "usage: %s [-d] [-l line] [-s speed | -speed]\n",
+ fprintf(stderr, "usage: %s [-dk] [-l line] [-s speed | -speed]\n",
__progname);
fprintf(stderr, " %s [host]\n", __progname);
exit(1);
@@ -100,11 +101,16 @@ main(int argc, char **argv)
errx(1, "speed asprintf");
}
- while ((opt
Re: tftpd(8): diff for ip path rewrite
On Wed, Oct 25, 2017 at 04:54:01PM +, Jeremie Courreges-Anglas wrote: > On Tue, Oct 24 2017, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > > On Mon, Oct 23 2017, Jan Klemkow <j.klem...@wemelug.de> wrote: > >> On Sun, Oct 22, 2017 at 09:32:54PM +, Jeremie Courreges-Anglas wrote: > >>> On Sat, Oct 21 2017, Jan Klemkow <j.klem...@wemelug.de> wrote: > >>> > On Fri, Oct 20, 2017 at 12:04:41PM +, Jeremie Courreges-Anglas > >>> > wrote: > >>> >> On Fri, Oct 20 2017, Sebastien Marie <sema...@online.fr> wrote: > >>> >> > On Thu, Oct 19, 2017 at 08:58:12PM +0200, Jan Klemkow wrote: > >>> >> >> + char nfilename[PATH_MAX]; > >>> >> >> + > >>> >> >> + snprintf(nfilename, sizeof nfilename, "%s/%s", > >>> >> >> + getip(>ss), filename); > >>> >> > > >>> >> > - filename has PATH_MAX length > >>> >> > - getip(>ss) could have NI_MAXHOST length > >>> >> > >>> >> INET6_ADDRSTRLEN since getip() calls getnameinfo(NI_NUMERICHOST), but > >>> >> your point stands. > >>> >> > >>> >> > so nfilename could be larger than PATH_MAX (sizeof nfilename). > >>> >> > > >>> >> > I assume the return of snprintf() need to be checked. if truncation > >>> >> > occured, a warning should be issued and nfilename discarded (just > >>> >> > calling tftp_open(client, filename)) ? > >>> >> > >>> >> I think we should refuse the request if truncated. > >>> > > >>> > done > >>> > > >>> >> >> + if (access(nfilename, R_OK) == 0) > >>> >> >> + tftp_open(client, nfilename); > >>> >> >> + else > >>> >> >> + tftp_open(client, filename); > >>> >> >> + } > >>> >> > >>> >> Here we look up the same file in both the client-specific subdirectory > >>> >> and the default directory. Should we instead look only in the > >>> >> client-specific directory if the latter exist? > >>> > > >>> > Common files should be found in the default directory. But, host > >>> > specific files could be overwritten if they exist in the subdirectory. > >>> > >>> I think it would be better to perform those access tests in > >>> validate_access(); logic in a single place, and a less quirky handling > >>> of SEEDPATH. Also the test done should probably depend on the type > >>> (read, write) of the request. Retrying with the default directory may > >>> make sense in read mode, but maybe not in write (and -c, create) mode? > >>> > >>> The updated diff below implements such semantics, but in > >>> validate_access(). While here, > >>> - improve diagnostic if both -i and -r are given; usage() doesn't show > >>> the conflict > >>> - also test snprintf return value against -1, as spotted by semarie@ > >>> > >>> Maybe we should add a mention in the manpage that the client can > >>> "escape" its client-specific directory? (ie /../192.0.2.1/file) > >>> > >>> The logic is more complicated but I hope it's for good. > >> > >> I successfully testes jca's diff in my setup and add two lines about > >> directory escaping to the manpage. > > > > I don't think there is a need to expand on security and machines > > changing their IP address, especially when you're using TFTP, an > > insecure protocol. I just wanted to stress that no enforcement was > > done. > > > > Here's an alternate take at documenting -i, addressing a few issues. It > > moves the "no path enforcement" sentence to CAVEATS. I hope you agree > > with this move. > > At least jmc@ thinks that the -i flag description is a better place. > > > While here: > > - kill .Tn > > - the content of the previous BUGS section doesn't look like a TFTP bug, > > so CAVEATS looks more appropriate to me > > I've kept those changes (to be committed seperately). > > > Feedback & oks welcome. > > New diff after feedback from jmc@ I tested this diff. It looks fine for me. Thanks, Jan > I
Re: tftpd(8): diff for ip path rewrite
On Sun, Oct 22, 2017 at 09:32:54PM +, Jeremie Courreges-Anglas wrote:
> On Sat, Oct 21 2017, Jan Klemkow <j.klem...@wemelug.de> wrote:
> > On Fri, Oct 20, 2017 at 12:04:41PM +, Jeremie Courreges-Anglas wrote:
> >> On Fri, Oct 20 2017, Sebastien Marie <sema...@online.fr> wrote:
> >> > On Thu, Oct 19, 2017 at 08:58:12PM +0200, Jan Klemkow wrote:
> >> >> + char nfilename[PATH_MAX];
> >> >> +
> >> >> + snprintf(nfilename, sizeof nfilename, "%s/%s",
> >> >> + getip(>ss), filename);
> >> >
> >> > - filename has PATH_MAX length
> >> > - getip(>ss) could have NI_MAXHOST length
> >>
> >> INET6_ADDRSTRLEN since getip() calls getnameinfo(NI_NUMERICHOST), but
> >> your point stands.
> >>
> >> > so nfilename could be larger than PATH_MAX (sizeof nfilename).
> >> >
> >> > I assume the return of snprintf() need to be checked. if truncation
> >> > occured, a warning should be issued and nfilename discarded (just
> >> > calling tftp_open(client, filename)) ?
> >>
> >> I think we should refuse the request if truncated.
> >
> > done
> >
> >> >> + if (access(nfilename, R_OK) == 0)
> >> >> + tftp_open(client, nfilename);
> >> >> + else
> >> >> + tftp_open(client, filename);
> >> >> + }
> >>
> >> Here we look up the same file in both the client-specific subdirectory
> >> and the default directory. Should we instead look only in the
> >> client-specific directory if the latter exist?
> >
> > Common files should be found in the default directory. But, host
> > specific files could be overwritten if they exist in the subdirectory.
>
> I think it would be better to perform those access tests in
> validate_access(); logic in a single place, and a less quirky handling
> of SEEDPATH. Also the test done should probably depend on the type
> (read, write) of the request. Retrying with the default directory may
> make sense in read mode, but maybe not in write (and -c, create) mode?
>
> The updated diff below implements such semantics, but in
> validate_access(). While here,
> - improve diagnostic if both -i and -r are given; usage() doesn't show
> the conflict
> - also test snprintf return value against -1, as spotted by semarie@
>
> Maybe we should add a mention in the manpage that the client can
> "escape" its client-specific directory? (ie /../192.0.2.1/file)
>
> The logic is more complicated but I hope it's for good.
I successfully testes jca's diff in my setup and add two lines about
directory escaping to the manpage.
Thanks,
Jan
Index: tftpd.8
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
retrieving revision 1.5
diff -u -p -r1.5 tftpd.8
--- tftpd.8 18 Jul 2015 05:32:56 - 1.5
+++ tftpd.8 23 Oct 2017 18:03:41 -
@@ -37,7 +37,7 @@
.Nd DARPA Trivial File Transfer Protocol daemon
.Sh SYNOPSIS
.Nm tftpd
-.Op Fl 46cdv
+.Op Fl 46cdiv
.Op Fl l Ar address
.Op Fl p Ar port
.Op Fl r Ar socket
@@ -100,6 +100,19 @@ If this option is specified,
.Nm
will run in the foreground and log
the client IP, type of request, and filename to stderr.
+.It Fl i
+.Nm
+tries to rewrite the requested filename with a prefix of
+the client's IP address.
+If the rewritten path exists
+.Nm
+will serve this file.
+If not, it will serve the original filename.
+This option is no security feature.
+Clients are able to escape thier specific directory by
+paths like /../ or by changing their IP address.
+This option can not be combined with
+.Fl r .
.It Fl l Ar address
Listen on the specified address.
By default
@@ -126,6 +139,8 @@ before the TFTP request will continue.
By default
.Nm
does not use filename rewriting.
+This option can not be combined with
+.Fl i .
.It Fl v
Log the client IP, type of request, and filename.
.It Ar directory
Index: tftpd.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
retrieving revision 1.39
diff -u -p -r1.39 tftpd.c
--- tftpd.c 26 May 2017 17:38:46 - 1.39
+++ tftpd.c 23 Oct 2017 17:56:03 -
@@ -282,7 +282,7 @@ __dead void
usage(void)
{
extern char *__progname;
- fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]"
+ fprintf(stderr, "usage: %s [-46cdiv] [-l address] [-p port] [-r socket]"
" directory\n", __progna
Re: tftpd(8): diff for ip path rewrite
On Fri, Oct 20, 2017 at 12:04:41PM +, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 20 2017, Sebastien Marie <sema...@online.fr> wrote:
> > On Thu, Oct 19, 2017 at 08:58:12PM +0200, Jan Klemkow wrote:
> >> + char nfilename[PATH_MAX];
> >> +
> >> + snprintf(nfilename, sizeof nfilename, "%s/%s",
> >> + getip(>ss), filename);
> >
> > - filename has PATH_MAX length
> > - getip(>ss) could have NI_MAXHOST length
>
> INET6_ADDRSTRLEN since getip() calls getnameinfo(NI_NUMERICHOST), but
> your point stands.
>
> > so nfilename could be larger than PATH_MAX (sizeof nfilename).
> >
> > I assume the return of snprintf() need to be checked. if truncation
> > occured, a warning should be issued and nfilename discarded (just
> > calling tftp_open(client, filename)) ?
>
> I think we should refuse the request if truncated.
done
> >> + if (access(nfilename, R_OK) == 0)
> >> + tftp_open(client, nfilename);
> >> + else
> >> + tftp_open(client, filename);
> >> + }
>
> Here we look up the same file in both the client-specific subdirectory
> and the default directory. Should we instead look only in the
> client-specific directory if the latter exist?
Common files should be found in the default directory. But, host
specific files could be overwritten if they exist in the subdirectory.
The diff below should address all comments.
Thanks,
Jan
Index: tftpd.8
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
retrieving revision 1.5
diff -u -p -r1.5 tftpd.8
--- tftpd.8 18 Jul 2015 05:32:56 - 1.5
+++ tftpd.8 21 Oct 2017 18:41:15 -
@@ -37,7 +37,7 @@
.Nd DARPA Trivial File Transfer Protocol daemon
.Sh SYNOPSIS
.Nm tftpd
-.Op Fl 46cdv
+.Op Fl 46cdiv
.Op Fl l Ar address
.Op Fl p Ar port
.Op Fl r Ar socket
@@ -100,6 +100,16 @@ If this option is specified,
.Nm
will run in the foreground and log
the client IP, type of request, and filename to stderr.
+.It Fl i
+.Nm
+tries to rewrite the requested filename with a prefix of
+the client's IP address.
+If the rewritten path exists
+.Nm
+will serve this file.
+If not, it will serve the original filename.
+This option can not be combined with
+.Fl r .
.It Fl l Ar address
Listen on the specified address.
By default
@@ -126,6 +136,8 @@ before the TFTP request will continue.
By default
.Nm
does not use filename rewriting.
+This option can not be combined with
+.Fl i .
.It Fl v
Log the client IP, type of request, and filename.
.It Ar directory
Index: tftpd.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
retrieving revision 1.39
diff -u -p -r1.39 tftpd.c
--- tftpd.c 26 May 2017 17:38:46 - 1.39
+++ tftpd.c 21 Oct 2017 19:49:04 -
@@ -282,7 +282,7 @@ __dead void
usage(void)
{
extern char *__progname;
- fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]"
+ fprintf(stderr, "usage: %s [-46cdiv] [-l address] [-p port] [-r socket]"
" directory\n", __progname);
exit(1);
}
@@ -290,6 +290,7 @@ usage(void)
int cancreate = 0;
int verbose = 0;
int debug = 0;
+int iflag = 0;
int
main(int argc, char *argv[])
@@ -307,7 +308,7 @@ main(int argc, char *argv[])
int family = AF_UNSPEC;
int devnull = -1;
- while ((c = getopt(argc, argv, "46cdl:p:r:v")) != -1) {
+ while ((c = getopt(argc, argv, "46cdil:p:r:v")) != -1) {
switch (c) {
case '4':
family = AF_INET;
@@ -321,6 +322,11 @@ main(int argc, char *argv[])
case 'd':
verbose = debug = 1;
break;
+ case 'i':
+ if (rewrite != NULL)
+ usage();
+ iflag = 1;
+ break;
case 'l':
addr = optarg;
break;
@@ -328,6 +334,8 @@ main(int argc, char *argv[])
port = optarg;
break;
case 'r':
+ if (iflag == 1)
+ usage();
rewrite = optarg;
break;
case 'v':
@@ -903,7 +911,20 @@ again:
if (rwmap != NULL)
rewrite_map(client, filename);
- else
+ else if (iflag) {
+ char nfilename[PATH_MAX];
+
+ if (snprintf(nfilename, sizeof(nfilename), "%s/%s",
+
Re: tftpd(8): diff for ip path rewrite
On Thu, Oct 19, 2017 at 09:36:50AM +, Jeremie Courreges-Anglas wrote:
> On Wed, Oct 18 2017, Jan Klemkow <j.klem...@wemelug.de> wrote:
> > On Wed, Oct 18, 2017 at 08:37:48PM +, Jason McIntyre wrote:
> >> On Wed, Oct 18, 2017 at 10:25:13PM +0200, Jan Klemkow wrote:
> >> > This diff adds an option for client IP address path prefixes to the
> >> > tftpd(8). First, I used the -r rewrite socket for this, but...
> >> >
> >> > If you use the rewrite socket feature, the tftpd(8) will exit with an
> >> > error when the rewrite socket is closed. A reopen of the socket is not
> >> > possible, if its outside of the chroot directory. And a privilege
> >> > separated tftpd(8) is a bit overkill for a stable per client path
> >> > rewrite feature. This story led me to this change here.
>
> I think it makes sense to support this feature without the need for an
> additional unix service.
>
> >> > Any suggestions or objections are welcome. :-)
>
> Do we want to provide a fallback directory so that you don't need to
> restart tftpd without -i to support unknown clients?
bluhm@ suggested, that this should be the default behavior. Thus, the
ftpd(8) checks if a subdirectory with the client's ip address exists and
contains the requested file. It not, it uses the original path as
default. I implemented it in this diff:
Index: tftpd.8
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
retrieving revision 1.5
diff -u -p -r1.5 tftpd.8
--- tftpd.8 18 Jul 2015 05:32:56 - 1.5
+++ tftpd.8 19 Oct 2017 18:41:07 -
@@ -78,6 +78,14 @@ and therefore this path will be ignored
.Ox
network bootloaders access this path to harvest entropy during
kernel load.
+Also,
+.Nm
+always tries to rewrite the requested filename with a prefix of
+the client's IP address.
+If the rewritten path exists
+.Nm
+will serve this file.
+If not, it will serve the original filename.
.Pp
The options are as follows:
.Bl -tag -width Ds
Index: tftpd.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
retrieving revision 1.39
diff -u -p -r1.39 tftpd.c
--- tftpd.c 26 May 2017 17:38:46 - 1.39
+++ tftpd.c 19 Oct 2017 18:27:24 -
@@ -903,8 +903,17 @@ again:
if (rwmap != NULL)
rewrite_map(client, filename);
- else
- tftp_open(client, filename);
+ else {
+ char nfilename[PATH_MAX];
+
+ snprintf(nfilename, sizeof nfilename, "%s/%s",
+ getip(>ss), filename);
+
+ if (access(nfilename, R_OK) == 0)
+ tftp_open(client, nfilename);
+ else
+ tftp_open(client, filename);
+ }
return;
Re: tftpd(8): diff for ip path rewrite
On Wed, Oct 18, 2017 at 08:37:48PM +, Jason McIntyre wrote:
> On Wed, Oct 18, 2017 at 10:25:13PM +0200, Jan Klemkow wrote:
> > This diff adds an option for client IP address path prefixes to the
> > tftpd(8). First, I used the -r rewrite socket for this, but...
> >
> > If you use the rewrite socket feature, the tftpd(8) will exit with an
> > error when the rewrite socket is closed. A reopen of the socket is not
> > possible, if its outside of the chroot directory. And a privilege
> > separated tftpd(8) is a bit overkill for a stable per client path
> > rewrite feature. This story led me to this change here.
> >
> > Any suggestions or objections are welcome. :-)
>
> evening. some comments inline:
Thanks. Fixed diff:
Index: tftpd.8
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
retrieving revision 1.5
diff -u -p -r1.5 tftpd.8
--- tftpd.8 18 Jul 2015 05:32:56 - 1.5
+++ tftpd.8 18 Oct 2017 21:12:52 -
@@ -37,7 +37,7 @@
.Nd DARPA Trivial File Transfer Protocol daemon
.Sh SYNOPSIS
.Nm tftpd
-.Op Fl 46cdv
+.Op Fl 46cdiv
.Op Fl l Ar address
.Op Fl p Ar port
.Op Fl r Ar socket
@@ -100,6 +100,11 @@ If this option is specified,
.Nm
will run in the foreground and log
the client IP, type of request, and filename to stderr.
+.It Fl i
+Use the client's IP address as a subdirectory prefix for all requested
+filenames.
+This option can not be combined with
+.Fl r .
.It Fl l Ar address
Listen on the specified address.
By default
@@ -126,6 +131,8 @@ before the TFTP request will continue.
By default
.Nm
does not use filename rewriting.
+This option can not be combined with
+.Fl i .
.It Fl v
Log the client IP, type of request, and filename.
.It Ar directory
Index: tftpd.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
retrieving revision 1.39
diff -u -p -r1.39 tftpd.c
--- tftpd.c 26 May 2017 17:38:46 - 1.39
+++ tftpd.c 18 Oct 2017 21:16:25 -
@@ -282,7 +282,7 @@ __dead void
usage(void)
{
extern char *__progname;
- fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]"
+ fprintf(stderr, "usage: %s [-46cdiv] [-l address] [-p port] [-r socket]"
" directory\n", __progname);
exit(1);
}
@@ -290,6 +290,7 @@ usage(void)
int cancreate = 0;
int verbose = 0;
int debug = 0;
+int iflag = 0;
int
main(int argc, char *argv[])
@@ -307,7 +308,7 @@ main(int argc, char *argv[])
int family = AF_UNSPEC;
int devnull = -1;
- while ((c = getopt(argc, argv, "46cdl:p:r:v")) != -1) {
+ while ((c = getopt(argc, argv, "46cdil:p:r:v")) != -1) {
switch (c) {
case '4':
family = AF_INET;
@@ -321,6 +322,11 @@ main(int argc, char *argv[])
case 'd':
verbose = debug = 1;
break;
+ case 'i':
+ if (rewrite != NULL)
+ usage();
+ iflag = 1;
+ break;
case 'l':
addr = optarg;
break;
@@ -328,6 +334,8 @@ main(int argc, char *argv[])
port = optarg;
break;
case 'r':
+ if (iflag)
+ usage();
rewrite = optarg;
break;
case 'v':
@@ -903,7 +911,13 @@ again:
if (rwmap != NULL)
rewrite_map(client, filename);
- else
+ else if (iflag) {
+ char nfilename[PATH_MAX];
+
+ snprintf(nfilename, sizeof nfilename, "%s/%s",
+ getip(>ss), filename);
+ tftp_open(client, nfilename);
+ } else
tftp_open(client, filename);
return;
tftpd(8): diff for ip path rewrite
Hi,
This diff adds an option for client IP address path prefixes to the
tftpd(8). First, I used the -r rewrite socket for this, but...
If you use the rewrite socket feature, the tftpd(8) will exit with an
error when the rewrite socket is closed. A reopen of the socket is not
possible, if its outside of the chroot directory. And a privilege
separated tftpd(8) is a bit overkill for a stable per client path
rewrite feature. This story led me to this change here.
Any suggestions or objections are welcome. :-)
Bye,
Jan
Index: tftpd.8
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.8,v
retrieving revision 1.5
diff -u -p -r1.5 tftpd.8
--- tftpd.8 18 Jul 2015 05:32:56 - 1.5
+++ tftpd.8 18 Oct 2017 19:58:40 -
@@ -40,7 +40,7 @@
.Op Fl 46cdv
.Op Fl l Ar address
.Op Fl p Ar port
-.Op Fl r Ar socket
+.Op Fl i | Fl r Ar socket
.Ar directory
.Sh DESCRIPTION
.Nm
@@ -113,6 +113,12 @@ listens on the port indicated in the
.Ql tftp
service description; see
.Xr services 5 .
+.It Fl i
+.Nm
+will use the clients IP address as subdirectory prefix for all requested
+filenames.
+This option can not be combined with
+.Fl r .
.It Fl r Ar socket
Issue filename rewrite requests to the specified UNIX domain socket.
.Nm
@@ -126,6 +132,8 @@ before the TFTP request will continue.
By default
.Nm
does not use filename rewriting.
+This option can not be combined with
+.Fl i .
.It Fl v
Log the client IP, type of request, and filename.
.It Ar directory
Index: tftpd.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/tftpd/tftpd.c,v
retrieving revision 1.39
diff -u -p -r1.39 tftpd.c
--- tftpd.c 26 May 2017 17:38:46 - 1.39
+++ tftpd.c 18 Oct 2017 19:59:40 -
@@ -282,14 +282,15 @@ __dead void
usage(void)
{
extern char *__progname;
- fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port] [-r socket]"
- " directory\n", __progname);
+ fprintf(stderr, "usage: %s [-46cdv] [-l address] [-p port]"
+ " [-i | -r socket] directory\n", __progname);
exit(1);
}
int cancreate = 0;
int verbose = 0;
int debug = 0;
+int iflag = 0;
int
main(int argc, char *argv[])
@@ -307,7 +308,7 @@ main(int argc, char *argv[])
int family = AF_UNSPEC;
int devnull = -1;
- while ((c = getopt(argc, argv, "46cdl:p:r:v")) != -1) {
+ while ((c = getopt(argc, argv, "46cdil:p:r:v")) != -1) {
switch (c) {
case '4':
family = AF_INET;
@@ -321,6 +322,11 @@ main(int argc, char *argv[])
case 'd':
verbose = debug = 1;
break;
+ case 'i':
+ if (rewrite != NULL)
+ usage();
+ iflag = 1;
+ break;
case 'l':
addr = optarg;
break;
@@ -328,6 +334,8 @@ main(int argc, char *argv[])
port = optarg;
break;
case 'r':
+ if (iflag)
+ usage();
rewrite = optarg;
break;
case 'v':
@@ -903,7 +911,13 @@ again:
if (rwmap != NULL)
rewrite_map(client, filename);
- else
+ else if (iflag) {
+ char nfilename[PATH_MAX];
+
+ snprintf(nfilename, sizeof nfilename, "%s/%s",
+ getip(>ss), filename);
+ tftp_open(client, nfilename);
+ } else
tftp_open(client, filename);
return;
Re: [diff] httpd: tls client cert & CRL checks
Hi Jack,
On Fri, Jul 28, 2017 at 02:05:34AM +0930, Jack Burton wrote:
> On Thu, 27 Jul 2017 13:10:14 +0200
>
> > But, I found a bug in the part of the FastCGI variables. The
> > following condition is always false.
> >
> > > Index: usr.sbin/httpd/server_fcgi.c
> > > ===
> > > RCS file: /cvs/src/usr.sbin/httpd/server_fcgi.c,v
> > > retrieving revision 1.74
> > > diff -u -p -r1.74 server_fcgi.c
> > > --- usr.sbin/httpd/server_fcgi.c 21 Jan 2017 11:32:04
> > > - 1.74 +++ usr.sbin/httpd/server_fcgi.c 21 Jul
> > > 2017 08:25:57 - @@ -282,11 +283,57 @@ server_fcgi(struct httpd
> > > *env, struct cl
> > ...
> > > + if (srv_conf->tls_ca != NULL) {
> > ...
>
> That's odd -- I'm not seeing that behaviour here -- in my tests
> srv_conf->tls_ca always behaved just as expected (it's NULL iff the "tls
> client ca" directive is not given for that server).
In the End, I found and fixed the real bug here:
@@ -430,7 +438,11 @@ config_getserver_config(struct httpd *en
}
f = SRVFLAG_TLS;
- srv_conf->flags |= parent->flags & f;
+ if ((srv_conf->flags & f) == 0) {
+ srv_conf->flags |= parent->flags & f;
+ srv_conf->tls_ca = parent->tls_ca;
+ srv_conf->tls_crl = parent->tls_crl;
+ }
f = SRVFLAG_ACCESS_LOG;
if ((srv_conf->flags & f) == 0) {
This additional copy fixes the bug I have seen by this config:
server "default" {
listen on 127.0.0.1 tls port 443
# TLS certificate and key files created with acme-client(1)
tls certificate "/root/ca/server.crt"
tls key "/root/ca/server.key"
#tls client ca "/root/ca/ca.crt" crl "/root/ca/ca.crl"
tls client ca "/root/ca/ca.crt"
location "*.cgi" {
fastcgi
root "/var/www/cgi-bin/env.cgi"
}
root "/htdocs/"
}
You find the whole diff below.
I tested:
- TLS without client certs
- TLS with client certs and without CRL
- TLS with client certs and with CRL
- as well as environment variables in CGI-Scripts
Everything should work now.
Bye,
Jan
Index: usr.sbin/httpd/config.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.53
diff -u -p -r1.53 config.c
--- usr.sbin/httpd/config.c 19 Jul 2017 17:36:25 - 1.53
+++ usr.sbin/httpd/config.c 29 Jul 2017 18:14:36 -
@@ -304,10 +304,18 @@ config_setserver_tls(struct httpd *env,
log_debug("%s: configuring tls for %s", __func__, srv_conf->name);
+ if (config_settls(env, srv, TLS_CFG_CA, "ca", srv_conf->tls_ca,
+ srv_conf->tls_ca_len) != 0)
+ return (-1);
+
if (config_settls(env, srv, TLS_CFG_CERT, "cert", srv_conf->tls_cert,
srv_conf->tls_cert_len) != 0)
return (-1);
+ if (config_settls(env, srv, TLS_CFG_CRL, "crl", srv_conf->tls_crl,
+ srv_conf->tls_crl_len) != 0)
+ return (-1);
+
if (config_settls(env, srv, TLS_CFG_KEY, "key", srv_conf->tls_key,
srv_conf->tls_key_len) != 0)
return (-1);
@@ -430,7 +438,11 @@ config_getserver_config(struct httpd *en
}
f = SRVFLAG_TLS;
- srv_conf->flags |= parent->flags & f;
+ if ((srv_conf->flags & f) == 0) {
+ srv_conf->flags |= parent->flags & f;
+ srv_conf->tls_ca = parent->tls_ca;
+ srv_conf->tls_crl = parent->tls_crl;
+ }
f = SRVFLAG_ACCESS_LOG;
if ((srv_conf->flags & f) == 0) {
@@ -655,9 +667,21 @@ config_getserver_tls(struct httpd *env,
}
switch (tls_conf.tls_type) {
+ case TLS_CFG_CA:
+ if (config_gettls(env, srv_conf, _conf, "ca", p, len,
+ _conf->tls_ca, _conf->tls_ca_len) != 0)
+ goto fail;
+ break;
+
case TLS_CFG_CERT:
if (config_gettls(env, srv_conf, _conf, "cert", p, len,
_conf->tls_cert, _conf->tls_cert_len) != 0)
+ goto fail;
+ break;
+
+ case TLS_CFG_CRL:
+ if (config_gettls(env, srv_conf, _conf, "crl", p, len,
+ _conf->tls_crl, _conf->tls_crl_len) != 0)
goto fail;
break;
Index: usr.sbin/httpd/httpd.conf.5
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.82
diff -u -p -r1.82 httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5 9 Apr 2017 09:13:28 - 1.82
+++ usr.sbin/httpd/httpd.conf.5 28 Jul 2017 11:28:25 -
@@ -342,6 +342,28 @@ The revision of
Re: [diff] httpd: tls client cert & CRL checks
Hi Jack,
On Fri, Jul 21, 2017 at 06:33:43PM +0930, Jack Burton wrote:
> Thoughts?
I've tested your diff. The main feature looks fine to me. TLS
connections with and with out Clients certs, as well as with and without
certificate revocation lists seams to work. Also, the tests are
passing.
But, I found a bug in the part of the FastCGI variables. The following
condition is always false.
> Index: usr.sbin/httpd/server_fcgi.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_fcgi.c,v
> retrieving revision 1.74
> diff -u -p -r1.74 server_fcgi.c
> --- usr.sbin/httpd/server_fcgi.c 21 Jan 2017 11:32:04 - 1.74
> +++ usr.sbin/httpd/server_fcgi.c 21 Jul 2017 08:25:57 -
> @@ -282,11 +283,57 @@ server_fcgi(struct httpd *env, struct cl
...
> + if (srv_conf->tls_ca != NULL) {
...
It has to be replaced with the following condition:
+ if (clt->clt_srv->srv_conf.tls_ca != NULL) {
To make this working I have to change two void pointers by more specific
types. Below, you find the whole diff:
bye,
Jan
Index: regress/usr.sbin/httpd/tests/Client.pm
===
RCS file: /mount/openbsd/cvs/src/regress/usr.sbin/httpd/tests/Client.pm,v
retrieving revision 1.1
diff -u -p -r1.1 Client.pm
--- regress/usr.sbin/httpd/tests/Client.pm 16 Jul 2015 16:35:57 -
1.1
+++ regress/usr.sbin/httpd/tests/Client.pm 21 Jul 2017 11:20:24 -
@@ -59,6 +59,11 @@ sub child {
PeerAddr=> $self->{connectaddr},
PeerPort=> $self->{connectport},
SSL_verify_mode => SSL_VERIFY_NONE,
+ SSL_use_cert=> $self->{offertlscert} ? 1 : 0,
+ SSL_cert_file => $self->{offertlscert} ?
+ $self->{chroot}."/client.crt" : "",
+ SSL_key_file=> $self->{offertlscert} ?
+ $self->{chroot}."/client.key" : "",
) or die ref($self), " $iosocket socket connect failed: $!,$SSL_ERROR";
print STDERR "connect sock: ",$cs->sockhost()," ",$cs->sockport(),"\n";
print STDERR "connect peer: ",$cs->peerhost()," ",$cs->peerport(),"\n";
Index: regress/usr.sbin/httpd/tests/Httpd.pm
===
RCS file: /mount/openbsd/cvs/src/regress/usr.sbin/httpd/tests/Httpd.pm,v
retrieving revision 1.2
diff -u -p -r1.2 Httpd.pm
--- regress/usr.sbin/httpd/tests/Httpd.pm 30 Jan 2017 21:18:24 -
1.2
+++ regress/usr.sbin/httpd/tests/Httpd.pm 21 Jul 2017 11:20:24 -
@@ -72,6 +72,8 @@ sub new {
print $fh "\n";
print $fh "\ttls certificate \"".$args{chroot}."/server.crt\"\n";
print $fh "\ttls key \"".$args{chroot}."/server.key\"";
+ $self->{verifytls}
+ and print $fh "\ntls client ca \"".$args{chroot}."/ca.crt\"";
}
print $fh "\n\troot \"/\"";
print $fh "\n\tlog style combined";
Index: regress/usr.sbin/httpd/tests/Makefile
===
RCS file: /mount/openbsd/cvs/src/regress/usr.sbin/httpd/tests/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- regress/usr.sbin/httpd/tests/Makefile 14 Jul 2017 13:31:44 -
1.8
+++ regress/usr.sbin/httpd/tests/Makefile 21 Jul 2017 11:20:24 -
@@ -77,10 +77,16 @@ ca.crt:
server.req:
openssl req -batch -new -subj
/L=OpenBSD/O=httpd-regress/OU=server/CN=localhost/ -nodes -newkey rsa -keyout
server.key -out server.req
+client.req:
+ openssl req -batch -new -subj
/L=OpenBSD/O=httpd-regress/OU=client/CN=localhost/ -nodes -newkey rsa -keyout
client.key -out $@
+
server.crt: ca.crt server.req
openssl x509 -CAcreateserial -CAkey ca.key -CA ca.crt -req -in
server.req -out server.crt
-${REGRESS_TARGETS:M*tls*} ${REGRESS_TARGETS:M*https*}: server.crt
+client.crt: ca.crt client.req
+ openssl x509 -CAcreateserial -CAkey ca.key -CA ca.crt -req -in
client.req -out $@
+
+${REGRESS_TARGETS:M*tls*} ${REGRESS_TARGETS:M*https*}: server.crt client.crt
# make perl syntax check for all args files
Index: usr.sbin/httpd/config.c
===
RCS file: /mount/openbsd/cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.53
diff -u -p -r1.53 config.c
--- usr.sbin/httpd/config.c 19 Jul 2017 17:36:25 - 1.53
+++ usr.sbin/httpd/config.c 21 Jul 2017 11:20:24 -
@@ -304,10 +304,18 @@ config_setserver_tls(struct httpd *env,
log_debug("%s: configuring tls for %s", __func__, srv_conf->name);
+ if (config_settls(env, srv, TLS_CFG_CA, "ca", srv_conf->tls_ca,
+ srv_conf->tls_ca_len) != 0)
+ return (-1);
+
if (config_settls(env, srv, TLS_CFG_CERT, "cert", srv_conf->tls_cert,
Re: diff: add missing rtm_send to nd6
Hi Martin,
On Thu, Jun 08, 2017 at 09:44:37AM +0200, Martin Pieuchot wrote:
> On 08/06/17(Thu) 00:47, Jan Klemkow wrote:
> > This diff adds a missing routing message to the neighbor discovery code.
> > The message informs the userland about new reachable IPv6 nodes on the
> > network. The IPv6 network stack acts more like the IPv4 port by this
> > diff. Now, the behavior is like arpcache() in netinet/if_ether.c on
> > line 653.
>
> The call should be under KERNEL_LOCK()/KERNEL_UNLOCK(). Writing to
> routing sockets isn't protected by the NET_LOCK().
>
> Yes this doesn't matter right now, but since we're working on removing
> the KERNEL_LOCK() from the protocol layer, let's have this ready ;)
Here is a fixed version of this diff.
Thanks,
Jan
Index: nd6_nbr.c
===
RCS file: /cvs/src/sys/netinet6/nd6_nbr.c,v
retrieving revision 1.116
diff -u -p -r1.116 nd6_nbr.c
--- nd6_nbr.c 16 May 2017 12:24:04 - 1.116
+++ nd6_nbr.c 8 Jun 2017 08:44:28 -
@@ -715,6 +715,10 @@ nd6_na_input(struct mbuf *m, int off, in
if (is_solicited) {
ln->ln_state = ND6_LLINFO_REACHABLE;
ln->ln_byhint = 0;
+ /* Notify userland that a new ND entry is reachable. */
+ KERNEL_LOCK();
+ rtm_send(rt, RTM_RESOLVE, ifp->if_rdomain);
+ KERNEL_UNLOCK();
if (!ND6_LLINFO_PERMANENT(ln)) {
nd6_llinfo_settimer(ln,
ND_IFINFO(ifp)->reachable);
diff: add missing rtm_send to nd6
Hi,
This diff adds a missing routing message to the neighbor discovery code.
The message informs the userland about new reachable IPv6 nodes on the
network. The IPv6 network stack acts more like the IPv4 port by this
diff. Now, the behavior is like arpcache() in netinet/if_ether.c on
line 653.
Bye,
Jan
Index: nd6_nbr.c
===
RCS file: /cvs/src/sys/netinet6/nd6_nbr.c,v
retrieving revision 1.116
diff -u -p -r1.116 nd6_nbr.c
--- nd6_nbr.c 16 May 2017 12:24:04 - 1.116
+++ nd6_nbr.c 7 Jun 2017 22:11:31 -
@@ -715,6 +715,8 @@ nd6_na_input(struct mbuf *m, int off, in
if (is_solicited) {
ln->ln_state = ND6_LLINFO_REACHABLE;
ln->ln_byhint = 0;
+ /* Notify userland that a new ND entry is reachable. */
+ rtm_send(rt, RTM_RESOLVE, ifp->if_rdomain);
if (!ND6_LLINFO_PERMANENT(ln)) {
nd6_llinfo_settimer(ln,
ND_IFINFO(ifp)->reachable);
snmpd: remove unused variables
Hi,
This diff removes two local variables which are never used.
bye,
Jan
Index: trap.c
===
RCS file: /cvs/src/usr.sbin/snmpd/trap.c,v
retrieving revision 1.29
diff -u -p -r1.29 trap.c
--- trap.c 21 Apr 2017 13:46:15 - 1.29
+++ trap.c 31 May 2017 16:12:43 -
@@ -63,7 +63,6 @@ trap_agentx(struct agentx_handle *h, str
struct ber_element *varbind, *iter;
int x = 0, state = 0;
int ret = AGENTX_ERR_NONE;
- int seensysuptime, seentrapoid;
size_t len = 0;
pid_tpid = -1;
char*v = NULL;
@@ -71,7 +70,6 @@ trap_agentx(struct agentx_handle *h, str
*varcpy = NULL;
varbind = NULL;
iter = NULL;
- seensysuptime = seentrapoid = 0;
if (pdu->hdr->flags & AGENTX_NON_DEFAULT_CONTEXT) {
ret = AGENTX_ERR_UNSUPPORTED_CONTEXT;
Re: httpd: proposed patch to add TLS client certificate support
Hi Jack,
I'm not a developer (just a contributor), but I worked on httpd client
certs a year ago, too. (https://marc.info/?t=14528592613=1=2)
I got a private response from a developer, who had an own similar diff
in preparation. He told me that is better to name configuration option
"client ca " instead of "ca ".
You could adapt my regression test to make sure the feature does not
break in future development:
https://marc.info/?l=openbsd-tech=146289968117988=2
I had not time to test your diff, but I like it. I also need this
feature in httpd.
In response of your second mail:
I prefer the Idea to handle revocations by a CRL which is checked by
libtls in case of client certificates.
btw: As far as I know, there is a source tree lock at the moment. Thus,
it may take some time to integrate you diff.
Just my two cent,
Jan
On Thu, Mar 30, 2017 at 10:17:46PM +1030, Jack Burton wrote:
> One of our sites has a need to require/verify TLS client certs,
> without the overhead & complexity of apache / nginx, etc.
>
> OpenBSD's httpd seemed the obvious candidate, and I figured that the
> feature would be useful to others too -- see attached diff for an
> initial implementation.
>
> Of course, there are two parts to verifying TLS client certs:
>
> 1. Checking that the certificate was issued by a locally-trusted CA and
> has not yet expired. That's fairly straightforward and (I would hope)
> non-controversial. The attached diff adds that to httpd and also
> exposes as new fastcgi variables some of the more useful client cert
> data that libtls provides (since fastcgi responders are likely where
> identity is of most interest).
>
> 2. Validating that the certificate has not yet been revoked. The
> attached diff does NOT address that part, but that's what I intend to
> turn my attention to next, if there's any interest in adding TLS client
> cert support to httpd. I'll send a separate post with my thoughts on
> that shortly (as there's a bunch of ways to do it, so some discussion
> on which to prefer is probably in order).
>
> So, my question here for the devs is: does this fit in with the intended
> direction of httpd(8)? (if so, I'll work on part 2 next; if not, I'll
> stop bothering you)
>
> This is the first time I've submitted a diff with a proposed new feature
> (as opposed to just a bug fix) for any part of OpenBSD, so if I've gone
> about any part of it in the wrong way, please correct me & I'll try to
> do better next time.
>
> Index: config.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/config.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 config.c
> --- config.c 25 Mar 2017 17:25:34 - 1.51
> +++ config.c 30 Mar 2017 10:03:42 -
> @@ -326,6 +326,28 @@ config_settls(struct httpd *env, struct
> }
> }
>
> + if (srv_conf->tls_ca_len != 0) {
> + DPRINTF("%s: sending ca cert(s) for \"%s[%u]\" to %s fd %d",
> + __func__, srv_conf->name, srv_conf_id,
> + ps->ps_title[PROC_SERVER], srv->srv_s);
> +
> + memset(, 0, sizeof(tls));
> + tls.id = srv_conf->id;
> + tls.tls_ca_len = srv_conf->tls_ca_len;
> +
> + c = 0;
> + iov[c].iov_base =
> + iov[c++].iov_len = sizeof(tls);
> + iov[c].iov_base = srv_conf->tls_ca;
> + iov[c++].iov_len = srv_conf->tls_ca_len;
> +
> + if (proc_composev(ps, PROC_SERVER, IMSG_CFG_TLS, iov, c) != 0) {
> + log_warn("%s: failed to compose IMSG_CFG_TLS imsg for "
> + "`%s'", __func__, srv_conf->name);
> + return (-1);
> + }
> + }
> +
> return (0);
> }
>
> @@ -644,6 +666,13 @@ config_gettls(struct httpd *env, struct
> tls_conf.tls_ocsp_staple_len)) == NULL)
> goto fail;
> s += tls_conf.tls_ocsp_staple_len;
> + }
> + if (tls_conf.tls_ca_len != 0) {
> + srv_conf->tls_ca_len = tls_conf.tls_ca_len;
> + if ((srv_conf->tls_ca = get_data(p + s,
> + tls_conf.tls_ca_len)) == NULL)
> + goto fail;
> + s += tls_conf.tls_ca_len;
> }
>
> return (0);
> Index: httpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> retrieving revision 1.81
> diff -u -p -r1.81 httpd.conf.5
> --- httpd.conf.5 25 Mar 2017 17:25:34 - 1.81
> +++ httpd.conf.5 30 Mar 2017 10:03:43 -
> @@ -342,6 +342,18 @@ The revision of the HTTP specification u
> .It Ic SERVER_SOFTWARE
> The server software name of
> .Xr httpd 8 .
> +.It Ic TLS_PEER_EXPIRES
> +The time at which the TLS client certificate, if any, expires,
> +in seconds since the epoch.
> +.It Ic TLS_PEER_HASH
> +A hash of the TLS client certificate, if any. See
> +.Xr
fix: cy(4) debug format strings
Hi,
the kernel does not compile with option CY_DEBUG because of several
format string mistakes. This diff fixes them. It compiles on i386
and amd64 without any errors.
bye,
Jan
Index: cy.c
===
RCS file: /cvs/openbsd/src/sys/dev/ic/cy.c,v
retrieving revision 1.35
diff -u -p -r1.35 cy.c
--- cy.c31 Oct 2014 09:45:27 - 1.35
+++ cy.c1 Feb 2017 10:09:05 -
@@ -116,7 +116,7 @@ cy_probe_common(bus_space_tag_t memt, bu
chip_offs -= (CY32_ADDR_FIX << bustype);
#ifdef CY_DEBUG
- printf("cy: probe chip %d offset 0x%lx ... ",
+ printf("cy: probe chip %d offset 0x%x ... ",
cy_chip, chip_offs);
#endif
@@ -446,7 +446,7 @@ cyread(dev, uio, flag)
struct tty *tp = cy->cy_tty;
#ifdef CY_DEBUG
- printf("%s read port %d uio 0x%x flag 0x%x\n", sc->sc_dev.dv_xname,
+ printf("%s read port %d uio %p flag 0x%x\n", sc->sc_dev.dv_xname,
port, uio, flag);
#endif
@@ -469,7 +469,7 @@ cywrite(dev, uio, flag)
struct tty *tp = cy->cy_tty;
#ifdef CY_DEBUG
- printf("%s write port %d uio 0x%x flag 0x%x\n", sc->sc_dev.dv_xname,
+ printf("%s write port %d uio %p flag 0x%x\n", sc->sc_dev.dv_xname,
port, uio, flag);
#endif
@@ -511,7 +511,7 @@ cyioctl(dev, cmd, data, flag, p)
int error;
#ifdef CY_DEBUG
- printf("%s port %d ioctl cmd 0x%x data 0x%x flag 0x%x\n",
+ printf("%s port %d ioctl cmd 0x%lx data %p flag 0x%x\n",
sc->sc_dev.dv_xname, port, cmd, data, flag);
#endif
@@ -596,7 +596,7 @@ cystart(tp)
int s;
#ifdef CY_DEBUG
- printf("%s port %d start, tty 0x%x\n", sc->sc_dev.dv_xname, port, tp);
+ printf("%s port %d start, tty %p\n", sc->sc_dev.dv_xname, port, tp);
#endif
s = spltty();
@@ -633,7 +633,7 @@ cystop(tp, flag)
int s;
#ifdef CY_DEBUG
- printf("%s port %d stop tty 0x%x flag 0x%x\n", sc->sc_dev.dv_xname,
+ printf("%s port %d stop tty %p flag 0x%x\n", sc->sc_dev.dv_xname,
port, tp, flag);
#endif
@@ -670,7 +670,7 @@ cyparam(tp, t)
int s, opt;
#ifdef CY_DEBUG
- printf("%s port %d param tty 0x%x termios 0x%x\n", sc->sc_dev.dv_xname,
+ printf("%s port %d param tty %p termios %p\n", sc->sc_dev.dv_xname,
port, tp, t);
printf("ispeed %d ospeed %d\n", t->c_ispeed, t->c_ospeed);
#endif
@@ -1363,7 +1363,7 @@ cd1400_channel_cmd(cy, cmd)
u_int waitcnt = 5 * 8 * 1024; /* approx 5 ms */
#ifdef CY_DEBUG
- printf("c1400_channel_cmd cy 0x%x command 0x%x\n", cy, cmd);
+ printf("c1400_channel_cmd cy %p command 0x%x\n", cy, cmd);
#endif
/* wait until cd1400 is ready to process a new command */
