HDMI from Lenovo X1 Extreme Laptop
Hi there, I have a Lenovo X1 Extreme Laptop (Gen4), the hardware probe looks like this: https://bsd-hardware.info/?probe=d19db2828c , and the Lenovo specs: https://psref.lenovo.com/Detail/ThinkPad_X1_Extreme_Gen_4?M=20Y5001DMX It has two graphics cards: 1. Embedded - Intel UHD (Tiger Lake) 2. Discrete - Nvidia GeForce RTX 3050 Ti Mobile 4GB I am trying to connect an external screen via the HDMI port, but with no luck so far. The output of xrandr shows: eDP-1 connected primary 3840x2400+0+0 (normal left inverted right x axis y axis) 344mm 215mm ... HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) DP-3 disconnected (normal left inverted right x axis y axis) DP-4 disconnected (normal left inverted right x axis y axis) I have connected my Dell screen via a HDMI cable, but I am unable to get a picture, and the output from xrandr remains the same. I tried running also: xrandr --output HDMI-1 --auto --output eDP-1 --auto That made no difference either... I guess because it shows HDMI-1 as disconnected? I realise that Nvidia cards are not supported in OpenBSD, and I have read that some laptops only have the HDMI port connected to the Discrete graphics card (Nvidia), whilst some have it connected to both graphics cards. How can I determine under OpenBSD if the HDMI port is connected to one or both graphics cards please? Additionally, if it turns out it is only connected to the Nvidia card. What are my other options for powering an external display? I am often travelling so need a small cable based (i.e. not a Dock) solution. The laptop claims to export DisplayPort 1.4 over Thunderbolt 4 as well. Would such an adapter from Thunderbolt 4 to HDMI be supported by OpenBSD - https://www.sonnettech.com/product/thunderbolt-dual-hdmi-adapter/overview.html ? Thanks Adam. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
Re: Installing OpenBSD amd64 on UTM on Intel Mac?
Here is my blog post on how I got this working - https://blog.adamretter.org.uk/running-openbsd-74-under-utm/ On Sat, 13 Jan 2024 at 19:55, Adam Retter wrote: > > I've had some success with this on Intel Mac, although it requires some > workarounds. I'm in the process of writing a blog, I'll post it here in the > next few days if I can... > > On Fri, 12 Jan 2024, 22:32 Implausibility, wrote: >> >> Hi. >> >> Since there's some uncertainty around the future of VMware Fusion on the >> Mac, I've decided to switch to UTM (with QEMU under the covers) -- but I >> can't seem to get OpenBSD .isos (7.3 or 7.4) to boot -- instead, I get >> dumped into the UEFI shell, which is a dead end. >> >> I've done a number of searches (on the mailing list and the web in general), >> and all of the results are for running the ARM64 port on the M-series Macs >> -- but my target machine has an Intel CPU. >> >> Can anyone provide some insight into running OpenBSD under UTM on a Mac? >> >> Thanks. >> -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
Re: How to access Xauthority for VNC Server
Hi Stuart, Sorry for the slow response. I have created the file /home/aretter/.xsession with the mode 755 and the owner and group 'aretter'. The file contains the single line: x0vncserver -display :0 -PasswordFile ~/.vnc/passwd I rebooted the system, logged in on the console as `aretter` and ran `ps -A` unfortunately there is no `x0vncserver` running. I grep'd for `x0nvserver` in the log files within /var/log and found nothing. Any ideas, how can I figure out why this isn't working? > This would run as your uid and with X environment variables intact so no > faffing with XAUTHORITY needed. Does this mean that I should see an XAUTHORITY environment variable after I login on the console? If so, I don't see anything like that reported by `env`. Kind regards. Adam. On Wed, 3 Jan 2024 at 00:34, Stuart Henderson wrote: > > On 2024-01-02, Adam Retter wrote: > > > > XAUTHORITY=/etc/X11/xenodm/authdir/authfiles/A:0-r4dlnM x0vncserver > > -display :0 -PasswordFile ~/.vnc/passwd > > > > It is not clear to me how I can set this up so that x0vncserver can > > access the correctly named auth file each time the machine restarts, > > and also under which account it would be considered best practice to > > run x0vncserver... Should I run it under my user account, the `_x11` > > account, or an account created just for that purpose? > > Ideally the VNC Server would start during system startup also. > > It won't help for system startup, but you can add the x0vncserver > command (backgrounded with &) from .xsession to run after login. > This would run as your uid and with X environment variables intact so > no faffing with XAUTHORITY needed. > > (I would recommend listening to localhost only and connecting via ssh > port-forwarding; for unix VNC clients "-via $hostname localhost" runs > the ssh command for you). > > > > -- > Please keep replies on the mailing list. > -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
Re: Installing OpenBSD amd64 on UTM on Intel Mac?
I've had some success with this on Intel Mac, although it requires some workarounds. I'm in the process of writing a blog, I'll post it here in the next few days if I can... On Fri, 12 Jan 2024, 22:32 Implausibility, wrote: > Hi. > > Since there's some uncertainty around the future of VMware Fusion on the > Mac, I've decided to switch to UTM (with QEMU under the covers) -- but I > can't seem to get OpenBSD .isos (7.3 or 7.4) to boot -- instead, I get > dumped into the UEFI shell, which is a dead end. > > I've done a number of searches (on the mailing list and the web in > general), and all of the results are for running the ARM64 port on the > M-series Macs -- but my target machine has an Intel CPU. > > Can anyone provide some insight into running OpenBSD under UTM on a Mac? > > Thanks. > >
How to access Xauthority for VNC Server
Apologies but I am a little bit unclear about how X authfiles should work in OpenBSD. I have started with a fresh OpenBSD 7.4 install, and I opted to install the X Window System. My goal is to be able to export my display over VNC as I have no access to the mouse and keyboard of the machine. I have installed the VNC Server software by running as root - pkg_add tigervnc To be able to run the VNC Server, it needs access to the X Authority file. I want to ideally run the VNC Server under a non-root account. I have found an authority file under /etc/X11/xenodm/authdir/authfiles/ however its name seems to be randomly decided each time xenodm is started during System boot. For example at present it is /etc/X11/xenodm/authdir/authfiles/A:0-r4dlnM but that will change if the system is rebooted. To run the VNC Server, I think I need to execute something like the following command: XAUTHORITY=/etc/X11/xenodm/authdir/authfiles/A:0-r4dlnM x0vncserver -display :0 -PasswordFile ~/.vnc/passwd It is not clear to me how I can set this up so that x0vncserver can access the correctly named auth file each time the machine restarts, and also under which account it would be considered best practice to run x0vncserver... Should I run it under my user account, the `_x11` account, or an account created just for that purpose? Ideally the VNC Server would start during system startup also. I also note that the auth files such as /etc/X11/xenodm/authdir/authfiles/A:0-r4dlnM are owned by the `_x11` account and group, and are only readable by the owner (mode 0600). Please advise on the best way to set this up? Kind regards. Adam. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
[apologies in advance for top-posting]
bgpd(8) is excellent in many ways, and I am SO very grateful it exists. (Thank
you Henning, Claudio, Peter and everyone else who has contributed to it over
the years! It has straight-up saved my bacon a couple of times.)
But one feature it does not yet AFAIK have is Additional Paths
("additional-path", or just "add-path") [1]. This is where a BGP speaker
advertises not only its "best" routes, but *all* its routes, to its peers. The
FIB remains unchanged, but the RIB can grow very large in a well-connected AS.
Since each router now knows all the available paths through every other router,
convergence is - at least in theory - sped up quite dramatically, and you
mostly avoid the "hole" described. It's not a perfect solution but it works
very well.
If you're brave enough, at least some versions/forks of Bird/Quagga/Zebra have
support for add-path. I wouldn't recommend running these on OpenBSD, generally
speaking - bgpd(8) is more appropriate 99.999% of the time - but you might find
it worthwhile, depending on your needs. Be particularly careful of any routing
software that lacks the ability to affect kernel routes - unless you're just
running a route reflector, that will change your design *significantly*.
Or, as Stuart said, running a "proper" IGP like OSPF could bridge some of the
gaps you might see. YMMV.
-Adam
P.S. From what I heard a few years ago, OpenBSD isn't completely ignoring
add-path, it's just
complex/difficult/time-consuming/unfunded/low-priority/pick-your-favourite-reason.
[1] https://datatracker.ietf.org/doc/html/rfc7911
-Original Message-
From: owner-m...@openbsd.org On Behalf Of Sebastian
Benoit
Sent: Monday, November 29, 2021 3:38 PM
To: misc@openbsd.org
Subject: Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
Stuart Henderson(s...@spacehopper.org) on 2021.11.13 00:11:08 +:
> I have a pair of -current routers running bgpd (let's call them rtr-a
> and rtr-b) on a subnet which also has some vpn gateways and firewalls.
>
> These routers provide a carp address which the vpn gateways are using
> as default route. There are some networks behind the vpn gateways (a
> /32 to accept incoming vpn connections and some other prefixes that
> vpn clients are numbered from).
>
> rtr-a and rtr-b have static routes to those networks, and they have
> network statements in bgpd.conf to announce them to their ibgp peers
> ("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are
> reachable from the rest of the network. (This is replacing an existing
> setup using ospf, trying to remove routing protocols from machines
> that don't really need them).
>
> It is working but something seems a little odd - the paths are
> announced from both routers briefly and show up on the rest of the
> network from both rtr-a and rtr-b. But after a few seconds, rtr-b
> receives these paths from rtr-a, and then rtr-b stops announcing them
> itself. (they stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh
> nex" does correctly identify the associated nexthops as connected/UP).
>
> Is this expected/correct behaviour?
It is expected: once rtr-b receives the route from rtr-a, it will run the route
decision process on it. IF both routers are configured identically except for
the router-id, one of the routes will be prefered at either the "oldest path"
or the "lowest bgp id" criteria.
As only one route is a best route, that one will be annouced to the neighbors.
However this is IBGP. In a set of IBGP connected routers, a router will not
announce a route to other IBGP peers that it received from on a IBGP session.
Thus, rtr-b will stop announcing that route.
When rtr-a goes down, the session is shut down or the prefix is filtered, bgpd
wont see the "better" route anymore and announce its own instead.
> I'd prefer to have them announced from both rtr-a and rtr-b, so
> there's no blackhole period if rtr-a is restarted while rtr-b figures
> out that it should start announcing them, etc. (No need for tracking
> carp state in this case, I'm not using stateful pf rules on the traffic
> involved).
This is a place where ospf might give you faster failover, especiall y with the
redistribute ... depend on ... syntax.
> If rtr-b stops seeing the prefixes from rtr-a (either by taking down
> the ibgp session, or by filtering) I see the announcements from both
> rtr-a and rtr-b again. So the obvious workaround is to filter, but I
> thought I'd ask first in case it's something that is better handled by
> code changes rather than config.
Re: USB devices power control
The simplest could be something like these, https://www.amazon.ca/Powered-USB-Hub/s?k=Powered+USB+Hub. 11 (of the first 12) products are USB 3 hubs with individual port power controls. I have seen single-port USB cables with power switches, too, although I don't remember where. Your idea could be better, but these already exist. Only some (although, *most* AFAIK) USB hub chipsets support turning power on and off for individual ports. Under Linux you can use https://github.com/mvp/uhubctl to control it. Nothing exists (that I know of) under OpenBSD today. You might also use a "smart" hub like those seen at https://electronics.stackexchange.com/questions/393468/efficient-way-to-selectively-unpower-usb-ports and port the necessary software to OpenBSD. (The ugen device driver would probably be adequate, but it might be more of a rewrite than a port. No idea how painful that would wind up being, I've never programmed anything using ugen.) Options exist, but it's possible none of them are *exactly* what you want. -Adam On 2021-10-07 11:57, jeanfrancois wrote: Ok thank both, I might develop such device then, if other people interested I'd share the product. I'll be used to have backup / spare drives online for the work time only; Jean-François Le 06/10/2021 à 16:36, m...@josuah.net a écrit : If nothing can be found software-side, a dedicated hardware could possibly do it. If it exists driver side, some tool like this could give a hint for finding it on other operating system, and then comparing with OpenBSD as well as getting the actual standard names for that feature: https://github.com/mvp/uhubctl Not really a solution, but rather a way to get a little closer.
Re: Run a command on "last day of month"
On Wed, 1 Sept 2021 at 16:39, Adam Paulukanis wrote: > > On Wed, 1 Sept 2021 at 16:32, Christian Weisgerber wrote: > > > > Goetz Schultz: > > > > > I would go the other way and check tomorrows date. If it is "01", then I > > > know today is the last of this month: > > > > > > date --date="tomorrow" +%d > > > 02 > > > > That's not OpenBSD. > > > > $ date --date="tomorrow" +%d > > date: unknown option -- - > > usage: date [-aju] [-f pformat] [-r seconds] > > [-z output_zone] [+format] [[cc]yy]mm]dd]HH]MM[.SS]] > > > > > Not sure if it is OpenBSD. I am on Darwin right now Nevermind. It seems OpenBSD does not have it. > > $ date -v+1d +%d # if today is the last day of the month, tomorrow will be > 1st.
Re: Run a command on "last day of month"
On Wed, 1 Sept 2021 at 16:32, Christian Weisgerber wrote: > > Goetz Schultz: > > > I would go the other way and check tomorrows date. If it is "01", then I > > know today is the last of this month: > > > > date --date="tomorrow" +%d > > 02 > > That's not OpenBSD. > > $ date --date="tomorrow" +%d > date: unknown option -- - > usage: date [-aju] [-f pformat] [-r seconds] > [-z output_zone] [+format] [[cc]yy]mm]dd]HH]MM[.SS]] > Not sure if it is OpenBSD. I am on Darwin right now $ date -v+1d +%d # if today is the last day of the month, tomorrow will be 1st.
Re: Intel 10Gb card (82598AF) on 6.9 release
Jonathan, just wanted to report the patch worked. The card is up and running. Many thanks.
Re: Intel 10Gb card (82598AF) on 6.9 release
On Fri, Jul 16, 2021 at 6:47 PM Jonathan Matthew wrote:
>
>
> I think the problem here is that we don't check if msi is enabled
> before deciding we can use msix. Can you try this diff out?
> I wrote this after seeing a similar report somewhere, but I can't find
> it now.
>
> Index: pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/pci.c,v
> retrieving revision 1.119
> diff -u -p -r1.119 pci.c
> --- pci.c 8 Sep 2020 20:13:52 - 1.119
> +++ pci.c 22 Jun 2021 02:55:50 -
> @@ -410,16 +410,48 @@ pcisubmatch(struct device *parent, void
> }
>
> int
> +pci_device_msi_enabled(pci_chipset_tag_t pc, pcitag_t tag)
> +{
> + int off;
> + pcireg_t cap;
> + uint64_t addr;
> +
> + if (pci_get_ht_capability(pc, tag, PCI_HT_CAP_MSI, &off, &cap)) {
> + /*
> +* XXX Should we enable MSI mapping ourselves on
> +* systems that have it disabled?
> +*/
> + if (cap & PCI_HT_MSI_ENABLED) {
> + if ((cap & PCI_HT_MSI_FIXED) == 0) {
> + addr = pci_conf_read(pc, tag,
> + off + PCI_HT_MSI_ADDR);
> + addr |= (uint64_t)pci_conf_read(pc, tag,
> + off + PCI_HT_MSI_ADDR_HI32) << 32;
> + } else
> + addr = PCI_HT_MSI_FIXED_ADDR;
> +
> + /*
> +* XXX This will fail to enable MSI on systems
> +* that don't use the canonical address.
> +*/
> + if (addr == PCI_HT_MSI_FIXED_ADDR)
> + return (1);
> + }
> + }
> +
> + return (0);
> +}
> +
> +int
> pci_probe_device(struct pci_softc *sc, pcitag_t tag,
> int (*match)(struct pci_attach_args *), struct pci_attach_args *pap)
> {
> pci_chipset_tag_t pc = sc->sc_pc;
> struct pci_attach_args pa;
> struct pci_dev *pd;
> - pcireg_t id, class, intr, bhlcr, cap;
> + pcireg_t id, class, intr, bhlcr;
> int pin, bus, device, function;
> - int off, ret = 0;
> - uint64_t addr;
> + int ret = 0;
>
> pci_decompose_tag(pc, tag, &bus, &device, &function);
>
> @@ -486,28 +518,8 @@ pci_probe_device(struct pci_softc *sc, p
> }
> pa.pa_intrline = PCI_INTERRUPT_LINE(intr);
>
> - if (pci_get_ht_capability(pc, tag, PCI_HT_CAP_MSI, &off, &cap)) {
> - /*
> -* XXX Should we enable MSI mapping ourselves on
> -* systems that have it disabled?
> -*/
> - if (cap & PCI_HT_MSI_ENABLED) {
> - if ((cap & PCI_HT_MSI_FIXED) == 0) {
> - addr = pci_conf_read(pc, tag,
> - off + PCI_HT_MSI_ADDR);
> - addr |= (uint64_t)pci_conf_read(pc, tag,
> - off + PCI_HT_MSI_ADDR_HI32) << 32;
> - } else
> - addr = PCI_HT_MSI_FIXED_ADDR;
> -
> - /*
> -* XXX This will fail to enable MSI on systems
> -* that don't use the canonical address.
> -*/
> - if (addr == PCI_HT_MSI_FIXED_ADDR)
> - pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
> - }
> - }
> + if (pci_device_msi_enabled(pc, tag))
> + pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
>
> /*
> * Give the MD code a chance to alter pci_attach_args and/or
> @@ -1697,6 +1709,9 @@ int
> pci_intr_msix_count(pci_chipset_tag_t pc, pcitag_t tag)
> {
> pcireg_t reg;
> +
> + if (pci_device_msi_enabled(pc, tag) == 0)
> + return (0);
>
> if (pci_get_capability(pc, tag, PCI_CAP_MSIX, NULL, ®) == 0)
> return (0);
Jonathan, thanks for the quick reply. I've never applied a patch
before but don't mind giving it a shot if you'll bear with me. This
patch would be for the -current tree, correct? So the process would be
to get the -current source, apply the patch, then follow the steps to
compile a new kernel?
Intel 10Gb card (82598AF) on 6.9 release
I'm having difficulty getting an Intel 10Gb ethernet card recognized on 6.9. The card is recognized by the ix driver but this error shows up in dmesg: ix0 at pci1 dev 0 function 0 "Intel 82598AF" rev 0x01ixgbe_allocate_msix: pci_intr_map_msix vec 0 failed The rest of dmesg: OpenBSD 6.9 (GENERIC.MP) #3: Mon Jun 7 08:21:26 MDT 2021 r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6341455872 (6047MB) avail mem = 6133891072 (5849MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xea0c0 (74 entries) bios0: vendor Hewlett-Packard version "786F1 v01.35" date 10/23/2015 bios0: Hewlett-Packard HP Compaq dc7800 Small Form Factor acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR acpi0: wakeup devices PCI0(S4) COM1(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.96 MHz, 06-17-06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.51 MHz, 06-17-06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG1) acpiprt2 at acpi0: bus -1 (PEG2) acpiprt3 at acpi0: bus 32 (PCX1) acpiprt4 at acpi0: bus 48 (PCX2) acpiprt5 at acpi0: bus -1 (PCX5) acpiprt6 at acpi0: bus -1 (PCX6) acpiprt7 at acpi0: bus 7 (HUB_) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0003" at acpi0 not configured tpm0 at acpi0 TPM_ addr 0x4e/0x2, device 0x rev 0xff acpibtn0 at acpi0: PBTN "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: !C2(750@40 io@0xf814), C1(1000@20 halt), PSS acpicpu1 at acpi0: !C2(750@40 io@0xf814), C1(1000@20 halt), PSS cpu0: Enhanced SpeedStep 2992 MHz: speeds: 3000, 1998 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82Q35 Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel 82Q35 PCIE" rev 0x02: apic 1 int 16 pci1 at ppb0 bus 1 em0 at pci1 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 1 int 16, address 00:14:5e:76:e2:48 inteldrm0 at pci0 dev 2 function 0 "Intel 82Q35 Video" rev 0x02 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0: apic 1 int 16, G33, gen 3 "Intel 82Q35 HECI" rev 0x02 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel 82Q35 PT IDER" rev 0x02: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev 3 function 3 "Intel 82Q35 KT" rev 0x02: ports: 16 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 0 bytes em2 at pci0 dev 25 function 0 "Intel ICH9 IGP AMT" rev 0x02: apic 1 int 19, address 00:1f:29:d3:dc:76 uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 1 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x02: apic 1 int 21 azalia0: codecs: Analog Devices AD1884 audio0 at azalia0 ppb1 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02 pci2 at ppb1 bus 32 ppb2 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x02: apic 1 int 21 pci3 at ppb2 bus 48 uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 1 int 20 uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 1 int 21 ehci1 at pci0 dev 29 func
Re: How to unlock a serial port
On 2021-01-19 19:15, Nick Holland wrote: On 1/19/21 4:35 PM, Adam Thompson wrote: I ran into this exact problem last year. It'll be in the list archives. According to Theo (if I understood him correctly) it's partly due to the way BSD serial ports have always worked, i.e. in a rather under-specified manner. Apparently the core tty(4) code around this particular symptom hasn't really changed at all since OpenBSD forked. I'm curious what you think "this exact problem" is. Based on later messages in the thread, it's clear I did *not* have the exact same problem, after all. I was experiencing ttys that remained busy after the process that opened them had closed. So, for example, if I used "screen /dev/cua0 9600", after exiting screen(1), confirming with ps(1) that all screen processes were gone, and confirming with lsof/fstat that nothing still had either cua00 or tty00 open, if I re-ran "screen /dev/cua00 9600" - or ANY other application, including cu(1) - the new process would simply block. ktrace(8) confirmed that the open(2) call was simply blocking... forever. I could reproduce it with cu(1) as well as screen. Don't think I tried any other apps. I recall that someone suggested at the time that it might be signal line related, but it didn't matter whether I had full RS-232 CTS/RTS and/or DCD/DSR signalling, basic 3-wire signalling only, or even if I unplugged the cable entirely, the blocking behaviour stuck around until I rebooted. Granted, rebooting on a single-port terminal server isn't the end of the world, but it was a PITA that I got tired of. (Oh, if I used a USB serial adapter, unplugging and replugging the USB dongle also cleared the problem.) I'm not going to say serial support in OpenBSD is perfect, but it works Darned Well, Mostly, I agree. I still don't know what was different about this one use case. Pretty sure it wasn't hardware - I reproduced it on three vastly different amd64 systems, and with both traditional UARTs and USB dongles. Pretty sure it wasn't (Exclusively) a PEBCAK issue. But still not sure what it was. I'll try again at some point, and I'll post if/when it happens to me again. -Adam
Re: How to unlock a serial port
[Replying directly as well, as I believe my MTA is still blacklisted by the OpenBSD mail server. Guess we'll find out! -Adam] On 2021-01-17 20:09, Tilo Stritzky wrote: On 14/01/21 17:38 Andrew Grillet wrote: Hi I am running OpenBSD on a T2000 (Sparc64). I was trying to use the serial port from the primary domain, connected via ssh, and my network lost the connection. My tty00 is now locked: jay# stty -f /dev/tty00 stty: /dev/tty00: Device busy I do not want to reboot the primary, as the guests are running various live services. I cannot find evidence of a lock file in /dev/spool/lock. Is there a way out of this predicament? fstat(1) is your friend here. Note that each tty has a corresponding cua device, they're both under the same lock. tilo I ran into this exact problem last year. It'll be in the list archives. According to Theo (if I understood him correctly) it's partly due to the way BSD serial ports have always worked, i.e. in a rather under-specified manner. Apparently the core tty(4) code around this particular symptom hasn't really changed at all since OpenBSD forked. My solution was to install Linux, sorry - I never did find a way around the problem on OpenBSD. -Adam
Re: Mounting encrypted drive on boot
‐‐‐ Original Message ‐‐‐ On Wednesday, June 3, 2020 7:27 AM, Chris Narkiewicz wrote: > My setup consist of OpenBSD 6.7 with full drive encryption using > softraid, configured as described in FAQ: > > /dev/sd0a - encrypted volume > /dev/sd1 - decrypted > > I have additional need to mount an encrypted /var volume on boot. > This volume is separate drive attached to be VPS "machine". > > I want to mount this drive automatically on boot by adding > relevant entries to /etc/fstab, but before this can be done, > softraid device must be configured using bioctl. > > On Linux this is done by adding some entries to /etc/crypttab > and the boot script performs required configuration before disks > in fstab are mounted. > > How to do similar thing in OpenBSD? > > Somebody on StackOverflow advised on modifying /etc/rc > and run bioctl before disks are mounted, but I'm not sure > if this is a right approach, especially that attaching > more disks might change the /dev/sd* numberign. > > What would be the best approach? > > Best regards, > Chris Take look at https://xosc.org/enchome.html, and use the FAQ along with that document. It works for me with an encrypted /home, but /var might be a lot more problematic. Cheers Adam
Re: RCS file ownership?
Being neither a C programmer nor a Texinfo fan, checking GNU RCS is a
bit painful, and my conclusions aren't guaranteed.
AFAICT, GNU RCS (v5.9.4, ca. 2015, examined) creates a temp file,
unlinks the target file, then renames the temp file. I beleve this
guarantees(-ish, modulo "special" filesystems including NFS and
FreeBSD's directory-SUID behaviour) that resulting file ownership =
euid.
The GNU docs mention the repo owner in passing a few times but do not
have a section describing multi-user operation.
The Tichy docs also don't mention file ownership. I'm trying to review
the O'Donovan book, too, but it's been a long time since I had to tool
up to handle raw PS... not quite there yet.
Purdue RCS appears to be the direct ancestor of GNU RCS.
I'm not sure which other implementations you'd be worried about - I
thought OpenBSD's RCS was the direct descendant of NetBSD's and shares
common lineage with the other *BSDs?
All in all, it looks like RCS and its docs were written in the era when
UNIX machines were - more or less by universally - used by multiple
people, and you just had an innate sense of how multi-user file
ownership would work. Most of my UNIX machines now resemble appliances,
and exactly zero of them are multi-user in the classical sense.
-Adam
On 2020-04-29 21:53, Theo de Raadt wrote:
Sorry, but my mail goes further.
It says it should be correct. For some definition of correct. It
should either behave somehow for a logical reason, or it should behave
in the historical fashion. Or once the historical behaviour is looked
at, if there is an argument that is wrong, then it should be changed
with logic about "this is an improvement" backing the argument.
I think it is wrong to document how *this* rcs implimentation behaves,
without comparing it against others.
My guess is 50% that the others don't unlink, but rewrite the file.
And the changes it might require to be compatible are not substantial.
At most a 20 line diff, to a few programs in the family.
athom...@athompso.net wrote:
Thank you for that detail!
Addressing this one corner case would require substantial changes, I
think. Not worth
it, in my opinion.
I think it would be worthwhile describing the multi-user mode of
operation of RCS in
the manual, as it's currently completely absent/omitted. Patch coming
soon, maybe
tomorrow if I can make time.
-Adam
On Apr. 29, 2020 21:28, Theo de Raadt wrote:
athom...@athompso.net wrote:
> Heh, good point. Didn't even occur to me because as it happens, I
am
> running as root and would like to not change the ownership.-Adam
> On Apr. 29, 2020 13:32, Anders Andersson
wrote:
>
> On Wed, Apr 29, 2020 at 7:46 PM Adam Thompson
> wrote:
> >
> > When I use co(1) with "-l" to check out a file (and/or "ci -l")
is
> there
> > any way to preserve file ownership and *not* have it reset to
the
> user
> > running co(1) or ci(1)?
> > I don't see anything in rcs(1), co(1) or ci(1) that even
mentions
> the
> > fact that the file will wind up owned by the user running the
> command.
> > Ideas? Pointers to documentation?
>
> How could it possibly do anything else unless you always run co
as
> root?
Our rcs tools do:
52628 co RET kbind 0
52628 co CALL unlink(0x7f7ed1f3)
52628 co NAMI "ls.c"
52628 co RET unlink -1 errno 2 No such file or directory
52628 co CALL open
(0x7f7ed1f3,0x601,0100444)
52628 co NAMI "ls.c"
52628 co RET open 4
52628 co CALL kbind(0x7f7ec908,24,0x847da2a816b5d817)
Which appears to be this:
else {
(void)unlink(dst);
if ((fd = open(dst, O_WRONLY|O_CREAT|O_TRUNC, mode))
== -1)
err(1, "%s", dst);
I don't know what older or gnu rcs do. I guess whichever way this is
done
it must balance concerns between atomicity of concurrent reads
performed
by earlier processes, versus replacement of a potentially active
file.
If the latter is chosen, it would unlink(), perform the open more
carefully, check that it is in the right place with fstat, but then
it needs some work for ftruncate (to get rid of extra file contents
at the end). If the open() failed, it might try an unlink followed
by
open()?
Other rcs implimentations need to be checked. It is better if they
work
the same.
RCS file ownership?
When I use co(1) with "-l" to check out a file (and/or "ci -l") is there any way to preserve file ownership and *not* have it reset to the user running co(1) or ci(1)? I don't see anything in rcs(1), co(1) or ci(1) that even mentions the fact that the file will wind up owned by the user running the command. Ideas? Pointers to documentation? Thanks, -Adam
Re: mount dir over another dir
On 2020-04-16 02:13, Ono Caritofilaxy wrote: Hello. I want to mount /usr/local/srcdir /usr/local/dstdir/subdir answer was "no" 3 years ago https://marc.info/?l=openbsd-misc&m=149743861203607&w=2 Can I do this now? If not - why? Is it dangerous? You should be able to do this as an NFS mount. With all the nastiness that NFS mounts come with, but it's an option. (I'm doing it in production on 6.6-STABLE.) -Adam
door handles
None of the Taymor levers are quite right. So I went looking, and I found some of what I'm looking for. Short list: (top pick) 1. Omnia 762, plus privacy bolt. I love it but holy shit that's expensive @ ~US$180ea! https://www.omniaindustries.com/product/762/ 2. Rocky Mountain Hardware's "BELLA" lever, included in door set, price unknown, distributor/retailer unknown. https://www.rockymountainhardware.com/products/door-hardware/handles/levers/door-levers/bella-lever-l150 3. Emtek (an Assa Abloy company)'s "Spencer" Lever. Price unknown. Lots of local retailers. https://emtek.com/passage-privacy-levers/spencer-brass-lever 4. Schlage/Dexter J-series "Dover" lever. Price: cheap. Local availability unknown. https://www.schlagecanada.com/en/home/products/J40DOVFFF.html# 5. Schlage/Dexter "Jazz" level. Price: cheapish. Local availability unknown. https://www.schlagecanada.com/en/home/products/F40JAZFFF.html# (bottom pick) 6. Weslock "Bristol" or "Bristol UL" http://weslock.com/product/bristol-2/ or http://weslock.com/product/bristol-ul-2/
Re: syspatch(8) return values?
On 2020-02-08 06:03, Antoine Jacoutot wrote: On Fri, Jan 31, 2020 at 09:03:59AM -0600, Adam Thompson wrote: There's no mention of what syspatch(8) returns, in the manpage. I can prove quickly enough that it exits(0) when there's nothing to do, but I'm more interested in knowing (for automation purposes) what the return values are in other circumstances, and all my systems are already up to date. Before standing up yet another system, I figured I'd ask here. I can think of four scenarios syspatch(8) perhaps ought to distinguish, at least I'm interested in these 4 outcomes: 1. nothing to do 2. patches waiting, but didn't do anthing 3. patches applied 4. something went wrong Can I reliably tell based on $? or do I have to parse the output? Most likely parse, yes. "patches waiting, but didn't do anything" might be interesting (i.e patches are available); dunno... Equally if not more interesting would be "I tried to apply patches but failed somehow". Which happened to me, and which is why I asked in the first place. *sigh* I'll try to propose some bad diffs [if I'm writing them, they'll be bad] someday soon. -Adam
Re: Dell Latitude e6400 OpenBSD Drive Issue
On 2020-02-10 09:36, Michael G Workman wrote: Ok, thanks for the info. For your E6400, see this guide: https://www.parts-people.com/blog/2012/10/16/dell-latitude-e6420-cmos-battery-removal-and-installation/ I found E6400 CMOS batteries from multiple vendors on the first page of Google results, most around US$10. The only recommendation I can give is that I've used Parts-People.com in the past, no complaints with them. Make sure you get the right replacement - check if your battery is 2-wire or 3-wire *before* ordering a replacement - many of the listings don't worry about such minor details, g. The older the Latitude, the harder it is to open, but even an E6400 is pretty easy, even if you've never opened up a laptop before. Good luck, -Adam
Re: Dell Latitude e6400 OpenBSD Drive Issue
On 2020-02-09 06:58, Michael G Workman wrote: Hello, Shout out to the OpenBSD developers for making a great OS! I was able to install OpenBSD 6.6 on a Dell Latitude e6400 laptop, with a USB Install. Sent the dmesg in already. The installer would not recognize the hard drive, a brand new SSD drive. The solution to that, from stack exchange, was to change the SATA settings in BIOS from IRRTL to AHCI, that fixed the problem. However if my laptop is powered off for a while, the SATA setting changes back to IRRTL instead of AHCI, very annoying, not sure why the BIOS would not make my changes persistent. I think it may be a hardware issue, but just wanted to know if anyone else has encountered this before? Thanks. *Michael G. Workman* (321) 432-9295 michael.g.work...@gmail.com I have run several laptops from that series with OpenBSD. The other replies are correct, your BIOS battery is dead. Unfortunately, on many of the Latitudes, the BIOS battery is of the variety that's embedded in the RTC chip, and is not separately replaceable. Some, however, including - the 6430 for example - have a regular coin cell, albeit wrapped in a proprietary cover with a non-standard connector, but at least is *is* replaceable without insane amounts of work. I have the owner's manuals for many of the 6400 series, email me directly if you can't find the guide to replacing parts for your particular model. -Adam
Re: suggestions for USB printer (maybe even with scanner)?
On 2020-02-05 13:56, Claus Assmann wrote: I need to buy a printer to connect to one of my OpenBSD machines and I prefer a USB connection (as I don't control the network at my current place). Can I just buy any USB printer or are there printers which do not work with OpenBSD? If so, what do I need to check / avoid? Any suggestion for something "cheap" (to print just a few documents as needed)? I never had to buy a printer before, so I'm not familiar with this area -- if possible I would like to get a printer/scanner but I have no idea what I can buy locally :-( A HP laserjet (which was a gift but broke today) worked only with one of my OpenBSD machines which seemingly was related to the USB HW, using a printcap entry like this: usb:lp=/dev/ulpt0:sd=/var/spool/output/usb:sf:sh:tr=^D: I don't know what you need in a printer, and I don't know what you mean by cheap, so... YMMV. However, I've found Brother **LASER** printers to be very good, and most of them support PCL6 and/or PS3. For example, the HL-L2370DW can only connect via USB, and supports PCL6, and currently sells for ~C$150-160. Just don't try to use their MFC-* line of color printers under UNIX (except MacOS). FWIW, if you're in a situation where you have a spare Mac, the Mac can bridge from CUPS/PDF format to Brother proprietary format... bit pf a pain but it works. -Adam
tap(4) remaining active (status: active) after process exits
Hi
I have a process that uses a tap(4) interface, when the process exits, i
expected the interface be have status "no carrier", it is still "active".
I setup the tap interface as follows
cd /dev/
doas ./MAKEDEV tap100
doas ifconfig tap100 inet 10.0.0.1 netmask 255.255.255.0
in code the interface is opened as follows
open("/dev/tap100", O_RDWR | O_NONBLOCK)
I don't close the device (but did test this too, and not change), and the
interface remains "active" after the process is finished.
my program used to leave the interface in a status of "no carrier" in
OpenBSD 6.4 and 6.5, but with the recent tap/tun work this appear to no
longer be the case.
I am running current, see my dmesg below.
should i post this to bugs@ instead.
Cheers
Adam
OpenBSD 6.6-current (GENERIC.MP) #26: Mon Feb 3 12:55:51 AWST 2020
ast...@x220.adamsteen.com.au:/sys/arch/amd64/compile/GENERIC.MP
real mem = 17041059840 (16251MB)
avail mem = 16512131072 (15747MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries)
bios0: vendor LENOVO version "8DET69WW (1.39 )" date 07/18/2013
bios0: LENOVO 4291N58
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT
SSDT DMAR UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.27 MHz, 06-2a-07
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 MHz, 06-2a-07
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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 5 (EXP4)
acpiprt5 at acpi0: bus 13 (EXP5)
acpiprt6 at acpi0: bus -1 (EXP7)
acpicpu0 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu1 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
acpibat0 at acpi0: BAT0 model "42T4861" serial 16466 type LION oem "SANYO"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0: version 1.0
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
acpivout at acpivideo0 not configured
acpivideo1 at acpi0: VID_
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 2492 MHz: speeds: 2501, 2500, 2200, 2000, 1800, 1600,
1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address
f0:de:f1:77:c2:c8
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x04: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
azalia0 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x04: msi
azalia0: codecs: Conexant CX20590, Intel/0x2805, using Conexant CX20590
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb4: msi
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 1 "Inte
syspatch(8) return values?
There's no mention of what syspatch(8) returns, in the manpage. I can prove quickly enough that it exits(0) when there's nothing to do, but I'm more interested in knowing (for automation purposes) what the return values are in other circumstances, and all my systems are already up to date. Before standing up yet another system, I figured I'd ask here. I can think of four scenarios syspatch(8) perhaps ought to distinguish, at least I'm interested in these 4 outcomes: 1. nothing to do 2. patches waiting, but didn't do anthing 3. patches applied 4. something went wrong Can I reliably tell based on $? or do I have to parse the output? Thanks, -Adam
password-less user (without bothering security(8))?
Hi, On 6.6-STABLE, I'm looking at security(8) and it's not immediately obvious to me how I can have an SSH key-only user who does not have a password, that also does not trigger daily security warnings. The goal is to have a user that can never log in on the console, or via password any other way (FTP, SMTP auth, POP, etc., etc.), but only via the RSA key provided. Is there a way to placate security(8) that I'm just not seeing? Or is my goal fundamentally misguided for some reason I'm not seeing? The user in this case is semi-trusted (e.g. yes, we'll let you login using an unprivileged account to run bgpctl in pipelines) but not organizationally-trusted (i.e. but that's ALL we want you to do on this system). Thanks, -Adam
Re: Is there an easier way to browse ports?
Ah, there's a good answer to the question I just asked Marc, thanks!-Adam
Re: Is there an easier way to browse ports?
Oh, ok... Do you recall an example offhand? (I haven't noticed systemic problems with either, but then I'm hardly a ports expert!)Thanks,-Adam On Nov. 7, 2019 07:18, Marc Espie wrote: On Wed, Nov 06, 2019 at 04:44:48PM -0600, Adam Thompson wrote: > Also http://openports.se/ and http://ports.su/ . Don't use those, they don't know how the openbsd ports are named.
Re: Is there an easier way to browse ports?
On 2019-11-01 06:12, Mischa wrote: On 1 Nov 2019, at 12:08, Alfred Morgan wrote: My current workflow looks something like this: $ cd /usr/ports $ make print-index | less I search and scroll through and find something interesting such as opensonic. I read the Info: game based on the Sonic the Hedgehog universe ^Z $ cat games/opensonic/pkg/DESCR # I can't get make describe to work I read more about it. I google opensonic for screenshots. $ pkg_add opensonic $ opensonic $ fg Ideally I would like a graphical ports browser with name, screenshots, and description that I can scroll and search through. Curation would be nice: ports suggestions, popular ports, dev team ports picks, etc. -alfred Have a look at: https://openports.pl <https://openports.pl/> I think it ticks some of your boxes. :) Mischa Also http://openports.se/ and http://ports.su/ . -Adam
Re: Tools for writers
On 2019-11-02 11:14, Peter Nicolai Mathias Hansteen wrote: 2. nov. 2019 kl. 16:00 skrev Oliver Leaver-Smith : What tools do people find useful for writing on OpenBSD? By writing I mean long form such as novels and technical books, including plot and character development, outlining, and formatting for publishing (not all the same application necessarily) I have found a number which boast Linux support, but not really anything that stands out which supports OpenBSD (aside from the obvious LaTeX et al.) I really can’t speak to plot and character development, but all three editions of The Book of PF were written using OpenOffice and later LibreOffice write on OpenBSD snapshots. Earlier versions of that manuscript were developed using DocBook SGML (editing with emacs), but the publisher (fortunately) did not want any truck with that. For any new projects I would likely look half-heartedly for something markdown based but would probably end up going the LibreOffice route again. FWIW, Brian Kernighan's new book was written using groff(1), with final rasterization done by gs(1), obviously there's a number of other tools involved. On the other hand, unless you name is Brian Kernighan (or possibly Kristaps, Ingo, or jmc@) I doubt that toolset will satisfy you :-). A few people around here have used TeX, LaTeX, and LyX (a LaTeX front-end) all of which are very much capable of large projects split into sections/chapters/etc. AFAIK OpenBSD's LaTeX / TeX packages are all more than adequate to the task, and all of the necessary tools are in ports. -Adam
bgpctl(8) community question
[OpenBSD 6.5-STABLE, up to date] When using bgpctl(8), I'm able to do almost everything I need, but I'm having trouble figuring out how to do one thing: How do I show routes that do NOT have a community (or ext-community, or large-community) attribute? The best I can come up with so far is a fairly ugly AWK script that buffers the detailed route output, then emits it if it doesn't see a Communities: line. Am I missing a better way? Thanks, -Adam N.B. manually looking through N sets of DFZ route tables isn't going to happen, I need a mostly-automatic solution.
Re: help understanding cua/tty EBUSY behaviour?
On 2019-08-03 18:14, Theo de Raadt wrote: Adam Thompson wrote: Summary: I open cua0 with cu(1), quit cu(1), try to re-open with cu(1) but now it immediately fails with EBUSY. *Usually* doesn't happen with USB-to-serial (cuaU[0-9]) but have still seen it once or twice. [...] You are observing the forcing-down of DTR and RTS for a long enough period that the other side of the link notices the event. Therefore it is not suprising you are finding this behaviour very similar in many drivers and operating systems. Thanks! I feel as though I'm seeing something that's slightly off (see below), but I was focused on the open() end of things not the close() end - I now need to do more reading. FWIW, things that don't *feel* right about this: * "long enough" doesn't typically describe multiple days, in DTE/DCE signalling. Far-end device is the same when testing using cua00 vs. cuaU0. * isn't cua(4) supposed to be the device we use to ignore line signals? Why would closing it fiddle with line status? Maybe I'm reading too much into hupcl in stty(1) manpage... * and now I'm wondering if cu(1) fiddles with [-]clocal and/or [-]hupcl As I said, more reading now you've given me a direction and I'll probably come back with at least one or two of my own answers. -Adam
help understanding cua/tty EBUSY behaviour?
Summary: I open cua0 with cu(1), quit cu(1), try to re-open with cu(1) but now it immediately fails with EBUSY. *Usually* doesn't happen with USB-to-serial (cuaU[0-9]) but have still seen it once or twice. I've seen this behaviour on OpenBSD 6.4, OpenBSD 6.5, and FreeBSD 11.2, and on 3 radically different systems (hardware-wise) so I don't think it's a version-specific or even hardware-specific bug, more likely something I'm failing to understand. I'm using OpenBSD as a remote serial console server for up to 3 switches at a time (OOB access to a few switches in my lab). This works, mostly... but occasionally, a serial port, almost always the onboard hardware cua0/tty0 port, somehow wedges and requires me to reboot the OBSD system to regain access to it. The symptom is that when attempting to open(2) the device, I get EBUSY... for no obvious reason. fuser(1) shows no other processes having a filehandle on /dev/cua00. I don't understand why this happens inconsistently - about ~75% of the time on /dev/cua00, but only ~10% of the time on /dev/cuaU[0-1]. Of the ~75% of the time it happens on /dev/cua00, about 1/3 of those times, if I wait a minute or ten, I can then re-open the device (again using cu(1)), and 2/3 of those times it persists until a reboot. On the USB devices, I can - with 100% success - eliminate the problem by walking over, unplugging the serial adapter, and re-inserting it. I haven't tried using e.g. screen(1) from ports, I've only tested using cu(1) in base so far. I can try something else if there's a reason to... on the OpenBSD box anyway, it'll be a bit harder on the FreeBSD appliance. As I said, I've even seen this on FreeBSD, so I expect I just need someone to provide an explanation of what nuance of tty(4) usage I'm missing. Help? Thanks, -Adam
Re: SCM
On 2019-07-23 12:43, Stuart Henderson wrote: On 2019-07-22, Stefan Sperling wrote: If your university class prefers using git, I'd recommend the repository at https://github.com/openbsd/src. However, it doesn't include branches/tags, because we haven't found anything that is able to successfully convert the OpenBSD CVS repository to git unless it ignores these. I haven't tried this with the OpenBSD code base, but in a previous life I did a CVS to Git conversion starting with a repo that resembled OpenBSD's in many ways. The "solution" was to get to git by way of SVN. SVN was able to preserve branches/tags/etc. from CVS into SVN, and was then able to in turn be converted to git through SVN's git-compatibility layer (IIRC). Whether this helps anyone out there... *shrug* -Adam
Re: ipv6 nmap breakage under 6.5-STABLE ?
On 2019-07-22 09:51, Adam Thompson wrote: Hi, [Cross-posted to misc & ports as I'm not sure if there's a bug in software or in wetware.] I'm trying to run nmap (from ports) on 6.5-STABLE but am getting an ungoogle-able error message every time: Forgot to mention - this occurs under OpenBSD, but not Linux (CentOS 7.6.1810 & nmap 6.40). Obviously that's not an apples-to-apples comparison, but it's what I've got access to from here right now. -Adam
ipv6 nmap breakage under 6.5-STABLE ?
Hi, [Cross-posted to misc & ports as I'm not sure if there's a bug in software or in wetware.] I'm trying to run nmap (from ports) on 6.5-STABLE but am getting an ungoogle-able error message every time: root@bgpmirror:~# nmap -Pn -A -n --top-ports=100 -6 2620:132:300e:700::113 Starting Nmap 7.70 ( https://nmap.org ) at 2019-07-22 09:43 CDT sendmsg: Message too long sendmsg: Message too long [...continues like this for a really long time...] Interspersed semi-randomly (not always at the same point) I also see mixed in there a single occurrence: sendmsg: Message too long sendmsg: Bad address Unable to send packet in probe_transmission_handler: Bad address (14) sendmsg: Invalid argument Unable to send packet in probe_transmission_handler: Invalid argument (22) sendmsg: Message too long Unable to send packet in probe_transmission_handler: Message too long (40) sendmsg: Message too long Performing a similar scan on an IPv4 address works as expected. This appears to be a v6-specific problem. Known issue? Workarounds? Thanks, -Adam
Re: Postscript printer recommendations
On 2019-07-14 15:40, Stuart Henderson wrote: If you don't want trackable prints, don't buy a colour laser printer of any brand, it is very common. Unsure about mono and inkjet printers, I would tend to assume that they're common on at least most hi-res colour printers. Nearly every printer sold today (including cheap inkjets AND b&w printers) have these tracking dots. It's unclear why/how this came to be; I've heard multiple stories and am unsure which to believe, if any. Regardless of the why/how, consensus is clear: those dots are real and can tie output back to your printer. I read that Postscript printers produce superior graphics (from Xerox website): In 2019, that remains true only in a very small number of edge cases. The absolute highest resolution graphics today are mostly printed using ESC/P (if Epson), PCL3 (if HP), or whatever Canon uses (if Canon). Mostly people "prefer" Postscript output over PCL because the default rendering gammas(sic) are slightly different and Postscript is usually perceptually more pleasing. Adjust gamma on your PCL printer from 1.1 to 1.2 and *poof* just as good as Postscript. YMMV, even Postscript-compatible printers are all different nowadays. If I was looking to spend money on a nice printer I'd get one which can accept postscript and PDF directly over lpr. (I'd be very tempted by the hp "pagewide" printers. Also Kyocera seem good especially for high volume stuff). I haven't tried Kyocera recently, but I have tried HP recently in that line. Stay as far away as you can get. All the decent PageWide printers seem to be discontinued already, and the replacement 11x17" color OfficeJet Pros are severely lobotomized and need to talk to the "cloud" for almost all functions except basic print-to-paper... and even that doesn't work very reliably, even with the Windows/MacOS drivers. If I was looking for something cheap and cheerful then I would worry less about postscript but look for something where I can see signs of support in the ports tree. The HPLIP ports are nice and easy to use and work with a wide range of HP and some other printers, easiest to use with CUPS (it really isn't difficult), but if you want to avoid it I believe the HPIJS part of HPLIP can be used without CUPS. I've heard good things about brlaser for the non-postscript Brother printers too, though most of them do have ps anyway. Even if keeping things cheap I would definitely want something with an ethernet port (it doesn't add much if anything to the cost) for flexibility of positioning the printer, easier sharing between machines, and not having to mess around with permissions on device nodes etc.. Agreed - most decent business printers nowadays come with both ethernet and wifi, so you get the best of both worlds. Brother's mono lasers are generally *excellent* value for the money. Color lasers unknown. Stay away from their color inkjets, they are effectively Win/Mac-only. (But if you are on Win/Mac, those provide excellent $/page.) Epson's color inkjets are pretty good, and at the *really* high end beat color lasers in all ways, and include Postscript. (Those high-end units also cost many 10s of $Ks. But, wow, nice specs.) Lower-end units support ESC/P and mostly work with CUPS. Buy the business models if you want a decent cost-per-page. Canon printers can be decent, but are not usually good value for money... YMMV, just make sure you can return it if you can't make it work. HP used to be very good, and their mono LaserJets are still acceptable. Color LaserJets... less good, but maybe still acceptable. Inkjets? Who knows, there's a new model every week, each incompatible with the last one. Your best bet will likely be to purchase a new "business-grade" printer from a shop that will let you return it if you can't get it to work. Unfortunately, YMMV depending on what part of the world you're in, any local promotions/sales, the phase of the moon, whether Jupiter is in alignment with Saturn, etc., etc. Good luck, -Adam
Re: How does OpenBSD probe for I/O devices?
On 2019-06-12 13:12, ¯\__/¯ ¯\__/¯ wrote: I've search for the answer to this question, but I can't find it. I also read the source code, but I still don't get how it works. Help pl0x Not sure exactly what you're looking for... On modern architectures, most OSes (including OpenBSD) "walk the hardware device tree". The possible topologies and nodes of the device tree are controlled by the kernel source code. OpenBSD does 99% of it at boot time, with a few notable exclusions (PCMCIA, PC CARD, USB, can't remember what else). Look under /usr/src/sys/arch/* for functions with "_attach_" in their names, which should give you a very rough idea of where to start looking. For both historical and somewhat-current documentation on how this works, check out https://en.wikipedia.org/wiki/Marshall_Kirk_McKusick#Bibliography . (I'm unaware of any OpenBSD-specific publications covering that sort of thing, but OpenBSD *is* derived from the same BSD UNIX that Kirk wrote about. Lessons learned about one BSD can, usually, have their concepts applied to their cousins - although the implementation details have diverged quite a bit by now.) -Adam
Re: The su manual doesn't mention use root account by default
On 2019-06-12 03:55, Ingo Schwarze wrote: Even though su(1) can still be used today to relinquish privilege when you are already root, no more development is done on it and people rarely look at the manual page. The last time new functionality was added to the su(1) manual page was almost a decade ago, and the last time before that 17 years ago. Well, su(8) also is used to obtain root privileges in the first place. FWIW, I regularly use "su" on OpenBSD because it's a relatively consistent cross-platform way to have root run a command as someone else. I recall a good number of ports using su(8) internally in, e.g. process-control scripts - but that was years ago, not sure if it's still true or not. doas simply isn't available anywhere else (yet). (IMHO, I don't think a portable version of doas has a lot of potential - it's not complicated enough! ) During initial system installation & deployment, before doas is configured, and assuming you haven't [yet] added your SSH keys to ~root/.ssh/allowed_keys, it's quite impossible to avoid using su. (AFAIK. If there's another way, let me know!) I hope you're just saying that su(8) is a mature, stable utility that needs no further work right now. It kind of sounds like you might be saying that su(8) could be on the chopping block, much like sudo(8)... have I misread that? -Adam
openup failing?
I've seen a large number failures recently from m:tier's openup tool, complaining of: ftp: connect: Host is down !!! Cannot retrieve https://stable.mtier.org/openup !!! Please verify your Internet connection, proxy settings and firewall. I'm seeing this from two different networks/providers/companies, so I'm assuming it's not me, but am posting this to validate that assumption. Assuming it's not just me, does anyone know what's going on with them? The relevant routes appear in the DFZ, but none of the *.mtier.org IPs I know of respond. -Adam
"Invalid argument" when exec'ing and/or ktrace'ing a file?
I have a binary - built on this 6.5-STABLE amd64 system by an automatic build process as part of a CPAN module installation, that will not execute: rt@rt$ /var/www/rt/local/plugins/RT-Extension-TicketPDF/bin/wkhtmltopdf ksh: /var/www/rt/local/plugins/RT-Extension-TicketPDF/bin/wkhtmltopdf: Invalid argument or even allow itself to be ktrace'd: rt@rt$ ktrace /var/www/rt/local/plugins/RT-Extension-TicketPDF/bin/wkhtmltopdf ktrace: exec of '/var/www/rt/local/plugins/RT-Extension-TicketPDF/bin/wkhtmltopdf' failed: Invalid argument At least ktrace(8) told me it was an exec(3) problem. So off I go to exec(3) which leads me to execve(2), wherein I see: [EINVAL] argv did not contain at least one element. errno(2) confirms the english expansion of "Illegal argument" file(1) gives me a clue, but I don't know what to do with it: rt@rt$ file `locate bin/wkhtmltopdf` /usr/local/bin/wkhtmltopdf: ELF 64-bit LSB shared object, x86-64, version 1 /var/www/rt/local/plugins/RT-Extension-TicketPDF/bin/wkhtmltopdf: ELF 64-bit LSB executable, x86-64, version 1 where the version in /usr/local/bin is from ports. the RT::Extension::TicketPDF version is significantly larger, ~4x, which led me to: rt@rt$ ldd `locate bin/wkhtmltopdf` /usr/local/bin/wkhtmltopdf: StartEnd Type Open Ref GrpRef Name 041737f61000 04173ac77000 exe 20 0 /usr/local/bin/wkhtmltopdf 0419ee50 0419ee599000 rlib 01 0 /usr/local/lib/libjpeg.so.70.0 [...elided...] /var/www/rt/local/plugins/RT-Extension-TicketPDF/bin/wkhtmltopdf: not a dynamic executable So... how do I figure out why a static binary (whose build process is pretty opaque) won't/can't run? Clueless at this level, my detailed knowledge of how exec worked under OpenBSD ended in the a.out era. (oh, the reason I don't use the version from ports? It's too new for the TicketPDF code. *sigh*) Thanks for any pointers, -Adam
Re: OpenBSD on VMware ESXi
On 2019-05-22 09:25, mxb wrote: I think FreeBSD or any Linux template will work just fine and add vmxnet3. However, last I checked (1year ago) vmxnet3 been less stable than e1000 under pressure. Don't use the Linux templates. I would recommend against using the FreeBSD templates, and go with "Other (64-bit)" instead. YMMV on using FreeBSD vs Other, I haven't seen consistent results here yet... just don't pick Linux, or DOS, or Windows - in some situations, that allows VMware to take certain shortcuts that are based on assumptions about the Linux/Win/etc. kernel & device drivers that (probably) aren't valid under OpenBSD. Various people have reported different problems with vmxnet3; I'm aware of at least 4 or 5 different environment-specific issues (i.e. can't be reproduced on any other vSphere/ESXi system). I have some of those problems, and I cannot reproduce them outside my production environment, but they don't prevent me from running OpenBSD. Workarounds: * use vmxnet2 * use e1000 If vmxnet3 and pvscsi work for you (you'll know pretty darn fast!), use them. When they work, which is usually (in my experience), they're generally very stable and high-performing compared to the emulated h/w (e1000, lsisas, lsiscsi, buslogic). I also experience timer issues, and I've had to specify kern.timecounter.hardware=i8254 in sysctl.conf. This is likely a VMware problem, not an OpenBSD problem, but it's non-trivial to diagnose. (Even i8254 doesn't work perfectly: e.g. usleep() isn't very accurate in my VMs!) I'm also running these VMs on very heavily-loaded hosts, which is probably a factor. My disk write throughput is horrible, but that's an interaction between how OpenBSD does writes, how VMware handles writes into thin-provisioned disks, and how my NFS storage handles writes on thin-provisioned volumes; it's not an OpenBSD problem, strictly speaking, although that's the only place it's normally visible. Overall, OpenBSD works well under ESXi, but there are semi-random problems that do have workarounds. Several years ago, Theo noted (approximately, I'm going from memory here AND paraphrasing) that it was hard enough for OpenBSD to handle broken hardware implementations, it's exponentially harder to handle an incorrect software emulation of hardware that was incorrect in the first place. This has proven accurate, and VMware doesn't really care much about OpenBSD, since I doubt it even registers on their radar so they're not terribly interested in fixing VMware bugs that are only visible under OpenBSD. (If you have a support contract, please submit bug reports to VMware. If enough of us do so, they might start fixing some of the problems.) -Adam
Re: relayd without pf?
FWIW, I also encountered some slightly different error messages, I'll see if I can reproduce those. -Adam On May 14, 2019 4:48:29 p.m. CDT, Reyk Floeter wrote: > >> Am 14.05.2019 um 23:06 schrieb Adam Thompson : >> >>> On 2019-05-14 15:42, Adam Thompson wrote: >>> OK, I'm pretty sure this is a dumb question, but... >>> Does relayd work properly, or at all with pf disabled? (in >6.5-RELEASE) >> >> >> I have partially answered my own question. That last message was >posted prematurely, in more than one way, sorry! >> >> 1. the relayd.conf in the previous message was copied-and-pasted from >the wrong window, in mid-edit. >> >> 2. relayd(8) does not work with pf(4) disabled. I'm unclear if this >is a bug, or by design. With pf disabled, it outputs: >> root@rt:~# relayd -dv >> startup >> relayd: pfe: pf is disabled >> parent: proc_open: imsg_flush: Broken pipe >> ca exiting, pid 37187 >> ca exiting, pid 79962 >> ca exiting, pid 95113 >> root@rt:~# hce exiting, pid 91576 >> relay exiting, pid 26432 >> relay exiting, pid 6966 >> relay exiting, pid 50166 >> >> The message "pfe: pf is disabled" looks like an informational message >to me, I'm not using any pf features, so it shouldn't matter... but it >very much does matter, and relayd exits shortly after starting if pf is >disabled. >> >> Pinging @reyk - is this a bug or deliberate? >> > >It’s a historical reason because redirects existed first. And most >OpenBSD systems keep pf enabled by default. > >But you’re right; it should be easy to fix. > >Reyk -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: relayd without pf?
On 2019-05-14 15:42, Adam Thompson wrote: OK, I'm pretty sure this is a dumb question, but... Does relayd work properly, or at all with pf disabled? (in 6.5-RELEASE) I have partially answered my own question. That last message was posted prematurely, in more than one way, sorry! 1. the relayd.conf in the previous message was copied-and-pasted from the wrong window, in mid-edit. 2. relayd(8) does not work with pf(4) disabled. I'm unclear if this is a bug, or by design. With pf disabled, it outputs: root@rt:~# relayd -dv startup relayd: pfe: pf is disabled parent: proc_open: imsg_flush: Broken pipe ca exiting, pid 37187 ca exiting, pid 79962 ca exiting, pid 95113 root@rt:~# hce exiting, pid 91576 relay exiting, pid 26432 relay exiting, pid 6966 relay exiting, pid 50166 The message "pfe: pf is disabled" looks like an informational message to me, I'm not using any pf features, so it shouldn't matter... but it very much does matter, and relayd exits shortly after starting if pf is disabled. Pinging @reyk - is this a bug or deliberate? -Adam
relayd without pf?
OK, I'm pretty sure this is a dumb question, but...
Does relayd work properly, or at all with pf disabled? (in 6.5-RELEASE)
It looks like it should as long as I use "relay" instead of "redirect",
but I'm having trouble, and don't want to keep banging my head against a
wall if it's something this simple.
Thanks,
-Adam
--begin relayd.conf--
http protocol rtproxy {
pass quick
}
relay rt4 {
listen on 0.0.0.0 port 80
protocol rtproxy
forward to 127.0.0.1 port 8080
}
relay rt6 {
listen on :: port 80
protocol rtproxy
forward to ::1 port 8080
}
--end relayd.conf--
Re: post-6.5-upgrade bgpd(8) problem
On 2019-05-09 13:53, Sebastian Benoit wrote: bgpctl sh rib neigh out for all neighbors. All empty. Also look at bgpctl sh rib best Completely empty. if any routes are actually selected - maybe the "nexthop qualify via default" isnt working. I see two things... 1) when run as "bgpd -dv" I get repeated notifications about the same next-hops, dunno if that's normal or not. And 2) from bgpd.conf(5): route-collector (yes|no) If set to yes, the route selection process is turned off. The default is no. and I have it set to yes, since this is supposed to behave like a route collector. Granted, with a single source of routes at the moment, I could turn that off... let's see what happens when I do: Yup. That behaviour has definitely changed, somehow - taking a not-so-wild guess, it's likely _somehow_ related to claudio@'s introduction of Adj-Rib-Out but I'm not enough of a C programmer (or kernel routing expert) to say for sure. For now, commenting out the "route-collector yes" line in bgpd.conf will work, but there's a (for me) minor regression. I have no idea which way the code is supposed to behave, so can't tell if this is a bug or a bugfix! Based on CVS logs, it's probably a change introduced in rde.c after v1.442. -Adam
post-6.5-upgrade bgpd(8) problem
I've upgraded my looking glass from 6.4 to 6.5, and an experiencing an
unexpected problem - routes learned from one (iBGP) peer are not being
automatically exported to other (eBGP) peers.
I did not change /etc/bgpd.conf, but behaviour seems to have changed
nonetheless. The upgrade from 6.4 to 6.5 appeared smooth otherwise,
nothing to suggest subtle breakage under the hood.
As you can see below, this bgpd.conf is almost so simple it *can't* have
problems. Apparently "almost" being the operative word.
Under 6.4, this behaved as though "export none" only applied to the
first group. Under 6.5, it behaves as though "export none" is a global
setting.
Under 6.5, bgpctl show produces:
root@bgpmirror:~# bgpctl sh
Neighbor ASMsgRcvdMsgSent OutQ
Up/Down State/PrfRcvd
Hermes IPv4 16796 128773 85 0
00:41:40 753748
Hermes IPv6 16796 29727 85 0
00:41:40 68228
MBNOG IPv4 65204 97 85 0
00:41:40 0
MBNOG IPv6 65204 97 85 0
00:41:40 0
BGPMon.io IPv4 6447 0 21 0 Never
Active
isolario.it IPv465517 86 85 0
00:41:39 0
isolario.it IPv665517 86 85 0
00:41:39 0
and the operator of the MBNOG route collector confirms that I stopped
sending him a full routing table at the same time I did the OS upgrade.
Any ideas? What other information would help diagnose this problem?
Thanks,
-Adam
Dmesg & bgpd.conf:
https://gist.github.com/athompso/e334d8621ce458925e25bb44b8068341
bgpd.conf, duplicated here for convenience:
===BOF===
route-collector yes
socket "/var/www/run/bgpd.rsock" restricted # for bgplg
# settings
nexthop qualify via default
fib-update no
dump table-v2 "/var/www/htdocs/bgplg/mrt/rib-dump.mrt" 3600
dump updates in "/var/www/htdocs/bgplg/mrt/updates-in-%H%M" 300
dump all in "/var/www/htdocs/bgplg/mrt/all-in-%H%M" 300
# myself
AS X
router-id X.X.X.X
# neighbors
group hermes {
enforce local-as no
enforce neighbor-as no
export none
neighbor X.X.X.X {
remote-as X
descr "Hermes IPv4"
}
neighbor X:X:X:X::X {
remote-as X
descr "Hermes IPv6"
}
}
group bgpresearch {
multihop 32
enforce local-as no
enforce neighbor-as no
neighbor 192.160.102.196 {
remote-as 65204
descr "MBNOG IPv4"
}
neighbor 2620:132:3003:300::196 {
remote-as 65204
descr "MBNOG IPv6"
}
neighbor 129.82.138.6 {
remote-as 6447
descr "BGPMon.io IPv4"
}
neighbor 146.48.78.12 {
remote-as 65517
descr "isolario.it IPv4"
}
neighbor 2a00:1620:c0:4e:146:48:78:12 {
remote-as 65517
descr "isolario.it IPv6"
}
}
# policies
allow quick from group hermes
allow quick to group bgpresearch
===EOF===
(if you want to see the unredacted version of bgpd.conf, ask and I'll
email it directly to you, I just don't want internal addresses in the
public archive.)
Re: User who invoke doas
On Thu, May 2, 2019 at 20:17, Nick Holland wrote: > On 5/1/19 10:28 PM, Adam Steen wrote: >> Hi >> >> In a shell script invoked by doas, is it possible to find which user >> invoke the script? my search a the moment has come up empty. > > most likely place would be an environment variable, right? > > So ... > > $ whoami > nick > > $ doas -s > > # whoami > root > > # env |grep nick > LOGNAME=nick > HOME=/home/nick > MAIL=/var/mail/nick > > PATH=/home/nick/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R/bin:/usr/local/bin:/usr/local/sbin:/usr/games:. > USER=nick > > # echo "I started out as $LOGNAME" > I started out as nick > > 'dar ya go. > > Nick. Awesome thanks Nick!
User who invoke doas
Hi In a shell script invoked by doas, is it possible to find which user invoke the script? my search a the moment has come up empty. Cheers Adam
Re: How to restrict ip to access a directory in OpenBSD's httpd
On 2019-04-03 11:30, Stuart Henderson wrote: On 2019-04-03, =?utf-8?B?RnVuZw==?= wrote: apache support somthing like Order Allow,Deny Allow from all Deny from 1.2.3.4 How to achieve in OpenBSD's httpd? We are using OpenBSD 6.4. There is no built-in simple way. It can be done by having httpd listen on two different ports, one allowing access to this directory, the other denying access, and using a PF rdr-to rule to send traffic to the "allow access" port if it has the correct source IP address. But this is a bit of a mess. I vaguely recall hearing someone (possibly Reyk, several years ago?) mention that relayd can handle access control for httpd, if httpd is listening only on loopback. This seems like overkill, but does fit the "UNIX philosophy" of doing one thing well. I'm not at all sure it was Reyk, and I'm sure not 100% confident of this solution, but a quick glance at the man pages suggests it's not totally insane, either. -Adam
Unabled to build Xenocara
Hi All I am trying to update my system from the latest snapshot (success) and then rebuild everything from source (done many times before). following release(8), i have been able to build the kernel and base, but not Xenocara, i get the following error. checking whether libxcb was compiled against xcb-proto >= 1.6... checking for gawk... (cached) awk no configure: error: libxcb was compiled against xcb-proto ; it needs to be compiled against version 1.6 or higher *** Error 1 in lib/xcb-util (/usr/X11R6/share/mk/bsd.xorg.mk:158 'config.status') *** Error 1 in lib/xcb-util (/usr/X11R6/share/mk/bsd.xorg.mk:196 'build') *** Error 1 in lib (:48 'build') *** Error 1 in . (:48 'realbuild') *** Error 1 in . (Makefile:38 'do-build') *** Error 1 in /usr/xenocara (Makefile:27 'build') Before my second build attempt i ensured /usr/xojb was empty and owned by build:wobj with mode 770, but still got the above error. any tips would be welcome. Cheers Adam
Re: Determining if a package is installed (regardless of version)
‐‐‐ Original Message ‐‐‐ On Wednesday, March 27, 2019 2:58 PM, Anton Lindqvist wrote: > On Wed, Mar 27, 2019 at 02:24:24AM +0000, Adam Steen wrote: > > > Hi All > > I need to determine if a package is installed, lets use autoconf as an > > example > > I can run "pkg_info -mqP" and get back list of packages, i.e. > > devel/autoconf/2.69 > > shells/bash > > sysutils/coreutils > > x11/dmenu > > x11/dstat > > x11/dwm > > . > > . > > . > > devel/git,-main > > devel/gmp,-main > > sysutils/firmware/intel > > sysutils/firmware/inteldrm > > . > > . > > . > > sysutils/firmware/uvideo > > sysutils/firmware/vmm > > directly comparing "devel/autoconf" with "devel/autoconf/2.69", is it > > possible to get pkg_info to report a package without any version or stem > > information? > > using https://man.openbsd.org/pkg_info i couldn't find anything that jumps > > out, i was hoping not to do any further post processing. > > Cheers > > Adam > > There could be multiple ways of achieving the same result but I often > use the following when scripting package installation: > > $ env PKG_PATH= pkg_info autoconf >/dev/null && echo installed Hi Anton I should have been more specific, my use case completes the check in two steps 1. find out whats installed, builds a list of packages 2. install whats not installed. I used autoconf as it is a problem package, git and gmp would also be packages of concerned, but shells/bash and sysutils/coreutils are not a problem, see the output above Cheers Adam
Determining if a package is installed (regardless of version)
Hi All I need to determine if a package is installed, lets use autoconf as an example I can run "pkg_info -mqP" and get back list of packages, i.e. devel/autoconf/2.69 shells/bash sysutils/coreutils x11/dmenu x11/dstat x11/dwm . . . devel/git,-main devel/gmp,-main sysutils/firmware/intel sysutils/firmware/inteldrm . . . sysutils/firmware/uvideo sysutils/firmware/vmm directly comparing "devel/autoconf" with "devel/autoconf/2.69", is it possible to get pkg_info to report a package without any version or stem information? using https://man.openbsd.org/pkg_info i couldn't find anything that jumps out, i was hoping not to do any further post processing. Cheers Adam
Re: security - preferred way to make check_access_file happy?
On 2019-02-25 11:14, Stuart Henderson wrote: On 2019/02/25 09:13, Adam Thompson wrote: > Use vipw to put 13 * in the password field > > From passwd(5) > [...] > authentication, conventionally have 13 asterisks in the password field. Thank you! Now that I know what I'm looking for, I can see the relevant code in security(8), too. I wonder if there's a way for ports to do that for me while calling useradd? Another rabbit hole to go down. Thanks again, -Adam It normally does already. Do you have an unusual "password" line in /etc/usermgmt.conf? Nope. Ugh, although I said ports does this often in my experience, the only system/port I have right now where it's doing it is the RANCID package on that dedicated VM. I have two other VMs where I have manually created single-purpose userids without passwords that also complain (one for RT [not from ports], one for webhosting). So it could just be that package; at least I can't demonstrate any others right now. -Adam
Re: security - preferred way to make check_access_file happy?
Use vipw to put 13 * in the password field From passwd(5) [...] authentication, conventionally have 13 asterisks in the password field. Thank you! Now that I know what I'm looking for, I can see the relevant code in security(8), too. I wonder if there's a way for ports to do that for me while calling useradd? Another rabbit hole to go down. Thanks again, -Adam
Re: security - preferred way to make check_access_file happy?
Whoops... I'm getting the messages from 3 systems, all running 6.4-STABLE, with no local modifications, under both VMware and Openstack, using openup to keep systems updated. Dmesg available if anyone thinks it's relevant. -Adam On 2019-02-25 08:50, Adam Thompson wrote: Hi, I'm getting daily insecurity (i.e. security(8)) nags about userids that are off but still have a valid shell and access files. (Specifically, I'm getting the nag from check_access_files() in /usr/libexec/security.) Since ports (at least in my experience) regularly creates userids that will trigger this warning, what's the "best" way to disable the warning? I'm reluctant to mess with permissions on directories created by packages, but maybe that's the best way? Otherwise, it looks like I can disable the warning by setting a password on the userid in question. However, that leads to the question: what if I don't *want* a password on the account, because it's supposed to be a SFTP-only, public-key-authentication-only account, but still needs to be readable and needs a valid shell for various cron jobs to be happy? If I'm following the logic correctly, one of the warnings I'm getting is for ~/.ssh being readable on a userid with no password - exactly the scenario I just mentioned. But AFAIK they can't login if I take away S_IRUSR on ~/.ssh? The most distasteful option is to hack /usr/libexec/security to ignore certain userids, but ... it's there for a reason. The cleanest example I have right now from ports is _rancid, created by the rancid package, and triggered by the existence of ~_rancid/.ssh with S_IRUSR (u+r) permissions. Suggestions / advice? Thanks, -Adam
security - preferred way to make check_access_file happy?
Hi, I'm getting daily insecurity (i.e. security(8)) nags about userids that are off but still have a valid shell and access files. (Specifically, I'm getting the nag from check_access_files() in /usr/libexec/security.) Since ports (at least in my experience) regularly creates userids that will trigger this warning, what's the "best" way to disable the warning? I'm reluctant to mess with permissions on directories created by packages, but maybe that's the best way? Otherwise, it looks like I can disable the warning by setting a password on the userid in question. However, that leads to the question: what if I don't *want* a password on the account, because it's supposed to be a SFTP-only, public-key-authentication-only account, but still needs to be readable and needs a valid shell for various cron jobs to be happy? If I'm following the logic correctly, one of the warnings I'm getting is for ~/.ssh being readable on a userid with no password - exactly the scenario I just mentioned. But AFAIK they can't login if I take away S_IRUSR on ~/.ssh? The most distasteful option is to hack /usr/libexec/security to ignore certain userids, but ... it's there for a reason. The cleanest example I have right now from ports is _rancid, created by the rancid package, and triggered by the existence of ~_rancid/.ssh with S_IRUSR (u+r) permissions. Suggestions / advice? Thanks, -Adam
cvsweb.openbsd.org - same as cvsweb in ports?
I know this has been asked before, but my google-fu cannot unearth any trace of it, so I have to ask again - sorry! What version of cvsweb does cvsweb.openbsd.org run? And where is that software available? It appears to not quite be the same as cvsweb in ports, so... ? Thanks, -Adam
Re: keeping track of MAC addresses
On 2019-02-14 02:01, mailingli...@dotbit.ro wrote: I would like to keep tabs on the MAC/IP addresses in my secure net. I do know how to do this, but keeping track of ethernet MAC addresses seems quite cumbersome in OpenBSD, not that it is more convenient in any other general purpose operating system but many interfaces for ex. routers make it easy to manage, especially MAC filtering. Perhaps look at the "arpwatch" package in ports, which may be applicable. But... you know that both ARP and MAC addresses can be trivially spoofed, right? Just using /etc/ethers instead of ARP does *not* make your network secure. Some "intelligent" switches do ARP sniffing to populate their internal hardware FIBs. (Yes, that's a dumb idea. Switch vendors still do it.) Disabling ARP on your hosts is... not generally a good idea. PS: after running ifconfig em0 -arp my Allied Telesis AT-GS950-16 managed switch took the link down and refuses to bring it back up on the same port without a reset. Other ports work fine. I won't say this is impossible, but it seems unlikely. I think it's more likely the lack of ARP traffic on the port caused the switch to do something "interesting" with IP traffic destined for this host. Or maybe something else triggered storm-prevention features in the switch? Running an ifconfig(8) command should not be able to persistently shut down a switch port in any network environment. Did you observe the link lights on the NIC and switch actually turn off and stay off? As I have already mentioned I can manage by myself, but it seems to me that this is something that a lot of people would want. Not so much, AFAIK. Disabling core IP protocols usually generates more problems than it solves. Let us know how disabling/blocking ICMPv6 works out for you... ;-) [Hint: that's a trick question. You can't run IPv6 without ICMPv6.] You could filter on MAC addresses instead of restricting ARP: https://www.openbsd.org/faq/pf/tagging.html#ethernet That requires using bridge(4) which apparently is on its way out, and I don't know if the replacement (switch(4)) supports filtering packets based on MAC address or not - it's OpenFlow-compliant, so there has to be a way, but it may or may not be easily accessible from inside OpenBSD. You may also want to assign new MAC addresses to your hosts, both to eliminate the need to gather the MACs, and to simplify maintenance (e.g. the labour involved in replacing a NIC on a server or a motherboard is O(n^2) with hardware-bound MAC addresses in your setup, instead of O(1)). There are special LAAs (Locally-Assigned Addresses) that you can use for this. OpenBSD supports setting a locally-assigned MAC address with ifconfig(8) "lladdr" option. Good luck on your strange quest, -Adam
Re: PPPoE vlan issue 6.4
To follow up in case anyone has similar issues in the future I have now got this working. It appears I had several issues. 1) ISP documentation stating to use VLAN2 This appears to be incorrect for my ISP. I had vlan2 set up on my DD-WRT router, when doing a TCP dump on the router I could see PPPoE traffic over vlan2 however when I plugged the router into another machine to tcpdump on the other end the VLAN was being stripped. This was what initially was misleading me. Disabling vlan2 on my setup for PPPoE resolved the issue where I was not getting any PADO responses from the PADI packets. 2) No IPv6 configured on the PPPoE interface During the PPPoE negotiation, my ISP sends an IPv6 address. This causes the PPP implementation to try and open an IPv6 interface which does not exist: "pppoe0: ipv6cp_open(): no IPv6 interface". This then results in OpenBSD sending a disconnect packet "pppoe0: lcp close(opened)" which then cancels the whole PPPoE initialization as the remote receives a disconnect. I've only read the PPPoE spec enough to debug my issue but I'm not sure a disconnect should be sent at this stage anyway as it prevents getting to the IPv4 address negotiation. To resolve the no IPv6 "ipv6cp_open(): no IPv6 interface" issue I needed to add an IPv6 statement to my /etc/hostname.pppoe0 file 3) IPv4 address not agreed error "ipcp parse opt values: address 10.20.21.253 [not agreed] send conf-nak" This looked strange, in my PPPoE config I had "inet 0.0.0.0 255.255.255.255" which means the interface should accept any address given. I then tried looking at the "sys/net/if_pppoe.c" and tracing back from there. Eventually, I discovered I had a subtle config issue in my /etc/hostname.pppoe file, mtu and llprio where on new lines: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev em0 authproto pap \ authname 'username' authkey 'password' mtu 1492 llprio 1 dest 0.0.0.1 inet6 eui64 !/sbin/route add default -ifp pppoe0 0.0.0.1 !/sbin/route add ::/0 -ifp pppoe0 fe80::%pppoe0 Changing to the below resolved the issue: inet 0.0.0.0 255.255.255.255 NONE mtu 1492 llprio 1 \ pppoedev em0 authproto pap \ authname 'username' authkey 'password' dest 0.0.0.1 inet6 eui64 !/sbin/route add default -ifp pppoe0 0.0.0.1 !/sbin/route add ::/0 -ifp pppoe0 fe80::%pppoe0 Finally I had an active PPPoE connection. Hope this helps anyone in the future. -- Adam Evans On Sun, 10 Feb 2019, at 16:51, Adam Evans wrote: > Some more debugging, a lot further but still no success. > > I attached the DD-WRT modem directly to a computer to capture the PADI > packets. > > Capturing from the DD-WRT modem directly, PADI packets look like the below: > > 22:15:54.329145 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype > 802.1Q (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI > [Service-Name] [Host-Uniq 0xEE72] > 0x: 0002 8863 1109 000c 0101 > 0103 ...c > 0x0010: 0004 ee72 ...r.. > > > On the other end of the wire at the client the packets look like: > 12:13:05.995412 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype > PPPoE D (0x8863), length 60: PPPoE PADI [Service-Name] [Host-Uniq > 0x622A] > 0x: 1109 000c 0101 0103 0004 622a ..b* > 0x0010: > 0x0020: 838c 7a4d zM > > 12:13:20.277749 a0:63:91:47:81:07 (oui Unknown) > Broadcast, ethertype > PPPoE D (0x8863), length 60: PPPoE PADI [Service-Name] [Host-Uniq > 0xF02A] > 0x: 1109 000c 0101 0103 0004 f02a ...* > 0x0010: > 0x0020: e929 b08f ...).. > > From the above it looks like the PPPoE Discovery is not done over the > vlan as it get's stripped. > > I updated the /etc/hostname.pppoe0 config to change pppodev from vlan2 > to em0. I then plugged the device in to the bridged modem and brought up > the PPPoE interface which returned the below. I do not have IPv6 setup > in my PPPoE config so it looks like the remote tries to send me a IPv6 > packet which causes OpenBSD to send a terminate session response. > > # ifconfig pppoe0 up > Feb 10 13:18:48 foo /bsd: pppoe0: lcp close(initial) > Feb 10 13:18:48 foo /bsd: pppoe0: lcp open(initial) > Feb 10 13:18:48 foo /bsd: pppoe0: lcp initial->starting > Feb 10 13:18:48 foo /bsd: pppoe0: phase establish > Feb 10 13:18:48 foo /bsd: pppoe0 (8863) state=1, session=0x0 output -> > ff:ff:ff:ff:ff:ff, len=18 > Feb 10 13:18:48 foo /bsd: pppo
Re: PPPoE vlan issue 6.4
google.com.(32) 16:30:08.340939 00:0d:b9:4f:74:98 4c:77:6d:2c:eb:14 8864 82: PPPoE-Session code Session, version 1, type 1, id 0xf7ba, length 62 IP 0.0.0.1.47174 > 192.168.2.1.53: 29988+ A? www.google.com.(32) 16:30:09.613257 4c:77:6d:2c:eb:14 00:0d:b9:4f:74:98 8864 60: PPPoE-Session code Session, version 1, type 1, id 0xf7ba, length 14 LCP Echo-Request Id=0x01: Magic-Number=403967986 Data=329b51bf 16:30:09.613283 00:0d:b9:4f:74:98 4c:77:6d:2c:eb:14 8864 34: PPPoE-Session code Session, version 1, type 1, id 0xf7ba, length 14 LCP Echo-Reply Id=0x01: Magic-Number=849039807 Data=329b51bf 16:30:18.353786 00:0d:b9:4f:74:98 4c:77:6d:2c:eb:14 8864 82: PPPoE-Session code Session, version 1, type 1, id 0xf7ba, length 62 IP 0.0.0.1.17812 > 192.168.2.1.53: 29988+ A? www.google.com.(32) 16:30:24.405493 00:0d:b9:4f:74:98 4c:77:6d:2c:eb:14 8864 30: PPPoE-Session code Session, version 1, type 1, id 0xf7ba, length 10 LCP Echo-Request Id=0x3f: Magic-Number=849039807 16:30:24.413557 4c:77:6d:2c:eb:14 00:0d:b9:4f:74:98 8864 60: PPPoE-Session code Session, version 1, type 1, id 0xf7ba, length 10 LCP Echo-Reply Id=0x3f: Magic-Number=403967986 16:30:29.644658 4c:77:6d:2c:eb:14 00:0d:b9:4f:74:98 8864 60: PPPoE-Session code Session, version 1, type 1, id 0xf7ba, length 14 LCP Echo-Request Id=0x02: Magic-Number=403967986 Data=329b51bf ... -- Adam Evans On Sat, 9 Feb 2019, at 17:51, Adam Evans wrote: > Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 > with Intel i210AT nics however I am having difficulties with PPPoE. I > can see the discovery PADI packets going out using tcpdump but do not > see any PADO response so PPPoE times out and retries sending the PADI > packets. > > More confusing is my Netgear R7000 running DD-WRT that I want to replace > with the APU handles PPPoE just fine and bizarrely the PADI packets look > the same however the packets from OpenBSD don't get a response but the > R7000 does. > > Using tcpdump the PADI message form OpenBSD looks like below: > > 15:21:47.340929 a0:63:91:47:81:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q > vid 2 pri 0 PPPoE-Discovery > code Initiation, version 1, type 1, id 0x, length 12 > tag Service-Name, length 0 > tag Host-Uniq, length 4 \210\352\235\232 > > From the router running DD-WRT we can see the PADI packet followed by > the response PADO: > > 01:14:57.164338 a0:63:91:47:81:07 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q > (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI > [Service-Name] [Host-Uniq 0x5544] > > 01:14:57.171736 78:da:6e:de:df:d4 > a0:63:91:47:81:07, ethertype 802.1Q > (0x8100), length 103: vlan 2, p 0, ethertype PPPoE D, PPPoE PADO > [Vendor-Specific "..AVC30861999"] [Service-Name] [Host-Uniq > 0x5544] [AC-Name "syd-gls-har-bras24"] [AC-Cookie "po.N? > f'..D27"] > > To me, the PADI packets look the same, I even spoofed the MAC on the > OpenBSD box so it looks like the DD-WRT router although this shouldn't > be necessary I just wanted to verify. > > Does anyone have any ideas? My ISP requires me to use vlan 2, the > packets look like they are using vlan 2. I also set priority to 0 to > match the dd-wrt router. I've also tried to disable pflog in case that > was blocking ingress with no luck. I'm out of ideas as the egress PADI > broadcasts look identical from both devices. Any help is appreciated. > > If config output: > > lo0: flags=8049 mtu 32768 > index 5 priority 0 llprio 3 > groups: lo > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet 127.0.0.1 netmask 0xff00 > em0: flags=8843 mtu 1492 > lladdr 00:0d:b9:4f:74:98 > index 1 priority 0 llprio 3 > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > status: active > em1: flags=8802 mtu 1500 > lladdr 00:0d:b9:4f:74:99 > index 2 priority 0 llprio 3 > media: Ethernet autoselect (none) > status: no carrier > em1: flags=8802 mtu 1500 > lladdr 00:0d:b9:4f:74:99 > index 2 priority 0 llprio 3 > media: Ethernet autoselect (none) > status: no carrier > em2: flags=8843 mtu 1500 > lladdr 00:0d:b9:4f:74:9a > index 3 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (none) > status: no carrier > inet 192.168.2.103 netmask 0xff00 broadcast 192.168.2.255 > enc0: flags=0<> > index 4 priority 0 llprio 3 > groups: enc > status: a
Re: PPPoE vlan issue 6.4
Sorry, a copy and paste error
Below is the ifconfig -A output, note I've updated llprio to 1 on the vlan
which now looks to send down the wire as prio=0 when testing on a client. Ref:
http://openbsd-archive.7691.n7.nabble.com/use-link0-on-vlan-4-to-force-the-vlan-priority-to-llprio-td339390.html.
With llprio=1 on the pppoe0 device I get the below
OpenBSD:
22:10:52.275405 00:0d:b9:4f:74:98 Broadcast 8100 36: 802.1Q vid 2 pri 1
PPPoE-Discovery
code Initiation, version 1, type 1, id 0x, length 12
tag Service-Name, length 0
tag Host-Uniq, length 4 \307\270\216T
: 000d b94f 7498 8100 0002 .Ot.
0010: 8863 1109 000c 0101 0103 0004 .c..
0020: c7b8 8e54...T
Imac client:
22:00:24.885745 00:0d:b9:4f:74:98 (oui Unknown) > Broadcast, ethertype 802.1Q
(0x8100), length 60: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name]
[Host-Uniq 0xC7B88E54]
0x: 1109 000c 0101 0103 0004 c7b8
0x0010: 8e54 .T..
0x0020: ..
In the morning I'll try doing a packet capture on the DD-WRT device that works
plugged in to another machine to grab it's PADI packets.
Ifconfig (note ethernet cable unpluged on em0 at the time):
lo0: flags=8049 mtu 32768
index 5 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff00
em0: flags=8843 mtu 1500
lladdr 00:0d:b9:4f:74:98
index 1 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
em1: flags=8802 mtu 1500
lladdr 00:0d:b9:4f:74:99
index 2 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
em2: flags=8843 mtu 1500
lladdr 00:0d:b9:4f:74:9a
index 3 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
enc0: flags=0<>
index 4 priority 0 llprio 3
groups: enc
status: active
pppoe0: flags=8851 mtu 1492
index 6 priority 0 llprio 1
dev: vlan2 state: PADI sent
sid: 0x0 PADI retries: 33 PADR retries: 0
sppp: phase establish authproto pap authname "redacted"
groups: pppoe egress
status: no carrier
inet 0.0.0.1 --> 0.0.0.0 netmask 0xff00
vlan2: flags=8843 mtu 1500
lladdr 00:0d:b9:4f:74:98
index 7 priority 0 llprio 1
encap: vnetid 2 parent em0
groups: vlan
media: Ethernet autoselect (none)
status: no carrier
pflog0: flags=141 mtu 33136
index 8 priority 0 llprio 3
groups: pflog
--
Adam Evans
On Sat, 9 Feb 2019, at 21:35, Sebastien Marie wrote:
> On Sat, Feb 09, 2019 at 05:51:27PM +1100, Adam Evans wrote:
> > Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 with
> > Intel i210AT nics however I am having difficulties with PPPoE. I can see
> > the discovery PADI packets going out using tcpdump but do not see any PADO
> > response so PPPoE times out and retries sending the PADI packets.
> >
> > More confusing is my Netgear R7000 running DD-WRT that I want to replace
> > with the APU handles PPPoE just fine and bizarrely the PADI packets look
> > the same however the packets from OpenBSD don't get a response but the
> > R7000 does.
> >
> >
> > If config output:
>
> the ifconfig output is a bit odd.
>
> > lo0: flags=8049 mtu 32768
> > index 5 priority 0 llprio 3
> > groups: lo
> > inet6 ::1 prefixlen 128
> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
> > inet 127.0.0.1 netmask 0xff00
> > em0: flags=8843 mtu 1492
> > lladdr 00:0d:b9:4f:74:98
> > index 1 priority 0 llprio 3
> > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
> > status: active
> > em1: flags=8802 mtu 1500
> > lladdr 00:0d:b9:4f:74:99
> > index 2 priority 0 llprio 3
> > media: Ethernet autoselect (none)
> > status: no carrier
> > em1: flags=8802 mtu 1500
> > lladdr 00:0d:b9:4f:74:99
> > index 2 priority 0 llprio 3
> > media: Ethernet autoselect (none)
> > status: no carrier
>
> em1 is listed twice
>
> > em2: flags=8843 mtu 1500
> > lladdr 00:0d:b9:4f:74:9a
> > index 3 priority 0 llprio 3
> > groups: egress
> > media: Ethernet autoselect (none)
> > status: no carrier
> > inet 192.168.2.103 netmask 0xfff
Re: PPPoE vlan issue 6.4
Thanks for the suggestion of plugging it into another machine to do a packet dump. There's a miss-match on the priority from what OpenBSD is reporting to what the client sees on the other end. OpenBSD priority=0, client has priority=1. OpenBSD: 21:01:37.959968 00:0d:b9:4f:74:98 Broadcast 8100 36: 802.1Q vid 2 pri 0 PPPoE-Discovery code Initiation, version 1, type 1, id 0x, length 12 tag Service-Name, length 0 tag Host-Uniq, length 4 \215\205\320] : 000d b94f 7498 8100 2002 .Ot... . 0010: 8863 1109 000c 0101 0103 0004 .c.. 0020: 8d85 d05d...] On the client (IMac) 21:01:40.169419 00:0d:b9:4f:74:98 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 60: vlan 2, p 1, ethertype PPPoE D, PPPoE PADI [Service-Name] [Host-Uniq 0x8D85D05D] 0x: 1109 000c 0101 0103 0004 8d85 0x0010: d05d .].. 0x0020: .. This looks to be wrong? The client (directly connected imac) should not be seeing a priority of 1? It's strange on the OpenBSD side it has a priority of one on the packet dump unless it's modified further along? Also I'm not sure where what looks to be padding comes from, if that is on the openbsd side or the mac side? This is my first time using OpenBSD but looking through the changelogs the llprio set on the interface should be correctly setting the priority? The tcpdump on the OpenBSD side looks to support that. Re the modem, I have a ISP provided modem which is locked down like ISP's do so I do not have access to set vlans on that manually. I have been using it in bridge mode with DD-WRT for about 2 years and DD-WRT had the WAN port set to vlan 2. -- Adam Evans On Sat, 9 Feb 2019, at 20:33, Stuart Henderson wrote: > On 2019-02-09, Adam Evans wrote: > > Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 with > > Intel i210AT nics however I am having difficulties with PPPoE. I can see > > the discovery PADI packets going out using tcpdump but do not see any PADO > > response so PPPoE times out and retries sending the PADI packets. > > > > More confusing is my Netgear R7000 running DD-WRT that I want to replace > > with the APU handles PPPoE just fine and bizarrely the PADI packets look > > the same however the packets from OpenBSD don't get a response but the > > R7000 does. > > > > Using tcpdump the PADI message form OpenBSD looks like below: > > > > 15:21:47.340929 a0:63:91:47:81:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid > > 2 pri 0 PPPoE-Discovery > > code Initiation, version 1, type 1, id 0x, length 12 > > tag Service-Name, length 0 > > tag Host-Uniq, length 4 \210\352\235\232 > > > > From the router running DD-WRT we can see the PADI packet followed by the > > response PADO: > > > > 01:14:57.164338 a0:63:91:47:81:07 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q > > (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI > > [Service-Name] [Host-Uniq 0x5544] > > > > 01:14:57.171736 78:da:6e:de:df:d4 > a0:63:91:47:81:07, ethertype 802.1Q > > (0x8100), length 103: vlan 2, p 0, ethertype PPPoE D, PPPoE PADO > > [Vendor-Specific "..AVC30861999"] [Service-Name] [Host-Uniq > > 0x5544] [AC-Name "syd-gls-har-bras24"] [AC-Cookie "po.N?f'..D27"] > > > > To me, the PADI packets look the same, I even spoofed the MAC on the > > OpenBSD box so it looks like the DD-WRT router although this shouldn't be > > necessary I just wanted to verify. > > Can you get a more complete dump? (e.g. tcpdump -s1500 -X -e -i em0/eth0) > > Can you get a dump of the PADI from another machine plugged into em0 to check > that it actually makes it onto the wire with the expected tag/prio?? > > > em0: flags=8843 mtu 1492 > > I don't expect it to make a difference this early in the negotiation but > em0 should be mtu 1500, you'll run into problems later with 1492. > > FWIW normally I do the vlan handling in the modem rather than on the router > and pppoe setup is usually straightforward, though it should work either way. > >
PPPoE vlan issue 6.4
Hi, i'm trying to set up an OpenBSD router (6.4) on a PcEngines APU2D4 with Intel i210AT nics however I am having difficulties with PPPoE. I can see the discovery PADI packets going out using tcpdump but do not see any PADO response so PPPoE times out and retries sending the PADI packets. More confusing is my Netgear R7000 running DD-WRT that I want to replace with the APU handles PPPoE just fine and bizarrely the PADI packets look the same however the packets from OpenBSD don't get a response but the R7000 does. Using tcpdump the PADI message form OpenBSD looks like below: 15:21:47.340929 a0:63:91:47:81:07 ff:ff:ff:ff:ff:ff 8100 36: 802.1Q vid 2 pri 0 PPPoE-Discovery code Initiation, version 1, type 1, id 0x, length 12 tag Service-Name, length 0 tag Host-Uniq, length 4 \210\352\235\232 >From the router running DD-WRT we can see the PADI packet followed by the >response PADO: 01:14:57.164338 a0:63:91:47:81:07 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 36: vlan 2, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Host-Uniq 0x5544] 01:14:57.171736 78:da:6e:de:df:d4 > a0:63:91:47:81:07, ethertype 802.1Q (0x8100), length 103: vlan 2, p 0, ethertype PPPoE D, PPPoE PADO [Vendor-Specific "..AVC30861999"] [Service-Name] [Host-Uniq 0x5544] [AC-Name "syd-gls-har-bras24"] [AC-Cookie "po.N?f'..D27"] To me, the PADI packets look the same, I even spoofed the MAC on the OpenBSD box so it looks like the DD-WRT router although this shouldn't be necessary I just wanted to verify. Does anyone have any ideas? My ISP requires me to use vlan 2, the packets look like they are using vlan 2. I also set priority to 0 to match the dd-wrt router. I've also tried to disable pflog in case that was blocking ingress with no luck. I'm out of ideas as the egress PADI broadcasts look identical from both devices. Any help is appreciated. If config output: lo0: flags=8049 mtu 32768 index 5 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 em0: flags=8843 mtu 1492 lladdr 00:0d:b9:4f:74:98 index 1 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active em1: flags=8802 mtu 1500 lladdr 00:0d:b9:4f:74:99 index 2 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier em1: flags=8802 mtu 1500 lladdr 00:0d:b9:4f:74:99 index 2 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier em2: flags=8843 mtu 1500 lladdr 00:0d:b9:4f:74:9a index 3 priority 0 llprio 3 groups: egress media: Ethernet autoselect (none) status: no carrier inet 192.168.2.103 netmask 0xff00 broadcast 192.168.2.255 enc0: flags=0<> index 4 priority 0 llprio 3 groups: enc status: active pflog0: flags=141 mtu 33136 index 6 priority 0 llprio 3 groups: pflog pppoe0: flags=8851 mtu 1492 index 7 priority 0 llprio 0 dev: vlan2 state: PADI sent sid: 0x0 PADI retries: 10 PADR retries: 0 sppp: phase establish authproto pap authname "b8nfv2em" groups: pppoe status: no carrier inet 0.0.0.1 --> 0.0.0.0 netmask 0xff00 vlan2: flags=8843 mtu 1492 lladdr 00:0d:b9:4f:74:98 index 8 priority 0 llprio Config files: ## /etc/hostname.em0: mtu 1492 up ## /etc/hostname.vlan2: vnetid 2 parent em0 llprio 0 mtu 1492 up ## /etc/hostname.pppoe0: inet 0.0.0.0 255.255.255.255 NONE \ pppoedev vlan2 authproto pap \ authname 'redacted' authkey 'redacted' up mtu 1492 llprio 0 dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 -- Adam Evans
Re: purpose of bgpd.conf dump "timeout" parameter?
Yes, that clarifies it, thank you. I will attempt to explain that better and provide patch for bgpd.conf.5 next week. May I suggest a future function for bgpctl/bgpd - creating an MRT dump on demand? Even if only able to run in the context of bgpd(8), I think it could be helpful. (Certainly it would be helpful to me. Which is probably obvious since I'm suggesting it...) Something else to tack onto the to-do list, I guess. Thanks, -Adam On February 8, 2019 5:23:24 PM CST, Claudio Jeker wrote: >On Fri, Feb 08, 2019 at 03:56:12PM -0600, Adam Thompson wrote: >> In bgpd.conf(5), for the "dump" directive there is an optional >"timeout" >> parameter. What is its purpose? I assume from the examples that >it's >> denominated in seconds... > >Yes it is. > >> my first guess was to time out on attempting to write to the dump >file, but >> that doesn't seem realistic. It looks like it's a cycle, i.e. the >dump file >> will be recreated every X seconds, but if so, why is it called >"timeout" and >> not "interval" ? > >Because naming is hard :) > >> I see in the source that MRT_MAX_TIMEOUT is set to 7200 - does this >mean >> that if I leave the parameter unset, the MRT file will be re-dumped >every 2 >> hrs? > >No, it just limits the poll timeout but it will only fire once the time >really ran out. > >> Yes, I'll produce a patch for the manpage if someone can explain what >the >> parameter is supposed to do / how it works. > >After timeout seconds the file is reopened (or maybe a new file is >opened >depending on the strftime expand of the filename). For all and update >dumps this just puts new messages into a new file. For table dumps it >will >issue a new dump. e.g. > dump table "/tmp/rib-dump-%H%M" 300 >will create a new table dump every 5 minutes. > >Hope that helps. >-- >:wq Claudio -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
purpose of bgpd.conf dump "timeout" parameter?
In bgpd.conf(5), for the "dump" directive there is an optional "timeout" parameter. What is its purpose? I assume from the examples that it's denominated in seconds... my first guess was to time out on attempting to write to the dump file, but that doesn't seem realistic. It looks like it's a cycle, i.e. the dump file will be recreated every X seconds, but if so, why is it called "timeout" and not "interval" ? I see in the source that MRT_MAX_TIMEOUT is set to 7200 - does this mean that if I leave the parameter unset, the MRT file will be re-dumped every 2 hrs? Yes, I'll produce a patch for the manpage if someone can explain what the parameter is supposed to do / how it works. Thanks, -Adam
Re: smtpd - help needed tranlsating to new virtual map syntax [FIXED]
On 2019-01-21 04:08, Gilles Chehade wrote: In this test case, my translations map had: What is a translation map ? There is no such thing in OpenSMTPD (as of today). A virtual map that happened to be called . You're feeding the virtual table with invalid values. Apparently, yes. Also, this is a recipient translation mechanism, similar to aliases, and not a sender rewriting mechanism which we do not have at this point. [...] virtual _now_ only works on recipients, not senders ? the virtual code hasn't changed, it works the way it always did. there is no way it could ever do what you're describing or attempting to do given that it doesn't operate at all anywhere near the message. there is no way it has ever parsed: This is all very surprising to hear. The existing system works (somehow). So I am apparently misunderstanding what is happening, because with the configuration as shown, telling the various broken email senders to use that box as their mailhost _somehow_ fixes the bogus From: headers and envelopes. Oh, this just occurred to me as I'm writing: I really hope I didn't switch to a different MTA on that system years ago, and then just forgot to check which MTA was actually running. If that's the case, I'm not going to bother posting an update, because I'll be busy banging my head on the wall and then hiding in shame. I'm not convinced the new smtpd.conf grammar improves anything at all, but I assume it must help someone or it wouldn't have changed... but I believe my use case got thrown out with the bathwater, so to speak. Oh, well. :-( This is bullshit. The grammar doesn't reduce the functional scope, it can only expand it. I'm taking your word for it - you will know far better than I do! What you are describing has never existed in smtpd, there's never been code to translate sender addresses and there's a good reason for that: Good reasons aside, I still need to accommodate other vendor's broken mail implementations, because I can't fix them. I know of multiple reasons source rewriting is a bad idea, in general, but I get paid to make stuff work, not just say that it's broken. it not considered doable before the grammar change... But sure, blame it on the grammar. I believed that the grammar change had rendered my use case impossible because was now limited to local delivery methods. Clearly I was wrong... and not even in the way I thought I might be wrong. I may sound a bit harsh, but starting a thread with "this is my last try or I'll switch" (as if it actually matters) My apologies - that was meant to sound more like "I have a plan B so if this isn't possible, that's OK but I've wasted so much time on this I'm kinda running out of time, please tell me if I should just stop now and switch". I know *exactly* how much OpenBSD devs care if I use their code or not! I do not want to be "that asshole", although it seems I've succeeded again - sorry. Thank you for taking the time to reply. Now I'm going to go check that mail server a 7,000,000th time, this time to see what MTA is actually *running*, not just *configured*. I'm not sure whether I want it to be such a blatant mistake on my part or not... if yes, this all makes sense but I'm an idiot, whereas if no, then WTF, how is it working at all? FWIW: I am much happier with OpenSMTPd than with other MTAs because of its forward-declarative configuration syntax. Thank you for your work on bringing a modern, lean, secure(-er) MTA into existence. -Adam
Re: smtpd - help needed tranlsating to new virtual map syntax
I found the "-T" (trace) flag to smtpd(8), and it gives me this, which AFAICT confirms my suspicions: [...] rule #2 matched: match from src allowed-hosts for any => translate lookup: lookup "athom...@athompso.net" as ALIAS in table static:translations -> 0 lookup: lookup "athompso" as ALIAS in table static:translations -> 0 lookup: lookup "@athompso.net" as ALIAS in table static:translations -> 0 lookup: lookup "@" as ALIAS in table static:translations -> 0 expand: lka_expand: no aliases for virtual mproc: lka -> pony : 53 IMSG_SMTP_EXPAND_RCPT expand: 0x154201b89018: clearing expand tree imsg: pony <- lka: IMSG_SMTP_EXPAND_RCPT (len=53) smtp: 0x1127a72e6000: >>> 524 5.2.4 Mailing list expansion problem [...] complete output attached below, I've changed to @old.athompso.net and @new.athompso.net during testing since the last email. On the sending side, from another host (listed in ), I'm running: swaks --to athom...@athompso.net --from athom...@old.athompso.net --server which faithfully reports the 5.2.4 error. I'm slightly disappointed, I still like OpenSMTPd's concise configuration syntax. Postfix could still rewrite source addresses last time I checked, I hope it's still there - I do NOT want to run sendmail, thank you very much. -Adam Smtpd(8) trace output including invocation: ===from here to end of message=== bhs# smtpd -d -T all -v -d debug: init ssl-tree debug: init ca-tree debug: init ssl-tree debug: using "fs" queue backend debug: using "ramqueue" scheduler backend debug: using "ram" stat backend info: OpenSMTPD 6.4.0 starting debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ca-tree debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: init ssl-tree debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "fs" queue backend debug: using "ram" stat backend setup_peer: klondike -> control[63932] fd=4 setup_peer: klondike -> pony express[40666] fd=5 setup_done: ca[35575] done debug: using "ram" stat backend setup_peer: control -> klondike[35575] fd=4 setup_peer: control -> lookup[49698] fd=5 setup_peer: control -> pony express[40666] fd=6 setup_peer: control -> queue[21502] fd=7 setup_peer: control -> scheduler[14152] fd=8 setup_done: control[63932] done debug: using "ram" stat backend setup_peer: lookup -> control[63932] fd=4 setup_peer: lookup -> pony express[40666] fd=5 setup_peer: lookup -> queue[21502] fd=6 setup_done: lka[49698] done debug: using "ram" stat backend setup_peer: pony express -> control[63932] fd=4 setup_peer: pony express -> klondike[35575] fd=5 setup_peer: pony express -> lookup[49698] fd=6 setup_peer: pony express -> queue[21502] fd=7 setup_done: pony[40666] done debug: using "ram" stat backend setup_peer: queue -> control[63932] fd=4 setup_peer: queue -> pony express[40666] fd=5 setup_peer: queue -> lookup[49698] fd=6 setup_peer: queue -> scheduler[14152] fd=7 setup_done: queue[21502] done debug: using "ramqueue" scheduler backend debug: using "ram" stat backend setup_peer: scheduler -> control[63932] fd=4 setup_peer: scheduler -> queue[21502] fd=5 setup_done: scheduler[14152] done smtpd: setup done mproc: parent -> control: enabled mproc: parent -> lka: enabled mproc: parent -> queue: enabled mproc: parent -> ca: enabled mproc: parent -> pony: enabled debug: parent_send_config_ruleset: reloading mproc: parent -> lka : 0 IMSG_CONF_START mproc: parent -> lka : 0 IMSG_CONF_END debug: parent_send_config: configuring pony process mproc: parent -> pony : 0 IMSG_CONF_START mproc: parent -> pony : 0 IMSG_CONF_END debug: parent_send_config: configuring ca process mproc: parent -> ca : 0 IMSG_CONF_START mproc: parent -> ca : 0 IMSG_CONF_END setup_proc: klondike done setup_proc: control done setup_proc: lookup done setup_proc: pony express done setup_proc: queue done setup_proc: scheduler done mproc: ca -> control: enabled debug: bounce warning after 4h mproc: ca -> parent: enabled mproc: ca -&g
Re: smtpd - help needed tranlsating to new virtual map syntax
As it turns out, no, that doesn't work.
Trying to fix up broken sender mail domain-parts only simply gets me a "5.2.4
Mailing list expansion problem" error, with no debug output to suggest why.
In this test case, my translations map had:
@bad.athompso.net @good.athompso.net
in it. Obviously, this is a test setup :).
Smtpd.conf itself consisted of:
listen on all received-auth
smtp max-message-size 100M
table translations file:/etc/mail/translations # ORIG->NEW
mappings
table allowed-hosts file:/etc/mail/allowed-hosts# Who can
connect? (bare IP addresses or CIDR subnets)
action translate lmtp "/var/run/lmtp.sock" virtual
# 1st pass on allowed rewrite mail
action forward forward-only
# and now it's not our problem anymore
match for any from local action forward # 2nd pass for
reinjected mail, this time just forward it
match for any from src action translate # inbound mail
- hand it to LMTP, translating as we go
A cursory glance at the source code (yikes, it's been a long time since I was a
programmer) suggests that virtual now only works on recipients, not senders.
Which is too bad for me, as that means I'll have to switch at least one box to
use Postfix.
I'm not convinced the new smtpd.conf grammar improves anything at all, but I
assume it must help someone or it wouldn't have changed... but I believe my use
case got thrown out with the bathwater, so to speak. Oh, well. :-(
(If anyone cares, the bad sender addresses are mostly alerts coming from older
Sun ALOMs and at least one Lexmark printer that also sends email with broken
From addresses.)
-Adam
-Original Message-
From: owner-m...@openbsd.org On Behalf Of Adam Thompson
Sent: Wednesday, January 16, 2019 8:26 AM
To: 'Edgar Pettijohn' ; misc@openbsd.org
Subject: Re: smtpd - help needed tranlsating to new virtual map syntax
As I said, I haven't tried anything yet as I don't want to break a working
system, and I don't have a good way to test this in parallel right now.
The manpage says "The local delivery methods support additional options: [...]
virtual" without specifying which delivery methods are "local". My assumption
was that only "mbox" and "mda" were local, as lmtp can, and often does, point
to another server.
Some brief experiments with a VM only got me syntax errors, so I didn't pursue
that very thoroughly before asking for clarification.
-Adam
-Original Message-
From: Edgar Pettijohn
Sent: Wednesday, January 16, 2019 8:12 AM
To: Adam Thompson ; misc@openbsd.org
Subject: Re: smtpd - help needed tranlsating to new virtual map syntax
It would be helpful if you show what you have tried.
Should be as simple as:
action "relay-01" lmtp /var/run/lmtp.sock virtual
match from src action "relay-01"
Edgar
On Jan 16, 2019 7:37 AM, Adam Thompson wrote:
>
> [Cross-posting here before I give up and switch to Postfix -Adam]
>
>
> I have an old instance that uses smtpd's virtual to rewrite *sender*
> addresses.
> Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see how
> to accomplish my goal any more - it looks impossible.
>
> I don't want to upgrade a working mail relay server to something that might
> be broken, so I'm seeking assistance first.
>
> The purpose of this system is purely to relay mail from internal,
> semi-broken-ish systems out to our Office365 tenant, but I need to clean up
> bogus MAIL FROM / "From:" headers first, lest they be flagged as spam.
>
> In general, I think I'm asking how to use virtual with the "relay"
> action in the new syntax - the manual tells me this is impossible!?
>
> Thanks,
> -Adam
>
>
> Old smtpd.conf:
>
> ===start===
> listen on 0.0.0.0
> listen on ::
> table aliases db:/etc/opensmtpd/aliases.db table vmap
> db:/etc/opensmtpd/vmap.db table localnets { 192.168.10.0/24,
> 192.168.100.0/24, 192.168.157.0/24, 192.168.158.0/24,
> 192.168.101.0/24, 10.158.0.0/16 } accept from local
> for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
> accept from source 192.168.158.63 for domain 192.168.158.63 virtual
> deliver to lmtp localhost:25 accept from source 192.168.100.63
> for domain 192.168.100.63 virtual deliver to lmtp localhost:25
> accept from source 192.168.158.63 for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
> remote.XXX.ca accept from source 192.168.100.63 for any
> relay via smtp://XXX-ca.mail.protection.outlook.com as sys
Re: smtpd - help needed tranlsating to new virtual map syntax
As I said, I haven't tried anything yet as I don't want to break a working
system, and I don't have a good way to test this in parallel right now.
The manpage says "The local delivery methods support additional options: [...]
virtual" without specifying which delivery methods are "local". My assumption
was that only "mbox" and "mda" were local, as lmtp can, and often does, point
to another server.
Some brief experiments with a VM only got me syntax errors, so I didn't pursue
that very thoroughly before asking for clarification.
-Adam
-Original Message-
From: Edgar Pettijohn
Sent: Wednesday, January 16, 2019 8:12 AM
To: Adam Thompson ; misc@openbsd.org
Subject: Re: smtpd - help needed tranlsating to new virtual map syntax
It would be helpful if you show what you have tried.
Should be as simple as:
action "relay-01" lmtp /var/run/lmtp.sock virtual
match from src action "relay-01"
Edgar
On Jan 16, 2019 7:37 AM, Adam Thompson wrote:
>
> [Cross-posting here before I give up and switch to Postfix -Adam]
>
>
> I have an old instance that uses smtpd's virtual to rewrite *sender*
> addresses.
> Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see how
> to accomplish my goal any more - it looks impossible.
>
> I don't want to upgrade a working mail relay server to something that might
> be broken, so I'm seeking assistance first.
>
> The purpose of this system is purely to relay mail from internal,
> semi-broken-ish systems out to our Office365 tenant, but I need to clean up
> bogus MAIL FROM / "From:" headers first, lest they be flagged as spam.
>
> In general, I think I'm asking how to use virtual with the "relay"
> action in the new syntax - the manual tells me this is impossible!?
>
> Thanks,
> -Adam
>
>
> Old smtpd.conf:
>
> ===start===
> listen on 0.0.0.0
> listen on ::
> table aliases db:/etc/opensmtpd/aliases.db table vmap
> db:/etc/opensmtpd/vmap.db table localnets { 192.168.10.0/24,
> 192.168.100.0/24, 192.168.157.0/24, 192.168.158.0/24,
> 192.168.101.0/24, 10.158.0.0/16 } accept from local
> for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
> accept from source 192.168.158.63 for domain 192.168.158.63 virtual
> deliver to lmtp localhost:25 accept from source 192.168.100.63
> for domain 192.168.100.63 virtual deliver to lmtp localhost:25
> accept from source 192.168.158.63 for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
> remote.XXX.ca accept from source 192.168.100.63 for any
> relay via smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca
> hostname remote.XXX.ca accept from source for any
>
> relay via smtp://XXX-ca.mail.protection.outlook.com hostname
> remote.XXX.ca ===end===
>
> old vmap:
>
> ===start===
> ilom-alert@192.168.100.63: sys...@xxx.ca
> sys...@xxx.ca: sys...@xxx.ca
> sys...@ad.xxx.ca: sys...@xxx.ca
> root@XXX.local: sys...@xxx.ca
> ===end===
>
>
smtpd - help needed tranlsating to new virtual map syntax
[Cross-posting here before I give up and switch to Postfix -Adam]
I have an old instance that uses smtpd's virtual to rewrite *sender*
addresses.
Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see how to
accomplish my goal any more - it looks impossible.
I don't want to upgrade a working mail relay server to something that might be
broken, so I'm seeking assistance first.
The purpose of this system is purely to relay mail from internal, semi-broken-ish systems
out to our Office365 tenant, but I need to clean up bogus MAIL FROM / "From:"
headers first, lest they be flagged as spam.
In general, I think I'm asking how to use virtual with the "relay" action
in the new syntax - the manual tells me this is impossible!?
Thanks,
-Adam
Old smtpd.conf:
===start===
listen on 0.0.0.0
listen on ::
table aliases db:/etc/opensmtpd/aliases.db
table vmap db:/etc/opensmtpd/vmap.db
table localnets { 192.168.10.0/24, 192.168.100.0/24, 192.168.157.0/24,
192.168.158.0/24, 192.168.101.0/24, 10.158.0.0/16 }
accept from local for anyrelay via
smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
accept from source 192.168.158.63 for domain 192.168.158.63 virtual
deliver to lmtp localhost:25
accept from source 192.168.100.63 for domain 192.168.100.63 virtual
deliver to lmtp localhost:25
accept from source 192.168.158.63 for anyrelay via smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
remote.XXX.ca
accept from source 192.168.100.63 for anyrelay via smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
remote.XXX.ca
accept from source for anyrelay via
smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
===end===
old vmap:
===start===
ilom-alert@192.168.100.63: sys...@xxx.ca
sys...@xxx.ca: sys...@xxx.ca
sys...@ad.xxx.ca: sys...@xxx.ca
root@XXX.local: sys...@xxx.ca
===end===
bgplg doesn't work with wildcard httpd servers
Running 6.4 (-stable, via openup/mtier).
I have bgpd(8) talking to my border router, acting as a route collector.
That part seems fine.
I now have httpd(8) configured trivially to run bgplg(8) (per the
bgplg(8) manpage) but it's not working, and I can't tell why. **EDIT:
yes, I can, see below**
httpd.conf:
===start===
server "*" {
listen on * port 80
location "/cgi-bin/*" {
fastcgi
root ""
}
}
===end===
On the client end, I get:
bgpmirror# wget -v http://localhost/cgi-bin/bgplg
--2019-01-11 10:12:05-- http://localhost/cgi-bin/bgplg
Resolving localhost (localhost)... 127.0.0.1, ::1
Connecting to localhost (localhost)|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 No headers, assuming
HTTP/0.9
Length: unspecified
Saving to: 'bgplg'
(it never completes until I kill it)
Ktrace'ing slowcgi and httpd in -d mode reveals that bgplg execve's
properly, loads, spits out "invalid character in input" and dies.
Slowcgi and/or httpd do not handle this... well, at all, really. That
error message also does not get logged anywhere nor is visible anywhere
except ktrace logs.
Looking at the bgplg source code, this means there's something funky in
its environment that it doesn't like. Ah. It looks like it's the "*"
in server_name, as passed in by slowcgi:
slowcgi: env[18], SERVER_NAME=*
Yup. That's the problem, all right: /usr/src/usr.bin/bgplg/bgplg.c:115
excludes '*'. But I want my looking glass to be accessible from at
least two different hostnames, and I really would prefer to not have to
define them all manually in httpd.conf(5).
The naive local fix is trivial (adding '*' to the strchr call in line
115), but what else might I be breaking or letting in? Clearly this is
supposed to ensure the environment is sanitized before continuing, but
is "*" forbidden because it's unsafe, or simply because it never
occurred to anyone?
Thoughts / suggestions ?
Thanks,
-Adam
Porting some software to OpenBSD
Hi All I have a question about string (printf) formatting. I have a variable 'uint64_t freq' which is printed with 'log(DEBUG, "Solo5: clock_init(): freq=%lu\n", freq);' but am getting the following error ' error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] freq); ^~~~ 1 error generated. ' The easy fix is to change the format to '%llu', but this brakes FreeBSD and Linux. Am i missing something or should i be investigating the log implementation? Cheers Adam
Re: vmm(4) update EPT to match mprotect in intial elf load. (Solo5 using vmm, doesn't involved vmd)
‐‐‐ Original Message ‐‐‐ On Thursday, December 13, 2018 9:36 AM, Mike Larkin wrote: > On Thu, Dec 13, 2018 at 12:41:10AM +0000, Adam Steen wrote: > > > Hi All > > The Solo5/Mirage tender is in the process of enforcing that guest executable > > code is not also writable (W^X), but it looks like vmm is not updating EPT > > to match the prot from mprotect(). > > further information > > https://github.com/Solo5/solo5/issues/303#issuecomment-446503933 > > copied here for completeness > > <-- quote --> > > @mato OpenBSD will not allow an mprotect call with both write and execute > > enabled, W^X has been enforced at OS level since September 2016. I initially > > hit this in porting efforts. > > @adamsteen I know that. What I don't know is, does this subsequent > > `mprotect()` > > for a PHDR with `PF_X | PF_R` set (i.e. `.text`) > > https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_elf.c#L215 > > called on the guest memory range initially set up at > > https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_openbsd.c#L117 > > have the intended effect on the underlying EPT mapping actually used by vmm > > to > > back that memory, i.e. disallowing `PROT_WRITE`. I'm guessing it does as > > otherwise the OpenBSD port would probably not work at all since the initial > > mapping does not include `PROT_EXEC`, but given that the FreeBSD vmm has a > > separate interface for this (VM_MMAP_MEMSEG) I'm not 100% sure. > > To confirm, could you build the branch at > > https://github.com/mato/solo5/tree/enforce-nox, manually run the `test_nox` > > case, and post the output? While you're at it, can you confirm that all the > > other new tests there pass? > > <-- end quote --> > > Is there some way i can ensure that vmm updates the EPT to match the prot > > from inital mprotect(). > > Cheers > > Adam > > There are two different maps maintained here. One is in vmd or whatever > userland equivalent you're using to set up Solo5. The other is the map > used by the EPT part in vmm. > > These are shared via uvm_share. I don't know how hard it would be to make > permission changes on one side of the map match the other automatically (nor > am I sure that even makes sense). > > What I could offer would be a new ioctl to set permissions on the EPT side. > Something like "vmm_mprotect_ept" or the like. Would that work? > > -ml Paraphrasing Martin Lucina, Something like "vmm_mprotect_ept" or the like, would work for the project, A nice to have feature of this would be to allow execute-only EPT mappings. see [1] Cheers Adam [1] https://github.com/Solo5/solo5/issues/303#issuecomment-446911276
vmm(4) update EPT to match mprotect in intial elf load. (Solo5 using vmm, doesn't involved vmd)
Hi All The Solo5/Mirage tender is in the process of enforcing that guest executable code is not also writable (W^X), but it looks like vmm is not updating EPT to match the prot from mprotect(). further information https://github.com/Solo5/solo5/issues/303#issuecomment-446503933 copied here for completeness <-- quote --> @mato OpenBSD will not allow an mprotect call with both write and execute enabled, W^X has been enforced at OS level since September 2016. I initially hit this in porting efforts. @adamsteen I know that. What I don't know is, does this subsequent `mprotect()` for a PHDR with `PF_X | PF_R` set (i.e. `.text`) https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_elf.c#L215 called on the guest memory range initially set up at https://github.com/mato/solo5/blob/enforce-nox/tenders/hvt/hvt_openbsd.c#L117 have the intended effect on the underlying EPT mapping actually used by vmm to back that memory, i.e. disallowing `PROT_WRITE`. I'm guessing it does as otherwise the OpenBSD port would probably not work at all since the initial mapping does not include `PROT_EXEC`, but given that the FreeBSD vmm has a separate interface for this (VM_MMAP_MEMSEG) I'm not 100% sure. To confirm, could you build the branch at https://github.com/mato/solo5/tree/enforce-nox, manually run the `test_nox` case, and post the output? While you're at it, can you confirm that all the other new tests there pass? <-- end quote --> Is there some way i can ensure that vmm updates the EPT to match the prot from inital mprotect(). Cheers Adam
Re: 6.4-release tset(1) really slow, what have I missed?
On 2018-12-02 22:12, Adam Thompson wrote: > I'm unsure if my test is valid, but I switched to i8254 (confirmed successful > via sysctl), and tset(1) continues to pause for an unnaturally long time. > But then I rebooted and re-tested the same sysctl vaules, and this time > tset(1) took 1sec, as expected. WTF... > > Well, putting that into sysctl.conf seems to be a reasonable workaround for > now. I also enabled timestepwarnings, and they are occurring, although I > don't yet know how often. I understand why I got inconsistent results... I had two different hosts open in the two windows I was using. Thank goodness they were both just personal systems! I'll re-test tomorrow morning when I'm more awake! -Adam
Re: 6.4-release tset(1) really slow, what have I missed?
On 2018-12-02 20:50, Philip Guenther wrote:
> On Sun, Dec 2, 2018 at 2:15 PM Adam Thompson wrote:
>
>> I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
>> one thing there that's different from everywhere else I've used 6.4.
>>
>> tset(1) takes approximately 12-15 seconds to execute, (almost) every
>> time.
>>
>> On a DigitalOcean VPS running 6.3-STABLE (via openup) tset sensibly
>> takes about 1 or 2 seconds:
>> athom...@mail.athompso.net:~$ time tset -s
>> TERM=xterm;
>> 0m01.01s real 0m00.00s user 0m00.01s system
>> athom...@mail.athompso.net:~$ uname -r
>> 6.3
>>
>> On the OVH VPS running 6.4-STABLE (via openup), the same command takes
>> 15 seconds:
>> athom...@mail2.athompso.net:~$ time tset -s
>> TERM=xterm;
>> 0m15.19s real 0m00.00s user 0m00.01s system
>> athom...@mail2.athompso.net:~$ uname -r
>> 6.4
>>
>> That's from two SSH sessions from the same client with the same
>> parameters.
>>
>> I've captured ktrace(1) output, which shows tset(1) doing, well,
>> nothing:
>> ...
>> 57429/443422 tset 0.035908 CALL
>> kbind(0x7f7f7678,24,0xecf2201fc1aab9ca)
>> 57429/443422 tset 0.035933 RET kbind 0
>> 57429/443422 tset 0.035950 CALL
>> nanosleep(0x7f7f7760,0x7f7f7750)
>> 57429/443422 tset 0.035967 STRU struct timespec { 1 }
>> 57429/443422 tset 15.809238 STRU struct timespec { 0 }
>> 57429/443422 tset 15.809272 RET nanosleep 0
>> 57429/443422 tset 15.809303 CALL
>> kbind(0x7f7f76c8,24,0xecf2201fc1aab9ca)
>> 57429/443422 tset 15.809380 RET kbind 0
>> ...
>>
>> I don't think this is a bug in 6.4, it's clearly environment-specific...
>> but I have no idea what on earth could be causing it.
>
> It requested a sleep of 1 second and 15 seconds passed. That's a kernel
> timetracking issue, so the output of "sysctl kern.timecounter" would be a
> good place to start. Is this is an MP kernel using the CPU TSC, but on a VM
> where the virtual CPU's TSCs aren't in sync?
>
> Philip Guenther
Thanks for the pointer! I noticed, once, that the system clock was way
off, but I assumed that was one of the boots where I didn't have
networking at startup so ntpd(8) -s failed to operate as expected. Bad
kernel timekeeping would also produce that result, though.
Anyway:
athom...@mail2.athompso.net:~$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=acpitimer
kern.timecounter.choice=i8254(0) acpitimer0(1000) dummy(-100)
and it's an SP kernel running on one vCPU. No way of knowing what's
happening under the hood, other than that it's OpenStack Nova, which
IIRC means KVM virtualization. Note the lack of advertised TSC support.
I'm unsure if my test is valid, but I switched to i8254 (confirmed
successful via sysctl), and tset(1) continues to pause for an
unnaturally long time. But then I rebooted and re-tested the same
sysctl vaules, and this time tset(1) took 1sec, as expected. WTF...
Well, putting that into sysctl.conf seems to be a reasonable workaround
for now. I also enabled timestepwarnings, and they are occurring,
although I don't yet know how often.
Is this likely to be a big enough problem that I should ditch this VPS
platform for now?
dmesg output, to verify SP kernel with no TSC:
OpenBSD 6.4 (GENERIC) #1: Mon Nov 26 09:32:17 CET 2018
r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 4177379328 (3983MB)
avail mem = 4041621504 (3854MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6890 (10 entries)
bios0: vendor SeaBIOS version "2:1.10.2-58953eb7" date 04/01/2014
bios0: OpenStack Foundation OpenStack Nova
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC
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: Intel Core Processor (Haswell, no TSX, IBRS), 2394.81 MHz,
06-3c-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,ARAT,XSAVEOPT,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 1000MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
...etc...
Thanks,
-Adam
6.4-release tset(1) really slow, what have I missed?
I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
one thing there that's different from everywhere else I've used 6.4.
tset(1) takes approximately 12-15 seconds to execute, (almost) every
time.
On a DigitalOcean VPS running 6.3-STABLE (via openup) tset sensibly
takes about 1 or 2 seconds:
athom...@mail.athompso.net:~$ time tset -s
TERM=xterm;
0m01.01s real 0m00.00s user 0m00.01s system
athom...@mail.athompso.net:~$ uname -r
6.3
On the OVH VPS running 6.4-STABLE (via openup), the same command takes
15 seconds:
athom...@mail2.athompso.net:~$ time tset -s
TERM=xterm;
0m15.19s real 0m00.00s user 0m00.01s system
athom...@mail2.athompso.net:~$ uname -r
6.4
That's from two SSH sessions from the same client with the same
parameters.
I've captured ktrace(1) output, which shows tset(1) doing, well,
nothing:
...
57429/443422 tset 0.035908 CALL
kbind(0x7f7f7678,24,0xecf2201fc1aab9ca)
57429/443422 tset 0.035933 RET kbind 0
57429/443422 tset 0.035950 CALL
nanosleep(0x7f7f7760,0x7f7f7750)
57429/443422 tset 0.035967 STRU struct timespec { 1 }
57429/443422 tset 15.809238 STRU struct timespec { 0 }
57429/443422 tset 15.809272 RET nanosleep 0
57429/443422 tset 15.809303 CALL
kbind(0x7f7f76c8,24,0xecf2201fc1aab9ca)
57429/443422 tset 15.809380 RET kbind 0
...
I don't think this is a bug in 6.4, it's clearly environment-specific...
but I have no idea what on earth could be causing it.
(dmesg, etc. omitted in this first message, since it's so ridiculously
specific.)
Oh, and to make it even weirder, it doesn't ALWAYS happen. It ran
quickly twice earlier today, but never again.
Normally I'd say "it's DNS", and I thought it was due to the slow login
times, but ktrace(1) says otherwise.
Any ideas?
Thanks,
-Adam
Qsynth midi latency not low enough... what to do?
PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces ~1/4sec delay between keypress and sound. NARRATIVE: I finally got Qsynth working under Xfce (it freezes X under twm!) so I can control fluidsynth in a reasonably-obvious way... but I am now experiencing substantial latency. The good news is that it feels just like playing an old pneumatic or tracker organ, where there’s a ~0.25sec delay between keypress and sound. The bad news is that it feels just like playing an old pneumatic or tracker organ... I’m not a good enough musician to handle the roughly quarter-second delay when playing live. I know from many musicians that near-zero-latency from MIDI softsynths (even when using soundfonts) is possible... although no-one I know of uses OpenBSD. Is sndio(4) suitable for real-time(-ish) performance? Or do I need a (OS) platform that does ASIO or JACK? (I mostly play by ear so I'm targeting <<0.1sec latency.) If sndio core or umidi(4) support isn’t the problem, the only obvious thing to blame is FluidSynth... but the CPU in this laptop should be more than up to the task, and – again – I know this particular piece of software handles low-latency live performance in other configurations (i.e. on Linux, using JACK). I don't suspect Qsynth at the moment, as it only controls how fluidsynth launches, it doesn't put itself in the data path. Unsurprisingly, I’ve been unable to find any useful information on running this kind of setup under OpenBSD. But as mentioned before, I’m trying to avoid the (to me) insanity that is JACK. Dmesg follows, just in case anyone spots anything useful in there… Hardware setup, broadly: * Dell Latitude E6430 laptop - booting in EFI mode to work around a weird bootloader bug * onboard azalia(4) audio (for now) using onboard speakers (for now) * Roland A500PRO MIDI controller, connected via USB * M-audio Uno USB-MIDI, nothing connected to it yet * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected makes no difference) Advice / pointers gratefully accepted, including pointers to documentation or threads I may have missed. Thanks, -Adam Dmesg << __EOF__ (so to speak) OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018 r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8471482368 (8079MB) avail mem = 8205459456 (7825MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebf40 (101 entries) bios0: vendor Dell Inc. version "A21" date 05/08/2017 bios0: Dell Inc. Latitude E6430 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT HPET SSDT SSDT SSDT ASF! SLIC BGRT SSDT acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2193.29 MHz, 06-3a-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2192.89 MHz, 06-3a-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz, 2192.89 MHz, 06-3a-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Co
recommended h/w for fanless audio-out?
Hello, I’d like to use OpenBSD to build a MIDI synthesizer using SoundFonts, as the OpenBSD MIDI and audio subsystems are remarkably understandable and sane, compared to everything else out there today. � However, I’m having difficulty finding a combination of hardware that is known to be supported. (I tried this a few years ago, but was unhappy with the results due to the quality of the audio-out ports on the laptop I used.) � I’ve heard a fair bit here about USB audio not working very well, or at all, in -stable right now. I’m unsure if this only applies to XHCI ports or not? � Therefore, ideally, I’d like a fanless amd64 architecture system, that boots from SATA (not eMMC) with either onboard stereo++ audio (up to and including 7.1ch) *or* a PCI slot for a sound card. A laptop with really good audio-out would work, too, but I don’t know of any. If connecting USB audio to a RPi or BeagleBone Black works well, then I could try that, too. � I intend to use USB MIDI interfaces, as they appear to be supported and working fine (IIRC). � The problem is that, as I browse the list of embedded, fanless systems I can get from DigiKey, Mouser, et al., all the boards with audio have HD Audio Codecs that I cannot confirm work with OpenBSD, and I don’t know enough about how azalia(4) [et a.] works with random unsupported DACs to drop $250-$500 on something that may or may not work (i.e. the codec isn’t explicitly supported). � Can anyone make any recommendations for specific hardware that’s fanless and has working audio-out ports? � And/or if I’ve gone off completely in the wrong direction about USB audio, please tell me so. (Working multi-channel USB audio would made this a lot simpler/easier/cheaper.) � Thanks in advance, -Adam �
MirageOS on OpenBSD
Hi All As some of you know i have been working at making MirageOS work on OpenBSD, It now works. If you don't know what it is, please see [1], if you don't care, please stop reading. I have built and tested all applications, device-usage and tutorials in mirage-skeleton. You maybe asking how do i do this myself? The following script works from a fresh install of OpenBSD current (soon to be 6.4)and builds the 'static_website_tls' #!/bin/sh -e # Please ensure doas is setup for the current user # tweak the environment, so things can be a little cleaner PREFIX=$HOME/.local if [ ! -d "$PREFIX" ]; then mkdir $PREFIX fi export PATH=$PREFIX/bin:$PATH export AUTOCONF_VERSION=2.69 # required packages doas pkg_add autoconf%2.69 bash bzip2 curl git gmake gpatch gtar--\ ocaml pkgconf unzip-- xz # build opam # waiting on OPAM PR#3538 - https://github.com/ocaml/opam/pull/3538 ulimit -s 32768 git clone https://github.com/adamsteen/opam.git cd opam ./configure --prefix $PREFIX gmake lib-ext gmake gmake install cd .. # setup the 2.0.0 repository # there was an issue with the auto conversion process # opam-repo PR#12605 - https://github.com/ocaml/opam-repository/pull/12605 git clone https://github.com/ocaml/opam-repository.git cd opam-repository git checkout 2.0.0 cd .. # setup opam and mirage opam init --comp 4.06.1 -n default opam-repository eval $(opam env) opam install mirage -y # waiting on the next release of Solo5 opam pin add solo5-kernel-ukvm git://github.com/Solo5/solo5 -y # mirage-skeleton tutorials git clone https://github.com/mirage/mirage-skeleton.git cd mirage-skeleton/applications/static_website_tls mirage configure -t ukvm gmake depends gmake the script can also be viewed/downloaded from [2]. If you have a OpenBSD current machine, please test this and let me know how you go! Hopefully with time its should be as simple as doas pkg_add opam init opam install mirage -y mirage configure -t ukvm gmake depends gmake Cheers Adam [1] https://mirage.io/ [2] github: https://gist.github.com/adamsteen/6bdae8dc93d8f91f9eb6cf1de4b5 raw: https://gist.githubusercontent.com/adamsteen/6bdae8dc93d8f91f9eb6cf1de4b5/raw/3619c6f3e42756b11bb3788b2226dc3be67d7913/setup.sh
Re: OCaml/Opam and parsexp ( or num)
Sorry for the noise, this was a stack size problem, fixed with ulimit. Now to figure why the patch fails to apply with the ocaml patch. Cheers Adam ‐‐‐ Original Message ‐‐‐ On September 4, 2018 3:31 PM, Adam Steen wrote: > Hi All > > I am trying to install mirage[1] with opam install mirage but building > parsexp v0.11.0 fails with SEGV [2]. This is on an amd64/current machine. > > I am trying this with an OPAM 2 built from source. > > I tried with chrisz@ patch for ocaml 4.07 et al [3] but num fails to build > when the patches can not be applied, opam looks like it hangs, but then > eventually returns with a failure. > > #=== ERROR while compiling num.1.1 > # > These patches didn't apply at > /home/asteen/.opam/default/.opam-switch/build/num.1.1: > > - findlib-install.patch: "/usr/local/bin/gpatch -p1 -E -i > /home/asteen/.opam/log/processed-patch-32042-70a526" exited with code 1 > > Any tips on where to look into next would be appreciated? > > Cheers > Adam > > [1] https://mirage.io/ > [2] https://github.com/ocaml/opam-repository/issues/12559 > [3] https://marc.info/?l=openbsd-ports&m=153216412010547&w=2 >
OCaml/Opam and parsexp ( or num)
Hi All I am trying to install mirage[1] with opam install mirage but building parsexp v0.11.0 fails with SEGV [2]. This is on an amd64/current machine. I am trying this with an OPAM 2 built from source. I tried with chrisz@ patch for ocaml 4.07 et al [3] but num fails to build when the patches can not be applied, opam looks like it hangs, but then eventually returns with a failure. #=== ERROR while compiling num.1.1 # These patches didn't apply at /home/asteen/.opam/default/.opam-switch/build/num.1.1: - findlib-install.patch: "/usr/local/bin/gpatch -p1 -E -i /home/asteen/.opam/log/processed-patch-32042-70a526" exited with code 1 Any tips on where to look into next would be appreciated? Cheers Adam [1] https://mirage.io/ [2] https://github.com/ocaml/opam-repository/issues/12559 [3] https://marc.info/?l=openbsd-ports&m=153216412010547&w=2
iridium --enable-unveil and extensions
Hi all I think i must be missing something, i am unable to get extensions working in Iridium with "--enable-unveil". unveil.main has "~/.config rwc" and i thought extensions live under ".config/iridium/Default/Extensions" so thought maybe that should be enough, its not. as a hack i added "~/.config rwc" to all unveil files under /etc/iridium, but that didn't work. (they are removed now) Once i can figure out how to get an extension working, i would like to tighten in unveil so only it can work. The output to stdout/stderr didn't help, is there another log file? Cheers Adam
Re: Best way to serve files to Windows?
On 2018-07-18 09:35, Tom Smyth wrote: Hi John, You would need microsoft services for unix (SFU) for NFS connectivity FYI - so no-one goes haring off in the wrong direction. SFU is the server-side component, equivalent to running nfsd(8). On the client side, only certain editions of Windows can speak NFS: - Windows 10 *Enterprise* can mount remote NFS shares. - Windows 7 *Ultimate* can mount remote NFS shares. (No idea about Win8, sorry.) Win10Ent, at least, has flexible authentication options, but IIRC defaults to uid=0/gid=0 (gee, thanks). It prefers to use Kerberos security, which won't work with OpenBSD's NFS server. It's possible to make this work reasonably well, but it takes a fair bit of time. So, as everyone else said, you're better off running Samba on your OpenBSD system. Have fun. -Adam
Re: supported Audio card with SPDIF input
On 2018-07-24 17:54, Diana Eichert wrote: ok, answered my own question by grep'ng within /usr/share/man/man4, looks like azalia(4) systems. Was hoping for something usb attached but no such luck. On Tue, 24 Jul 2018, Diana Eichert wrote: I'm trying to connect to an audio system that only has SPDIF output. I looked at man pages but nothing obvious regarding supported audio devices with SPDIF input support. Anyone have recommendations? Or is it supported? Very broadly speaking, as long as the USB device conforms to the USB Audio Class spec, it doesn't matter whether it's got S/PDIF or Coax or 2xRCA or XLR - audio waveforms should still get transferred from PC to output. What I think you might lose is any sort of decent mixer control, although with S/PDIF I expect you might not really care about that? Caveat: I have not personally tried a USB-to-S/PDIF audio device, but I *have* read the specs and the datasheets. In theory, theory is the same as reality... Best-case, a USB SPDIF output device would a) conform to the USB Audio Device Class interface, and b) report that it has no adjustable mixers, so that on the software side, the mixer doesn't get confused. -Adam
Trying to enable dumpcore in Solo5 for OpenBSD's vmm
Hi I am trying to enable dumpcore in Solo5 for OpenBSD's vmm by porting ukvm_dumpcore_freebsd_x86_64.c [1]. I am able to get all the registers from vmm using "ioctl(env->vmd_fd, VMM_IOC_READREGS, &vrp)" but i don't have a prstatus_t structure to fill in. Does OpenBSD have a prstatus_t structure? if so which header file is it located in? or else what is the appropriate structure i should be using? Cheers Adam [1] https://github.com/Solo5/solo5/blob/a6030aa2403e5630507b86150f2ea80e637eb9c9/ukvm/ukvm_dumpcore_freebsd_x86_64.c
Re: Viewport for man.openbsd.org -- readability on phones
On 2018-05-19 02:59, justina colmena wrote: https://man.openbsd.org/mandoc.css That's the css. You style it how you like it. That's the whole point of it. And I agree. It's very readable on my phone. Original message From: Mihai Popescu Date: 5/18/18 11:04 PM (GMT-09:00) To: misc@openbsd.org Subject: Re: Viewport for man.openbsd.org -- readability on phones I don't understand what you are trying to say. I took and iPhone with iOS and Safari ( i think!) on it and pointed the browser to the current link of man pages [1]. All i can say is the layout is displayed on full display, not stretched. Text is fine, paragraphs are scaled ok, not even a simple problem. Font is fine. [1] https://man.openbsd.org/ Just to confirm, it also works and looks fine on my phone (is that "works phine"? ) which is running Chrome under Android 8.1. I can see why it would not look fine on an extremely low-res display, though: the margins could overwhelm the page, and the resultant wrapping would be very not-pretty. OTOH, *every* website will look bad on a phone that old. -Adam
Re: Virtualbox vs latest snapshot
On 2018-04-12 20:02, Nick Holland wrote: On 04/12/18 09:47, Consus wrote: On 08:28 Thu 12 Apr, Nick Holland wrote: Another "failure mode" of VirtualBox people should be aware of: I understand through good sources, Oracle monitors the IP addresses that it's downloaded from, and if they can trace it back to a commercial IP (i.e., not a home address), and if they see you download (or update) the "not for unrestricted free use" parts, their lawyers will contact you and send you a bill...and they really don't care about "for work" or "not for work related" uses. I'd really recommend removing this product from your computers. This won't stand in court. You sources are so high on crack it's not even funny. Think about it a moment, Using my real name, and a public, trackable identity, I just accused a very big company with lots of lawyers (and they know how to use them!) of something. If my facts are not in order, I could be in big trouble. My facts are in order. It's not about court. It's about threatening lots of companies and hoping a few pay up to avoid the cost of going to court -- which is considerable, win or lose. What you believe changes nothing. Their licenses are complicated, easy to use wrong, and they seem to care. I recommend against using their products for that reason. Nick. My tale of Oracle woe: My company got spanked by Oracle a couple of years ago because one of our developers was downloading multiple versions of the RDBMS, trying to find a version that would be happy with a binary database file we got from a client. Their License Enforcement dept. (it's part of the Sales division, which tells you something...) undertook a sneaky campaign of phoning all our staff asking them how they were satisfied with their Oracle products. They finally audited us, and - not for the products that dev was downloading, but for something else entirely - it turned out we were accidentally in violation of one of our licenses, as one sentence had changed somewhere in the ~20yrs we'd been using it to invalidate our use case. Since it was not intentional, and we were cooperating with them, and we are very small (~10 persons, at the time) they ONLY required a top-up payment roughly equal to 1 developer's annual salary. The threat of being sued out of existence, if we didn't cooperate, was made explicitly. We were, in my opinion, deliberately maneuvered into a non-compliant position over a period of many years, then subject to a "sting" operation, and finally bullied into compliance. And we also use VirtualBox :-(. For now. It's notable that at least in Canada, BSA (MS,Adobe,Sybase,etc.,etc.) audits are legal - and are often accompanied by provincial Sheriffs. (Not the same thing as a U.S Sheriff, but still a law enforcement officer.) The threat of legal action is NOT just an empty threat. -Adam
Re: pkg using "6.3" instead of "snapshots"
Try pkg_add -D snap We are close to a release so it automatically refers to the release See https://man.openbsd.org/pkg_add and check out -D snap And https://marc.info/?l=openbsd-misc&m=152145991212654&w=2 Where Peter N. M. Hansteen answers your question Cheers Adam On Sat, Mar 24, 2018 at 15:21, Tony Boston wrote: > Hello list, am using -current on my x230 for a while now which was working > okay since today. When I downloaded the new bsd.rd and did an upgrade, it > said that it would download from /pub/OpenBSD/6.3/amd64 which I had to change > to s/6.3/snaptshots here. The problem is, pkg now always uses "6.3" when I > try to update packages or install new ones. Is there a switch I have to set? > I didn't need to do anything like that before. Cheers -- Tony GPG-FP: > 913BBD25 8DA503C7 BAE0C0B6 8995E906 4FBAD580
Re: Dell Latitude E6540 OpenBSD 6.2 amd64 freezes when adjusting refresh rate using xrandr
On 2018-03-20 15:18, Xianwen Chen wrote: Dear Mihai, Although your tone in your email was not pleasant, You are posting to OpenBSD-misc. Objectionable tone is very common, particularly for users who *appear* to be complaining about immeasurably-small problems that aren't actually significant in the real world. If you wish to remain an OpenBSD user, get used to people being rude. (I am not going to speculate whether this is good or bad, but it is the case.) If you are right that humans are not able to see the difference between 60 Hz and 59.95 Hz, then something is wrong with xrandr that the actual refresh rate is quite below 60, not as much as 59.95 as reported by xrandr, because I can clearly see the flickering. I do not think that this is a minimal thing, because the flickering screen makes my head dizzy. Then my suggestion would be to replace the lights in your room, not try to fix a 0.05Hz deviation. The vast majority of systems I own report that the LCDs actually run at 59.95Hz; I've only seen one or two that ever reported 60Hz. This is normal. In a worst-case scenario, room lighting that is at a very slightly different frequency can cause odd effects, this is known as interference, and can produce a "beat frequency". If the difference is small it's possible you could experience this as flickering. (I believe the flickering is actually an neuro-optical illusion, but you might still be experiencing it.) I do not think that there is problem with the connection cable, as there was no such problem when the same external monitor is connected to a ThinkPad R52 using the same VGA cable a couple of days ago. I can check the cable connection again tomorrow. That is irrelevant. You have measured one VGA driver against a completely different VGA driver. Different laptops = different electronics = different results. I am sceptical whether there is any other source of distortion. I don't know where to start if there should be distortion. Fluorescent lights, or cheap LED lights - anything that needs a ballast or rectifier. Any of these things can cause not only the beat frequency optical interference mentioned above, but ALSO can cause electromagnetic interference in the cable. Oh, and cheap USB chargers are another common source of really bad EM interference. And guess what's almost immune to this type of EM interference? HDMI, DVI-D or DP cables. Guess what's REALLY susceptible? VGA cables. Hmm. The exact frequency of a monitor, regardless of type, is almost always irrelevant to human eyes. Whether it's 30Hz, 47.8Hz, 59.95Hz or 60.0Hz As you are apparently experiencing real problems, I would check, in order: 1. your cable - switch to HDMI (or HDMI->DVI or HDMI->DP) and get rid of VGA **immediately**. 2. your lights - try it with all the lights EXCEPT regular incandescent / halogen lights turned off. 3. your eyes - get a thorough examination by a doctor; there are some rare conditions that could cause odd things like this. 4. your brain - make sure you don't have a brain tumour (yes, I'm serious, it can cause things like this!) As to the VGA cable - this is such an important point that I agree with Nick - please go away and don't complain further until you have switched to a digital connection of some sort. I recall that my Dell E6430 was quite capable of producing so-called "120Hz" digital signals, and yours is a generation newer than that. I am 99% certain that your problem will go away with a different cable. (If you want DVI + DP connectors instead of HDMI, buy a Dell E-series dock on eBay for $50.) -Adam
Re: Jan 20 snapshot
On Sun, Jan 21, 2018 at 09:30:22AM -0700, Base Pr1me wrote: > Anyone else's system hanging randomly after upgrading to yesterday's > snapshot? This isn't a panic that drops to ddb. It's just freezing with no > response to anything. I haven't notice any problems with: kern.version=OpenBSD 6.2-current (GENERIC.MP) #379: Sat Jan 20 14:30:55 MST 2018 Regards, Adam
Re: OpenBSD SPARC T4-1 softraid boot issues
I'm afraid I don't know the answer to that, sorry. Not sure if anyone does... I think the SCSI HBA driver is the same on SPARC64 as on AMD64, but then Sun had a habit of "improving" control interfaces for Solaris so who knows. I do know under Solaris there is a bioctl-like tool to manage it, for what that's worth. -Adam On December 28, 2017 1:32:40 PM CST, Jordan Geoghegan wrote: >Yes I had considered using the onboard hardware raid, but I don't >particularly trust it. I also need the ability to rebuild my arrays >while the machine is online and was hoping to be able to do the 3 disk >RAID1 offered by OpenBSD softraid. Do you know if bioctl(8) is capable >of controlling the onboard raid controller, or will I need to do all >raid rebuilds via the hardware raid bios on the T4? > > >On 12/28/17 08:58, Adam Thompson wrote: >> On 2017-12-26 14:56, Jordan wrote: >>> I've recently gotten my hands on a couple shiny new SPARC T4-1 and >>> T3-1 servers and I was looking to install OpenBSD with a softraid >>> mirror on them for production use. The problem is, is that I end up >>> with this upon following the install instructions and rebooting: >> >> FWIW... >> AFAIK every single T4-1 (probably T3-1s but not certain) is capable >of >> hardware RAID-0/1/10 on the SCSI controller, and that's how they're >> shipped from Sun/Oracle even when running Solaris. I'm not absolutely > >> certain that it's supported by OpenBSD, but I do recall seeing that >it >> could be used as-is when I was investigating running OpenBSD on my >> T-series gear. There's Oracle documentation on how to access the >> on-card firmware to set up and manage the RAID set in a pre-OS >situation. >> >> YMMV. Unfortunately, both of mine are still running Solaris so I >> can't confirm right now. >> -Adam -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: OpenBSD SPARC T4-1 softraid boot issues
On 2017-12-26 14:56, Jordan wrote: I've recently gotten my hands on a couple shiny new SPARC T4-1 and T3-1 servers and I was looking to install OpenBSD with a softraid mirror on them for production use. The problem is, is that I end up with this upon following the install instructions and rebooting: FWIW... AFAIK every single T4-1 (probably T3-1s but not certain) is capable of hardware RAID-0/1/10 on the SCSI controller, and that's how they're shipped from Sun/Oracle even when running Solaris. I'm not absolutely certain that it's supported by OpenBSD, but I do recall seeing that it could be used as-is when I was investigating running OpenBSD on my T-series gear. There's Oracle documentation on how to access the on-card firmware to set up and manage the RAID set in a pre-OS situation. YMMV. Unfortunately, both of mine are still running Solaris so I can't confirm right now. -Adam
Linking the amd64 Kernel with ld.lld (further more have the default system linker as ld.lld)
Hi All Do you know if its possible to link the amd64 kernel with ld.lld? and if so would you change LD?= in sys.mk? I haven't been able to find anything about this besides "Bug 30815 - linking OpenBSD/amd64 kernel" [1]. Which says the linked kernel doesn't boot, thus if we can't link the kernel with ld.lld, the default system linker is a non-starter. Is this a direction the project wants to head? Cheers Adam [1] https://bugs.llvm.org/show_bug.cgi?id=30815
Re: Integrating "safe" languages into OpenBSD?
> The question for consideration is if microservices/unikernels approach > is not the best combination of both worlds, e.g. having something like > Mirage or HalVM based application/service running on top of OpenBSD in > its VMM, that may be interesting. Unfortunately so far both supports > IIRC just Xen. > Just a note on the above statements, i currently have solo5/vmm (with lots of help from Mike L and Mike B) [1] running on OpenBSD Current and am working towards [2] getting MirageOS [3] working too, if you would like more information please let me know. Cheers Adam [1] https://github.com/adamsteen/solo5 [2] https://github.com/Solo5/solo5/issues/206 [3] https://mirage.io/
Re: awk in OpenBSD
I would guess the latest update Dec, 2012, doesn't off any worth upgrading for, [1] Dec 20, 2012: fiddled makefile to get correct yacc and bison flags. pick yacc (linux) or bison (mac) as necessary. added __attribute__((__noreturn__)) to a couple of lines in proto.h, to silence someone's enthusiastic checker. fixed obscure call by value bug in split(a[1],a) reported on 9fans. the management of temporary values is just a mess; i took a shortcut by making an extra string copy. thanks to paul patience and arnold robbins for passing it on and for proposed patches. tiny fiddle in setfval to eliminate -0 results in T.expr, which has irritated me for 20+ years. [1] https://github.com/danfuzz/one-true-awk/blob/master/versions/2012-12-20/FIXES On Thu, Oct 19, 2017 at 1:14 PM, Niels Kobschaetzki wrote: > >> On 19. Oct 2017, at 06:23, flipchan wrote: >> >> Yeah blindly follow the flow of the others , DONT THINK SO > > That doesn’t explain the reasoning WHY the newer awk is not used. > >>> On October 19, 2017 4:25:09 AM GMT+02:00, Andras Farkas >>> wrote: >>> On the 6.2 release page, and confirmed in the source code, one can see >>> The system includes the following major components from outside >>> suppliers: >>> Awk Aug 10, 2011 version >>> This turns out to be one release behind upstream, where the latest >>> release is from December 20 2012: a quick check shows that >>> DragonFlyBSD, FreeBSD, and NetBSD all use this version. >>> >>> Just out of curiosity, is there a reason why OpenBSD uses the 2011 >>> release? > > Niels
Re: Calculate the frequency of the tsc timecounter
On Tue, Aug 1, 2017 at 6:43 PM, Adam Steen wrote: > Hi Mike > > Please see the output below (I did have to update a few DPRINTF's with > the change to clang, did you want a diff for checking in?) > I appreciate you having a look. > > Cheers > Adam > > root on sd0a (15cc7df693e2251e.a) swap on sd0b dump on sd0b > vm_impl_init_vmx: created vm_map @ 0x80b99000 > vm_resetcpu: resetting vm 1 vcpu 0 to power on defaults > guest eptp = 0x39eb8f01e > vmm_alloc_vpid: allocated VPID/ASID 1 > vmx_handle_exit: unhandled exit 2147483681 (unknown) > vcpu @ 0x800032ffc000 > rax=0x rbx=0x rcx=0x > rdx=0x rbp=0x rdi=0x5000 > rsi=0x r8=0x r9=0x > r10=0x r11=0x r12=0x > r13=0x r14=0x r15=0x > rip=0x0010 rsp=0x1ff8 > cr0=0x0020 (pg cd nw am wp NE et ts em mp pe) > cr2=0x > cr3=0x (pwt pcd) > cr4=0x2000 (pke smap smep osxsave pcide fsgsbase smxe > VMXE osxmmexcpt osfxsr pce pge mce pae pse de tsd pvi vme) > --Guest Segment Info-- > cs=0x0008 rpl=0 base=0x limit=0x a/r=0xa099 > granularity=1 dib=0 l(64 bit)=1 present=1 sys=1 type=code, x only, accessed > code, r/x > ds=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 > granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed > es=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 > granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed > fs=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 > granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed > gs=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 > granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed > ss=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 > granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed > tr=0x base=0x limit=0x a/r=0x008b > granularity=0 dib=0 l(64 bit)=0 present=1 sys=0 type=tss (busy) > gdtr base=0x1000 limit=0x0017 > idtr base=0x limit=0x > ldtr=0x base=0x limit=0x a/r=0x1 > (unusable) > --Guest MSRs @ 0xff039b869000 (paddr: 0x00039b869000)-- > MSR 0 @ 0xff039b869000 : 0xc080 (EFER), > value=0x0500 (sce LME LMA nxe) > MSR 1 @ 0xff039b869010 : 0xc081 (STAR), value=0x > MSR 2 @ 0xff039b869020 : 0xc082 (LSTAR), value=0x > MSR 3 @ 0xff039b869030 : 0xc083 (CSTAR), value=0x > MSR 4 @ 0xff039b869040 : 0xc084 (SFMASK), value=0x > MSR 5 @ 0xff039b869050 : 0xc102 (KGSBASE), value=0x > vcpu @ 0x800032ffc000 > parent vm @ 0xff0395ee7000 > mode: VMX > pinbased ctls: 0x7f0016 > true pinbased ctls: 0x7f0016 > EXTERNAL_INT_EXITING: Can set:Yes Can clear:Yes > NMI_EXITING: Can set:Yes Can clear:Yes > VIRTUAL_NMIS: Can set:Yes Can clear:Yes > ACTIVATE_VMX_PREEMPTION_TIMER: Can set:Yes Can clear:Yes > PROCESS_POSTED_INTERRUPTS: Can set:No Can clear:Yes > procbased ctls: 0xfff9fffe0401e172 > true procbased ctls: 0xfff9fffe04006172 > INTERRUPT_WINDOW_EXITING: Can set:Yes Can clear:Yes > USE_TSC_OFFSETTING: Can set:Yes Can clear:Yes > HLT_EXITING: Can set:Yes Can clear:Yes > INVLPG_EXITING: Can set:Yes Can clear:Yes > MWAIT_EXITING: Can set:Yes Can clear:Yes > RDPMC_EXITING: Can set:Yes Can clear:Yes > RDTSC_EXITING: Can set:Yes Can clear:Yes > CR3_LOAD_EXITING: Can set:Yes Can clear:Yes > CR3_STORE_EXITING: Can set:Yes Can clear:Yes > CR8_LOAD_EXITING: Can set:Yes Can clear:Yes > CR8_STORE_EXITING: Can set:Yes Can clear:Yes > USE_TPR_SHADOW: Can set:Yes Can clear:Yes > NMI_WINDOW_EXITING: Can set:Yes Can clear:Yes > MOV_DR_EXITING: Can set:Yes Can clear:Yes > UNCONDITIONAL_IO_EXITING: Can set:Yes Can clear:Yes > USE_IO_BITMAPS: Can set:Yes Can clear:Yes > MONITOR_TRAP_FLAG: Can set:Yes Can clear:Yes > USE_MSR_BITMAPS: Can set:Yes Can clear:Yes > MONITOR_EXITING: Can set:Yes Can clear:Yes > PAUSE_EXITING: Can set:Yes Can clear:Yes > procbased2 ctls: 0xff > VIRTUALIZE_APIC: Can set:
Re: Calculate the frequency of the tsc timecounter
On Mon, Jul 31, 2017 at 3:58 PM, Mike Belopuhov wrote:
> On Mon, Jul 31, 2017 at 09:48 +0800, Adam Steen wrote:
>> Ted Unangst wrote:
>> > we don't currently export this info, but we could add some sysctls. there's
>> > some cpufeatures stuff there, but generally stuff isn't exported until
>> > somebody finds a use for it... it shouldn't be too hard to add something to
>> > amd64/machdep.c sysctl if you're interested.
>>
>> I am interested, as i need the info, i will look into it and hopefully
>> come back with a patch.
>
> This is a bad idea because TSC as the time source is only usable
> by OpenBSD on Skylake and Kaby Lake CPUs since they encode the TSC
> frequency in the CPUID. All older CPUs have their TSCs measured
> against the PIT. Currently the measurement done by the kernel isn't
> very precise and if TSC is selected as a timecounter, the machine
> would be gaining time on a pace that cannot be corrected by our NTP
> daemon. (IIRC, about an hour a day on my Haswell running with NTP).
>
> To be able to use TSC as a timecounter source on OpenBSD or Solo5
> you'd have to improve the in-kernel measurement of the TSC frequency
> first. I've tried to perform 10 measurements and take an average and
> it does improve accuracy, however I believe we need to poach another
> bit from Linux and re-calibrate TSC via HPET:
>
>
> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L409
>
> I think this is the most sane thing we can do. Here's a complete
> procedure that Linux kernel undertakes:
>
>
> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L751
>
> Regards,
> Mike
Hi Mike and Ted
I understand using the tsc as a timecounter on non Skylake and
Kabylake processors is inaccurate, but this i my first real foray into
kernel programming, so wanted to started of slow. below is a diff to
expose if the tsc is invariant and the tsc frequency via sysctl
machdep. I would like to get this commited first and then move on to
improving the in-kernel measurement of the tsc frequency as Mike
describes above.
Sorry its taken a while to get back to you I have been working with
Mike Larkin on vmm and my port of Solo5/ukvm.
Cheers
Adam
comments?
Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.87
diff -u -p -u -p -r1.87 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 20 Jun 2017 05:34:41 - 1.87
+++ sys/arch/amd64/amd64/identcpu.c 2 Aug 2017 23:45:54 -
@@ -63,6 +63,8 @@ struct timecounter tsc_timecounter = {
tsc_get_timecount, NULL, ~0u, 0, "tsc", -1000, NULL
};
+u_int64_t amd64_tsc_freq = 0;
+int amd64_has_invariant_tsc;
int amd64_has_xcrypt;
#ifdef CRYPTO
int amd64_has_pclmul;
@@ -566,9 +568,12 @@ identifycpu(struct cpu_info *ci)
/* Check if it's an invariant TSC */
if (cpu_apmi_edx & CPUIDEDX_ITSC)
ci->ci_flags |= CPUF_INVAR_TSC;
+
+amd64_has_invariant_tsc = (ci->ci_flags & CPUF_INVAR_TSC) != 0;
}
ci->ci_tsc_freq = cpu_tsc_freq(ci);
+amd64_tsc_freq = ci->ci_tsc_freq;
amd_cpu_cacheinfo(ci);
Index: sys/arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.231
diff -u -p -u -p -r1.231 machdep.c
--- sys/arch/amd64/amd64/machdep.c 12 Jul 2017 06:26:32 - 1.231
+++ sys/arch/amd64/amd64/machdep.c 2 Aug 2017 23:45:54 -
@@ -425,7 +425,9 @@ int
cpu_sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp,
size_t newlen, struct proc *p)
{
+extern u_int64_t amd64_tsc_freq;
extern int amd64_has_xcrypt;
+ extern int amd64_has_invariant_tsc;
dev_t consdev;
dev_t dev;
int val, error;
@@ -496,6 +498,10 @@ cpu_sysctl(int *name, u_int namelen, voi
pckbc_release_console();
return (error);
#endif
+case CPU_TSCFREQ:
+return (sysctl_rdquad(oldp, oldlenp, newp, amd64_tsc_freq));
+ case CPU_INVARIANTTSC:
+ return (sysctl_rdint(oldp, oldlenp, newp, amd64_has_invariant_tsc));
default:
return (EOPNOTSUPP);
}
Index: sys/arch/amd64/include/cpu.h
===
RCS file: /cvs/src/sys/arch/amd64/include/cpu.h,v
retrieving revision 1.113
diff -u -p -u -p -r1.113 cpu.h
--- sys/arch/amd64/include/cpu.h 12 Jul 2017 06:26:32 - 1.113
+++ sys/arch/amd64/include/cpu.h 2 Aug 2017 23:45:56 -
@@ -429,7 +429,9 @@ void mp_setperf_init(void);
#define CPU_XCRYPT 12 /* supports VIA xcrypt in userland */
#define CPU_LIDACTION 14 /* action caused by lid close */
#define CPU_FORCEUKBD 15 /* Force ukbd(4) as console keyboard */
-#define CPU_MAXID 16 /* number of valid machdep ids */
+#
Re: Calculate the frequency of the tsc timecounter
Hi Mike Please see the output below (I did have to update a few DPRINTF's with the change to clang, did you want a diff for checking in?) I appreciate you having a look. Cheers Adam root on sd0a (15cc7df693e2251e.a) swap on sd0b dump on sd0b vm_impl_init_vmx: created vm_map @ 0x80b99000 vm_resetcpu: resetting vm 1 vcpu 0 to power on defaults guest eptp = 0x39eb8f01e vmm_alloc_vpid: allocated VPID/ASID 1 vmx_handle_exit: unhandled exit 2147483681 (unknown) vcpu @ 0x800032ffc000 rax=0x rbx=0x rcx=0x rdx=0x rbp=0x rdi=0x5000 rsi=0x r8=0x r9=0x r10=0x r11=0x r12=0x r13=0x r14=0x r15=0x rip=0x0010 rsp=0x1ff8 cr0=0x0020 (pg cd nw am wp NE et ts em mp pe) cr2=0x cr3=0x (pwt pcd) cr4=0x2000 (pke smap smep osxsave pcide fsgsbase smxe VMXE osxmmexcpt osfxsr pce pge mce pae pse de tsd pvi vme) --Guest Segment Info-- cs=0x0008 rpl=0 base=0x limit=0x a/r=0xa099 granularity=1 dib=0 l(64 bit)=1 present=1 sys=1 type=code, x only, accessed code, r/x ds=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed es=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed fs=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed gs=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed ss=0x0010 rpl=0 base=0x limit=0x a/r=0xc093 granularity=1 dib=1 l(64 bit)=0 present=1 sys=1 type=data, r/w, accessed tr=0x base=0x limit=0x a/r=0x008b granularity=0 dib=0 l(64 bit)=0 present=1 sys=0 type=tss (busy) gdtr base=0x1000 limit=0x0017 idtr base=0x limit=0x ldtr=0x base=0x limit=0x a/r=0x1 (unusable) --Guest MSRs @ 0xff039b869000 (paddr: 0x00039b869000)-- MSR 0 @ 0xff039b869000 : 0xc080 (EFER), value=0x0500 (sce LME LMA nxe) MSR 1 @ 0xff039b869010 : 0xc081 (STAR), value=0x MSR 2 @ 0xff039b869020 : 0xc082 (LSTAR), value=0x MSR 3 @ 0xff039b869030 : 0xc083 (CSTAR), value=0x MSR 4 @ 0xff039b869040 : 0xc084 (SFMASK), value=0x MSR 5 @ 0xff039b869050 : 0xc102 (KGSBASE), value=0x vcpu @ 0x800032ffc000 parent vm @ 0xff0395ee7000 mode: VMX pinbased ctls: 0x7f0016 true pinbased ctls: 0x7f0016 EXTERNAL_INT_EXITING: Can set:Yes Can clear:Yes NMI_EXITING: Can set:Yes Can clear:Yes VIRTUAL_NMIS: Can set:Yes Can clear:Yes ACTIVATE_VMX_PREEMPTION_TIMER: Can set:Yes Can clear:Yes PROCESS_POSTED_INTERRUPTS: Can set:No Can clear:Yes procbased ctls: 0xfff9fffe0401e172 true procbased ctls: 0xfff9fffe04006172 INTERRUPT_WINDOW_EXITING: Can set:Yes Can clear:Yes USE_TSC_OFFSETTING: Can set:Yes Can clear:Yes HLT_EXITING: Can set:Yes Can clear:Yes INVLPG_EXITING: Can set:Yes Can clear:Yes MWAIT_EXITING: Can set:Yes Can clear:Yes RDPMC_EXITING: Can set:Yes Can clear:Yes RDTSC_EXITING: Can set:Yes Can clear:Yes CR3_LOAD_EXITING: Can set:Yes Can clear:Yes CR3_STORE_EXITING: Can set:Yes Can clear:Yes CR8_LOAD_EXITING: Can set:Yes Can clear:Yes CR8_STORE_EXITING: Can set:Yes Can clear:Yes USE_TPR_SHADOW: Can set:Yes Can clear:Yes NMI_WINDOW_EXITING: Can set:Yes Can clear:Yes MOV_DR_EXITING: Can set:Yes Can clear:Yes UNCONDITIONAL_IO_EXITING: Can set:Yes Can clear:Yes USE_IO_BITMAPS: Can set:Yes Can clear:Yes MONITOR_TRAP_FLAG: Can set:Yes Can clear:Yes USE_MSR_BITMAPS: Can set:Yes Can clear:Yes MONITOR_EXITING: Can set:Yes Can clear:Yes PAUSE_EXITING: Can set:Yes Can clear:Yes procbased2 ctls: 0xff VIRTUALIZE_APIC: Can set:Yes Can clear:Yes ENABLE_EPT: Can set:Yes Can clear:Yes DESCRIPTOR_TABLE_EXITING: Can set:Yes Can clear:Yes ENABLE_RDTSCP: Can set:Yes Can clear:Yes VIRTUALIZE_X2APIC_MODE: Can set:Yes Can clear:Yes ENABLE_VPID: Can set:Yes Can clear:Yes WBINVD_EXITING: Can set:Yes Can clear:Yes UNRESTRICTED_GUEST: Can set:Yes Can clear:Yes APIC_REGISTER_VIRTUALIZATION: Can set:No Can clear:Yes VIRTUAL_INTERRUPT_DELIVERY: Can set:No Can clear:Yes PAUSE_LOOP_EXITING
