Re: uniq(1): support arbitrarily long lines
On 2021/11/01 10:36, Scott Cheloha wrote:
> How did you generate this input? Is it just ten million lines with a
> single 'z' character? `jot -bz 1000`?
That one was lots of copies of ports/infrastructure/bsd.port.mk catted together.
> Updated patch.
>
> I screwed up. We don't need to free(3) prevline when we print a line.
> We can just swap the pointers (and now, sizes) as we did before and
> let getline(3) handle reallocation.
Aha! That's a lot better and restores performance to how it was before.
On a different machine so times aren't directly comparable with the
previous, but:
$ hyperfine 'uniq /tmp/z' 'obj/uniq /tmp/z'
Benchmark 1: uniq /tmp/z
Time (mean ± σ): 2.564 s ± 0.105 s[User: 2.380 s, System: 0.173 s]
Range (min … max):2.423 s … 2.748 s10 runs
Benchmark 2: obj/uniq /tmp/z
Time (mean ± σ): 2.575 s ± 0.141 s[User: 2.350 s, System: 0.214 s]
Range (min … max):2.478 s … 2.940 s10 runs
Summary
'uniq /tmp/z' ran
1.00 ± 0.07 times faster than 'obj/uniq /tmp/z'
Which I think is pretty much a noop in terms of time.
OK sthen@
> Index: uniq.c
> ===
> RCS file: /cvs/src/usr.bin/uniq/uniq.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 uniq.c
> --- uniq.c31 Jul 2018 02:55:57 - 1.27
> +++ uniq.c1 Nov 2021 15:30:55 -
> @@ -45,8 +45,6 @@
> #include
> #include
>
> -#define MAXLINELEN (8 * 1024)
> -
> int cflag, dflag, iflag, uflag;
> int numchars, numfields, repeats;
>
> @@ -59,10 +57,10 @@ __dead void usage(void);
> int
> main(int argc, char *argv[])
> {
> - char *t1, *t2;
> + char *prevline, *t1, *t2, *thisline;
> FILE *ifp = NULL, *ofp = NULL;
> + size_t prevsize, thissize, tmpsize;
> int ch;
> - char *prevline, *thisline;
>
> setlocale(LC_CTYPE, "");
>
> @@ -133,15 +131,18 @@ main(int argc, char *argv[])
> if (pledge("stdio", NULL) == -1)
> err(1, "pledge");
>
> - prevline = malloc(MAXLINELEN);
> - thisline = malloc(MAXLINELEN);
> - if (prevline == NULL || thisline == NULL)
> - err(1, "malloc");
> -
> - if (fgets(prevline, MAXLINELEN, ifp) == NULL)
> + prevline = NULL;
> + prevsize = 0;
> + if (getline(&prevline, &prevsize, ifp) == -1) {
> + free(prevline);
> + if (ferror(ifp))
> + err(1, "getline");
> exit(0);
> -
> - while (fgets(thisline, MAXLINELEN, ifp)) {
> + }
> +
> + thisline = NULL;
> + thissize = 0;
> + while (getline(&thisline, &thissize, ifp) != -1) {
> /* If requested get the chosen fields + character offsets. */
> if (numfields || numchars) {
> t1 = skip(thisline);
> @@ -157,11 +158,20 @@ main(int argc, char *argv[])
> t1 = prevline;
> prevline = thisline;
> thisline = t1;
> + tmpsize = prevsize;
> + prevsize = thissize;
> + thissize = tmpsize;
> repeats = 0;
> } else
> ++repeats;
> }
> + free(thisline);
> + if (ferror(ifp))
> + err(1, "getline");
> +
> show(ofp, prevline);
> + free(prevline);
> +
> exit(0);
> }
>
>
ospfd/ospf6d, interfaces in log messages
I've recently started seeing a number of flaps with ospfd/ospf6d
with invalid seq nums / "seq num mismatch, bad flags" logged.
Not quite sure what's going yet as they must be occurring on
various local switched segments on one nic and also on ethernet
wan circuits direct to router on a separate pcie nic, anyway
it's made it clear that very few of the log messages relating
to neighbours identify which interface is involved.
I don't know if it makes sense to commit or not, but there's a
diff below adding the interface wherever the neighbour ID is logged
if anyone's interested (same changes to both ospfd and ospf6d).
Nov 2 11:29:30 ospfd[78532]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 20d22487 his 20d22485
Nov 2 11:29:30 ospf6d[89545]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 4cabc5c1 his 4cabc5c0
Nov 2 11:29:34 ospf6d[89545]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine 98360a5 his 98360a4
Nov 2 11:29:34 ospfd[78532]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine f708c646 his f708c645
Nov 2 11:29:38 ospfd[78532]: recv_db_description: neighbor ID xx.11:
invalid seq num, mine e4068bcc his e4068bcb
Nov 2 11:30:06 ospf6d[89545]: recv_db_description: neighbor ID xx.3:
seq num mismatch, bad flags
Nov 2 11:30:14 ospf6d[89545]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine 98360ae his 98360ad
Nov 2 11:30:14 ospfd[78532]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine f708c64f his f708c64e
Nov 2 11:30:22 ospfd[78532]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 20d22493 his 20d22490
Nov 2 11:30:22 ospfd[78532]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 20d22493 his 20d22492
Nov 2 11:30:39 ospfd[78532]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 20d2249c his 20d2249b
Nov 2 11:30:59 ospf6d[89545]: recv_db_description: neighbor ID xx.11:
seq num mismatch, bad flags
Nov 2 11:30:59 ospfd[78532]: recv_db_description: neighbor ID xx.11:
seq num mismatch, bad flags
Nov 2 11:31:09 ospfd[78532]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine f708c65c his f708c65b
Index: ospf6d/database.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/database.c,v
retrieving revision 1.20
diff -u -p -r1.20 database.c
--- ospf6d/database.c 15 Jul 2020 14:47:41 - 1.20
+++ ospf6d/database.c 2 Nov 2021 17:11:38 -
@@ -60,9 +60,9 @@ send_db_description(struct nbr *nbr)
case NBR_STA_INIT:
case NBR_STA_2_WAY:
case NBR_STA_SNAP:
- log_debug("send_db_description: neighbor ID %s: "
+ log_debug("send_db_description: neighbor ID %s (%s): "
"cannot send packet in state %s", inet_ntoa(nbr->id),
- nbr_state_name(nbr->state));
+ nbr->iface->name, nbr_state_name(nbr->state));
goto fail;
case NBR_STA_XSTRT:
bits |= OSPF_DBD_MS | OSPF_DBD_M | OSPF_DBD_I;
@@ -160,8 +160,8 @@ recv_db_description(struct nbr *nbr, cha
int dupe = 0;
if (len < sizeof(dd_hdr)) {
- log_warnx("recv_db_description: neighbor ID %s: "
- "bad packet size", inet_ntoa(nbr->id));
+ log_warnx("recv_db_description: neighbor ID %s (%s): "
+ "bad packet size", inet_ntoa(nbr->id), nbr->iface->name);
return;
}
memcpy(&dd_hdr, buf, sizeof(dd_hdr));
@@ -170,9 +170,10 @@ recv_db_description(struct nbr *nbr, cha
/* db description packet sanity checks */
if (ntohs(dd_hdr.iface_mtu) > nbr->iface->mtu) {
- log_warnx("recv_db_description: neighbor ID %s: "
+ log_warnx("recv_db_description: neighbor ID %s (%s): "
"invalid MTU %d expected %d", inet_ntoa(nbr->id),
- ntohs(dd_hdr.iface_mtu), nbr->iface->mtu);
+ nbr->iface->name, ntohs(dd_hdr.iface_mtu),
+ nbr->iface->mtu);
return;
}
@@ -180,8 +181,9 @@ recv_db_description(struct nbr *nbr, cha
nbr->last_rx_bits == dd_hdr.bits &&
ntohl(dd_hdr.dd_seq_num) == nbr->dd_seq_num - nbr->dd_master ?
1 : 0) {
- log_debug("recv_db_description: dupe from neighbor ID %s",
- inet_ntoa(nbr->id));
+ log_debug("recv_db_description: dupe from "
+ "neighbor ID %s (%s)", inet_ntoa(nbr->id),
+ nbr->iface->name);
dupe = 1;
}
@@ -190,9 +192,9 @@ recv_db_description(struct nbr *nbr, cha
case NBR_STA_ATTEMPT:
case NBR_STA_2_WAY:
case NBR_STA_SNAP:
- log_debug("recv_db_description: neighbor ID %s:
Re: ifconfig: zap dead code
On 2021/11/02 23:47, Klemens Nanni wrote:
> No idea what it was supposed to do back then; cvs blame points at
ha, that's Jason's username for various places
it's obviously not needed, but it's tempting to keep it for historical
interest!
> OK?
>
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.447
> diff -u -p -r1.447 ifconfig.c
> --- ifconfig.c2 Nov 2021 23:39:27 - 1.447
> +++ ifconfig.c2 Nov 2021 23:46:28 -
> @@ -411,11 +411,6 @@ const struct cmd {
> { "alias", IFF_UP, 0, notealias },
> { "-alias", -IFF_UP,0, notealias },
> { "delete", -IFF_UP,0, notealias },
> -#ifdef notdef
> -#define EN_SWABIPS 0x1000
> - { "swabips",EN_SWABIPS, 0, setifflags },
> - { "-swabips", -EN_SWABIPS,0, setifflags },
> -#endif /* notdef */
> { "netmask",NEXTARG,0, setifnetmask },
> { "mtu",NEXTARG,0, setifmtu },
> { "nwid", NEXTARG,0, setifnwid },
>
Re: New hw.perfpolicy behavior
On 2021/11/03 16:46, Damien Miller wrote: > On Tue, 2 Nov 2021, Theo de Raadt wrote: > > > Paul de Weerd wrote: > > > > > A recent commit by Theo changed the hw.perfpolicy behavior to always > > > run at full speed when AC power is on. This means that my workstation > > > (and servers, once I upgrade them) now consumes significantly more > > > power, even though they usually idle. > > > > Did you measure how much more power? > > > > You must measure, to make such a claim. > > > > Your OptiPlex 9020 is probably a modern i5/i7, which probably contains > > C states similar to this: > > > > acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > > > > Which means when the idle loop calls the "mwait" instruction, the cpu > > will 'instantly' slow down to a lower clock and make other power use > > reductions, until an interrupt happens and requires labour again. > > See also https://en.wikichip.org/wiki/race-to-sleep - it's generally > more energy efficient to run the CPU at full speed so it can finish its > work faster and get back to a low-power state sooner So there's not really any point in doing this scaling on laptops either then, and it could be counterproductive? Would it actually be better for the decision to be "has mwait or an alternative mechanism on other arches" and only if that's absent consider whether it has ac power?
Re: New hw.perfpolicy behavior
On 2021/11/03 05:47, Crystal Kolipe wrote: > > Your OptiPlex 9020 is probably a modern i5/i7, which probably contains > > C states similar to this: > > > > acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > > > > Which means when the idle loop calls the "mwait" instruction, the cpu > > will 'instantly' slow down to a lower clock and make other power use > > reductions, until an interrupt happens and requires labour again. > > This high frequcency cycling causes detectable (*) RF noise. In the vast > majority of cases this shouldn't be an issue, but it seems worth noting > just in case we start seeing bug reports of humming on speakers once > this change sees it's way into the next release and more people are > exposed to it. using mwait is a years-old change
Re: [patch] httpd static gzip compression
On 2021/11/04 14:21, prx wrote: > Hello, > The attached patch add support for static gzip compression. > > In other words, if a client support gzip compression, when "file" is > requested, httpd will check if "file.gz" is avaiable to serve. > > Regards. > > prx btw this was rejected before, https://github.com/reyk/httpd/issues/21
Re: [patch] httpd static gzip compression
On 2021/11/04 08:27, Theo de Raadt wrote: > prx wrote: > > > * Stuart Henderson le [04-11-2021 14:09:39 +]: > > > On 2021/11/04 14:21, prx wrote: > > > > Hello, > > > > The attached patch add support for static gzip compression. > > > > > > > > In other words, if a client support gzip compression, when "file" is > > > > requested, httpd will check if "file.gz" is avaiable to serve. > > > > > > > > Regards. > > > > > > > > prx > > > > > > btw this was rejected before, > > > > > > https://github.com/reyk/httpd/issues/21 > > > > > > > This diff doesn't compress "on the fly". > > It's up to the webmaster to compress files **before** serving them. In some ways it would be better if it *did* compress on the fly, as then you don't have so much to consider with the effect on block/match rules, whether a request is passed to a fastcgi handler, etc. (But of course then you have CPU use issues). Not sure if it's still actually needed, but most web servers with gzip support usually have a way to disable it per user-agent due to problems that have occurred. > Does any other program work this way? > > Where you request one filename, and it gives you another? Some of the webservers do, for language selection etc. Sometimes it's useful. Fortunately there are various options for more fully featured web servers if people need that, if I understand correctly the whole point of httpd was that it doesn't have many features. > I have a difficult time understanding why gzip has to sneak it's way > into everything. > > I always prefer software that does precisely what I expect it to do. >
Re: ftp: Print actually requested URLs
On 2021/11/06 17:29, Klemens Nanni wrote: > Encoding URL paths changes the requested URL and therefore may yield > different responses (opposed to an unencoded URL), solely depending on > how the server implements de/encoding. Makes sense as this matches what various other tools that fetch URLs do for printing. Or another approach would be to not output the URL at all (it's still visible with -d).
net.inet6.icmp6.nd6_debug and RDNSS
net.inet6.icmp6.nd6_debug is fairly noisy if you advertise nameservers, OK to silence those warnings? Nov 7 00:45:34 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 04:26:22 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 04:26:26 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 04:31:10 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 06:04:41 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 08:57:05 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 10:48:36 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:02:51 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:08:21 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:09:57 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:11:41 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Nov 7 12:15:48 bamboo /bsd: nd6_options: unsupported option 25 - option ignored Index: netinet6/nd6.c === RCS file: /cvs/src/sys/netinet6/nd6.c,v retrieving revision 1.235 diff -u -p -r1.235 nd6.c --- netinet6/nd6.c 8 Mar 2021 16:49:07 - 1.235 +++ netinet6/nd6.c 7 Nov 2021 12:24:03 - @@ -271,6 +271,10 @@ nd6_options(union nd_opts *ndopts) ndopts->nd_opts_pi_end = (struct nd_opt_prefix_info *)nd_opt; break; + case ND_OPT_DNSSL: + case ND_OPT_RDNSS: + /* Don't warn */ + break; default: /* * Unknown options must be silently ignored,
Re: sppp(4)/pppoe(4) - DNS configuration via resolvd(8)
On 2021/11/08 15:50, Klemens Nanni wrote: > With this diff pppoe(4) sends two nameservers and thus wins, but that is > expected and setups such as mine must either > - disable resolvd > - enable resolvd but also enable unwind > (unwind also learns DNS proposals but always wins in resolv.conf) > - enable resolvd and clear pppoe(4) proposals, > e.g. `route nameserver pppoe0' > - do whatever else fits their setup This is already a problem though having additional sources of nameserver addresses does mean that more people will run into it. Most resolvers handed out by ISPs or on local networks are only reachable from (or at least only give valid responses to) IPs on the expected network; that's OK when the nameserver is in the same subnet as the client (typical home ISP router config) but otherwise it's not (you do get to learn how very quick resolvd is at changing the file back to what it wants though!). Feels like maybe it should only add a resolver if it's either on a directly-connected interface or there's a route for the ns address pointing at the interface that the ns was learned from. Though there's an extra complication if you have multiple route tables..
Re: smtpd smtp_proceed_wiz function
On 2021/11/08 14:52, Crystal Kolipe wrote:
> src/usr.sbin/smtpd/smtp_session.c contains the following code:
>
> 1892static void
> 1893smtp_proceed_wiz(struct smtp_session *s, const char *args)
> 1894{
> 1895smtp_reply(s, "500 %s %s: this feature is not supported
> yet ;-)",
> 1896esc_code(ESC_STATUS_PERMFAIL, ESC_INVALID_COMMAND),
> 1897esc_description(ESC_INVALID_COMMAND));
> 1898}
>
> This was added between revisions 1.194 and 1.195, with no mention in the
> changelog.
>
> I'm not aware of a 'wiz' command in any SMTP related RFC.
>
> Is this spurious debugging code related to the addition of DSN and enhanced
> status code support? Or is it there as a way to identify servers that are
> running smtpd in the wild? Or is there some other reason?
>
This will become clear if you look into sendmail history :)
Re: relayd regress tcp performance
What's the status of this diff?
On 2021/09/21 17:30, Alexander Bluhm wrote:
> On Sat, Sep 18, 2021 at 02:35:20PM +0200, Jan Klemkow wrote:
> > The following diff removes the every 2nd ACK feature again and ensures
> > that we send out an ACK if soreceive() empties the receive buffer.
>
> Looks good in my perform tests, 22% tcp throughput increase.
>
> http://bluhm.genua.de/perform/results/2021-09-20T11:05:31Z/perform.html
> http://bluhm.genua.de/perform/results/2021-09-20T11:05:31Z/gnuplot/tcp.html
>
> > We are so close to 7.0, that I would suggest to commit this after the
> > release. Thus, we don't risk another last minute regression.
> >
> > OK?
>
> OK bluhm@ post 7.0
>
> > Index: netinet/tcp_input.c
> > ===
> > RCS file: /cvs/src/sys/netinet/tcp_input.c,v
> > retrieving revision 1.370
> > diff -u -p -r1.370 tcp_input.c
> > --- netinet/tcp_input.c 9 Aug 2021 17:03:08 - 1.370
> > +++ netinet/tcp_input.c 18 Sep 2021 07:53:45 -
> > @@ -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 \
> > Index: netinet/tcp_usrreq.c
> > ===
> > RCS file: /cvs/src/sys/netinet/tcp_usrreq.c,v
> > retrieving revision 1.181
> > diff -u -p -r1.181 tcp_usrreq.c
> > --- netinet/tcp_usrreq.c30 Apr 2021 13:52:48 - 1.181
> > +++ netinet/tcp_usrreq.c18 Sep 2021 07:53:45 -
> > @@ -329,8 +329,15 @@ tcp_usrreq(struct socket *so, int req, s
> > * template for a listening socket and hence the kernel
> > * will panic.
> > */
> > - if ((so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) != 0)
> > + if ((so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING)) != 0) {
> > + /*
> > +* If soreceive() empty the receive buffer, we have to
> > +* send a window update.
> > +*/
> > + if (so->so_rcv.sb_cc == 0)
> > + tp->t_flags |= TF_ACKNOW;
> > (void) tcp_output(tp);
> > + }
> > break;
> >
> > /*
>
Re: add 802.11n 40MHz support to iwn(4)
On 2021/11/09 20:38, Jan Stary wrote: > On Nov 09 00:36:03, h...@stare.cz wrote: > > As a naive test of speed, I am downloading a 100MB file > > from a http server just behind the AP with > > ftp -o /dev/null http://stare.cz/.tmp/file > > An average of ten runs is 5.31 MB/s without the diff > > and 3.37 MB/s with the (updated) diff. > > Any idea how enabling 40 MHz could slow it down? > > Jan > One possibility is interference in the extended part of the channel that isn't present in the basic 20MHz.
Re: [PATCH] [src] share/man/man5/hostname.if.5 - nwid -> join
On 2021/11/11 16:30, Klemens Nanni wrote: > On Thu, Nov 11, 2021 at 04:11:10PM +, Raf Czlonka wrote: > > Hello, > > > > It seems like this has been missed in recent thread[0]. > > > > Not entirely sure whether the sentence "flows" any longer but here > > it goes anyway. > > > > [0] https://marc.info/?l=openbsd-tech&m=163507448118443&w=2 > > Thanks, I missed that! > > > Index: share/man/man5/hostname.if.5 > > === > > RCS file: /cvs/src/share/man/man5/hostname.if.5,v > > retrieving revision 1.77 > > diff -u -p -r1.77 hostname.if.5 > > --- share/man/man5/hostname.if.517 Jul 2021 15:28:31 - 1.77 > > +++ share/man/man5/hostname.if.511 Nov 2021 16:09:33 - > > @@ -67,13 +67,13 @@ inet 10.0.0.1 255.255.255.0 10.0.0.255 d > > Each line is processed separately and in order. > > For example: > > .Bd -literal -offset indent > > -nwid mynwid wpakey mywpakey > > +join mynwid wpakey mywpakey > > inet6 autoconf > > inet autoconf > > .Ed > > .Pp > > would run ifconfig three times to set the > > -.Cm nwid > > +.Cm join > > and > > .Cm wpakey > > of the interface, > > Maybe this reads better in general? > > would run ifconfig three times to join a wireless network using WPA and > to set the AUTOCONF6 and AUTOCONF4 flags, respectively. It is more "add a network to the join list", join implies that it's connecting directly to that ssid (i.e. what "nwid" did). > No need to explain lines command by command. Keep it simple; users > must read ifconfig(8) anyway. > > One might as well say to > > ... and > to enable automatic address configuration for IPv6 and IPv4, respectively. > > Then we don't have the weird mix of conceptual words and technical bits, > i.e. "connect to wifi" vs. "set if flags [they're picked up by network > daemons, but we don't say which ones]". > > DYNAMIC ADDRESS CONFIGURATION down below repeats all this, anyway. > > Feedback? OK? > > > Index: hostname.if.5 > === > RCS file: /cvs/src/share/man/man5/hostname.if.5,v > retrieving revision 1.77 > diff -u -p -r1.77 hostname.if.5 > --- hostname.if.5 17 Jul 2021 15:28:31 - 1.77 > +++ hostname.if.5 11 Nov 2021 16:30:00 - > @@ -67,21 +67,15 @@ inet 10.0.0.1 255.255.255.0 10.0.0.255 d > Each line is processed separately and in order. > For example: > .Bd -literal -offset indent > -nwid mynwid wpakey mywpakey > +join mynwid wpakey mywpakey > inet6 autoconf > inet autoconf > .Ed > .Pp > -would run ifconfig three times to set the > -.Cm nwid > -and > -.Cm wpakey > -of the interface, > -the > -.Sy AUTOCONF6 > -flag and the > -.Sy AUTOCONF4 > -flag, respectively. > +would run ifconfig three times to > +.Cm join > +a wireless network using WPA > +and enable dynamic address configuration, respectively. > .Sh STATIC ADDRESS CONFIGURATION > The following packed formats are valid for configuring network > interfaces with static addresses. >
Re: snmpd: tweak listen on
On 2021/08/09 20:55, Martijn van Duren wrote: > On Mon, 2021-08-09 at 11:57 +0200, Martijn van Duren wrote: > > > > This diff fixes all of the above: > > - Allow any to be used resolving to 0.0.0.0 and :: > > - Set SO_REUSEADDR on sockets, so we can listen on both any and > > localhost > > - Document that we listen on any by default I've discovered a problem with this, if you have "family inet4" or "family inet6" in resolv.conf then startup fails, either with the implicit listen: snmpd: Unexpected resolving of :: or with explicit e.g. "listen on any snmpv3": /etc/snmpd.conf:3: invalid address: any Config-based workaround is e.g. "listen on 0.0.0.0 snmpv3" Should host() use a specific ai_family instead of PF_UNSPEC where we already know that it's a v4 or v6 address? Or just do like httpd/parse.y where host() tries v4, then v6 if that fails, then dns?
Re: IPsec tdb ref counting
On 2021/11/13 18:04, Alexander Bluhm wrote:
> Hi,
>
> To make IPsec MP safe we need refcounting for the tdb. The diff
> below is part of something bigger we have at genua. Although it
> does not cover timeouts and the tdb reaper yet, I want to get this
> in as a frist step.
>
> It passes regress but there are setups that are not covered. Bridge
> and pfsync with IPsec and TCP signature need special care.
>
> When testing, please check for tdb leaks. The vmstat -m tdb in use
> culumn must be 0. It it is not, try ipsecctl -F. If ipsecctl -sa
> shows nothing, but vmstat -m shows a used tdb, then it is a bug.
>
> NameSize Requests FailInUse Pgreq Pgrel Npage Hiwat Minpg Maxpg
> Idle
> tdb 904 5600 7 7 0 7 0 8
> 0
Tested with a box running isakmpd at home. Config is:
isakmpd_flags=-Kv -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30
-D10=20
ike passive esp \
from xxx.xx.xxx.1 (xxx.xx.xxx.0/27) to 0.0.0.0/0 \
local xxx.xx.xxx.1 \
main auth hmac-sha2-256 enc aes group ecp256 \
quick enc aes-128-gcm group ecp256 \
srcid xxx
isakmpd starts at boot, 3 devices connect in and tunnels come up,
FLOWS and SAD show in ipsecctl -sa.
isakmpd crashes shortly after starting (as described in previous mails;
this is not new, it happens very often on the first start at boot),
FLOWS and SAD remain showing. At this point they still show InUse:
NameSize Requests FailInUse Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle
tdb 1088906 1 0 1 1 0 80
After ipsecctl -F they are freed:
tdb 1088900 1 0 1 1 0 81
Restart isakmpd, ipsecctl -f /etc/ipsec.conf, devices connect back in:
tdb 1088 1806 2 1 1 1 0 80
(And at this point isakmpd is usually stable).
I will leave a shell loop running vmstat -m every few minutes to check
if it grows.
(Bad timing for testing TCPMD5 because over the last couple of days I have
just removed bgpd+ospfd from the machines that would have been good
choices to run test diffs..I might be able to get some simple setup
back up and running though)
>
> ok?
>
> bluhm
>
> Index: net/if_bridge.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_bridge.c,v
> retrieving revision 1.358
> diff -u -p -r1.358 if_bridge.c
> --- net/if_bridge.c 11 Nov 2021 18:08:17 - 1.358
> +++ net/if_bridge.c 11 Nov 2021 23:24:31 -
> @@ -1577,10 +1577,12 @@ bridge_ipsec(struct ifnet *ifp, struct e
>
> prot = (*(tdb->tdb_xform->xf_input))(&m, tdb, hlen,
> off);
> + tdb_unref(tdb);
> if (prot != IPPROTO_DONE)
> ip_deliver(&m, &hlen, prot, af);
> return (1);
> } else {
> + tdb_unref(tdb);
> skiplookup:
> /* XXX do an input policy lookup */
> return (0);
> Index: net/if_pfsync.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_pfsync.c,v
> retrieving revision 1.298
> diff -u -p -r1.298 if_pfsync.c
> --- net/if_pfsync.c 11 Nov 2021 12:35:01 - 1.298
> +++ net/if_pfsync.c 11 Nov 2021 23:24:31 -
> @@ -1325,11 +1325,13 @@ pfsync_update_net_tdb(struct pfsync_tdb
> /* Neither replay nor byte counter should ever decrease. */
> if (pt->rpl < tdb->tdb_rpl ||
> pt->cur_bytes < tdb->tdb_cur_bytes) {
> + tdb_unref(tdb);
> goto bad;
> }
>
> tdb->tdb_rpl = pt->rpl;
> tdb->tdb_cur_bytes = pt->cur_bytes;
> + tdb_unref(tdb);
> }
> return;
>
> Index: net/pfkeyv2.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pfkeyv2.c,v
> retrieving revision 1.221
> diff -u -p -r1.221 pfkeyv2.c
> --- net/pfkeyv2.c 25 Oct 2021 18:25:01 - 1.221
> +++ net/pfkeyv2.c 12 Nov 2021 21:03:45 -
> @@ -1044,7 +1044,8 @@ pfkeyv2_sa_flush(struct tdb *tdb, void *
> if (!(*((u_int8_t *) satype_vp)) ||
> tdb->tdb_satype == *((u_int8_t *) satype_vp)) {
> tdb_unlink_locked(tdb);
> - tdb_free(tdb);
> + tdb_unbundle(tdb);
> + tdb_unref(tdb);
> }
> return (0);
> }
> @@ -1327,7 +1328,7 @@ pfkeyv2_send(struct socket *so, void *me
>
> if ((rval = pfkeyv2_get_proto_alg(newsa->tdb_satype,
> &newsa->tdb_sproto, &alg))) {
> - tdb_free(freeme);
> + tdb_unref(freeme);
>
Re: IPsec tdb ref counting
On 2021/11/13 21:49, Stuart Henderson wrote: > On 2021/11/13 18:04, Alexander Bluhm wrote: > > Hi, > > > > To make IPsec MP safe we need refcounting for the tdb. The diff > > below is part of something bigger we have at genua. Although it > > does not cover timeouts and the tdb reaper yet, I want to get this > > in as a frist step. > > > > It passes regress but there are setups that are not covered. Bridge > > and pfsync with IPsec and TCP signature need special care. > > > > When testing, please check for tdb leaks. The vmstat -m tdb in use > > culumn must be 0. It it is not, try ipsecctl -F. If ipsecctl -sa > > shows nothing, but vmstat -m shows a used tdb, then it is a bug. > > > > NameSize Requests FailInUse Pgreq Pgrel Npage Hiwat Minpg Maxpg > > Idle > > tdb 904 5600 7 7 0 7 0 8 > >0 > > Tested with a box running isakmpd at home. Config is: > > isakmpd_flags=-Kv -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30 > -D10=20 > > ike passive esp \ > from xxx.xx.xxx.1 (xxx.xx.xxx.0/27) to 0.0.0.0/0 \ > local xxx.xx.xxx.1 \ > main auth hmac-sha2-256 enc aes group ecp256 \ > quick enc aes-128-gcm group ecp256 \ > srcid xxx > > isakmpd starts at boot, 3 devices connect in and tunnels come up, > FLOWS and SAD show in ipsecctl -sa. > > isakmpd crashes shortly after starting (as described in previous mails; > this is not new, it happens very often on the first start at boot), > FLOWS and SAD remain showing. At this point they still show InUse: > > NameSize Requests FailInUse Pgreq Pgrel Npage Hiwat Minpg Maxpg > Idle > tdb 1088906 1 0 1 1 0 8 > 0 > > After ipsecctl -F they are freed: > > tdb 1088900 1 0 1 1 0 8 > 1 > > Restart isakmpd, ipsecctl -f /etc/ipsec.conf, devices connect back in: > > tdb 1088 1806 2 1 1 1 0 8 > 0 > > (And at this point isakmpd is usually stable). > > I will leave a shell loop running vmstat -m every few minutes to check > if it grows. > > (Bad timing for testing TCPMD5 because over the last couple of days I have > just removed bgpd+ospfd from the machines that would have been good > choices to run test diffs..I might be able to get some simple setup > back up and running though) Ah, that was interesting: Sat Nov 13 21:44:17 GMT 2021 tdb 1088 1806 2 1 1 1 0 80 Sat Nov 13 21:54:44 GMT 2021 tdb 1088 1806 2 1 1 1 0 80 Sat Nov 13 22:04:44 GMT 2021 tdb 1088 270 12 2 1 1 1 0 80 and then shortly after, boom. Unfortunately I didn't get much from ddb before it hanged after I tried changing cpu. [playback] Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7b2d20, count: 248 End of stack trace. splassert: tdb_free: want 2 have 0 Starting stack trace... tdb_free(80f40b88) at tdb_free+0x47 pfkeyv2_send(fd80603603b8,80f44c00,170) at pfkeyv2_send+0x656 pfkeyv2_output(fd8064cb5e00,fd80603603b8,0,0) at pfkeyv2_output+0x8a pfkeyv2_usrreq(fd80603603b8,9,fd8064cb5e00,0,0,80009508) at pfkeyv2_usrreq+0x1b0 sosend(fd80603603b8,0,80001fd8f6f0,0,0,0) at sosend+0x3a9 dofilewritev(80009508,7,80001fd8f6f0,0,80001fd8f7f0) at dofilewritev+0x14d sys_writev(80009508,80001fd8f790,80001fd8f7f0) at sys_writev+0xd2 syscall(80001fd8f860) at syscall+0x3a9 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7b2d20, count: 248 End of stack trace. splassert: tdb_free: want 2 have 0 Starting stack trace... tdb_free(80f40308) at tdb_free+0x47 pfkeyv2_send(fd80603603b8,80eff300,50) at pfkeyv2_send+0x656 pfkeyv2_output(fd8062506e00,fd80603603b8,0,0) at pfkeyv2_output+0x8a pfkeyv2_usrreq(fd80603603b8,9,fd8062506e00,0,0,80009508) at pfkeyv2_usrreq+0x1b0 sosend(fd80603603b8,0,80001fd8f6f0,0,0,0) at sosend+0x3a9 dofilewritev(80009508,7,80001fd8f6f0,0,80001fd8f7f0) at dofilewritev+0x14d sys_writev(80009508,80001fd8f790,80001fd8f7f0) at sys_writev+0xd2 syscall(80001fd8f860) at syscall+0x3a9 Xsyscall() at Xsyscall+0x128 en
Re: IPsec tdb ref counting
On 2021/11/13 22:41, Stuart Henderson wrote: > On 2021/11/13 21:49, Stuart Henderson wrote: > > On 2021/11/13 18:04, Alexander Bluhm wrote: > > > Hi, > > > > > > To make IPsec MP safe we need refcounting for the tdb. The diff > > > below is part of something bigger we have at genua. Although it > > > does not cover timeouts and the tdb reaper yet, I want to get this > > > in as a frist step. > > > > > > It passes regress but there are setups that are not covered. Bridge > > > and pfsync with IPsec and TCP signature need special care. > > > > > > When testing, please check for tdb leaks. The vmstat -m tdb in use > > > culumn must be 0. It it is not, try ipsecctl -F. If ipsecctl -sa > > > shows nothing, but vmstat -m shows a used tdb, then it is a bug. > > > > > > NameSize Requests FailInUse Pgreq Pgrel Npage Hiwat Minpg > > > Maxpg Idle > > > tdb 904 5600 7 7 0 7 0 > > > 80 > > > > Tested with a box running isakmpd at home. Config is: > > > > isakmpd_flags=-Kv -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30 > > -D10=20 > > > > ike passive esp \ > > from xxx.xx.xxx.1 (xxx.xx.xxx.0/27) to 0.0.0.0/0 \ > > local xxx.xx.xxx.1 \ > > main auth hmac-sha2-256 enc aes group ecp256 \ > > quick enc aes-128-gcm group ecp256 \ > > srcid xxx > > > > isakmpd starts at boot, 3 devices connect in and tunnels come up, > > FLOWS and SAD show in ipsecctl -sa. > > > > isakmpd crashes shortly after starting (as described in previous mails; > > this is not new, it happens very often on the first start at boot), > > FLOWS and SAD remain showing. At this point they still show InUse: > > > > NameSize Requests FailInUse Pgreq Pgrel Npage Hiwat Minpg Maxpg > > Idle > > tdb 1088906 1 0 1 1 0 8 > >0 > > > > After ipsecctl -F they are freed: > > > > tdb 1088900 1 0 1 1 0 8 > >1 > > > > Restart isakmpd, ipsecctl -f /etc/ipsec.conf, devices connect back in: > > > > tdb 1088 1806 2 1 1 1 0 8 > >0 > > > > (And at this point isakmpd is usually stable). > > > > I will leave a shell loop running vmstat -m every few minutes to check > > if it grows. > > > > (Bad timing for testing TCPMD5 because over the last couple of days I have > > just removed bgpd+ospfd from the machines that would have been good > > choices to run test diffs..I might be able to get some simple setup > > back up and running though) > > Ah, that was interesting: > > Sat Nov 13 21:44:17 GMT 2021 > tdb 1088 1806 2 1 1 1 0 8 > 0 > > Sat Nov 13 21:54:44 GMT 2021 > tdb 1088 1806 2 1 1 1 0 8 > 0 > > Sat Nov 13 22:04:44 GMT 2021 > tdb 1088 270 12 2 1 1 1 0 8 > 0 > > and then shortly after, boom. Unfortunately I didn't get > much from ddb before it hanged after I tried changing cpu. > > [playback] > Xsyscall() at Xsyscall+0x128 > end of kernel > end trace frame: 0x7f7b2d20, count: 248 > End of stack trace. > splassert: tdb_free: want 2 have 0 > Starting stack trace... > tdb_free(80f40b88) at tdb_free+0x47 > pfkeyv2_send(fd80603603b8,80f44c00,170) at pfkeyv2_send+0x656 > pfkeyv2_output(fd8064cb5e00,fd80603603b8,0,0) at pfkeyv2_output+0x8a > pfkeyv2_usrreq(fd80603603b8,9,fd8064cb5e00,0,0,80009508) at > pfkeyv2_usrreq+0x1b0 > sosend(fd80603603b8,0,80001fd8f6f0,0,0,0) at sosend+0x3a9 > > dofilewritev(80009508,7,80001fd8f6f0,0,80001fd8f7f0) at > dofilewritev+0x14d > sys_writev(80009508,80001fd8f790,80001fd8f7f0) at > sys_writev+0xd2 > syscall(80001fd8f860) at syscall+0x3a9 > > Xsyscall() at Xsyscall+0x128 > end of kernel > end trace frame: 0x7f7b2d20, count: 248 > End of stack trace. > splassert: tdb_free: want 2 have 0 > Starting stack trace... > tdb_free(80f40308) at tdb_free+0x47 > pfkeyv2_send(fd80603603b8,80eff300,50) at pfkeyv2_send+
Re: IPsec tdb ref counting
On 2021/11/13 23:05, Stuart Henderson wrote: > On 2021/11/13 22:41, Stuart Henderson wrote: > > On 2021/11/13 21:49, Stuart Henderson wrote: > > > On 2021/11/13 18:04, Alexander Bluhm wrote: > > > > Hi, > > > > > > > > To make IPsec MP safe we need refcounting for the tdb. The diff > > > > below is part of something bigger we have at genua. Although it > > > > does not cover timeouts and the tdb reaper yet, I want to get this > > > > in as a frist step. > > > > > > > > It passes regress but there are setups that are not covered. Bridge > > > > and pfsync with IPsec and TCP signature need special care. > > > > > > > > When testing, please check for tdb leaks. The vmstat -m tdb in use > > > > culumn must be 0. It it is not, try ipsecctl -F. If ipsecctl -sa > > > > shows nothing, but vmstat -m shows a used tdb, then it is a bug. > > > > > > > > NameSize Requests FailInUse Pgreq Pgrel Npage Hiwat Minpg > > > > Maxpg Idle > > > > tdb 904 5600 7 7 0 7 0 > > > > 80 > > > > > > Tested with a box running isakmpd at home. Config is: > > > > > > isakmpd_flags=-Kv -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30 > > > -D10=20 > > > > > > ike passive esp \ > > > from xxx.xx.xxx.1 (xxx.xx.xxx.0/27) to 0.0.0.0/0 \ > > > local xxx.xx.xxx.1 \ > > > main auth hmac-sha2-256 enc aes group ecp256 \ > > > quick enc aes-128-gcm group ecp256 \ > > > srcid xxx > > > > > > isakmpd starts at boot, 3 devices connect in and tunnels come up, > > > FLOWS and SAD show in ipsecctl -sa. > > > > > > isakmpd crashes shortly after starting (as described in previous mails; > > > this is not new, it happens very often on the first start at boot), > > > FLOWS and SAD remain showing. At this point they still show InUse: > > > > > > NameSize Requests FailInUse Pgreq Pgrel Npage Hiwat Minpg > > > Maxpg Idle > > > tdb 1088906 1 0 1 1 0 > > > 80 > > > > > > After ipsecctl -F they are freed: > > > > > > tdb 1088900 1 0 1 1 0 > > > 81 > > > > > > Restart isakmpd, ipsecctl -f /etc/ipsec.conf, devices connect back in: > > > > > > tdb 1088 1806 2 1 1 1 0 > > > 80 > > > > > > (And at this point isakmpd is usually stable). > > > > > > I will leave a shell loop running vmstat -m every few minutes to check > > > if it grows. > > > > > > (Bad timing for testing TCPMD5 because over the last couple of days I have > > > just removed bgpd+ospfd from the machines that would have been good > > > choices to run test diffs..I might be able to get some simple setup > > > back up and running though) > > > > Ah, that was interesting: > > > > Sat Nov 13 21:44:17 GMT 2021 > > tdb 1088 1806 2 1 1 1 0 8 > >0 > > > > Sat Nov 13 21:54:44 GMT 2021 > > tdb 1088 1806 2 1 1 1 0 8 > >0 > > > > Sat Nov 13 22:04:44 GMT 2021 > > tdb 1088 270 12 2 1 1 1 0 8 > >0 > > > > and then shortly after, boom. Unfortunately I didn't get > > much from ddb before it hanged after I tried changing cpu. > > > > [playback] > > Xsyscall() at Xsyscall+0x128 > > end of kernel > > end trace frame: 0x7f7b2d20, count: 248 > > End of stack trace. > > splassert: tdb_free: want 2 have 0 > > Starting stack trace... > > tdb_free(80f40b88) at tdb_free+0x47 > > pfkeyv2_send(fd80603603b8,80f44c00,170) at pfkeyv2_send+0x656 > > pfkeyv2_output(fd8064cb5e00,fd80603603b8,0,0) at pfkeyv2_output+0x8a > > pfkeyv2_usrreq(fd80603603b8,9,fd8064cb5e00,0,0,80009508) at > > pfkeyv2_usrreq+0x1b0 > > sosend(fd80603603b8,0,80001fd8f6f0,0,0,0) at sosend+0x3a9 > > > > dofilewritev(80009508,7,80001fd8f6f0,0,80001fd8f7f0) at > > dofilewritev+0x14d > > sys_writev(80009508,ff
Re: snmpd(8): New application layer - step towards agentx support
On 2021/11/14 11:49, Martijn van Duren wrote: > sthen@ found an issue when using this diff with netsnmp tools. > > The problem was that I put the requestID in the msgID, resulting > in a mismatch upon receiving the reply. The reason that snmp(1) > works is because msgID and requestID are the same. > Diff below fixes things. This version works for me, and the runtime increase with librenms fetches and polls (which use a mixture of get/bulkwalk) is acceptable (10% or so).
Re: IPsec tdb ref counting
On 2021/11/14 03:12, Vitaliy Makkoveev wrote:
> Hi,
>
> Do you have panics with this diff?
Running now, I don't hit the splassert traces with this one.
I will let you know if there is a panic.
> Index: sys/net/if_bridge.c
> ===
> RCS file: /cvs/src/sys/net/if_bridge.c,v
> retrieving revision 1.358
> diff -u -p -r1.358 if_bridge.c
> --- sys/net/if_bridge.c 11 Nov 2021 18:08:17 - 1.358
> +++ sys/net/if_bridge.c 14 Nov 2021 00:09:26 -
> @@ -1577,10 +1577,12 @@ bridge_ipsec(struct ifnet *ifp, struct e
>
> prot = (*(tdb->tdb_xform->xf_input))(&m, tdb, hlen,
> off);
> + tdb_unref(tdb);
> if (prot != IPPROTO_DONE)
> ip_deliver(&m, &hlen, prot, af);
> return (1);
> } else {
> + tdb_unref(tdb);
> skiplookup:
> /* XXX do an input policy lookup */
> return (0);
> Index: sys/net/if_pfsync.c
> ===
> RCS file: /cvs/src/sys/net/if_pfsync.c,v
> retrieving revision 1.298
> diff -u -p -r1.298 if_pfsync.c
> --- sys/net/if_pfsync.c 11 Nov 2021 12:35:01 - 1.298
> +++ sys/net/if_pfsync.c 14 Nov 2021 00:09:26 -
> @@ -1325,11 +1325,13 @@ pfsync_update_net_tdb(struct pfsync_tdb
> /* Neither replay nor byte counter should ever decrease. */
> if (pt->rpl < tdb->tdb_rpl ||
> pt->cur_bytes < tdb->tdb_cur_bytes) {
> + tdb_unref(tdb);
> goto bad;
> }
>
> tdb->tdb_rpl = pt->rpl;
> tdb->tdb_cur_bytes = pt->cur_bytes;
> + tdb_unref(tdb);
> }
> return;
>
> Index: sys/net/pfkeyv2.c
> ===
> RCS file: /cvs/src/sys/net/pfkeyv2.c,v
> retrieving revision 1.221
> diff -u -p -r1.221 pfkeyv2.c
> --- sys/net/pfkeyv2.c 25 Oct 2021 18:25:01 - 1.221
> +++ sys/net/pfkeyv2.c 14 Nov 2021 00:09:26 -
> @@ -1044,7 +1044,8 @@ pfkeyv2_sa_flush(struct tdb *tdb, void *
> if (!(*((u_int8_t *) satype_vp)) ||
> tdb->tdb_satype == *((u_int8_t *) satype_vp)) {
> tdb_unlink_locked(tdb);
> - tdb_free(tdb);
> + tdb_unbundle(tdb);
> + tdb_unref(tdb);
> }
> return (0);
> }
> @@ -1327,7 +1328,7 @@ pfkeyv2_send(struct socket *so, void *me
>
> if ((rval = pfkeyv2_get_proto_alg(newsa->tdb_satype,
> &newsa->tdb_sproto, &alg))) {
> - tdb_free(freeme);
> + tdb_unref(freeme);
> freeme = NULL;
> NET_UNLOCK();
> goto ret;
> @@ -1363,7 +1364,7 @@ pfkeyv2_send(struct socket *so, void *me
> headers[SADB_X_EXT_DST_MASK],
> headers[SADB_X_EXT_PROTOCOL],
> headers[SADB_X_EXT_FLOW_TYPE]))) {
> - tdb_free(freeme);
> + tdb_unref(freeme);
> freeme = NULL;
> NET_UNLOCK();
> goto ret;
> @@ -1386,7 +1387,7 @@ pfkeyv2_send(struct socket *so, void *me
> rval = tdb_init(newsa, alg, &ii);
> if (rval) {
> rval = EINVAL;
> - tdb_free(freeme);
> + tdb_unref(freeme);
> freeme = NULL;
> NET_UNLOCK();
> goto ret;
> @@ -1397,7 +1398,7 @@ pfkeyv2_send(struct socket *so, void *me
> /* Delete old version of the SA, insert new one */
> tdb_delete(sa2);
> puttdb((struct tdb *) freeme);
> - sa2 = freeme = NULL;
> + freeme = NULL;
> } else {
> /*
>* The SA is already initialized, so we're only allowed
> to
> @@ -1503,7 +1504,7 @@ pfkeyv2_send(struct socket *so, void *me
> newsa->tdb_satype = smsg->sadb_msg_satype;
> if ((rval = pfkeyv2_get_proto_alg(newsa->tdb_satype,
> &newsa->tdb_sproto, &alg))) {
> - tdb_free(freeme);
> + tdb_unref(freeme);
> freeme = NULL;
> NET_UNLOCK();
> goto ret;
> @@ -1541,7 +1542,7 @@ pfkeyv2_send(struct socket *so, void *me
> headers[SADB_X_EXT_DST_M
Re: X server updated to version 21.1.1
Remove the symlink named something like 70-bitmap-only from /etc/fonts/conf.d -- Sent from a phone, apologies for poor formatting. On 15 November 2021 09:05:46 Zé Loff wrote: On Fri, Nov 12, 2021 at 07:18:52PM +0100, Matthieu Herrb wrote: Hi, I've updated the X server in Xenocara to version 21.1.1, together with Freetype (2.11.0) and fontconfig 2.13.94. One of the visible change of this update is that some LCD panels now report their real physical dimensions to the X server, rather than just computing it based on a default resolution of 96dpi. This means that the actual DPI computed from these dimensions will change and impact the size of the displayed fonts. If your fonts have chanded sizes too much after the last snapshot update, you can add xrandr --dpi 96 in your ~/.xsession (or ~/.xinitrc) file to set the resolution manually to the previous default. You can also fiddle with the X resources (~/.Xresources ) to fix font sizes in invidual applications. Older X applications are more likely to mis-behave and need the global dpi fix. -- Matthieu Herrb Hi Matthieu Thanks for this. Just a minor hiccup: After upgrading I can no longer use .bcf fonts via Xft, as I think they stopped being picked up by fontconfig (don't show up on fc-list). Are you aware if anything fundamental changed on that side of things? I'm fairly sure the config is (still) correct, since other OTFs and TTFs on the same directory are available. Thanks in advance Zé --
Re: [PATCH] [www] faq/current.html - docoment recent changes in Xenocara [Was: Re: X server updated to version 21.1.1]
On 2021/11/15 12:16, Raf Czlonka wrote: > On Mon, Nov 15, 2021 at 11:38:20AM GMT, Zé Loff wrote: > > > > On Mon, Nov 15, 2021 at 11:01:39AM +, Stuart Henderson wrote: > > > Remove the symlink named something like 70-bitmap-only from > > > /etc/fonts/conf.d > > > > Yes! Thank you! > > For the archives: it's /etc/fonts/conf.d/70-no-bitmaps.conf > > How about mentioning all of this in current.html[0]? > > Please treat it as a stub - it'll obviously need some massaging. The no-bitmaps one was a one-off in at most a couple of snapshots so I'm not sure if it's worth listing in there. If too many irrelevant things are listed then people won't read the file.. The DPI thing maybe changing again as upstream have backed out the auto setting.
Re: vport: set UP on ip assign
On 2021/11/15 12:27, Klemens Nanni wrote: > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote: > > I think physical interfaces should come up when something is configured > > on them, but virtual interfaces shouldn't -- mostly because the order of > > configuration is often muddled. > > So "inet6 2001:db8::1" in hostname.em0 will do the trick but > hostname.vport0 would need another "up" for the same behaviour: that's > rather confusing me as a user. hostname.* files are orthogonal to this; netstart can process all the lines, then if it has seen a line doing address configuration and has not seen an explicit "down", it can bring the interface up automatically at the end. (if this changed, it would be a nightmare for users to do anything else). Users would need to make sure they have a netstart which does that if updating a kernel, but that's just a case of matching kernel+userland and is nothing new for OpenBSD. The different behaviour would be apparent with separate runs of ifconfig. some scripts may need adapting and users might need to run "ifconfig XX up" themselves but I don't think that would be a problem.
Re: IPsec tdb ddb print
On 2021/11/15 17:23, Alexander Bluhm wrote:
> + DUMP(ids, "%p");
> + DUMP(ids_swapped, "%d");
> + DUMP(mtu, "%d");
> + DUMP(mtutimeout, "%lld");
> + pr("%18s: %08x\n", "udpencap_port",
> + ntohl(tdb->tdb_udpencap_port));
ntohl is incorrect here:
udpencap_port: 1194
Index: netinet/ip_ipsp.c
===
RCS file: /cvs/src/sys/netinet/ip_ipsp.c,v
retrieving revision 1.250
diff -u -p -r1.250 ip_ipsp.c
--- netinet/ip_ipsp.c 16 Nov 2021 13:53:14 - 1.250
+++ netinet/ip_ipsp.c 18 Nov 2021 08:08:47 -
@@ -591,8 +591,7 @@ tdb_printit(void *addr, int full, int (*
DUMP(ids_swapped, "%d");
DUMP(mtu, "%d");
DUMP(mtutimeout, "%lld");
- pr("%18s: %08x\n", "udpencap_port",
- ntohl(tdb->tdb_udpencap_port));
+ pr("%18s: %08x\n", "udpencap_port", tdb->tdb_udpencap_port);
DUMP(tag, "%d");
DUMP(tap, "%d");
DUMP(rdomain, "%d");
Re: IPsec tdb ddb print
On 2021/11/18 09:15, Claudio Jeker wrote:
> On Thu, Nov 18, 2021 at 08:10:26AM +0000, Stuart Henderson wrote:
> > On 2021/11/15 17:23, Alexander Bluhm wrote:
> > > + DUMP(ids, "%p");
> > > + DUMP(ids_swapped, "%d");
> > > + DUMP(mtu, "%d");
> > > + DUMP(mtutimeout, "%lld");
> > > + pr("%18s: %08x\n", "udpencap_port",
> > > + ntohl(tdb->tdb_udpencap_port));
> >
> > ntohl is incorrect here:
> >
> > udpencap_port: 1194
> >
> > Index: netinet/ip_ipsp.c
> > ===
> > RCS file: /cvs/src/sys/netinet/ip_ipsp.c,v
> > retrieving revision 1.250
> > diff -u -p -r1.250 ip_ipsp.c
> > --- netinet/ip_ipsp.c 16 Nov 2021 13:53:14 - 1.250
> > +++ netinet/ip_ipsp.c 18 Nov 2021 08:08:47 -
> > @@ -591,8 +591,7 @@ tdb_printit(void *addr, int full, int (*
> > DUMP(ids_swapped, "%d");
> > DUMP(mtu, "%d");
> > DUMP(mtutimeout, "%lld");
> > - pr("%18s: %08x\n", "udpencap_port",
> > - ntohl(tdb->tdb_udpencap_port));
> > + pr("%18s: %08x\n", "udpencap_port", tdb->tdb_udpencap_port);
> > DUMP(tag, "%d");
> > DUMP(tap, "%d");
> > DUMP(rdomain, "%d");
> >
>
> I think this needs to be ntohs(tdb->tdb_udpencap_port) since it is still
> stored in network byte order.
With ntohs, it's "udpencap_port: "
Re: snmpd: tweak listen on
On 2021/11/20 10:20, Martijn van Duren wrote:
> On Sun, 2021-11-14 at 22:30 +0100, Sebastian Benoit wrote:
> > If there is no obvious reason (i.e. be different because you need it for a
> > specific feature) why not to use the same host*() function as other parse.y?
> > it would be better to stay in sync with otehrr daemons. That way if there is
> > an issue in one daemon, we can fix it in all of them.
> >
> > Or, to turn the argument around: if you have found a way to improve those
> > functions in parse.y, you could push for your changes to be applied to all
> > parse.y that use the same function.
> >
> > This applies to other parse.y functions too. The more they deviate, the
> > harder maintanance becomes.
>
> This is the original message[0] (code committed had some tweaks not in this
> mail).
> In there I mention reyk's commit message saying that host_* could be merged.
> This commit tried to implement that (but apparently doesn't hold true any
> more, or maybe it never did). Moving away from struct address in host() also
> has the benefit that having different implementations of struct address to
> be more forgiving and it's less code overall.
>
> Since it took over a year to find this particular edge case I think it could
> be a good idea to push this code to the other daemons as well, but I'm short
> on time at the moment.
>
> Diff below should fix this particular issue and is easy enough to revert if
> we decide to go for the behaviour change of getaddrinfo proposed in my
> previous mail.
ok
> I'm not afraid of moving the other way in getaddrinfo (that AI_NUMERICHOST
> is also subject to the family statement in resolv.conf), because that would
I don't like that at all. And I don't think it matches resolv.conf's
definition of "family":
family Specify which type of Internet protocol family to prefer, if
a host is reachable using different address families.
the "if a host is reachable using different address families"
means that this doesn't apply for numeric addresses. (OK there could be
a side-case with CLAT on OS that don't force IPV6_V6ONLY but not on
OpenBSD).
> also break all current host_v6 implementations in parse.y, so that would
> be an overhaul in all parse.y files anyway.
>
> martijn@
> >
> > Martijn van Duren(openbsd+t...@list.imperialat.at) on 2021.11.14 00:23:59
> > +0100:
> > > On Sat, 2021-11-13 at 13:23 +, Stuart Henderson wrote:
> > > > On 2021/08/09 20:55, Martijn van Duren wrote:
> > > > > On Mon, 2021-08-09 at 11:57 +0200, Martijn van Duren wrote:
> > > > > >
> > > > > > This diff fixes all of the above:
> > > > > > - Allow any to be used resolving to 0.0.0.0 and ::
> > > > > > - Set SO_REUSEADDR on sockets, so we can listen on both any and
> > > > > > ?? localhost
> > > > > > - Document that we listen on any by default
> > > >
> > > > I've discovered a problem with this, if you have "family inet4" or
> > > > "family inet6" in resolv.conf then startup fails, either with the
> > > > implicit listen:
> > > >
> > > > snmpd: Unexpected resolving of ::
> > > >
> > > > or with explicit e.g. "listen on any snmpv3":
> > > >
> > > > /etc/snmpd.conf:3: invalid address: any
> > > >
> > > > Config-based workaround is e.g. "listen on 0.0.0.0 snmpv3"
> > > >
> > > > Should host() use a specific ai_family instead of PF_UNSPEC where we
> > > > already know that it's a v4 or v6 address? Or just do like httpd/parse.y
> > > > where host() tries v4, then v6 if that fails, then dns?
> > > >
>
> [0] https://marc.info/?l=openbsd-tech&m=159838549814986&w=2
>
> Index: parse.y
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
> retrieving revision 1.72
> diff -u -p -r1.72 parse.y
> --- parse.y 25 Oct 2021 11:21:32 - 1.72
> +++ parse.y 20 Nov 2021 09:19:00 -
> @@ -1600,7 +1600,16 @@ host(const char *s, const char *port, in
> bzero(&hints, sizeof(hints));
> hints.ai_family = PF_UNSPEC;
> hints.ai_socktype = type;
> + /*
> + * Without AI_NUMERICHOST getaddrinfo might not resolve ip addresses
> + * for families not specified in the "family" statement in resolv.conf.
> + */
> + hints.ai_flags = AI_NUMERICHOST;
> error = getaddrinfo(s, port, &hints, &res0);
> + if (error == EAI_NONAME) {
> + hints.ai_flags = 0;
> + error = getaddrinfo(s, port, &hints, &res0);
> + }
> if (error == EAI_AGAIN || error == EAI_NODATA || error == EAI_NONAME)
> return 0;
> if (error) {
>
Re: vport: set UP on ip assign
How about a flag that can be passed via ifconfig to disable the implicit up? Then netstart could use it to enaure that an interface is only brought up after it has finished configuration (which *is* a problem for pppoe and carp at least) and it suits people's finger memory for ifconfig? Of course keeping auto-up in any form only solves the actual user-facing problem and doesn't make it easier to cope with the kernel side for locking.
Re: Pass -U to pgrep and pkill in rc.subr(8)
Yes that will break a lot of existing scripts, also it is probably not
needed - rc.subr uses the process name *and arguments*, if you're using
default top options you'll only see the name, use top -C or ps to check as
there is probably more that you can match on.
--
Sent from a phone, apologies for poor formatting.
On 26 November 2021 06:12:33 Ville Valkonen wrote:
Hello,
I would guess the main reason is privilege separation. There will be
privileged (owner root) and unprivileged (dedicated user) processess and
both needs to be killed.
--
Kind regards,
Ville Valkonen
On Fri 26. Nov 2021 at 2.24, Vincent Lee wrote:
Hey all,
I noticed that rc.subr(8)'s invocations of pgrep(1) and pkill(1) don't
filter by the user (by passing -U or -u). I'm wondering if there's a
reason for this?
The reason is that I'm running thelounge (thelounge.chat). It's a NodeJS
application, and by default its command line shows in top(1) as
"node". I know that I can set `pexp` in my rc script, but setting it to
just "node" without filtering by user seems overly broad, in case other
node binaries are running as other users.
I know I can also override rc_check and friends entirely in the rc
script, but this seems like something that most rc scripts can benefit
from.
Here's a diff that makes the change, but let me know if this wasn't done
for any reason or other ways I can get around this problem. Thanks!
diff --git etc/rc.d/rc.subr etc/rc.d/rc.subr
index 2af4887d1..addc6f95d 100644
--- etc/rc.d/rc.subr
+++ etc/rc.d/rc.subr
@@ -144,7 +144,7 @@ _rc_alarm()
}
_rc_sendsig() {
- pkill -${1:-TERM} -T "${daemon_rtable}" -xf "${pexp}"
+ pkill -${1:-TERM} -T "${daemon_rtable}" -U "${daemon_user}" -xf
"${pexp}"
}
_rc_wait_for_start() {
@@ -165,7 +165,7 @@ rc_start() {
}
rc_check() {
- pgrep -T "${daemon_rtable}" -q -xf "${pexp}"
+ pgrep -T "${daemon_rtable}" -U "${daemon_user}" -q -xf "${pexp}"
}
rc_reload() {
disabling a cpu socket
I have some amd64 machines which are doing 600+ gettimeofday/second
at quiet times and way more when they're busy and I'd quite like to
get them onto userland tsc, however they're dual socket and the skew
between cores on the different sockets is too great. There's no way to
disable a socket in BIOS settings, and physically removing a cpu would
be very inconvenient.
Where would I need to make changes (as a local patch obviously) to skip
a cpu? Can I just avoid doing the cpu_intr_init/cpu_start_secondary/
sched_init_cpu/ncpus++/etc from amd64/cpu.c 638-645 ? i.e. these bits
631 case CPU_ROLE_AP:
632 /*
633 * report on an AP
634 */
635 printf("apid %d (application processor)\n",
caa->cpu_apicid);
636
637 #if defined(MULTIPROCESSOR)
638 cpu_intr_init(ci);
639 cpu_start_secondary(ci);
640 sched_init_cpu(ci);
641 ncpus++;
642 if (ci->ci_flags & CPUF_PRESENT) {
643 ci->ci_next = cpu_info_list->ci_next;
644 cpu_info_list->ci_next = ci;
645 }
646 #else
647 printf("%s: not started\n", sc->sc_dev.dv_xname);
648 #endif
Re: iwm/iwx: try to make roaming more reliable
On 2021/11/27 12:44, Stefan Sperling wrote: > The current implementation suffers from race conditions which can > leave the interface in a state where it gets "stuck". I have seen > this happen on iwm(4) 9560 in particular, while testing the driver > with new firmware images recently published by Intel. This may well > be related to other hangs people have reported in multi-AP environments > on both iwm(4) and iwx(4). Working here with 9560 iwm, I've forced roaming via fixing to a distant AP and then removing the fixed chan, done it several times with no problems, the only thing visible in ping with default timers is that the RTTs go down; not a single drop. iwm0: firmware has detected regulatory domain 'GB' (0x4742) iwm0: sending deauth to 22:xx:xx:xx:xx:28 on channel 120 mode 11n iwm0: roaming from 22:xx:xx:xx:xx:28 chan 120 to 76:xx:xx:xx:xx:e7 chan 136 iwm0: RUN -> AUTH iwm0: sending auth to 76:xx:xx:xx:xx:e7 on channel 136 mode 11a iwm0: AUTH -> ASSOC iwm0: sending assoc_req to 76:xx:xx:xx:xx:e7 on channel 136 mode 11a iwm0: ASSOC -> RUN iwm0: associated with 76:xx:xx:xx:xx:e7 ssid "XX" channel 136 start MCS 0 short preamble long slot time HT enabled iwm0: missed beacon threshold set to 30 beacons, beacon interval is 100 TU iwm0: received msg 1/4 of the 4-way handshake from 76:xx:xx:xx:xx:e7 iwm0: sending msg 2/4 of the 4-way handshake to 76:xx:xx:xx:xx:e7 iwm0: received msg 3/4 of the 4-way handshake from 76:xx:xx:xx:xx:e7 iwm0: sending msg 4/4 of the 4-way handshake to 76:xx:xx:xx:xx:e7 iwm0: sending addba_req to 76:xx:xx:xx:xx:e7 on channel 136 mode 11n iwm0: sending addba_resp to 76:xx:xx:xx:xx:e7 on channel 136 mode 11n OpenBSD 7.0-current (GENERIC.MP) #15: Mon Nov 29 20:22:21 GMT 2021 st...@bamboo.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP real mem = 16926281728 (16142MB) avail mem = 16267046912 (15513MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x77d49000 (64 entries) bios0: vendor LENOVO version "N2HET63W (1.46 )" date 06/01/2021 bios0: LENOVO 20QF00B2UK acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 UEFI SSDT HPET APIC MCFG ECDT SSDT SSDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT 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) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c 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,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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES 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 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) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c 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,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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c 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,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,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1715.39 MHz, 06-8e-0c cpu3: FPU,VME,DE,PSE
Re: Please test: UVM fault unlocking (aka vmobjlock)
On 2021/11/29 22:50, Martin Pieuchot wrote: > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > Diff below unlock the bottom part of the UVM fault handler. I'm > > interested in squashing the remaining bugs. Please test with your usual > > setup & report back. > > Thanks to all the testers, here's a new version that includes a bug fix. > > Tests on !x86 architectures are much appreciated! Running here on amd64 and arm64 (plus I added WITNESS to kernel config on arm64 which is only for x86 in your diff). No failures so far, though the machine is quiet (mostly just running conserver + NSD) so it's not the best test ever - if somebody has a more active machine that would be good to get tested. i386 will get a good workout shortly (mkr'ing now). I have one lock order reversal showing at boot on arm64: witness: lock order reversal: 1st 0xff800dab18c0 vmmaplk (&map->lock) 2nd 0xff800da32098 inode (&ip->i_lock) lock order "&ip->i_lock"(rrwlock) -> "&map->lock"(rwlock) first seen at: #0 rw_enter_read+0x44 #1 uvmfault_lookup+0xd8 #2 uvm_fault_check+0x40 #3 uvm_fault+0xdc #4 do_el1h_sync+0x118 #5 handle_el1h_sync+0x70 #6 uiomove+0x9c #7 ffs_read+0x1cc #8 VOP_READ+0x3c #9 vn_rdwr+0xac #10 vmcmd_map_readvn+0x8c #11 exec_process_vmcmds+0x84 #12 sys_execve+0x610 #13 start_init+0x23c #14 proc_trampoline+0x14 lock order "&map->lock"(rwlock) -> "&ip->i_lock"(rrwlock) first seen at: #0 rw_enter+0x84 #1 rrw_enter+0x60 #2 VOP_LOCK+0x64 #3 vn_lock+0xa8 #4 uvn_io+0x19c #5 uvm_pager_put+0xf0 #6 uvn_flush+0x274 #7 uvm_map_clean+0x228 #8 svc_handler+0x310 #9 do_el0_sync+0xe0 #10 handle_el0_sync+0x78 OpenBSD 7.0-current (GENERIC.MP) #4: Tue Nov 30 10:01:15 GMT 2021 st...@mala.spacehopper.org:/sys/arch/arm64/compile/GENERIC.MP real mem = 4134567936 (3943MB) avail mem = 3937853440 (3755MB) random: good seed from bootblocks mainbus0 at root: Raspberry Pi 4 Model B Rev 1.2 psci0 at mainbus0: PSCI 1.1, SMCCC 1.2 cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3 cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu0: 1024KB 64b/line 16-way L2 cache cpu0: CRC32,ASID16 cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3 cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu1: 1024KB 64b/line 16-way L2 cache cpu1: CRC32,ASID16 cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3 cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu2: 1024KB 64b/line 16-way L2 cache cpu2: CRC32,ASID16 cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3 cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu3: 1024KB 64b/line 16-way L2 cache cpu3: CRC32,ASID16 efi0 at mainbus0: UEFI 2.7 efi0: https://github.com/pftf/RPi4 rev 0x1 smbios0 at efi0: SMBIOS 3.3.0 smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.31" date 09/09/2021 smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B apm0 at mainbus0 "system" at mainbus0 not configured "axi" at mainbus0 not configured simplebus0 at mainbus0: "soc" bcmclock0 at simplebus0 bcmmbox0 at simplebus0 bcmgpio0 at simplebus0 bcmaux0 at simplebus0 ampintc0 at simplebus0 nirq 256, ncpu 4 ipi: 0, 1: "interrupt-controller" bcmtmon0 at simplebus0 bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA6 DMA7 DMA8 DMA9 "timer" at simplebus0 not configured pluart0 at simplebus0: console com0 at simplebus0: ns16550, no working fifo "local_intc" at simplebus0 not configured bcmdog0 at simplebus0 bcmirng0 at simplebus0 "firmware" at simplebus0 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured sdhc0 at simplebus0 sdhc0: SDHC 3.0, 250 MHz base clock sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "clocks" at mainbus0 not configured "phy" at mainbus0 not configured "clk-27M" at mainbus0 not configured "clk-108M" at mainbus0 not configured simplebus1 at mainbus0: "emmc2bus" sdhc1 at simplebus1 sdhc1: SDHC 3.0, 100 MHz base clock sdmmc1 at sdhc1: 8-bit, sd high-speed, mmc high-speed, ddr52, dma "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: 54000 kHz simplebus2 at mainbus0: "scb" bcmpcie0 at simplebus2 pci0 at bcmpcie0 ppb0 at pci0 dev 0 function 0 "Broadcom BCM2711" rev 0x10 pci1 at ppb0 bus 1 xhci0 at pci1 dev 0 function 0 "VIA VL805 xHCI" rev 0x01: intx, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "VIA xHCI root hub" rev 3.00/1.00 addr 1 bse0 at simplebus2: address dc:a6:32:8b:e1:b7 brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2 "dma" at simplebus2 not configured "hevc-decoder" at simplebus2 not configured "rpivid-local-intc" at simplebus2 not configured "h264-decoder" at simplebus2 not configured "vp9-decoder" at simplebus2 not configured gpioleds0 at mainbus0: "led0", "led1" "sd_io_1v8_reg" at mainbus0 not configured "sd_vcc_reg" at mainbus0 not configured "fixedregulator_3v3" at m
Re: sppp(4)/pppoe(4) - avoid endless loop in remote ip negotiation
On 2021/12/01 20:58, Krzysztof Kanas wrote: > On 2021-12-01 10:21, Klemens Nanni wrote: > > On Fri, Nov 26, 2021 at 01:35:14PM +0100, Krzysztof Kanas wrote: > > > Hi. When remote side in sppp doesn't reply for to PPP IPCP IP-Address > > > sppp will try to negotiate remote IP in endless loop. Instead use > > > 10.64.64.1 + if_index as remote IP. > > > > Why add some arbitrary RFC 1918 IP if negotiation fails? That's not > > what users request or expect. > > > > I agree that is unexpected but I couldn't find any info in RFC's what to > do if remote side don't reply. I am not familiar enough with PPP/SPP, > so I tried simples thing I could think of, which is to assign RFC 1918 > IP address. IMHO: either keep waiting (the other side may complete IPCP later), or after X retries then drop the session and reattempt negotiation from scratch. A session that is up and stuck with a bogus IP is probably worse than a session that keeps trying to negotiate an address isn't it? How are you configuring the interface? Due to the race condition with "auto up" behaviour on the interface, I would recommend something like this in hostname.pppoeX, you need to have the dest address set to 0.0.0.1 *before* the interface comes up and if you follow the "clean" example in the manpage that doesn't always work inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev em1 authproto chap authname "xyz@foo" authkey "fnord" up This abuses the fact that the dest address in stored in the same variable as the broadcast address on an ethernet interface (my diff to change the example in the manual previously was rejected due to this) but it works ok everywhere I've tried it and "dest" on a separate line doesn't.
Re: sppp(4)/pppoe(4) - avoid endless loop in remote ip negotiation
On 2021/12/04 15:32, Krzysztof Kanas wrote: > I tried the settings: > > inet 0.0.0.0 255.255.255.255 0.0.0.1 \ > pppoedev em0 authproto chap \ > authname 'testcaller' authkey 'secret' up > !/sbin/route add default -ifp pppoe0 0.0.0.1 > > But that didn't fixed my ICPC negotiation problem. > > If I changed first line to (use bougs remote IP) > inet 0.0.0.0 255.255.255.255 10.64.64.33 \ > ... > > Then it works around IPCP problem, but now routing becomes problem as > !/sbin/route add default -ifp pppoe0 0.0.0.1 > > So > > inet 0.0.0.0 255.255.255.255 10.64.64.33 \ > pppoedev em0 authproto chap \ > authname 'testcaller' authkey 'secret' up > !/sbin/route add default -ifp pppoe0 10.64.64.33 > > Seems to be working. > > I will test it more, but does this sound correct ? > And if so then is it worth while to add this to man page to bugs section > ? This is expected, with the current routing table code, even with -ifp set to a point-to-point interface, the route can only be added if the route destination matches the remote address on the interface at the time. "0.0.0.1" can only be added as a route while the remote address is set to the 0.0.0.1 'magic' value. So, there's another race condition here, if the interface comes up quickly and IPCP completes before the route command is executed, the route won't be added. In practice I haven't hit this when the whole thing is run from netstart, but when commands are entered by hand you usually need to check and use the actual address. And of course if you configure a value other than 0.0.0.1, you need to use that value in the route instead. So, while it's a bit annoying, and worse than the older route table code, I do think it's working as expected i.e. not a bug.
Re: em(4) vlan tagging support for 82576
On 2021/12/05 19:22, Yury Shefer wrote: > Hi all, > > I have quad-port Intel ET2 NIC based on 82576[1] controller. The manual > says that hardware VLAN tagging should be supported but ifconfig output > shows VLAN_MTU only in hwfeatures on OpenBSD 7.0. How do I check if 802.1Q > tagging is offloaded or not? And if it's not - does it matter at 1Gbps > speeds on 3 Ghz CPU? > > $ dmesg | grep em0 > em0 at pci11 dev 0 function 0 "Intel 82576" rev 0x01: msi, address > 90:e2:ba:84:64:14 > > $ ifconfig em0 hwfeatures > em0: flags=808843 mtu 1500 Not supported by the driver with 82576 - you would see VLAN_HWTAGGING here: > hwfeatures=10 hardmtu 9216 ^ >From if_em.c: 1949 #if NVLAN > 0 1950 if (sc->hw.mac_type != em_82575 && sc->hw.mac_type != em_82580 && 1951 sc->hw.mac_type != em_82576 && 1952 sc->hw.mac_type != em_i210 && sc->hw.mac_type != em_i350) 1953 ifp->if_capabilities |= IFCAP_VLAN_HWTAGGING; 1954 #endif >From commit log: revision 1.242 date: 2010/08/03 16:21:52; author: jsg; state: Exp; lines: +3 -2; Disable hardware VLAN stripping/insertion on 8257[56] for now. While stripping works insertion seems to have trouble in certain conditions, which needs to be fixed before we want to enable hardware support for this. ok deraadt@ You are best placed to tell whether it matters for your system. Is it fast enough already? Bandwidth doesn't matter all that much, packets-per-second is more important.
Re: com(4) at acpi(4) on amd64
On 2021/12/06 21:08, Patrick Wildt wrote:
> Hi,
>
> On one machine I had the pleasure of having to try and use the
> Serial-over-LAN feature which shows up as just another com(4)
> device. Instead of having to manually add a com(4) at isa(4)
> I figured it would be nicer to have them attach via ACPI. At
> least on that machine, the SOL definitely shows up in the DSDT.
>
> Since I don't want to break any legacy machines, I figured I'd
> keep ignoring the isa(4) addresses specified in amd64's GENERIC.
>
> Right now this diff is more about putting it out there, not about
> asking for OKs, as amd64 isn't really my strong suit. If people
> are interested, I can definitely put in all the feedback there is.
>
> Patrick
>
> diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
> index ecccd1323d9..edb0131d823 100644
> --- a/sys/arch/amd64/conf/GENERIC
> +++ b/sys/arch/amd64/conf/GENERIC
> @@ -76,6 +76,7 @@ tpm*at acpi?
> acpihve* at acpi?
> acpisurface* at acpi?
> acpihid* at acpi?
> +com* at acpi?
> ipmi0at acpi? disable
> ccpmic* at iic?
> tipmic* at iic?
> diff --git a/sys/dev/acpi/acpi.c b/sys/dev/acpi/acpi.c
> index 7577424e8a2..e89869aedbd 100644
> --- a/sys/dev/acpi/acpi.c
> +++ b/sys/dev/acpi/acpi.c
> @@ -3140,7 +3140,6 @@ const char *acpi_isa_hids[] = {
> "PNP0303", /* IBM Enhanced Keyboard (101/102-key, PS/2 Mouse) */
> "PNP0400", /* Standard LPT Parallel Port */
> "PNP0401", /* ECP Parallel Port */
> - "PNP0501", /* 16550A-compatible COM Serial Port */
> "PNP0700", /* PC-class Floppy Disk Controller */
> "PNP0F03", /* Microsoft PS/2-style Mouse */
> "PNP0F13", /* PS/2 Mouse */
> diff --git a/sys/dev/acpi/com_acpi.c b/sys/dev/acpi/com_acpi.c
> index 852be6c71b3..9251b973372 100644
> --- a/sys/dev/acpi/com_acpi.c
> +++ b/sys/dev/acpi/com_acpi.c
> @@ -49,6 +49,7 @@ struct cfattach com_acpi_ca = {
>
> const char *com_hids[] = {
> "HISI0031",
> + "PNP0501",
> NULL
> };
>
> @@ -61,6 +62,13 @@ com_acpi_match(struct device *parent, void *match, void
> *aux)
> struct acpi_attach_args *aaa = aux;
> struct cfdata *cf = match;
>
> +#ifdef __amd64__
> + /* Ignore com(4) at isa(4) */
> + if (aaa->aaa_addr[0] == 0x3f8 || aaa->aaa_addr[0] == 0x2f8 ||
> + aaa->aaa_addr[0] == 0x3e8 || aaa->aaa_addr[0] == 0x2e8)
> + return 0;
> +#endif
One of the benefits of using ACPI to pick up UARTs is that it can cope
with vendors who have screwed up their interrupt assignments (the most
common mistake I've encountered is to have 0x3f8 irq3 / 0x2f8 irq4),
I think this part of the diff will prevent that from working.
Also, it's more than just amd64 ;)
> +
> return acpi_matchhids(aaa, com_hids, cf->cf_driver->cd_name);
> }
>
> @@ -95,8 +103,10 @@ com_acpi_attach(struct device *parent, struct device
> *self, void *aux)
> sc->sc.sc_uarttype = COM_UART_16550;
> sc->sc.sc_frequency = freq ? freq : COM_FREQ;
>
> +#ifndef __amd64__
> sc->sc.sc_reg_width = acpi_getpropint(sc->sc_node, "reg-io-width", 4);
> sc->sc.sc_reg_shift = acpi_getpropint(sc->sc_node, "reg-shift", 2);
> +#endif
>
> if (com_acpi_is_console(sc)) {
> SET(sc->sc.sc_hwflags, COM_HW_CONSOLE);
> @@ -105,7 +115,9 @@ com_acpi_attach(struct device *parent, struct device
> *self, void *aux)
> comconsrate = B115200;
> }
>
> - if (bus_space_map(sc->sc.sc_iot, aaa->aaa_addr[0], aaa->aaa_size[0],
> + if (sc->sc.sc_iobase == comconsaddr)
> + sc->sc.sc_ioh = comconsioh;
> + else if (bus_space_map(sc->sc.sc_iot, aaa->aaa_addr[0],
> aaa->aaa_size[0],
> 0, &sc->sc.sc_ioh)) {
> printf(": can't map registers\n");
> return;
>
Re: add number of prefixed received to bgpctl -j sh
On 2021/12/12 14:13, Denis Fondras wrote:
> Number of received prefixes appear in `bgpctl sh` but not in `bgpctl -j sh`.
>
> Here is a diff to add this piece of information.
>
> OK ?
Makes sense, but if prefix_cnt is added, max_prefix probably should be too
> Index: output_json.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpctl/output_json.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 output_json.c
> --- output_json.c 27 Jul 2021 07:42:37 - 1.12
> +++ output_json.c 12 Dec 2021 13:10:18 -
> @@ -315,6 +315,8 @@ json_neighbor(struct peer *p, struct par
> json_do_printf("state", "%s", statenames[p->state]);
> json_do_printf("last_updown", "%s", fmt_monotime(p->stats.last_updown));
> json_do_int("last_updown_sec", get_monotime(p->stats.last_updown));
> + if (p->state == STATE_ESTABLISHED)
> + json_do_uint("received_prefixes", p->stats.prefix_cnt);
>
> switch (res->action) {
> case SHOW:
>
Re: [PATCH] [src] etc/etc.*/login.conf, share/man/man5/login.conf.5, libexec/login_radius/login_radius.8
On 2021/12/28 18:46, Raf Czlonka wrote: > I was also thinking of normalising 'snk' as it is described as: > > "Digital Pathways SecureNet Key authentication" > > in login.conf(5), but: > > "SNK-004 authentication" > > in all of its manual pages - login_snk(8), snkadm(8), and snkinit(8). > > Also, the other token authentication styles in login.conf(5) file > mention (ANSI) X9.9 and the 'snk' line does not. Either way, I wasn't > sure which way around to go. Digital Pathways SecureNet produces much better search results than SNK-004 for someone trying to figure out whether this is any use. Though adding X9.9 would also make it more obvious that it can be ignored ;)
Re: unwind/unbound: fix build with opaque DSA
On 2022/01/09 14:18, Theo Buehler wrote:
> This switches to using the OpenSSL 1.1 codepath that does DSA_set0_pqg().
> Hopefully it's not too much hassle for updates. DSA_set0_pqg() has been
> in LibreSSL for a while, so we can probably upstream this easily.
>
> libunbound in ports will need the same patch.
OK.
> Index: sbin/unwind/libunbound/sldns/keyraw.c
> ===
> RCS file: /cvs/src/sbin/unwind/libunbound/sldns/keyraw.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 keyraw.c
> --- sbin/unwind/libunbound/sldns/keyraw.c 14 Aug 2021 07:32:46 -
> 1.2
> +++ sbin/unwind/libunbound/sldns/keyraw.c 9 Jan 2022 12:24:28 -
> @@ -250,7 +250,7 @@ sldns_key_buf2dsa_raw(unsigned char* key
> if(!(dsa = DSA_new())) {
> return NULL;
> }
> -#if OPENSSL_VERSION_NUMBER < 0x1010 || defined(HAVE_LIBRESSL)
> +#if OPENSSL_VERSION_NUMBER < 0x1010
> #ifndef S_SPLINT_S
> dsa->p = P;
> dsa->q = Q;
> @@ -428,7 +428,7 @@ sldns_key_buf2rsa_raw(unsigned char* key
> BN_free(modulus);
> return NULL;
> }
> -#if OPENSSL_VERSION_NUMBER < 0x1010 || defined(HAVE_LIBRESSL)
> +#if OPENSSL_VERSION_NUMBER < 0x1010
> #ifndef S_SPLINT_S
> rsa->n = modulus;
> rsa->e = exponent;
> Index: usr.sbin/unbound/sldns/keyraw.c
> ===
> RCS file: /cvs/src/usr.sbin/unbound/sldns/keyraw.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 keyraw.c
> --- usr.sbin/unbound/sldns/keyraw.c 13 Aug 2021 19:58:46 - 1.6
> +++ usr.sbin/unbound/sldns/keyraw.c 9 Jan 2022 12:24:54 -
> @@ -250,7 +250,7 @@ sldns_key_buf2dsa_raw(unsigned char* key
> if(!(dsa = DSA_new())) {
> return NULL;
> }
> -#if OPENSSL_VERSION_NUMBER < 0x1010 || defined(HAVE_LIBRESSL)
> +#if OPENSSL_VERSION_NUMBER < 0x1010
> #ifndef S_SPLINT_S
> dsa->p = P;
> dsa->q = Q;
> @@ -428,7 +428,7 @@ sldns_key_buf2rsa_raw(unsigned char* key
> BN_free(modulus);
> return NULL;
> }
> -#if OPENSSL_VERSION_NUMBER < 0x1010 || defined(HAVE_LIBRESSL)
> +#if OPENSSL_VERSION_NUMBER < 0x1010
> #ifndef S_SPLINT_S
> rsa->n = modulus;
> rsa->e = exponent;
>
Re: new: lang/polyml
On 2022/01/11 23:06, Philip Guenther wrote: > On Tue, Jan 11, 2022 at 4:09 PM Daniel Dickman wrote: > > > On Mon, Jan 10, 2022 at 8:12 PM Leo Larnack wrote: > > > > > > i386 > > > > > > > > > > > with this diff I was able to install includes, rebuild ld.so and > > ctfconv. I've not managed to build a release yet. > > ... > > Umm, with what diff? There was no diff in nor attached to that message. > :-/ https://marc.info/?l=openbsd-tech&m=164186375804139&w=2 > (That was a lot of lines of output. I don't know about ports@, but my > expectation would be there would be *zero* reviewers of anything before, > say, the last 50 lines of output before the switch to actual compilation. > Standard "make lots of noise so when a failure occurs we can see the > leadup, but we'll ignore it otherwise" style of output, like a base build. > You read the lead up to the warnings and errors only. ) The output from configure scripts and previous build stages is often quite important when figuring out a build problem (especially if something works on some machines and fails on others). To my eyes the key bit is probably Created structure Motif **Writing object code** Segmentation fault (core dumped) *** Error 139 in . (Makefile:1158 'polyexport.o') but somebody else might notice something different
Re: request for testing: malloc and large allocations
On 2022/01/09 14:54, Otto Moerbeek wrote:
> currently malloc does cache a number of free'ed regions up to 128k in
> size. This cache is indexed by size (in # of pages), so it is very
> quick to check.
>
> Some programs allocate and deallocate larger allocations in a frantic
> way. Accodomate those programs by also keeping a cache of regions
> betwen 128k and 2M, in a cache of variable sized regions.
>
> My test case speeds up about twice. A make build gets a small speedup.
>
> This has been tested by myself on amd64 quite intensively. I am asking
> for more tests, especialy on more "exotic" platforms. I wil do arm64
> myself soon. Test can be running your favorite programs, doing make
> builds or running tests in regress/lib/libc/malloc.
This has been through mkr and ports bulk build on i386.
Ports build times vary too much to say if it's faster there but
no issues have been seen.
> Thanks in advance!
>
> -Otto
>
> Index: stdlib/malloc.c
> ===
> RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
> retrieving revision 1.272
> diff -u -p -r1.272 malloc.c
> --- stdlib/malloc.c 19 Sep 2021 09:15:22 - 1.272
> +++ stdlib/malloc.c 9 Jan 2022 13:10:35 -
> @@ -113,13 +113,28 @@ struct region_info {
>
> LIST_HEAD(chunk_head, chunk_info);
>
> -#define MAX_CACHEABLE_SIZE 32
> -struct cache {
> - void *pages[MALLOC_MAXCACHE];
> +/*
> + * Two caches, one for "small" regions, one for "big".
> + * Small cacche is an array per size, big cache is one array with different
> + * sizes regions
> + */
> +#define MAX_SMALLCACHEABLE_SIZE 32
> +#define MAX_BIGCACHEABLE_SIZE512
> +#define BIGCACHE_SIZEMALLOC_MAXCACHE
> +/* If the total # of pages is larger than this, evict before inserting */
> +#define BIGCACHE_FILL(sz)(MAX_BIGCACHEABLE_SIZE * (sz) / 4)
> +
> +struct smallcache {
> + void **pages;
> ushort length;
> ushort max;
> };
>
> +struct bigcache {
> + void *page;
> + size_t psize;
> +};
> +
> struct dir_info {
> u_int32_t canary1;
> int active; /* status of malloc */
> @@ -139,7 +154,10 @@ struct dir_info {
> void *delayed_chunks[MALLOC_DELAYED_CHUNK_MASK + 1];
> u_char rbytes[32]; /* random bytes */
> /* free pages cache */
> - struct cache cache[MAX_CACHEABLE_SIZE];
> + struct smallcache smallcache[MAX_SMALLCACHEABLE_SIZE];
> + ushort bigcache_size;
> + size_t bigcache_used;
> + struct bigcache bigcache[BIGCACHE_SIZE];
> #ifdef MALLOC_STATS
> size_t inserts;
> size_t insert_collisions;
> @@ -714,18 +732,61 @@ unmap(struct dir_info *d, void *p, size_
> size_t psz = sz >> MALLOC_PAGESHIFT;
> void *r;
> u_short i;
> - struct cache *cache;
> + struct smallcache *cache;
>
> if (sz != PAGEROUND(sz) || psz == 0)
> wrterror(d, "munmap round");
>
> - if (psz > MAX_CACHEABLE_SIZE || d->cache[psz - 1].max == 0) {
> + if (d->bigcache_size > 0 && psz > MAX_SMALLCACHEABLE_SIZE &&
> + psz <= MAX_BIGCACHEABLE_SIZE) {
> + u_short base = getrbyte(d);
> + u_short j;
> +
> + /* don't look through all slots */
> + for (j = 0; j < d->bigcache_size / 4; j++) {
> + i = (base + j) % d->bigcache_size;
> + if (d->bigcache_used <
> + BIGCACHE_FILL(d->bigcache_size)) {
> + if (d->bigcache[i].psize == 0)
> + break;
> + } else {
> + if (d->bigcache[i].psize != 0)
> + break;
> + }
> + }
> + /* if we didn't find a preferred slot, use random one */
> + if (d->bigcache[i].psize != 0) {
> + size_t tmp;
> +
> + r = d->bigcache[i].page;
> + d->bigcache_used -= d->bigcache[i].psize;
> + tmp = d->bigcache[i].psize << MALLOC_PAGESHIFT;
> + if (!mopts.malloc_freeunmap)
> + validate_junk(d, r, tmp);
> + if (munmap(r, tmp))
> + wrterror(d, "munmap %p", r);
> + STATS_SUB(d->malloc_used, tmp);
> + }
> +
> + if (clear > 0)
> + explicit_bzero(p, clear);
> + if (mopts.malloc_freeunmap) {
> + if (mprotect(p, sz, PROT_NONE))
> + wrterror(d, "mprotect %p", r);
> + } else
> + junk_free(d->malloc_junk, p, sz);
> + d->bigcache[i].page = p;
> + d->bigcache[i].psize = psz;
> + d->bigcache_used += psz;
> + return;
> + }
> +
Re: clang: compile static analyzer
On 2022/01/14 16:52, Rafael Sadowski wrote: > On Fri Jan 14, 2022 at 03:17:21PM +0100, Tobias Heider wrote: > > Hi, > > > > clang ships with a pretty useful static analyzer to find all kinds of bugs > > in C and C++ code: > > > > https://clang-analyzer.llvm.org/ > > > > I use it regularly to check my own diffs and found plenty of bugs I could > > have missed otherwise. While we have the code in base we don't actually > > build it into our libclang currently, so the only ways to use it are > > manually modifying the Makefiles or installing llvm from ports. > > > > I was wondering if anyone else uses this and if there was any interest to > > have this in our base clang? > > Please checkout devel/clang-tools-extra, if you missed something let me know. > CLANG_ENABLE_STATIC_ANALYZER=ON is enabled by default. No need for clang-tools-extra, it is in the llvm package Like others I am happy just having the static analyzer / scan-build in ports. It is useful, but I think not really useful enough to add to the time taken by llvm in every base build when it's available in ports.
Re: dt: make vmm tracepoints amd64 only
On 2022/01/17 10:10, Crystal Kolipe wrote: > On Mon, Jan 17, 2022 at 01:00:44PM +, Klemens Nanni wrote: > > These don't hurt on !VMM architectures but I was still surprised to see > > them on e.g. sparc64: > > > > # arch -s ; btrace -l | grep vmm > > sparc64 > > tracepoint:vmm:guest_enter > > tracepoint:vmm:guest_exit > > > > Like some network drivers, we could use __amd64__ to limit those to > > amd64 and save a few bits in all other kernels. > > Don't we want this on i386 too? vmm is amd64 only.
Re: usr.sbin/ospf6d: fix -Wunused-but-set-variable warnings
On 2022/01/17 14:54, Christian Weisgerber wrote:
> usr.sbin/ospf6d: fix -Wunused-but-set-variable warnings
>
> merge_config() sets "rchange", but doesn't use it. Comparing the
> code to osfpd/ospfd.c makes me think that's an omission. Either
> way it seems odd that the two code bases differ here.
This is probably something to do with reload being disabled in ospf6d.
> rde_summary_update() is incomplete. We can simply #ifdef out the
> unused variables. The lack of indentation or braces following an
> "else" is not pretty. I don't know if we want to fix that up.
>
> M usr.sbin/ospf6d/ospf6d.c
> M usr.sbin/ospf6d/rde.c
>
> diff 436bb480188bab67f704c5f9fcbcf0478db9c100
> a992977b148f5fd9d4e3b9af9aeccac488edfa7a
> blob - b1193eaf336b9f5aa6a3b076efe4080881829152
> blob + af22bd43781a4eaa32b5454fe8fa4fc9992f0b4b
> --- usr.sbin/ospf6d/ospf6d.c
> +++ usr.sbin/ospf6d/ospf6d.c
> @@ -738,7 +738,7 @@ merge_config(struct ospfd_conf *conf, struct ospfd_con
> if_start(conf, iface);
> }
> }
> - if (a->dirty) {
> + if (a->dirty || rchange) {
> a->dirty = 0;
> orig_rtr_lsa(LIST_FIRST(&a->iface_list)->area);
> }
> blob - f4a047206ec2c2e6d2550562560d5933825fb39d
> blob + 4c43bb9296fef10f6d8f9e6a63fcc76e16fe5de9
> --- usr.sbin/ospf6d/rde.c
> +++ usr.sbin/ospf6d/rde.c
> @@ -1249,8 +1249,10 @@ void
> rde_summary_update(struct rt_node *rte, struct area *area)
> {
> struct vertex *v = NULL;
> -//XXXstruct lsa *lsa;
> +#if 0 /* XXX */
> + struct lsa *lsa;
> u_int16_ttype = 0;
> +#endif
>
> /* first check if we actually need to announce this route */
> if (!(rte->d_type == DT_NET || rte->flags & OSPF_RTR_E))
> @@ -1271,13 +1273,13 @@ rde_summary_update(struct rt_node *rte, struct area *a
> /* TODO inter-area network route stuff */
> /* TODO intra-area stuff -- condense LSA ??? */
>
> +#if 0 /* XXX a lot todo */
> if (rte->d_type == DT_NET) {
> type = LSA_TYPE_INTER_A_PREFIX;
> } else if (rte->d_type == DT_RTR) {
> type = LSA_TYPE_INTER_A_ROUTER;
> } else
>
> -#if 0 /* XXX a lot todo */
> /* update lsa but only if it was changed */
> v = lsa_find(area, type, rte->prefix.s_addr, rde_router_id());
> lsa = orig_sum_lsa(rte, area, type, rte->invalid);
>
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: perl clang -Wcompound-token-split-by-macro
btw, bumping the library version for libperl is a safer way of triggering those updates than revision bumps; the latter are subject to a build timing problem, you have to hope that the ports build machines are running a version of base built with the updated perl. On 2022/01/21 18:27, Alexander Bluhm wrote: > On Fri, Jan 21, 2022 at 08:39:34AM -0800, Andrew Hewus Fresh wrote: > > On Fri, Jan 21, 2022 at 04:34:13PM +0100, Marc Espie wrote: > > > So I don't really think perl requires any change. > > > > > > Possibly hacking a bit on ports that use an outdated version of ppport.h > > > > Updating ppport.h seems reasonable to me. > > I am regulary testing a bunch of Perl ports. > http://bluhm.genua.de/portstest/results/latest.html > > In the log file are 17590 -Wcompound-token-split-by-macro warnings. > http://bluhm.genua.de/portstest/results/2022-01-21T11%3A17%3A03Z/test.log > > I can update and patch ppport.h each time I touch such a port. FWIW here's the list from a grep over ports build logs. (I don't propose changing this in all of them, though, only if they're touched anyway). archivers/p5-Compress-Bzip2 audio/p5-Audio-Scan audio/rhythmbox audio/xmms2 converters/p5-Convert-Binary-C converters/p5-Cpanel-JSON-XS converters/p5-Sereal-Decoder converters/p5-Sereal-Encoder converters/p5-Unicode-LineBreak databases/p5-CDB_File databases/p5-DBD-MariaDB databases/p5-DBD-Pg databases/p5-DBD-SQLite databases/p5-DBD-SQLite2 databases/p5-DBD-Sybase databases/p5-DBD-mysql databases/p5-DBI databases/postgresql databases/postgresql-previous devel/autogen devel/libtool devel/libxsvf devel/luaposix devel/p5-Algorithm-Permute devel/p5-BSD-Resource devel/p5-Class-Load-XS devel/p5-Class-XSAccessor devel/p5-Curses devel/p5-Data-Dump-Streamer devel/p5-DateTime devel/p5-Devel-Declare devel/p5-Devel-FastProf devel/p5-Devel-Gladiator devel/p5-Devel-NYTProf devel/p5-Devel-Size devel/p5-File-FnMatch devel/p5-List-MoreUtils-XS devel/p5-Moose devel/p5-Package-Stash-XS devel/p5-Params-Validate devel/p5-Ref-Util-XS devel/p5-Set-Object devel/p5-Sort-Key devel/p5-Sub-Attribute devel/p5-Sub-Identify devel/p5-Sub-Name devel/p5-Term-ReadLine-Gnu devel/p5-Test-LeakTrace devel/p5-Tie-Hash-Indexed devel/p5-USB-LibUSB devel/p5-YAML-Syck devel/p5-YAML-XS devel/p5-autobox devel/p5-forks devel/silc-toolkit geo/p5-Geo-Coordinates-UTM-XS graphics/p5-Cairo graphics/p5-Imager graphics/p5-Imager-QRCode math/graphviz math/p5-AI-FANN math/p5-Math-Int128 math/p5-Math-Int64 math/p5-Math-Prime-Util math/p5-Statistics-CaseResampling misc/p5-File-LibMagic misc/p5-OPCUA-Open62541 multimedia/p5-Storable-AMF multimedia/synfig net/dico net/ircd-hybrid net/p5-BSD-Socket-Splice net/p5-MaxMind-DB-Reader-XS net/p5-MaxMind-DB-Writer net/p5-Net-Pcap net/p5-Net-SSH-Perl net/p5-Net-SSH2 net/silc-client net/silc-server print/texinfo security/p5-Crypt-OpenSSL-EC security/p5-Crypt-OpenSSL-ECDSA security/p5-Crypt-Rijndael security/p5-CryptX security/p5-Digest-Skein security/p5-Net-SSLeay security/p5-Unix-OpenBSD-Random sysutils/libvirt-python sysutils/p5-Unix-Statgrab telephony/siproxd textproc/p5-List-SomeUtils-XS textproc/p5-Template textproc/p5-Text-CSV_XS textproc/p5-XML-LibXML textproc/p5-XML-LibXSLT textproc/redland www/p5-HTML-Escape www/p5-HTTP-Parser-XS www/p5-WWW-Form-UrlEncoded-XS www/p5-libapreq2 x11/kde-applications/ksirk x11/p5-Tk
Re: use 307 instead of 302 for redirect in httpd.conf
On 2022/02/01 11:50, Kirill Miazine wrote:
> Hi, tech
>
> I tried misc@ first, but then without a patch. Now diff is at the end of
> the message.
>
> Currently, /etc/examples/httpd.conf uses HTTP 302 to do a redirect, but
> apparently 307 should give a more predictable behaviour.
>
> According to
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302, "even if
> the specification requires the method (and the body) not to be altered
> when the redirection is performed, not all user-agents conform here
> - you can still find this type of bugged software out there. It is
> therefore recommended to set the 302 code only as a response for GET or
> HEAD methods and to use 307 Temporary Redirect instead, as the method
> change is explicitly prohibited in that case."
>
> "The only difference between 307 and 302 is that 307 guarantees that the
> method and the body will not be changed when the redirected request is
> made. With 302, some old clients were incorrectly changing the method to
> GET: the behavior with non-GET methods and 302 is then unpredictable on
> the Web, whereas the behavior with 307 is predictable. For GET requests,
> their behavior is identical."
>
> Wouldn't it be better to use 307 in the example httpd.conf?
>
> --- /etc/examples/httpd.conf Sun Jan 30 19:00:39 2022
> +++ httpd.confTue Feb 1 11:45:00 2022
> @@ -7,7 +7,7 @@
> request strip 2
> }
> location * {
> - block return 302 "https://$HTTP_HOST$REQUEST_URI";
> + block return 307 "https://$HTTP_HOST$REQUEST_URI";
> }
> }
>
>
Any idea what compatibility is like for this? Not thinking of the big
browsers mentioned in the mozilla page but console browsers, CLI clients,
etc.
(Also for this, which is an example of an http->https redirect, I wonder
if 301 would actually be the more appropriate response..or there is
308 but that is only recommended for non GET/HEAD requests).
Re: amd64: simplify TSC sync testing
This definitely wants testing on Ryzen ThinkPads (e.g. E485/E585/X395/T495s) or Inspiron 5505, I see user TSC disabled on a lot of those in dmesglog. On 2022/01/27 10:28, Scott Cheloha wrote: > Hi, > > sthen@ complained recently about a multisocket system not being able > to use the TSC in userspace because the sync test measured too much > skew and disabled it. > > I don't think there is any real skew on that system. I think the sync > test is confusing NUMA overhead for skew and issuing a false positive > result. > > Now, we _could_ change the test to account for NUMA overhead. I don't > know exactly how you would do it, but I imagine you could devise a > handshake to compute an estimate and then factor that into your skew > measurement. > > Another approach is to drop the current skew measurement handshake in > favor of a dumber approach without that particular false positive case. > > This patch changes our sync test to a dumber approach. Instead of > trying to measure and correct for skew we only test for lag and do > not attempt to correct for it if we detect it. > > Two CPUs enter a loop and continuously check whether the other CPU's > TSC lags their own. With this approach the false positive we are > seeing on sthen@'s machine is impossible because we are only checking > whether one value lags the other, not whether their difference exceeds > an arbitrary value. Synchronization is tested to within a margin of > error because both CPUs are checking for lag at the same time. > > To keep the margin of error is as small as possible for a given clock > rate we spin for a relatively long time. Right now we spin for 1 > millisecond per test round. This is arbitrary but it seems to work. > There is a point of diminishing returns for round duration. This > sync test approach takes much more time than the current handshake > approach and I'd like to minimize our impact on boot time. > > To actually shrink the margin of error you need to run the CPUs at the > highest possible clock rate. If they are underclocked due to e.g. > SpeedStep your margin of error grows and the test may fail to detect > lag. > > We do two rounds of testing for each CPU. This is arbitrary. You > could do more. I think at least one additional test round is a good > idea, just in case we "get lucky" in the first round. I think this > could help mitigate measurement problems introduced by factors beyond > our control. For example, if one of the CPUs blacks out for the > duration of the test because it is preempted by the hypervisor the > test will pass but the result is bogus. If we do more test rounds we > have a better chance of getting a meaningful result even if we get > unlucky with hypervisor preemption or something similar. > > Misc. notes: > > - We no longer have a per-CPU skew value. If any TSC lags another we > just set the timecounter quality to a negative number. We don't > disable userspace or attempt to correct the skew in the kernel. > > I think that bears repeating: we are no longer correcting the skew. > If we detect any lag the TSC is effectively broken. > > - There is no longer any concept of TSC drift. Drift is computed > from skew change and we have no skew value anymore. > > - Am I allowed to printf(9) from a secondary CPU during boot? It > seems to hang the kernel but I don't know why. > > - I have no idea how to use the volatile keyword correctly. I am > trying to keep the compiler from optimizing away my stores. I don't > think it implicitly understands that two threads are looking at these > variables at the same time > > If I am abusing it please tell me. I'm trying to avoid a situation > where some later compiler change subtly breaks the test. If I > sprinkle volatile everywhere my impression is that it forces the > compiler to actually do the store. > > - I have aligned the global TSC values to 64 bytes to try to minimize > "cache bounce". Each value has one reader and one writer so if the > two values are on different cache lines a write to one value shouldn't > cause a cache miss for the writer of the other value. > > ... right? > > I'm not an expert on cache stuff. Can someone shed light on whether > I am doing the right thing here? > > - I rolled my own thread barriers for the test. Would a generic > thread barrier be useful elsewhere in the kernel? Feels wrong to roll > my own synchronization primitive, but maybe we actually don't need > them anywhere else? > > - I would like to forcibly reset IA32_TSC_ADJUST before running the > test but I don't think the CPU feature flags are set early enough > for tsc_reset_adjust() to see the relevant flag even if the CPU > has that register. > > Could we initialize the flags earlier in boot, before the sync test? > > Testing notes: > > - Tests on multisocket systems, multiprocessor VMs on various hypervisors, > and on systems where the TSC is currently disabled
Re: amd64: simplify TSC sync testing
Thanks for testing. On 2022/02/02 13:51, Dave Voutila wrote: > > Jason McIntyre writes: > > > On Wed, Feb 02, 2022 at 04:52:40PM +, Stuart Henderson wrote: > >> This definitely wants testing on Ryzen ThinkPads (e.g. > >> E485/E585/X395/T495s) > >> or Inspiron 5505, I see user TSC disabled on a lot of those in dmesglog. > >> > >> > > > > hi. > > > > here are the results from a 5505. was the timecounter meant to switch > > from tsc? > > > > jmc > > > > $ sysctl kern.timecounter > > kern.timecounter.tick=1 > > kern.timecounter.timestepwarnings=0 > > kern.timecounter.hardware=i8254 > > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000) > > > > I'm seeing the same issue...switching to i8254 pit where before it was > using tsc. :( There are two separate related things, one is the kernel choice, and the other is whether TSC can be used directly from userland for gettimeofday and friends without a syscall. Does the dmesg without the diff say "user TSC disabled"? If so then it was only using it in the kernel. >From reading the diff, I do expect that tsc priority is dropped if the measurements indicate problems, but I wonder why it falls back to i8254 even though acpihpet/acpitimer are available and higher priority.. > This is a Lenovo X13. dmesg and sysctl output follows. > > -dv > > $ sysctl kern.timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=i8254 > kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000) > > > OpenBSD 7.0-current (CUSTOM.MP) #4: Wed Feb 2 13:24:56 EST 2022 > d...@kogelvis2.sisu.home:/usr/src/sys/arch/amd64/compile/CUSTOM.MP > real mem = 16301219840 (15546MB) > avail mem = 15664230400 (14938MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xbf711000 (69 entries) > bios0: vendor LENOVO version "R1CET63W(1.32 )" date 04/09/2021 > bios0: LENOVO 20UF0013US > acpi0 at bios0: ACPI 6.3 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT IVRS SSDT SSDT TPM2 SSDT MSDM BATB > HPET APIC MCFG SBST WSMT VFCT SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI SSDT > SSDT BGRT > acpi0: wakeup devices GPP0(S3) RESA(S3) GPP4(S4) GPP5(S3) L850(S3) GPP6(S3) > GPP7(S3) GP17(S3) XHC0(S3) XHC1(S3) LID_(S4) SLPB(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2096.39 MHz, 17-60-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2096.06 MHz, 17-60-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > tsc: cpu0/cpu2 sync round 1: 1093 regressions > tsc: cpu0/cpu2 sync round 1: cpu0 lags cpu2 by 0 cycles > tsc: cpu0/cpu2 sync round 1: cpu2 lags cpu0 by 21 cycles &
Re: userland clock_gettime proof of concept
running on 38 of these, btw. OpenBSD 6.7-current (GENERIC.MP) #0: Sat Jun 27 21:15:58 BST 2020 sthen@...:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4169592832 (3976MB) avail mem = 4028198912 (3841MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec170 (83 entries) bios0: vendor Intel Corp. version "WYLPT10H.86A.0044.2016.1214.1710" date 12/14/2016 bios0: Intel Corporation D34010WYK acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT MCFG HPET SSDT SSDT DMAR CSRT acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S4) EHC2(S4) XHC_(S4) HDEF(S4) PEG0(S4) [...] 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) Core(TM) i3-4010U CPU @ 1.70GHz, 1696.34 MHz, 06-45-01 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,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC skew=0 observed drift=0 cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz 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) i3-4010U CPU @ 1.70GHz, 1696.09 MHz, 06-45-01 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,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: TSC skew=-22 observed drift=0 cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, 1696.08 MHz, 06-45-01 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,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: TSC skew=-8 observed drift=0 cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, 1696.08 MHz, 06-45-01 cpu3: 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,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: TSC skew=-22 observed drift=0 cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP04) acpiprt3 at acpi0: bus -1 (PEG0) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x extent `acpipci0 pcibus' (0x0 - 0xff), flags=0 0x3f - 0xff extent `acpipci0 pciio' (0x0 - 0x), flags=0 0xcf8 - 0xcff 0x1 - 0x extent `acpipci0 pcimem' (0x0 - 0x), flags=0 0x0 - 0x9 0xc - 0xc 0xe8000 - 0xdf1f 0xfeb0 - 0x acpicmos0 at acpi0 "NTN0530"
Re: Use VGA text mode palette RGB values in rasops(9)
On 2020/07/07 15:16, Frederic Cambus wrote: > Hi tech@, > > The recent spike of interest around framebuffer consoles has prompted > me to revisit a proposal I sent back in early 2017 [1]. > > Aesthetics considerations aside, kettenis@ raised the concern that colors > from the original rasops palette carefully matched what OpenFirmware > uses for the console on sparc64. ..and they're a good choice on sparc64 console with the pale background that the palette is normally used with. I agree that the blue we have now is a bit too dark against a black background.
silicom X710 ixl, unable to query phy types, no sff
I have some ixl cards which show "unable to query phy types" at attach time, and return either EIO or ENODEV if I try fetching sff pages. I booted with SFP+ in all ixl ports and have this: ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c ixl0: unable to query phy types ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d ixl1: unable to query phy types ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e ixl2: unable to query phy types ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f ixl3: unable to query phy types # ifconfig ixl sff ixl0: flags=8802 mtu 1500 lladdr 00:e0:ed:75:a5:5c index 3 priority 0 llprio 3 media: Ethernet autoselect status: no carrier ifconfig: ixl0 transceiver: Input/output error ixl1: flags=8802 mtu 1500 lladdr 00:e0:ed:75:a5:5d index 4 priority 0 llprio 3 media: Ethernet autoselect status: no carrier ifconfig: ixl1 transceiver: Input/output error ixl2: flags=8802 mtu 1500 lladdr 00:e0:ed:75:a5:5e index 5 priority 0 llprio 3 media: Ethernet autoselect (10GbaseLR full-duplex) status: active ifconfig: ixl2 transceiver: Operation not supported by device ixl3: flags=8802 mtu 1500 lladdr 00:e0:ed:75:a5:5f index 6 priority 0 llprio 3 media: Ethernet autoselect status: no carrier ifconfig: ixl3 transceiver: Input/output error With "ifconfig ixlX debug" set, I get this on the interface ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003 Firmware on these are a bit older than the Intel cards that I've seen so my first thought is to try updating, I've mailed Silicom to ask them if they can provide anything newer (Intel's own downloads say not to use them for non Intel-branded cards and I don't really want to brick a card..), does anyone have other ideas while I'm waiting to hear back from them? OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul 8 10:37:10 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8464842752 (8072MB) avail mem = 8193245184 (7813MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries) bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018 bios0: Supermicro Super Server acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) BR3D(S4) RP01(S4) [...] 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) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.27 MHz, 06-56-03 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC skew=0 observed drift=0 cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: TSC skew=4 observed drift=0 cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.00 MHz, 06-56-03 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE
Re: silicom X710 ixl, unable to query phy types, no sff
Update on this: Silicom support responded promptly, asked sensible questions, didn't immediately bail on the fact that I'm not running a supported OS, and prepared an update (to run under Linux but the Debian live image worked fine for this). ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5c ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5d ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5e ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5f ixl3: flags=8802 mtu 1500 lladdr 00:e0:ed:75:a5:5f index 6 priority 0 llprio 3 media: Ethernet autoselect (10GbaseLR full-duplex) status: active transceiver: SFP LC, 1310 nm, 10.0km SMF model: FLEXOPTIX P.1396.10 rev A serial: F78R21S, date: 2018-07-09 voltage: 3.30 V, bias current: 32.07 mA temp: 29.43 C (low -25.00 C, high 90.00 C) tx: -2.63 dBm (low -7.00 dBm, high 2.50 dBm) rx: -4.75 dBm (low -16.00 dBm, high 1.00 dBm) On 2020/07/08 22:59, Stuart Henderson wrote: > I have some ixl cards which show "unable to query phy types" at > attach time, and return either EIO or ENODEV if I try fetching sff > pages. > > I booted with SFP+ in all ixl ports and have this: > > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c > ixl0: unable to query phy types > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d > ixl1: unable to query phy types > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e > ixl2: unable to query phy types > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f > ixl3: unable to query phy types > > # ifconfig ixl sff > ixl0: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5c > index 3 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl0 transceiver: Input/output error > ixl1: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5d > index 4 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl1 transceiver: Input/output error > ixl2: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5e > index 5 priority 0 llprio 3 > media: Ethernet autoselect (10GbaseLR full-duplex) > status: active > ifconfig: ixl2 transceiver: Operation not supported by device > ixl3: flags=8802 mtu 1500 > lladdr 00:e0:ed:75:a5:5f > index 6 priority 0 llprio 3 > media: Ethernet autoselect > status: no carrier > ifconfig: ixl3 transceiver: Input/output error > > With "ifconfig ixlX debug" set, I get this on the interface > > ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003 > > Firmware on these are a bit older than the Intel cards that I've seen > so my first thought is to try updating, I've mailed Silicom to ask them > if they can provide anything newer (Intel's own downloads say not to > use them for non Intel-branded cards and I don't really want to > brick a card..), does anyone have other ideas while I'm waiting to > hear back from them? > > > OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul 8 10:37:10 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8464842752 (8072MB) > avail mem = 8193245184 (7813MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries) > bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018 > bios0: Supermicro Super Server > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT > SSDT SSDT PRAD DMAR HEST BERT ERST EINJ > acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) > BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) > BR3D(S4) RP01(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processo
Re: silicom X710 ixl, unable to query phy types, no sff
On 2020/07/09 22:57, David Gwynne wrote:
> ok.
>
> so the problem is the older api doenst support the "get phy types" command,
> or the sff commands.
yes, looks like it.
> should we silence the "get phy types" error output?
I think that makes sense.
> is there a better errno to use when the sff command isn't supported? should
> we add something to the manpage? should that something be "i'm not angry,
> just disappointed"?
linux does this in the kernel driver (i40e_ethdev.c)
static int i40e_get_module_info(struct rte_eth_dev *dev,
struct rte_dev_module_info *modinfo)
{
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
uint32_t sff8472_comp = 0;
uint32_t sff8472_swap = 0;
uint32_t sff8636_rev = 0;
i40e_status status;
uint32_t type = 0;
/* Check if firmware supports reading module EEPROM. */
if (!(hw->flags & I40E_HW_FLAG_AQ_PHY_ACCESS_CAPABLE)) {
PMD_DRV_LOG(ERR,
"Module EEPROM memory read not supported. "
"Please update the NVM image.\n");
return -EINVAL;
}
reported by ethtool like this
# /usr/sbin/ethtool --module-info ens1f2
Cannot get module EEPROM information: Invalid argument
btw, Silicom didn't recognise the firmware version as we print it (5.0.40043),
ethtool and the intel tools display it like this instead
# /usr/sbin/ethtool -i ens1f2
driver: i40e
version: 2.3.2-k
firmware-version: 5.02 0x80002248 0.0.0
expansion-rom-version:
bus-info: :05:00.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
>
> > On 9 Jul 2020, at 10:36 pm, Stuart Henderson wrote:
> >
> > Update on this: Silicom support responded promptly, asked sensible
> > questions, didn't immediately bail on the fact that I'm not running a
> > supported OS, and prepared an update (to run under Linux but the
> > Debian live image worked fine for this).
> >
> > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5c
> > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5d
> > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5e
> > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW
> > 7.0.50775 API 1.8, msix, 4 queues, address 00:e0:ed:75:a5:5f
> >
> > ixl3: flags=8802 mtu 1500
> >lladdr 00:e0:ed:75:a5:5f
> >index 6 priority 0 llprio 3
> >media: Ethernet autoselect (10GbaseLR full-duplex)
> >status: active
> >transceiver: SFP LC, 1310 nm, 10.0km SMF
> >model: FLEXOPTIX P.1396.10 rev A
> > serial: F78R21S, date: 2018-07-09
> >voltage: 3.30 V, bias current: 32.07 mA
> >temp: 29.43 C (low -25.00 C, high 90.00 C)
> >tx: -2.63 dBm (low -7.00 dBm, high 2.50 dBm)
> >rx: -4.75 dBm (low -16.00 dBm, high 1.00 dBm)
> >
> >
> >
> > On 2020/07/08 22:59, Stuart Henderson wrote:
> >> I have some ixl cards which show "unable to query phy types" at
> >> attach time, and return either EIO or ENODEV if I try fetching sff
> >> pages.
> >>
> >> I booted with SFP+ in all ixl ports and have this:
> >>
> >> ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c
> >> ixl0: unable to query phy types
> >> ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d
> >> ixl1: unable to query phy types
> >> ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e
> >> ixl2: unable to query phy types
> >> ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW
> >> 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f
> >> ixl3: unable to query phy types
> >>
> >> # ifconfig ixl sff
> >> ixl0: flags=8802 mtu 1500
> >>lladdr 00:e0:ed:75:a5:5c
> >>index 3 priority 0 llprio 3
> >>media: Ethernet autoselect
> >>status: no
Re: silicom X710 ixl, unable to query phy types, no sff
Thanks. The Intel NVM update on that link is the one I mentioned that says not to use it on OEM cards, this is in the readme "This package is intended to be used on Intel branded adapters. Please contact your OEM vendor for an appropriate package. In some cases this package may update an OEM device. This package only updates the NVM image for the device family listed on the package. Each Intel Ethernet product family has its own NVM Update Package." The quad cards are expensive enough that I thought it prudent to follow that advice and ask the vendor. If they had been less helpful then maybe I would have tried the straight-from-Intel file anyway but no need now :) On 2020/07/09 20:55, Tom Smyth wrote: > Hi Stuart, > Just a suggestion > but I have had a difficult time with xl710s Last summer and my vendor > advised me to upgrade the firmware on the cards > if you upgrade > The firmware can be downloaded from here: > https://downloadcenter.intel.com/product/93104/Intel-Ethernet-Controller-XL710-BM1 > (check the exact chipset you have) > > > You can apply the update by running "nvmupdate64e" and following the > prompts. You'll need to restart the machine or power cycle ... > > Hope this helps, > > > > > > On Wed, 8 Jul 2020 at 23:09, Stuart Henderson wrote: > > > I have some ixl cards which show "unable to query phy types" at > > attach time, and return either EIO or ENODEV if I try fetching sff > > pages. > > > > I booted with SFP+ in all ixl ports and have this: > > > > ixl0 at pci6 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 1, FW > > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5c > > ixl0: unable to query phy types > > ixl1 at pci6 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 0, FW > > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5d > > ixl1: unable to query phy types > > ixl2 at pci6 dev 0 function 2 "Intel X710 SFP+" rev 0x02: port 2, FW > > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5e > > ixl2: unable to query phy types > > ixl3 at pci6 dev 0 function 3 "Intel X710 SFP+" rev 0x02: port 3, FW > > 5.0.40043 API 1.5, msix, 4 queues, address 00:e0:ed:75:a5:5f > > ixl3: unable to query phy types > > > > # ifconfig ixl sff > > ixl0: flags=8802 mtu 1500 > > lladdr 00:e0:ed:75:a5:5c > > index 3 priority 0 llprio 3 > > media: Ethernet autoselect > > status: no carrier > > ifconfig: ixl0 transceiver: Input/output error > > ixl1: flags=8802 mtu 1500 > > lladdr 00:e0:ed:75:a5:5d > > index 4 priority 0 llprio 3 > > media: Ethernet autoselect > > status: no carrier > > ifconfig: ixl1 transceiver: Input/output error > > ixl2: flags=8802 mtu 1500 > > lladdr 00:e0:ed:75:a5:5e > > index 5 priority 0 llprio 3 > > media: Ethernet autoselect (10GbaseLR full-duplex) > > status: active > > ifconfig: ixl2 transceiver: Operation not supported by device > > ixl3: flags=8802 mtu 1500 > > lladdr 00:e0:ed:75:a5:5f > > index 6 priority 0 llprio 3 > > media: Ethernet autoselect > > status: no carrier > > ifconfig: ixl3 transceiver: Input/output error > > > > With "ifconfig ixlX debug" set, I get this on the interface > > > > ixl2: ixl_sff_get_byte(dev 0xa0, reg 0x7f) -> 0003 > > > > Firmware on these are a bit older than the Intel cards that I've seen > > so my first thought is to try updating, I've mailed Silicom to ask them > > if they can provide anything newer (Intel's own downloads say not to > > use them for non Intel-branded cards and I don't really want to > > brick a card..), does anyone have other ideas while I'm waiting to > > hear back from them? > > > > > > OpenBSD 6.7-current (GENERIC.MP) #337: Wed Jul 8 10:37:10 MDT 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8464842752 (8072MB) > > avail mem = 8193245184 (7813MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries) > > bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018 > > bios0: Supermicro Super Server > > acpi0 at bios0: ACPI 5.0 > > acpi0: sleep states S0 S4 S5 > > acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT > > SSDT SSDT PRAD DMAR HEST BE
Re: empty rc.firsttime when installing
On 2020/07/14 15:03, Denis Fondras wrote:
> I was upgrading an EdgeRouter and it restarted multiple times instead of
> booting
> /bsd
>
> When I had a chance to boot it correctly, I noticed that sysmerge and
> fw_update
> were run multiple times.
>
> This diff avoids filling rc.firsttime and rc.sysmerge.
hmm, that will cause problems for some things I do (the main one being:
sysupgrade -n, add a pkg_add -u line to rc.firsttime, reboot).
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1154
> diff -u -p -r1.1154 install.sub
> --- distrib/miniroot/install.sub 26 May 2020 16:21:00 - 1.1154
> +++ distrib/miniroot/install.sub 14 Jul 2020 12:54:27 -
> @@ -2734,6 +2734,9 @@ finish_up() {
> local _kernel_dir=/mnt/usr/share/relink/kernel
> local _kernel=${MDKERNEL:-GENERIC} _syspatch_archs="amd64 arm64 i386"
>
> + # Empty rc.firsttime
> + echo "" >/mnt/etc/rc.firsttime
> +
> # Mount all known swap partitions. This gives systems with little
> # memory a better chance at running 'MAKEDEV all'.
> if [[ -x /mnt/sbin/swapctl ]]; then
> @@ -2812,7 +2815,7 @@ finish_up() {
>
> # Ensure that sysmerge in batch mode is run on reboot.
> [[ $MODE == upgrade ]] &&
> - echo "/usr/sbin/sysmerge -b" >>/mnt/etc/rc.sysmerge
> + echo "/usr/sbin/sysmerge -b" >/mnt/etc/rc.sysmerge
>
> # If a proxy was needed to fetch the sets, use it for fw_update and
> syspatch
> [[ -n $http_proxy ]] &&
>
Re: iked.conf.5: provide gre example
On 2020/07/15 10:02, Theo de Raadt wrote: > It is extremely unwise to use DNS names at this level (or things which > look like DNS names). The same problems that pf has with DNS, are > present here. You really don't want people to get into this habit. Same in gre(4) config which needs addresses too. I agree. > > +.Pp > > +This example encrypts a > > +.Xr gre 4 > > +tunnel from local machine A to peer D using FQDN-based public key > > +authentication. > > +.Ar transport > > +mode is used to avoid duplicate encapsulation of GRE; The inside encapsulation of IPsec tunnel mode is gif not gre, so it isn't duplicate gre encap. "transport mode is used to avoid double encapsulation" would do? > > +.Ar dstid > > +is set explicitly to the peer's FQDN such that its public key is looked up > > even > > +if the peer does not send its FQDN as peer ID: > > +.Bd -literal -offset indent > > +ikev2 transport \e > > + proto gre \e > > + from A.example.com to D.example.com \e > > + peer D.example.com \e > > + dstid D.example.com > > +.Ed > > .Sh SEE ALSO > > .Xr enc 4 , > > .Xr ipsec 4 , > > >
Re: wsfontload(8): display number of characters in a loaded font
Seems useful. While it's not especially likely anyone is parsing the output
of this, just in case they are it's usually more admin-friendly to add a
new column at the end unless there's a good reason not to.
--
Sent from a phone, apologies for poor formatting.
On 16 July 2020 21:29:50 Frederic Cambus wrote:
Hi tech@,
Here is a diff to add a new column to wsfontload -l output, which
reports the number of characters contained in a loaded font.
It's especially useful with user loaded fonts as they can contain more
than 256 characters.
Below is the current output of wsfontload -l, without the diff:
# Name Encoding W H
0 Boldface ibm 8 16
1 Spleen 6x12 iso 6 12
2 Spleen 8x16 iso 8 16
3 Spleen 12x24 iso 12 24
4 Spleen 16x32 iso 16 32
5 Spleen 32x64 iso 32 64
And now with the diff:
# Name EncodingChars W H
0 Boldface ibm 254 8 16
1 Spleen 6x12 iso 96 6 12
2 Spleen 8x16 iso 224 8 16
3 Spleen 12x24 iso 224 12 24
4 Spleen 16x32 iso 224 16 32
5 Spleen 32x64 iso 224 32 64
Comments? OK?
Index: usr.sbin/wsfontload/wsfontload.c
===
RCS file: /cvs/src/usr.sbin/wsfontload/wsfontload.c,v
retrieving revision 1.21
diff -u -p -r1.21 wsfontload.c
--- usr.sbin/wsfontload/wsfontload.c 28 Jun 2019 13:32:51 - 1.21
+++ usr.sbin/wsfontload/wsfontload.c 16 Jul 2020 16:11:18 -
@@ -141,7 +141,8 @@ main(int argc, char *argv[])
if (list) {
i = 0;
- p = " # Name Encoding W H";
+ p = " # Name Encoding" \
+"Chars W H";
do {
f.index = i;
res = ioctl(wsfd, WSDISPLAYIO_LSFONT, &f);
@@ -151,10 +152,11 @@ main(int argc, char *argv[])
puts(p);
p = NULL;
}
- printf("%2d %-32s %8s %2d %2d\n",
+ printf("%2d %-32s %8s %8d %2d %2d\n",
f.index, f.name,
encodings[f.encoding].name,
-f.fontwidth, f.fontheight);
+f.numchars, f.fontwidth,
+f.fontheight);
}
}
i++;
Re: Add ability to set control values with video(1)
On 2020/07/25 09:20, Theo de Raadt wrote: > The normal idiom is when last-close happens in a driver, all modal-state > is lost and restored to default, and when you use the driver again -- > the new open gets you a raw configuration which is then changed via > ioctl, before futher use. Isn't this a bit like volume controls for audio which do exist outside of a particular application's opening of the device?
Re: Python 3.8 os.listdir EINVAL on large directories
Moving to tech.
In gmane.os.openbsd.misc, you wrote:
> Hi all,
>
> I am getting a stacktrace from the borg command in the borgbackup
> package while checking a backup (see bottom of email for full
> output, since it's verbose). The relevant part is this:
>
> filenames = os.listdir(os.path.join(data_path, dir))
> OSError: [Errno 22] Invalid argument:
> '/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12'
>
> This is same error is reproducible with a test Python 3.8 program:
>
> #!/usr/bin/env python
>
> import os
> os.listdir('/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/')
>
> Running ktrace & kdump reveals the error is from calling
> getdents(2):
>
> 76903 python3.8
> CALL open(0x1ec7f06de3b0,0x3)
> 76903 python3.8
> NAMI "/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/"
> 76903 python3.8 RET open 3
> [...]
> 76903 python3.8 CALL getdents(3,0x1ec7c9257000,0x4000)
> 76903 python3.8 RET getdents 16384/0x4000
> [...]
> 76903 python3.8 CALL getdents(3,0x1ec7c9257000,0x4000)
> 76903 python3.8 RET getdents 16384/0x4000
> [...]
> 76903 python3.8 CALL getdents(3,0x1ec7c9257000,0x4000)
> 76903 python3.8 RET getdents 16384/0x4000
> [...]
> 76903 python3.8 CALL getdents(3,0x1ec7c9257000,0x4000)
> 76903 python3.8 RET getdents -1 errno 22 Invalid argument
>
> Looking at the man page for getdents(2), I found it interesting
> that it says this call "is not a portable interface and should not
> be used directly by applications" and it recommends using
> readdir(3) instead.
ktrace only shows system calls not library functions. I don't
see python calling getdents directly, there is a fair chance that
python is calling readdir, and readdir is calling getdents.
> To give you a rough idea of the number of files and filename sizes
> in this directory:
>
> $ ls /mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12/ | wc
> 15341534 10738
I haven't been able to recreate this including over nfs yet.
What filesystem type and mount options?
getdents(2) :-
format. Up to nbytes of data will be transferred. nbytes must be greater
than or equal to the block size associated with the file (see stat(2)).
Some filesystems may not support getdents() with buffers smaller than this
size.
...
getdents() will fail if:
...
[EINVAL] The file referenced by fd is not a directory, or nbytes
is too small for returning a directory entry or block of
entries, or the current position pointer is invalid.
> Where does the problem lie -- the upstream Python code, the
> OpenBSD-specific patches in its port definition, or somewhere
> else? And in case it matters, this is a -current amd64 system,
> with "sysupgrade -s" executed on 7/15.
>
> Thank you,
> Aaron Miller
>
> --
> Exception ignored in: 0x1e17e13fd310>
> Traceback (most recent call last):
> File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 180, in __del__
> assert False, "cleanup happened in Repository.__del__"
> AssertionError: cleanup happened in Repository.__del__
> Local Exception
> Traceback (most recent call last):
> File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> line 4565, in main
> exit_code = archiver.run(args)
> File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> line 4497, in run
> return set_ec(func(args))
> File "/usr/local/lib/python3.8/site-packages/borg/archiver.py",
> line 161, in wrapper
> with repository:
> File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 190, in __enter__
> self.open(self.path, bool(self.exclusive),
> lock_wait=self.lock_wait, lock=self.do_lock)
> File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 450, in open
> segment = self.io.get_latest_segment()
> File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 1253, in get_latest_segment
> for segment, filename in self.segment_iterator(reverse=True):
> File "/usr/local/lib/python3.8/site-
> packages/borg/repository.py", line 1241, in segment_iterator
> filenames = os.listdir(os.path.join(data_path, dir))
> OSError: [Errno 22] Invalid argument:
> '/mnt/thinkpad_void_obsd_borg/thinkpad.borg/data/12'
>
> Platform: OpenBSD millipede.iforgotmy.name 6.7 GENERIC.MP#348
> amd64
> Borg: 1.1.13 Python: CPython 3.8.3 msgpack: 0.5.6
> PID: 31745 CWD: /mnt/thinkpad_void_obsd_borg
> sys.argv: ['/usr/local/bin/borg', 'check', 'thinkpad.borg']
> SSH_ORIGINAL_COMMAND: None
>
>
Re: cat(1): add more restrictive pledge(2)
On 2020/07/31 00:07, tempmai...@firemail.cc wrote:
> I have to say I'm only a beginner to C but hopefully my patch is
> good.
>
> This patch adds a second and more restrictive pledge (only "stdio"
> instead of "stdio rpath") after the getopt loop if there is no
> input file or if the input file is "-" (stdin) or a sequence of
> repeated instances of "-". It doesn't move argv past the last "-",
> and doesn't pledge if it runs into an input file other than "-".
>
> I've compiled it and tested it with ktrace(1) and kdump(1) and it
> appears to work as expected and pledge correctly with at least
> these invocations:
> $ echo test | ./cat -uv # pledge("stdio", NULL);
> $ echo test | ./cat -uv - # pledge("stdio", NULL);
> $ echo test | ./cat # pledge("stdio", NULL);
> $ echo test | ./cat - - - # pledge("stdio", NULL);
> $ echo test | ./cat - # pledge("stdio", NULL);
> $ echo test | ./cat - cat.c # pledge("stdio rpath", NULL);
> $ echo test | ./cat cat.c - # pledge("stdio rpath", NULL);
>
>
>
> Index: bin/cat/cat.c
> ===
> RCS file: /cvs/src/bin/cat/cat.c,v
> retrieving revision 1.27
> diff -u -p -u -p -r1.27 cat.c
> --- bin/cat/cat.c 28 Jun 2019 13:34:58 - 1.27
> +++ bin/cat/cat.c 30 Jul 2020 23:21:14 -
> @@ -94,7 +94,26 @@ main(int argc, char *argv[])
> "usage: %s [-benstuv] [file ...]\n", __progname);
> return 1;
> }
> + argc -= optind;
> argv += optind;
> +
> + if (argc) {
> + if (!strcmp(*argv, "-")) {
> + do {
> + if (argc == 1) {
> + if (pledge("stdio", NULL) == -1)
> + err(1, "pledge");
> + argc--, argv++;
> + break;
> + } else
> + argc--, argv++;
> + } while (argc && !strcmp(*argv, "-"));
> + argc++, argv--;
> + }
> + } else {
> + if (pledge("stdio", NULL) == -1)
> + err(1, "pledge");
> + }
>
> if (bflag || eflag || nflag || sflag || tflag || vflag)
> cook_args(argv);
>
The improvement is fairly small; cat doesn't have network access or the
ability to write files with the previous pledge. Is this worth the
considerable extra complexity?
It's hard to get a feel for whether the argc/argv manipulation is correct.
no output on glass console after switching to serial
I've just been building a machine with serial console to go to colo tomorrow and have noticed that there's no output on glass console after the "switching console to com0" message. The only getty running after boot is the one on serial console. I won't be able to do much in the way of testing on it now but thought it would be worth flagging anyway. Anyone see similar on other machines? >> OpenBSD/amd64 BOOT 3.52 boot> booting hd0a:/bsd: 14488904+3191824+344096+0+872448 [972760+128+1137936+860957]=0x14ddc88 entry point at 0x81001000 [ using 2972808 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-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.7-current (GENERIC.MP) #380: Fri Jul 31 09:04:24 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8464842752 (8072MB) avail mem = 8193216512 (7813MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (46 entries) bios0: vendor American Megatrends Inc. version "1.3" date 03/19/2018 bios0: Supermicro Super Server acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ acpi0: wakeup devices IP2P(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) BR3D(S4) RP01(S4) [...] 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) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.27 MHz, 06-56-03 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,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 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.01 MHz, 06-56-03 cpu3: 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.00 MHz, 06-56-03 cpu4: 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,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RT
Re: no output on glass console after switching to serial
On 2020/08/01 22:21, Mark Kettenis wrote: > > pci11 at ppb9 bus 10 > > vga1 at pci11 dev 0 function 0 "ASPEED Technology AST2000" rev 0x30 > > This is the BMC graphics and seems to be the only grapics device > available on this machine. Correct. > > wsdisplay at vga1 not configured > > And I think this means the BIOS did not configure it as the primary > graphics device and/or an active VGA device. I'm not sure VGA text > mode will work in such a setup so even if wsdisplay(4) would attach > here it probably wouldn't work. Aha. That sounds plausible, thanks. > Any reason why you've chosen to installl this machine as a "legacy > BIOS" machine instead of UEFI? I think the latter would have given > you efifb(4). Mostly because I normally pxeboot machines to install them, and I couldn't figure out how to get that to work with UEFI.
Re: [PATCH]: Add a check for upgrade feature to sysupgrade(8)
On 2020/08/03 13:50, Solene Rapenne wrote: > On Mon, 3 Aug 2020 13:28:38 +0200 > Emil Engler : > > > ## Abstract > > This patch adds an argument to sysupgrade(8) which makes it possible > > to check if an upgrade is available, similar to "syspatch -c". > > This works both, for snapshots and releases. > > > > ## Usage > > Add "-c" to sysupgrade. > > If the script exits with a zero, an upgrade is available. If it fails > > you are already on the newest version or an upgrade cannot be pulled > > for whatever reason. > > > > ## Motivation > > I want a cronjob on my desktop (which is on -current) that checks > > regularly if a new snapshot is available and notifies me if this is > > the case. syspatch(8) already has such a feature, so why not add > > one to sysupgrade? Also it could be useful on -stable and -release > > systems. > > it seems to me you could use this in your crontab > > sysupgrade -n | grep "Already on last snapshot" || sh > send_mail_new_snasphot.sh > That won't just check, it will stage the release for install on next boot.
Re: $pexp in re.subr(8)
On 2020/08/06 18:12, Thomas Levine wrote:
> The present patch changes the rc.subr(8) manual page to match
> the implementation.
>
> The current manual page for rc.subr(8) says that $pexp is "A regular
> expression to be passed to pgrep(1) in order to find the desired process
> or to be passed to pkill(1) to stop it."
>
> The file /etc/rc.d/rc.subr currently uses $pexp only as a fixed
> expression, with the -xf flags.
>
> > grep pexp /etc/rc.d/rc.subr
> pexp=${pexp}
> multicast nfs_server pexp pf pkg_scripts shlib_dirs spamd_black
> pgrep -T "${daemon_rtable}" -q -xf "${pexp}"
> pkill -HUP -T "${daemon_rtable}" -xf "${pexp}"
> pkill -T "${daemon_rtable}" -xf "${pexp}"
> # make sure pexp matches the process (i.e. doesn't include the quotes)
> pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
>
> The -xf flags are explained in the pgrep(1) and pkill(1) man page.
>
> -x Require an exact match of the process name, or argument
> list if -f is given. The default is to match any substring.
This means that the regular expression must match the full process
string. Equivalent to providing an expression with ^ at the start and
$ at the end of the.
>
> The present patch replaces instances of "regular expression" with
> "fixed expression".
>
> I also think a better phrasing would be to explain in the rc.subr(8)
> man page that $pexp is a substring of the process name with flags and
> that it uses pgrep with -xf. I might eventually do that in a separate
> patch.
>
>
> Index: rc.subr.8
> ===
> RCS file: /cvs/src/share/man/man8/rc.subr.8,v
> retrieving revision 1.37
> diff -u -p -r1.37 rc.subr.8
> --- rc.subr.8 21 Feb 2020 00:47:21 - 1.37
> +++ rc.subr.8 7 Aug 2020 00:46:34 -
> @@ -184,7 +184,7 @@ call
> .It Ic rc_check
> Search for processes of the service with
> .Xr pgrep 1
> -using the regular expression given in the
> +using the fixed expression given in the
> .Va pexp
> variable.
> .It Ic rc_start
> @@ -199,7 +199,7 @@ Send a
> .Dv SIGTERM
> signal using
> .Xr pkill 1
> -on the regular expression given in the
> +on the fixed expression given in the
> .Va pexp
> variable.
> .It Ic rc_reload
> @@ -207,7 +207,7 @@ Send a
> .Dv SIGHUP
> signal using
> .Xr pkill 1
> -on the regular expression given in the
> +on the fixed expression given in the
> .Va pexp
> variable.
> One has to make sure that sending
> @@ -267,7 +267,7 @@ functions.
> User to run the daemon as, using
> .Xr su 1 .
> .It Va pexp
> -A regular expression to be passed to
> +A fixed expression to be passed to
> .Xr pgrep 1
> in order to find the desired process or to be passed to
> .Xr pkill 1
>
Re: sync unwind to libunbound 1.11.0
On 2020/08/27 15:28, Florian Obser wrote: > all heavy lifting done by sthen in unbound > > tests? ok with me. only tested lightly (the machine I normally use does DNS for other machines too so runs unbound). related, any idea what's happening here? unwind[51500]: fatal in main: could not bind to 127.0.0.1 or ::1 on port 53: Address already in use unbound is listening to *:53, but shouldn't other software be able to listen if bound to a specific address like 127.0.0.1:53? is this a bug somewhere or am I just missing something about UDP? _unbound unbound381773* internet6 dgram udp *:53 _unbound unbound381775* internet dgram udp *:53 _unbound unbound481983* internet6 dgram udp *:53 _unbound unbound481985* internet dgram udp *:53
Re: unwind(8): use SO_REUSEADDR
On 2020/08/29 20:06, Florian Obser wrote: > I can't think of a downside, OK. > (Not sure of a use case either though.) It makes it easier to test unwind diffs on a machine that normally runs another nameserver :) OK.
Re: shrinking and growing reallocs: a theoretical? bad case for performance
On 2020/08/31 08:39, Otto Moerbeek wrote: > A question from Theo made me think about realloc and come up with a > particular bad case for performance. I do not know if it happens in > practice, but it was easy to create a test program to hit the case. Not very scientific testing (a single attempt at building one port), but this seems to help quite a lot when compiling programs written in rust. I encourage others to test the diff :-)
Re: sppp: add free() sizes
On 2020/09/12 19:13, Martin Pieuchot wrote: > Another approach would be to always use array of AUTHMAXLEN, I'm not sure > the size justifies two malloc(9). it used to do that, changed in if_sppsubr.c 1.74
Re: trunk: keep interface up on port removal
This has been tried before, I forget what but there were problems -- Sent from a phone, apologies for poor formatting. On 12 September 2020 21:16:31 Alexander Bluhm wrote: OK bluhm@ On Sat, Sep 12, 2020 at 05:49:52PM +0200, Klemens Nanni wrote: Index: if_trunk.c === RCS file: /cvs/src/sys/net/if_trunk.c,v retrieving revision 1.149 diff -u -p -r1.149 if_trunk.c --- if_trunk.c 28 Jul 2020 09:52:32 - 1.149 +++ if_trunk.c 12 Sep 2020 15:41:14 - @@ -423,10 +423,6 @@ trunk_port_destroy(struct trunk_port *tp /* Remove multicast addresses from this port */ trunk_ether_cmdmulti(tp, SIOCDELMULTI); - /* Port has to be down */ - if (ifp->if_flags & IFF_UP) - if_down(ifp); - ifpromisc(ifp, 0); if (tr->tr_port_destroy != NULL)
Re: trunk: keep interface up on port removal
On 2020/09/13 11:12, Stuart Henderson wrote: > This has been tried before, I forget what but there were problems from chat logs when I tried this before: 14:52 < sthen> if i kill the if_down, no crash, but the mac address doesn't get updated so i end up with the same one on em0, em1, trunk0
Re: trunk: keep interface up on port removal
On 2020/09/13 13:23, Klemens Nanni wrote: > On Sun, Sep 13, 2020 at 11:31:12AM +0100, Stuart Henderson wrote: > > On 2020/09/13 11:12, Stuart Henderson wrote: > > > This has been tried before, I forget what but there were problems > > > > from chat logs when I tried this before: > > > > 14:52 < sthen> if i kill the if_down, no crash, but the mac address doesn't > > get updated so i end up with the same one on em0, em1, trunk0 > Thanks for mentioning it, I'll look into whether I can fix this or we > have revert my commit to avoid breakage around MAC addresses. > > I'd expect such information to be present in CVS log or code (comments). > It's not in CVS log because it was tested and didn't work so wasn't committed. I don't know if there's precedent for documenting everything somebody might try but fails in a code comment, feels like the tree would be littered with possibly outdated comments if that's done regularly?
Re: trunk: keep interface up on port removal
On 2020/09/13 14:47, Klemens Nanni wrote:
> So there's a dance around UP interfaces already; CVS log dates this
> code back to 2010 when deraadt rearanged code into ifnewlladdr(), the
> previous if.c revision also head this dance around UP.
>
> The if_down() line I removed from trunk(4) dates back to if_trunk.c r1.1
> from 2005.
>
>
> Here's some practical tests further indicating that my diff does not
> break anything and whatever sthen encountered at whatever time in the
> past is no longer an issue:
This was in 2015 btw.
> With my commit in -CURRENT, the MAC address *is* being restored on my
> physical interfaces:
>
> $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
> em0: flags=8843 mtu 1500
> lladdr 3c:97:0e:6e:e9:1b
> athn0: flags=8843 mtu 1500
> lladdr 04:f0:21:30:37:de
>
> $ doas ifconfig trunk0 trunkport em0 trunkport athn0
>
> $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
> em0:
> flags=8b43 mtu 1500
> lladdr 3c:97:0e:6e:e9:1b
> athn0: flags=8943 mtu
> 1500
> lladdr 3c:97:0e:6e:e9:1b
>
> $ doas ifconfig trunk0 destroy
>
> $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
> em0: flags=8843 mtu 1500
> lladdr 3c:97:0e:6e:e9:1b
> athn0: flags=8843 mtu 1500
> lladdr 04:f0:21:30:37:de
>
> Observe how UP is set on the physical interfaces, i.e. my diff is in.
> MAC addresses of physical interfaces are properly restored.
>
> They are also restored when I create the same trunk0 interface but
> generate a random MAC for it as well, i.e. overwriting MACs for all
> ports while in the trunk:
>
>
> $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
> em0: flags=8843 mtu 1500
> lladdr 3c:97:0e:6e:e9:1b
> athn0: flags=8843 mtu 1500
> lladdr 04:f0:21:30:37:de
>
> $ doas ifconfig trunk0 trunkport em0 trunkport athn0 lladdr random
>
> $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
> em0:
> flags=8b43 mtu 1500
> lladdr 88:c2:6a:b2:21:41
> athn0: flags=8943 mtu
> 1500
> lladdr 88:c2:6a:b2:21:41
>
> $ doas ifconfig trunk0 destroy
>
> $ { ifconfig em0 ; ifconfig athn0 ; } | grep -e flags= -e lladdr
> em0: flags=8843 mtu 1500
> lladdr 3c:97:0e:6e:e9:1b
> athn0: flags=8843 mtu 1500
> lladdr 04:f0:21:30:37:de
>
>
> I also tested this with vether(4) ports under trunk just to check if
> there's anything different for pseudo interfaces, but they behave the
> same as em(4) and athn(4) for me regardless of `lladdr random' on trunk.
>
> Am I missing anything?
I can't test at the moment, but the other case is removing a port from
the trunk without destroying the trunk interface itself. That's almost
certainly what I was testing at the time.
The other thing to be aware of is that you may then end up with two
separate interfaces with the same MAC. This may cause some problems for
incoming traffic now we don't use weak host model on non-router systems.
Not sure there is much we can do about that though.
Re: trunk: keep interface up on port removal
On 2020/09/14 10:57, Klemens Nanni wrote: > On Sun, Sep 13, 2020 at 06:44:13PM +0100, Stuart Henderson wrote: > > I can't test at the moment, but the other case is removing a port from > > the trunk without destroying the trunk interface itself. That's almost > > certainly what I was testing at the time. > Right, that's different from destroying the trunk. > > > The other thing to be aware of is that you may then end up with two > > separate interfaces with the same MAC. This may cause some problems for > > incoming traffic now we don't use weak host model on non-router systems. > > Not sure there is much we can do about that though. > I tested removing a single port from trunk and observed that both > interfaces do end up with the same MAC address, but this happens without > my diff already - I still don't see any behaviour after my diff wrt. MAC > addresses or anything else but the UP flag on port interfaces. > Thanks, that sounds like it's alright then.
Re: pthread_spin_unlock and ownership behaviour
Ports-wise, from a Nov 2019 build on i386, these used it: $ grep -Rl pthread_spin_unlock wrkscan wrkscan/devel/libivykis wrkscan/x11/gnustep/base wrkscan/x11/e17/eina wrkscan/misc/posixtestsuite wrkscan/net/libunbound wrkscan/net/libshout wrkscan/net/icecast wrkscan/net/bird/1,-doc wrkscan/net/bird/1,-main,v6 wrkscan/net/bird/2 wrkscan/net/strongswan wrkscan/mail/mailest wrkscan/geo/gdal,-main -- Sent from a phone, apologies for poor formatting. On 3 October 2020 10:45:05 Martijn van Duren wrote: Back in 2012 kurt@ added an abort call for the undefined behaviour cases on pthread_mutex_unlock. This helped me a great deal in examining the cause of some weird behaviour in icinga (or in the case of openbsd, just plain crash). For shits and giggles I deceided to look into pthread_spin_unlock and saw that we return EPERM here, while POSIX states that this behaviour is unconditionally undefined.[0] Is there a reason why we shouldn't abort here as well? I don't have a particular usecase for this, but the mutex case helped me and it only seems like the right thing to do from a semetrical point of view. The only cases of pthread_spin_unlock in base I found were in libunbound (which with my testing with unwind didn't caused any issues) and gnu/llvm/compiler-rt/lib/tsan, which I don't know where to test. I have no idea which ports use it. martijn@ [0] https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_spin_unlock.html Index: librthread/rthread_spin_lock.c === RCS file: /cvs/src/lib/librthread/rthread_spin_lock.c,v retrieving revision 1.5 diff -u -p -r1.5 rthread_spin_lock.c --- librthread/rthread_spin_lock.c 6 Apr 2020 00:01:08 - 1.5 +++ librthread/rthread_spin_lock.c 3 Oct 2020 09:42:21 - @@ -102,12 +102,12 @@ pthread_spin_unlock(pthread_spinlock_t * pthread_spinlock_t l; if (lock == NULL || *lock == NULL) - return (EINVAL); + abort(); l = *lock; if (l->owner != self) - return (EPERM); + abort(); l->owner = NULL; _spinunlock(&l->lock); Index: libpthread/man/pthread_spin_unlock.3 === RCS file: /cvs/src/lib/libpthread/man/pthread_spin_unlock.3,v retrieving revision 1.3 diff -u -p -r1.3 pthread_spin_unlock.3 --- libpthread/man/pthread_spin_unlock.36 Apr 2020 00:01:08 - 1.3 +++ libpthread/man/pthread_spin_unlock.33 Oct 2020 09:42:21 - @@ -38,17 +38,14 @@ functions. .Sh RETURN VALUES If successful, .Fn pthread_spin_unlock -returns zero; otherwise an error number is returned to indicate the error. +returns zero. .Sh ERRORS .Fn pthread_spin_unlock -will fail if: -.Bl -tag -width Er -.It Bq Er EINVAL -The value specified by +will call +.Xr abort 3 +if the value specified by .Fa lock -is invalid. -.It Bq Er EPERM -The lock is not owned by the calling thread. +is invalid or if the lock is not owned by the calling thread. .El .Sh SEE ALSO .Xr pthread_spin_init 3 ,
Re: Make df output more human friendly in daily(8)
On 2020/10/03 08:44, Daniel Jakots wrote: > On Sat, 3 Oct 2020 08:00:44 +0200, Ingo Schwarze > wrote: > > > But this needs to remain: > > > > > -Reports on which file systems need to be dumped via > > > -.Xr dump 8 . > > > -.It > > Indeed, I wrongly assumed that the other dump call was silent. Here's > the updated diff: > -if [ "X$VERBOSESTATUS" != X0 ]; then > - netstat -ivn > -fi > +next_part "Backing up filesystems with dump:" > +dump w | grep -vB1 ^Dump The "next_part" header text is wrong, it isn't doing a backup here, it's only reporting which need to be dumped.
Re: ssh-keygen: generate ed25519 keys by default
On 2020/10/08 15:40, Christian Weisgerber wrote: > At this point, I don't know how many SSH servers are still out there > that don't handle Ed25519. I still have an ECDSA key somewhere > that I use to log into a machine that still runs... "OpenSSH_6.0p1 > Debian-4+deb7u7, OpenSSL 1.0.1t 3 May 2016". There is a lot of > networking equipment that allows uploading of a user key for SSH > login but may include a comically obsolete version of OpenSSH or > some alternative implementation that doesn't do Ed25519. I don't think that's a show-stopper, people using such equipment likely already need to do non-default things to have OpenSSH connect to it, My typical config for connecting to switches, including some current models running latest available firmware, looks like KexAlgorithms +diffie-hellman-group14-sha1 HostKeyAlgorithms +ssh-rsa (and I still have a few things running where I need to break out an alternative client because openssh won't talk to them at all any more..)
NSD 4.3.3
Here's an update to NSD 4.3.3. Any tests/comments/OKs? diff in order; - changelog - code changes - manpage changes - autoconf foo doc/ChangeLog | 55 doc/RELNOTES | 24 dbaccess.c |4 - ipc.c |1 mini_event.h |5 + nsd-control.c |2 nsd.c | 141 --- options.c | 16 + options.h |4 + server.c |2 tsig-openssl.c | 145 + tsig-openssl.h |2 util.c | 13 util.h |3 - zonec.c|8 ++ zonec.h|2 nsd-checkconf.8.in |2 nsd-checkzone.8.in |2 nsd-control.8.in |2 nsd.8.in |4 - nsd.conf.5.in | 12 ++-- nsd.conf.sample.in |4 - Makefile.in|2 acx_nlnetlabs.m4 | 47 + config.h.in| 12 configure | 56 ++-- configure.ac | 22 27 files changed, 507 insertions(+), 85 deletions(-) Index: doc/ChangeLog === RCS file: /cvs/src/usr.sbin/nsd/doc/ChangeLog,v retrieving revision 1.4 diff -u -p -r1.4 ChangeLog --- doc/ChangeLog 23 Jul 2020 13:54:08 - 1.4 +++ doc/ChangeLog 9 Oct 2020 20:28:16 - @@ -1,3 +1,58 @@ +1 October 2020: Wouter + - tag for 4.3.3rc1 release. + +30 September 2020: Wouter + - Updated date in nsd -v output. + - Fixup bug013_truncate, checkconf and cutest_qroot tests for new + default EDNS size. + +29 September 2020: Willem + - Follow DNS flag day 2020 advice and + set default EDNS message size to 1232. + +4 September 2020: Wouter + - Remove unused space from LIBS on link line. + +3 September 2020: Wouter + - Merge PR #121: Increase log level of recreated database from + WARNING to ERR. + +1 September 2020: Wouter + - Fix #119: fix compile warnings from new gcc. + - Fix #119: warn when trying to parse a directory. + +27 August 2020: Wouter + - Merged PR #113 with fixes. Instead of listing an IP-address to + listen on, an interface name can be specified in nsd.conf, with + ip-address: eth0. The IP-addresses for that interface are then used. + +26 August 2020: Wouter + - Add xstrdup for PR #113. + - Tidy up code like in PR #113. + - Import code from PR #113. + - Fix for unknown EVP_MAC_CTX_free function in openssl 3.0.0 tsig code. + +24 August 2020: Wouter + - Fix that configure checks for EVP_sha256 to detect openssl, because + HMAC_CTX_new is deprecated in 3.0.0. + - Port TSIG code for openssl 3.0.0-alpha6. + - Sync acx_nlnetlabs.m4 with the unbound repo. + - Review fixes for tsig, defensive free and zero. + +4 August 2020: Wouter + - Merge #117: mini_event.h (4.3.2 and 4.3.1) on OpenBSD cannot find + fd_set - patch. + +23 July 2020: Wouter + - Merge #115 from millert: Fix strlcpy() usage. From OpenBSD. + +15 July 2020: Wouter + - Fix make install with --with-pidfile="". + +14 July 2020: Wouter + - Tag for 4.3.2 release. Master branch contains the next version + in development, 4.3.3. + 7 July 2020: Wouter - Tag for 4.3.2rc1. Index: doc/RELNOTES === RCS file: /cvs/src/usr.sbin/nsd/doc/RELNOTES,v retrieving revision 1.3 diff -u -p -r1.3 RELNOTES --- doc/RELNOTES23 Jul 2020 13:54:08 - 1.3 +++ doc/RELNOTES9 Oct 2020 20:28:16 - @@ -1,5 +1,29 @@ NSD RELEASE NOTES +4.3.3 + +FEATURES: + - Follow DNS flag day 2020 advice and + set default EDNS message size to 1232. + - Merged PR #113 with fixes. Instead of listing an IP-address to + listen on, an interface name can be specified in nsd.conf, with + ip-address: eth0. The IP-addresses for that interface are then used. + - Port TSIG code for openssl 3.0.0-alpha6. +BUG FIXES: + - Fix make install with --with-pidfile="". + - Merge #115 from millert: Fix strlcpy() usage. From OpenBSD. + - Merge #117: mini_event.h (4.3.2 and 4.3.1) on OpenBSD cannot find + fd_set - patch. + - Fix that configure checks for EVP_sha256 to detect openssl, because + HMAC_CTX_new is deprecated in 3.0.0. + - Fix #119: fix compile warnings from new gcc. + - Fix #119: warn when trying to parse a directory. + - Merge PR #121: Increase log level of recreated database from + WARNING to ERR. + - Remove unused space from LIBS on link line. + - Updated date in nsd -v output. + + 4.3.2 FEATURES: Index: dbaccess.c === RCS file: /cvs/src/usr.sbin/nsd
Re: NSD 4.3.3
On 2020/10/09 21:35, Stuart Henderson wrote: > Here's an update to NSD 4.3.3. Any tests/comments/OKs? Updated to reinstate the pledge lost in nsd.c (merge error as we had a local commit post 4.3.2), spotted by tb. (I didn't reorder the diff for easier reading this time). Index: Makefile.in === RCS file: /cvs/src/usr.sbin/nsd/Makefile.in,v retrieving revision 1.29 diff -u -p -r1.29 Makefile.in --- Makefile.in 23 Jul 2020 13:54:07 - 1.29 +++ Makefile.in 9 Oct 2020 21:36:14 - @@ -126,7 +126,7 @@ install: orig-install: all $(INSTALL) -d $(DESTDIR)$(sbindir) $(INSTALL) -d $(DESTDIR)$(configdir) - $(INSTALL) -d $(DESTDIR)$(piddir) + if test -n "$(piddir)"; then $(INSTALL) -d $(DESTDIR)$(piddir); fi $(INSTALL) -d $(DESTDIR)$(xfrdir) $(INSTALL) -d $(DESTDIR)$(dbdir) $(INSTALL) -d $(DESTDIR)$(mandir) Index: acx_nlnetlabs.m4 === RCS file: /cvs/src/usr.sbin/nsd/acx_nlnetlabs.m4,v retrieving revision 1.3 diff -u -p -r1.3 acx_nlnetlabs.m4 --- acx_nlnetlabs.m424 Jun 2016 08:34:03 - 1.3 +++ acx_nlnetlabs.m49 Oct 2020 21:36:14 - @@ -2,7 +2,8 @@ # Copyright 2009, Wouter Wijngaards, NLnet Labs. # BSD licensed. # -# Version 34 +# Version 35 +# 2020-08-24 Use EVP_sha256 instead of HMAC_Update (for openssl-3.0.0). # 2016-03-21 Check -ldl -pthread for libcrypto for ldns and openssl 1.1.0. # 2016-03-21 Use HMAC_Update instead of HMAC_CTX_Init (for openssl-1.1.0). # 2016-01-04 -D_DEFAULT_SOURCE defined with -D_BSD_SOURCE for Linux glibc 2.20 @@ -673,30 +674,30 @@ AC_DEFUN([ACX_SSL_CHECKS], [ ACX_RUNTIME_PATH_ADD([$ssldir/lib]) fi -AC_MSG_CHECKING([for HMAC_Update in -lcrypto]) +AC_MSG_CHECKING([for EVP_sha256 in -lcrypto]) LIBS="$LIBS -lcrypto" LIBSSL_LIBS="$LIBSSL_LIBS -lcrypto" AC_TRY_LINK(, [ -int HMAC_Update(void); -(void)HMAC_Update(); +int EVP_sha256(void); +(void)EVP_sha256(); ], [ AC_MSG_RESULT(yes) -AC_DEFINE([HAVE_HMAC_UPDATE], 1, - [If you have HMAC_Update]) +AC_DEFINE([HAVE_EVP_SHA256], 1, + [If you have EVP_sha256]) ], [ AC_MSG_RESULT(no) # check if -lwsock32 or -lgdi32 are needed. BAKLIBS="$LIBS" BAKSSLLIBS="$LIBSSL_LIBS" -LIBS="$LIBS -lgdi32" -LIBSSL_LIBS="$LIBSSL_LIBS -lgdi32" + LIBS="$LIBS -lgdi32 -lws2_32" + LIBSSL_LIBS="$LIBSSL_LIBS -lgdi32 -lws2_32" AC_MSG_CHECKING([if -lcrypto needs -lgdi32]) AC_TRY_LINK([], [ -int HMAC_Update(void); -(void)HMAC_Update(); +int EVP_sha256(void); +(void)EVP_sha256(); ],[ -AC_DEFINE([HAVE_HMAC_UPDATE], 1, -[If you have HMAC_Update]) +AC_DEFINE([HAVE_EVP_SHA256], 1, +[If you have EVP_sha256]) AC_MSG_RESULT(yes) ],[ AC_MSG_RESULT(no) @@ -706,11 +707,11 @@ AC_DEFUN([ACX_SSL_CHECKS], [ LIBSSL_LIBS="$LIBSSL_LIBS -ldl" AC_MSG_CHECKING([if -lcrypto needs -ldl]) AC_TRY_LINK([], [ -int HMAC_Update(void); -(void)HMAC_Update(); +int EVP_sha256(void); +(void)EVP_sha256(); ],[ -AC_DEFINE([HAVE_HMAC_UPDATE], 1, -[If you have HMAC_Update]) +AC_DEFINE([HAVE_EVP_SHA256], 1, +[If you have EVP_sha256]) AC_MSG_RESULT(yes) ],[ AC_MSG_RESULT(no) @@ -720,11 +721,11 @@ AC_DEFUN([ACX_SSL_CHECKS], [ LIBSSL_LIBS="$LIBSSL_LIBS -ldl -pthread" AC_MSG_CHECKING([if -lcrypto needs -ldl -pthread]) AC_TRY_LINK([], [ -int HMAC_Update(void); -(void)HMAC_Update(); +int EVP_sha256(void); +(void)EVP_sha256(); ],[ -AC_DEFINE([HAVE_HMAC_UPDATE], 1, -[If you have HMAC_Update]) +AC_DEFINE([HAV
Re: Unbound 1.12.0
On 2020/10/11 15:37, Renaud Allard wrote: > > > On 10/10/2020 22:05, Stuart Henderson wrote: > > Here's an update to the recently released version of Unbound. Much of > > the additional code is for DoH and is unused here as it requires the > > nghttp2 library. > > > > nghttp2 seems to be MIT licensed. Could it be possible to import it in base? > Personally I am not particularly interested in pushing a library that is already in ports into base.. At this point I would prefer to handle it as a simple update, then consider 1) whether there should be a separate "ports unbound" with things that can't (or can't easily) be handled in base - e.g. this, python, dnstap or 2) whether unbound should just move back to ports completely.
[s...@spacehopper.org: Re: Remove useless line from daemon class in login.conf]
Just found this in my local tree still, iirc danj liked it but there
wasn't much other enthusiasm. Any other comments? Should I just drop
the diff? Change 'a' to use 2^10 minimum? Change to fixed 2^10 with
no auto measurement?
- Forwarded message from Stuart Henderson -
From: Stuart Henderson
Date: Sat, 23 May 2020 22:08:11 +0100
Subject: Re: Remove useless line from daemon class in login.conf
On 2020/05/22 16:04, Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2020/05/22 17:06, Daniel Jakots wrote:
> > > Hi,
> > >
> > > We used to have different numbers of blowfish rounds between the
> > > default and daemon classes in login.conf. On Jun 26, 2016, tedu
> > > committed "upgrade selected login.conf to use auto rounds for bcrypt"
> > > for amd64, sparc64, i386, and maccpc [1].
> > >
> > > Since the class daemon inherits from the default class, the
> > > :localcipher=blowfish,a:\
> > > is a duplicate.
> > >
> > > Here's a diff to remove them.
> >
> > I'm OK with unifying these settings, but FWIW I never switched to auto
> > for these, it doesn't seem all that sensible for somebody with the ability
> > to generate enough load on the machine to be able to reduce the strength
> > of bcrypt down to the 64 (2^6) rounds minimum.
>
> Yes, that is problematic.
>
> The minimum should be probably be raised, we should consider if auto
> should even exist anymore.
>
As long as it doesn't allow weakening things I think auto should still
exist so that machines can have a stronger bcrypt where it's cheap.
When this was introduced, login.conf for amd64/i386/macppc/sparc64
changed from 8 (normal users) and 9 (daemon class i.e. root) to auto.
Since other, mainly slower, arches stayed with hardcoded 8/9 I don't
think the current minimum reachable in the code makes sense at all.
I've gone to a few machines and done:
- 50 runs of "encrypt -b a" to see what setting was chosen by auto
for i in `jot 50`; do echo foo | encrypt -b a; sleep .1; done | cut -d'$' -f3 |
sort | uniq -c
- 50 runs of "encrypt -b 9" or "encrypt -b 10" and averaged, to see
how long those two settings take
time for i in `jot 50`; do echo foo | encrypt -b 10; done
(divided by 50)
Chosen -b 9-b 10
Cortex-A53 1.4GHz (pi3) all 8 0.220.40
GX-412TC 1GHz (APU2)all 8 0.160.31
Cortex-A72 1.5GHz (pi4) all 9 0.070.14
L5520 2.27GHz all 9 0.080.16
E3-1225v3 3.2GHz12x8 3x9 35x10 0.050.10
E3-1240v5 3.5GHzall 10 0.040.08
E3-1270v6 3.8GHzall 11 0.030.05
I think bumping the minimum to 2^9 would be reasonable, there's a more
noticeable delay on some machines but I think that's fair enough (any
cracking is likely to be done on a fast machine, and the user can force
it lower themselves if they want to take the risk).
With a higher minimum than that the delay starts to get very noticeable
in some cases, so I'm not sure we're ready for that yet.
I think it also makes sense to use blowfish,a in login.conf on all
arches, replacing the old 8/9. Actually -b a is already used in the
installer for both root and the standard user on all archs, whatever
they have in login.conf. Resulting in the situation that on some
archs, the bcrypt created during install for root's password is
weaker than it would be if reset after boot.
So maybe this or something like it?
Index: lib/libc/crypt/bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.57
diff -u -p -r1.57 bcrypt.c
--- lib/libc/crypt/bcrypt.c 26 Aug 2016 08:25:02 - 1.57
+++ lib/libc/crypt/bcrypt.c 23 May 2020 20:16:46 -
@@ -237,14 +237,15 @@ bcrypt_checkpass(const char *pass, const
DEF_WEAK(bcrypt_checkpass);
/*
- * Measure this system's performance by measuring the time for 8 rounds.
- * We are aiming for something that takes around 0.1s, but not too much over.
+ * Measure this system's performance by measuring the time for 2^9 rounds.
+ * We are aiming for something that takes around 0.1s, not too much over,
+ * but without allowing it to be too weak.
*/
int
_bcrypt_autorounds(void)
{
struct timespec before, after;
- int r = 8;
+ int r = 9;
char buf[_PASSWORD_LEN];
int duration;
@@ -257,12 +258,12 @@ _bcrypt_autorounds(void)
duration += (after.tv_nsec - before.tv_nsec) / 1000;
/* too quick? slow it down. */
- while (r < 16 && duration <= 6) {
+ while (r < 16 && duration <= 75000) {
r += 1;
d
Re: Typo Diffs
On 2020/10/16 02:36, Varik Valefor wrote:
> Sir or Madam:
>
> Included within this message should be some diffs which can be applied to
> fix some typographical errors and general wording problems which exist
> within the OpenBSD manual pages, as well as some other files.
>
> These changes are proposed because typographical errors look bad and can
> lead to assumptions of incompetence.
>
> KUTGW,
> Varik "NOT A COMPUTER PROGRAMMER!!!" Valefor
The "the the" fixes are good; the others seem to mostly be stylistic
changes which are a matter of opinion, a diff in the reverse direction
would be equally valid, we don't usually commit changes like that though
the maintainers of the relevant parts of the tree may take some of them.
One proposed change in openssl(1) is clearly worse ("to for").
> - BEGIN DIFFS -
> diff --git a/lib/libutil/ober_add_string.3 b/lib/libutil/ober_add_string.3
> index 5eb6bd32ea0..77a13e629a0 100644
> --- a/lib/libutil/ober_add_string.3
> +++ b/lib/libutil/ober_add_string.3
> @@ -134,7 +134,7 @@ creates zero or more
> structures.
> For each byte in
> .Fa fmt ,
> -arguments of the the types given in the following table are consumed
> +arguments of the types given in the following table are consumed
> and passed to the listed function, creating one
> .Vt ber_element
> per byte.
>
> diff --git a/share/man/man9/physio.9 b/share/man/man9/physio.9
> index 528581eedaa..2977813bbe8 100644
> --- a/share/man/man9/physio.9
> +++ b/share/man/man9/physio.9
> @@ -56,7 +56,7 @@ The maximum amount of data to transfer with each call to
> is determined by the
> .Fa minphys
> routine.
> -Since
> +Because
> .Fa uio
> normally describes user space addresses,
> .Fn physio
> @@ -85,7 +85,9 @@ A break-down of the arguments follows:
> The device strategy routine to call for each chunk of data to initiate
> device I/O.
> .It Fa dev
> -The device number identifying the device to interact with.
> +The device number of the device with which
> +.Nm
> +should interact.
> .It Fa flags
> Direction of transfer; the only valid settings are
> .Dv B_READ
>
> diff --git a/usr.bin/ftp/ftp.1 b/usr.bin/ftp/ftp.1
> index 4f4bfd8d5d5..b5683b0d546 100644
> --- a/usr.bin/ftp/ftp.1
> +++ b/usr.bin/ftp/ftp.1
> @@ -316,7 +316,7 @@ slow connection after
> The host with which
> .Nm
> is to communicate may be specified on the command line.
> -If this is done,
> +If this host is specified,
> .Nm
> will immediately attempt to establish a connection to an
> FTP server on that host; otherwise,
> @@ -1675,7 +1675,7 @@ entry cannot be utilized by multiple
> .Ic machine
> definitions; rather, it must be defined following each
> .Ic machine
> -it is intended to be used with.
> +with which it is to be used.
> If a macro named
> .Ic init
> is defined, it is automatically executed as the last step in the
>
> diff --git a/usr.bin/sed/sed.1 b/usr.bin/sed/sed.1
> index 87a5d04aa4a..4d4b0d3660c 100644
> --- a/usr.bin/sed/sed.1
> +++ b/usr.bin/sed/sed.1
> @@ -427,7 +427,7 @@ string for the first instance of the regular expression
> in the pattern space.
> Any character other than backslash or newline can be used instead of
> a slash to delimit the regular expression and the replacement.
> -Also see the the section about
> +Also see the section about
> .Sx SED REGULAR EXPRESSIONS .
> .Pp
> An ampersand
>
> diff --git a/usr.bin/openssl/openssl.1 b/usr.bin/openssl/openssl.1
> index e364586f5ad..f1f4361c472 100644
> --- a/usr.bin/openssl/openssl.1
> +++ b/usr.bin/openssl/openssl.1
> @@ -408,10 +408,10 @@ are assumed to be the names of files containing
> certificate requests.
> The
> .Fa password
> used to encrypt the private key.
> -Since on some systems the command line arguments are visible,
> +On some systems, the command line arguments are visible; therefore,
> this option should be used with caution.
> .It Fl keyfile Ar file
> -The private key to sign requests with.
> +The private key with which requests should be signed.
> .It Fl keyform Cm pem | der
> Private key file format.
> The default is
>
> diff --git a/usr.bin/x99token/x99token.1 b/usr.bin/x99token/x99token.1
> index 1d004dea440..8a29f22ce99 100644
> --- a/usr.bin/x99token/x99token.1
> +++ b/usr.bin/x99token/x99token.1
> @@ -49,7 +49,7 @@ is not specified,
> is in calculator mode.
> In this mode you must enter the same PIN as used in the initialization step.
> The PIN is used to decode the key read from the keyfile.
> -Next you enter the challenge you have been presented with.
> +Next, you enter the challenge which has been presented to you.
> The
> .Nm
> program will provide you with a response to the challenge.
>
> diff --git a/usr.bin/openssl/openssl.1 b/usr.bin/openssl/openssl.1
> index e364586f5ad..da4b73aee3c 100644
> --- a/usr.bin/openssl/openssl.1
> +++ b/usr.bin/openssl/openssl.1
> @@ -371,7 +371,7 @@ If reading the serial from the text file as specified in
> the
> configuration fails, create a new random serial
Re: net.inet.ip.forwarding=0 vs lo(4)
On 2020/10/18 14:04, David Gwynne wrote: > the problem i'm hitting is that i have a multihomed box where the > service it provides listens on an IP address that's assigned to lo1. > it's a host running a service, it's not a router, so the > net.inet.ip.forwarding sysctl is not set to 1. I ran into this, I just turned on the forwarding sysctl to avoid the problem. > i came up with this diff, which adds even more special casing for > loopback interfaces. it says addreesses on loopbacks are globally > reachable, even if ip forwarding is disabled. I don't see why loopbacks should be special. Another place this might show up is services running on carp addresses (I haven't updated those machines yet but there's a fair chance they'll be affected too). I would prefer an explicit sysctl to disable "strong host model".
Re: pf route-to issues
On 2020/10/19 15:35, David Gwynne wrote:
> every few years i try and use route-to in pf, and every time it
> goes badly. i tried it again last week in a slightly different
> setting, and actually tried to understand the sharp edges i hit
> this time instead of giving up. it turns out there are 2 or 3
> different things together that have cause me trouble, which is why
> the diff below is so big.
I used to route-to/reply-to quite a lot at places with poor internet
connections to split traffic between lines (mostly those have better
connections now so I don't need it as often). It worked as I expected -
but I only ever used it with the interface specified.
I mostly used it with pppoe interfaces so the peer address was unknown
at ruleset load time. (I was lucky and had static IPs my side, but the
ISP side was variable). I relied on the fact that once packets are
directed at a point-point interface there's only one place for them to
go. I didn't notice that ":peer" might be useful here (and the syntax
'route-to pppoe1:peer@pppoe1' is pretty awkward so I probably wouldn't
have come up with it), I had 0.0.0.1@pppoe1, 0.0.0.2@pppoe2 etc
(though actually I think it works with $any_random_address@pppoeX).
> the first and i would argue most fundamental problem is a semantic
> problem. if you ask a random person who has some clue about networks
> and routing what they would expect the "argument" to route-to or
> reply-to to be, they would say "a nexthop address" or "a gateway
> address". eg, say i want to force packets to a specific backend
> server without using NAT, i would write a rule like this:
>
> n_servers="192.0.2.128/27"
> pass out on $if_internal to $n_servers route-to 192.168.0.1
>
> pfctl will happily parse this, shove it into the kernel, let you read
> the rules back out again with pfctl -sr, and it all looks plausible, but
> it turns out that it's using the argument to route-to as an interface
> name. because rulesets can refer to interfaces that don't exist yet, pf
> just passes the IP address around as a string, hoping i'll plug in an
> interface with a driver name that looks like an ip address. i spent
> literally a day trying to figure out why a rule like this wasn't
> working.
I don't think I tried this, but the pf.conf(5) BNF syntax suggests it's
supposed to work. So either doc or implementation bug there.
route = ( "route-to" | "reply-to" | "dup-to" )
( routehost | "{" routehost-list "}" )
[ pooltype ]
routehost-list = routehost [ [ "," ] routehost-list ]
routehost = host | host "@" interface-name |
"(" interface-name [ address [ "/" mask-bits ] ] ")"
> the second problem is that the pf_route calls from pfsync don't
> have all the information it is supposed to have. more specifically,
> an ifp pointer isn't set which leads to a segfault. the ifp pointer
> isn't set because pfsync doesnt track which interface a packet is
> going out, it assumes the ip layer will get it right again later, or a
> rule provided something usable.
>
> the third problem is that pf_route relies on information from rules to
> work correctly. this is a problem in a pfsync environment because you
> cannot have the same ruleset on both firewalls 100% of the time, which
> means you cannot have route-to/reply-to behave consistently on a pair of
> firwalls 100% of the time.
I didn't run into this because pppoe(4) and pfsync/carp don't really
go well together, but ouch!
> all of this together makes things work pretty obviously and smoothly.
> in my opinion anyway. route-to now works more like rdr-to, it just
> feels like it changes the address used for the route lookup rather
> than changing the actual IP address in the packet. it also works
> predictably in a pfsync pair, which is great from the point of view of
> high availability.
>
> the main caveat is that it's not backward compatible. if you're already
> using route-to, you will need to tweak your rules to have them parse.
> however, i doubt anyone is using this stuff because it feels very broken
> to me.
Do you expect this to work with a bracketed "address" to defer lookup
until rule evaluation time? i.e.
pass out proto tcp to any port 22 route-to (pppoe1:peer)
I think that will be all that's needed to allow converting the pppoe
use case. I don't have a multiple pppoe setup handy but I can probably
hack together some sort of test.
I've also used route-to with squid "transparent" proxying (shown in
the pkg-readme), I don't do that any more but I can put a squid test
together easily enough.
> @@ -1842,37 +1833,18 @@ pfrule: action dir logquick interface
> decide_address_family($7.src.host, &r.af);
> decide_address_family($7.dst.host, &r.af);
>
> - if ($8.route.rt) {
> + if ($8.rt) {
> + if ($8.rt != PF_DUPTO && !r.direction) {
>
Re: net.inet.ip.forwarding=0 vs lo(4)
On 2020/10/19 11:47, David Gwynne wrote: > On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote: > > On 2020/10/18 14:04, David Gwynne wrote: > > > the problem i'm hitting is that i have a multihomed box where the > > > service it provides listens on an IP address that's assigned to lo1. > > > it's a host running a service, it's not a router, so the > > > net.inet.ip.forwarding sysctl is not set to 1. > > > > I ran into this, I just turned on the forwarding sysctl to avoid the > > problem. > > > > > i came up with this diff, which adds even more special casing for > > > loopback interfaces. it says addreesses on loopbacks are globally > > > reachable, even if ip forwarding is disabled. > > > > I don't see why loopbacks should be special. Another place this > > might show up is services running on carp addresses (I haven't updated > > those machines yet but there's a fair chance they'll be affected too). > > I would prefer an explicit sysctl to disable "strong host model". > > loopback is already special. if a packet comes from an loopback > interface, we allow it to talk to any IP on the local machine. i think > this is mostly to cope with the semantic we've had where local traffic > get's tied to a loopback interface instead of going anywhere near the > physical ones. > > carp is also special. > > let me paste the ip_laddr function instead of the diff to it, it's a bit > more obvious what's going on: Thanks, that will already work for the machines I was thinking of then. > back to loopback and receiving packets. loopback is special because it > is not connected to the outside world. it is impossible to send a packet > via a loopback interface from another host, so configuring a globally > (externally) routable IP on it is currently pointless unless you enable > forwarding. i think making loopback more special and allowing it > to be globally reachable makes sense. i can't think of any downsides to > this at the moment, except that the behaviour would be subtle/not > obvious ok, so it makes sense for this to be independent of any possible separate lever. > is there a need to configure a globally reachable IP on a non-loopback > interface on a host (not router)? if so, then i'd be more convinced that > we need a separate lever to pull. I'm not using it this way, but here's a scenario. Say there are a couple of webservers with addresses from a carp on ethernet/vlan, with a link to their upstream router on some separate interface. They announce the carp prefix into ospf. They aren't routing themselves so the only reason to have forwarding=1 is to have them use "weak host model". With forwarding=0 I think they'll have to use "stub router no" otherwise everything will be announced high metric (rather than being dependent on carp state), but ospfd explicitly handles this; it's marked in parse.y with "/* allow to force non stub mode */".
Re: pf route-to issues
On 2020/10/19 19:53, David Gwynne wrote:
> On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote:
> > On 2020/10/19 15:35, David Gwynne wrote:
> > > every few years i try and use route-to in pf, and every time it
> > > goes badly. i tried it again last week in a slightly different
> > > setting, and actually tried to understand the sharp edges i hit
> > > this time instead of giving up. it turns out there are 2 or 3
> > > different things together that have cause me trouble, which is why
> > > the diff below is so big.
> >
> > I used to route-to/reply-to quite a lot at places with poor internet
> > connections to split traffic between lines (mostly those have better
> > connections now so I don't need it as often). It worked as I expected -
> > but I only ever used it with the interface specified.
>
> cool. did it work beyond the first packet in a connection?
It must have done. The webcams would have utterly broken the rest of
traffic if it hadn't :)
> > I mostly used it with pppoe interfaces so the peer address was unknown
> > at ruleset load time. (I was lucky and had static IPs my side, but the
> > ISP side was variable). I relied on the fact that once packets are
> > directed at a point-point interface there's only one place for them to
> > go. I didn't notice that ":peer" might be useful here (and the syntax
> > 'route-to pppoe1:peer@pppoe1' is pretty awkward so I probably wouldn't
> > have come up with it), I had 0.0.0.1@pppoe1, 0.0.0.2@pppoe2 etc
> > (though actually I think it works with $any_random_address@pppoeX).
>
> yes. i was trying to use it with peers over ethernet, and always
> struggled with the syntax.
>
> > > the first and i would argue most fundamental problem is a semantic
> > > problem. if you ask a random person who has some clue about networks
> > > and routing what they would expect the "argument" to route-to or
> > > reply-to to be, they would say "a nexthop address" or "a gateway
> > > address". eg, say i want to force packets to a specific backend
> > > server without using NAT, i would write a rule like this:
> > >
> > > n_servers="192.0.2.128/27"
> > > pass out on $if_internal to $n_servers route-to 192.168.0.1
> > >
> > > pfctl will happily parse this, shove it into the kernel, let you read
> > > the rules back out again with pfctl -sr, and it all looks plausible, but
> > > it turns out that it's using the argument to route-to as an interface
> > > name. because rulesets can refer to interfaces that don't exist yet, pf
> > > just passes the IP address around as a string, hoping i'll plug in an
> > > interface with a driver name that looks like an ip address. i spent
> > > literally a day trying to figure out why a rule like this wasn't
> > > working.
> >
> > I don't think I tried this, but the pf.conf(5) BNF syntax suggests it's
> > supposed to work. So either doc or implementation bug there.
>
> im leaning toward implementation bug.
>
> > route = ( "route-to" | "reply-to" | "dup-to" )
> > ( routehost | "{" routehost-list "}" )
> > [ pooltype ]
> >
> > routehost-list = routehost [ [ "," ] routehost-list ]
> >
> > routehost = host | host "@" interface-name |
> > "(" interface-name [ address [ "/" mask-bits ] ] ")"
> >
> > > the second problem is that the pf_route calls from pfsync don't
> > > have all the information it is supposed to have. more specifically,
> > > an ifp pointer isn't set which leads to a segfault. the ifp pointer
> > > isn't set because pfsync doesnt track which interface a packet is
> > > going out, it assumes the ip layer will get it right again later, or a
> > > rule provided something usable.
> > >
> > > the third problem is that pf_route relies on information from rules to
> > > work correctly. this is a problem in a pfsync environment because you
> > > cannot have the same ruleset on both firewalls 100% of the time, which
> > > means you cannot have route-to/reply-to behave consistently on a pair of
> > > firwalls 100% of the time.
> >
> > I didn't run into this because pppoe(4) and pfsync/carp don't really
> > go well together, but ouch!
> >
> > > all of th
Re: Fw: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64 multiboot system
On 2020/11/08 11:42, Benjamin Baier wrote:
> Forwarding to tech@ by request from Stuart Henderson
> This issue came up on misc@
> https://marc.info/?l=openbsd-misc&m=160477082230840&w=2
>
> Begin forwarded message:
>
> Date: Sat, 7 Nov 2020 22:30:44 +0100
> From: Benjamin Baier
> To: Bruce Lilly
> Cc: m...@openbsd.org
> Subject: Re: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64
> multiboot system
>
>
> On Sat, 7 Nov 2020 12:36:42 -0500
> Bruce Lilly wrote:
>
> > I have a multiboot system with several OSes on the same hardware.
> >
> > Summary: OpenBSD UUID reported by dmidecode and from sysctl differ
> > significantly w.r.t. byte ordering. Multiple OSes report the same dmidecode
> > UUID, and most other OSes provide one or more alternate ways of accessing
> > the UUID which yields results consistent with dmidecode.
> >
> > Details:
> > dmidecode (after fiddling with kern.allowkmem via /etc/sysctl.conf on
> > OpenBSD)
> > run on each OS that has a dmidecode utility reports the same hardware UUID
> > (modulo hexadecimal digit case), viz.
> >
> > UUID: 484B1340-D7AA-81E5-3CED-9C5C8E3D6756
> >
> > OpenBSD (6.8) `sysctl hw.uuid` instead reports:
> >
> > hw.uuid=40134b48-aad7-e581-3ced-9c5c8e3d6756
> >
> > Note that the differences are:
> > 1. case of hexadecimal digits (inconsequential)
> > 2. byte ordering (but inconsistently so between the initial part
> > and the last 64 bits (the latter part's byte ordering is consistent
> > with dmidecode))
> >
> According to SMBIOS Reference Specification, you are correct.
> 7.2.1
> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI,
> UEFI, and Microsoft specifications) has consistently used little-endian
> byte encoding for the first three
> fields: time_low, time_mid, time_hi_and_version. The same encoding, also
> known as wire format, should
> also be used for the SMBIOS representation of the UUID.
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as:
> 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.
>
> What are the ramifications of a changed UUID?
> What software depends on hw.uuid not changing?
>
> Greetings Ben
>
> ---
I think it would be correct to change our code to follow the spec,
but reading the manual of current versions of dmidecode it goes a bit
further;
There is some ambiguity about how to interpret the UUID fields
prior to SMBIOS specification version 2.6. There was no mention
of byte swapping, and RFC 4122 says that no byte swapping should
be applied by default. However, SMBIOS specification version
2.6 (and later) explicitly states that the first 3 fields of
the UUID should be read as little-endian numbers (byte-swapped).
Furthermore, it implies that the same was already true for older
versions of the specification, even though it was not mentioned.
In practice, many hardware vendors were not byte-swapping the
UUID. So, in order to preserve compatibility, it was decided
to interpret the UUID fields according to RFC 4122 (no byte
swapping) when the SMBIOS version is older than 2.6, and to
interpret the first 3 fields as little-endian (byte-swapped)
when the SMBIOS version is 2.6 or later. The Linux kernel follows
the same logic.
It would seem sensible to follow that lead here I think? Diff for that
below.
I don't think many people will be making existing use of hw.uuid but it
is possible, I don't think there's much we can do other than mention it
in upgrade notes.
Index: amd64/amd64/bios.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
retrieving revision 1.43
diff -u -p -u -2 -5 -r1.43 bios.c
--- amd64/amd64/bios.c 26 Aug 2020 03:29:05 - 1.43
+++ amd64/amd64/bios.c 9 Nov 2020 14:14:18 -
@@ -476,30 +476,45 @@ smbios_info(char *str)
strlcpy(hw_serial, sminfop, infolen);
}
if (smbios_entry.mjr > 2 || (smbios_entry.mjr == 2 &&
smbios_entry.min >= 1)) {
/*
* If the uuid value is all 0xff the uuid is present but not
* set, if its all 0 then the uuid isn't present at all.
*/
uuidf = SMBIOS_UUID_NPRESENT|SMBIOS_UUID_NSET;
for (i = 0; i < sizeof(sys->uuid); i++) {
if (sys->uuid[i] != 0xff)
uuidf &= ~SMBIOS_UUID_NSET;
if (sys->uuid[i] != 0)
uuidf &= ~SMBIOS_UUID_NPRESENT;
}
Re: Fw: Hardware UUID discrepancies (dmidecode vs. sysctl) on amd64 multiboot system
On 2020/11/09 15:28, Mark Kettenis wrote: > > I think it would be correct to change our code to follow the spec, > > but reading the manual of current versions of dmidecode it goes a bit > > further; > > > > There is some ambiguity about how to interpret the UUID fields > > prior to SMBIOS specification version 2.6. There was no mention > > of byte swapping, and RFC 4122 says that no byte swapping should > > be applied by default. However, SMBIOS specification version > > 2.6 (and later) explicitly states that the first 3 fields of > > the UUID should be read as little-endian numbers (byte-swapped). > > Furthermore, it implies that the same was already true for older > > versions of the specification, even though it was not mentioned. > > In practice, many hardware vendors were not byte-swapping the > > UUID. So, in order to preserve compatibility, it was decided > > to interpret the UUID fields according to RFC 4122 (no byte > > swapping) when the SMBIOS version is older than 2.6, and to > > interpret the first 3 fields as little-endian (byte-swapped) > > when the SMBIOS version is 2.6 or later. The Linux kernel follows > > the same logic. > > > > It would seem sensible to follow that lead here I think? Diff for that > > below. > > > > I don't think many people will be making existing use of hw.uuid but it > > is possible, I don't think there's much we can do other than mention it > > in upgrade notes. > > Given that explanation, I'd argue that we should leave things as-is. > Folks interpreted the standard differently and in the end our > interpretation won. Adding more code to "fix" this issue doesn't make Our interpretation only won for pre-2.6 SMBIOS versions.. > a lot of sense to me. Besides, where in the documentation is it > spelled out that hw.uuid matches the SMBIOS UUID? I suppose this is true, it only says "The universal unique identification number assigned to the machine". But we do also suggest using it in pxeboot(8) and anyone doing this will need the id with the standard interpretation.
Re: Strange snmpd issue with 6.7
Moving this to tech@. Not an answer but here's some more information. misc thread archived at https://marc.info/?t=16046954722&r=1&w=2 but I think the important bits are all in quotes in this mail anyway. On 2020/11/12 20:35, Winfred Harrelson wrote: > On Thu, Nov 12, 2020 at 09:51:46AM -, Stuart Henderson wrote: > > On 2020-11-09, Winfred Harrelson wrote: > > > On Sat, Nov 07, 2020 at 01:53:00PM -, Stuart Henderson wrote: > > >> On 2020-11-06, Winfred Harrelson wrote: > > >> > I am running OpenBSD 6.7 and am having a strange issue with snmpd(8). > > >> > > > >> > The issue is that it doesn't have all the arp entries but this was > > >> > working before. I don't know exactly when this started happening > > >> > but I just noticed today. > > >> > > > >> > Here is the machine in question and what I get: > > >> > > > >> > wharrels@styx1:/home/wharrels$ uname -a > > >> > OpenBSD styx1 6.7 GENERIC.MP#3 amd64 > > >> > > > >> > wharrels@styx1:/home/wharrels$ arp -a | wc -l > > >> > 985 > > >> > > > >> > Box is acting as a firewall so that is normal. Actually normal to > > >> > have many more than that. But if I do a query from another machine > > >> > via snmpwalk I get a completely different number of machines in > > >> > the arp table: > > >> > > > >> > [wharrels@newtron ~]$ snmpwalk -v2c -c public styx1 > > >> > ip.ipNetToMediaTable.ipNetToMediaEntry.ipNetToMediaPhysAddress | wc -l > > >> > 456 > > >> > > > >> > Not even close to the same number of machines. The above OID > > >> > translates to > > >> > 1.3.6.1.2.1.4.22.1.2 if you want to try this and see what you get. > > >> > > > >> > Should I be using a different OID to get the arp table or is there > > >> > another way to do this? It might be that this was not working quite > > >> > right before but I don't remember it being off like this. > > >> > > > >> > Any help would be appreciated, thanks. > > >> > > > >> > Winfred > > >> > > > >> > > > >> > > >> If you have set "filter-routes yes" then this is expected as it will > > >> stop snmpd from seeing route updates and thus new additions to the > > >> ARP table. > > > > > > I do not have that in my config file. Man page says the default is "no" > > > so this should not be it correct? I will try adding the line with a > > > "no" just to see if that changes anything though. > > > > Correct. > > > > >> If you have not then I'd say this is a bug and best reported to > > >> bugs@ rather than misc@. > > > > > > I am running 6.7 on this box so I may wait until I can get it updated > > > to 6.8 before reporting to bugs@. > > > > Worth doing though I think 6.8 is unlikely to help. > > > > Does restarting snmpd result in picking up the full arp table again? > > Yes initially. Unfortunately, after a while they get out of sync > again. Gets more out of sync longer it runs though not quickly. > > I have another box running 6.4 that is also having the same issue. > I am not going to bother complaining about that one because it is > too old and in more of a need to be updated. Am hoping to update > both over the coming holidays. I see what looks like the same with -current too, I usually have filter-routes on most firewalls/routers to reduce cpu load (especially if running dynamic routing protocols) so I have to ignore results from those machines because they will definitely miss any changes made after the initial load[1], After hunting around I found some other machines that don't use filter-routes and do have a mismatch between arp -an and ipNetToMediaTable entries (I suppose the simplest query to find these is a plain snmpwalk on ipNetToMediaPhysAddress). I only usually see either the same number or one fewer address in ipNetToMediaTable than arp -an. I wanted to see if I could spot anything in snmpd debug output (snmpd -dv) when this happened so I ran this in one terminal $ while true; do echo `snmp walk -v 2c -c public 82.68.199.132 ipNetToMediaPhysAddress|grep -c [H]ex-STRING` `arp -an | grep -c :`; sleep .5; done to show up discrepancies while running "arp -da" in another several times. The debug output was pretty noisy so I started a
Re: Import seq(1) from FreeBSD
On 2020/11/16 05:49, Todd C. Miller wrote: > This is originally from NetBSD but FreeBSD appears to have some > additional fixes. > > I know we have jot(1) but seq(1) is considerably easier to use for > simple things and at this point, most other systems have it. OK with me. If this goes in then patches/symlinks can be removed from a handful of ports (they're mostly taught to use gseq from coreutils). devel/ccache devel/universal-ctags mail/notmuch/notmuch net/isc-bind net/munin net/rrdtool security/cvechecker
Re: AUDIORECDEVICE environment variable in sndio lib
On 2020/11/17 17:13, Peter J. Philipp wrote:
> Hi,
>
> I have a mic on snd/1 and speakers on snd/0. I had tried a lot of different
> settings with audacity port but couldn't get this to work, so I chose the
> method of last resort. Below is a patch to allow an AUDIORECDEVICE
> environment
> variable specifying the wanted microphone.
This seems a worthwhile addition.
> Index: sio.c
> ===
> RCS file: /cvs/src/lib/libsndio/sio.c,v
> retrieving revision 1.24
> diff -u -p -u -r1.24 sio.c
> --- sio.c 29 Jun 2019 06:05:26 - 1.24
> +++ sio.c 17 Nov 2020 16:13:04 -
> @@ -43,6 +43,7 @@ sio_open(const char *str, unsigned int m
> {
> static char devany[] = SIO_DEVANY;
> struct sio_hdl *hdl;
> + char *rec = NULL;
>
> #ifdef DEBUG
> _sndio_debug_init();
> @@ -55,6 +56,12 @@ sio_open(const char *str, unsigned int m
> str = getenv("AUDIODEVICE");
> if (str == NULL)
> str = devany;
> + rec = getenv("AUDIORECDEVICE");
> + if (rec == NULL)
> + rec = devany;
> +
> + if (rec && mode == SIO_REC)
> + str = rec;
If AUDIORECDEVICE is unset, it would be better to fallback to
AUDIODEVICE rather than directly to devany.
Re: AUDIORECDEVICE environment variable in sndio lib
On 2020/11/17 18:23, Peter J. Philipp wrote:
> On Tue, Nov 17, 2020 at 05:09:28PM +0000, Stuart Henderson wrote:
> > On 2020/11/17 17:13, Peter J. Philipp wrote:
> > > Hi,
> > >
> > > I have a mic on snd/1 and speakers on snd/0. I had tried a lot of
> > > different
> > > settings with audacity port but couldn't get this to work, so I chose the
> > > method of last resort. Below is a patch to allow an AUDIORECDEVICE
> > > environment
> > > variable specifying the wanted microphone.
> >
> > This seems a worthwhile addition.
> >
> > > Index: sio.c
> > > ===
> > > RCS file: /cvs/src/lib/libsndio/sio.c,v
> > > retrieving revision 1.24
> > > diff -u -p -u -r1.24 sio.c
> > > --- sio.c 29 Jun 2019 06:05:26 - 1.24
> > > +++ sio.c 17 Nov 2020 16:13:04 -
> > > @@ -43,6 +43,7 @@ sio_open(const char *str, unsigned int m
> > > {
> > > static char devany[] = SIO_DEVANY;
> > > struct sio_hdl *hdl;
> > > + char *rec = NULL;
> > >
> > > #ifdef DEBUG
> > > _sndio_debug_init();
> > > @@ -55,6 +56,12 @@ sio_open(const char *str, unsigned int m
> > > str = getenv("AUDIODEVICE");
> > > if (str == NULL)
> > > str = devany;
> > > + rec = getenv("AUDIORECDEVICE");
> > > + if (rec == NULL)
> > > + rec = devany;
> > > +
> > > + if (rec && mode == SIO_REC)
> > > + str = rec;
> >
> > If AUDIORECDEVICE is unset, it would be better to fallback to
> > AUDIODEVICE rather than directly to devany.
>
> This is a good suggestion! Thanks! I have updated the patch. I also
> appreciate Solene's offer for manpage addition, thanks!
>
> New diff follows... let me know if it can be done better, I won't be able
> to update it until tomorrow.
>
> -peter
>
> Index: sio.c
> ===
> RCS file: /cvs/src/lib/libsndio/sio.c,v
> retrieving revision 1.24
> diff -u -p -u -r1.24 sio.c
> --- sio.c 29 Jun 2019 06:05:26 - 1.24
> +++ sio.c 17 Nov 2020 17:18:57 -
> @@ -43,6 +43,7 @@ sio_open(const char *str, unsigned int m
> {
> static char devany[] = SIO_DEVANY;
> struct sio_hdl *hdl;
> + char *rec = NULL;
>
> #ifdef DEBUG
> _sndio_debug_init();
> @@ -55,6 +56,12 @@ sio_open(const char *str, unsigned int m
> str = getenv("AUDIODEVICE");
> if (str == NULL)
> str = devany;
> + rec = getenv("AUDIORECDEVICE");
> + if (rec == NULL)
> + rec = str;
> +
> + if (rec && mode == SIO_REC)
> + str = rec;
the "if rec == NULL" needs to go for that to work; simplifies the diff
nicely too :)
Index: sio.c
===
RCS file: /cvs/src/lib/libsndio/sio.c,v
retrieving revision 1.24
diff -u -p -r1.24 sio.c
--- sio.c 29 Jun 2019 06:05:26 - 1.24
+++ sio.c 17 Nov 2020 17:27:42 -
@@ -43,6 +43,7 @@ sio_open(const char *str, unsigned int m
{
static char devany[] = SIO_DEVANY;
struct sio_hdl *hdl;
+ char *rec = NULL;
#ifdef DEBUG
_sndio_debug_init();
@@ -55,6 +56,9 @@ sio_open(const char *str, unsigned int m
str = getenv("AUDIODEVICE");
if (str == NULL)
str = devany;
+ rec = getenv("AUDIORECDEVICE");
+ if (rec && mode == SIO_REC)
+ str = rec;
}
if (strcmp(str, devany) == 0) {
hdl = _sio_aucat_open("snd/0", mode, nbio);
Index: sioctl.c
===
RCS file: /cvs/src/lib/libsndio/sioctl.c,v
retrieving revision 1.1
diff -u -p -r1.1 sioctl.c
--- sioctl.c26 Feb 2020 13:53:58 - 1.1
+++ sioctl.c17 Nov 2020 17:27:42 -
@@ -28,6 +28,7 @@ sioctl_open(const char *str, unsigned in
{
static char devany[] = SIO_DEVANY;
struct sioctl_hdl *hdl;
+ char *rec = NULL;
#ifdef DEBUG
_sndio_debug_init();
@@ -38,6 +39,9 @@ sioctl_open(const char *str, unsigned in
str = getenv("AUDIODEVICE");
if (str == NULL)
str = devany;
+ rec = getenv("AUDIORECDEVICE");
+ if (rec && mode == SIO_REC)
+ str = rec;
}
if (strcmp(str, devany) == 0) {
hdl = _sioctl_aucat_open("snd/0", mode, nbio);
Re: Ryzen 5800X hw.setperf vs hw.cpuspeed
On 2020/11/20 07:41, Bryan Steele wrote: > At least on a desktop I'd suggest to leaved apmd(8) and not do any > manual hw.setperf tweaking, you should have adequate cooling the planet doesn't! :/
Re: clean /dev from /etc/daily ?
On 2020/11/23 09:31, Bryan Steele wrote: > On Mon, Nov 23, 2020 at 03:25:34PM +0100, Otto Moerbeek wrote: > > tOn Mon, Nov 23, 2020 at 01:53:01PM +0100, Solene Rapenne wrote: > > > > > A common mistake when using dd is to create a file in /dev which > > > fills up the space of / and may stay silent until / gets filled up > > > by something else that will fail. > > > > > > Would it be OK to add this in /etc/daily? > > > > > > find /dev -type f ! -name MAKEDEV -delete > > > > > > AFAIK /dev should have only MAKEDEV as a regular file. > > > hier(7) says /dev only have block and character devices > > > with the exception of MAKEDEV. > > > > > > > reporting is good, but deleting not. > > > > -Otto > > ^^ > > I like this option a lot more, as users will get an opportunity to > learn. I don't object to reporting (I do object to automatically deleting), but realistically for many people who would make this mistake, the daily mails are just going to build up unread in /var/mail/$USER...
wg(4), change port in example
Trying out the example from wg(4) I ran into this: # ifconfig wg1 192.168.5.1/24 ifconfig: SIOCAIFADDR: Address already in use After some head scratching it turns out that it's not complaining about anything set on the line immediately resulting in the error, but instead it's really wgport (that was set previously) colliding with portmap on port 111. Would it make sense to at least use ports in the example that aren't used by a common daemon? Index: wg.4 === RCS file: /cvs/src/share/man/man4/wg.4,v retrieving revision 1.5 diff -u -p -r1.5 wg.4 --- wg.429 Sep 2020 19:37:08 - 1.5 +++ wg.424 Nov 2020 15:02:50 - @@ -138,14 +138,14 @@ but demonstrates two interfaces on the s .Bd -literal #!/bin/sh -ifconfig wg1 create wgport 111 wgkey `openssl rand -base64 32` rdomain 1 -ifconfig wg2 create wgport 222 wgkey `openssl rand -base64 32` rdomain 2 +ifconfig wg1 create wgport 7111 wgkey `openssl rand -base64 32` rdomain 1 +ifconfig wg2 create wgport 7222 wgkey `openssl rand -base64 32` rdomain 2 PUB1="`ifconfig wg1 | grep 'wgpubkey' | cut -d ' ' -f 2`" PUB2="`ifconfig wg2 | grep 'wgpubkey' | cut -d ' ' -f 2`" -ifconfig wg1 wgpeer $PUB2 wgendpoint 127.0.0.1 222 wgaip 192.168.5.2/32 -ifconfig wg2 wgpeer $PUB1 wgendpoint 127.0.0.1 111 wgaip 192.168.5.1/32 +ifconfig wg1 wgpeer $PUB2 wgendpoint 127.0.0.1 7222 wgaip 192.168.5.2/32 +ifconfig wg2 wgpeer $PUB1 wgendpoint 127.0.0.1 7111 wgaip 192.168.5.1/32 ifconfig wg1 192.168.5.1/24 ifconfig wg2 192.168.5.2/24 .Ed
wg(4) manpage tweaks
It's not very clear how to fetch the pubkey. OK to add this to wg(4)? Index: wg.4 === RCS file: /cvs/src/share/man/man4/wg.4,v retrieving revision 1.6 diff -u -p -r1.6 wg.4 --- wg.424 Nov 2020 16:33:05 - 1.6 +++ wg.427 Nov 2020 12:28:32 - @@ -64,6 +64,9 @@ interface may be configured to recognise .It Key Each peer uses its private key and corresponding public key to identify itself to others. +The public key may be displayed by running +.Xr ifconfig 8 +as root after configuring the private key. A peer configures a .Nm wg interface with its own private key and with the public keys of its peers. @@ -138,9 +141,11 @@ but demonstrates two interfaces on the s .Bd -literal #!/bin/sh +# create interfaces, set random private keys ifconfig wg1 create wgport 7111 wgkey `openssl rand -base64 32` rdomain 1 ifconfig wg2 create wgport 7222 wgkey `openssl rand -base64 32` rdomain 2 +# retrieve the public keys associated with the private keys PUB1="`ifconfig wg1 | grep 'wgpubkey' | cut -d ' ' -f 2`" PUB2="`ifconfig wg2 | grep 'wgpubkey' | cut -d ' ' -f 2`"
Re: wg(4) manpage tweaks
On 2020/11/27 13:41, Jason McIntyre wrote: > > +++ wg.427 Nov 2020 12:28:32 - > > @@ -64,6 +64,9 @@ interface may be configured to recognise > > .It Key > > Each peer uses its private key and corresponding public key to > > identify itself to others. > > +The public key may be displayed by running > > +.Xr ifconfig 8 > > +as root after configuring the private key. > > A peer configures a > > .Nm wg > > interface with its own private key and with the public keys of its peers. > > i'm not sure about this text. wouldn;t the "Keys" section make more > sense? the "Keys" section itself says: > >When an interface has a private key set with wgkey, the >corresponding public key is shown in the status output of >the interface, like so: > > wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > maybe we should just elaborate here? Ah yes, that does seem a better place, maybe this helps, though perhaps the addition to the example script is enough to give the hint anyway. Index: man4/wg.4 === RCS file: /cvs/src/share/man/man4/wg.4,v retrieving revision 1.7 diff -u -p -r1.7 wg.4 --- man4/wg.4 27 Nov 2020 14:04:49 - 1.7 +++ man4/wg.4 27 Nov 2020 14:08:56 - @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st When an interface has a private key set with .Nm wgkey , the corresponding -public key is shown in the status output of the interface, like so: +public key is shown in the status output of the interface +displayed by +.Xr ifconfig 8 +when run as root, like so: .Bd -literal -offset indent wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= .Ed > i agree a bit of explanation makes sense here. saying that, you should > really join "create interfaces" and "set random private keys" with a > semicolon or "and" or somesuch, not a comma. I've committed that with a semicolon.
Re: wg(4) manpage tweaks
On 2020/11/27 14:17, Jason McIntyre wrote: > On Fri, Nov 27, 2020 at 02:09:57PM +0000, Stuart Henderson wrote: > > On 2020/11/27 13:41, Jason McIntyre wrote: > > > > +++ wg.427 Nov 2020 12:28:32 - > > > > @@ -64,6 +64,9 @@ interface may be configured to recognise > > > > .It Key > > > > Each peer uses its private key and corresponding public key to > > > > identify itself to others. > > > > +The public key may be displayed by running > > > > +.Xr ifconfig 8 > > > > +as root after configuring the private key. > > > > A peer configures a > > > > .Nm wg > > > > interface with its own private key and with the public keys of its > > > > peers. > > > > > > i'm not sure about this text. wouldn;t the "Keys" section make more > > > sense? the "Keys" section itself says: > > > > > >When an interface has a private key set with wgkey, the > > >corresponding public key is shown in the status output of > > >the interface, like so: > > > > > > wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > > > > > maybe we should just elaborate here? > > > > Ah yes, that does seem a better place, maybe this helps, though > > perhaps the addition to the example script is enough to give the > > hint anyway. > > > > Index: man4/wg.4 > > === > > RCS file: /cvs/src/share/man/man4/wg.4,v > > retrieving revision 1.7 > > diff -u -p -r1.7 wg.4 > > --- man4/wg.4 27 Nov 2020 14:04:49 - 1.7 > > +++ man4/wg.4 27 Nov 2020 14:08:56 - > > @@ -124,7 +124,10 @@ will accept any random 32-byte base64 st > > When an interface has a private key set with > > .Nm wgkey , > > the corresponding > > -public key is shown in the status output of the interface, like so: > > +public key is shown in the status output of the interface > > +displayed by > > +.Xr ifconfig 8 > > +when run as root, like so: > > .Bd -literal -offset indent > > wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= > > .Ed > > > > > > fine by me. i tried to think if we had any precedent in the man pages > for this, where output is exposed by root, but couldn't. i thought our > wireless interfaces did sth like that. > > i also tried to shorten your text but couldn;t come up with anything > better. > so ok. > jmc > Alternatively: Index: wg.4 === RCS file: /cvs/src/share/man/man4/wg.4,v retrieving revision 1.7 diff -u -p -r1.7 wg.4 --- wg.427 Nov 2020 14:04:49 - 1.7 +++ wg.427 Nov 2020 14:28:03 - @@ -125,8 +125,9 @@ When an interface has a private key set .Nm wgkey , the corresponding public key is shown in the status output of the interface, like so: -.Bd -literal -offset indent -wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= +.Bd -literal +# ifconfig wg1 | grep wgpubkey + wgpubkey NW5l2q2MArV5ZXpVXSZwBOyqhohOf8ImDgUB+jPtJps= .Ed .Sh EXAMPLES Create two
libressl pc files
Several ports are patched to cope with the version number in pkgconfig
files for libressl libs (currently all at 1.0.0)
portoriginally wanted
lang/php/7.2>= 1.0.1
lang/php/7.3>= 1.0.1
lang/php/7.4>= 1.0.1
multimedia/xine-lib >= 1.0.2
security/opensc >= 1.0.1
www/e2guardian >= 1.0.1
textproc/mupdf >= 1.1.0
instrumenting pkg-config these are the rest of what's wanted:
audio/pulseaudio> 0.9
emulators/retroarch >= 1.0.0
games/warzone2100 >= 1.0.0
mail/opendkim >= 0.9.7
multimedia/gstreamer-0.10/plugins-bad,-main >= 0.9.5
net/openvpn >= 1.0.2
net/qbittorrent/qbittorrent-nox >= 1.0
net/qbittorrent/qbittorrent >= 1.0
net/seafile/client >= 0.98
net/transmission,-gtk >= 0.9.7
print/qpdf >= 1.1.0
productivity/grisbi >= 1.0.0
security/libbde >= 1.0
security/libewf >= 1.0
security/xca>= 0.9.8
security/xmlsec,-main >= 1.0.0
sysutils/libfsapfs >= 1.0
sysutils/libfvde>= 1.0
sysutils/libluksde >= 1.0
sysutils/libqcow>= 1.0
sysutils/libsmraw >= 1.0
sysutils/syslog-ng >= 0.9.8
www/aria2 >= 0.9.8
www/nghttp2 >= 1.0.1
x11/remmina >= 1.0.0
x11/virt-viewer >= 1.0.0
x11/x11vnc >= 1.0.0
I'm wondering if it would make sense to bump the advertised
version so that at least the >= 1.0.2 checks work. Though the only
things in ports wanting 1.1.0 (mupdf, qpdf) are happy building against
libressl anyway so perhaps we should just change it to 2.0.0 to match
LIBRESSL_VERSION_NUMBER. (Typically pkg-config checks are just used
to detect presence of a suitable version, not to choose codepaths
for ifdefs).
Currently the version in pc files comes from SHLIB_VERSION_NUMBER
in libcrypto/opensslv.h; however that is in a section which says
"These will never change" so if we want to keep that promise then
perhaps the generate_pkgconfig.sh scripts should generate the
number for the pc files directly.
Any OKs for either of these?
Index: libcrypto/opensslv.h
===
RCS file: /cvs/src/lib/libcrypto/opensslv.h,v
retrieving revision 1.62
diff -u -p -u -1 -2 -r1.62 opensslv.h
--- libcrypto/opensslv.h18 Nov 2020 11:10:08 - 1.62
+++ libcrypto/opensslv.h25 Nov 2020 20:28:56 -
@@ -4,15 +4,15 @@
/* These will change with each release of LibreSSL-portable */
#define LIBRESSL_VERSION_NUMBER 0x303fL
/*^ Patch starts here */
#define LIBRESSL_VERSION_TEXT "LibreSSL 3.3.0"
/* These will never change */
#define OPENSSL_VERSION_NUMBER 0x2000L
#define OPENSSL_VERSION_TEXT LIBRESSL_VERSION_TEXT
#define OPENSSL_VERSION_PTEXT " part of " OPENSSL_VERSION_TEXT
#define SHLIB_VERSION_HISTORY ""
-#define SHLIB_VERSION_NUMBER "1.0.0"
+#define SHLIB_VERSION_NUMBER "2.0.0"
#endif /* HEADER_OPENSSLV_H */
or just changing generate_pkgconfig (either like this, or alternatively
ripping more out):
Index: libcrypto/generate_pkgconfig.sh
===
RCS file: /cvs/src/lib/libcrypto/generate_pkgconfig.sh,v
retrieving revision 1.2
diff -u -p -r1.2 generate_pkgconfig.sh
--- libcrypto/generate_pkgconfig.sh 3 Sep 2016 12:42:46 - 1.2
+++ libcrypto/generate_pkgconfig.sh 25 Nov 2020 20:30:06 -
@@ -53,7 +53,8 @@ fi
version_re="s/^#define[[:blank:]]+SHLIB_VERSION_NUMBER[[:blank:]]+\"(.*)\".*/\1/p"
#version_file=${curdir}/src/crypto/opensslv.h
version_file=${curdir}/opensslv.h
-lib_version=$(sed -nE ${version_re} ${version_file})
+#lib_version=$(sed -nE ${version_re} ${version_file})
+lib_version="2.0.0"
# Put -I${includedir} into Cflags so configure script tests like
# test -n "`pkg-config --cflags openssl`"
Index: libssl/generate_pkgconfig.sh
===
RCS file: /cvs/src/lib/libssl/generate_pkgconfig.sh,v
retrieving revision 1.9
diff -u -p -r1.9 generate_pkgconfig.sh
--- libssl/generate_pkgconfig.sh3 Sep 2016 12:42:42 - 1.9
+++ libssl/generate_pkgconfig.sh25 Nov 2020 20:30:06 -
@@ -52,7 +52,8 @@ fi
version_re="s/^#define[[:blank:]]+SHLIB_VERSION_NUMBER[[:blank:]]+\"(.*)\".*/\1/p"
version_file=${curdir}/../libcrypto/opensslv.h
-lib_version=$(sed -nE ${version_re} ${version_file})
+#lib_version=$(sed -nE ${version_re} ${version_file})
+lib_version="2.0.0"
# Put -I${includedir} into Cflags so configure script tests like
# test -n "`pkg-config --cflags openssl`"
wireguard + witness
Thought I'd try a WITNESS kernel to see if that gives any clues about what's going on with my APU crashing all over the place (long shot but I got bored with trying different older kernels..) I see these from time to time (one during netstart, and another 4 in 15 mins uptime), anyone know if they're important? witness: lock_object uninitialized: 0x80bcf0d8 Starting stack trace... witness_checkorder(80bcf0d8,9,0) at witness_checkorder+0xab rw_enter_write(80bcf0c8) at rw_enter_write+0x43 noise_remote_decrypt(80bcea48,978dc3d,0,fd805e22cb7c,10) at noise_remote_decrypt+0x135 wg_decap(8054a000,fd8061835200) at wg_decap+0xda wg_decap_worker(8054a000) at wg_decap_worker+0x7a taskq_thread(8012d900) at taskq_thread+0x9f end trace frame: 0x0, count: 251 End of stack trace.
Re: wireguard + witness
On 2020/12/01 10:32, Sebastien Marie wrote:
> On Tue, Dec 01, 2020 at 06:59:22AM +0100, Sebastien Marie wrote:
> > On Mon, Nov 30, 2020 at 11:14:46PM +0000, Stuart Henderson wrote:
> > > Thought I'd try a WITNESS kernel to see if that gives any clues about
> > > what's going on with my APU crashing all over the place (long shot but
> > > I got bored with trying different older kernels..)
> > >
> > > I see these from time to time (one during netstart, and another 4 in
> > > 15 mins uptime), anyone know if they're important?
> >
> > this check ("lock_object uninitialized") was recently added in witness.
> >
> > it means that the rwlock was uninitialized (the witness flag
> > LO_INITIALIZED isn't present whereas it should) when witness check the
> > lock.
> >
> > it could be:
> > - someone omits to call rw_init() or RWLOCK_INITIALIZER() (possible bug if
> > memory isn't zero)
> > - the struct has been zeroed (possible bug too)
> >
> > > witness: lock_object uninitialized: 0x80bcf0d8
> > > Starting stack trace...
> > > witness_checkorder(80bcf0d8,9,0) at witness_checkorder+0xab
> > > rw_enter_write(80bcf0c8) at rw_enter_write+0x43
> > > noise_remote_decrypt(80bcea48,978dc3d,0,fd805e22cb7c,10) at
> > > noise_remote_decrypt+0x135
> > > wg_decap(8054a000,fd8061835200) at wg_decap+0xda
> > > wg_decap_worker(8054a000) at wg_decap_worker+0x7a
> > > taskq_thread(8012d900) at taskq_thread+0x9f
> > > end trace frame: 0x0, count: 251
> > > End of stack trace.
> >
> > from the trace, the sole rw_enter_write() usage in noise_remote_decrypt() is
> >
> > rw_enter_write(&r->r_keypair_lock)
> >
> > but I am seeing few rw_init() on r_keypair_lock. I will see if I could
> > see the source of the problem.
> >
>
> Jason, Matt,
>
> sthen@ told me that the same lock is reported several times (exactly,
> two locks are reported several times: lock1, lock2, lock1, lock2...)
>
> witness(4) reports when a lock doesn't have LO_INITIALIZED flag set in
> internal part of `struct rwlock'. Next it sets it, and skip futher
> analysis for this particular lock.
>
> if the same lock is reported several times, it means the memory is
> zeroed (and so the flag removed). it could be intented or not. but in
> all cases, a rwlock should be properly initialized with rw_init() or
> RWLOCK_INITIALIZER() before use.
>
> I don't have enough experiency with wg(4) stuff to well understand the
> issue. in wg_decap(), the peer is get from a `struct wg_tag` (from
> wg_tag_get()). If i didn't mess myself, the p_remote could come from
> wg_send_initiation() or wg_send_response(). but for both, it comes
> from wg_peer_create(), and p_remote is initialized with
> noise_remote_init() (and so lock have proper rw_init()).
>
> do you have idea on the cause of the lost of the rwlock flag ?
>
> if you want to test it with witness(4) enabled, you will need to build
> a kernel with "option WITNESS" in config file. you could uncomment it
> from sys/arch/amd64/conf/GENERIC.MP, and run make config, make clean,
> make
>
> Thanks.
> --
> Sebastien Marie
>
Config of the machine is simple; one wg peer, the peer is on a fixed
internet address, this machine is natted but the address won't change.
It isn't routing, wg is only to reach the machine itself.
Here's a more complete console log but I don't think it adds anything
to the above.
pf enabled
starting network
em0: no link
em0: 192.168.42.220 lease accepted from 192.168.42.21 (00:1b:21:9b:68:10)
add net 192.168.40.0/21: gateway 192.168.43.33
add net 195.95.187.0/24: gateway 192.168.43.33
reordering libraries:witness: lock_object uninitialized: 0x80bcf580
Starting stack trace...
witness_checkorder(80bcf580,9,0) at witness_checkorder+0xab
rw_enter_write(80bcf570) at rw_enter_write+0x43
noise_remote_decrypt(80bcea48,3f71de8d,0,fd80073918fc,10) at
noise_remote_decrypt+0x135
wg_decap(8054a000,fd8067faf900) at wg_decap+0xda
wg_decap_worker(8054a000) at wg_decap_worker+0x7a
taskq_thread(8012d900) at taskq_thread+0x9f
end trace frame: 0x0, count: 251
End of stack trace.
done.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd sndiod.
starting package daemons: conserver lldpd.
starting lo
