Re: pf.conf(5) about queueing may be wrong
On 2021/08/23 19:03, Solene Rapenne wrote: > pf.conf says this in QUEUEING > https://man.openbsd.org/pf.conf#QUEUEING > > > If the referenced queue does not exist on the outgoing interface, > > the default queue for that interface is used. > > however, with this simple config > > queue std on re0 bandwidth 100M > queue lan parent std bandwidth 100M > queue internet parent std bandwidth 900K flows 512 default > match proto udp from em0:network to any port 53 queue dns > > when reloading the file with pfctl, I get the following error: > /etc/pf.conf:27: queue dns is not defined In your config, the queue "dns" does not exist _at all_ in the config. > From the man page, I understand that if the queue used in match > doesn't exist, the default queue is used, as if "queue dns" wasn't > written in the rule. The manual talks about something a bit different, a queue that does not exist _on a particular interface_. > Either the man page is wrong or not easy to understand, or the > parser is wrong. I don't think it is wrong or even really hard to understand.
Re: pf.conf(5) about queueing may be wrong
On 2021/08/23 22:21, Klemens Nanni wrote: > On Mon, Aug 23, 2021 at 07:03:45PM +0200, Solene Rapenne wrote: > > pf.conf says this in QUEUEING > > https://man.openbsd.org/pf.conf#QUEUEING > > > > > If the referenced queue does not exist on the outgoing interface, > > > the default queue for that interface is used. > > This text is outdated, pfctl gained the below error in 2014 "shortly" > after henning reworked queueing in 2013 to where that manual text dates > back. > > > however, with this simple config > > > > queue std on re0 bandwidth 100M > > queue lan parent std bandwidth 100M > > queue internet parent std bandwidth 900K flows 512 default > > match proto udp from em0:network to any port 53 queue dns > > > > when reloading the file with pfctl, I get the following error: > > /etc/pf.conf:27: queue dns is not defined > > > > From the man page, I understand that if the queue used in match > > doesn't exist, the default queue is used, as if "queue dns" wasn't > > written in the rule. > > Specified queues must exist, rules without `[set] queue ...' do use the > default queue, obviously. > > > Either the man page is wrong or not easy to understand, or the > > parser is wrong. > > OK kn to remove that sentence from the manual. > Not ok with me.
Re: allow KARL with config(8)'d kernels
On 2021/08/25 10:35, Sebastien Marie wrote: > On Tue, Aug 24, 2021 at 01:53:41PM +0200, Paul de Weerd wrote: > > I have a new machine where I'd like to use IPMI. Of course, doing > > `config -e -f /bsd` will break KARL, so I tried to find a minimal way > > of supporting this. Done by introducing a new config file, > > /etc/kernel.conf, which gets applied to the kernel reorder_kernel > > builds and installs. > > I like it: it is simple. > > but here are some thoughts (with questions and some answers, but it is > open): > > - does it integrate well with syspatch ? > > yes, syspatch will call /usr/libexec/reorder_kernel (and the > configuration will be applied) > > > - after install or upgrade, does the installed kernel (by installer) > has the configuration applied ? > > it seems not: install.sub has it owns logic and is directly calling > "make newbsd ; make install" and do not use reorder_kernel script. > > > I could see reason to avoid it, and reason to requiring it. > > > For install, no problem: the file is controlled (it doesn't > exist). It doesn't change anything. > > For upgrade, the file could exists. Should the installer using it or > not ? > > > If using it, it makes the upgrade process dependent of the file: how > to deal with an invalid file ? should the file ignored (kernel > installed but not configured) ? I don't see a reason why upgrade shouldn't use it. Invalid file handling is no more or less of a problem for upgrades than reboots. > how to deal with a format change in config(8) (file on disk in old > format, used config(8) understanding new format) ? but config(8) > doesn't change often, and could take care of both formats for one > release, and/or current.html could mention some required changes. > > > If not using it, does it is a problem that the first boot will be > different from next boot ? > > I could imagine some changes made to be the machine bootable, so the > first boot could lead to unbootable machine (but it isn't different > from now). > Questions are open: I have no problem which using or not using the > configuration file on upgrade, but I think it should be documented (to > avoid questions and/or surprises). > Somebody had an earlier method for applying kernel config changes automatically that IIRC used a bootloader based mechanism passing the config to the kernel. I think that might actually be better overall as you could bypass it at the boot loader (rather than requiring a backup "clean" kernel) though that's more work and I expect difficult to do within space constraints on some archs. I would be quite happy to have this problem solved one way or another, while a "one size fits all" kernel should be the goal, there are some workarounds needed e.g. for semi-broken hardware and I think that's always likely to be the case.
wg(4) ipv6 ospf6d
Trying to announce a network on a wg(4) interface via ospf6d, just
using passive to pick up the prefix, i.e.
interface wg0 { passive }
It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".
With -v I get 'interface with index 27 not found' (this is "normal"
with ospf6d) and the routable address does show up e.g. "if_newaddr:
ifindex 27, addr 2a03::xx:xx::/64" before giving the
unnumbered interface error. There is normally no link-local address
for wg.
If I manually configure a link-local the interface is successfully
added.
Anyone have an idea what the behaviour should be here? For passive
would it make sense to accept an interface without link-local?
Re: wg(4) ipv6 ospf6d
On 2021/08/25 13:33, Daniel Jakots wrote: > On Wed, 25 Aug 2021 18:02:11 +0100, Stuart Henderson > wrote: > > > If I manually configure a link-local the interface is successfully > > added. > > > > Anyone have an idea what the behaviour should be here? For passive > > would it make sense to accept an interface without link-local? > > I discussed about that with remi@ a few months ago when I considered > using ospf6d, as I had the same cryptic error than you give. I was told: > > > ospf6d can not work without a link-local address on the interface. > > RFC 5340 mandates the use of link-local addresses in section 2.5. > > And here's a link to the mentioned section: > https://datatracker.ietf.org/doc/html/rfc5340#section-2.5 > > Cheers, > Daniel Thanks, but in itself that doesn't give a reason to have this restriction on a "passive" interface, in that case it's only redistributing the network on the interface, not sending OSPF packets on the interface itself.
Re: wg(4) ipv6 ospf6d
On 2021/08/25 19:58, Crystal Kolipe wrote: > On Wed, Aug 25, 2021 at 06:02:11PM +0100, Stuart Henderson wrote: > > If I manually configure a link-local the interface is successfully > > added. > > > > Anyone have an idea what the behaviour should be here? For passive > > would it make sense to accept an interface without link-local? > > Is there a specific use case for leaving the interface configured without > IPv6 link-local? > > We use IPv6 extensively, (and are aware of various issues with the OpenBSD > IPv6 implementation), but I'm not aware of any advantage or problem that is > resolved by deliberately removing or not configuring link-local. If we > support this particular case of wg on such an interface, and by extension > encourage the general practice, then users with little experience of IPv6 are > likely to start shooting themselves in the foot by disabling it on a whim. > > If there is a problem somewhere that is resolved by removing IPv6 link-local, > I'm curious to know what it is. > It's not a question of "removing IPv6 link-local", with wg it is not there at all unless you go out your way and explicitly configure a link-local address.
Re: [Patch] - Add -u (update packages) to sysupgrade(8)
On 2021/08/27 23:07, Aaron Poffenberger wrote:
> On 2021-08-27 23:00 -0400, Daniel Jakots wrote:
> > On Fri, 27 Aug 2021 20:17:51 -0500, Aaron Poffenberger
> > wrote:
> >
> > > + ${PKGS} && echo "pkg_add -Iu" >> /etc/rc.firsttime
> >
> > I don't think this addition is worth it, but anyway this won't work for
I do - I do this a lot manually and it's a pain to start sysupgrade
downloading with -n, wait for it to finish, then edit the file so
would welcome a flag to do it.
I find the method helpful as it means you don't run outdated packages
after reboot (which might even crash after some updates) and don't need
to reboot 3 times (to bsd.rd for sysupgrade, then to the new kernel,
then again to restart package daemons etc) which takes flipping ages on
some servers.
It's not perfect because some packages ask questions if pkg_adf is
run in interactive mode (mostly just postgresql across major version
updates). Aaron's diff uses -I to disable that which stops those
packages from getting updated when the trigger condition applies,
but that's not very common in the ports tree and doesn't make it
less useful.
The point at which rc.firsttime runs is after sshd starts, so if the
package update does run into any problems you can still connect in
to fix, and progress can be seen in "dmesg -s" or syslog.
> > people running -current when it's release time and the release isn't
> > available yet (-Dsnap).
sysupgrade itself doesn't work properly in that case either, you need
tricks to get from "not quite release but the -beta suffix was removed"
to actual release. I think there might be other problems with the
system relating to version handling in that time too. Basically we just
need to keep that to the smallest possible time window.
> Initially I considered a PKG_ADD environment variable to let the
> override the command concatenated to /etc/rc.firsttime, but held
> off until needed. Something like the following would resolve that
> concern.
>
> PKG_ADD='pkg_add -Iu -Dsnap' sysupgrade -u
No need for that complexity, just set a variable to -Dsnap if sysupgrade
-s was used and include it on the line that adds pkg_add to the file.
Bikeshed: I think I'd prefer using a -p flag to signify packages rather
than -u.
Re: wg(4) ipv6 ospf6d
On 2021/08/25 22:23, Sebastian Benoit wrote:
> Stefan Sperling(s...@stsp.name) on 2021.08.25 22:02:02 +0200:
> > On Wed, Aug 25, 2021 at 08:13:26PM +0200, Florian Obser wrote:
> > > On 2021-08-25 18:02 +01, Stuart Henderson wrote:
> > > > Trying to announce a network on a wg(4) interface via ospf6d, just
> > > > using passive to pick up the prefix, i.e.
> > > >
> > > > interface wg0 { passive }
> > > >
> > > > It's failing with "/etc/ospf6d.conf:10: unnumbered interface wg0".
> > > >
> > > > With -v I get 'interface with index 27 not found' (this is "normal"
> > > > with ospf6d) and the routable address does show up e.g. "if_newaddr:
> > > > ifindex 27, addr 2a03::xx:xx::/64" before giving the
> > > > unnumbered interface error. There is normally no link-local address
> > > > for wg.
> > > >
> > > > If I manually configure a link-local the interface is successfully
> > > > added.
> > > >
> > > > Anyone have an idea what the behaviour should be here? For passive
> > > > would it make sense to accept an interface without link-local?
> > > >
> > >
> > > RFC 4291 2.1:
> > >All interfaces are required to have at least one Link-Local unicast
> > >address.
> >
> > If you're not using the interface to send or receive OSPF messages this
> > should not matter. I doubt the RFC authors considered the possibility
> > of an IPv6-capable interface that doesn't support link-local.
>
> Thats because by definition it's not IPv6 capable :-P
>
> In this case, it should be possible to distribute a route that points to the
> wg peer using
>
> redistribute _prefix_ depend on wg0
>
> instead of using passive.
>
> If that does not work i would like to know why.
>
Yes this does work and I think I prefer it, thanks.
(I had problems either with "redistribute" or with my expectations of
what it would do before, but this seems alright..)
Re: [patch] traceroute timeouts
OK? Index: traceroute.8 === RCS file: /cvs/src/usr.sbin/traceroute/traceroute.8,v retrieving revision 1.69 diff -u -p -w -r1.69 traceroute.8 --- traceroute.811 Feb 2020 18:41:39 - 1.69 +++ traceroute.828 Aug 2021 08:56:20 - @@ -201,7 +201,7 @@ and are listed. .It Fl w Ar waittime Set the time, in seconds, to wait for a response to a probe. -The default is 5. +The default is 3. .It Fl x Print the ICMP extended headers if available. This option is not available for IPv6. Index: traceroute.c === RCS file: /cvs/src/usr.sbin/traceroute/traceroute.c,v retrieving revision 1.164 diff -u -p -w -r1.164 traceroute.c --- traceroute.c12 Jul 2021 15:09:21 - 1.164 +++ traceroute.c28 Aug 2021 08:56:20 - @@ -351,7 +351,7 @@ main(int argc, char *argv[]) rcvsock4 = rcvsock6 = sndsock4 = sndsock6 = -1; v4sock_errno = v6sock_errno = 0; - conf->waittime = 5 * 1000; + conf->waittime = 3 * 1000; if ((rcvsock6 = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6)) == -1) v6sock_errno = errno; @@ -554,9 +554,9 @@ main(int argc, char *argv[]) err(1, "setsockopt SO_RTABLE"); break; case 'w': - conf->waittime = strtonum(optarg, 2, INT_MAX, &errstr); + conf->waittime = strtonum(optarg, 1, INT_MAX, &errstr); if (errstr) - errx(1, "wait must be >1 sec."); + errx(1, "wait must be >=1 sec."); conf->waittime *= 1000; break; case 'x':
arm64 rpi4 upgrade, "Failed to install bootblocks" at end
Spotted this at the end of a sysupgrade run. No issue with the reboot but it doesn't look quite right, in particular the newfs_msdos is a bit scary. [...] Installing xshare70.tgz 100% |**| 4505 KB00:36 Installing xfont70.tgz 100% |**| 39344 KB01:47 Installing xserv70.tgz 100% |**| 12346 KB00:11 Location of sets? (disk http nfs or 'done') [done] done Making all device nodes... done. sh: /sbin/fsck_msdos: not found newfs_msdos: /dev/rsd0i is mounted on /mnt/boot installboot: unable to mount EFI System partition: Device busy Failed to install bootblocks. You will not be able to boot OpenBSD from sd0. syncing disks... done rebooting...
Re: arm64 rpi4 upgrade, "Failed to install bootblocks" at end
On 2021/08/28 22:28, Stuart Henderson wrote: > Spotted this at the end of a sysupgrade run. No issue with the reboot but > it doesn't look quite right, in particular the newfs_msdos is a bit scary. > > [...] > Installing xshare70.tgz 100% |**| 4505 KB00:36 > > Installing xfont70.tgz 100% |**| 39344 KB01:47 > > Installing xserv70.tgz 100% |**| 12346 KB00:11 > > Location of sets? (disk http nfs or 'done') [done] done > Making all device nodes... done. > sh: /sbin/fsck_msdos: not found > newfs_msdos: /dev/rsd0i is mounted on /mnt/boot Oh and I see why I hit it now, I have this from when I was trying various u-boot changes (to make it easier to update the files from the booted system). $ grep boot /etc/fstab a3d7f93f60aec212.i /boot msdos rw,noatime 1 1
Re: [Patch] - Add -u (update packages) to sysupgrade(8)
On 2021/08/28 09:26, Sebastien Marie wrote: > On Fri, Aug 27, 2021 at 08:17:51PM -0500, Aaron Poffenberger wrote: > > Following is patch to add a flag to upgrade packages during > > rc.firsttime after a sysupgrade. > > > > if you need this flag, is it a ponctual usage (running sysupgrade with > the flag or not, depending the moment) ? or you will use it everytime > you use sysupgrade ? For my normal use, I decide at the time I run sysupgrade whether I want to update packages or not (if it's just a small bump in base, or I'm updating to test something quickly and it won't matter about packages, then I'll often skip it to save time - also I'll skip it if I know there's a major pgsql update in the way). I'd say my "more common" case would be to _not_ update. > for permanent usage, I would recommand using existing facility: the > /upgrade.site script. That's handy and I didn't know about it (though it does break /u for /usr tab-completion though :p). I don't think I'll use it for this usage but it's nice to have.
Re: async traceroute(8)
On 2021/09/01 11:25, Florian Obser wrote: > So traceroute sends one probe, waits upto 5^W3 seconds for an answer to > arrive, sends the next probe and so on. > > This makes it a bit faster (10x on a path with two intermediate systems > not answering) by sending probes, waiting for the answer and doing > reverse DNS lookups async. Basics are working here with icmp and udp. -A doesn't work reliably, try it with an empty cache - I think it only prints if the route lookup had a reply before the rdns lookup. I don't know libevent, is it possible to reset the timer and skip the 30ms delay if a response is received? Currently it's a little slower for the case where all hops respond. Hosts that don't respond result in a lot of *'s printed quickly, maybe scrolling the useful output off the terminal. The overall output is the same as the sequential version if you actually leave it to finish but most users would have hit ^C by then. I don't know what could be done to improve it (suppressing multiple * * * lines might help?) but user experience with that isn't great as-is. Try mp3.com for an example.
Re: timeout: Prettify man page and usage
On 2021/09/02 08:56, Job Snijders wrote: > On Thu, Sep 02, 2021 at 07:23:26AM +0100, Jason McIntyre wrote: > > > .Ar time > > > -can be integer or decimal numbers. > > > +are positive integer or real (decimal) numbers, with an optional > > > > can you have a negative timeout? > > Negative values are not permitted > > $ timeout -- -1 /bin/ls > timeout: invalid duration: Undefined error: 0 that's a terrible error message ;)
Re: OpenSSH: RSA/SHA1 disabled by default
On 2021/09/07 14:40, Martijn van Duren wrote: > On Mon, 2021-08-30 at 10:08 +1000, Damien Miller wrote: > > Hi, > > > > RSA/SHA1, a.k.a the "ssh-rsa" signature type is now disabled by default > > in OpenSSH. > > > > While The SSH protocol confusingly uses overlapping names for key and > > signature algorithms, this does not stop the use of RSA keys and there > > is no need to regenerate "ssh-rsa" keys - most servers released in the > > last five years will automatically negotiate the use of RSA/SHA-256/512 > > signatures. > > > > This has been coming for a long time, but I do expect it will be > > distruptive for some people as there are likely to be some devices > > out there that cannot be upgraded to support the safer algorithms. > > > > In these cases, it is possible to selectively re-enable RSA/SHA1 > > support by specifying PubkeyAcceptedAlgorithms=+ssh-rsa in the > > ssh_config(5) or sshd_config(5) for the endpoint. > > > > Please report any problems here, to bugs@ or to openssh@ > > > > Thanks, > > Damien > > > Just did an update to the latest snapshot and this breaks connection > to one of the older hosts I still need to connect to from time to time. > > Reverting this diff fixes the issue for me. > > According to -G it should work: > > $ ssh -G -oPubkeyAcceptedAlgorithms=ssh-rsa 10.255.3.242 | grep -i > PubkeyAcceptedAlgorithms > pubkeyacceptedalgorithms ssh-rsa -oHostKeyAlgorithms=+ssh-rsa It works, I have disabled ssh-rsa by default for ages and have set that for various cisco/procurve switches that I need to connect to.
Re: OpenSSH: RSA/SHA1 disabled by default
On 2021/09/08 09:03, Damien Miller wrote: > This is a case of the host key algorithm not matching, so you > should use HostKeyAlgorithms=+ssh-rsa - I'll make sure to mention > this in the release notes. People seem to really be having a hard time grasping what's being disabled by default. And it doesn't help with the confusion that a large well-known site doing a lot of SSH traffic for many users are handling ssh-rsa deprecation as "old user RSA keys will still work with SHA-1 but new ones will need SHA-2" (creating an artificial link between user keys and host key algorithm that doesn't exist in the protocol).
Re: Change vm_dsize to vsize_t
On 2021/09/09 06:47, Greg Steuck wrote: > Mark Kettenis writes: > > >> From: "Theo de Raadt" > >> Date: Tue, 07 Sep 2021 07:08:19 -0600 > >> > >> Or we could coordinate the Greg approach as a sysctl ABI change near a > >> libc major bump. On the other side of such a bump, all kernel + base + > >> packages are updated to use the new storage ABI. We get orderly .h > >> files without a confusing glitch, and kern_sysctl.c doesn't need to > >> store the value into two fields (32bit and 64bit) for the forseeable > >> future. > >> > >> Over the years I've arrived at the conclusion that maintaining binary > >> compatibility at all costs collects too much confusing damage. Instead, > >> we've built an software ecosystem where ABI changes are expected and > >> carry minimal consequence. Sadly rust and especially go made a different decision about that. > I'd take some short term intense pain over a long term nagging one. I'll > try to beg somebody with a full unpacked source ports tree to grep for > p_vm_dsize. Superficially, I only see it in a single patch: > > /usr/ports/databases/mongodb/patches/patch-src_mongo_util_processinfo_openbsd_cpp I think it's a change to kinfo_proc in general that is more of a problem than the individual member. The last big change in that area was supposed to be to avoid this pain - indeed kvm_getprocs manual says If the size of the kinfo_proc structure increases in size in a future release of OpenBSD, the library will only return the requested amount of data for each array entry and programs that use kvm_getprocs() will continue to function without the need for recompilation. FWIW search results for p_vm_dsize from 15 month old unpacked src: u/lcdproc-0.5.5/lcdproc-0.5.5/clients/lcdproc/machine_NetBSD.c 73:#define PROCSIZE(pp) ((pp)->p_vm_tsize + (pp)->p_vm_dsize + (pp)->p_vm_ssize) u/mongodb-3.2.22/mongodb-src-r3.2.22/src/mongo/util/processinfo_openbsd.cpp 114:return ((task->p_vm_dsize + task->p_vm_ssize + task->p_vm_tsize) * sysconf(_SC_PAGESIZE)) / u/libgtop2-2.40.0/libgtop-2.40.0/sysdeps/openbsd/procmem.c 125: (pinfo[0].p_vm_tsize + pinfo[0].p_vm_dsize + pinfo[0].p_vm_ssize) u/libgtop2-2.40.0/libgtop-2.40.0/sysdeps/openbsd/procsegment.c 74: buf->data_rss = pinfo[0].p_vm_dsize * pagesize; u/spidermonkey68-68.9.0/firefox-68.9.0/third_party/python/psutil/psutil/_psutil_bsd.c 240:vms = (long)(kp.p_vm_dsize + kp.p_vm_ssize + kp.p_vm_tsize) * pagesize; 248:memdata = (long)kp.p_vm_dsize * pagesize; u/spidermonkey68-68.9.0/firefox-68.9.0/xpcom/base/nsMemoryReporterManager.cpp 178: ((kp.p_vm_dsize + kp.p_vm_ssize + kp.p_vm_tsize) * getpagesize()) u/thunderbird-68.9.0/thunderbird-68.9.0/xpcom/base/nsMemoryReporterManager.cpp 178: ((kp.p_vm_dsize + kp.p_vm_ssize + kp.p_vm_tsize) * getpagesize()) u/thunderbird-68.9.0/thunderbird-68.9.0/third_party/python/psutil/psutil/_psutil_bsd.c 240:vms = (long)(kp.p_vm_dsize + kp.p_vm_ssize + kp.p_vm_tsize) * pagesize; 248:memdata = (long)kp.p_vm_dsize * pagesize; u/net-snmp-5.8.1.pre2/net-snmp-5.8.1.pre2/agent/mibgroup/host/hr_swrun.c 1273:proc_table[LowProcIndex].p_vm_dsize; 1295:proc_table[LowProcIndex].p_vm_dsize; u/zabbix-4.0.19-no_server/zabbix-4.0.19/src/libs/zbxsysinfo/netbsd/proc.c 169:value = pproc->p_vm_tsize + pproc->p_vm_dsize + pproc->p_vm_ssize; u/zabbix-4.0.19-no_server/zabbix-4.0.19/src/libs/zbxsysinfo/openbsd/proc.c 45:#define ZBX_P_VM_DSIZE p_vm_dsize 53:#define ZBX_P_VM_DSIZE kp_eproc.e_vm.vm_dsize 262:value = proc[i].ZBX_P_VM_TSIZE + proc[i].ZBX_P_VM_DSIZE + proc[i].ZBX_P_VM_SSIZE; u/zabbix-4.0.19-mysql/zabbix-4.0.19/src/libs/zbxsysinfo/netbsd/proc.c 169:value = pproc->p_vm_tsize + pproc->p_vm_dsize + pproc->p_vm_ssize; u/zabbix-4.0.19-mysql/zabbix-4.0.19/src/libs/zbxsysinfo/openbsd/proc.c 45:#define ZBX_P_VM_DSIZE p_vm_dsize 53:#define ZBX_P_VM_DSIZE kp_eproc.e_vm.vm_dsize 262:value = proc[i].ZBX_P_VM_TSIZE + proc[i].ZBX_P_VM_DSIZE + proc[i].ZBX_P_VM_SSIZE; u/zabbix-4.0.19-pgsql/zabbix-4.0.19/src/libs/zbxsysinfo/netbsd/proc.c 169:value = pproc->p_vm_tsize + pproc->p_vm_dsize + pproc->p_vm_ssize; u/zabbix-4.0.19-pgsql/zabbix-4.0.19/src/libs/zbxsysinfo/openbsd/proc.c 45:#define ZBX_P_VM_DSIZE p_vm_dsize 53:#define ZBX_P_VM_DSIZE kp_eproc.e_vm.vm_dsize 262:value = proc[i].ZBX_P_VM_TSIZE + proc[i].ZBX_P_VM_DSIZE + proc[i].ZBX_P_VM_SSIZE; u/zabbix-4.0.19-sqlite3/zabbix-4.0.19/src/libs/zbxsysinfo/netbsd/proc.c 169:value = pproc->p_vm_tsize + pproc->p_vm_dsize + pproc->p_vm_ssize; u/zabbix-4.0.19-sqlite3/zabbix-4.0.19/src/libs/zbxsysinfo/openbsd/proc.c 45:#define ZBX_P_VM_DSIZE p_vm_dsize 53:#define ZBX_P_VM_DSIZE kp_eproc.e_vm.vm_dsize 262:value = proc[i].ZBX_P_VM_TSIZE + proc[i].ZBX_P_VM_DSIZE +
Re: Diff: Function Length Reduction
On 2021/09/10 00:27, VARIK VALEFOR wrote: > P.S. s/originalBuf/vp->buffer/g I think this is a good demonstration of why sometimes it's better to have longer but simpler code.
Re: Diff: Function Length Reduction
On 2021/09/10 16:39, VARIK VALEFOR wrote: > Is any particular aspect of the replacement code bad? The use of 'magic number' ASCII values obfuscates what the code is doing.
Re: new usb id for urtwn
On 2018/07/11 16:27, Mikhail wrote:
> Ping? Ok?
>
> On Thu, 21 Jun 2018 at 18:28, Mikhail wrote:
>
> > Taken from FreeBSD:
> >
> > diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
> > index 0e204a196b1..d9aee16b05f 100644
> > --- a/sys/dev/usb/if_urtwn.c
> > +++ b/sys/dev/usb/if_urtwn.c
> > @@ -306,6 +306,7 @@ static const struct urtwn_type {
> > URTWN_DEV_8192CU(TRENDNET, RTL8192CU),
> > URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
> > /* URTWN_RTL8188E */
> > + URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
> > URTWN_DEV_8188EU(DLINK, DWA123D1),
> > URTWN_DEV_8188EU(DLINK, DWA125D1),
> > URTWN_DEV_8188EU(ELECOM,WDC150SU2M),
> >
Not OK. Try compiling it...
Re: Next command of GDB does not work properly unusual
On 2018/07/12 16:16, YASUOKA Masahiko wrote:
> Hi,
>
> > The next command of GDB does not work properly.
> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
>
> It seems that gdb can't read the dwarf generated by clang properly.
> I found a better fix at the upstream.
>
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ca5f395d6255337974262b4a6f40da531fcf6204
>
> ok?
I believe that is a post-GPLv3 commit..
> Index: gnu/usr.bin/binutils/gdb/dwarf2read.c
> ===
> RCS file: /var/cvs/openbsd/src/gnu/usr.bin/binutils/gdb/dwarf2read.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 dwarf2read.c
> --- gnu/usr.bin/binutils/gdb/dwarf2read.c 27 Dec 2004 21:05:10 -
> 1.5
> +++ gnu/usr.bin/binutils/gdb/dwarf2read.c 12 Jul 2018 07:07:57 -
> @@ -6479,13 +6479,13 @@ dwarf_decode_lines (struct line_header *
> * lh->minimum_instruction_length;
> line += lh->line_base + (adj_opcode % lh->line_range);
>lh->file_names[file - 1].included_p = 1;
> - if (!decode_for_pst_p)
> + if (!decode_for_pst_p && is_stmt)
> {
> /* Append row to matrix using current values. */
> record_line (current_subfile, line,
> check_cu_functions (address, cu));
> }
> - basic_block = 1;
> + basic_block = 0;
> }
> else switch (op_code)
> {
> @@ -6499,7 +6499,7 @@ dwarf_decode_lines (struct line_header *
> case DW_LNE_end_sequence:
> end_sequence = 1;
>lh->file_names[file - 1].included_p = 1;
> - if (!decode_for_pst_p)
> + if (!decode_for_pst_p && is_stmt)
> record_line (current_subfile, 0, address);
> break;
> case DW_LNE_set_address:
>
> On Thu, 28 Jun 2018 14:14:51 +0900 (JST)
> Masato Asou wrote:
> > Hi tech,
> >
> > I have a problem and I have ad hoc patch to solve this problem.
> > However, this patch is AD HOC. Does anybody have correct solution?
> >
> > The next command of GDB does not work properly.
> > I use OpenBSD 6.3 and /usr/bin/gdb (GDB 6.3).
> >
> > When I debuging my program with next command, I expect stop at next
> > line. However, program returned from current function unusual.
> >
> > It seems that this problem will occur if there is a WHILE immediately
> > after the function call.
> >
> > Example as below:
> >
> > $ uname -a
> > OpenBSD asou-obsd63.soum.co.jp 6.3 GENERIC#100 amd64
> > $ cat main.c
> > #include
> > #include
> > #include
> > #include
> >
> > int
> > main(int argc, char *argv[])
> > {
> > extern void sub(int);
> > int ch;
> > int flag_a = 0;
> >
> > sub(1);
> > while ((ch = getopt(argc, argv, "a")) != -1) {
> > switch (ch) {
> > case 'a':
> > flag_a = 1;
> > break;
> > default:
> > err(1, "Unknown option: %c\n", ch);
> > break;
> > }
> > }
> >
> > printf("flag_a = %d\n", flag_a);
> > return (0);
> > }
> >
> > void
> > sub(int flag)
> > {
> > printf("flag = %d\n", flag);
> > }
> > $ cc -g main.c
> > $ gdb a.out
> > GNU gdb 6.3
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for details.
> > This GDB was configured as "amd64-unknown-openbsd6.3"...
> > (gdb) b main
> > Breakpoint 1 at 0x56b: file main.c, line 11.
> > (gdb) run
> > Starting program: /home/asou/tmp/a.out
> > Breakpoint 1 at 0x12776150056b: file main.c, line 11.
> >
> > Breakpoint 1, main (argc=1, argv=0x7f7c3b08) at main.c:11
> > 11 int flag_a = 0;
> > Current language: auto; currently minimal
> > (gdb) next
> > 13 sub(1);
> > (gdb) next
> > flag = 1
> > 0x127761500579 in main (argc=1, argv=0x7f7c3b08)
> >from /home/asou/tmp/a.out
> > (gdb) next
> > Single stepping until exit from function main,
> > which has no line number information.
> > flag_a = 0
> > 0x127761500436 in _start () from /home/asou/tmp/a.out
> > (gdb) bt
> > #0 0x127761500436 in _start () from /home/asou/tmp/a.out
> > #1 0x in ?? ()
> > (gdb)
> >
> > My patch as below:
> >
> > $ git diff
> > diff --git a/gnu/usr.bin/binutils/gdb/dwarf2read.c
> > b/gnu/usr.bin/binutils/gdb/dwarf2read.c
> > index 96f9e0f8551..651904d763d 100644
> > --- a/gnu/usr.bin/binutils/gdb/dwarf2read.c
> > +++ b/gnu/usr.bin/binutils/gdb/dwa
Re: [update] base zlib
There have been several diffs to update this already, they have been rejected (upstream using some things that were not wanted iirc). -- Sent from a phone, apologies for poor formatting. On 14 July 2018 19:01:51 Marc Espie wrote: On Sat, Jul 14, 2018 at 06:15:59PM +0100, David CARLIER wrote: Hi, Just to anticipate things, the age of the version starts to show with some third party softwares, so I was thinking if we could update to the latest while keeping just the necessary code and backporting our internal changes. Kind regards. Did you get this thru a full build, including all ports ?... How about a diff instead of a brand new tarball ?
Re: Fwd: new usb id for urtwn
On 2018/07/19 18:00, Mikhail wrote:
> Anyone?
>
>
> -- Forwarded message --
> From: Mikhail
> Date: Wed, Jul 11, 2018 at 6:12 PM
> Subject: Re: new usb id for urtwn
> To: Stuart Henderson
> Cc: tech@openbsd.org
>
>
> Sorry, new patch attached.
>
> On Wed, Jul 11, 2018 at 4:45 PM, Stuart Henderson
> wrote:
> > On 2018/07/11 16:27, Mikhail wrote:
> >> Ping? Ok?
> >>
> >> On Thu, 21 Jun 2018 at 18:28, Mikhail wrote:
> >>
> >> > Taken from FreeBSD:
> >> >
> >> > diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
> >> > index 0e204a196b1..d9aee16b05f 100644
> >> > --- a/sys/dev/usb/if_urtwn.c
> >> > +++ b/sys/dev/usb/if_urtwn.c
> >> > @@ -306,6 +306,7 @@ static const struct urtwn_type {
> >> > URTWN_DEV_8192CU(TRENDNET, RTL8192CU),
> >> > URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
> >> > /* URTWN_RTL8188E */
> >> > + URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
> >> > URTWN_DEV_8188EU(DLINK, DWA123D1),
> >> > URTWN_DEV_8188EU(DLINK, DWA125D1),
> >> > URTWN_DEV_8188EU(ELECOM,WDC150SU2M),
> >> >
> >
> > Not OK. Try compiling it...
> >
If you look at the top of the usbdevs.h and usbdevs_data.h files you'll
see "THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT." - these should
be generated by adding to the usbdevs file and running make.
I've committed a fixed version.
Re: pcidevs Sandisk or WD
On 2018/07/19 10:00, Bryan Vyhmeister wrote: > I am wanting to add the WD Black High-performance NVMe SSD PCI > IDs to pcidevs and I am not sure how to proceed. WD bought Sandisk a > while back but the vendor ID is 15b7 which is Sandisk Corp. The product > itself is WD Black High-performance NVMe SSD and is labeled as Western > Digital. The vendor ID of 15b7 does not exist in our pcidevs at this > point. Should I create a diff as 15b7 being Sandisk or Western Digital? > There are only two products listed under 15b7 that I have found (2001 > and 5001) and this SSD I have is a new (third) one (5002). My intention > is to add the information for 5001 and 5002 which are the original WD > Black NVMe SSD and the new WD Black High-performance NVMe SSD. I have > both 500GB and 1TB versions which share the same product ID as expected. > Output from dmesg and pcidump is below. AFAIK typically we list under the original vendor name though I'm sure there are exceptions to this. My vote would be for listing as Sandisk. > > Bryan > > > > nvme0 at pci3 dev 0 function 0 unknown vendor 0x15b7 product 0x5002 rev 0x00: > msi, NVMe 1.3 > nvme0: WDS100T2X0C-00L350, firmware 101110WD, serial 181123456789 > > > 4:0:0: unknown unknown > 0x: Vendor ID: 15b7 Product ID: 5002 > 0x0004: Command: 0007 Status: 0010 > 0x0008: Class: 01 Subclass: 08 Interface: 02 Revision: 00 > 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 > 0x0010: BAR mem 64bit addr: 0xe000/0x4000 > 0x0018: BAR empty () > 0x001c: BAR empty () > 0x0020: BAR mem 64bit addr: 0xe0004000/0x0100 > 0x0028: Cardbus CIS: > 0x002c: Subsystem Vendor ID: 15b7 Product ID: 5002 > 0x0030: Expansion ROM Base Address: > 0x0038: > 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 > 0x0080: Capability 0x01: Power Management > State: D0 > 0x0090: Capability 0x05: Message Signalled Interrupts (MSI) > 0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) > 0x00c0: Capability 0x10: PCI Express > Link Speed: 5.0 / 8.0 GT/s Link Width: x4 / x4 > 0x0100: Enhanced Capability 0x01: Advanced Error Reporting > 0x0150: Enhanced Capability 0x03: Device Serial Number > 0x01b8: Enhanced Capability 0x18: Latency Tolerance Reporting > 0x0300: Enhanced Capability 0x19: Secondary PCIe Capability > 0x0900: Enhanced Capability 0x1e: L1 PM >
tracking down sources of spin cpu%
My workstation is freezing up a lot again (usually in 30-60ish second bursts with no or very slow response to mouse or keyboard or screen updates). I have a status bar (xstatbar) that displays a graph of the last minute or so's cpu% split off into user/nice/system/spin/interrupt/idle. It skips a lot of updates when the machine freezes but it's obvious that it's mostly in spin. It seems particularly likely to occur when opening browser tabs. Is there anything sane that I can do (ahead of time, as I can't type when it's in that state) that will give clues about what's going on? dmesg below, FWIW. OpenBSD 6.3-current (GENERIC.MP) #11: Fri Jul 20 14:48:58 BST 2018 st...@symphytum.spacehopper.org:/src/cvs-openbsd/sys/arch/amd64/compile/GENERIC.MP real mem = 17067200512 (16276MB) avail mem = 16540782592 (15774MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (92 entries) bios0: vendor Dell Inc. version "A12" date 05/11/2017 bios0: Dell Inc. PowerEdge T20 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! DMAR acpi0: wakeup devices UAR1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(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 E3-1225 v3 @ 3.20GHz, 3392.57 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,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.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,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 E3-1225 v3 @ 3.20GHz, 3392.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,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 E3-1225 v3 @ 3.20GHz, 3392.15 MHz 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,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 4 (RP05) acpiprt4 at acpi0: bus -1 (PEG0) acpiprt5 at acpi0: bus -1 (PEG1) acpiprt6 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpicmos0 at acpi0 "INT3F0D" at acpi0 not configured acpibtn0 at acpi0: PWRB "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 3392 MHz: speeds: 3201, 3200, 3000, 2900, 2700, 2500, 2300, 2200, 2000, 1800, 1700, 1500, 1300, 1
Re: inteldrm: always use probed screen size for fb
On 2018/07/24 13:25, Bryan Vyhmeister wrote: > (Obviously clock was wrong and I did not realize it. Looks like ntpd is > not setting the clock with -s for some reason so rdate did the trick.) If the clock is already more than a little bit wrong and you have "constraints" in ntpd.conf, ntpd (even with -s) cannot fix it.
Re: tracking down sources of spin cpu%
On 2018/07/24 23:07, Stuart Henderson wrote: > My workstation is freezing up a lot again (usually in 30-60ish second > bursts with no or very slow response to mouse or keyboard or screen > updates). > > I have a status bar (xstatbar) that displays a graph of the last minute > or so's cpu% split off into user/nice/system/spin/interrupt/idle. It > skips a lot of updates when the machine freezes but it's obvious that > it's mostly in spin. > > It seems particularly likely to occur when opening browser tabs. > > Is there anything sane that I can do (ahead of time, as I can't type > when it's in that state) that will give clues about what's going on? I had a think about what might have changed when it started freezing again and remembered that I had switched X back to modesetting at a time which would roughly correlate with this (I had been using intel(4) to cope with vncviewer problems, and switched back after jcs enabled SHM in vncviewer). I've moved back to intel(4) now to see if this removes/reduces the problem. Haven't run into one since, but it's still a bit early to say if it's actually helped. (intel does remove one other annoyance, for some inexplicable reason context menus like the right-click menu in browsers often show up on the wrong monitor with modesetting..).
Re: tracking down sources of spin cpu%
On 2018/07/25 12:00, Antoine Jacoutot wrote: > > I see the exact same issue as you do. > > I'll try with s/modesetting/intel and see if it improves things. > > OK I can already confirm this "fixes" the issue for me. It's been up for long enough now that I agree. For anyone else running into this, here is the xorg.conf stanza to switch (no other entries are needed in the file). Section "Device" Identifier "Intel Graphics" Driver "intel" EndSection
Re: inteldrm: always use probed screen size for fb
On 2018/07/25 06:10, Bryan Vyhmeister wrote: > On Wed, Jul 25, 2018 at 08:51:53AM +0100, Stuart Henderson wrote: > > On 2018/07/24 13:25, Bryan Vyhmeister wrote: > > > (Obviously clock was wrong and I did not realize it. Looks like ntpd is > > > not setting the clock with -s for some reason so rdate did the trick.) > > > > If the clock is already more than a little bit wrong and you have > > "constraints" in ntpd.conf, ntpd (even with -s) cannot fix it. > > Thanks for that info. This is with the default ntpd.conf which does > indeed have constraints. I have not powered this system on for quite a > while. I appreciate the explanation. > > Bryan The problem is that if the clock is wrong, the server's certificate and/or OCSP stapling can't be validated (it either appears to have expired, or not be valid yet), so ntpd is unable to connect using https to check the time. Personally I am no fan of "constraints", I use local NTP servers and trust the relevant parts of the network more than the RTC and batteries on my machines, and don't really like sending potentially fingerprintable external packets showing that a machine has rebooted, so I usually disable it. Obviously opinions differ on this :-)
Re: tracking down sources of spin cpu%
On 2018/07/25 15:26, Alexandre Ratchov wrote: > On Wed, Jul 25, 2018 at 11:56:04AM +0100, Stuart Henderson wrote: > > On 2018/07/25 12:00, Antoine Jacoutot wrote: > > > > I see the exact same issue as you do. > > > > I'll try with s/modesetting/intel and see if it improves things. > > > > > > OK I can already confirm this "fixes" the issue for me. > > > > It's been up for long enough now that I agree. > > > > For anyone else running into this, here is the xorg.conf stanza to > > switch (no other entries are needed in the file). > > > > Section "Device" > >Identifier "Intel Graphics" > >Driver "intel" > > EndSection > > > > Do you remember if the problem occurs with the modesetting driver if > you disable acceleration, ie you add: > > Option "AccelMethod" "none" > > to the "Device" section? > I hadn't tried that before. I just gave it a go, didn't see any freezes, but browser rendering was so slow as to be useless - Firefox took about 10 minutes to get to a state where I could interact with it (didn't help that the saved open tab was a complex map I suppose) and ~30 seconds to react to anything. chromium wasn't quite as bad, but I couldn't live with it.
Re: tracking down sources of spin cpu%
On 2018/07/25 22:57, Alexandre Ratchov wrote: > On Wed, Jul 25, 2018 at 05:10:05PM +0100, Stuart Henderson wrote: > > On 2018/07/25 15:26, Alexandre Ratchov wrote: > > > On Wed, Jul 25, 2018 at 11:56:04AM +0100, Stuart Henderson wrote: > > > > On 2018/07/25 12:00, Antoine Jacoutot wrote: > > > > > > I see the exact same issue as you do. > > > > > > I'll try with s/modesetting/intel and see if it improves things. > > > > > > > > > > OK I can already confirm this "fixes" the issue for me. > > > > > > > > It's been up for long enough now that I agree. > > > > > > > > For anyone else running into this, here is the xorg.conf stanza to > > > > switch (no other entries are needed in the file). > > > > > > > > Section "Device" > > > >Identifier "Intel Graphics" > > > >Driver "intel" > > > > EndSection > > > > > > > > > > Do you remember if the problem occurs with the modesetting driver if > > > you disable acceleration, ie you add: > > > > > > Option "AccelMethod" "none" > > > > > > to the "Device" section? > > > > > > > I hadn't tried that before. I just gave it a go, didn't see any freezes, > > but browser rendering was so slow as to be useless - Firefox took about > > 10 minutes to get to a state where I could interact with it (didn't help > > that the saved open tab was a complex map I suppose) and ~30 seconds to > > react to anything. chromium wasn't quite as bad, but I couldn't live > > with it. > > This is strange, firefox starts almost immediately on both of my > machines (~1.5s on the faster one, i5-2500K) , with: > > Section "Device" > Identifier "Card0" > Driver "modesetting" > Option "SWcursor" "on" > Option "AccelMethod" "none" > EndSection > > AFAIU, if AccelMethod is set to none, the device behaves like a bare > framebuffer (given "modern" memory speeds, this covers all desktop > needs, ex. mplayer uses ~6% CPU for a full-screen 720p movie). So, > what you observe may be unrelated to graphics. Which processes consume > CPU and appear to spin? > With 'Driver modesetting / AccelMethod none' the busiest firefox process uses 100-200% cpu while it's loading saved tabs etc, and this takes ~10 minutes. With 'Driver intel' it loads the same tabs and starts responding in about 10 seconds. With no xorg.conf, so 'Driver modesetting' and default AccelMethod, it loads tabs and starts responding reasonably quickly (I'm not going back to it to check now, but probably also about 10 seconds), but I get freezes very often. Anyway unless somebody has a particular request that will help track down what's going on, I'll stick with intel, as it significantly reduces the risk of me wanting to hammer a screwdriver through the monitors (or, possibly worse, consider buying a Mac) if I'm trying to actually get anything done :)
Re: acme-client.1 - fix mangled sentence and stray plural
All 3 are OK with me, if there are no objections I can commit them later (but would be happy if someone beats me to it :) On 2018/08/02 14:49, Ross L Richardson wrote: > > This is the first of several diffs containing separate bits of the > earlier combined diff. > > "X509" to "X.509" for correctness and consistency with acme-client.conf.5 > > > Index: acme-client.1 > === > RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v > retrieving revision 1.24 > diff -u -p -r1.24 acme-client.1 > --- acme-client.1 13 Jun 2018 15:08:24 - 1.24 > +++ acme-client.1 2 Aug 2018 04:29:36 - > @@ -44,7 +44,7 @@ Specify an alternative configuration fil > .It Fl n > No operation: check and print configuration. > .It Fl r > -Revoke the X509 certificate found in the certificates. > +Revoke the X.509 certificate. > .It Fl v > Verbose operation. > Specify twice to also trace communication and data transfers. > @@ -110,7 +110,7 @@ as above: > .Pp > A daily > .Xr cron 8 > -job can renew the certificates: > +job can renew the certificate: > .Pp > .Dl acme-client example.com && rcctl reload httpd > .Sh SEE ALSO > On 2018/08/02 14:57, Ross L Richardson wrote: > > It's an "X.509 certificate" rather than a "TLS certificate". > As pointed out by sthen@, TLS isn't the only possible use. > > > > Index: acme-client.1 > === > RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v > retrieving revision 1.24 > diff -u -p -r1.24 acme-client.1 > --- acme-client.1 13 Jun 2018 15:08:24 - 1.24 > +++ acme-client.1 2 Aug 2018 04:41:05 - > @@ -56,7 +56,7 @@ The domain name. > looks in its configuration for a > .Ar domain > section corresponding to the domain given as command line argument. > -It then uses that configuration to retrieve a TLS certificate. > +It then uses that configuration to retrieve an X.509 certificate. > If the certificate already exists and is less than 30 days from expiry, > .Nm > will attempt to refresh the signature. > On 2018/08/02 15:09, Ross L Richardson wrote: > > According to code (and testing), each is optional but at least > one must be present. > > > Index: acme-client.conf.5 > === > RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v > retrieving revision 1.13 > diff -u -p -r1.13 acme-client.conf.5 > --- acme-client.conf.58 Jul 2018 15:41:17 - 1.13 > +++ acme-client.conf.52 Aug 2018 04:33:57 - > @@ -120,6 +120,9 @@ plain domain name forms. > The private key file for which the certificate will be obtained. > .It Ic domain certificate Ar file > The filename of the certificate that will be issued. > +This is optional if > +.Ar domain full chain certificate > +is specified. > .It Ic domain chain certificate Ar file > The filename in which to store the certificate chain > that will be returned by the certificate authority. > @@ -137,6 +140,9 @@ This is a combination of the > and the > .Ar domain chain certificate > in one file, and is required by most browsers. > +This is optional if > +.Ar domain certificate > +is specified. > .It Ic sign with Ar authority > The certificate authority (as declared above in the > .Sx AUTHORITIES >
Re: bgpd: fix rde_filter_equal
On 2018/08/02 14:32, Claudio Jeker wrote:
> Currently if anyone uses the example bgpd filter rules all neighbors will
> do a full softreconfiguration even when no rule have been changed. This is
> because the skip logic was wrongly implemented and so rules like 'pass to
> ebgp' will result in non equality of the ruleset even though it is fine.
>
> By introducing a rde_filter_skip_rule() function the skip logic goes into
> a single place and so less errors should happen.
>
> OK?
It reads well, and is much clearer split off to a function this way.
Testing while watching bgpd -dv output it detects filter changes when
I expect them and does the right thing. OK sthen@
> --
> :wq Claudio
>
> PS: this may speed up config reloads in some cases a fair amount
>
> Index: rde_filter.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde_filter.c,v
> retrieving revision 1.97
> diff -u -p -r1.97 rde_filter.c
> --- rde_filter.c 22 Jul 2018 16:59:08 - 1.97
> +++ rde_filter.c 2 Aug 2018 12:22:10 -
> @@ -549,6 +549,37 @@ rde_prefix_match(struct filter_prefix *f
> return (0); /* should not be reached */
> }
>
> +/* return true when the rule f can never match for this peer */
> +static int
> +rde_filter_skip_rule(struct rde_peer *peer, struct filter_rule *f)
> +{
> + /* if any of the two is unset then rule can't be skipped */
> + if (peer == NULL || f == NULL)
> + return (0);
> +
> + if (f->peer.groupid != 0 &&
> + f->peer.groupid != peer->conf.groupid)
> + return (1);
> +
> + if (f->peer.peerid != 0 &&
> + f->peer.peerid != peer->conf.id)
> + return (1);
> +
> + if (f->peer.remote_as != 0 &&
> + f->peer.remote_as != peer->conf.remote_as)
> + return (1);
> +
> + if (f->peer.ebgp != 0 &&
> + f->peer.ebgp != peer->conf.ebgp)
> + return (1);
> +
> + if (f->peer.ibgp != 0 &&
> + f->peer.ibgp != !peer->conf.ebgp)
> + return (1);
> +
> + return (0);
> +}
> +
> int
> rde_filter_equal(struct filter_head *a, struct filter_head *b,
> struct rde_peer *peer, struct prefixset_head *psh)
> @@ -561,43 +592,12 @@ rde_filter_equal(struct filter_head *a,
>
> while (fa != NULL || fb != NULL) {
> /* skip all rules with wrong peer */
> - if (peer != NULL && fa != NULL && fa->peer.groupid != 0 &&
> - fa->peer.groupid != peer->conf.groupid) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> - if (peer != NULL && fa != NULL && fa->peer.peerid != 0 &&
> - fa->peer.peerid != peer->conf.id) {
> + if (rde_filter_skip_rule(peer, fa)) {
> fa = TAILQ_NEXT(fa, entry);
> continue;
> }
> -
> - if (peer != NULL && fb != NULL && fb->peer.groupid != 0 &&
> - fb->peer.groupid != peer->conf.groupid) {
> + if (rde_filter_skip_rule(peer, fb)) {
> fb = TAILQ_NEXT(fb, entry);
> - continue;
> - }
> - if (peer != NULL && fb != NULL && fb->peer.peerid != 0 &&
> - fb->peer.peerid != peer->conf.id) {
> - fb = TAILQ_NEXT(fb, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.remote_as != 0 &&
> - fa->peer.remote_as != peer->conf.remote_as) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.ebgp != 0 &&
> - fa->peer.ebgp != peer->conf.ebgp) {
> - fa = TAILQ_NEXT(fa, entry);
> - continue;
> - }
> -
> - if (peer != NULL && fa != NULL && fa->peer.ibgp != 0 &&
> - fa->peer.ibgp != !peer->conf.ebgp) {
> - fa = TAILQ_NEXT(fa, entry);
> continue;
> }
>
>
Re: correct nd6_timer_next accounting
On 2018/08/01 23:18, Florian Obser wrote: > I'm chasing a bug in IPv6 where ndp reports an entry as (incomplete) > but when you try to reach that target no neighbor solicitation is > send. Not sure if it's related or not but I've seen weird v6 behaviour on my workstation for a while which I've been trying to figure out in order to get enough information together to make a useful report. But since you have problems in a similar area I'll mention it now before figuring any more out in case it's relevant. Trying to connect to any host (directly connected or remote) fails with EHOSTUNREACH, but the route is there, ndp is there, PF is not in the way (I see the same with pfctl -d). No difference with the nd6_timer_next diff. $ cat /etc/mygate 82.68.199.142 2a02:8011:7003:1::1 $ ifconfig vlan2 vlan2: flags=8843 mtu 1500 lladdr f8:b1:56:ac:32:76 index 6 priority 0 llprio 3 encap: vnetid 2 parent em0 groups: vlan egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 82.68.199.130 netmask 0xfff0 broadcast 82.68.199.143 inet6 fe80::78d8:e34b:df38:885e%vlan2 prefixlen 64 scopeid 0x6 inet6 2a02:8011:7003:1:fab1:56ff:feac:3276 prefixlen 64 $ ifconfig -A|grep inet6 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 fe80::78d8:e34b:df38:885e%vlan2 prefixlen 64 scopeid 0x6 inet6 2a02:8011:7003:1:fab1:56ff:feac:3276 prefixlen 64 $ netstat -rnfinet6 Routing tables Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface default2a02:8011:7003:1::1UGS1 2560 - 8 vlan2 ::/96 ::1UGRS 0 0 32768 8 lo0 ::1::1UHhl 10 22 32768 1 lo0 :::0.0.0.0/96 ::1UGRS 0 0 32768 8 lo0 2002::/24 ::1UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1UGRS 0 0 32768 8 lo0 2a02:8011:7003:1::/64 2a02:8011:7003:1:fab1:56ff:feac:3276 UCn 20 - 4 vlan2 2a02:8011:7003:1::100:0d:b9:41:7e:48 UHLch 1 13 - 3 vlan2 2a02:8011:7003:1:20d:93ff:fe63:da5a 00:0d:b9:14:30:ec UHLc 1 12 - 3 vlan2 2a02:8011:7003:1:fab1:56ff:feac:3276 f8:b1:56:ac:32:76 UHLl 1 36 - 1 vlan2 fe80::/10 ::1UGRS 0 1 32768 8 lo0 fec0::/10 ::1UGRS 0 0 32768 8 lo0 fe80::1%lo0fe80::1%lo0UHl0 0 32768 1 lo0 fe80::%vlan2/64fe80::78d8:e34b:df38:885e%vlan2 UCn0 0 - 4 vlan2 fe80::78d8:e34b:df38:885e%vlan2f8:b1:56:ac:32:76 UHLl 0 0 - 1 vlan2 ff01::/16 ::1UGRS 0 1 32768 8 lo0 ff01::%lo0/32 ::1Um 0 1 32768 4 lo0 ff01::%vlan2/32fe80::78d8:e34b:df38:885e%vlan2 Um 0 1 - 4 vlan2 ff02::/16 ::1UGRS 0 1 32768 8 lo0 ff02::%lo0/32 ::1Um 0 1 32768 4 lo0 ff02::%vlan2/32fe80::78d8:e34b:df38:885e%vlan2 Um 0 1 - 4 vlan2 $ ndp -na Neighbor Linklayer Address Netif ExpireS Flags 2a02:8011:7003:1::1 00:0d:b9:41:7e:48 vlan2 23h54m6s S R 2a02:8011:7003:1:20d:93ff:fe63:da5a 00:0d:b9:14:30:ec vlan2 23h54m9s S 2a02:8011:7003:1:fab1:56ff:feac:3276 f8:b1:56:ac:32:76 vlan2 permanent R l fe80::78d8:e34b:df38:885e%vlan2 f8:b1:56:ac:32:76 vlan2 permanent R l $ ping6 mala PING mala.spacehopper.org (2a02:8011:7003:1:20d:93ff:fe63:da5a): 56 data bytes ping6: sendmsg: No route to host ping: wrote mala.spacehopper.org 64 chars, ret=-1 ^C --- mala.spacehopper.org ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss $ telnet -6 mala 22 Trying 2a02:8011:7003:1:20d:93ff:fe63:da5a... telnet: connect to address 2a02:8011:7003:1:20d:93ff:fe63:da5a: No route to host $ route -n get -inet6 mala route to: 2a02:8011:7003:1:20d:93
Re: rad(8): move dns settings to global options
On 2018/08/03 14:58, Florian Obser wrote:
> sthen pointed out that it's better to overwrite dns options, not to merge
That works exactly how I'd expect - OK.
> diff --git engine.c engine.c
> index db31fb2a15b..93010cace51 100644
> --- engine.c
> +++ engine.c
> @@ -260,6 +260,7 @@ engine_dispatch_main(int fd, short event, void *bula)
> {
> static struct rad_conf *nconf;
> static struct ra_iface_conf *ra_iface_conf;
> + static struct ra_options_conf *ra_options;
> struct imsg imsg;
> struct imsgev *iev = bula;
> struct imsgbuf *ibuf;
> @@ -325,6 +326,9 @@ engine_dispatch_main(int fd, short event, void *bula)
> fatal(NULL);
> memcpy(nconf, imsg.data, sizeof(struct rad_conf));
> SIMPLEQ_INIT(&nconf->ra_iface_list);
> + SIMPLEQ_INIT(&nconf->ra_options.ra_rdnss_list);
> + SIMPLEQ_INIT(&nconf->ra_options.ra_dnssl_list);
> + ra_options = &nconf->ra_options;
> break;
> case IMSG_RECONF_RA_IFACE:
> if ((ra_iface_conf = malloc(sizeof(struct
> @@ -334,10 +338,11 @@ engine_dispatch_main(int fd, short event, void *bula)
> sizeof(struct ra_iface_conf));
> ra_iface_conf->autoprefix = NULL;
> SIMPLEQ_INIT(&ra_iface_conf->ra_prefix_list);
> - SIMPLEQ_INIT(&ra_iface_conf->ra_rdnss_list);
> - SIMPLEQ_INIT(&ra_iface_conf->ra_dnssl_list);
> + SIMPLEQ_INIT(&ra_iface_conf->ra_options.ra_rdnss_list);
> + SIMPLEQ_INIT(&ra_iface_conf->ra_options.ra_dnssl_list);
> SIMPLEQ_INSERT_TAIL(&nconf->ra_iface_list,
> ra_iface_conf, entry);
> + ra_options = &ra_iface_conf->ra_options;
> break;
> case IMSG_RECONF_RA_AUTOPREFIX:
> if ((ra_iface_conf->autoprefix = malloc(sizeof(struct
> @@ -361,7 +366,7 @@ engine_dispatch_main(int fd, short event, void *bula)
> fatal(NULL);
> memcpy(ra_rdnss_conf, imsg.data, sizeof(struct
> ra_rdnss_conf));
> - SIMPLEQ_INSERT_TAIL(&ra_iface_conf->ra_rdnss_list,
> + SIMPLEQ_INSERT_TAIL(&ra_options->ra_rdnss_list,
> ra_rdnss_conf, entry);
> break;
> case IMSG_RECONF_RA_DNSSL:
> @@ -370,7 +375,7 @@ engine_dispatch_main(int fd, short event, void *bula)
> fatal(NULL);
> memcpy(ra_dnssl_conf, imsg.data, sizeof(struct
> ra_dnssl_conf));
> - SIMPLEQ_INSERT_TAIL(&ra_iface_conf->ra_dnssl_list,
> + SIMPLEQ_INSERT_TAIL(&ra_options->ra_dnssl_list,
> ra_dnssl_conf, entry);
> break;
> case IMSG_RECONF_END:
> diff --git frontend.c frontend.c
> index e80879c67d5..7b7487f560b 100644
> --- frontend.c
> +++ frontend.c
> @@ -304,6 +304,7 @@ frontend_dispatch_main(int fd, short event, void *bula)
> {
> static struct rad_conf *nconf;
> static struct ra_iface_conf *ra_iface_conf;
> + static struct ra_options_conf *ra_options;
> struct imsg imsg;
> struct imsgev *iev = bula;
> struct imsgbuf *ibuf = &iev->ibuf;
> @@ -367,6 +368,9 @@ frontend_dispatch_main(int fd, short event, void *bula)
> fatal(NULL);
> memcpy(nconf, imsg.data, sizeof(struct rad_conf));
> SIMPLEQ_INIT(&nconf->ra_iface_list);
> + SIMPLEQ_INIT(&nconf->ra_options.ra_rdnss_list);
> + SIMPLEQ_INIT(&nconf->ra_options.ra_dnssl_list);
> + ra_options = &nconf->ra_options;
> break;
> case IMSG_RECONF_RA_IFACE:
> if ((ra_iface_conf = malloc(sizeof(struct
> @@ -376,10 +380,11 @@ frontend_dispatch_main(int fd, short event, void *bula)
> ra_iface_conf));
> ra_iface_conf->autoprefix = NULL;
> SIMPLEQ_INIT(&ra_iface_conf->ra_prefix_list);
> - SIMPLEQ_INIT(&ra_iface_conf->ra_rdnss_list);
> - SIMPLEQ_INIT(&ra_iface_conf->ra_dnssl_list);
> + SIMPLEQ_INIT(&ra_iface_conf->ra_options.ra_rdnss_list);
> + SIMPLEQ_INIT(&ra_iface_conf->ra_options.ra_dnssl_list);
> SIMPLEQ_INSERT_TAIL(&nconf->ra_iface_list,
> ra_iface_conf, entry);
> + ra_options = &ra_iface_conf->ra_optio
lo(4) automatic ::1 setting and multiple loopbacks
While looking into something unrelated I found a strange extra ::1 address on lo1 (I usually hang my loopback addresses for IBGP off lo1). lo1: flags=8049 mtu 32768 index 12 priority 0 llprio 3 groups: lo inet xxx.xx.xxx.1 netmask 0x inet6 ::1 prefixlen 128 inet6 fe80::1%lo1 prefixlen 64 scopeid 0xc inet6 ::x:xxx::1 prefixlen 128 I haven't run into problems as a result of this (fortunately ospf6d picked the correct address to redistribute) but it doesn't seem right. $ ifconfig lo | grep -e ^lo -e 'inet6 ::1' lo0: flags=8049 mtu 32768 inet6 ::1 prefixlen 128 lo1: flags=8049 mtu 32768 inet6 ::1 prefixlen 128 It seems we did this a while ago to fix breakage after NOINET6 but reading commit log, it definitely doesn't seem expected that ::1 would appear on additional loopback interfaces (see lines marked with >) - : $ acvs log -N -r1.315 if.c : : RCS file: /cvs/src/sys/net/if.c,v : Working file: if.c : head: 1.559 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 580; selected revisions: 1 : description: : : revision 1.315 : date: 2015/01/27 10:31:19; author: mpi; state: Exp; lines: +12 -21; commitid: 5QOPq50YTGxsLtYH; : Ensure that link-local addresses are correctly configured on loopback : interfaces. : : When the kernel automagically configures IPv6 addresses on loopback : interfaces, start by assigning a link-local address and then try to : assign "::1". : > Only the first configured loopback interface per rdomain can have the > "::1" address. But even if other loopback interfaces failed to get : this address, because it is already taken, give them a chance to have : a link-local address. : : While here change in6_ifattach() to return an error value and remove : duplicated code. : : Fix a regression introduced by the NOINET6 flag removal. : : ok henning@, stsp@, florian@, benno@ : = Any thoughts on how bad this is and whether it needs fixing or can be ignored? (I suppose I could add "inet6 ::1 delete" to hostname.lo1..)
Re: avoid overflow in snmp message id
On 2018/08/10 10:26, Rob Pierce wrote:
> Prevent server side (snmpd) overflow for message id in the snmp header.
>
> ok?
Matches RFC3412 6.2, OK sthen@
> Index: snmpclient.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpctl/snmpclient.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 snmpclient.c
> --- snmpclient.c 8 Aug 2018 18:50:38 - 1.16
> +++ snmpclient.c 10 Aug 2018 14:21:23 -
> @@ -407,7 +407,7 @@ snmpc_sendreq(struct snmpc *sc, unsigned
> erroridx = SNMPC_MAXREPETITIONS;
>
> /* SNMP header */
> - sc->sc_msgid = arc4random();
> + sc->sc_msgid = arc4random() & 0x7fff;
> if ((root = ber_add_sequence(NULL)) == NULL)
> return (-1);
> if ((b = ber_printf_elements(root, "ds{tddd{{O0}}",
>
Fwd from arm@: Re: problem with new php build on armv7
I just noticed (after replying) that this was originally on arm@. Forwarding to a list with slightly more readers :) - Forwarded message from Stuart Henderson - From: Stuart Henderson Date: Sat, 11 Aug 2018 12:16:50 +0100 To: s_g...@telus.net Cc: a...@openbsd.org User-Agent: NeoMutt/20180716 Subject: Re: problem with new php build on armv7 Mail-Followup-To: s_g...@telus.net, a...@openbsd.org On 2018/08/10 23:54, s_g...@telus.net wrote: > I just tried to use php70 from the recent package build for armv7, on a > fresh install of current Aug 9. > > > > When started, php runs constantly with the following log entries: > > > > op1bsdtest2# tail /var/log/php-fpm.log > > [10-Aug-2018 23:40:26] WARNING: [pool www] child 45495 exited on signal 10 > (SIGBUS) after 1098009296.00 seconds from start > > [10-Aug-2018 23:40:26] NOTICE: [pool www] child 59471 started > > [10-Aug-2018 23:40:26] WARNING: [pool www] child 79334 exited on signal 10 > (SIGBUS) after 1098009296.00 seconds from start > > [10-Aug-2018 23:40:26] NOTICE: [pool www] child 89082 started > > [10-Aug-2018 23:40:26] WARNING: [pool www] child 22475 exited on signal 10 > (SIGBUS) after 1098009296.00 seconds from start > > [10-Aug-2018 23:40:26] NOTICE: [pool www] child 39523 started > > [10-Aug-2018 23:40:26] WARNING: [pool www] child 84388 exited on signal 10 > (SIGBUS) after 1098009296.00 seconds from start > > [10-Aug-2018 23:40:26] NOTICE: [pool www] child 79891 started > > [10-Aug-2018 23:40:26] WARNING: [pool www] child 45004 exited on signal 10 > (SIGBUS) after 1098009296.00 seconds from start > > [10-Aug-2018 23:40:26] NOTICE: [pool www] child 23439 started > > > > I tried php56 and got similar results. > > Has anyone had any success with the latest php package on armv7? > > > > I am currently using php70 from a package I build in mid May (release > 7.0.29). > armv7 recently switched from the gnu linker to the clang one (lld), which might be involved. Can you get some more information? - Try running php at the command-line: $ php-7.0 -r 'phpinfo();' - Try the above with LD_DEBUG set in the environment, there is likely to be a lot of output so run it under script(1). Look for errors, or even better do the same with an older working binary and compare output between the two: $ LD_DEBUG=1 php-7.0 -r 'phpinfo();' - Try running it under gdb and see if you can get a backtrace. $ gdb `which php-7.0` set args -r 'phpinfo();' r If command-line php doesn't crash, try the various things above with php-fpm-7.0 and -F to run in the foreground instead of -r 'phpinfo();'. - End forwarded message -
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
On 2018/08/14 18:43, Bryan Vyhmeister wrote: > On Tue, Aug 14, 2018 at 05:53:43PM +0300, Denis wrote: > > Most of modern modems have serial discipline ports and USB Mobile > > Broadband Interface Model (MBIM) interface in some port compositions > > simultaneously. It seems very useful to have different disciplines > > supported by umsm(4) and umb(4) drivers on the same device. > > > > > > > Does it possible to have simultaneously operated AT + NMEA ports by > > umsm(4)driver and MBIM interface by umb(4) driver on the same MC7304 > > device in 6.3? > > What is the advantage in having a device attach to both umsm(4) and > umb(4)? What are you trying to accomplish? The EM7455 worked perfectly > with umb(4) until your previous umsm(4) diff and now it only attaches as > umsm(4). Are you wanting to send SMS messages or something like that > with your devices? > > Bryan > Denis has a good point because umsm is needed for GPS and as you suggest SMS. What determines which driver attaches when a device is supported by multiple drivers? Perhaps the simplest option without more complex work to support different interfaces on different drivers would be to have the device attach to umb by default but attach to umsm instead if umb is disabled in the kernel. Then at least a standard kernel could be used with "disable umb" from boot config.
Re: umsm(4) and umb(4) separate loading for the same composite USB modem device
On 2018/08/15 09:56, Stuart Henderson wrote: > On 2018/08/14 18:43, Bryan Vyhmeister wrote: > > On Tue, Aug 14, 2018 at 05:53:43PM +0300, Denis wrote: > > > Most of modern modems have serial discipline ports and USB Mobile > > > Broadband Interface Model (MBIM) interface in some port compositions > > > simultaneously. It seems very useful to have different disciplines > > > supported by umsm(4) and umb(4) drivers on the same device. > > > > > > > > > > > Does it possible to have simultaneously operated AT + NMEA ports by > > > umsm(4)driver and MBIM interface by umb(4) driver on the same MC7304 > > > device in 6.3? > > > > What is the advantage in having a device attach to both umsm(4) and > > umb(4)? What are you trying to accomplish? The EM7455 worked perfectly > > with umb(4) until your previous umsm(4) diff and now it only attaches as > > umsm(4). Are you wanting to send SMS messages or something like that > > with your devices? > > > > Bryan > > > > Denis has a good point because umsm is needed for GPS and as you > suggest SMS. > > What determines which driver attaches when a device is supported by > multiple drivers? Perhaps the simplest option without more complex work > to support different interfaces on different drivers would be to have > the device attach to umb by default but attach to umsm instead if umb is > disabled in the kernel. Then at least a standard kernel could be used > with "disable umb" from boot config. > (In case it's not clear I definitely agree with backing out the change for now, the above is me considering ways forward because it definitely seems reasonable to want to use the GPS ..)
Re: php 5.6 and php 7 using php-fpm ?
To run the two versions concurrently, use the rc.conf.local flags variables (php56_fpm_flags/php70_fpm_flags) to give them different config files (-y /path/to/fpm.conf). -- Sent from a phone, apologies for poor formatting. On 16 August 2018 22:09:57 "Elias M. Mariani" wrote: Hi, Somebody knows how to set up 2 different socks, one with php56 and another with php70 ? Yo can just run rcctl start php56_fpm php70_fpm Because they would use the same fpm.sock. And this is configured in /etc/php-fpm.conf, I did not found another place to configure this. Cheers. Elias.
Re: ospfd: prevent additional ospfd from starting
On 2018/08/21 17:16, Remi Locherer wrote:
> Hi tech,
>
> recently we had a short outage in our network. A script started an additional
> ospfd instance because the -n flag for config test was missing.
This is a problem with bgpd as well, last time I did this it killed one of the
*other* routers on the network (i.e. not just the one where I accidentally ran
2x bgpd...).
> What then happend was not nice:
> - The new ospfd unlinked the control socket of the first ospfd
> - The new ospfd removed all routes from the first ospfd
> - The new ospfd was not able to build up an adjacency and therefore could
> not install the routes needed for a recovery.
> - Both ospfd instances were running but non-functional.
>
> Of course the faulty script is fixed by now. ;-)
>
> It would be nice if ospfd could prevent such a situation.
>
> Below diff does these things:
> - Detect a running ospfd by first doing a connect on the control socket.
> - Do not delete the control socket on exit.
> - This could delete the socket of another instance.
> - Unlinking the socket on shutdown will be in the way once we add pledge
> to the main process. It was removed recently from various daemons.
This all sounds very sensible.
> - Do not delete routes added by another process even if they have
> prio RTP_OSPF. Without this the new ospfd will remove all the routes
> of the first one.
I'm unsure about this, the above changes stop the new ospfd from running
don't they, so that shouldn't be a problem?
If an ospfd blows up for whatever reason, it would be quite inconvenient
if it needs manual route tweaks rather than just 'rcctl start ospfd' to fix it
..
> A side effect of this is that alien OSPF routes are now only logged but
> not removed anymore. Should a crashed ospfd leave some routes behind the
> next ospfd does not clean them up anymore. The admin would need to check
> the logs and remove them manually with the route command.
>
> Does this make sense?
>
> Comments? OK?
>
> Remi
>
>
> Index: control.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/control.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 control.c
> --- control.c 24 Jan 2017 04:24:25 - 1.44
> +++ control.c 17 Aug 2018 22:41:43 -
> @@ -42,19 +42,29 @@ int
> control_init(char *path)
> {
> struct sockaddr_un sun;
> - int fd;
> + int fd, fd_check;
> mode_t old_umask;
>
> + bzero(&sun, sizeof(sun));
> + sun.sun_family = AF_UNIX;
> + strlcpy(sun.sun_path, path, sizeof(sun.sun_path));
> +
> + if ((fd_check = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
> + log_warn("control_init: socket check");
> + return (-1);
> + }
> + if (connect(fd_check, (struct sockaddr *)&sun, sizeof(sun)) == 0) {
> + log_warnx("control_init: socket in use");
> + return (-1);
> + }
> + close(fd_check);
> +
> if ((fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC | SOCK_NONBLOCK,
> 0)) == -1) {
> log_warn("control_init: socket");
> return (-1);
> }
>
> - bzero(&sun, sizeof(sun));
> - sun.sun_family = AF_UNIX;
> - strlcpy(sun.sun_path, path, sizeof(sun.sun_path));
> -
> if (unlink(path) == -1)
> if (errno != ENOENT) {
> log_warn("control_init: unlink %s", path);
> @@ -98,16 +108,6 @@ control_listen(void)
> evtimer_set(&control_state.evt, control_accept, NULL);
>
> return (0);
> -}
> -
> -void
> -control_cleanup(char *path)
> -{
> - if (path == NULL)
> - return;
> - event_del(&control_state.ev);
> - event_del(&control_state.evt);
> - unlink(path);
> }
>
> /* ARGSUSED */
> Index: control.h
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/control.h,v
> retrieving revision 1.6
> diff -u -p -r1.6 control.h
> --- control.h 10 Feb 2015 05:24:48 - 1.6
> +++ control.h 17 Aug 2018 21:02:36 -
> @@ -39,6 +39,5 @@ int control_listen(void);
> void control_accept(int, short, void *);
> void control_dispatch_imsg(int, short, void *);
> int control_imsg_relay(struct imsg *);
> -void control_cleanup(char *);
>
> #endif /* _CONTROL_H_ */
> Index: kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
> retrieving revision 1.111
> diff -u -p -r1.111 kroute.c
> --- kroute.c 10 Jul 2018 11:49:04 - 1.111
> +++ kroute.c 21 Aug 2018 14:13:27 -
> @@ -263,6 +263,7 @@ kr_change_fib(struct kroute_node *kr, st
> kn->r.nexthop.s_addr = kroute[i].nexthop.s_addr;
> kn->r.flags = kroute[i].flags | F_OSPFD_INSERTED;
> kn->r.priority = RTP_OSPF;
> + kn->r.pid = kr_state.pid;
> kn->r.ext_tag = kroute
Re: Add $daemon_nice to rc.subr
On 2018/09/04 10:57, Thomas de Grivel wrote: > plus it's really 6 new lines in rc.subr, no big deal. 6 lines in rc.subr, but add this and someone will want to add something else (ulimit? setting environment variables?) and it's more, plus the accompanying documentation (which I think reduces the chance of people seeing things which are already possible..) There's already a mechanism to do what you want (note you can set the priority for "daemon" as well, to apply by default). While you might not like login.conf, it's not so horrible that there needs to be a duplicate mechanism..
Re: iostat: add "sp" column for CP_SPIN
On 2018/09/04 12:07, Solene Rapenne wrote:
> Naoki Fukaumi wrote:
> > hi tech@,
> >
> > new cpu state, CP_SPIN, was added,
> > https://marc.info/?l=openbsd-cvs&m=152630109526317&w=2
> >
> > but there is no column for it in the header of iostat,
> >
> > $ iostat
> > tty sd0 cpu
> > tin tout KB/t t/s MB/s us ni sy in id
> >01 11.473 0.04 0 0 0 0 0100
> >
> > this patch adds "sp" for CP_SPIN.
> >
> > --
> > FUKAUMI Naoki
> >
> > Index: usr.sbin/iostat/iostat.c
> > ===
> > RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v
> > retrieving revision 1.40
> > diff -u -p -u -p -r1.40 iostat.c
> > --- usr.sbin/iostat/iostat.c10 Feb 2018 19:49:50 - 1.40
> > +++ usr.sbin/iostat/iostat.c4 Sep 2018 04:19:14 -
> > @@ -229,7 +229,7 @@ header(void)
> > printf(" %16.16s ", cur.dk_name[i]);
> >
> > if (ISSET(todo, SHOW_CPU))
> > - printf("cpu");
> > + printf(" cpu");
> > printf("\n");
> >
> > /* Sub-Headers. */
> > @@ -254,7 +254,7 @@ header(void)
> > printf(" KB xfr time ");
> >
> > if (ISSET(todo, SHOW_CPU))
> > - printf(" us ni sy in id");
> > + printf(" us ni sy sp in id");
> > printf("\n");
> > }
> >
>
> ok solene@ for this, but the man page should be updated too, it contains the
> list of columns displayed.
>
Is iostat(8) something where people are likely to parse output?
(I first thought of sysutils/munin, iostat parsing is not enabled
there, but there might be others).
Re: iostat: add "sp" column for CP_SPIN
On 2018/09/04 14:22, Solene Rapenne wrote: > About munin I'm trying to get a diff accepted upstream to fix cpu plugin and > talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. While > it's not related, I prefer to announce it here so people don't waste time > fixing it again by looking at the thread :) Ah nice. When I worked on the initial munin port with mk I had intended to try to get upstream to take the openbsd plugins separately (rather than the current "copy similar OS and patch" approach), but I got fed up with rrdtool performance on OpenBSD and stopped using munin before I got round to it.. (and then I started using librenms and got fed up with rrdtool performance once again ;)
Re: iostat: add "sp" column for CP_SPIN
On 2018/09/04 15:27, Solene Rapenne wrote: > Stuart Henderson wrote: > > On 2018/09/04 14:22, Solene Rapenne wrote: > > > About munin I'm trying to get a diff accepted upstream to fix cpu plugin > > > and > > > talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. > > > While > > > it's not related, I prefer to announce it here so people don't waste time > > > fixing it again by looking at the thread :) > > > > Ah nice. When I worked on the initial munin port with mk I had intended > > to try to get upstream to take the openbsd plugins separately (rather > > than the current "copy similar OS and patch" approach), but I got fed up > > with rrdtool performance on OpenBSD and stopped using munin before I got > > round to it.. (and then I started using librenms and got fed up with > > rrdtool performance once again ;) > > Using rrdcached the performances are really good. But that certainly depend on > the number of systems. It may not scale well with more than 50 systems, this > is > also highly dependent on the number of plugins on each systems (as 1 value = 1 > rrd file). Not sure if I tried rrdcached with munin but I am using it with librenms and it's not really good here. In 9 days uptime, I have ~32h of cpu time from rrdcached, and lots of spin while the threads are actively processing. (Yes there are lots of RRDs ;) 159 threads: 2 running, 153 idle, 4 on processor up 9 days, 14:40 CPU0 states: 44.2% user, 0.0% nice, 24.5% sys, 31.3% spin, 0.0% intr, 0.0% idle CPU1 states: 45.2% user, 0.0% nice, 25.5% sys, 29.3% spin, 0.0% intr, 0.0% idle CPU2 states: 49.4% user, 0.0% nice, 24.1% sys, 26.5% spin, 0.0% intr, 0.0% idle CPU3 states: 49.0% user, 0.0% nice, 20.1% sys, 30.9% spin, 0.0% intr, 0.0% idle Memory: Real: 1847M/5197M act/tot Free: 2722M Cache: 2836M Swap: 0K/4098M
Re: iostat: add "sp" column for CP_SPIN
On 2018/09/04 16:11, Landry Breuil wrote: > On Tue, Sep 04, 2018 at 03:27:29PM +0200, Solene Rapenne wrote: > > Stuart Henderson wrote: > > > On 2018/09/04 14:22, Solene Rapenne wrote: > > > > About munin I'm trying to get a diff accepted upstream to fix cpu > > > > plugin and > > > > talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. > > > > While > > > > it's not related, I prefer to announce it here so people don't waste > > > > time > > > > fixing it again by looking at the thread :) > > > > > > Ah nice. When I worked on the initial munin port with mk I had intended > > > to try to get upstream to take the openbsd plugins separately (rather > > > than the current "copy similar OS and patch" approach), but I got fed up > > > with rrdtool performance on OpenBSD and stopped using munin before I got > > > round to it.. (and then I started using librenms and got fed up with > > > rrdtool performance once again ;) > > > > Using rrdcached the performances are really good. But that certainly depend > > on > > the number of systems. It may not scale well with more than 50 systems, > > this is > > also highly dependent on the number of plugins on each systems (as 1 value > > = 1 > > rrd file). > > Seconded, rrdcached really helps a lot until you have waaayyy too many rrds, > and then switch to a real tsdb While other time-series DBs may perform better than rrdtool, the amount of spin (kernel lock contention) seen with this relatively simple software suggests it might be a worthwhile starting point to investigate what's going on kernel-side. >(hint: influxdb is in ports) (as is prometheus. no graphite, though ;)
Re: slow vim and malloc
On 2018/09/12 12:49, Manolis Tzanidakis wrote: > Hello Stuart, > > On Wed (06/06/18), Stuart Henderson wrote: > > I've been finding vim with my standard settings really slow on OpenBSD. > > It's been bugging me for a while, but it just took about 1.2s to open > > and display a 20k patch, which was bad enough to make me dig into it > > again. > > Try this: > set re=1 > > > Best, > Manolis > Actually it's improved a lot now, I'm not sure whether that was due to a change in OpenBSD or in vim. I probably did already try re=1 at the time, we used to have it set by default in the port because highlighting was intolerably slow with malloc.conf linked to 'J', but that improved a while ago (it's still slower than the old regex engine, but acceptably so).
Re: pfctl: prevent modifying internal anchors through their tables
On 2018/09/12 17:38, Jason McIntyre wrote:
> On Wed, Sep 12, 2018 at 02:05:25PM +0200, Alexander Bluhm wrote:
> >
> > > + warnx("anchors apply to -f, -F, -t and -s only");
> >
> > If I understand English comma rules correctly, there is also a comma
> > before the " and". At least this is what we do in the man page.
> >
> > bluhm
> >
>
> hi.
>
> just to note: it is not wrong to omit the comma. i personally use them
> there, because it eliminates some potential confusion in lists. but it
> does sometime look/read better without. it's a matter of taste i guess.
>
> jmc
>
btw (as jmc will already know of course!) this is known as an "Oxford comma"
or "serial comma", you will find a *lot* of references and arguments in both
directions if you search ;)
Re: Snapshot issue: panic: trap type 18, code=0
Almost certainly the same problem, retry when you have a newer snap. The list currently doesn't reject attachments, but please don't send a 740k image when a hundred bytes of text would do (and be easier for readers). -- Sent from a phone, apologies for poor formatting. On 16 September 2018 23:03:29 jungle Boogie wrote: Hi all, Snapshot from 14 September evening time was fine. I cannot boot the bsd.rd installer to upgrade on a real x64 machine. Other reports similar were regarding virtual box, but that's not the case for me. If the list accepts pictures, please see attached image. Thanks!
Re: OpenBGPd Feature Request / Question if the Feature Request
On 2018/09/22 09:21, Tom Smyth wrote: > I like the NFsen idea, however I think for a simple eyeball ISP we could > be able to achieve it by adding a default + exceptions summarisation > to openBGPd ( I would rather not create more dependencies on our BGP > ) > I want to install the minimum number of routes for transit > so that I am confident the packet will reach the intended destination > and then leave the rest of the switch CAM for Prefixes learned on > a local internet exchange. Interesting idea but I think the method you're suggesting puts you at higher risk of things *not* reaching their destination - if you have good and not-so-good transits, the diffs are likely to be things you don't want anyway and could interfere with correct routing. Some providers have a bit of a problem with "stuck" routes (if there's a stuck more-specific route at one provider, that will be a difference, and you'll send traffic there on a road to nowhere instead of to a valid less-specific). Another issue is that a good provider may have filtered a dubious announcement (hijack attempt), a less fastidious one might not. If I wanted to identify *whether* a transit provider is sending such routes, analysing a diff of the announcements between them and another provider is quite a good way to find them. My suggestion if you're trying to use the hardware in this way: only use transit providers who can be trusted to generally provide good transit (which rules out a few ;) and just use defaults plus maybe allow some extra through filters to encourage certain traffic to go a certain way, or to balance load if your ports are hot.
Re: [patch] Perl: update Scalar-List-Utils to 1.50
On 2018/09/25 19:02, Charlene Wendling wrote: > Hi, > > I'm proposing here a diff to update Scalar-List-Utils to 1.50. > > It will be needed to import p5-List-AllUtils, that in turn would allow > to import p5-GeoIP2 (currently in -wip) and update others like > p5-Audio-MPD. > > The changelog indicates no backward incompatible changes between this > version and 1.42 we're currently shipping [1]. > > Testing: > > - It passes Perl global test suite. > - 'make test' for p5-List-AllUtils runs fine as well, p5-Audio-MPD > builds and runs with no issues. > - Actually i've been asked to make it public for further testing ;) > > Any comment/feedback is welcome! > > Charlène. > > > [1] https://metacpan.org/changes/distribution/Scalar-List-Utils A quick and dirty search for '(List|Scalar|Sub)::Util' in source to all p5-* ports suggests it's used by 400+ things there, plus it's used by other bits of perl core so, even if it seems a relatively safe update, my feeling is that this is a bit late for 6.4. When I looked at changelog it seems to me that 1.45 does have a breaking change, the old "uniq" was moved to "uniqstr" and a slightly different "uniq" was added, I couldn't say if this is _actually_ likely to be a problem though. My preferred approach would be to update all of perl core sometime not too long after a release (and after some initial ports testing) really.. I know it's a bunch more work but I'm pretty sure we have the same problem with other modules too..
Re: slow vim and malloc
On 2018/09/25 22:24, Matthias Schmidt wrote: > hi Stuart, > > * Stuart Henderson wrote: > > > > These settings in .vimrc make it quite noticeable > > > > syn > > set foldmethod=syntax > > set foldlevelstart=1 > > Totally forget about this thread. I had the same issue and the > following options made vim + syntax highlighting at least a bit more > usable for me. > > let sh_minlines=100 > let sh_maxlines=600 > set synmaxcol=300 > > Cheers and HTH > > Matthias > I've had a play with various "set re" options to use the old and new RE engines, new engine speeds range from "similar to the old one" to "much much slower than the old one" in my tests (depending on what it's doing and depending on malloc.conf flags). I considered changing the port back to using re=1 by default, but I ran into out-of-bounds reads in some cases when opening a file with syntax-highlighting enabled and paging through to the very end (especially with "hard" malloc.conf flags) so have put it to one side for now ...
Re: rework bgpd.conf.5 a bit
On 2018/10/03 16:19, Claudio Jeker wrote:
> I don't like how a lot of things got pushed into the global configuration
> section in bgpd.conf.5 especially since some bits should be their own
> sections. I see this for example for sets and for network statements.
>
> My proposal is to add two new sections which gives us the following
> structure:
> Macros
> Global Configuration
> Set Configuration
> Network Announcements
> MPLS VPN Configuration
> Neighbors and Groups
> Filter
>
> This allows also to write a bit more about sets and network statements
> which is in my opinion a good thing. This is not perfect but IMO better
> and a starting point for making this page even better.
I think that's a lot better. OK with a few comments inline
> --
> :wq Claudio
>
> Index: bgpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
> retrieving revision 1.179
> diff -u -p -r1.179 bgpd.conf.5
> --- bgpd.conf.5 3 Oct 2018 06:57:36 - 1.179
> +++ bgpd.conf.5 3 Oct 2018 13:56:48 -
> @@ -38,6 +38,12 @@ configuration file.
> .It Sy Global Configuration
> Global settings for
> .Xr bgpd 8 .
> +.It Sy Set Configuration
> +The definition of various lookup tables are done in this section.
this could be simplified to "Various lookup tables are defined in this section"
> +.It Sy Network Announcements
> +Networks which should be announced by
> +.Xr bgpd 8
> +are set in this section.
> .It Sy MPLS VPN Configuration
> The definition and properties for BGP MPLS VPNs are set in this section.
> .It Sy Neighbors and Groups
> @@ -144,19 +150,6 @@ or as a large number (ASPLAIN format), f
> AS 196618
> .Ed
> .Pp
> -.It Xo
> -.Ic as-set Ar name
> -.Ic { Ar as-number ... Ic }
> -.Xc
> -An
> -.Ic as-set
> -holds a collection of AS numbers and can be used with the AS specific
> -parameter in
> -.Sx FILTER
> -rules.
> -Lookups against as-sets are more efficient than a large number of rules
> -which differ only in the AS number.
> -.Pp
> .It Ic connect-retry Ar seconds
> Set the number of seconds before retrying to open a connection.
> This timer should be sufficiently large in EBGP configurations.
> @@ -267,73 +260,6 @@ listen on 127.0.0.1
> Log received and sent updates.
> .Pp
> .It Xo
> -.Ic network
> -.Ar address Ns Li / Ns Ar prefix
> -.Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic static Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic connected Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic rtlabel Ar label Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network
> -.Pq Ic inet Ns | Ns Ic inet6
> -.Ic priority Ar number Op Ic set ...\&
> -.Xc
> -.It Xo
> -.Ic network prefix-set
> -.Ar name
> -.Op Ic set ...\&
> -.Xc
> -Announce the specified network as belonging to our AS.
> -If set to
> -.Ic connected ,
> -routes to directly attached networks will be announced.
> -If set to
> -.Ic static ,
> -all static routes will be announced.
> -If set to
> -.Ic rtlabel ,
> -routes with the specified
> -.Ar label
> -will be announced.
> -If set to
> -.Ic priority ,
> -routes with the specified
> -.Ar priority
> -will be announced.
> -If a prefix-set
> -.Ar name
> -is specified, all networks in the prefix-set will be announced.
> -.Bd -literal -offset indent
> -network 192.168.7.0/24
> -.Ed
> -.Pp
> -It is possible to set default
> -.Em AS path attributes
> -per
> -.Ic network
> -statement:
> -.Bd -literal -offset indent
> -network 192.168.7.0/24 set localpref 220
> -.Ed
> -.Pp
> -See also the
> -.Sx ATTRIBUTE SET
> -section.
> -.Pp
> -.It Xo
> .Ic nexthop
> .Ic qualify
> .Ic via
> @@ -351,42 +277,6 @@ daemons like
> .Xr ospfd 8 .
> .Pp
> .It Xo
> -.Ic prefix-set Ar name
> -.Ic { Ar address Ns Li / Ns Ar len ... Ic }
> -.Xc
> -A
> -.Ic prefix-set
> -holds a collection of prefixes and can be used in place
> -of the
> -.Ic prefix
> -parameter in
> -.Sx FILTER
> -rules.
> -.\" XXX not implemented
> -.\" and
> -.\".Ic network
> -.\" statements.
> -Lookups against prefix-sets are more efficient than a large number of rules
> -which differ only in prefix.
> -.Pp
> -A prefix can be followed by the prefixlen operators listed for the
> -.Ic prefix
> -parameter in the
> -.Sx PARAMETERS
> -section.
> -.Pp
> -The first example creates a set of prefixes called
> -.Dq private ,
> -to hold a number of RFC 1918 private network blocks.
> -The second example shows the use of prefixlen operators.
> -.Bd -literal -offset indent
> -prefix-set private { 10.0.0.0/8, 172.16.0.0/12,
> - 192.168.0.0/16, fc00::/7 }
> -prefix-set as64496set { 192.0.2.0/24 prefixlen >= 26,
> - 2001:db8::/32 or-longer }
> -.Ed
> -.Pp
> -.It Xo
> .Ic rde
> .Ic med
> .Ic compare
> @@ -445,21 +335,6 @@ The default is
> .Ic ignore .
> .Pp
> .It Xo
> -.Ic roa-set
> -.Ic { Ar address Ns Li /
traceroute6 and ospf6d (icmp6 source addresses and link-locals)
With ospf6d, routes are added using link-local addresses. ICMP6 messages are generated with a source of, I think, the local address associated with the route to the recipient, so with a couple of hops in the internal network it results in traceroutes looking like $ traceroute6 -n www.google.com traceroute6 to www.google.com (2a00:1450:4009:80f::2004), 64 hops max, 60 byte packets 1 fe80::5606:33d8:d784:cd2f%vlan701 (fe80::5606:33d8:d784:cd2f%vlan701) 0.519 ms 1.547 ms 0.417 ms 2 * * * 3 * * * 4 2001:728:0:5000::55 7.843 ms 8.236 ms 7.391 ms [...] The first hop works (ugliness aside) because the link-local is directly connected, the next ones don't because the ICMP response are sourced from a link-local addresses (to match the route to the destination) but these aren't allowed to be forwarded by routers. (And once packets have left the AS, things work as expected on global addresses). What's anyone else doing? Just living with it or has anyone figured a way to make it nicer? I'd like to reply with either a global scope address for the interface, or a loopback address, I didn't get anywhere with PF translation though.
Re: traceroute6 and ospf6d (icmp6 source addresses and link-locals)
On 2018/10/05 18:38, Alexander Bluhm wrote:
> IPv6 Source selection is a mess!
>
> > ICMP6 messages
> > are generated with a source of, I think, the local address associated with
> > the route to the recipient,
>
> It is not that simple. Look at in6_ifawithscope() in sys/netinet6/in6.c.
I know that's used for newly generated packets, but I'm not sure it's the
case for icmp6, I haven't tried modifying the kernel to confirm for sure
that this is the code generating the address in this case, but it seems
likely, in icmp6.c:
/*
1112 * If the incoming packet was addressed directly to us (i.e.
unicast),
1113 * use dst as the src for the reply.
1114 * The IN6_IFF_TENTATIVE|IN6_IFF_DUPLICATED case would be VERY
rare,
1115 * but is possible (for example) when we encounter an error while
1116 * forwarding procedure destined to a duplicated address of ours.
1117 */
1118 rt = rtalloc(sin6tosa(&sa6_dst), 0, rtableid);
1119 if (rtisvalid(rt) && ISSET(rt->rt_flags, RTF_LOCAL) &&
1120 !ISSET(ifatoia6(rt->rt_ifa)->ia6_flags,
1121 IN6_IFF_ANYCAST|IN6_IFF_TENTATIVE|IN6_IFF_DUPLICATED)) {
1122 src = &t;
1123 }
> Could you provide your ifconfig and route output? So we could
> figure out into which path of this algorith you are running.
The host running traceroute has a handful of global scope addresses on
loopback interfaces, plus a global scope address on a vlan interface
facing the next router, all advertised into ospf.
The default source address is one of the loopbacks,
2001:67c:15f4:a423::26, so the only route back from the rest of the
network to this address is via link-locals all the way.
BGP routes changed so I'll include a traceroute using the default source
address again so all the new copied output is consistent:
$ traceroute6 -n www.google.com
traceroute6 to www.google.com (2a00:1450:4009:80b::2004), 64 hops max, 60 byte
packets
1 fe80::5606:33d8:d784:cd2f%vlan701 0.494 ms 0.362 ms 0.373 ms
2 * * *
3 * * *
4 2001:7f8:17::1b1b:1 7.272 ms 7.332 ms 6.938 ms
5 2001:7f8:17::3b41:1 6.699 ms 6.342 ms 6.453 ms
[...]
>From the first hop router,
gr1$ route -n get -inet6 2001:67c:15f4:a423::26
route to: 2001:67c:15f4:a423::26
destination: 2001:67c:15f4:a423::26
mask: :::::::
gateway: fe80::e648:4970:e85f:5e13%vlan701
interface: vlan701
if address: fe80::5606:33d8:d784:cd2f%vlan701
priority: 32 (ospf)
flags:
use mtuexpire
29464060 0 0
>From the second hop router,
gr5$ route -n get -inet6 2001:67c:15f4:a423::26
route to: 2001:67c:15f4:a423::26
destination: 2001:67c:15f4:a423::26
mask: :::::::
gateway: fe80::d05a:f0e8:e5e:a30a%vlan740
interface: vlan740
if address: fe80::b769:5751:d87b:44b7%vlan740
priority: 32 (ospf)
flags:
use mtuexpire
20369017 0 0
If instead I source packets from the vlan interface (directly connected
to the next router), I instead get this:
$ traceroute6 -n -s 2a03:8920:1:52bd::184 www.google.com
traceroute6 to www.google.com (2a00:1450:4009:80b::2004) from
2a03:8920:1:52bd::184, 64 hops max, 60 byte packets
1 2a03:8920:1:52bd::181 1.769 ms 0.382 ms 0.377 ms
2 * * *
3 * * *
4 2001:7f8:17::1b1b:1 6.931 ms 6.999 ms 7.115 ms
5 2001:7f8:17::3b41:1 6.466 ms 6.568 ms 6.416 ms
The routes in this case from the hop 1 and 2 routers are
gr1$ route -n get -inet6 2a03:8920:1:52bd::184
route to: 2a03:8920:1:52bd::184
destination: 2a03:8920:1:52bd::184
mask: :::::::
interface: vlan701
if address: 2a03:8920:1:52bd::181
priority: 3 ()
flags:
use mtuexpire
22811 0 3
gr5$ route -n get -inet6 2a03:8920:1:52bd::184
route to: 2a03:8920:1:52bd::184
destination: 2a03:8920:1:52bd::
mask: :::::
gateway: fe80::d05a:f0e8:e5e:a30a%vlan740
interface: vlan740
if address: fe80::b769:5751:d87b:44b7%vlan740
priority: 32 (ospf)
flags:
use mtuexpire
234 0 0
So the first hop packet is returned from a "normal" address, and the
second (from tcpdump) is returned from fe80::b769:5751:d87b:44b7 and of
course doesn't make it all the way back to the host running traceroute.
> Once I have have added the following rule from a newer RFC. It
> makes things better for many caes, but not with OSPF6. There you
> may have an interface with only link-local addresses. Then this
> link-local is used instead of another better scoped one.
I have global addresses on all interfaces involved, none of the involved
interfaces just have link-local.
> /* RFC 3484 5. Rule 5: Prefer outgoing interface */
>
> > 4 2001:728:0:5000::55 7.843 ms 8.236 ms 7.391 ms
>
> How can this work? Does your AS-Bounda
Re: Clean install or upgrade to 6.4 fw_update error
That error message is because there are no syspatch yet, it is not from the firmware update. On 18 October 2018 16:02:34 Mischa wrote: Hi All, Just ran a couple of updates and clean installs and I am seeing the following error during boot. Clean install: running rc.firsttime Path to firmware: http://firmware.openbsd.org/firmware/6.4/ Installing: intel-firmware Checking for available binary patches...ftp: Error retrieving file: 404 Not Found Upgrade: running rc.firsttime Path to firmware: http://firmware.openbsd.org/firmware/6.4/ Updating: intel-firmware-20180807v0 Checking for available binary patches...ftp: Error retrieving file: 404 Not Found Doing this by hand after login is successful. # fw_update -v intel-firmware-20180807p0v0 Path to firmware: http://firmware.openbsd.org/firmware/6.4/ Updating: intel-firmware-20180807p0v0 Mischa
Re: signify: invalid comment in /tmp/syspatch.xxx/SHA256.sig
On 2018/10/18 18:58, James Anderson wrote: > Freshly upgraded to 6.4, rebooted and went to update syspatches, firmware, > packages. Running syspatch I expected a 404 error > (https://marc.info/?l=openbsd-tech&m=153987805403874&w=2), but instead > was greeted with "signify: invalid comment". Thought this was a local > issue but there are no /tmp/syspatch.*/SHA256.sig files. > > Reproducible by running syspatch again. > > > # /usr/sbin/syspatch > signify: invalid comment in /tmp/syspatch.iujrhbPKJw/SHA256.sig;must start > with 'untrusted comment: ' > > # /usr/sbin/syspatch > signify: invalid comment in /tmp/syspatch.27SgFlZvHH/SHA256.sig; must start > with 'untrusted comment: ' > > # /usr/sbin/syspatch > signify: invalid comment in /tmp/syspatch.PNiOjhEPTx/SHA256.sig; must start > with 'untrusted comment: ' > Fixed on some mirrors now; others will catch up shortly.
Re: bgplg: allow neighbors with space in name
On 2018/10/24 17:38, Denis Fondras wrote: > I have peers with description containing spaces but bgplg won't accept that by > default. > > I'd like some comments on that diff. > It is OK for bgplgsh (show ip bgp in "Peer 1" feels OK) but not for bgplg as I > have to quote the peer description in the input box (feels rather unnatural). it feels like allowing " in allowed characters for the CGI is starting to open a can of worms.. personally I think I'd change the descriptions to avoid spaces.
Re: unveil ospfd's parent proc
On 2018/10/26 18:15, Remi Locherer wrote: > On Fri, Oct 26, 2018 at 06:01:40PM +0200, Florian Obser wrote: > > This breaks usage of the "include" keyword. Something that all the parse.y > > daemons support. > > > > Oh, of course! > > I guess this is similar to unveil files based on a list of command line args. Similar, but with parse.y daemons, it can change at config reload time too.
Re: wdc(4): remove unnecessary if/else block
On 2018/11/01 23:00, Frederic Cambus wrote:
> Hi tech@,
>
> Remove unnecessary if/else block, both branches are identical. We can
> in fact use the ATA_DELAY macro directly.
>
> Coverity CID 1453008.
>
> Comments? OK?
>
> Index: dev/ata/ata_wdc.c
> ===
> RCS file: /cvs/src/sys/dev/ata/ata_wdc.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 ata_wdc.c
> --- dev/ata/ata_wdc.c 30 Dec 2017 20:46:59 - 1.51
> +++ dev/ata/ata_wdc.c 1 Nov 2018 12:34:17 -
> @@ -240,7 +240,6 @@ _wdc_ata_bio_start(struct channel_softc
> u_int16_t cyl;
> u_int8_t head, sect, cmd = 0;
> int nblks;
> - int ata_delay;
> int error, dma_flags = 0;
>
> WDCDEBUG_PRINT(("_wdc_ata_bio_start %s:%d:%d\n",
> @@ -283,10 +282,6 @@ _wdc_ata_bio_start(struct channel_softc
> if (ata_bio->flags & ATA_LBA48)
> dma_flags |= WDC_DMA_LBA48;
> }
> - if (ata_bio->flags & ATA_SINGLE)
> - ata_delay = ATA_DELAY;
> - else
> - ata_delay = ATA_DELAY;
There since r1.1 :-)
The indirection could possibly have been done to allow tweaking the
delay with ddb for debug, but I don't think that really matters for wdc
any more..
OK with me
> again:
> /*
>*
> @@ -345,7 +340,7 @@ again:
> }
> /* Initiate command */
> wdc_set_drive(chp, xfer->drive);
> - if (wait_for_ready(chp, ata_delay) < 0)
> + if (wait_for_ready(chp, ATA_DELAY) < 0)
> goto timeout;
>
> /* start the DMA channel (before) */
> @@ -391,7 +386,7 @@ again:
> }
> /* Initiate command! */
> wdc_set_drive(chp, xfer->drive);
> - if (wait_for_ready(chp, ata_delay) < 0)
> + if (wait_for_ready(chp, ATA_DELAY) < 0)
> goto timeout;
> if (ata_bio->flags & ATA_LBA48) {
> wdccommandext(chp, xfer->drive, cmd,
> @@ -410,7 +405,7 @@ again:
> }
> /* If this was a write and not using DMA, push the data. */
> if ((ata_bio->flags & ATA_READ) == 0) {
> - if (wait_for_drq(chp, ata_delay) != 0) {
> + if (wait_for_drq(chp, ATA_DELAY) != 0) {
> printf("%s:%d:%d: timeout waiting for DRQ, "
> "st=0x%b, err=0x%02x\n",
> chp->wdc->sc_dev.dv_xname, chp->channel,
>
Re: prevent bgpd from starting when control socket already used
On 2018/11/11 22:45, Job Snijders wrote: > Shouldnt we already bomb out at the following? > > cannot bind to 0.0.0.0:179: Address already in use > cannot bind to [::]:179: Address already in use > > In any regard, I agree with the functionality proposed. No strong opinion > on the diff itself. Should: probably, yes, but we don't at present. Last time I did this by mistake I ended up having to get onto the *peer* via OOB, I can't remember if killing bgpd was enough, I have a feeling I had to force a reboot..
Re: 6.4 openBGPD Segfault caused by filters referencing undeclared prefix-set
On 2018/11/18 08:58, Tom Smyth wrote: > I have attached the coredump Generally the coredump by itself isn't that useful to others as it needs the right binary to go with it, a backtrace is usually better: gdb /usr/sbin/bgpd /path/to/bgpd.core bt For reference, in some cases multiple processes will crash, because the filenames are all "bgpd.core" they can overwrite each other. See the bottom of the sysctl manpage for a way around that.
Re: traceroute6 and ospf6d (icmp6 source addresses and link-locals)
On 2018/12/05 12:40, Arnaud BRAND wrote: > Or is there something else I missed ? > > > + if (ifa != NULL) src = &(ifa->ia_addr.sin6_addr); > > > + if (src == NULL) src = > > > &ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr; if (ifa != NULL) src = &(ifa->ia_addr.sin6_addr); if (src == NULL) src = &ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr;
Re: [Patch] Specify unit for 'every' in ifstated.conf.5
On 2018/12/06 13:01, Ted Unangst wrote: > Jason McIntyre wrote: > > On Thu, Dec 06, 2018 at 10:21:47PM +1100, Ross L Richardson wrote: > > > > > > The number is in seconds, but that's currently not specified. > > > > > > Wording which preserved "frequency" but made sense with "seconds" > > > eluded me, so I changed things to refer to "interval". > > > > > > > > > Ross > > > > > > > > > > > > Index: ifstated.conf.5 > > > === > > > RCS file: /cvs/src/usr.sbin/ifstated/ifstated.conf.5,v > > > retrieving revision 1.13 > > > diff -u -p -r1.13 ifstated.conf.5 > > > --- ifstated.conf.5 18 Jun 2018 06:04:25 - 1.13 > > > +++ ifstated.conf.5 6 Dec 2018 11:12:44 - > > > @@ -90,7 +90,8 @@ interfaces this equals the init state. > > > .Pp > > > In contrast to link state tests, external tests must be run periodically > > > to > > > evaluate their status. > > > -The frequency at which an external test is run has to be set with the > > > +The interval in seconds between invocations of an external test has to > > > +be set with the > > > .Ar every > > The interval in seconds between test runs is specified by the required keyword > every. > That implies "test 2 starts X seconds after the *end* of test 1", but actually it's "test 2 starts X seconds after the *start* of test 1" which is what I think the original use of "frequency" was trying to imply.
Re: nsd 4.1.26
On 2018/12/06 11:02, Florian Obser wrote: > tests, OKs? OK. Very little change apart from the dnstap interface that we can't use.
Re: [PATCH] Always generate SAN
Moved to tech@. Full original mail at
https://marc.info/?l=openbsd-misc&m=163187837530385&w=2
On 2021-09-17, Wolf wrote on misc@:
> Use of only CN is not allowed according to Baseline Requirements 1.8.0
> from CA Browser Forum. Using CN is not prohibited, but if it is present,
> value in it must also be present in SAN. And SAN is always required.
Baseline requirements relate to the CA-signed certificate; a CA will
make changes to the certificate requested in a CSR for baseline requirements
compliance.
> While currently Let's Encrypt does accept requests without CN, in the
> interest of future-proofing, this commit modifies acme-client to always
> generate SAN and include CN in it.
There are two issues:
- if you only list a plain domain (no "alternative names") in acme-client.conf
then subjectAlternativeName isn't generated in the CSR at all.
a CA is definitely expected to fix this up. If this was the only problem
then I would recommend deferring to post-7.0.
- if you list alternative domains, only the alternatives and not the
main domain are listed in subjectAlternativeName in the CSR.
This is definitely wrong. If SAN is present, the domain name in the subject
must be ignored. Current CAs are clearly fixing this up, but we are generating
the SANs incorrectly here and I don't think we should rely on them being fixed,
So I think for this reason it's worth getting this in pre 7.0.
> I recommend viewing the diff with whitespace differences ignored (-w),
> helps to show how minimal it is.
Indeed; "if (altsz > 1)" is removed shifting the indentation up a level,
and the loop initialiser is changed from "i = 1" to "i = 0".
> I've tested this and it issues valid certificate that includes both CN
> and SAN (check current cert of wolfsden.cz if you want to make sure).
>
> Baseline Requirements can be found here [0], CN is described in
> 7.1.4.2.2.
>
> Why this is even a problem: My version of acme-client has some tests and
> pebble (let's encrypt's test server) already does not accept
> certificates without correct SAN [1].
pebble is not exactly "letsencrypt's test server" (which I'd think of as
their staging server) it's test server *software* for integration testing etc
and is expected to be more strict than a real server. (i.e. if someone wants
to test this against a fussy server, they will need to run the software
themselves, running against letsencrypt-staging is *not* sufficient).
> usr.sbin/acme-client/keyproc.c | 90 +-
> 1 file changed, 44 insertions(+), 46 deletions(-)
[quoting removed so they diff will apply directly; it is unchanged from the
original]
This is OK sthen@.
diff --git a/usr.sbin/acme-client/keyproc.c b/usr.sbin/acme-client/keyproc.c
index b4cc6184e26..3a1d68526d9 100644
--- a/usr.sbin/acme-client/keyproc.c
+++ b/usr.sbin/acme-client/keyproc.c
@@ -175,53 +175,51 @@ keyproc(int netsock, const char *keyfile, const char
**alts, size_t altsz,
* TODO: is this the best way of doing this?
*/
- if (altsz > 1) {
- nid = NID_subject_alt_name;
- if ((exts = sk_X509_EXTENSION_new_null()) == NULL) {
- warnx("sk_X509_EXTENSION_new_null");
- goto out;
- }
- /* Initialise to empty string. */
- if ((sans = strdup("")) == NULL) {
- warn("strdup");
- goto out;
- }
- sansz = strlen(sans) + 1;
-
- /*
-* For each SAN entry, append it to the string.
-* We need a single SAN entry for all of the SAN
-* domains: NOT an entry per domain!
-*/
-
- for (i = 1; i < altsz; i++) {
- cc = asprintf(&san, "%sDNS:%s",
- i > 1 ? "," : "", alts[i]);
- if (cc == -1) {
- warn("asprintf");
- goto out;
- }
- pp = recallocarray(sans, sansz, sansz + strlen(san), 1);
- if (pp == NULL) {
- warn("recallocarray");
- goto out;
- }
- sans = pp;
- sansz += strlen(san);
- strlcat(sans, san, sansz);
- free(san);
- san = NULL;
- }
-
- if (!add_ext(exts, nid, sans)) {
- warnx("add_ext");
- goto out;
- } else if (!X509_REQ_add_extensions(x, exts)) {
- warnx("X509_REQ_add_extensions");
- goto out;
- }
- sk_X509_EXTENSION_pop_free(exts, X509_EXTENSION_free);
+ nid = NID_subject_alt_name;
+ if ((exts = sk_X509_EXTENSION_new_null()) == NULL) {
+
Re: pf.conf(5) & reply-to
On 2021/09/22 11:28, Landry Breuil wrote: > Le Tue, Sep 21, 2021 at 10:40:12PM +0200, Sebastian Benoit a écrit : > > Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200: > > > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > > > > did i screwup something somewhere in my config and there's a better way > > > > for that ? > > > > > > This was changed in February. No more interface, but gateway > > > addresses. It seems that some parts of the documentation were > > > missed. > > > > > > > should the manpage be improved for reply-to and talk about 'destination > > > > address' instead of 'interface' like route-to does ? > > > > > > Yes. > > > > > > It looks like most information is in the commit message. > > > https://marc.info/?l=openbsd-cvs&m=161213948819452&w=2 > > > > It's also on http://www.openbsd.org/faq/upgrade69.html > > my english sucks and i'm not sure i got the meaning right, but here's a > try: > > Index: pf.conf.5 > === > RCS file: /cvs/src/share/man/man5/pf.conf.5,v > retrieving revision 1.587 > diff -u -r1.587 pf.conf.5 > --- pf.conf.5 19 Jul 2021 16:23:56 - 1.587 > +++ pf.conf.5 22 Sep 2021 09:23:14 - > @@ -1103,13 +1103,14 @@ > option is similar to > .Cm route-to , > but routes packets that pass in the opposite direction (replies) to the > -specified interface. > +specified address. > Opposite direction is only defined in the context of a state entry, and > .Cm reply-to > is useful only in rules that create state. > It can be used on systems with multiple external connections to > -route all outgoing packets of a connection through the interface > -the incoming connection arrived through (symmetric routing enforcement). > +route all outgoing packets of a connection through the interface the incoming > +connection arrived through (symmetric routing enforcement) via the address of > +the gateway specified in the rule. I think using "connection" twice (internet connection, and TCP/UDP/...\ connection) can make this harder to read. Not 100% happy with this and I have to go out so won't do any more wordsmithing now, but maybe it gives some ideas? It can be used on systems with multiple paths to the internet to ensure that replies to an incoming network connection to a particular address are sent using the path associated with that address (symmetric routing enforcement). This is done by specifying the address of the gateway in "reply-to". > .It Cm route-to > The > .Cm route-to > > i wouldnt know how to change the example in faq/upgrade69.html as it is valid > (but only specific to the case of a point-to-point interface with a :peer > property) > > ccing experts :) >
Re: Should 80MB of RAM be enough for kernel relinking on i386?
Nobody should really by using i386 for new systems. The advantages of running amd64-compatible hardware are too big to ignore. Lower power consumption, much faster in most cases (the extra register used by PIE hurts i386 mode a lot more than amd64 mode with its extra registers), more address space for ASLR, some other security mitigations don't work on i386, more compatible with software in ports. If it's an old system then you already have it so you can just see for yourself how much space it needs (and make your own decisions on swap space vs RAM, and whether to disable relinking at boot [just using it for upgrades/syspatch], and whether to bodge things to use ld.bfd to save RAM). So much depends on how you're going to use the system that I don't think it's really useful to publish the numbers.
Re: sigwaitinfo(2) and sigtimedwait(2)
On 2021/09/24 19:36, Rafael Sadowski wrote: > I'm trying to port the more KDE stuff so my question is from porter > perspective. > > I need sigwaitinfo(2)/sigtimedwait(2) and I found both functions in > lib/libc/gen/sigwait.c with the comment "need kernel to fill in more > siginfo_t bits first". Is the comment still up to date? If no, is it > possible to unlock the functions? > > Thanks, Rafael > I don't think any more bits have been filled in since these were added revision 1.13 date: 2012/04/13 08:25:37; author: guenther; state: Exp; lines: +40 -1; Add sigwaitinfo and sigtimedwait stubs under #if 0; a bit more kernel support is needed before they can be usefully enabled but I don't want to misplace this diff yet again For sure si_pid is not filled in, I ran into that with icinga2 relatively recently (jmatthew helped a lot figuring that one out).. https://marc.info/?t=12021803142&r=1&w=2
Re: Variable type fix in parse.y (all of them)
On 2021/09/29 21:21, Christian Weisgerber wrote:
> The oft-copied parse.y code declares some variables as "unsigned char *"
> but passes them to functions that take "char *" arguments and doesn't
> make any use of the unsigned property.
btw, those used to be char:
revision 1.628
date: 2013/11/25 12:52:45; author: benno; state: Exp; lines: +7 -7;
use u_char for buffers in yylex, for ctype calls
found by millert@, ok deraadt@
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.627
retrieving revision 1.628
diff -u -p -r1.627 -r1.628
--- parse.y 22 Nov 2013 04:12:48 - 1.627
+++ parse.y 25 Nov 2013 12:52:45 - 1.628
@@ -1,4 +1,4 @@
-/* $OpenBSD: parse.y,v 1.627 2013/11/22 04:12:48 deraadt Exp $ */
+/* $OpenBSD: parse.y,v 1.628 2013/11/25 12:52:45 benno Exp $ */
/*
* Copyright (c) 2001 Markus Friedl. All rights reserved.
@@ -5536,9 +5536,9 @@ lookup(char *s)
#define MAXPUSHBACK128
-char *parsebuf;
+u_char *parsebuf;
int parseindex;
-charpushback_buffer[MAXPUSHBACK];
+u_char pushback_buffer[MAXPUSHBACK];
int pushback_index = 0;
int
@@ -5630,8 +5630,8 @@ findeol(void)
int
yylex(void)
{
- char buf[8096];
- char*p, *val;
+ u_char buf[8096];
+ u_char *p, *val;
int quotec, next, c;
int token;
@@ -5654,7 +5654,7 @@ top:
return (findeol());
}
if (isalnum(c) || c == '_') {
- *p++ = (char)c;
+ *p++ = c;
continue;
}
*p = '\0';
@@ -5699,7 +5699,7 @@ top:
yyerror("string too long");
return (findeol());
}
- *p++ = (char)c;
+ *p++ = c;
}
yylval.v.string = strdup(buf);
if (yylval.v.string == NULL)
Re: OpenBSD Errata: September 30, 2021 (libressl)
On 2021/09/30 21:45, Sebastian Benoit wrote: > An errata patch for LibreSSL has been released for OpenBSD 6.8 and > OpenBSD 6.9. > > Compensate for the expiry of the DST Root X3 certificate. The use of an > unnecessary expired certificate in certificate chains can cause validation > errors. > > Binary updates for the amd64, i386 and arm64 platform are available > via the syspatch utility. Source code patches can be found on the > respective errata page: > > https://www.openbsd.org/errata68.html > https://www.openbsd.org/errata69.html > Note: you may have issues fetching the syspatches from your regular mirror due to this issue. Try fetching it normally first, as a number of mirrors are either unaffected, or have a workaround on the server side, but if that fails you have two options: - edit /etc/installurl to allow you to fetch the syspatches. Either switch https to http (the updates are signed and verified anyway), or use another mirror (including ftp.usa.openbsd.org, ftp.hostserver.de, cdn.openbsd.org). - locate the expired certificate in /etc/ssl/cert.pem and remove it, it is the one with this in the header above: === /O=Digital Signature Trust Co./CN=DST Root CA X3 If you're able to install the syspatch anyway (syspatch69-018_cert.tgz or syspatch68-032_cert.tgz) then you don't need either of the above steps.
Re: Relayd daily crash ca_dispatch_relay invalid
On 2021/10/01 09:29, abyx...@mnetic.ch wrote: > I'm getting a daily crash (call to fatalx). No clue what triggers it and the > logging is really sparse. I couldn't follow what the code in ca.c is actually > doing (what the hash belongs to that is triggering the crash). A snip from > /var/log/daemon is reproduced below. There are no other log messages in any > logs around the same time frame as the relayd shutdown. Also, that fd passing > failed for https is concerning. Any suggestions in debugging this? OpenBSD > 6.9, dmesg at bottom. > > > grep relayd /var/log/daemon > 876:Sep 30 15:07:39 mnetic relayd[222]: adding 1 hosts from table > axolotlfeeds:7053 (no check) > 877:Sep 30 15:07:39 mnetic relayd[44589]: adding 1 hosts from table > axolotlfeeds:7053 (no check) > 878:Sep 30 15:07:39 mnetic relayd[57595]: adding 1 hosts from table > axolotlfeeds:7053 (no check) > 909:Oct 1 00:42:20 mnetic relayd[95946]: ca: ca_dispatch_relay: invalid > relay hash > 'SHA256:f545fa75bd01d82c05359e21ae769d525c2971b8221a8e50e415fe3e62ea6553' > 910:Oct 1 00:42:20 mnetic relayd[44589]: relay: pipe closed > 911:Oct 1 00:42:20 mnetic relayd[8473]: hce exiting, pid 8473 > 912:Oct 1 00:42:20 mnetic relayd[15293]: pfe exiting, pid 15293 > 913:Oct 1 00:42:20 mnetic relayd[29437]: ca exiting, pid 29437 > 914:Oct 1 00:42:20 mnetic relayd[52845]: ca exiting, pid 52845 > 915:Oct 1 00:42:20 mnetic relayd[99285]: parent terminating, pid 99285 > 916:Oct 1 00:42:20 mnetic relayd[222]: relay exiting, pid 222 > 917:Oct 1 00:42:20 mnetic relayd[57595]: relay exiting, pid 57595 > 921:Oct 1 09:12:59 mnetic relayd[2129]: startup > 922:Oct 1 09:12:59 mnetic relayd[2129]: config_setrelay: fd passing failed > for `https': Too many open files ^^^ By default the limit for relayd is controlled by the openfiles settings for the "daemon" class in /etc/login.conf. You can check current use with fstat | grep -c relayd. If you need to raise it you can add something like this to the file, replacing XXX with "what you normally see when it's busy plus some extra leeway" and then "rcctl restart relayd" so it takes effect. relayd:\ :openfiles-max=XXX:\ :openfiles-cur=XXX:\ :tc=default: > dmesg > OpenBSD 6.9 (GENERIC) #5: Tue Aug 10 08:11:10 MDT 2021 > r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1056833536 (1007MB) > avail mem = 1009586176 (962MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6320 (9 entries) > bios0: vendor SeaBIOS version "Ubuntu-1.8.2-1ubuntu1.1" date 04/01/2014 > bios0: QEMU Standard PC (i440FX + PIIX, 1996) > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S3 S4 S5 > acpi0: tables DSDT FACP SSDT APIC HPET > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Westmere E56xx/L56xx/X56xx (Nehalem-C), 3067.15 MHz, 06-2c-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,HV,NXE,LONG,LAHF,ARAT,MELTDOWN > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 999MHz > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpihpet0 at acpi0: 1 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > "ACPI0006" at acpi0 not configured > acpipci0 at acpi0 PCI0 > acpicmos0 at acpi0 > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > acpicpu0 at acpi0: C1(@1 halt!) > cpu0: using IvyBridge MDS workaround > pvbus0 at mainbus0: KVM > pvclock0 at pvbus0 > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 > wired to compatibility, channel 1 wired to compatibility > atapiscsi0 at pciide0 channel 0 drive 1 > scsibus1 at atapiscsi0: 2 targets > cd0 at scsibus1 targ 0 lun 0: removable > cd0(pciide0:0:1): using PIO mode 4, DMA mode 2 > pciide0: channel 1 disabled (no drives) > uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11 > piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9 > iic0 at piixpm0 > vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: scree
Re: Relayd daily crash ca_dispatch_relay invalid
On 2021/10/01 14:43, Stuart Henderson wrote: > On 2021/10/01 09:29, abyx...@mnetic.ch wrote: > > I'm getting a daily crash (call to fatalx). No clue what triggers it and > > the logging is really sparse. I couldn't follow what the code in ca.c is > > actually doing (what the hash belongs to that is triggering the crash). A > > snip from /var/log/daemon is reproduced below. There are no other log > > messages in any logs around the same time frame as the relayd shutdown. > > Also, that fd passing failed for https is concerning. Any suggestions in > > debugging this? OpenBSD 6.9, dmesg at bottom. > > > > > > grep relayd /var/log/daemon > > 876:Sep 30 15:07:39 mnetic relayd[222]: adding 1 hosts from table > > axolotlfeeds:7053 (no check) > > 877:Sep 30 15:07:39 mnetic relayd[44589]: adding 1 hosts from table > > axolotlfeeds:7053 (no check) > > 878:Sep 30 15:07:39 mnetic relayd[57595]: adding 1 hosts from table > > axolotlfeeds:7053 (no check) > > 909:Oct 1 00:42:20 mnetic relayd[95946]: ca: ca_dispatch_relay: invalid > > relay hash > > 'SHA256:f545fa75bd01d82c05359e21ae769d525c2971b8221a8e50e415fe3e62ea6553' > > 910:Oct 1 00:42:20 mnetic relayd[44589]: relay: pipe closed > > 911:Oct 1 00:42:20 mnetic relayd[8473]: hce exiting, pid 8473 > > 912:Oct 1 00:42:20 mnetic relayd[15293]: pfe exiting, pid 15293 > > 913:Oct 1 00:42:20 mnetic relayd[29437]: ca exiting, pid 29437 > > 914:Oct 1 00:42:20 mnetic relayd[52845]: ca exiting, pid 52845 > > 915:Oct 1 00:42:20 mnetic relayd[99285]: parent terminating, pid 99285 > > 916:Oct 1 00:42:20 mnetic relayd[222]: relay exiting, pid 222 > > 917:Oct 1 00:42:20 mnetic relayd[57595]: relay exiting, pid 57595 > > 921:Oct 1 09:12:59 mnetic relayd[2129]: startup > > 922:Oct 1 09:12:59 mnetic relayd[2129]: config_setrelay: fd passing failed > > for `https': Too many open files > > ^^^ > > By default the limit for relayd is controlled by the openfiles settings > for the "daemon" class in /etc/login.conf. You can check current use > with fstat | grep -c relayd. If you need to raise it you can add > something like this to the file, replacing XXX with "what you normally > see when it's busy plus some extra leeway" and then "rcctl restart > relayd" so it takes effect. > > relayd:\ > :openfiles-max=XXX:\ > :openfiles-cur=XXX:\ > :tc=default: Hmm. Rereading your mail it might not be that..but if the limit is too low you could have other things failing as a result..
Re: Remove deprecated variables in sysctl(2)
On 2021/10/05 18:11, Solene Rapenne wrote: > Variables HW_PHYSMEM and HW_USERMEM were deprecated 13 years ago, > maybe we can remove them from sysctl(2)? "deprecated" doesn't mean removed or disabled, it just means that one shouldn't use them. These are still in system headers and supported by the kernel, and could possibly be used by ports. > It was originally in sysctl(3) if someone want to do some history > research > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/Attic/sysctl.3#rev1.178 > > Index: sysctl.2 > === > RCS file: /home/reposync/src/lib/libc/sys/sysctl.2,v > retrieving revision 1.44 > diff -u -p -r1.44 sysctl.2 > --- sysctl.2 18 May 2021 05:26:26 - 1.44 > +++ sysctl.2 5 Oct 2021 16:03:28 - > @@ -289,13 +289,11 @@ privileges may change the value. > .It Dv HW_NCPUONLINE Ta "integer" Ta "no" > .It Dv HW_PAGESIZE Ta "integer" Ta "no" > .It Dv HW_PERFPOLICY Ta "string" Ta "yes" > -.It Dv HW_PHYSMEM Ta "integer" Ta "no" > .It Dv HW_PHYSMEM64 Ta "int64_t" Ta "no" > .It Dv HW_PRODUCT Ta "string" Ta "no" > .It Dv HW_SENSORS Ta "node" Ta "not applicable" > .It Dv HW_SETPERF Ta "integer" Ta "yes" > .It Dv HW_SMT Ta "integer" Ta "yes" > -.It Dv HW_USERMEM Ta "integer" Ta "no" > .It Dv HW_USERMEM64 Ta "int64_t" Ta "no" > .It Dv HW_UUID Ta "string" Ta "no" > .It Dv HW_VENDOR Ta "string" Ta "no" > @@ -343,11 +341,6 @@ Can be one of > .Dq auto , > or > .Dq high . > -.It Dv HW_PHYSMEM > -The total physical memory, in bytes. > -This variable is deprecated; use > -.Dv HW_PHYSMEM64 > -instead. > .It Dv HW_PHYSMEM64 Pq Va hw.physmem > The total physical memory, in bytes. > .It Dv HW_PRODUCT Pq Va hw.product > @@ -393,11 +386,6 @@ is set to > If set to 1, enable simultaneous multithreading (SMT) on CPUs that > support it. > Disabled by default. > -.It Dv HW_USERMEM > -The amount of available non-kernel memory in bytes. > -This variable is deprecated; use > -.Dv HW_USERMEM64 > -instead. > .It Dv HW_USERMEM64 Pq Va hw.usermem > The amount of available non-kernel memory in bytes. > .It Dv HW_UUID Pq Va hw.uuid >
etc/syslog.conf: adjust comment for log host sample config
The comments in etc/syslog.conf describe partially log-client setup and partially log-host setup and use UDP. I think it would be better to focus on "loghost-client" setup in the default config, the server options needed seem better described in syslogd(8) than in comments in syslog.conf. Since we have nice TLS features I think it makes sense to advertise them here too, and remove the mention of ISDN which makes it seem dated. any comments? OK? Index: syslog.conf === RCS file: /cvs/src/etc/syslog.conf,v retrieving revision 1.20 diff -u -p -r1.20 syslog.conf --- syslog.conf 27 Dec 2016 13:38:14 - 1.20 +++ syslog.conf 9 Oct 2021 11:48:35 - @@ -22,13 +22,10 @@ mail.info /var/log/maillog # Everyone gets emergency messages. #*.emerg * -# Uncomment to log to a central host named "loghost". You need to run -# syslogd with the -u option on the remote host if you are using this. -# (This is also required to log info from things like routers and -# ISDN-equipment). If you run -u, you are vulnerable to syslog bombing, -# and should consider blocking external syslog packets. -#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none @loghost -#auth,daemon,syslog,user.info;authpriv,kern.debug @loghost +# Uncomment to log to a central host named "loghost" using syslog-tls. +# Other protocols are available, see syslogd(8). +#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none @tls://loghost +#auth,daemon,syslog,user.info;authpriv,kern.debug @tls://loghost # Uncomment to log messages from doas(1) to its own log file. Matches are done # based on the program name.
syslogd: allow setting TLS protocols
This allows setting which TLS versions are usable by syslogd. Some
environments require that TLSv1.0 is disabled. Manual wording stolen from
ftp(1). any comments? ok?
Index: syslogd.8
===
RCS file: /cvs/src/usr.sbin/syslogd/syslogd.8,v
retrieving revision 1.60
diff -u -p -r1.60 syslogd.8
--- syslogd.8 27 Sep 2018 08:33:25 - 1.60
+++ syslogd.8 9 Oct 2021 20:27:37 -
@@ -51,6 +51,7 @@
.Op Fl S Ar listen_address
.Op Fl s Ar reporting_socket
.Op Fl T Ar listen_address
+.Op Fl t Ar tls_protocols
.Op Fl U Ar bind_address
.Ek
.Sh DESCRIPTION
@@ -155,6 +156,12 @@ There is no well-known port for syslog o
must be specified using the
.Ar host : Ns Ar port
syntax.
+.It Fl t Ar tls_protocols
+Specify the TLS protocols that will be supported by
+.Nm
+(see
+.Xr tls_config_parse_protocols 3
+for details).
.It Fl U Ar bind_address
Create a UDP socket for receiving messages and bind it to the
specified address.
Index: syslogd.c
===
RCS file: /cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.270
diff -u -p -r1.270 syslogd.c
--- syslogd.c 19 Sep 2021 10:17:36 - 1.270
+++ syslogd.c 9 Oct 2021 20:27:37 -
@@ -373,6 +373,7 @@ main(int argc, char *argv[])
char**path_unix, *path_ctlsock;
char**bind_host, **bind_port, **listen_host, **listen_port;
char*tls_hostport, **tls_host, **tls_port;
+ uint32_ttls_protocols = TLS_PROTOCOLS_ALL;
/* block signal until handler is set up */
sigemptyset(&sigmask);
@@ -392,7 +393,7 @@ main(int argc, char *argv[])
nbind = nlisten = ntls = 0;
while ((ch = getopt(argc, argv,
- "46a:C:c:dFf:hK:k:m:nP:p:rS:s:T:U:uVZ")) != -1) {
+ "46a:C:c:dFf:hK:k:m:nP:p:rS:s:T:t:U:uVZ")) != -1) {
switch (ch) {
case '4': /* disable IPv6 */
Family = PF_INET;
@@ -463,6 +464,11 @@ main(int argc, char *argv[])
address_alloc("listen", optarg, &listen_host,
&listen_port, &nlisten);
break;
+ case 't': /* specify protocols for TLS */
+ if (tls_config_parse_protocols(&tls_protocols, optarg)
+ != 0)
+ errx(1, "failed to parse TLS protocols");
+ break;
case 'U': /* allow udp only from address */
address_alloc("bind", optarg, &bind_host, &bind_port,
&nbind);
@@ -645,7 +651,7 @@ main(int argc, char *argv[])
log_warnx("options -c and -k must be used together");
}
if (tls_config_set_protocols(client_config,
- TLS_PROTOCOLS_ALL) != 0)
+ tls_protocols) != 0)
log_warnx("set client TLS protocols: %s",
tls_config_error(client_config));
if (tls_config_set_ciphers(client_config, "all") != 0)
@@ -695,7 +701,7 @@ main(int argc, char *argv[])
tls_config_verify_client(server_config);
}
if (tls_config_set_protocols(server_config,
- TLS_PROTOCOLS_ALL) != 0)
+ tls_protocols) != 0)
log_warnx("set server TLS protocols: %s",
tls_config_error(server_config));
if (tls_config_set_ciphers(server_config, "compat") != 0)
Re: head(1): fully support the legacy -count syntax
On 2021/10/10 14:26, Scott Cheloha wrote: > On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote: > > Bryan Steele wrote: > > > > > On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote: > > > > On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote: > > > > > did anyone ever use it this way, or are you getting ahead of yourself. > > > > > > > > I don't understand the question. > > > > > > I've only ever seen it used with -count as the first argument, can't > > > say it's every occoured to me to type "head file -10". > > That is not what I proposed. Reread my first message: > > https://marc.info/?l=openbsd-tech&m=163388435528203&w=2 i.e. "head -2 -3 somefile" is taken as -3. This is unportable syntax, GNU head doesn't support it, current OpenBSD head doesn't support it, and it doesn't seem to be really meaningful. Additionally I don't think we've ever had a problem with this in ports. I think we would be better served to keep things as-is and not support it. Seems that FreeBSD is the odd one out here?
Re: syslogd: allow setting TLS protocols
On 2021/10/11 15:50, Alexander Bluhm wrote: > On Sat, Oct 09, 2021 at 09:36:01PM +0100, Stuart Henderson wrote: > > This allows setting which TLS versions are usable by syslogd. Some > > environments require that TLSv1.0 is disabled. Manual wording stolen from > > ftp(1). any comments? ok? > > netcat and ftp allow to give TLS options as key=value. Maybe we > want that here, otherwise we could run out of option letters. Do > our users want specific ciphers or other things? For my current use case, simply requiring 1.2 or newer is good enough and I don't need to set particular ciphers. I can change the implementation to use that method, but I wonder which options would be needed. There is only partial consistency between netcat and ftp so far, netcat: noverify, noname, clientcert, muststaple, ciphers, protocols (cafile and clientcert are implemented via flags other than -T) ftp: cafile, capath, depth, do, dont, muststaple, ciphers, protocols, noverifytime Following netcat's lead there is probably no need to move -C/-c/-K/-k to a different flag. Maybe there's some use case for noverifytime. ciphers/protocols make sense. noname/noverify don't seem to make much sense to me for syslogd. > Is it wise to set the same options for client and server TLS? > > When syslogd is relaying messages from dumb devices with broken TLS > stacks to modern SIEM systems, the requirements on both sides are > different. I avoided to dive too deeply into this question by using > sane defaults. I use "all" or "compat" cipher lists. > It seems for your use case the defaults do not match. > > Do you need TLS 1.0 disabled for receiving or sending side? This is a good question. For my current use case as I understand it it's enough to just not be _using_ pre-1.2 TLS, but it's easier to document and prove if the earlier protocols are actually disabled rather than just not used. I would say at a minimum it needs setting server-side but it would be helpful to do client-side as well. I didn't expect to see syslogd used to relaying messages from client to a remote server, but now that you've described it, it makes complete sense and I see how different settings for client and server would be useful there.
pax mtime
This is just a quick hack for now, but we need something like it in
order to correctly extract some newer tars with correct timestamps, in
particular python-generated ones like
https://pypi.io/packages/source/w/wheel/wheel-0.36.2.tar.gz
Index: tar.c
===
RCS file: /cvs/src/bin/pax/tar.c,v
retrieving revision 1.69
diff -u -p -r1.69 tar.c
--- tar.c 14 Jun 2021 00:36:13 - 1.69
+++ tar.c 15 Oct 2021 21:40:49 -
@@ -784,12 +784,17 @@ reset:
arcn->sb.st_mode = (mode_t)(asc_ul(hd->mode, sizeof(hd->mode), OCT) &
0xfff);
arcn->sb.st_size = (off_t)asc_ull(hd->size, sizeof(hd->size), OCT);
- val = asc_ull(hd->mtime, sizeof(hd->mtime), OCT);
- if (val > MAX_TIME_T)
- arcn->sb.st_mtime = INT_MAX;/* XXX 2038 */
- else
- arcn->sb.st_mtime = val;
- arcn->sb.st_ctime = arcn->sb.st_atime = arcn->sb.st_mtime;
+ if (arcn->sb.st_mtime == 0) {
+ val = asc_ull(hd->mtime, sizeof(hd->mtime), OCT);
+ if (val > MAX_TIME_T)
+ arcn->sb.st_mtime = INT_MAX;/* XXX 2038 */
+ else
+ arcn->sb.st_mtime = val;
+ }
+ if (arcn->sb.st_ctime == 0)
+ arcn->sb.st_ctime = arcn->sb.st_mtime;
+ if (arcn->sb.st_atime == 0)
+ arcn->sb.st_atime = arcn->sb.st_mtime;
/*
* If we can find the ascii names for gname and uname in the password
@@ -1266,6 +1271,13 @@ rd_xheader(ARCHD *arcn, int global, off_
if (!strcmp(keyword, "path")) {
arcn->nlen = strlcpy(arcn->name, p,
sizeof(arcn->name));
+ } else if (!strcmp(keyword, "mtime")) {
+ /* XXX error handling, and should parse
nanoseconds */
+ arcn->sb.st_mtime = strtoull(p, NULL, 10);
+ } else if (!strcmp(keyword, "atime")) {
+ arcn->sb.st_atime = strtoull(p, NULL, 10);
+ } else if (!strcmp(keyword, "ctime")) {
+ arcn->sb.st_ctime = strtoull(p, NULL, 10);
} else if (!strcmp(keyword, "linkpath")) {
arcn->ln_nlen = strlcpy(arcn->ln_name, p,
sizeof(arcn->ln_name));
Re: Increase of kern.seminfo.semmns sysctl
On 2021/10/17 15:31, Mikhail wrote: > Hello, current git of postgresql requires more semaphores than OpenBSD > currently suggests as a default, I propose to rise the limit to 100. > FreeBSD has 340, as a comparison. > > Another solution may be to add the note to README of postgresql's port > to rise the limit for the future version, but it looks inconvenient. It is there already. Perhaps we could lower the suggested value a bit though: $ cvs blame README-server | grep semmns Annotations for README-server *** 1.13 (sthen22-Nov-12): kern.seminfo.semmns=1024 > Comments, OKs? > > diff --git sys/sys/sem.h sys/sys/sem.h > index 184482d7810..03edc2e1d9e 100644 > --- sys/sys/sem.h > +++ sys/sys/sem.h > @@ -153,7 +153,7 @@ extern struct seminfo seminfo; > #define SEMMNI 10 /* # of semaphore identifiers */ > #endif > #ifndef SEMMNS > -#define SEMMNS 60 /* # of semaphores in system */ > +#define SEMMNS 100 /* # of semaphores in system */ > #endif > #ifndef SEMUME > #define SEMUME 10 /* max # of undo entries per process */ >
Re: snmpd: s/SNMP_C_GETRESP/SNMP_C_RESPONSE
On 2021/10/21 15:08, Martijn van Duren wrote:
> This one has been bothering me for a while.
>
> OK?
>
> martijn@
>
> Index: smi.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/smi.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 smi.c
> --- smi.c 4 Jan 2021 07:59:54 - 1.28
> +++ smi.c 21 Oct 2021 14:06:40 -
> @@ -377,7 +377,7 @@ smi_debug_elements(struct ber_element *r
> case SNMP_C_GETNEXTREQ:
> fprintf(stderr, "nextreq");
> break;
> - case SNMP_C_GETRESP:
> + case SNMP_C_RESPONSE:
> fprintf(stderr, "getresp");
ok.
maybe s/getresp/response in the fprintf above too?
> break;
> case SNMP_C_SETREQ:
> Index: snmp.h
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmp.h,v
> retrieving revision 1.17
> diff -u -p -r1.17 snmp.h
> --- snmp.h20 May 2021 08:53:12 - 1.17
> +++ snmp.h21 Oct 2021 14:06:40 -
> @@ -80,7 +80,7 @@ enum snmp_version {
> enum snmp_pdutype {
> SNMP_C_GETREQ = 0,
> SNMP_C_GETNEXTREQ = 1,
> - SNMP_C_GETRESP = 2,
> + SNMP_C_RESPONSE = 2,
> SNMP_C_SETREQ = 3,
> SNMP_C_TRAP = 4,
>
> Index: snmpe.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
> retrieving revision 1.77
> diff -u -p -r1.77 snmpe.c
> --- snmpe.c 21 Oct 2021 08:21:43 - 1.77
> +++ snmpe.c 21 Oct 2021 14:06:40 -
> @@ -207,7 +207,7 @@ snmpe_pdutype2string(enum snmp_pdutype p
> return "GetRequest";
> case SNMP_C_GETNEXTREQ:
> return "GetNextRequest";
> - case SNMP_C_GETRESP:
> + case SNMP_C_RESPONSE:
> return "Response";
> case SNMP_C_SETREQ:
> return "SetRequest";
> @@ -373,7 +373,7 @@ badversion:
> }
> break;
>
> - case SNMP_C_GETRESP:
> + case SNMP_C_RESPONSE:
> stats->snmp_ingetresponses++;
> msg->sm_errstr = "response without request";
> goto parsefail;
> @@ -812,7 +812,7 @@ snmpe_dispatchmsg(struct snmp_message *m
> (void) snmpe_parsevarbinds(msg);
>
> /* respond directly */
> - msg->sm_pdutype = SNMP_C_GETRESP;
> + msg->sm_pdutype = SNMP_C_RESPONSE;
> snmpe_response(msg);
> }
>
>
>
new option for rcctl ls
Sometimes I find it useful to list daemons which are set to 'disabled'
but are actually running. Either those where I have started them by hand
forgotten to enable in rc.conf.local, or to check for services which
shouldn't be running but which are anyway. Any comments on this diff
to add it to rcctl? It's pretty much the opposite of "rcctl ls failed".
Index: rcctl.8
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
retrieving revision 1.37
diff -u -p -r1.37 rcctl.8
--- rcctl.8 26 Jun 2021 18:02:48 - 1.37
+++ rcctl.8 21 Oct 2021 15:42:13 -
@@ -36,7 +36,7 @@
.Nm rcctl
.Cm ls
.Sm off
-.Cm all | failed | on | off | started | stopped
+.Cm all | failed | on | off | started | stopped | off-but-started
.Sm on
.Sh DESCRIPTION
The
@@ -119,6 +119,8 @@ which can be one of:
all services and daemons
.It Cm failed
enabled but stopped daemons
+.It Cm off-but-started
+services and daemons which are disabled but currently running
.It Cm off
disabled services and daemons
.It Cm on
Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.110
diff -u -p -r1.110 rcctl.sh
--- rcctl.sh27 Feb 2021 09:28:04 - 1.110
+++ rcctl.sh21 Oct 2021 15:42:13 -
@@ -35,7 +35,7 @@ usage()
"usage: rcctl get|getdef|set service | daemon [variable [arguments]]
rcctl [-df] ${_a} daemon ...
rcctl disable|enable|order [daemon ...]
- rcctl ls all|failed|off|on|started|stopped"
+ rcctl ls all|failed|off|on|started|stopped|off-but-started"
}
needs_root()
@@ -212,6 +212,13 @@ svc_ls()
echo ${_special_svcs} | tr "[:blank:]" "\n"
) | sort
;;
+ off-but-started)
+ for _svc in $(svc_ls off); do
+ ! svc_is_special ${_svc} && \
+ /etc/rc.d/${_svc} check >/dev/null && \
+ echo ${_svc} && _ret=1
+ done
+ ;;
failed)
for _svc in $(svc_ls on); do
! svc_is_special ${_svc} && \
@@ -502,7 +509,7 @@ ret=0
case ${action} in
ls)
lsarg=$2
- [[ ${lsarg} == @(all|failed|off|on|started|stopped) ]] || usage
+ [[ ${lsarg} ==
@(all|failed|off|on|started|stopped|off-but-started) ]] || usage
;;
order)
shift 1
Re: retire hifn safe ubsec
On 2021/10/21 16:30, Alexander Bluhm wrote: > Hi, > > Goal is to retire the async crypto API. It is slow and adds > complexity which hinders MP progress in IPsec. It is used by the > old PCI devices hifn(4), safe(4), and ubsec(4). > > These devices are not common anymore. Using the CPU for crypto is > faster than offloading via the PCI bus. By having special requirements > for the crypto API, those devices slow down modern machines. They > only support crypto algorithms that are insecure nowadays. > > ok to remove hifn(4) safe(4) ubsec(4) ? OK. The main useful feature as far as I'm concerned is the rng but I don't think it's useful/common enough to be worth doing anything other than just deleting the drivers.
Re: retire hifn safe ubsec
On 2021/10/21 10:02, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2021/10/21 16:30, Alexander Bluhm wrote: > > > Hi, > > > > > > Goal is to retire the async crypto API. It is slow and adds > > > complexity which hinders MP progress in IPsec. It is used by the > > > old PCI devices hifn(4), safe(4), and ubsec(4). > > > > > > These devices are not common anymore. Using the CPU for crypto is > > > faster than offloading via the PCI bus. By having special requirements > > > for the crypto API, those devices slow down modern machines. They > > > only support crypto algorithms that are insecure nowadays. > > > > > > ok to remove hifn(4) safe(4) ubsec(4) ? > > > > OK. The main useful feature as far as I'm concerned is the rng but > > I don't think it's useful/common enough to be worth doing anything other > > than just deleting the drivers. > > Perhaps that function can be left intact in a few drivers. I think it's not really worthwhile. From memory and a bit of a trawl in dmesglog the main use of these with OpenBSD has been is hifn on Soekris net45xx/48xx. (There might have been some on PCEngines WRAP but those were minipci only and the minipci hifn was much less common). > But honestly I think the software rng stack we have now does sufficient > amounts of churn, and I cannot see runtime operations which exhaust it. > Send or receive packets? You are generating interrupts at unpredictable > interrupt time deltas, those get folded in. This isn't a basic fold like > in other systems, it is powerful & sophisticated and I see no way it can > fall behind. Exactly. I'm definitely OK with them going, just wanted to consider possible use cases first.
Re: ixl(4): add checksum receive offloading
On 2021/10/22 11:25, Jan Klemkow wrote: > this diff add hardware checksum offloading for the receive path of > ixl(4) interfaces. Would be good to have this tested with NFS if anyone has a way to do so. nics are probably better now but I'm pretty sure we have had problems with NFS and offloading in the past. (there's a chance I might be able to test if my c27xx atom box still lives but you might be able to do it more easily)
Re: new option for rcctl ls
On 2021/10/22 12:20, Antoine Jacoutot wrote:
> On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
> > Sometimes I find it useful to list daemons which are set to 'disabled'
> > but are actually running. Either those where I have started them by hand
> > forgotten to enable in rc.conf.local, or to check for services which
> > shouldn't be running but which are anyway. Any comments on this diff
> > to add it to rcctl? It's pretty much the opposite of "rcctl ls failed".
>
> Hi.
>
> I have never had a use for this, so I don't really have an opinion...
> I am not super fan of the "off-but-started" option name though.
I hate the name but every other idea I had was worse :)
>
> >
> > Index: rcctl.8
> > ===
> > RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
> > retrieving revision 1.37
> > diff -u -p -r1.37 rcctl.8
> > --- rcctl.8 26 Jun 2021 18:02:48 - 1.37
> > +++ rcctl.8 21 Oct 2021 15:42:13 -
> > @@ -36,7 +36,7 @@
> > .Nm rcctl
> > .Cm ls
> > .Sm off
> > -.Cm all | failed | on | off | started | stopped
> > +.Cm all | failed | on | off | started | stopped | off-but-started
> > .Sm on
> > .Sh DESCRIPTION
> > The
> > @@ -119,6 +119,8 @@ which can be one of:
> > all services and daemons
> > .It Cm failed
> > enabled but stopped daemons
> > +.It Cm off-but-started
> > +services and daemons which are disabled but currently running
> > .It Cm off
> > disabled services and daemons
> > .It Cm on
> > Index: rcctl.sh
> > ===
> > RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> > retrieving revision 1.110
> > diff -u -p -r1.110 rcctl.sh
> > --- rcctl.sh27 Feb 2021 09:28:04 - 1.110
> > +++ rcctl.sh21 Oct 2021 15:42:13 -
> > @@ -35,7 +35,7 @@ usage()
> > "usage: rcctl get|getdef|set service | daemon [variable [arguments]]
> > rcctl [-df] ${_a} daemon ...
> > rcctl disable|enable|order [daemon ...]
> > - rcctl ls all|failed|off|on|started|stopped"
> > + rcctl ls all|failed|off|on|started|stopped|off-but-started"
> > }
> >
> > needs_root()
> > @@ -212,6 +212,13 @@ svc_ls()
> > echo ${_special_svcs} | tr "[:blank:]" "\n"
> > ) | sort
> > ;;
> > + off-but-started)
> > + for _svc in $(svc_ls off); do
> > + ! svc_is_special ${_svc} && \
> > + /etc/rc.d/${_svc} check >/dev/null && \
> > + echo ${_svc} && _ret=1
> > + done
> > + ;;
> > failed)
> > for _svc in $(svc_ls on); do
> > ! svc_is_special ${_svc} && \
> > @@ -502,7 +509,7 @@ ret=0
> > case ${action} in
> > ls)
> > lsarg=$2
> > - [[ ${lsarg} == @(all|failed|off|on|started|stopped) ]] || usage
> > + [[ ${lsarg} ==
> > @(all|failed|off|on|started|stopped|off-but-started) ]] || usage
> > ;;
> > order)
> > shift 1
> >
>
> --
> Antoine
>
Re: new option for rcctl ls
On 2021/10/22 12:56, Stuart Henderson wrote:
> On 2021/10/22 12:20, Antoine Jacoutot wrote:
> > On Thu, Oct 21, 2021 at 04:45:47PM +0100, Stuart Henderson wrote:
> > > Sometimes I find it useful to list daemons which are set to 'disabled'
> > > but are actually running. Either those where I have started them by hand
> > > forgotten to enable in rc.conf.local, or to check for services which
> > > shouldn't be running but which are anyway. Any comments on this diff
> > > to add it to rcctl? It's pretty much the opposite of "rcctl ls failed".
> >
> > Hi.
> >
> > I have never had a use for this, so I don't really have an opinion...
> > I am not super fan of the "off-but-started" option name though.
>
> I hate the name but every other idea I had was worse :)
Ingo had a nice suggestion:
Index: rcctl.8
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
retrieving revision 1.37
diff -u -p -r1.37 rcctl.8
--- rcctl.8 26 Jun 2021 18:02:48 - 1.37
+++ rcctl.8 22 Oct 2021 18:26:40 -
@@ -36,7 +36,7 @@
.Nm rcctl
.Cm ls
.Sm off
-.Cm all | failed | on | off | started | stopped
+.Cm all | failed | on | off | rogue | started | stopped
.Sm on
.Sh DESCRIPTION
The
@@ -123,6 +123,8 @@ enabled but stopped daemons
disabled services and daemons
.It Cm on
enabled services and daemons
+.It Cm rogue
+services and daemons which are disabled but currently running
.It Cm started
running daemons
.It Cm stopped
Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.110
diff -u -p -r1.110 rcctl.sh
--- rcctl.sh27 Feb 2021 09:28:04 - 1.110
+++ rcctl.sh22 Oct 2021 18:26:40 -
@@ -35,7 +35,7 @@ usage()
"usage: rcctl get|getdef|set service | daemon [variable [arguments]]
rcctl [-df] ${_a} daemon ...
rcctl disable|enable|order [daemon ...]
- rcctl ls all|failed|off|on|started|stopped"
+ rcctl ls all|failed|off|on|rogue|started|stopped"
}
needs_root()
@@ -228,6 +228,13 @@ svc_ls()
unset _on
done
;;
+ rogue)
+ for _svc in $(svc_ls off); do
+ ! svc_is_special ${_svc} && \
+ /etc/rc.d/${_svc} check >/dev/null && \
+ echo ${_svc} && _ret=1
+ done
+ ;;
started|stopped)
for _svc in $(ls_rcscripts); do
/etc/rc.d/${_svc} check >/dev/null && _started=1
@@ -502,7 +509,7 @@ ret=0
case ${action} in
ls)
lsarg=$2
- [[ ${lsarg} == @(all|failed|off|on|started|stopped) ]] || usage
+ [[ ${lsarg} == @(all|failed|off|on|rogue|started|stopped) ]] ||
usage
;;
order)
shift 1
Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall
On 2021/10/24 13:10, Mikhail wrote:
> Hello, current maximum size of /usr/src in large disk autoinstall
> configuration is set to 2G, which in insufficient for 'git clone', where
> the repo already exceeded this size, I suggest to change it to 3G, since
> most users have disks large enough to handle it.
> - { MEG(1300), GIG(2), 2, "/usr/src"},
> + { MEG(1300), GIG(3), 2, "/usr/src"},
The minimum needs to go up too, a cvs checkout is 1.3G already.
(Not that I use auto defaults without changes anyway, they don't
work too well for ports dev..)
Re: installer/wifi drivers: use join by default
On 2021/10/24 11:20, Klemens Nanni wrote: > @@ -174,7 +174,7 @@ The following > example creates a host-based access point on boot: > .Bd -literal -offset indent > mediaopt hostap > -nwid mynwid nwkey mywepkey > +join mynwid nwkey mywepkey > inet 192.168.1.1 255.255.255.0 that's not right for hostap
Re: installer/wifi drivers: use join by default
On 2021/10/24 11:57, Klemens Nanni wrote: > On Sun, Oct 24, 2021 at 12:41:11PM +0100, Stuart Henderson wrote: > > On 2021/10/24 11:20, Klemens Nanni wrote: > > > @@ -174,7 +174,7 @@ The following > > > example creates a host-based access point on boot: > > > .Bd -literal -offset indent > > > mediaopt hostap > > > -nwid mynwid nwkey mywepkey > > > +join mynwid nwkey mywepkey > > > inet 192.168.1.1 255.255.255.0 > > > > that's not right for hostap > > Thanks for eagle-eying this! > > OK? yes. (I don't use join everywhere, but it seems like a pretty good thing to use by default). > --- share/man/man4/an.4 15 Oct 2021 08:10:44 - 1.45 > +++ share/man/man4/an.4 24 Oct 2021 10:17:23 - > @@ -134,7 +134,7 @@ using WEP key > .Dq mywepkey , > obtaining an IP address using DHCP: > .Bd -literal -offset indent > -nwid mynwid nwkey mywepkey > +join mynwid nwkey mywepkey > inet autoconf > .Ed > .Sh DIAGNOSTICS wondering if it really makes sense to include these examples sections in wlan drivers any more, but that's orthogonal to this diff.
snmpd trap community problem
trondd noticed a startup problem with snmpd on mips64 but didn't see
them on amd64 and wondered if it was arch-specific, I had a go at
reproducing and see it very often on aarch64 and also sometimes on
amd64.
Any setting of "trap receiver $ip snmpv2c community $community"
triggers the problem:
# for i in `jot 20`; do snmpd -nvf /etc/snmpd.conf; done
trap receiver: missing community
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
trap receiver: missing community
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
configuration ok
trap receiver: missing community
Additionally even when configuration is accepted, the community is set
to junk
822 tr->ta_oid = $2;
823 tr->ta_version = $3.type;
with snmpv2c ta_version is set to 1
824 if ($3.type == ADDRESS_FLAG_SNMPV2) {
so this branch isn't taken
825 (void)strlcpy(tr->ta_community, $3.data,
826 sizeof(tr->ta_community));
827 free($3.data);
828 } else {
829 tr->ta_usmusername = $3.data;
830 tr->ta_seclevel = $3.value;
831 }
at this point ta_usmusername is set to the community and ta_community
is junk.
810 if ($4 != NULL) {
(gdb)
823 tr->ta_version = $3.type;
(gdb)
824 if ($3.type == ADDRESS_FLAG_SNMPV2) {
(gdb) p *tr
$3 = {ta_ss = {ss_len = 16 '\020', ss_family = 2 '\002', __ss_pad1 =
"\000\242\303_\273T", __ss_pad2 = 0,
__ss_pad3 = "\002\000\000\000\001\000\000\000\001\000\000\000\a", '\000'
}, ta_sslocal = {
ss_len = 0 '\000', ss_family = 0 '\000', __ss_pad1 =
"\000\000\000\000\000", __ss_pad2 = 0,
__ss_pad3 = '\000' }, ta_version = 1, {ta_community =
'\000' , {
ta_usmusername = 0x0, ta_usmuser = 0x0, ta_seclevel = 0}}, ta_oid = 0x0,
entry = {tqe_next = 0x0,
tqe_prev = 0x0}}
(gdb) n
829 tr->ta_usmusername = $3.data;
(gdb)
830 tr->ta_seclevel = $3.value;
(gdb)
832 TAILQ_INSERT_TAIL(&(conf->sc_trapreceivers),
tr, entry);
(gdb) p *tr
$4 = {ta_ss = {ss_len = 16 '\020', ss_family = 2 '\002', __ss_pad1 =
"\000\242\303_\273T", __ss_pad2 = 0,
__ss_pad3 = "\002\000\000\000\001\000\000\000\001\000\000\000\a", '\000'
}, ta_sslocal = {
ss_len = 0 '\000', ss_family = 0 '\000', __ss_pad1 =
"\000\000\000\000\000", __ss_pad2 = 0,
__ss_pad3 = '\000' }, ta_version = 1, {
ta_community = "\340\035a\250O\005", '\000' , {
ta_usmusername = 0x54fa8611de0 "zz", ta_usmuser = 0x0,
ta_seclevel = 0}}, ta_oid = 0x0,
entry = {tqe_next = 0x0, tqe_prev = 0x0}}
Re: snmpd trap community problem
ooops, sorry not trondd, it was jhuldtgren who spotted it!
On 2021/10/24 22:26, Stuart Henderson wrote:
> trondd noticed a startup problem with snmpd on mips64 but didn't see
> them on amd64 and wondered if it was arch-specific, I had a go at
> reproducing and see it very often on aarch64 and also sometimes on
> amd64.
>
> Any setting of "trap receiver $ip snmpv2c community $community"
> triggers the problem:
>
> # for i in `jot 20`; do snmpd -nvf /etc/snmpd.conf; done
> trap receiver: missing community
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> trap receiver: missing community
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> configuration ok
> trap receiver: missing community
>
> Additionally even when configuration is accepted, the community is set
> to junk
>
> 822 tr->ta_oid = $2;
> 823 tr->ta_version = $3.type;
>
> with snmpv2c ta_version is set to 1
>
> 824 if ($3.type == ADDRESS_FLAG_SNMPV2) {
>
> so this branch isn't taken
>
> 825 (void)strlcpy(tr->ta_community, $3.data,
> 826 sizeof(tr->ta_community));
> 827 free($3.data);
> 828 } else {
> 829 tr->ta_usmusername = $3.data;
> 830 tr->ta_seclevel = $3.value;
> 831 }
>
> at this point ta_usmusername is set to the community and ta_community
> is junk.
>
> 810 if ($4 != NULL) {
> (gdb)
> 823 tr->ta_version = $3.type;
> (gdb)
> 824 if ($3.type == ADDRESS_FLAG_SNMPV2) {
> (gdb) p *tr
> $3 = {ta_ss = {ss_len = 16 '\020', ss_family = 2 '\002', __ss_pad1 =
> "\000\242\303_\273T", __ss_pad2 = 0,
> __ss_pad3 = "\002\000\000\000\001\000\000\000\001\000\000\000\a", '\000'
> }, ta_sslocal = {
> ss_len = 0 '\000', ss_family = 0 '\000', __ss_pad1 =
> "\000\000\000\000\000", __ss_pad2 = 0,
> __ss_pad3 = '\000' }, ta_version = 1, {ta_community =
> '\000' , {
> ta_usmusername = 0x0, ta_usmuser = 0x0, ta_seclevel = 0}}, ta_oid =
> 0x0, entry = {tqe_next = 0x0,
> tqe_prev = 0x0}}
> (gdb) n
> 829 tr->ta_usmusername = $3.data;
> (gdb)
> 830 tr->ta_seclevel = $3.value;
> (gdb)
> 832 TAILQ_INSERT_TAIL(&(conf->sc_trapreceivers),
> tr, entry);
> (gdb) p *tr
> $4 = {ta_ss = {ss_len = 16 '\020', ss_family = 2 '\002', __ss_pad1 =
> "\000\242\303_\273T", __ss_pad2 = 0,
> __ss_pad3 = "\002\000\000\000\001\000\000\000\001\000\000\000\a", '\000'
> }, ta_sslocal = {
> ss_len = 0 '\000', ss_family = 0 '\000', __ss_pad1 =
> "\000\000\000\000\000", __ss_pad2 = 0,
> __ss_pad3 = '\000' }, ta_version = 1, {
> ta_community = "\340\035a\250O\005", '\000' , {
> ta_usmusername = 0x54fa8611de0 "zz", ta_usmuser = 0x0,
> ta_seclevel = 0}}, ta_oid = 0x0,
> entry = {tqe_next = 0x0, tqe_prev = 0x0}}
>
>
>
Re: snmpd trap community problem
On 2021/10/25 10:09, Martijn van Duren wrote: > Thanks for the detailed analysis. > > diff below should fix it. thanks, OK. I'm sure I tried that but maybe I missed the _ (SNMPV2 vs SNMP_V2).
Re: demystify vport(4) in vport(4) and ifconfig(8)
On 2021/10/27 17:44, David Gwynne wrote: > > > benno@ suggested I look at vether(4) to adapt the text related to > > bridge(4) but I'm not sure how to rewrite it properly for veb(4). > > i get that, but for a different reason. im too close to veb/vport, so i > think it's all very obvious. > > maybe we could split the first paragraph into separate ones for veb > and vport, and flesh them out a bit. what is it about vport that > needs to be said? I'm not so close to veb/vport (and haven't run into a situation to use it yet, though maybe I'll give it a try converting an etherip/ipsec bridge that I have). I think it's pretty obvious too, though I think people aren't grasping what "the network stack can be connected" means, would the diff below help? it feels a bit more like spelling things out than is usual for a manual page but maybe that's needed here. for ifconfig I would be in favour of _not_ listing all the possible cloneable interface types that can be used with create, it's just another thing to get out of sync - maybe just a few of the common ones and tell the reader about ifconfig -C at that point.. "ifconfig create" barely seems necessary except possibly for tun/tap - for most interface types you are going to run another ifconfig command (like "ifconfig veb0 add em0") which creates the interface automatically anyway. Index: veb.4 === RCS file: /cvs/src/share/man/man4/veb.4,v retrieving revision 1.2 diff -u -p -r1.2 veb.4 --- veb.4 23 Feb 2021 11:43:41 - 1.2 +++ veb.4 27 Oct 2021 09:03:49 - @@ -28,20 +28,30 @@ The .Nm veb pseudo-device supports the creation of a single layer 2 Ethernet network between multiple ports. -Ethernet interfaces are added to the bridge to be used as ports. +Ethernet interfaces are added to the .Nm veb -takes over the operation of the interfaces that are added as ports -and uses them independently of the host network stack. -The network stack can be connected to the Ethernet network managed -by +bridge to be used as ports. +Unlike +.Xr bridge 4 , .Nm veb -by creating a +takes over the operation of the interfaces that are added as ports. +They are then independent of the host network stack; the individual +Ethernet ports no longer function as independent layer 3 devices +and cannot be configured with +.Xr inet 4 +or +.Xr inet6 4 +addresses themselves. +.Pp +The Ethernet network managed by +.Nm veb +can be connected to the network stack as a whole by creating a .Nm vport interface and attaching it as a port to the bridge. From the perspective of the host network stack, a .Nm vport interface acts as a normal interface connected to an Ethernet -network. +network and can be configured with addresses. .Pp .Nm veb is a learning bridge that maintains a table of Ethernet addresses
Re: snmpd(8): don't allocate memory for system mib
On 2021/10/27 17:14, Martijn van Duren wrote:
> Trying to search for memory leaks in my new snmpd code I found some
> harmless, but annoying ones in system from SNMPv2-MIB.
>
> We call uname(3) every time (even if we don't even need info from
> that call) and ones set we save it until forever.
>
> Diff below calls uname(3) only a single time and if the variables
> aren't snmpd.conf I simply rebuild it every time.
I'm in two minds about this. While it's not something that will happen
very often, hostnames do get changed sometimes, and it would be nice to
have snmpd reflect the current name of the system rather than what it
was named when snmpd started.
> I also changed the default "system contact" to an empty string,
> since SNMPv2-MIB states:
> "If no contact information is known, the value is the zero-length
> string."
> I've basically never came across a system where there was both
> a smtp process accepting remote mail for the root-account and
> where the hostname were correctly resolving. If people are really
> attached to this value it's easy enough to set it, but I think
> it would be better to not tell unfounded assertions.
I'm certainly OK with that part.
> OK?
>
> martijn@
>
> Index: mib.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
> retrieving revision 1.102
> diff -u -p -r1.102 mib.c
> --- mib.c 1 Sep 2021 15:54:40 - 1.102
> +++ mib.c 27 Oct 2021 16:14:15 -
> @@ -126,22 +126,25 @@ mib_getsys(struct oid *oid, struct ber_o
> {
> struct ber_oid sysoid = OID(MIB_SYSOID_DEFAULT);
> char*s = oid->o_data;
> + char buf[256];
> struct ber_oid *so = oid->o_data;
> - struct utsname u;
> + static struct utsnameu;
> + int init = 0;
> long longticks;
>
> - if (uname(&u) == -1)
> - return (-1);
> + if (!init) {
> + if (uname(&u) == -1)
> + return (-1);
> + init = 1;
> + }
>
> switch (oid->o_oid[OIDIDX_system]) {
> case 1:
> if (s == NULL) {
> - if (asprintf(&s, "%s %s %s %s %s",
> + snprintf(buf, sizeof(buf), "%s %s %s %s %s",
> u.sysname, u.nodename, u.release,
> - u.version, u.machine) == -1)
> - return (-1);
> - oid->o_data = s;
> - oid->o_val = strlen(s);
> + u.version, u.machine);
> + s = buf;
> }
> *elm = ober_add_string(*elm, s);
> break;
> @@ -157,21 +160,13 @@ mib_getsys(struct oid *oid, struct ber_o
> ober_set_header(*elm, BER_CLASS_APPLICATION, SNMP_T_TIMETICKS);
> break;
> case 4:
> - if (s == NULL) {
> - if (asprintf(&s, "root@%s", u.nodename) == -1)
> - return (-1);
> - oid->o_data = s;
> - oid->o_val = strlen(s);
> - }
> + if (s == NULL)
> + s = "";
> *elm = ober_add_string(*elm, s);
> break;
> case 5:
> - if (s == NULL) {
> - if ((s = strdup(u.nodename)) == NULL)
> - return (-1);
> - oid->o_data = s;
> - oid->o_val = strlen(s);
> - }
> + if (s == NULL)
> + s = u.nodename;
> *elm = ober_add_string(*elm, s);
> break;
> case 6:
> Index: snmpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
> retrieving revision 1.58
> diff -u -p -r1.58 snmpd.conf.5
> --- snmpd.conf.5 2 Sep 2021 05:41:02 - 1.58
> +++ snmpd.conf.5 27 Oct 2021 16:14:15 -
> @@ -244,9 +244,6 @@ This is the default value.
> .It Ic system contact Ar string
> Specify the name or description of the system contact, typically a
> name or an email address.
> -The default value is
> -.Ar root@hostname
> -using the hostname of the local machine.
> .It Ic system description Ar string
> Specify a description of the local system.
> The default value is the operating system identification as printed by the
>
>
Re: demystify vport(4) in vport(4) and ifconfig(8)
On 2021/10/28 13:11, David Gwynne wrote: > On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote: > > On 2021/10/27 17:44, David Gwynne wrote: > > > > > > > benno@ suggested I look at vether(4) to adapt the text related to > > > > bridge(4) but I'm not sure how to rewrite it properly for veb(4). > > > > > > i get that, but for a different reason. im too close to veb/vport, so i > > > think it's all very obvious. > > > > > > maybe we could split the first paragraph into separate ones for veb > > > and vport, and flesh them out a bit. what is it about vport that > > > needs to be said? > > > > I'm not so close to veb/vport (and haven't run into a situation to use > > it yet, though maybe I'll give it a try converting an etherip/ipsec > > bridge that I have). I think it's pretty obvious too, though I think > > people aren't grasping what "the network stack can be connected" means, > > would the diff below help? it feels a bit more like spelling things out > > than is usual for a manual page but maybe that's needed here. > > I think it is needed here. My only issue is that the layer 3 stack is > more than just IP, it also includes mpls and pppoe and bpe(4). Listing > all that is heading into "list all the things" territory again though. I'll commit it with this tweaked a bit +They are then independent of the host network stack: the individual +Ethernet ports no longer function as independent devices and cannot +be configured with +.Xr inet 4 +or +.Xr inet6 4 +addresses or other layer-3 features themselves. happy to tweak further, but I think it's an improvement already > > for ifconfig I would be in favour of _not_ listing all the possible > > cloneable interface types that can be used with create, it's just another > > thing to get out of sync - maybe just a few of the common ones and tell > > the reader about ifconfig -C at that point.. "ifconfig create" barely > > seems necessary except possibly for tun/tap - for most interface types > > you are going to run another ifconfig command (like "ifconfig veb0 add > > em0") which creates the interface automatically anyway. > > Having clonable interfaces be implicitly created is something that > annoys me. If I ifconfig bridge0 add gre0, it should actually fail > without side effects such as bringing an unwanted child^Winterface > into the world. This and other implicit behaviours like bringing > an interface up when an address on it is configured are also painful > from a locking point of view, even after trying to figure out what's > reasonable to clean up when a later step fails. > > I seem to lose this argument every time though. The "auto up when configuring an address" is very convenient but it can result in actual problems too (pppoe needs to know which protocols to negotiate so it's racy) as well as making locking painful
Re: demystify vport(4) in vport(4) and ifconfig(8)
On 2021/10/28 23:19, Klemens Nanni wrote: > On Fri, Oct 29, 2021 at 12:57:54AM +0200, Ingo Schwarze wrote: > > MANPAGER=firefox man -T html $(ifconfig -C) > > This doesn't work if firefox is already running as the MANPAGER firefox > process exits immediately after sending the file/link to the running > process, which causes mandoc to exit after removing the temporary file, > by which time firefox fails to open the no longer exiting file. > I use mutt_bgrun for things like this
Re: demystify vport(4) in vport(4) and ifconfig(8)
On 2021/10/29 14:08, Ingo Schwarze wrote: > Hi Stuart, > > Stuart Henderson wrote on Fri, Oct 29, 2021 at 10:53:41AM +0100: > > On 2021/10/28 23:19, Klemens Nanni wrote: > >> On Fri, Oct 29, 2021 at 12:57:54AM +0200, Ingo Schwarze wrote: > > >>> MANPAGER=firefox man -T html $(ifconfig -C) > > >> This doesn't work if firefox is already running as the MANPAGER firefox > >> process exits immediately after sending the file/link to the running > >> process, which causes mandoc to exit after removing the temporary file, > >> by which time firefox fails to open the no longer exiting file. > >> > > > I use mutt_bgrun for things like this > > I don't see how that can possibly help. Oh, of course you're right - I was confused between my helper scripts. The one I actually use for html in mutt looks like this, so it's not any user for MANPAGER.. tmp=`mktemp -d /tmp/mutthtml.X` || exit 1 mhonarc -rcfile ~/.m2h_rcfile -single > $tmp/mail.html (chrome $tmp/mail.html 2>/dev/null; sleep 30; rm -r $tmp) &
Re: uniq(1): support arbitrarily long lines
On 2021/10/31 20:48, Scott Cheloha wrote: > In uniq(1), if we use getline(3) instead of fgets(3) we can support > arbitrarily long lines. It works for me, and getting rid of the length restriction is nice. I don't know how much of a concern it is, but it's about twice as slow: $ wc -l /tmp/z 1000 /tmp/z $ time (cat /tmp/z | uniq > /dev/null) 0m01.65s real 0m01.62s user 0m00.22s system $ time (cat /tmp/z | obj/uniq > /dev/null) 0m03.60s real 0m03.52s user 0m00.20s system $ time (cat /tmp/z | guniq > /dev/null) 0m01.33s real 0m01.28s user 0m00.20s system though in practice with large files I'd be more likely to sort | uniq -c and uniq's time is dwarfed by sort's.
