Re: MCU recommendations to program on OpenBSD?
> On Mar 3, 2024, at 18:36, Chris Narkiewicz wrote: > > On Sun, Mar 03, 2024 at 05:11:17PM +0800, Sadeep Madurange wrote: >> Any recommendations for MCUs with C >> language SDKs supported by OpenBSD? > > AVR - 8 bit > ARM - 32 bit > > Especially AVRs are top of the game when it comes to > open source toolchain support. You can probably keep developing esp32, at least: https://openports.pl/path/devel/arduino-esp32
Re: Use of fw_update to bootstrap OBSD
On Mon, Oct 09, 2023 at 08:01:14PM -0700, Andrew Hewus Fresh wrote:
> On Sun, Oct 08, 2023 at 02:36:16PM +0200, Thomas wrote:
> > Hello,
> >
> > I am installing OpenBSD on an old xps13 9380. The WiFi is not
> > supported and so I am using a usb dongle for which I need the
> > athn-firmware. I get it to work and now wanting to prep a USB disk
> > with all necessary firmware. I'm following the FAQ#4 on the website
> > (I suppose it works with more firmware than just the WiFi).
>
> fw_update does download and verify the signature on the SHA256.sig,
> however it does then overwrite the one with the signature with one
> without the signature.
I think this is as simple has having signify write the output to
/dev/null. It seems to work in my testing.
Index: fw_update.sh
===
RCS file: /cvs/src/usr.sbin/fw_update/fw_update.sh,v
retrieving revision 1.50
diff -u -p -r1.50 fw_update.sh
--- fw_update.sh28 Sep 2023 01:18:52 - 1.50
+++ fw_update.sh11 Oct 2023 02:37:24 -
@@ -180,7 +180,7 @@ fetch_cfile() {
set +o noclobber # we want to get the latest CFILE
fetch "$CFILE" || return 1
set -o noclobber
- ! signify -qVep "$FWPUB_KEY" -x "$CFILE" -m "$CFILE" &&
+ ! signify -qVep "$FWPUB_KEY" -x "$CFILE" -m /dev/null &&
warn "Signature check of SHA256.sig failed" &&
rm -f "$CFILE" && return 1
elif [ ! -e "$CFILE" ]; then
Re: Use of fw_update to bootstrap OBSD
On Sun, Oct 08, 2023 at 02:36:16PM +0200, Thomas wrote: > Hello, > > I am installing OpenBSD on an old xps13 9380. The WiFi is not supported and > so I am using a usb dongle for which I need the athn-firmware. I get it to > work and now wanting to prep a USB disk with all necessary firmware. I'm > following the FAQ#4 on the website (I suppose it works with more firmware > than just the WiFi). > > So, now to my question. Using fw_update -F to the current dir does download > all firmware (5 files) and SHA256.sig. However, the file SHA256.sig does not > include the signature, using signify like so: > > signify -Cp /etc/signify/openbsd-73-fw.pub -x SHA256.sig * > > Fails with message: invalid comment in SHA256.sig; must start with 'untrusted > comment: ' > > Downloading the SHA256.sig from firmware.openbsd.org/firmware/7.3/SHA256.sig > which includes the signature does work. > > Is it that normal behaviour? Since the firmware.openbsd.org site is not > HTTPS, and that, at least for me, fw_update does not download signed > SHA256.sig, would it not be possible to download unintended files? fw_update does download and verify the signature on the SHA256.sig, however it does then overwrite the one with the signature with one without the signature. Normally once it's verified we trust the location of the files and so we don't need to verify the signature again, but in the download case that may not be true (even if we trust the user when installing from a local directory and don't require a signed SHA256 file). https://github.com/openbsd/src/blob/master/usr.sbin/fw_update/fw_update.sh#L183-L185 > Thanks in advance, Thanks for noticing. I'll look at how best to adjust that when I have time to look at fw_update again.
Re: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header
On Fri, Sep 22, 2023 at 12:27 PM David Gwynne wrote: > On Mon, Sep 18, 2023 at 12:47:52PM -, Stuart Henderson wrote: > > On 2023-09-17, Andrew Lemin wrote: > > > I have been testing the Wireguard implementation on OpenBSD and noticed > > > that the ToS field is not being copied from the inner unencrypted > header to > > > the outer Wireguard header, resulting in ALL packets going into the > same PF > > > Prio / Queue. > > > > > > For example, ACKs (for Wireguard encrypted packets) end up in the first > > > queue (not the priority queue) despite PF rules; > > > > > > queue ext_iface on $extif bandwidth 1000M max 1000M > > > queue pri on $extif parent ext_iface flows 1000 bandwidth 25M min 5M > > > queue data on $extif parent ext_iface flows 1000 bandwidth 100M > default > > > > > > match on $extif proto tcp set prio (3, 6) set queue (data, pri) > > > > > > All unencrypted SYNs and ACKs etc correctly go into the 'pri' queue, > and > > > payload packets go into 'data' queue. > > > However for Wireguard encrypted packets, _all_ packets (including SYNs > and > > > ACKs) go into the 'data' queue. > > > > > > I thought maybe you need to force the ToS/prio/queue values, so I also > > > tried sledgehammer approach; > > > match proto tcp flags A/A set tos lowdelay set prio 7 set queue pri > > > match proto tcp flags S/S set tos lowdelay set prio 7 set queue pri > > > > > > But sadly all encrypted SYNs and ACKs etc still only go into the data > queue > > > no matter what. > > > This can be confirmed with wireshark that all ToS bits are lost > > > > > > This results in poor Wireguard performance on OpenBSD. > > > > Here's a naive untested diff that might at least use the prio internally > > in OpenBSD... > > > > Index: if_wg.c > > === > > RCS file: /cvs/src/sys/net/if_wg.c,v > > retrieving revision 1.29 > > diff -u -p -r1.29 if_wg.c > > --- if_wg.c 3 Aug 2023 09:49:08 - 1.29 > > +++ if_wg.c 18 Sep 2023 12:47:02 - > > @@ -1525,6 +1525,8 @@ wg_encap(struct wg_softc *sc, struct mbu > >*/ > > mc->m_pkthdr.ph_flowid = m->m_pkthdr.ph_flowid; > > > > + mc->m_pkthdr.pf.prio = m->m_pkthdr.pf.prio; > > + > > res = noise_remote_encrypt(>p_remote, >r_idx, , > > data->buf, plaintext_len); > > nonce = htole64(nonce); /* Wire format is little endian. */ > > > > > > i think this should go in, ok by me. > > implementing txprio and rxprio might be useful too, but requires more > plumbing than i have the energy for now. > Hi David, Just to make sure I understand currently, you mean also copying the priority to/from txprio/rxprio for the VLAN/CoS priorities? Thanks. I plan to test Stuart's patch this weekend and will confirm here, but I'm confident it will work first time knowing him :)
Re: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header
On Mon, Sep 18, 2023 at 10:59 PM Stuart Henderson wrote: > On 2023-09-17, Andrew Lemin wrote: > > I have been testing the Wireguard implementation on OpenBSD and noticed > > that the ToS field is not being copied from the inner unencrypted header > to > > the outer Wireguard header, resulting in ALL packets going into the same > PF > > Prio / Queue. > > > > For example, ACKs (for Wireguard encrypted packets) end up in the first > > queue (not the priority queue) despite PF rules; > > > > queue ext_iface on $extif bandwidth 1000M max 1000M > > queue pri on $extif parent ext_iface flows 1000 bandwidth 25M min 5M > > queue data on $extif parent ext_iface flows 1000 bandwidth 100M default > > > > match on $extif proto tcp set prio (3, 6) set queue (data, pri) > > > > All unencrypted SYNs and ACKs etc correctly go into the 'pri' queue, and > > payload packets go into 'data' queue. > > However for Wireguard encrypted packets, _all_ packets (including SYNs > and > > ACKs) go into the 'data' queue. > > > > I thought maybe you need to force the ToS/prio/queue values, so I also > > tried sledgehammer approach; > > match proto tcp flags A/A set tos lowdelay set prio 7 set queue pri > > match proto tcp flags S/S set tos lowdelay set prio 7 set queue pri > > > > But sadly all encrypted SYNs and ACKs etc still only go into the data > queue > > no matter what. > > This can be confirmed with wireshark that all ToS bits are lost > > > > This results in poor Wireguard performance on OpenBSD. > > Here's a naive untested diff that might at least use the prio internally > in OpenBSD... > Awesome! Thank you so much Stuart :D I will test this weekend.. > > Index: if_wg.c > === > RCS file: /cvs/src/sys/net/if_wg.c,v > retrieving revision 1.29 > diff -u -p -r1.29 if_wg.c > --- if_wg.c 3 Aug 2023 09:49:08 - 1.29 > +++ if_wg.c 18 Sep 2023 12:47:02 - > @@ -1525,6 +1525,8 @@ wg_encap(struct wg_softc *sc, struct mbu > */ > mc->m_pkthdr.ph_flowid = m->m_pkthdr.ph_flowid; > > + mc->m_pkthdr.pf.prio = m->m_pkthdr.pf.prio; > + > res = noise_remote_encrypt(>p_remote, >r_idx, , >data->buf, plaintext_len); > nonce = htole64(nonce); /* Wire format is little endian. */ > > >
OpenBSD Wireguard implementation not copying ToS from inner to outer WG header
Hi, I have been testing the Wireguard implementation on OpenBSD and noticed that the ToS field is not being copied from the inner unencrypted header to the outer Wireguard header, resulting in ALL packets going into the same PF Prio / Queue. For example, ACKs (for Wireguard encrypted packets) end up in the first queue (not the priority queue) despite PF rules; queue ext_iface on $extif bandwidth 1000M max 1000M queue pri on $extif parent ext_iface flows 1000 bandwidth 25M min 5M queue data on $extif parent ext_iface flows 1000 bandwidth 100M default match on $extif proto tcp set prio (3, 6) set queue (data, pri) All unencrypted SYNs and ACKs etc correctly go into the 'pri' queue, and payload packets go into 'data' queue. However for Wireguard encrypted packets, _all_ packets (including SYNs and ACKs) go into the 'data' queue. I thought maybe you need to force the ToS/prio/queue values, so I also tried sledgehammer approach; match proto tcp flags A/A set tos lowdelay set prio 7 set queue pri match proto tcp flags S/S set tos lowdelay set prio 7 set queue pri But sadly all encrypted SYNs and ACKs etc still only go into the data queue no matter what. This can be confirmed with wireshark that all ToS bits are lost This results in poor Wireguard performance on OpenBSD. OpenVPN has the --passtos directive to copy the ToS Bits, which means OpenVPN is faster than Wireguard on OpenBSD. Thanks, Andy.
Re: PF queue bandwidth limited to 32bit value
On Thu, Sep 14, 2023 at 7:23 PM Andrew Lemin wrote: > > > On Wed, Sep 13, 2023 at 8:35 PM Stuart Henderson < > stu.li...@spacehopper.org> wrote: > >> On 2023-09-13, Andrew Lemin wrote: >> > I have noticed another issue while trying to implement a 'prio'-only >> > workaround (using only prio ordering for inter-VLAN traffic, and HSFC >> > queuing for internet traffic); >> > It is not possible to have internal inter-vlan traffic be solely >> priority >> > ordered with 'set prio', as the existence of 'queue' definitions on the >> > same internal vlan interfaces (required for internet flows), demands one >> > leaf queue be set as 'default'. Thus forcing all inter-vlan traffic into >> > the 'default' queue despite queuing not being wanted, and so >> > unintentionally clamping all internal traffic to 4294M just because full >> > queuing is needed for internet traffic. >> >> If you enable queueing on an interface all traffic sent via that >> interface goes via one queue or another. >> > > Yes, that is indeed the very problem. Queueing is enabled on the inside > interfaces, with bandwidth values set slightly below the ISP capacities > (multiple ISP links as well), so that all things work well for all internal > users. > However this means that inter-vlan traffic from client networks to server > networks are restricted to 4294Mbps for no reason.. It would make a huge > difference to be able to allow local traffic to flow without being > queued/restircted. > > >> >> (also, AIUI the correct place for queues is on the physical interface >> not the vlan, since that's where the bottleneck is... you can assign >> traffic to a queue name as it comes in on the vlan but I believe the >> actual queue definition should be on the physical iface). >> > > Hehe yes I know. Thanks for sharing though. > I actually have very specific reasons for doing this (queues on the VLAN > ifaces rather than phy) as there are multiple ISP connections for multiple > VLANs, so the VLAN queues are set to restrict for the relevant ISP link etc. > Also separate to the multiple ISPs (I wont bore you with why as it is not relevant here), the other reason for queueing on the VLANs is because it allows you to get closer to the 10Gbps figure.. Ie, If you have queues on the 10Gbps PHY, you can only egress 4294Mbps to _all_ VLANs. But if you have queues per-VLAN iface, you can egress multiple times 4294Mbps on aggregate. Eg, vlans 10,11,12,13 on single mcx0 trunk. 10->11 can do 4294Mbps and 12->13 can do 4294Mbps, giving over 8Gbps egress in total on the PHY. It is dirty, but like I said, desperate for workarounds... :( > > >> >> "required for internet flows" - depends on your network layout.. the >> upstream feed doesn't have to go via the same interface as inter-vlan >> traffic. > > > I'm not sure what you mean. All the internal networks/vlans are connected > to local switches, and the switches have trunk to the firewall which hosts > the default gateway for the VLANs and does inter-vlan routing. > So all the clients go through the same VLANs/trunk/gateway for inter-vlan > as they do for internet. Strict L3/4 filtering is required on inter-vlan > traffic. > I am honestly looking for support to recognise that this is a correct, > valid and common setup, and so there is a genuine need to allow flows to > not be queued on interfaces that have queues (which has many potential > applications for many use cases, not just mine - so should be of interest > to the developers?). > > Do you know why there has to be a default queue? Yes I know that traffic > excluded from queues would take from the same interface the queueing is > trying to manage, and potentially causes congestion. However with 10Gbps > networking which is beyond common now, this does not matter when the queues > are stuck at 4294Mbps > > Desperately trying to find workarounds that appeal.. Surely the need is a > no brainer, and it is just a case of trying to encourage interest from a > developer? > > Thanks :) >
Re: PF queue bandwidth limited to 32bit value
On Wed, Sep 13, 2023 at 8:35 PM Stuart Henderson wrote: > On 2023-09-13, Andrew Lemin wrote: > > I have noticed another issue while trying to implement a 'prio'-only > > workaround (using only prio ordering for inter-VLAN traffic, and HSFC > > queuing for internet traffic); > > It is not possible to have internal inter-vlan traffic be solely priority > > ordered with 'set prio', as the existence of 'queue' definitions on the > > same internal vlan interfaces (required for internet flows), demands one > > leaf queue be set as 'default'. Thus forcing all inter-vlan traffic into > > the 'default' queue despite queuing not being wanted, and so > > unintentionally clamping all internal traffic to 4294M just because full > > queuing is needed for internet traffic. > > If you enable queueing on an interface all traffic sent via that > interface goes via one queue or another. > Yes, that is indeed the very problem. Queueing is enabled on the inside interfaces, with bandwidth values set slightly below the ISP capacities (multiple ISP links as well), so that all things work well for all internal users. However this means that inter-vlan traffic from client networks to server networks are restricted to 4294Mbps for no reason.. It would make a huge difference to be able to allow local traffic to flow without being queued/restircted. > > (also, AIUI the correct place for queues is on the physical interface > not the vlan, since that's where the bottleneck is... you can assign > traffic to a queue name as it comes in on the vlan but I believe the > actual queue definition should be on the physical iface). > Hehe yes I know. Thanks for sharing though. I actually have very specific reasons for doing this (queues on the VLAN ifaces rather than phy) as there are multiple ISP connections for multiple VLANs, so the VLAN queues are set to restrict for the relevant ISP link etc. > > "required for internet flows" - depends on your network layout.. the > upstream feed doesn't have to go via the same interface as inter-vlan > traffic. I'm not sure what you mean. All the internal networks/vlans are connected to local switches, and the switches have trunk to the firewall which hosts the default gateway for the VLANs and does inter-vlan routing. So all the clients go through the same VLANs/trunk/gateway for inter-vlan as they do for internet. Strict L3/4 filtering is required on inter-vlan traffic. I am honestly looking for support to recognise that this is a correct, valid and common setup, and so there is a genuine need to allow flows to not be queued on interfaces that have queues (which has many potential applications for many use cases, not just mine - so should be of interest to the developers?). Do you know why there has to be a default queue? Yes I know that traffic excluded from queues would take from the same interface the queueing is trying to manage, and potentially causes congestion. However with 10Gbps networking which is beyond common now, this does not matter when the queues are stuck at 4294Mbps Desperately trying to find workarounds that appeal.. Surely the need is a no brainer, and it is just a case of trying to encourage interest from a developer? Thanks :)
Re: PF queue bandwidth limited to 32bit value
On Wed, Sep 13, 2023 at 8:22 PM Stuart Henderson wrote: > On 2023-09-12, Andrew Lemin wrote: > > A, thats clever! Having bandwidth queues up to 34,352M would > definitely > > provide runway for the next decade :) > > > > Do you think your idea is worth circulating on tech@ for further > > discussion? Queueing at bps resolution is rather redundant nowadays, even > > on the very slowest links. > > tech@ is more for diffs or technical questions rather than not-fleshed-out > quick ideas. Doing this would solve some problems with the "just change it > to 64-bit" mooted on the freebsd-pf list (not least with 32-bit archs), > but would still need finding all the places where the bandwidth values are > used and making sure they're updated to cope. > > Yes good point :) I am not in a position to undertake this myself at the moment. If none of the generous developers feel included to do this despite the broad value, I might have a go myself at some point (probably not able until next year sadly). "just change it to 64-bit" mooted on the freebsd-pf list - I have been unable to find this conversation. Do you have a link? > > -- > Please keep replies on the mailing list. > >
Re: PF queue bandwidth limited to 32bit value
On Wed, Sep 13, 2023 at 3:43 AM Andrew Lemin wrote: > Hi Stuart. > > On Wed, Sep 13, 2023 at 12:25 AM Stuart Henderson < > stu.li...@spacehopper.org> wrote: > >> On 2023-09-12, Andrew Lemin wrote: >> > Hi all, >> > Hope this finds you well. >> > >> > I have discovered that PF's queueing is still limited to 32bit bandwidth >> > values. >> > >> > I don't know if this is a regression or not. >> >> It's not a regression, it has been capped at 32 bits afaik forever >> (certainly was like that when the separate classification via altq.conf >> was merged into PF config, in OpenBSD 3.3). >> > > Ah ok, it was talked about so much I thought it was part of it. Thanks for > clarifying. > > >> >> > I am sure one of the >> > objectives of the ALTQ rewrite into the new queuing system we have in >> > OpenBSD today, was to allow bandwidth values larger than 4294M. Maybe I >> am >> > imagining it.. >> >> I don't recall that though there were some hopes expressed by >> non-developers. >> > > Haha, it is definitely still wanted and needed. prio-only based ordering > is too limited > I have noticed another issue while trying to implement a 'prio'-only workaround (using only prio ordering for inter-VLAN traffic, and HSFC queuing for internet traffic); It is not possible to have internal inter-vlan traffic be solely priority ordered with 'set prio', as the existence of 'queue' definitions on the same internal vlan interfaces (required for internet flows), demands one leaf queue be set as 'default'. Thus forcing all inter-vlan traffic into the 'default' queue despite queuing not being wanted, and so unintentionally clamping all internal traffic to 4294M just because full queuing is needed for internet traffic. In fact 'prio' is irrelevant, as with or without 'prio' because queue's are required for internet traffic, all internal traffic becomes bound by the 'default' HSFC queue. So I would propose that the mandate on the 'default' keyword is relaxed (or a new keyword is provided for match/pass rules to force flows to not be queued), and/or implement the uint32 scale in bytes, instead of bits? I personally believe both are valid and needed? > > >> >> > Anyway, I am trying to use OpenBSD PF to perform/filter Inter-VLAN >> routing >> > with 10Gbps trunks, and I cannot set the queue bandwidth higher than a >> > 32bit value? >> > >> > Setting the bandwidth value to 4295M results in a value overflow where >> > 'systat queues' shows it wrapped and starts from 0 again. And traffic is >> > indeed restricted to such values, so does not appear to be just a >> cosmetic >> > 'systat queues' issue. >> > >> > I am sure this must be a bug/regression, >> >> I'd say a not-implemented feature (and I have a feeling it is not >> going to be all that simple a thing to implement - though changing >> scales so the uint32 carries bytes instead of bits per second might >> not be _too_ terrible). >> > > Following the great work to SMP unlock in the VLAN interface, and recent > NIC optimisations (offloading and interrupt handling) in various drivers, > you can now push packet filtered 10Gbps with modern CPUs without breaking a > sweat.. > > A, thats clever! Having bandwidth queues up to 34,352M would > definitely provide runway for the next decade :) > > Do you think your idea is worth circulating on tech@ for further > discussion? Queueing at bps resolution is rather redundant nowadays, even > on the very slowest links. > > >> > 10Gbps on OpenBSD is trivial >> and >> > common nowadays.. >> >> While using interfaces with 10Gbps link speed on OpenBSD is trivial, >> actually pushing that much traffic (particularly with more complex >> processing e.g. things like bandwidth controls, and particularly with >> smaller packet sizes) not so much. >> >> >> -- >> Please keep replies on the mailing list. >> >> Thanks again, Andy.
Re: PF queue bandwidth limited to 32bit value
Hi Stuart. On Wed, Sep 13, 2023 at 12:25 AM Stuart Henderson wrote: > On 2023-09-12, Andrew Lemin wrote: > > Hi all, > > Hope this finds you well. > > > > I have discovered that PF's queueing is still limited to 32bit bandwidth > > values. > > > > I don't know if this is a regression or not. > > It's not a regression, it has been capped at 32 bits afaik forever > (certainly was like that when the separate classification via altq.conf > was merged into PF config, in OpenBSD 3.3). > Ah ok, it was talked about so much I thought it was part of it. Thanks for clarifying. > > > I am sure one of the > > objectives of the ALTQ rewrite into the new queuing system we have in > > OpenBSD today, was to allow bandwidth values larger than 4294M. Maybe I > am > > imagining it.. > > I don't recall that though there were some hopes expressed by > non-developers. > Haha, it is definitely still wanted and needed. prio-only based ordering is too limited > > > Anyway, I am trying to use OpenBSD PF to perform/filter Inter-VLAN > routing > > with 10Gbps trunks, and I cannot set the queue bandwidth higher than a > > 32bit value? > > > > Setting the bandwidth value to 4295M results in a value overflow where > > 'systat queues' shows it wrapped and starts from 0 again. And traffic is > > indeed restricted to such values, so does not appear to be just a > cosmetic > > 'systat queues' issue. > > > > I am sure this must be a bug/regression, > > I'd say a not-implemented feature (and I have a feeling it is not > going to be all that simple a thing to implement - though changing > scales so the uint32 carries bytes instead of bits per second might > not be _too_ terrible). > Following the great work to SMP unlock in the VLAN interface, and recent NIC optimisations (offloading and interrupt handling) in various drivers, you can now push packet filtered 10Gbps with modern CPUs without breaking a sweat.. A, thats clever! Having bandwidth queues up to 34,352M would definitely provide runway for the next decade :) Do you think your idea is worth circulating on tech@ for further discussion? Queueing at bps resolution is rather redundant nowadays, even on the very slowest links. > > 10Gbps on OpenBSD is trivial and > > common nowadays.. > > While using interfaces with 10Gbps link speed on OpenBSD is trivial, > actually pushing that much traffic (particularly with more complex > processing e.g. things like bandwidth controls, and particularly with > smaller packet sizes) not so much. > > > -- > Please keep replies on the mailing list. > >
PF queue bandwidth limited to 32bit value
Hi all, Hope this finds you well. I have discovered that PF's queueing is still limited to 32bit bandwidth values. I don't know if this is a regression or not. I am sure one of the objectives of the ALTQ rewrite into the new queuing system we have in OpenBSD today, was to allow bandwidth values larger than 4294M. Maybe I am imagining it.. Anyway, I am trying to use OpenBSD PF to perform/filter Inter-VLAN routing with 10Gbps trunks, and I cannot set the queue bandwidth higher than a 32bit value? Setting the bandwidth value to 4295M results in a value overflow where 'systat queues' shows it wrapped and starts from 0 again. And traffic is indeed restricted to such values, so does not appear to be just a cosmetic 'systat queues' issue. I am sure this must be a bug/regression, 10Gbps on OpenBSD is trivial and common nowadays.. Tested on OpenBSD 7.3 Thanks for checking my sanity :) Andy.
Re: Intel E823-L Ethernet interfaces not detected
Hi Jonathan, This at least confirms the behavior is expected, thanks for the clarity. In the mean time, I've got plenty of new things to explore on the 7.3 release - with a pair of two perfectly good X550 Ethernet interfaces to do it with! For now I'll leave a standing offer: Any time into the future, if somebody at the project is thinking "Gee, wish I had an Intel E800 platform to evaluate" - reach out to me and I'd be happy to lend mine, and cover costs too. :) Thanks to you and all other contributors for the stellar software! -Andrew
Intel E823-L Ethernet interfaces not detected
Hi @misc, I just installed OpenBSD 7.3-release on a new amd64 system to replace an old one that had been on OpenBSD 5.5 (it was set it and forget it till the CPU fried!). I've found that some of the Ethernet interfaces aren't seen in ifconfig, so I suspect there's no driver/support yet. dmesg also reflects unknown ethernet devices (full output attached at the bottom of this message). I searched @misc and @tech archives and didn't succeed in finding any discussions, so starting one here (apology if I missed something). The non-working interfaces are using an Intel E823-L controller, while the working interfaces are using an Intel X550 controller. The mainboard is an Intel Xeon-D 1700 SoC platform (Supermicro X12SDV-4C-SPT4F). Of course I'd love some easy solution but hey, it is what it is if the support just isn't there. :) Searching online, I did find an Intel driver link for this controller that supports FreeBSD: https://www.intel.com/content/www/us/en/download/18332/ intel-network-adapter-freebsd-virtual-function-driver-for-intel-ethernet -controller-700-and-e810-series.html I also found a verbose lspci dump for the controller: https://www.servethehome.com/supermicro-x12sdv-4c-sp6f-review-25gbe-and- intel-xeon-d-1718t/supermicro-intel-e823-l-lspci-vvv/ ^ I think that's probably from Linux though. If my message in any way comes off as urgent - please know, it is not. I know the OpenBSD devs are busy. No expectations on my part at all. Although, I am willing to help any way I can. If somebody would like the use of the system, happy to lend it out, etc. Cheers, Andrew Full dmesg follows: OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33909121024 (32338MB) avail mem = 32862027776 (31339MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x6c252000 (48 entries) bios0: vendor American Megatrends International, LLC. version "1.1" date 10/05/2022 bios0: Supermicro Super Server efi0 at bios0: UEFI 2.8 efi0: American Megatrends rev 0x50018 acpi0 at bios0: ACPI 6.4 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP SPMI FIDT SSDT TCPA SSDT ERST BERT SSDT MCFG BDAT HMAT HPET WDDT APIC SLIT SRAT OEM4 OEM1 SSDT HEST DMAR TPM2 SSDT SSDT WSMT acpi0: wakeup devices RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) PXSX(S0) RP05(S0) PXSX(S0) RP06(S0) PXSX(S0) RP07(S0) PXSX(S0) RP08(S0) PXSX(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0x8000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 10MB 64b/line 20-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 10MB 64b/line 20-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) D-1718T CPU @ 2.60GHz, 2594.08 MHz, 06-6c-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,
Re: [7.3/i386] pf-badhost - Illegal instruction (core dumped)
Unfortunately it looks like sh -x does not trace into functions, and it is something inside "main" which is crashing: > > set -x or something. > Sorry, I should have started with that. > > test73# doas -u _pfbadhost pf-badhost -O openbsd > [ ... ] > + command -v typeset > + > /dev/null > + 2>&1 > + main -O openbsd > Illegal instruction > [ ... ] > Illegal instruction (core dumped) > > No blocklist changes... > Illegal instruction (core dumped) Both sh and ksh seem to behave that way, but bash will trace inside functions. Try calling the script with 'bash -x' and hopefully you can pinpoint which binary called by main() is crashing. -Andrew
Re: PC Engines APU platform EOL
I'm in the midst of testing the R86S as an alternative to my APU. My biggest issues so far with it: - No UART port, or even one to solder a header to. That means you're stuck with HDMI during install or to do any rescue work. - The SFPs in the taller version are Mellanox ConnectX-3s, which aren't supported in OpenBSD like the 4s and 5s. My ISP does fibre to the home, so I was hoping to directly connect my SFP to my firewall, bypassing my modem entirely. If you don't need SFP support, then the 2.5GbE ports seem to be supported. Otherwise it does seem like a very capable machine. On 5/4/23 00:23, Damian McGuckin wrote: On Thu, 4 May 2023, Maksim Rodin wrote: Is there any problem with fanless x86_64 mini PCs with several NICs, sold on aliexpress? Maybe, or give up on the rackmount and buy the R86S, as in https://www.aliexpress.com/i/1005004765507664.html An alternative is to buy 3 APU4s now 3 to cover failures and spares over the next few years. Hopefully, they still have some left. Thanks - Damian Pacific Engineering Systems International . 20D Grose St, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer
Re: hardware
That's been my motto as well. Except I recently picked up an R86s with older Mellanox ConnectX-3 10GbE SFPs, only to discover that OpenBSD only supports the newer ConnectX-4 and 5s :( I'd love to contribute in writing a driver in some way, but don't even know where to begin. On 4/28/23 13:55, Mihai Popescu wrote: Gustavo Rios wrote: What is the best supported servers by OpenBSD ? The older, the better! Take the oldest machine that will suit your needs. If it old enough, then someone: o released some (in)complete documentation o was pissed enough to start writing drivers and code for it o noticed bugs and reported them o ... already! Good luck!
curl-8.0.1 exists in two non-comparable versions (Someone forgot to bump a REVISION)
This happened when I ran 'pkg_add -u' after upgrading an i386 system from 7.2 to 7.3: andrew@bilbo:~$ doas pkg_add -u quirks-6.121 signed on 2023-04-22T01:10:43Z quirks-6.42->6.121: ok bash-5.2.15:libiconv-1.17->1.17: ok bash-5.2.15:gettext-runtime-0.21p1->0.21.1: ok bash-5.1.16->5.2.15: ok Couldn't find ngtcp2 in first signature Couldn't find nghttp3 in first signature Couldn't find ngtcp2_crypto_openssl in first signature Couldn't find www/nghttp3 in first signature Couldn't find net/ngtcp2 in first signature Error: curl-8.0.1 exists in two non-comparable versions Someone forgot to bump a REVISION curl-8.0.1,6,@nghttp2-1.49.0,c.96.2,crypto.50.0,nghttp2.0.20,pthread.26.2,ssl.53.0,z.7.0 vs. curl-8.0.1,6,@nghttp2-1.52.0,@nghttp3-0.9.0,@ngtcp2-0.13.1,c.97.0,crypto.50.2,nghttp2.0.21,nghttp3.0.1,ngtcp2.1.0,ngtcp2_crypto_openssl.0.0,pthread.27.0,ssl.53.2,z.7.0 curl-8.0.1:ngtcp2-0.13.1: ok curl-8.0.1:nghttp3-0.9.0: ok curl-8.0.1:nghttp2-1.49.0->1.52.0: ok Couldn't find nghttp3 in first signature Couldn't find ngtcp2 in first signature Couldn't find net/ngtcp2 in first signature Couldn't find www/nghttp3 in first signature Couldn't find ngtcp2_crypto_openssl in first signature Error: curl-8.0.1 exists in two non-comparable versions Someone forgot to bump a REVISION curl-8.0.1,6,@nghttp2-1.49.0,c.96.2,crypto.50.0,nghttp2.0.20,pthread.26.2,ssl.53.0,z.7.0 vs. curl-8.0.1,6,@nghttp2-1.52.0,@nghttp3-0.9.0,@ngtcp2-0.13.1,c.97.0,crypto.50.2,nghttp2.0.21,nghttp3.0.1,ngtcp2.1.0,ngtcp2_crypto_openssl.0.0,pthread.27.0,ssl.53.2,z.7.0 curl-8.0.1->8.0.1: ok iperf3-3.10.1->3.12: ok libsodium-1.0.18p1->1.0.18p1: ok par2cmdline-0.7.4p0->0.7.4p0: ok smartmontools-7.3->7.3p0: ok vim-9.0.0192-no_x11->9.0.1388-no_x11: ok xz-5.2.5p2->5.4.1: ok Read shared items: ok andrew@bilbo:~$ cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD It seems that it succeeded in the end, but what happened? Is there a 7.3-stable curl pkg with new dependencies but the same revision as 7.3? (Or maybe a 7.2-stable pkg, since I was apparently at 8.0.1 already?) Thanks, Andrew
Re: any way to "redo" a botched upgrade?
On Thu, Apr 20, 2023 at 12:49:35AM -0700, Jonathan Thornburg wrote: > Andrew Hewus Fresh wrote: > > This usually happens when an XS module is installed outside of the > > package ecosystem, often with a CPAN client. > > > > I would guess this error is Term::ReadLine::Gnu > > https://metacpan.org/pod/Term::ReadLine::Gnu > > I've never used the CPAN client (I always install CPAN perl modules > "manually" via 'perl Makefile.PL'; 'make'; 'make test'; 'doas make install', > and follow dependency chains manually). This also would have the same effect. The cpan tooling is just wrappers to do just this for you. I just guessed at Term::ReadLine::Gnu, you could search for the Gnu.so in /usr/local/libexec/perl5 and see what the actual module is. l8rZ, -- andrew Hey! It compiles! Ship it!
Re: any way to "redo" a botched upgrade?
On Wed, Apr 19, 2023 at 07:25:17PM -0700, Jonathan Thornburg wrote: > I've just upgraded an amd64 machine from 7.1 to 7.3 (first a 7.1-->7.2 > upgrade, immediately followed by a 7.2-->7.3 upgrade, both following the > FAQ instructions). After a full 'pkg_add -uvv', at least one package > (p5-Term-ReadPassword) is out-of-sync with the new perl binary: > # cat /tmp/foo > #!/usr/bin/perl > use warnings; > use strict; > use Term::ReadPassword; > > print "hello, world\n"; > # /tmp/foo > Gnu.c: loadable library and perl binaries are mismatched (got first > handshake key 0xec0, needed 0xeb8) This usually happens when an XS module is installed outside of the package ecosystem, often with a CPAN client. I would guess this error is Term::ReadLine::Gnu https://metacpan.org/pod/Term::ReadLine::Gnu You might be able to pkg_add p5-Term-ReadLine-Gnu to overwrite that file, but not sure that will work. I recommend looking at sysutils/sysclean as the easiest way to clean up those files. l8rZ, -- andrew Adding manpower to a late software project makes it later.
Re: Unable to receive dhcplease from ISP
On Sat, Apr 1, 2023 at 10:25 PM Nick Holland wrote: > I can replicate that with my ISP if I follow your steps. > With my service, if I change the MAC address of the machine attached to > my cable modem, I have to power cycle the cable modem to get a new > DHCP lease. > > Not saying that is your problem, but you never indicated you power > cycled the modem...which I have found critical for the last 20+ years. Also, sometimes you have to release the old lease (on the previously-active device, of course), or wait for it to expire. Usually that would let me grab a new lease on a different device without power-cycling the modem, and would occasionally be necessary even after a modem reset. This used to be accomplished with 'dhclient -r', but I'm not sure how to do that with dhcpleased, even after reading the man pages... ENOTIMPLEMENTED or am I overlooking something? I also found dhcpleasectl's behavior of forcibly renewing a lease by default, but needing a flag to just show the lease info, rather backwards -- and was quite surprised that it didn't require root to renew. I may be in the minority though. -Andrew
Re: Safely remove USB drive
A great bit of work. Do you know if USB DAT drives are working on Sparc64? They were not when I last tested (probably OBSD 6.2). Andrew On Mon, 13 Feb 2023 at 13:02, Crystal Kolipe wrote: > On Thu, Feb 09, 2023 at 09:20:48PM -0300, Crystal Kolipe wrote: > > There is no reason why we couldn't implement support for 'eject -t' for > sd > > devices, (which is internally treated as a tape retension command). > > > > In fact, I just made a patch to do that out of curiosity and was able to > > access the usb device again after 'reloading' it. > > Over the weekend I received a few emails off-list asking me about this, so > I've written up and posted a brief explainer here: > > https://research.exoticsilicon.com/articles/eject_command_hacking > >
Re: Mail from the command line
Thanks, I'll check it out. Andrew Le ven. 17 févr. 2023 à 15:14, Rodrigo Readi a écrit : > 2023-02-16 13:42 GMT, Andrew : > > Thanks Crystal for your reply and encouragement, > > I'll explore all your suggestions and references when I have enough time. > > If you do not have tine, better install and use alpine. > > You can read mail from a provider with imap without having to download > the attachements. > Mutt is not able to do that. > > And alpine is easier to configure, it works with gmail's xoauth2, > displays html-mail. > > I like BSD mail program, but unfortunately it is not always (easily) > usable due to the > modern requirements (html-mail, attachements). > > Rod. >
Re: Mail from the command line
Thanks Crystal for your reply and encouragement, I'll explore all your suggestions and references when I have enough time. Cheers, Andrew Le jeu. 16 févr. 2023 à 12:58, Crystal Kolipe a écrit : > On Thu, Feb 16, 2023 at 12:27:37PM +0100, Andrew wrote: > > *Do you know any recipe for using $ mail on the command line? Or a web > link > > that proposes one.* > > > > The man pages are great but they are meant for people with great > technical > > skills, which I am not. > > What exactly are you trying to set up? > > Local mail works out of the box on a default OpenBSD install, so I'm > assuming > that what you want to do is to send and receive mail to other internet > hosts > without using a desktop/gui client, I.E. using the traditional built-in > mail > functionality typical of a unix-like system. > > This isn't particularly difficult, but it does depend to a certain extent > on > the configuration of your ISP, and also exactly how you want the system to > behave. So it's not possible to give you a simple fixed list of steps to > follow to 'make it work'. > > First up, the /usr/bin/mail utility in base is really a hard link to > /usr/bin/mailx. > > This is a very simple command line mail tool, which you probably don't > want to > use as your mail email application because it's lacking many features. > > Other command line based mail programs are available in ports, such as > mutt, > which is widely used by openbsd developers. > > Then you need to set up smtpd to handle your inbound and outbound mail. > > For outbound mail, you _probably_ want to, (and need to), relay it via your > ISP's 'smarthost', but we would need more information to know this for > certain > and to give specific advice on how to set it up. > > For inbound mail, you have several choices: > > * Run your own MX on a fixed IP broadband link. > * Pick up your mail via POP3 or IMAP from within the mail user agent, > (such as > mutt), and feed it in to your local mail spools that way. > * Pick up your mail via POP3 or IMAP and feed it into the local mail > system. > * Run your own MX on your own server or VM somewhere, and relay it to your > own local, private MX. > * Other options also exist. > > If you are new to this, then you probably want the second option. Maybe > the > third. > > > And web pages are full of phoney tips which rarely work. > > Agreed. > > > I hope that this is the right place for asking such questions. > > Yes, it is. > > But we can't give you a step-by-step guide without a bit more information. >
Mail from the command line
Hi Misc, I'm so sorry guys if that question has been asked too often. *Do you know any recipe for using $ mail on the command line? Or a web link that proposes one.* The man pages are great but they are meant for people with great technical skills, which I am not. And web pages are full of phoney tips which rarely work. I hope that this is the right place for asking such questions. Cheers, Andrew
Re: BiDi sfp in ix
On Wed, Jan 11, 2023 at 11:53 AM Hrvoje Popovski wrote: > Hi all, > > claudio@ suggested to try same setup with FreeBSD. So I've tried FreeBSD > and Linux and results are same, 1G BiDi from FS.COM coded for Cisco > won't work with Intel 82599 10G card. > If I boot FreeBSD and Linux with that sfp in 82599 or X710 card that > interface will be disabled at boot and won't show up in OS. > On OpenBSD i could see it but mac address is 00:00:00:00:00:00 > > I've tried all combinations with unsupported_sfp statements for FreeBSD > and Linux but I couldn't see that interface in OS. > If I put that sfp in card after boot status is no carrier whatever I do, > at least on FreeBSD. I'm still playing with Linux.. > > > it seems that I've missed out all football here :) Definitely seems like the "Intel NIC unsupported SFP" behavior, nothing specific to BiDi. (But thanks to everyone in this thread for educating me about BiDi! I doubt I'll be using it any time soon, but it's neat how it works, and I definitely see the appeal if you have a limited number of fibres.) Note that in Linux, it actually disables the card until you unload and reload the driver, for example: Dec 8 17:01:19 lambda kernel: [ 1428.680975] ixgbe :24:00.0 enp36s0f0: NIC Link is Down Dec 8 17:01:19 lambda systemd-networkd[83876]: enp36s0f0: Lost carrier Dec 8 17:01:24 lambda kernel: [ 1433.830686] ixgbe :24:00.0: failed to initialize because an unsupported SFP+ module type was detected. Dec 8 17:01:24 lambda kernel: [ 1433.832843] ixgbe :24:00.0: Reload the driver after installing a supported module. Dec 8 17:01:24 lambda kernel: [ 1433.852297] ixgbe :24:00.0: removed PHC on enp36s0f0 Dec 8 17:01:24 lambda systemd-networkd[83876]: enp36s0f0: Link DOWN That was with an Intel X520-DA2 (82599). I had to 'rmmod ixgbe' and then 'modprobe ixgbe' (optionally with 'allow_unsupported_sfp=1') to get the card active again, even with an Intel SFP+ module. Apparently there is a bit you can toggle in the EEPROM to make that setting permanent in all OSes: https://forums.servethehome.com/index.php?threads/patching-intel-x520-eeprom-to-unlock-all-sfp-transceivers.24634/page-3#post-324427 Note that this only applies to the 500 series cards (ix), the 700 series (ixl) have a different EEPROM that doesn't easily allow unsupported modules, although in my experience they do allow more modules, e.g. Finisar, and AFAIK don't require reloading the driver after swapping in a "supported" SFP. I'm not exactly sure how the vendor-lock works, but I think it looks at the "Vendor OUI" bits in the SFP's EEPROM. My FS.com generic 10GBASE-SR modules have 00:00:00 there, while an "Intel" one from FS has 00:1b:21, but still the FS vendor name and PN. I don't know if OpenBSD's 'ifconfig transceiver' reports all of that, but Linux 'ethtool -m ' does. -Andrew
Re: Possible typo in fw_update
On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> substitution ${name:#word} is not documented in the manual page for ksh yet
> its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> a typo, a patch is provided to remove the colon. If it is not a typo, could
> someone explain what this syntax does?
It was a typo, committed, thanks!
> Is this was a typo however, and this parameter substitution is not
> officially supported, why did ksh not complain?
Not having read it, I assume the implementation reads the : and sets a
flag that says "must be be NULL" for the -, +, =, and ? substitutions
and the validation that the next character is one of those four is
missing.
An email to bugs@ with this question might get the attention of folks
who are more familiar with ksh internals and whether fixing this being
too accepting is worth the code and the likelihood of breaking scripts
with typos like this one.
> Rob
>
> diff --git usr.sbin/fw_update/fw_update.sh usr.sbin/fw_update/fw_update.sh
> index 4b77d4c7bd7..dbc80257228 100644
> --- usr.sbin/fw_update/fw_update.sh
> +++ usr.sbin/fw_update/fw_update.sh
> @@ -405,7 +405,7 @@ if [ "$LOCALSRC" ]; then
> FWURL="${LOCALSRC}"
> LOCALSRC=
> else
> - LOCALSRC="${LOCALSRC:#file:}"
> + LOCALSRC="${LOCALSRC#file:}"
> ! [ -d "$LOCALSRC" ] &&
> echo "The path must be a URL or an existing directory"
> >&2 &&
> exit 1
Re: Yet Another Laptop Recommendation Thread
On Tue, Sep 13, 2022, at 5:46 AM, Chris Cappuccio wrote: > Then there are arm64 laptops like the x13s and the apple stuff that are coming > out now, too. Kinda neat! Lots of custom stuff on these new apple and qualcomm > platforms. I know there’s been a lot of work done on the M1s, but I haven’t been following progress on the Snapdragon machines, which traditionally even Linux has trouble with. Has there been progress made on OpenBSD? I’d love to show support for non-amd64 architectures, but would rather keep my Apple devices as only “utility computers” rather than daily drivers ….
Re: recommended partitions to backup with dump
Remember that some that some things need to be explicitly dumped - eg databases and repositories because when you do restore, you might want to restore to an upgraded OS version. Rather than use dump, I use gtar - I have restored stuff after 30 years with gtar, to completely different OSes - eg OS/2 to OBSD! * If you do GFS (four tapes: grandfather, father, son, and NEXT), each tape is approximately used once per month, and can be expected to have quite a long life. The "Son" tape is kept near the drive, the "father" tape goes off-site. You tape from the disk backup (done with rsync) machine - databases and repositories can have hot standbys on the same machine. In case of disaster recovery, step 1 is to duplicate the "father" tape off site. Then you still have a chance of knowing how bad things are before you accidentally overwrite the "son". Once a year, you can put one father tape aside for archive, and replace with a fresh tape. Possibly twice a year - to maintain a second, completely separate, archive. If you don't use tapes, expect to lose data one day. I am probably the only person to have restored data from VMS to BBC Micro using 1600BPI reel to reel tapes. (Probably the only person to have a BBC micro with both reel-to-reel tape and ST506 interfaces). Andrew * ICL George 2 to VMS only worked with no compression, and George 2 to Cray :-) required an assembler program to convert between the two different the 6-bit ASCII character sets on 7-track 556 bpi tapes.
Re: serial console works only if system is booted from it
On Mon, Jul 25, 2022 at 9:01 PM Todd C. Miller wrote: > > On Sun, 24 Jul 2022 23:50:11 -0700, Kastus Shchuka wrote: > > > Apparently, restarting getty on tty00 was not enough. > > After reboot, I got login prompt on tty00 line. > > Running "ttyflags -a" as root would probably also fix it without > the need for a reboot. This is probably worth a mention in the ttys(5) man page. It's one of those things that once you've worked through it, you know, but it's not at all obvious that HUP-ing init applies changes from every other column but NOT any flags changes. I think the wording NetBSD has [1] is decent: "Nota Bene: Sending SIGHUP to init(8) does not change the state of the various tty(4) device flags listed above; the ttyflags(8) program must be run for changes in those flags to take effect on the devices." I'm pretty sure I tried 'local' on some Dell servers but it didn't work for me, on either the physical port or IPMI Serial-over-LAN; 'softcar' did the trick in my case. Without that I get the same issue -- getty only works if the device is also the boot console. Thanks, -Andrew [1] http://man.bsd.lv/NetBSD-9.2/ttys
Re: No login prompt on console ttyC0 after boot when using "set tty com0"
On Wed, Jun 29, 2022 at 8:53 PM Ted Wynnychenko wrote: > > Hello > I was wondering if there is anything I could do to help figure this out. > I do not have the requisite knowledge to even begin to understand why the > kernel does not configure the vga output when boot.conf redirects to com0. Look for a "redirection after boot" setting in your BIOS and try disabling that. The behavior you've described of both physical and serial consoles working at the boot prompt _without_ 'set tty com0' seems to indicate the BIOS is still handling redirection from keyboard/video to serial, and my guess is that when OpenBSD initializes the port for a serial console, it causes something in the BIOS-linked local keyboard/vga to go wonky (wsdisplay at vga1 not configured). Note that in UEFI mode, "wsdisplay at vga1 not configured" would be expected, as efifb takes over: $ dmesg|egrep 'wsdisplay|fb|vga|com[0-9]' vga1 at pci7 dev 0 function 0 "Matrox MGA G200eR" rev 0x01 wsdisplay at vga1 not configured com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo com1: console efifb0 at mainbus0: 1280x1024, 32bpp wsdisplay0 at efifb0 mux 1 wsdisplay0: screen 0-5 added (std, vt100 emulation) You might give UEFI mode a try, to see if efifb works better than the vga console. Redirection after boot is probably the more important setting though. Note that the login prompt appearing on a console (spawning a getty as configured in /etc/ttys) and the bootloader/kernel console device are independent settings. -Andrew
Re: OpenBSD 7.1 - hangs after userland upgrade on server hardware
ay L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 2 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus -1 (RP03) acpiprt7 at acpi0: bus 3 (RP04) acpiec0 at acpi0: not present acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PG00, resource for PEG0 acpipwrres1 at acpi0: PG01, resource for PEG1 acpipwrres2 at acpi0: PG02, resource for PEG2 acpipwrres3 at acpi0: WRST acpipwrres4 at acpi0: WRST acpipwrres5 at acpi0: WRST acpipwrres6 at acpi0: WRST acpipwrres7 at acpi0: FN00, resource for FAN0 acpipwrres8 at acpi0: FN01, resource for FAN1 acpipwrres9 at acpi0: FN02, resource for FAN2 acpipwrres10 at acpi0: FN03, resource for FAN3 acpipwrres11 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 3600 MHz: speeds: 3601, 3600, 3400, 3200, 3000, 2800, 2600, 2400, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v3 Host" rev 0x06 ppb0 at pci0 dev 1 function 0 "Intel Core 4G PCIE" rev 0x06: msi pci1 at ppb0 bus 1 mcx0 at pci1 dev 0 function 0 "Mellanox ConnectX-4 Lx" rev 0x00: FW 14.28.2006, msix, address ec:0d:9a:83:1f:3a mcx1 at pci1 dev 0 function 1 "Mellanox ConnectX-4 Lx" rev 0x00: FW 14.28.2006, msix, address ec:0d:9a:83:1f:3b xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x05: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 em0 at pci0 dev 25 function 0 "Intel I217-V" rev 0x05: msi, address 00:25:90:e1:e5:46 ehci0 at pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int 16 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb1 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xd5: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 3 "Intel 8 Series PCIE" rev 0xd5: msi pci3 at ppb2 bus 3 em1 at pci3 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:25:90:e1:e5:47 ehci1 at pci0 dev 29 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int 23 usb2 at ehci1: USB revision 2.0 uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 "Intel Q87 LPC" rev 0x05 ahci0 at pci0 dev 31 function 2 "Intel 8 Series AHCI" rev 0x05: msi, AHCI 1.3 ahci0: port 4: 6.0Gb/s ahci0: port 5: 6.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 4 lun 0: naa.500a075103185123 sd0: 61057MB, 512 bytes/sector, 125045424 sectors, thin sd1 at scsibus1 targ 5 lun 0: naa.55cd2e438062 sd1: 171705MB, 512 bytes/sector, 351651888 sectors, thin ichiic0 at pci0 dev 31 function 3 "Intel 8 Series SMBus" rev 0x05: apic 8 int 18 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-12800 SO-DIMM spdmem1 at iic0 addr 0x52: 4GB DDR3 SDRAM PC3-12800 SO-DIMM "Intel 8 Series Thermal" rev 0x05 at pci0 dev 31 function 6 not configured isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo pcppi0 at isa0 port 0x61 spkr0 at pcppi0 wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x52 wbsio0 port 0x290/2 not configured vmm0 at mainbus0: VMX/EPT dt: 445 probes uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.05 addr 2 uhub4 at uhub2 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.05 addr 2 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (2d1c73e93d7b352e.a) swap on sd0b dump on sd0b WARNING: / was not properly unmounted WARNING: /home was not properly unmounted WARNING: /usr/l
OpenBSD 7.1 - hangs after userland upgrade on server hardware
Hi all, I am totally stumped with issues while upgrading/installing 7.1 and I need some help! Server; Supermicro X10SLV-Q (Intel Q87 Express), Xeon E3-1280 v3, 8G RAM, Mellanox 10G NIC This server has been running OpenBSD flawlessly for years. I followed the upgrade instructions and was able to reboot fine onto the 7.1 kernel (I rebooted a couple of times on the 7.1 kernel in fact). However after I run 'pkg_add -u' to upgrade all of userland to 7.1, the machine started hanging during boot. The hang looked like an IO problem as it would always hang around the disk setup stages. I went into the BIOS and tried optimised defaults and failsafe defaults but no luck.. I also downloaded a fresh copy and tried installing 7.1 from flash, however the 7.1 installer also hangs. It hangs in the same place every time after selecting 'done' to the networking config. As I have a Mellanox card in here, I removed the NIC. but the hang continues so its not that.. I get nothing to debug, it just freezes. I have reinstalled 7.0 which is still working perfectly so this is not a hardware fault. Is there anything I can do to increase the verbosity to see what driver it is trying to load before the hang? Other information, this is a totally headless machine, with a Xeon CPU without any onboard GPU. It has a console connection with console-redirection in the bios, and I have to set the tty params during boot to interact over console. Otherwise everything else is standard. Thanks for your time, Best regards Andy.
Re: Framework laptop fails to enter sleep/suspend/hibernate
Ah yes this kind of makes sense. I was planning on making some room on the nvme drive for OpenBSD eventually anyways. Thanks! On Mon., Apr. 25, 2022, 05:01 Dave Voutila, wrote: > > Andrew W writes: > > > Not sure what else to try but I can't seem to get sleep/suspend to work > on > > my frame.work laptop. I've tried OpenBSD 7.0 and 7.1 now, running off a > 1TB > > USB drive. > > S4/Hibernation is not supported when swap is on a USB disk. I haven't > read the suspend code paths lately, but I wouldn't be susprised if this > is a problem as well. > > > > > Running apm -S or apm -z the screen goes blank and the keyboard remains > > backlit, eventually the fan starts spinning faster. I need to long press > > the power button to force shutdown the machine. Hibernate says it's not > > supported, which is a bit less of a concern to me but having one of them > > working would be very helpful. > > > > I've tried w/o X running, same results. I don't see any failures related > to > > the TPM in dmesg but also I've tried w/ it set to "hidden" in the bios, > > same result. > > > > I'm new to OpenBSD so maybe I'm missing something important to get this > > working but I haven't seen much in the way of configuration related to > this > > functionality? > > Can you try with your root and swap partitions on your nvme disk and not > on USB? Barring that, capturing all your machine details with sendbug(1) > would be helpful. > > -dv >
Framework laptop fails to enter sleep/suspend/hibernate
Not sure what else to try but I can't seem to get sleep/suspend to work on my frame.work laptop. I've tried OpenBSD 7.0 and 7.1 now, running off a 1TB USB drive. Running apm -S or apm -z the screen goes blank and the keyboard remains backlit, eventually the fan starts spinning faster. I need to long press the power button to force shutdown the machine. Hibernate says it's not supported, which is a bit less of a concern to me but having one of them working would be very helpful. I've tried w/o X running, same results. I don't see any failures related to the TPM in dmesg but also I've tried w/ it set to "hidden" in the bios, same result. I'm new to OpenBSD so maybe I'm missing something important to get this working but I haven't seen much in the way of configuration related to this functionality? Andrew. --- log attempting to hibernate, then trying sleep Apr 24 20:29:53 vortexbsd reorder_kernel: kernel relinking done Apr 24 20:32:02 vortexbsd apmd: system hibernating Apr 24 20:32:02 vortexbsd apmd: battery status: high. external power status: not connected. estimated battery life 63% (176 minutes life time estimate) Apr 24 20:32:03 vortexbsd apmd: hibernate: Operation not supported Apr 24 20:34:10 vortexbsd apmd: system suspending Apr 24 20:35:51 vortexbsd syslogd[65016]: start -- dmesg OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8346333184 (7959MB) avail mem = 8076058624 (7701MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439e2000 (50 entries) bios0: vendor INSYDE Corp. version "03.07" date 12/14/2021 bios0: Framework Laptop acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM SSDT NHLT SSDT LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT FPDT PTDT BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 4190.34 MHz, 06-8c-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line disabled 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 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 4190.34 MHz, 06-8c-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line disabled L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 3791.26 MHz, 06-8c-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 256KB 64b/line disabled L2 cache cpu2: disabling user TSC (skew=127) cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 3791.26 MHz, 06-8c-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,AC
Re: ikev2 fails with mschap-v2
On Wed, Feb 23, 2022 at 10:10 PM wrote:
>
> I honestly have no idea where the logs would even be stored or what
> the daemon runs as under MacOS 12.2.1 (Monterey).
I don't have a Monterey system handy, but at least under macOS
Catalina, VPN connections use setkey and racoon, similar to FreeBSD.
Parts of the FreeBSD handbook's chapter on IPsec VPN may be relevant.
The global conf is in /etc/racoon.conf, which has some logging options
(and the associated man pages are installed), and there's a
/var/log/racoon.log. setkey [ -P ] -D looks useful, but may not apply
if it's failing before establishing SA entries.
It also uses pppd, at least for L2TP over IPsec; a handy feature of
which is support for your own scripts at /etc/ppp/ip-{up,down}.
-Andrew
Re: Is it true that `dd` is almost not needed?
"The era of magnetic tapes" has not ended. It is just that some people mysteriously believe their data is safer "in the cloud" where they cannot monitor it, than on a tape in a fire safe under their own supervision. I have read back tapes I wrote myself 30 years earlier. Have you tried getting your data back from a deceased "cloud provider"? That is why we get all these stories of ransomware attacks. Also, for many of us that have spent half a century learning Unix, we do not want our well proven tools snatched from our hands. There is room for more than one knife in a virtual tool box. On Sat, 11 Dec 2021 at 23:58, Stuart Longland wrote: > On Sat, 11 Dec 2021 18:06:43 +0200 > wrote: > > > The Cult of DD > > Mar 17, 2017 > > You'll often see instructions for creating and using disk images on Unix > > systems making use of the dd command. This is a strange program of > > [obscure provenance](https://en.wikipedia.org/wiki/Dd_(Unix)) that > > somehow, still manages to survive in the 21st century. > > > > Actually, using dd is almost never necessary, and due to its highly > > nonstandard syntax is usually just an easy way to mess things up. For > > instance, you'll see instructions like this asking you to run commands > > like: > > > > […snip…] > > > > > > End of article and my questions: > > > > Is the author right in general? > > Is the author right for Linux environment? > > Is the author right for OpenBSD environment? > > Can `cat`/`tail` et all, create a "sparse" file? > > vk4msl-gap$ dd if=/dev/zero bs=1M count=1 seek=9 of=sparsefile > > 1+0 records in > > 1+0 records out > > 1048576 bytes transferred in 0.009 secs (108639200 bytes/sec) > > vk4msl-gap$ ls -lh sparsefile > > -rw-r--r-- 1 stuartl stuartl 10.0M Dec 12 08:42 sparsefile > > vk4msl-gap$ du -hs sparsefile > > 1.0Msparsefile > > Very useful for "thin provisioning" of raw disk images with virtual > machines. > > Can `cat`/`tail` et all read bytes from the middle of a file? > > vk4msl-gap$ echo -n '000102030405060708090a0b0c0d0e0f' > test > > vk4msl-gap$ dd if=test of=test.part bs=2 skip=4 count=4 > > 4+0 records in > > 4+0 records out > > 8 bytes transferred in 0.000 secs (66541 bytes/sec) > > vk4msl-gap$ cat test.part > > 04050607 > > Can `cat`/`tail` et all overwrite specific bytes in the middle of a file? > > vk4msl-gap$ echo -n 'aaabacad' | dd of=test bs=2 count=4 seek=8 > conv=notrunc > > 4+0 records in > > 4+0 records out > > 8 bytes transferred in 0.000 secs (98985 bytes/sec) > > vk4msl-gap$ cat test > > 0001020304050607aaabacad0c0d0e0f > > I think you'll find `dd` was written in the era of magnetic tapes as a > storage medium, and so the ability to seek to a specific part of a tape > then perform a read or write, was seen as a critical feature of the day. > > That same feature is handy when doing various low-level disk operations > as well (e.g. backing-up/restoring the boot sector/partition table). > -- > Stuart Longland (aka Redhatter, VK4MSL) > > I haven't lost my mind... > ...it's backed up on a tape somewhere. > >
Re: After upgrade to 6.9 pkg_add -u throws ListUtil.c error
On Mon, Nov 22, 2021 at 11:34:44PM +0100, pas...@pascallen.nl wrote: > After a sysupgrade to 6.9 > I try to update the packages but get thrown an error: > > router# pkg_add -Uu > ListUtil.c: loadable library and perl binaries are mismatched (got > handshake key 0xb60, needed 0xec0) This error generally means that you've installed perl modules (in this case List::Util) using a CPAN client instead of ports or packages. > How can I recover? Remove any modules you've installed outside of the ports tree into /usr/local/libdata/perl5. Once you upgrade to OpenBSD 7.0, base tools got smarter so that they won't be broken by this condition, but things outside of base will continue to have issues. I need to get back to some changes to improve this in the future, but time has not been on my side. l8rZ, -- andrew A printer consists of three main parts: the case, the jammed paper tray and the blinking red light.
Re: Server certs expired higher up the chain, imaps and https
On Thu, Sep 30, 2021 at 4:00 PM Sebastian Benoit wrote: > This is an issue with an expired root/intermediate certificate (DST Root X3) > in use by Let's Encrypt. > > [...] > An errata has just been published, you can install it using syspatch. Thanks for the quick patch! I can verify this fixes fetching with ftp(1) from https servers which use Let's Encrypt certificates. It looks like this is "workaround 2" as described in this OpenSSL blog [1]? I'm surprised this was even needed, as I thought this problem was "fixed" last year after the AddTrust External CA Root expiration. It seems to be a similar case of "while waiting for widespread acceptance of a new root, the intermediate is cross-signed". In that case the cert chain configured on your web server was: - host cert, signed by: - InCommon RSA Server CA (or several other intermediates), signed by: - USERTrust RSA Certification Authority, signed by: - AddTrust External CA Root (which expired 2020-05-30; recommended not to send the top-level root since it's in the client store and thus redundant). A few years before that expiration, they got a new USERTrust root into browser/OS certificate stores, and intermediates like InCommon were also signed by this new root. Browsers would ignore that last USERTrust intermediate cert since it wasn't needed, but OpenSSL before 1.1 would still consider it expired because of that intermediate. This seems to be a similar scenario, with: - host cert, signed by: - Let's Encrypt R3, signed by: - ISRG Root X1, signed by: - DST Root CA X3 (which just expired) Likewise, there's a new ISRG Root X1. The "alternate" or "short" chain on your server would consist of host + R3, but certbot etc. are defaulting to the "long" chain which adds the X1 intermediate. Unlike the USERTrust/AddTrust scenario, where the intermediate USERTrust cert expired the same time as the AddTrust root, the intermediate X1 cert doesn't expire until 2024-09-30. That seems to go against accepted standards of not issuing certificates expiring after the issuer expires, but maybe they got special dispensation. (And apparently Android doesn't care if the root expired, if everything else is valid? Also, apparently there was a different, older R3 intermediate which _also_ expired a couple days ago.) The immediate fix last year was to stop sending the unnecessary expired intermediate cert (i.e. only send host cert and InCommon RSA, not the USERTrust intermediate), but I thought a fix went into LibreSSL then to not consider a host "expired" if it was possible to generate a valid chain of trust, regardless of "extra" certs sent by the server? Indeed, Let's Encrypt's own documentation [2] thinks that only LibreSSL < 3.2.0 is affected, but that is not the case. LibreSSL 3.3.2 in OpenBSD 6.9 (before the new syspatch) still considered servers expired, as does the somewhat older version bundled in macOS. -Andrew [1] https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ [2] https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
And to answer my last question about SMP capabilities, it looks like the only locking going on is when the driver is talking to the Kernel itself through kstat which would make sense. So yes it looks like mcx does have SMP support :) Well its enough for me to buy a card from ebay to play with as the ConnectX-4 Lx cards are pretty cheap now. Warning to others reading my comments, me poking around in kernel code is akin to a blind person in a library before learning braille, so take nothing I say as fact, merely optimistic opinion :) On Wed, Sep 29, 2021 at 9:08 PM Andrew Lemin wrote: > So I think I have figured out some things Theo browsing through > https://github.com/openbsd/src/blob/master/sys/dev/pci/if_mcx.c. > > I can see that some offloading is supported, but have not yet figured out > how much is implemented yet. It looks like the offloading capability in > these cards are much more granular than I have understood from previous > hardware. > I was able to decipher some of it using this > https://www.mellanox.com/related-docs/user_manuals/Ethernet_Adapters_Programming_Manual.pdf > (this is very well written). > > And I was quite excited to see what looks like the RDMA access support in > the mcx driver! So we should be able to see the super low latency > capabilities with this card :) > > I will keep pushing myself.. Thanks again Theo > > On Wed, Sep 29, 2021 at 2:21 PM Andrew Lemin > wrote: > >> Hi Theo :) >> >> Ok sure, I will put on my cape-of-courage and start reading the source.. >> I may be some time! >> >> On Wed, Sep 29, 2021 at 1:56 PM Theo de Raadt >> wrote: >> >>> We tend to keep our driver manual pages without detailed promises. >>> They do ethernet, they do it best effort, etc. >>> >>> What you want to know can be found by reading the source, or the >>> commit logs. Since this is a locally written driver, the code is >>> surprisingly approachable. >>> >>> Andrew Lemin wrote: >>> >>> > Hi. I hope everyone is well and having a great day :) >>> > >>> > Just a quick question about the mcx (Mellanox 5th generation Ethernet >>> > device) drivers >>> > https://man.openbsd.org/mcx.4 >>> > >>> > The man page says nothing more than it supports; >>> > ConnectX-4 Lx EN >>> > ConnectX-4 EN >>> > ConnectX-5 EN >>> > ConnectX-6 EN >>> > >>> > I am looking for some clarity on what features and performance >>> > characteristics mcx boasts? >>> > >>> > For example are the following basic hardware features supported by this >>> > driver? >>> > IPv4 receive IP/TCP/UDP checksum offload >>> > IPv4 transmit TCP/UDP checksum offload >>> > VLAN tag insertion and stripping >>> > interrupt coalescing >>> > >>> > And what other features does it support? >>> > >>> > I also came across a comment in some forum a while back (so high >>> quality >>> > information ) that mentioned Mellanox drivers in OpenBSD are SMP >>> safe and >>> > so not giant-locked. Is this true? >>> > >>> > Thanks, Andy, >>> >>
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
So I think I have figured out some things Theo browsing through https://github.com/openbsd/src/blob/master/sys/dev/pci/if_mcx.c. I can see that some offloading is supported, but have not yet figured out how much is implemented yet. It looks like the offloading capability in these cards are much more granular than I have understood from previous hardware. I was able to decipher some of it using this https://www.mellanox.com/related-docs/user_manuals/Ethernet_Adapters_Programming_Manual.pdf (this is very well written). And I was quite excited to see what looks like the RDMA access support in the mcx driver! So we should be able to see the super low latency capabilities with this card :) I will keep pushing myself.. Thanks again Theo On Wed, Sep 29, 2021 at 2:21 PM Andrew Lemin wrote: > Hi Theo :) > > Ok sure, I will put on my cape-of-courage and start reading the source.. I > may be some time! > > On Wed, Sep 29, 2021 at 1:56 PM Theo de Raadt wrote: > >> We tend to keep our driver manual pages without detailed promises. >> They do ethernet, they do it best effort, etc. >> >> What you want to know can be found by reading the source, or the >> commit logs. Since this is a locally written driver, the code is >> surprisingly approachable. >> >> Andrew Lemin wrote: >> >> > Hi. I hope everyone is well and having a great day :) >> > >> > Just a quick question about the mcx (Mellanox 5th generation Ethernet >> > device) drivers >> > https://man.openbsd.org/mcx.4 >> > >> > The man page says nothing more than it supports; >> > ConnectX-4 Lx EN >> > ConnectX-4 EN >> > ConnectX-5 EN >> > ConnectX-6 EN >> > >> > I am looking for some clarity on what features and performance >> > characteristics mcx boasts? >> > >> > For example are the following basic hardware features supported by this >> > driver? >> > IPv4 receive IP/TCP/UDP checksum offload >> > IPv4 transmit TCP/UDP checksum offload >> > VLAN tag insertion and stripping >> > interrupt coalescing >> > >> > And what other features does it support? >> > >> > I also came across a comment in some forum a while back (so high quality >> > information ) that mentioned Mellanox drivers in OpenBSD are SMP safe >> and >> > so not giant-locked. Is this true? >> > >> > Thanks, Andy, >> >
Re: problems with outbound load-balancing (PF sticky-address for destination IPs)
Ah,
Your diagram makes perfect sense now :) Thank you - So it does not have to
undergo a full rehashing of all links (which breaks _lots_ of sessions when
NAT is involved), but also does not have to explicitly track anything in
memory like you say So better than full re-hashing and cheaper than
tracking.
PS; Thank you for confirming; "It therefor routes the same src/dst pair
over the same nexthop as long as there are no changes to the route".
I was getting hung up on the bit in the RFC that says "hash over the packet
header fields that identify a flow", so I was imagining the hashing was
using a lot of entropy including the ports. I guess I should have thought
around that more and read it as "hash over the IP packet header fields that
identify a flow" ;)
I shall go and experiment :)
On Wed, Sep 29, 2021 at 8:45 PM Claudio Jeker
wrote:
> On Wed, Sep 29, 2021 at 08:07:43PM +1000, Andrew Lemin wrote:
> > Hi Claudio,
> >
> > So you probably guessed I am using 'route-to { GW1, GW2, GW3, GW4 }
> random'
> > (and was wanting to add 'sticky-address' to this) based on your reply :)
> >
> > "it will make sure that selected default routes are sticky to source/dest
> > pairs" - Are you saying that even though multipath routing uses hashing
> to
> > select the path (https://www.ietf.org/rfc/rfc2992.txt - "The router
> first
> > selects a key by performing a hash (e.g., CRC16) over the packet header
> > fields that identify a flow."), subsequent new sessions to the same dest
> IP
> > with different source ports will still get the same path? I thought a new
> > session with a new tuple to the same dest IP would get a different hashed
> > path with multipath?
>
> OpenBSD multipath routing implements gateway selection by Hash-Threshold
> from RFC 2992. It therefor routes the same src/dst pair over the same
> nexthop as long as there are no changes to the route. If one of your
> links drops then some sessions will move links but the goal of
> hash-threshold is to minimize the affected session.
>
> > "On rerouting the multipath code reshuffles the selected routes in a way
> to
> > minimize the affected sessions." - Are you saying, in the case where one
> > path goes down, it will migrate all the entries only for that failed path
> > onto the remaining good paths (like ecmp-fast-reroute ?)
>
> No, some session on good paths may also migrate to other links, this is
> how the hash-threshold algorithm works.
>
> Split with 4 nexthops, now lets assume link 2 dies and stuff gets
> reshuffled:
> +=+=+=+=+
> | link 1 | link 2 | link 3 | link 4 |
> +=+=+===+===+=+=+
> | link 1| link 3| link 4|
> +===+
> Unaffected sessions for drop
> ^ ^^^ ^
> Affected sessions because of drop
># #
> Unsing other ways to split the hash into buckets (e.g. a simple modulo)
> causes more change.
>
> Btw. using route-to with 4 gw will not detect a link failure and 25% of
> your traffic will be dropped. This is another advantage of multipath
> routing.
>
> Cheers
> --
> :wq Claudio
>
> > Thanks for your time, Andy.
> >
> > On Wed, Sep 29, 2021 at 5:21 PM Claudio Jeker
> > wrote:
> >
> > > On Wed, Sep 29, 2021 at 02:17:59PM +1000, Andrew Lemin wrote:
> > > > I see this question died on its arse! :)
> > > >
> > > > This is still an issue for outbound load-balancing over multiple
> internet
> > > > links.
> > > >
> > > > PF's 'sticky-address' parameter only works on source IPs (because it
> was
> > > > originally designed for use when hosting your own server pools -
> inbound
> > > > load balancing).
> > > > I.e. There is no way to configure 'sticky-address' to consider
> > > destination
> > > > IPs for outbound load balancing, so all subsequent outbound
> connections
> > > to
> > > > the same target IP originate from the same internet connection.
> > > >
> > > > The reason why this is desirable is because an increasing number of
> > > > websites use single sign on mechanisms (quite a few different
> > > architectures
> > > > expose the issue described here). After a users outbound connection
> is
> > &
Re: problems with outbound load-balancing (PF sticky-address for destination IPs)
Hi Claudio,
So you probably guessed I am using 'route-to { GW1, GW2, GW3, GW4 } random'
(and was wanting to add 'sticky-address' to this) based on your reply :)
"it will make sure that selected default routes are sticky to source/dest
pairs" - Are you saying that even though multipath routing uses hashing to
select the path (https://www.ietf.org/rfc/rfc2992.txt - "The router first
selects a key by performing a hash (e.g., CRC16) over the packet header
fields that identify a flow."), subsequent new sessions to the same dest IP
with different source ports will still get the same path? I thought a new
session with a new tuple to the same dest IP would get a different hashed
path with multipath?
"On rerouting the multipath code reshuffles the selected routes in a way to
minimize the affected sessions." - Are you saying, in the case where one
path goes down, it will migrate all the entries only for that failed path
onto the remaining good paths (like ecmp-fast-reroute ?)
Thanks for your time, Andy.
On Wed, Sep 29, 2021 at 5:21 PM Claudio Jeker
wrote:
> On Wed, Sep 29, 2021 at 02:17:59PM +1000, Andrew Lemin wrote:
> > I see this question died on its arse! :)
> >
> > This is still an issue for outbound load-balancing over multiple internet
> > links.
> >
> > PF's 'sticky-address' parameter only works on source IPs (because it was
> > originally designed for use when hosting your own server pools - inbound
> > load balancing).
> > I.e. There is no way to configure 'sticky-address' to consider
> destination
> > IPs for outbound load balancing, so all subsequent outbound connections
> to
> > the same target IP originate from the same internet connection.
> >
> > The reason why this is desirable is because an increasing number of
> > websites use single sign on mechanisms (quite a few different
> architectures
> > expose the issue described here). After a users outbound connection is
> > initially randomly load balanced onto an internet connection, their
> browser
> > is redirected into opening multiple additional sockets towards the
> > website's load balancers / cloud gateways, which redirect the connections
> > to different internal servers for different parts of the site/page, and
> the
> > SSO authentication/cookies passed on the additional sockets must to
> > originate from the same IP as the original socket. As a result outbound
> > load-balancing does not work for these sites.
> >
> > The ideal functionality would be for 'sticky-address' to consider both
> > source IP and destination IP after initially being load balanced by
> > round-robin or random.
>
> Just use multipath routing, it will make sure that selected default routes
> are sticky to source/dest pairs. You may want the states to be interface
> bound if you need to nat-to on those links.
>
> On rerouting the multipath code reshuffles the selected routes in a way to
> minimize the affected sessions. All this is done without any extra memory
> usage since the hashing function is smart.
>
> --
> :wq Claudio
>
>
> > Thanks again, Andy.
> >
> > On Sat, Apr 3, 2021 at 12:40 PM Andy Lemin
> wrote:
> >
> > > Hi smart people :)
> > >
> > > The current implementation of ‘sticky-address‘ relates only to a sticky
> > > source IP.
> > > https://www.openbsd.org/faq/pf/pools.html
> > >
> > > This is used for inbound server load balancing, by ensuring that all
> > > socket connections from the same client/user/IP on the internet goes
> to the
> > > same server on your local server pool.
> > >
> > > This works great for ensuring simplified memory management of session
> > > artefacts on the application being hosted (the servers do not have to
> > > synchronise the users session data as extra sockets from that user will
> > > always connect to the same local server)
> > >
> > > However sticky-address does not have an equivalent for sticky
> destination
> > > IPs. For example when doing outbound load balancing over multiple ISP
> > > links, every single socket is load balanced randomly. This causes many
> > > websites to break (especially cookie login and single-sign-on style
> > > enterprise services), as the first outbound socket will originate
> randomly
> > > from one of the local ISP IPs, and the users login session/SSO (on the
> > > server side) will belong to that first random IP.
> > >
> > > When the user then browses to or uses another part of that same website
> > > which requires additional sockets, the additional sockets will pass
> the SSO
>
Re: Mellanox driver support details https://man.openbsd.org/mcx.4
Hi Theo :) Ok sure, I will put on my cape-of-courage and start reading the source.. I may be some time! On Wed, Sep 29, 2021 at 1:56 PM Theo de Raadt wrote: > We tend to keep our driver manual pages without detailed promises. > They do ethernet, they do it best effort, etc. > > What you want to know can be found by reading the source, or the > commit logs. Since this is a locally written driver, the code is > surprisingly approachable. > > Andrew Lemin wrote: > > > Hi. I hope everyone is well and having a great day :) > > > > Just a quick question about the mcx (Mellanox 5th generation Ethernet > > device) drivers > > https://man.openbsd.org/mcx.4 > > > > The man page says nothing more than it supports; > > ConnectX-4 Lx EN > > ConnectX-4 EN > > ConnectX-5 EN > > ConnectX-6 EN > > > > I am looking for some clarity on what features and performance > > characteristics mcx boasts? > > > > For example are the following basic hardware features supported by this > > driver? > > IPv4 receive IP/TCP/UDP checksum offload > > IPv4 transmit TCP/UDP checksum offload > > VLAN tag insertion and stripping > > interrupt coalescing > > > > And what other features does it support? > > > > I also came across a comment in some forum a while back (so high quality > > information ) that mentioned Mellanox drivers in OpenBSD are SMP safe > and > > so not giant-locked. Is this true? > > > > Thanks, Andy, >
Re: problems with outbound load-balancing (PF sticky-address for destination IPs)
I see this question died on its arse! :) This is still an issue for outbound load-balancing over multiple internet links. PF's 'sticky-address' parameter only works on source IPs (because it was originally designed for use when hosting your own server pools - inbound load balancing). I.e. There is no way to configure 'sticky-address' to consider destination IPs for outbound load balancing, so all subsequent outbound connections to the same target IP originate from the same internet connection. The reason why this is desirable is because an increasing number of websites use single sign on mechanisms (quite a few different architectures expose the issue described here). After a users outbound connection is initially randomly load balanced onto an internet connection, their browser is redirected into opening multiple additional sockets towards the website's load balancers / cloud gateways, which redirect the connections to different internal servers for different parts of the site/page, and the SSO authentication/cookies passed on the additional sockets must to originate from the same IP as the original socket. As a result outbound load-balancing does not work for these sites. The ideal functionality would be for 'sticky-address' to consider both source IP and destination IP after initially being load balanced by round-robin or random. Thanks again, Andy. On Sat, Apr 3, 2021 at 12:40 PM Andy Lemin wrote: > Hi smart people :) > > The current implementation of ‘sticky-address‘ relates only to a sticky > source IP. > https://www.openbsd.org/faq/pf/pools.html > > This is used for inbound server load balancing, by ensuring that all > socket connections from the same client/user/IP on the internet goes to the > same server on your local server pool. > > This works great for ensuring simplified memory management of session > artefacts on the application being hosted (the servers do not have to > synchronise the users session data as extra sockets from that user will > always connect to the same local server) > > However sticky-address does not have an equivalent for sticky destination > IPs. For example when doing outbound load balancing over multiple ISP > links, every single socket is load balanced randomly. This causes many > websites to break (especially cookie login and single-sign-on style > enterprise services), as the first outbound socket will originate randomly > from one of the local ISP IPs, and the users login session/SSO (on the > server side) will belong to that first random IP. > > When the user then browses to or uses another part of that same website > which requires additional sockets, the additional sockets will pass the SSO > credentials from the first socket, but the extra socket connection will > again be randomly load-balanced, and so the remote server will reject the > connection as it is originating from the wrong source IP etc. > > Therefore can I please propose a “sticky-address for destination IPs” as > an analogue to the existing sticky-address for source IPs? > > This is now such a problem that we have to use sticky-address even on > outbound load-balancing connections, which causes internal user1 to always > use the same ISP for _everthing_ etc. While this does stop the breakage, it > does not result in evenly distributed balancing of traffic, as users are > locked to one single transit, for all their web browsing for the rest of > the day after being randomly balanced once first-thing in the morning, > rather than all users balancing over all transits throughout the day. > > Another pain; using the current source-ip sticky-address for outbound > balancing, makes it hard to drain transits for maintenance. For example > without source sticky-address balancing, you can just remove the transit > from the Pf rule, and after some time, all traffic will eventually move > over to the other transits, allowing the first to be shut down for whatever > needs. But with the current source-ip sticky-address, that first transit > will take months to drain in a real-world situations.. > > lastly just as a nice-to-have, how feasible would a deterministic load > balancing algorithm be? So that balancing selection is done based on the > “least utilised” path? > > Thanks for your time and consideration, > Kindest regards Andy > > > > Sent from a teeny tiny keyboard, so please excuse typos. >
Mellanox driver support details https://man.openbsd.org/mcx.4
Hi. I hope everyone is well and having a great day :) Just a quick question about the mcx (Mellanox 5th generation Ethernet device) drivers https://man.openbsd.org/mcx.4 The man page says nothing more than it supports; ConnectX-4 Lx EN ConnectX-4 EN ConnectX-5 EN ConnectX-6 EN I am looking for some clarity on what features and performance characteristics mcx boasts? For example are the following basic hardware features supported by this driver? IPv4 receive IP/TCP/UDP checksum offload IPv4 transmit TCP/UDP checksum offload VLAN tag insertion and stripping interrupt coalescing And what other features does it support? I also came across a comment in some forum a while back (so high quality information ) that mentioned Mellanox drivers in OpenBSD are SMP safe and so not giant-locked. Is this true? Thanks, Andy,
Re: PF Outbound traffic Load Balancing over multiple tun/openvpn interfaces/tunnels
Hi. Sorry for extremely slow reply! Did you add the return routes for your internal subnets into each of the per-tun rdomains? To test your tunnels are setup correctly; Once you have the external interface in rdomain 0, and each VPN instance's tun interface is bound to different rdomains etc, you can test that your tunnel setup is working within the rdomain with "ping -V1 1.1.1.1" (to originate a ping within rdomain 1 for example). If the ping works, but gets lost when routing through the interface pair ( https://man.openbsd.org/pair), then check the routing table in rdomain 1 with "route -T1 show". Your tunnel will be the default gateway within that rdomain, but you will still need routes in the rdomain to get the return packets back to your internal networks. For this in my /etc/hostname.pair1 interface (pair interface that sits in rdomain 1), I add the line "!/sbin/route -T1 add 172.16.0.0/12 192.168.251.2" (where 192.168.251.2 is the IP for the peer-pair interface that sits in my internal rdomain 1). On Wed, May 8, 2019 at 12:09 AM mike42 wrote: > Trying to replicate same setup with pairs and different rdomains for each > tun > and also external interface, after a packet goes through pair interfaces > it's just disapears. > > Any ideas? > > routing in rdomain is set like: > > route -T add default tun > route -T add > > > > > > -- > Sent from: > http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html > >
Re: Raspberry Pi 4 Model B
Have you read the Raspberry Pi instructions from https://ftp.openbsd.org/pub/OpenBSD/6.9/arm64/INSTALL.arm64 ? What does your UART output show after it boots? Andrew On Fri, Sep 24, 2021 at 2:45 PM Joseph Olatt wrote: > Hi, > > I'm trying to load OpenBSD on a Raspberry Pi 4 Model B and I'm not > having much luck. I've tried OpenBSD 6.9's miniroot69.img and the > install process does not go past the U-Boot prompt. > > I tried miniroot70.img from the snapshots directory, as of today, and > after displaying the following line: > > bwfm0: failed loadfirmware of file > brcmfmac43455-sdio.raspberrypi,4-model-b.bin > > it reboots. > > Anybody else have success installing OpenBSD on this particular > hardware? Any insights or suggestions? > > Thank you. > joseph > >
Re: X11 SIGSEGV on VirtualBox
On Fri, Jun 18, 2021 at 3:24 PM Chris Narkiewicz wrote: > > I'm trying to run xenodm on VirtualBox VM. > VirtualBox 6.1.16_Ubuntu r140961 running on Ubuntu 20.04 with Intel > card. VM uses VMSVGA display with NO 3D acceleration. > > Fresh OpenBSD 6.9 install, but I tried latest snapshot - same problem. > > When starting Xorg server, it crashes with SIGSEGV. Does anybody know > why it happens? How can I generate some actionable debug output, such > as stacktrace, to help identify root cause? See the "How to get a core file out of the X server?" section of the Xenocara README [1]. You can then load Xorg and the core file into gdb/lldb. I think ports egdb may do better in some cases? Others who are more knowledgeable can weigh in on that. Potential workarounds: use the "vesa" X driver instead of "vmware"? I think VBox supports that but I don't remember. Another option is efifb/wsfb, which of course requires configuring the VM for UEFI mode and reinstalling. Both probably have lower performance though. -Andrew [1] https://github.com/openbsd/xenocara
Re: C style in OpenBSD
When you write code by yourself: On Tue, Jun 29, 2021 at 6:15 AM Reuben ua Bríġ wrote: > a style i came up with in imitation of some disgusting haskell code. When you write code with others: On Wed, Jun 30, 2021 at 7:34 AM Todd C. Miller wrote: > It is because consistency makes the code > easier to read for anyone familiar with that style. Part of that > means using common idioms that are immediately recognizable by > someone familiar with the style. This reduces the amount of time > is takes someone to understand the code. -- andrew fabbro and...@fabbro.org
altroot weekly.local
Is there any problem with putting ROOTBACKUP=1 in my weekly.local instead of daily.local? I'm backing up to an SD card and it's maybe not fast enough to back up in 24 hours, plus weekly backup would be fine. Many thanks.
Re: Sparc64 LDOM not working past OpenBSD 6.5
I have a T1000, and it runs 6.9 in primary and 7 guests. However, attempts to create and install a new ldom config result in complete loss of the device tree, and consequent inability to boot. restore to factory, and then restore the ldom config created with OBSD 6.3 will produce a working system. This system is available and currently could be used for testing, although not on the public internet, and only during office hours in Europe/London timezone - machine must be shut down out of office hours. Andrew . On Wed, 12 May 2021 at 03:22, Ax0n wrote: > > I have a SunFire T2000 that I originally installed 6.1 on. I set up LDOMs > way back in May 2017. I kept all of the domains up to date until OpenBSD > 6.6. After that, LDOMs would no longer work. The system would not boot > unless I reverted back to the single domain default using > bootmode config="factory-default" > > I kind of just forgot about the machine until 6.7 came out. I upgraded, and > got the same errors upon trying to boot. I re-generated the LDOM config as > outlined in this blog post I wrote: > > http://www.h-i-r.net/2017/05/logical-domains-on-sunfire-t2000-with.html > > That is, I dumped the factory-default config, used it as a template for the > new LDOM configuration, edited a config file, applied the config to the > directory and used ldomctl download to apply the LDOM config before > resetting the system. > > Specifically, the errors I get now (and yes, some are repeats, but it's ALL > I get from the console while booting) are: > > ERROR: /pci@780: Invalid hypervisor argument(s). function: b4 > ERROR: /pci@780: Invalid hypervisor argument(s). function: b4 > ERROR: /pci@780: Invalid hypervisor argument(s). function: b5 > WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node > WARNING: /pci@7c0/pci@0/pci@1/network: Missing network-vpd MD node > > And after that, the system hangs and I must exit to the ALOM system > controller prompt to do anything further, such as revert the configuration > and reset to make the system able to boot again. > > I searched and found one other person with this problem a while back ago, > but no resolution. I have hardware right here in front of me and I'm not > afraid to run -CURRENT and/or test patches to help. I am also willing to > provide remote SSH access to the system controller if someone wants to hack > on the hardware directly if it would help, though I think there are a few > LDOM-capable sparc64 machines in developers' hands already. > > dmesg: > console is /virtual-devices@100/console@1 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2021 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 6.9 (GENERIC.MP) #794: Sun Apr 18 12:34:31 MDT 2021 > dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP > real mem = 34225520640 (32640MB) > avail mem = 33608228864 (32051MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root: Sun Fire T200 > cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu2 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu3 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu4 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu5 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu6 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu7 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu8 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu9 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu10 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu11 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu12 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu13 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu14 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu15 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu16 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu17 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu18 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu19 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu20 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu21 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu22 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu23 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu24 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu25 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu26 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1200 MHz > cpu27 at mainb
Re: Minor upgrade issue
On Tue, May 04, 2021 at 10:19:14AM -0400, Steven Shockley wrote: > When following https://www.openbsd.org/faq/upgrade69.html, I noticed a minor > error when deleting the Perl files: > > : rm -f /usr/bin/podselect \ > > /usr/lib/libperl.so.20.0 \ > [...] > > /usr/share/man/man3p/Pod::Select.3p > rm: /usr/libdata/perl5/amd64-openbsd/Tie: is a directory > rm: /usr/libdata/perl5/amd64-openbsd/auto/Tie: is a directory > > Maybe it should be rm -rf? Or I missed a step. Of course I could just use > sysclean. Thanks. Added the -r back, it was in current.html. Thanks!
Release schedule/general product engineering
One of the key strengths of OpenBSD that it is well engineered - and consequently robust and reliable. Management of the release engineering is key to this. (Cathedral, not bizarre). However, release engineering is no longer mentioned on the home page of www.openbsd.org, and I could find no mention of it anywhere on the site. I wanted to know approximately when the next release would be available to decide whether to install 6.8, a snapshot or wait for 6.9 for a machine I have prepped and am going to configure "real soon now". I also can no longer find architecture-specific change logs (to see if work has been done that might affect Sparc64 installs, and make things different from when I installed 6.8 on this hardware last time). *** I think it is worth making this info more visible both for existing users (eg me) and potential future users *** I believe there will be future users (Netcraft notwithstanding) - people are often p'd off by other operating systems introducing new features they don't need which clobber the old ones they do - and might want to know there is a better way! (Even if they don't use Sparc64). [Written in anticipation of a general drift away from Intel and towards Arm by both server and workstation users]. There is also the possibility that people who have been hit by malware might want a more secure solution. regards Andrew
Re: native wireguard + nat
Please provide your whole pf.conf file and ifconfig output. It's difficult to help with only a small subset of the configuration. There are PF macros referenced, but they weren't included either. On Thu, Mar 4, 2021 at 10:53 AM Riccardo Giuntoli wrote: > root@ganesha:/etc# cat pf.conf | grep wg > > > > block in on wg > match out on $ext_if from wg0:network to any nat-to $ext_if:0 > pass in on wg from wg:network to ! modulate state > root@ganesha:/etc# > root@ganesha:/etc# ping -c 1 10.10.10.2 > PING 10.10.10.2 (10.10.10.2): 56 data bytes > 64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=84.140 ms > > --- 10.10.10.2 ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 84.140/84.140/84.140/0.000 ms > root@ganesha:/etc# > > root@ganesha:/etc# tcpdump -i vio0 host 10.10.10.2 > tcpdump: listening on vio0, link-type EN10MB > 17:51:48.596335 10.10.10.2.41470 > > m71os.services.getactivationkey.com.https: S 2252122240:2252122240(0) win > 65535 (DF) > ^C > 74 packets received by filter > 0 packets dropped by kernel > root@ganesha:/etc# > > PF nat doesn't translate. > > On Thu, Mar 4, 2021 at 6:43 PM Ashton Fagg wrote: > > > Riccardo Giuntoli writes: > > > > > Hi list. A pleasure to. > > > > > > Got a strange error with native wireguard for roadwarrior config. > > > > Pasting the full error makes people more likely to help you. > > > > > PF NAT doesn't work. > > > > Ok, but what's the error? "doesn't work" isn't very descriptive. > > > > > Someone with the same problem. > > > > > > root@ganesha:/etc# sysctl kern.version > > > kern.version=OpenBSD 6.8 (GENERIC) #5: Mon Feb 22 04:04:49 MST 2021 > > > r...@syspatch-68-amd64.openbsd.org: > > > /usr/src/sys/arch/amd64/compile/GENERIC > > > > > > root@ganesha:/etc# > > > > > -- > Name: Riccardo Giuntoli > Email: tag...@gmail.com > Location: sant Pere de Ribes, BCN, Spain > PGP Key: 0x67123739 > PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 > Key server: hkp://wwwkeys.eu.pgp.net >
boot_config(8) man page issue; and possibly openbsd.org/report.html
Hello everyone, it appears that there may be a way to misinterpret the man page for boot_config(8) in the state of commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + on the github openbsd src mirror. The problem description is under the headline "Issue". There is a realistic chance that I am misunderstanding something. If this is the case, what further measures can I take to narrow down the problem? === Issue === The boot_config(8) man page reads: [quote] The Ethernet card is not detected at boot because the kernel configuration does not match the physical hardware configuration, e.g. wrong IRQ in OpenBSD/i386. [...] UKC> find ne [...] 25 ne1 at isa0 port 0x300 size 0 iomem -1 iosiz 0 irq 10 drq -1 drq2 -1 flags 0x0 [...] ne1 seems to match the configuration except it uses IRQ 5 instead of IRQ 10. [...] UKC> change ne1 [...] irq [10] ? 5 [\quote] Note, that the line that is longer than 72 characters in this email is also longer than 72 characters in the original manual page. I selfishly chose a more accurate quote of the manual page over breaking the line. Plese let me know, in case this is a serious problem. Maybe https://www.openbsd.org/report.html should be augmented to refer to this specific quotation problem, in case it is important enough to document properly. The sentence "ne1 seems to match the configuration except it uses IRQ 5 instead of IRQ 10" has two ways of being interpreted: (1) the kernel configuration is using IRQ 5 and (2) the hardware configuration is using IRQ 5. After having misunderstood the sentence by assuming meaning (1) and noticing the inconsintency with the other relevant lines in the above quote of the man page, I suggest clarifying the sentence like so (change marked with square brackets): "ne1 seems to match the configuration except it [is supposed to use] IRQ 5 instead of IRQ 10" . One even more explicit option is: "ne1 [in the kernel configuration] seems to match [the hardware] configuration except [for the IRQ being used. The kernel currently uses IRQ 10 and the hardware uses IRQ 5, so the kernel configuration needs to be adjusted to match the hardware configuration.]" I want to thank the tireless efforts which have gone and are currently going into maintaining the exceptionally high documentation standards of OpenBSD. In case my suggestions above are overly pedantic, I sincerely apologize. === Affected Man Page File === /share/man/man8/boot_config.8 in commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + Thank you very much for your time. Kind regards, Andrew Easton
pkg_info(1) manpage issue
Hello everyone, it appears that there may be a way to misinterpret the man page for pkg_info(1) in the state of commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + on the github openbsd src mirror. The problem description is under the headline "Issue". There is a realistic chance that I am misunderstanding something. If this is the case, what further measures can I take to narrow down the problem? === Issue === The uninstalled packages are supposed to be listed together with their one-line summary. The manual page accessible with $ man 1 pkg_info; reads: [quote] When browsing through uninstalled packages, running pkg_info -I *.tgz will report a summary line for each package, so that it is possible to run pkg_info pkgname.tgz to obtain a longer package description, and pkg_add -n pkgname.tgz to check that the installation would proceed cleanly, including dependencies. [\quote] Copy-pasting the command "pkg_info -I *.tgz" from the manual page into the terminal yields the following error: computer$ pkg_info -I *.tgz Invalid spec: *.tgz Invalid spec: *.tgz computer$ Even calling pkg_info(1) with doas(1) yields the same behaviour: computer$ doas pkg_info -I *.tgz Invalid spec: *.tgz Invalid spec: *.tgz computer$ Note that there is a relatively long pause between the two "Invalid spec" messages both with and without doas(1). In which way am I misunderstanding the manual page for pkg_info(1) for the specific operation of browsing uninstalled packages and showing a summary line? === Affected Man-Page File === /usr.sbin/pkg_add/pkg_info.1 in commit 0b249e2164be2385bc6a5e82814435649b2b06e0 Date: Sun Jan 24 10:21:43 2021 + Kind regards, Andrew Easton
How to unlock a serial port
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? Andrew
Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states
The missing 256 MB memory is probably stolen by the onboard video; it may be possible to reduce this to a smaller amount via a BIOS setting. You might also try fiddling with any available ACPI settings, e.g. sleep states, etc. (IIRC my VIA Epia M had a setting for whether "sleep" meant S1 or S3.) And I kinda wonder if that unexplained 10-pin CN2 header might be a serial port? Although since it doesn't show up in dmesg, maybe not... I was about to ask if the ACPI dump differed between PXE vs. hdd boot, but then I realized that was impossible to check given the crash. :-) If you could boot another OS from both hdd and PXE, maybe compare ACPI dumps to see if the BIOS changes something? Another workaround would be to 'boot -c' and disable acpi0, but that of course doesn't help fix the bug. -Andrew
Re: Conditions that can trigger a package upgrade?
On Wed, Nov 04, 2020 at 01:12:23PM -0500, Jeremy O'Brien wrote: > On Wed, Nov 4, 2020, at 11:37, Chris Bennett wrote: > > Easy answer. System libraries that these packages were built with have > > changed. Package is the same except for being rebuilt with newer > > libraries. > > > > This demonstrates that I don’t understand the mechanism by which these > upgrade decisions are made then. How can pkg_add determine that a given > package was built against newer libraries if there is nothing in the package > header (+CONTENTS) indicating such? I assumed this would manifest itself in > the package signature in some way, since pkg_add is clearly making an upgrade > decision here. Or there is of course the possibility that there *is* some > information there that I’m overlooking. > > > Are you upgrading to a newer stable/release? > > Same answer. > > > > Are you getting this problem running pkg_add -u multiple times on the > > same system without changing to a newer version or snapshot? > > > > Then something is wrong. (Assumimg you are actually running the actual > > pkg_add -u) > > Check to make sure that you do not have any packages that have been > > since dropped. gettext caused me problems a good while back > > > > Please supply a little more info. That helps people to decide whether > > they want to answer or not. Most likely you don't have any problem. > > Have you read all of the relevant man pages? pkg_* > > > > Multiple times. My problem is that the documentation appears to be written > for a user of OpenBSD, not necessarily someone trying to fully grok the inner > workings of exactly how the pkg_* tools work. I’ve tried reading the perl > directly, but I haven’t found anything that seemed like a smoking gun. I > guess what I want to know is, what *exactly* is pkg_add doing/comparing to > determine that an upgrade is needed? It seems you haven't read enough. You might want to start with some of the fine documentation on the internals that espie@ has written, signatures are mentioned right in the intro, with a pointer to OpenBSD::Signature. http://man.openbsd.org/OpenBSD::Intro Of course, that doesn't explain how signatures work and the implementation is slightly more complex. https://github.com/openbsd/src/blob/master/usr.sbin/pkg_add/OpenBSD/Signature.pm Not entirely sure why it wants to update from the information I saw in this thread, but you could likely instrument the signature comparison to find out. l8rZ, -- andrew - http://afresh1.com Computer analyst to programmer: "You start coding. I'll go find out what they want."
Approved way to update installed ports after system upgrade?
What's the standard way to upgrade installed ports after a system upgrade? I've been trying to figure out how to do this properly, and it doesn't seem to have any mention in the FAQ. Thanks in advance.
Re: UTF-8 problem with php-7.4
On Thu, Sep 24, 2020 at 11:30:35AM +0200, Boudewijn Dijkstra wrote: > Op Thu, 24 Sep 2020 02:56:51 +0200 schreef Andrew Hewus Fresh > : > > On Wed, Sep 23, 2020 at 09:11:44AM +0200, Boudewijn Dijkstra wrote: > > > Op Thu, 10 Sep 2020 04:01:30 +0200 schreef Bambero : > > > > Hi, > > > > > > > > It seems that perl regular expressions lost one polish letter (ą): > > > > https://www.compart.com/en/unicode/U+0105 > > > > > > > > I can see this problem only under OpenBSD 6.7 with php-7.4 (same > > > > version of php under linux is OK) > > > > > > > > Ex.: > > > > > > > > PHP 7.4.10 or 7.4.5 > > > > > > > int(1) // OK > > > > > > > > PHP 7.4.10 or 7.4.5 > > > > > > > int(0) // UPS??? > > > > > > > > PHP 7.3.21 > > > > > > > int(1) // OK > > > > > > > > PHP 7.3.21 > > > > > > > int(1) // OK > > > > > > > > Any ideas how to fix that? > > > > > > > > Regards, > > > > Bambero > > > > > > The same happens with any UTF-8 sequence that ends in 0x85. I guess > > > (a part of) PHP's PCRE code is not in UTF-8 mode, causing triggers > > > onCHAR_NEL (=0x85). > > > > I don't know a lot about PHP or the external PCRE library, but my guess > > would be that php is treating the string as bytes not characters. Can > > you try using the "u" (PCRE_UTF8) modifier? > > > > https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php > > Indeed with "u" the expected 1 is returned! Now the question is, why is this > needed on OpenBSD but not in Linux or Windows? There are many unicode related changes in php 7.4, so I'm sure they fixed something. https://www.php.net/ChangeLog-7.php I would guess that linux and windows both default to a UTF-8 locale, while OpenBSD defaults to the C locale. Does the out put from locale(1) provide you any hints? Do you get any different results testing it with `LC_ALL=en_US.UTF-8`? I don't know enough about php to know how it determines what locale to use, so that may not have any effect, or you may need to adjust something else. l8rZ, -- andrew - http://afresh1.com Adding manpower to a late software project makes it later.
Re: UTF-8 problem with php-7.4
On Wed, Sep 23, 2020 at 09:11:44AM +0200, Boudewijn Dijkstra wrote:
> Op Thu, 10 Sep 2020 04:01:30 +0200 schreef Bambero :
> > Hi,
> >
> > It seems that perl regular expressions lost one polish letter (ą):
> > https://www.compart.com/en/unicode/U+0105
> >
> > I can see this problem only under OpenBSD 6.7 with php-7.4 (same version
> > of php under linux is OK)
> >
> > Ex.:
> >
> > PHP 7.4.10 or 7.4.5
> > > int(1) // OK
> >
> > PHP 7.4.10 or 7.4.5
> > > int(0) // UPS???
> >
> > PHP 7.3.21
> > > int(1) // OK
> >
> > PHP 7.3.21
> > > int(1) // OK
> >
> > Any ideas how to fix that?
> >
> > Regards,
> > Bambero
>
> The same happens with any UTF-8 sequence that ends in 0x85. I guess (a part
> of) PHP's PCRE code is not in UTF-8 mode, causing triggers on CHAR_NEL
> (=0x85).
I don't know a lot about PHP or the external PCRE library, but my guess
would be that php is treating the string as bytes not characters. Can
you try using the "u" (PCRE_UTF8) modifier?
https://www.php.net/manual/en/reference.pcre.pattern.modifiers.php
> for ($i = 0x75; $i <= 0x825; $i++) {
> $u = mb_chr($i);
> $str = 'dasw' . $u . 'zdas';
> $r = preg_match('/^.{5,64}$/', $str);
> if ($r == 0) {
> printf("%04x:", $i);
> for ($j = 0; $j < strlen($u); $j++) {
> $b = ord(substr($str, 4 + $j));
> printf(" %02x", $b);
> }
> printf(": %s\n", $str);
> }
> }
>
>
> --
> Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
>
Re: Microsoft's war on plain text email in open source
On Wed, Aug 26, 2020 at 2:36 AM Frank Beuth wrote: > “It is a fairly specific workflow that is a challenge for some newer > developers to engage with. As an example, my partner submitted a patch > to OpenBSD a few weeks ago, and he had to set up an entirely new mail > client which didn’t mangle his email message to HTML-ise or do other > things to it, so he could even make that one patch. That’s a barrier to > entry that’s pretty high for somebody who may want to be a first-time > contributor.”" > If someone struggles to send a plain-text email, what are the odds their OpenBSD patch is going to be accepted... -- andrew fabbro and...@fabbro.org
Re: perl hex possible bug
I realized after the fact, that looking at some of the different ways you can write numbers in perl. $n = 1234; # decimal integer $n = 0b1110011; # binary integer $n = 01234; # octal integer $n = 0x1234;# hexadecimal integer $n = 12.34e-56; # exponential notation $n = "-12.34e56"; # number specified as a string $n = "1234";# number specified as a string http://man.openbsd.org/perlnumber On Tue, Jul 21, 2020 at 05:24:34PM -0700, Andrew Hewus Fresh wrote: > On Tue, Jul 21, 2020 at 07:10:34PM -0500, Edgar Pettijohn wrote: > > I was playing around with the hex function in perl. So naturally I > > started with: > > > > perldoc -f hex > > > > Which showed me a few examples namely the following: > > > > print hex '0xAf'; # prints '175' > > print hex 'aF'; # same > > $valid_input =~ /\A(?:0?[xX])?(?:_?[0-9a-fA-F])*\z/ > > > > However, I get the following output: (newlines added for clarity) > > > > laptop$ perl -e 'print hex '0xAf';' > > 373 > > so, you're double-use of single quotes here causes some fun shell > processing. This is the same as: > > perl -e 'print hex 0xAf' > > (although let me re-do that with -E and say) > > $ perl -E 'say hex 0xAf' > 373 > > Well, as you say, that's not what you expect. > > But, perhaps there is an explanation. Lets try without hex. > > $ perl -E 'say 0xAf' > 175 > > interesting, but where's the hex? > > $ perl -E 'say hex 175' > 373 > > ahh, there it is. > > Just to get back on the original page though and avoid the shell > confusion, lets try one last thing. > > $ perl -E 'say hex "0xAf"' > 175 > > And that work. Although I guess we can also > > $ perl -e 'print hex "0xAf"' > 175 > > if you'd like. > > > > laptop$ perl -e 'print hex 'aF';' > > 175 > > > > I'm guessing there is a bug here but not sure if its software or > > documentation. > > > > Thanks, > > > > Edgar > > > > -- > andrew - http://afresh1.com > > Hey! It compiles! Ship it! > -- andrew - http://afresh1.com Hey, I think I see a barn up ahead. -- The American Astronaut
Re: perl hex possible bug
On Tue, Jul 21, 2020 at 07:10:34PM -0500, Edgar Pettijohn wrote: > I was playing around with the hex function in perl. So naturally I > started with: > > perldoc -f hex > > Which showed me a few examples namely the following: > > print hex '0xAf'; # prints '175' > print hex 'aF'; # same > $valid_input =~ /\A(?:0?[xX])?(?:_?[0-9a-fA-F])*\z/ > > However, I get the following output: (newlines added for clarity) > > laptop$ perl -e 'print hex '0xAf';' > 373 so, you're double-use of single quotes here causes some fun shell processing. This is the same as: perl -e 'print hex 0xAf' (although let me re-do that with -E and say) $ perl -E 'say hex 0xAf' 373 Well, as you say, that's not what you expect. But, perhaps there is an explanation. Lets try without hex. $ perl -E 'say 0xAf' 175 interesting, but where's the hex? $ perl -E 'say hex 175' 373 ahh, there it is. Just to get back on the original page though and avoid the shell confusion, lets try one last thing. $ perl -E 'say hex "0xAf"' 175 And that work. Although I guess we can also $ perl -e 'print hex "0xAf"' 175 if you'd like. > laptop$ perl -e 'print hex 'aF';' > 175 > > I'm guessing there is a bug here but not sure if its software or > documentation. > > Thanks, > > Edgar > -- andrew - http://afresh1.com Hey! It compiles! Ship it!
Re: Article OpenBSD: Not Free Not Fuctional and Definetly Not Secure and BSD, the truth blog
On Wed, May 27, 2020 at 9:22 PM Quantum Robin wrote: > While surfing on the Google to learn more about OpenBSD, I encountered this > one: "OpenBSD: Not Free Not Fuctional and Definetly Not Secure ( > https://aboutthebsds.wordpress.com/2013/01/25/20/) > If OpenBSD was to have a sex scandal, I would have hoped for something more colorful. Ho hum. Is the author telling the truth? Or just yet another anti-BSD thing? > The author isn't even lying well, much less telling the truth. -- andrew fabbro and...@fabbro.org
Re: Why does OpenBSD still include Perl in its base installation?
On Tue, May 19, 2020 at 10:19:23PM +0200, Dawid Czeluśniak wrote: > 3. Are there people among this community who think that > the base installation of OpenBSD should not include Perl > and Perl-dependent programs and utilities? I assume there are people in the community who think that OpenBSD should not include a lot of things, fortunately it is not the community who decides what OpenBSD becomes, but instead the developers. > Looking at FreeBSD for a moment it seems like Perl left the > base system in May 2002 (18 years ago)[0]. > In a nutshell the rationale was more or less the following[1]: > > > It appears that having Perl in the base distro has > > the following problems: > > > 1. It increases the distro image size. FreeBSD's minimal iso download is 370M while OpenBSD's is largest install media is 450M, however if you are looking for a more minimal install of OpenBSD, you can ~10M cd67.iso and avoid a little bit by only installing the absolutely necessary sets. https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.1/ http://ftp.openbsd.org/pub/OpenBSD/6.7/amd64/ In my opinion, the things that OpenBSD includes in the base system provide an excellent trade-off between size and utility. 18 years ago, an extra 60M of installed files may have made a difference. These days, it's insignificant. > > 2. It forces everyone to use the same version of Perl. It forces everyone to use the same default version of perl, and in exchange promises working packages for programs written in perl. There are several ways to manage having additional versions of perl installed if you need them. Both perlbrew and plenv come to mind. https://perlbrew.pl/ https://github.com/tokuhirom/plenv > > 3. If someone tries to install over that version or just even patch it, > > it can break stuff in BSD which needed the old version. I patch the in-base perl regularly, both breaking stuff and not. Not knowing what you're doing is a not only a great way to learn, but also a great way to break stuff. > > 4. Installing multiple copies imposes weird symlink tricks > > or else breaks other stuff. See above for some ways to do this that work really well, these days that's mostly a solved problem, but it does require both reading and understanding. > All comments and opinions are appreciated. Thanks! Oh good. Perl fits a really important niche between shell scripts and C, its combination of "whipupitude" and "manipulexity" make it great for a large range of tasks. While there are now several languages that also fit into that space, choices between them boil down to personal preference and momentum. The fact that there are so many lines of perl doing the amazingly complex work of managing the package system means that it is here to stay. Unix is full of text streams and having a tool available that excels at processing text is a significant benefit to the OpenBSD base system. Having perl in base was one of the things that brought me joy when I started using OpenBSD and it continues to bring me joy. > [0] https://lists.freebsd.org/pipermail/freebsd-announce/2002-May/000823.html Being the OpenBSD "Perl5 guy", I consider keeping OpenBSD's "base perl" up to date well worth the effort and don't think it is a significant amount of work. There has been some headway by the perl5-porters in removing things from the perl core. Go see the last few upgrade guides where there are instructions on deleting the modules that have been removed. FreeBSD's incompatibility with the Perl 5 release cycle, where Perl gets security updates for the current and previous release, would have meant that the maintainer there would need to do significant work to backport fixes to several old versions of perl. That can be "hellish", but fortunately OpenBSD does not have that particular problem. Fortunately, I can count the number of backwards incompatible changes to Perl since I've been using it on one hand, so importing those new versions into OpenBSD is generally the work of only a few days, most of which turns out to be uneventful testing that things still work. > [1] https://bsd.slashdot.org/comments.pl?sid=32564=3513689 See above. l8rZ, -- andrew - http://afresh1.com I wish life had an UNDO function.
Re: USB 3.0 flash drive not functional
So I've confirmed that sd_get_parms is returning -1 here (by using
printf() statements in /usr/src/sys/scsi/sd.c):
1671: if (sd_read_cap(sc, flags) != 0)
1672:return -1;
Then then sets this error variable to -1:
218: error = sd_get_parms(sc, sd_autoconf);
Then this check is false, and is bypassed:
222: if (error == 0) {
223: printf("%s: %lluMB, %u bytes/sector, %llu sectors",
...
This explains why I'm not seeing seeing the "bytes/sector" output.
On Tue, May 12, 2020 at 10:15 PM Andrew Klaus wrote:
>
> I recently tried using a USB Flash Drive (64GB Capacity) under OpenBSD
> 6.7 on both amd64 and arm64. It's detected as a umass0 device, but
> won't display the disksize/sector line in dmesg and is not available
> for me to use as a drive. This drive does work on other operating
> systems, so I know the drive is functional.
>
> I compiled with options SCSIDEBUG and UMASS_DEBUG, and now seeing this in
> dmesg:
>
> umass0 at uhub0 port 9 configuration 1 interface 0 "PNY Technologies
> USB 3.0 FD" rev 3.00/1.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus4 at umass0: 2 targets, initiator 0
> probe(umass0:1:0): got 36 of 55 bytes of inquiry data:
> --
> 000: 00 80 06 02 33 00 00 00 50 4e 59 00 00 00 00 00
> 016: 55 53 42 20 33 2e 30 20 46 44 00 00 00 00 00 00
> 032: 00 00 00 00
> --
> probe(umass0:1:0): got 55 of 55 bytes of inquiry data:
> --
> 000: 00 80 06 02 33 00 00 00 50 4e 59 00 00 00 00 00
> 016: 55 53 42 20 33 2e 30 20 46 44 00 00 00 00 00 00
> 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 048: 00 00 00 00 00 00 00
> --
> scsi_inqmatch: match priority 2. T_DIRECT T_REMOV <"", "", "">
> sd0 at scsibus4 targ 1 lun 0: SCSI/SPC-4 removable
> serial.154b..
> probe(umass0:1:0): state 0, luns 1, openings 1
> probe(umass0:1:0): flags (0x0801)
> probe(umass0:1:0): quirks (0x4008)
> sd0(umass0:1:0): Check Condition (error 0) on opcode 0x1e
> sd0(umass0:1:0): Check Condition (error 0) on opcode 0x9e
> sd0(umass0:1:0): read capacity 10 data:
> --
> 000: 00 00 00 00 00 00 00 00
> --
> sd0(umass0:1:0): Check Condition (error 0) on opcode 0x1e
> sd0(umass0:1:0): Check Condition (error 0) on opcode 0x9e
> sd0(umass0:1:0): read capacity 10 data:
> --
> 000: 00 00 00 00 00 00 00 00
> --
>
> When trying to edit it under fdisk, it gives me Device not configured:
>
> # fdisk -e /dev/rsd0c
> # fdisk: /dev/rsd0c: Device not configured
>
> I presume this has to something to do with the "read capacity 10 data"
> showing null bytes. I looked at this field with other (working) USB
> Flash drives and they have non-null data here.
>
> My knowledge in this area is limited, but I'd like to learn how to fix
> this. I know I could just get another flash drive, but I enjoy the
> challenge.
>
> Any pointers on where to go from here would be really appreciated.
>
> Thanks!
USB 3.0 flash drive not functional
I recently tried using a USB Flash Drive (64GB Capacity) under OpenBSD 6.7 on both amd64 and arm64. It's detected as a umass0 device, but won't display the disksize/sector line in dmesg and is not available for me to use as a drive. This drive does work on other operating systems, so I know the drive is functional. I compiled with options SCSIDEBUG and UMASS_DEBUG, and now seeing this in dmesg: umass0 at uhub0 port 9 configuration 1 interface 0 "PNY Technologies USB 3.0 FD" rev 3.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus4 at umass0: 2 targets, initiator 0 probe(umass0:1:0): got 36 of 55 bytes of inquiry data: -- 000: 00 80 06 02 33 00 00 00 50 4e 59 00 00 00 00 00 016: 55 53 42 20 33 2e 30 20 46 44 00 00 00 00 00 00 032: 00 00 00 00 -- probe(umass0:1:0): got 55 of 55 bytes of inquiry data: -- 000: 00 80 06 02 33 00 00 00 50 4e 59 00 00 00 00 00 016: 55 53 42 20 33 2e 30 20 46 44 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 048: 00 00 00 00 00 00 00 -- scsi_inqmatch: match priority 2. T_DIRECT T_REMOV <"", "", ""> sd0 at scsibus4 targ 1 lun 0: SCSI/SPC-4 removable serial.154b.. probe(umass0:1:0): state 0, luns 1, openings 1 probe(umass0:1:0): flags (0x0801) probe(umass0:1:0): quirks (0x4008) sd0(umass0:1:0): Check Condition (error 0) on opcode 0x1e sd0(umass0:1:0): Check Condition (error 0) on opcode 0x9e sd0(umass0:1:0): read capacity 10 data: -- 000: 00 00 00 00 00 00 00 00 -- sd0(umass0:1:0): Check Condition (error 0) on opcode 0x1e sd0(umass0:1:0): Check Condition (error 0) on opcode 0x9e sd0(umass0:1:0): read capacity 10 data: -- 000: 00 00 00 00 00 00 00 00 -- When trying to edit it under fdisk, it gives me Device not configured: # fdisk -e /dev/rsd0c # fdisk: /dev/rsd0c: Device not configured I presume this has to something to do with the "read capacity 10 data" showing null bytes. I looked at this field with other (working) USB Flash drives and they have non-null data here. My knowledge in this area is limited, but I'd like to learn how to fix this. I know I could just get another flash drive, but I enjoy the challenge. Any pointers on where to go from here would be really appreciated. Thanks!
Re: loading DBD-Pg under base httpd, works but it's wrong way
On Fri, May 01, 2020 at 01:11:12AM -0400, Chris Bennett wrote: > On Thu, Apr 30, 2020 at 08:16:05PM -0700, Andrew Hewus Fresh wrote: > > I'm assuming this is using slowcgi, is that correct? > > Yes > > > > > Depending on your use case, it might be easier to have a separate > > slowcgi process for just this script and then add OpenBSD::Pledge(3p) > > and possibly OpenBSD::Unveil(3p) to limit what the script can do. This > > could work with slowcgi's `-u` flag to have this script run as a > > specific user. > > > > I have several domains. Some are running very limited scripts. > > For several, just some very basic stuff. Pledge and Unveil would work > great for those. I'll check into that. They write files and send emails. Do note that httpd expects that slowcgi will be chrooted to the same place as httpd and sets some of the FCGI_PARAMS based on finding the scripts in that chroot. It's possible to make that work with a "phantom" directory structure in the httpd chroot that mirrors the scripts you will be running with slowcgi. They don't need to be the full files, empty files that are set as executable work fine for faking the check. With that hack and messing with "root" and "rewrite request" in the location served by that fastcgi should allow you to get the information to the script in the necessary format. Another option is a Plack Middleware that rewrites those variables as necessary. Running slowcgi with the debug (-d) flag is very informative. > One site has a ton of complicated scripts, many in mod_perl that I want > to ditch. You may want to look at some of the options for modules that fake being mod_perl and run under Plack, which has a FastCGI handler that works well with httpd(8). https://metacpan.org/search?q=plack+apache https://metacpan.org/pod/Plack::Handler::FCGI > I am also forking a forum software that's been dropped. > It makes a lot of sense to pull all of those perl scripts into a single > wrapper. It reads/writes to postgresql, sends and receives emails and > can optionally write files. Pledge and Unveil sound like good optional > settings. My preference is to make it portable after ditching some > security issues and dropping mod_perl 1 from it, etc. If those scripts were ported from CGI to mod_perl and not changed significantly, I have had good experience with CGI::Emulate::PSGI which will load those CGIs into a persistent process. The benefit of having been ported to mod_perl is that someone probably created an "init" function that resets all the state necessary at the beginning of the request. https://metacpan.org/pod/CGI::Emulate::PSGI If they were written specifically targeting mod_perl 1, you probably have a slog ahead of you and I don't envy you the task. > This has all been a bit frustrating, but having worked things out, now > it's fun! That's computers for you. l8rZ, -- andrew - http://afresh1.com Real programmers don't document. If it was hard to write, it should be hard to understand.
Re: OpenBSD VPS hoster with unlimited/limited nonfiltered traffic
On Fri, Apr 10, 2020 at 2:55 AM Martin wrote: > I'm looking for relatively cheap VPS with OpenBSD installation support and > with ~1Tb of unfiltered traffic. In any words all in/out VPS ports must be > opened by default. > FYI, virtually any provider who offers KVM-based VMs can run OpenBSD. There are literally tons of KVM-based providers out there. These days, it's no longer a case of "finding a provider that supports OpenBSD" as much as just making sure you're getting a KVM-based VPS (and not OpenVZ, for example). Then you mount the virtual CD of your choice and away you go, booting bsd.rd and installing your OS. Bigger players like Vultr will have fancy features like snapshots, APIs, etc. I like Vultr, but I also like supporting indy companies. BuyVM.net is one I can recommend, but you'll need to open a ticket to have them remove the mail port restrictions. RamNode is another quality host. I also have had a good experience at securedragon.net. Regardless of who you choose, I'd open a pre-sales ticket just to confirm they support what you want to run and what you want to do. I'd ask specifically if they have the OpenBSD version you want (and if not, every provider I've dealt with is happy to download the .iso and make it available...some even allow you to upload your own ISOs), and also ask about port restrictions. There are some forums dedicated to discussing cheap (and not so cheap) VPSes. I'm partial to lowendtalk.com, but there's also talk.lowendspirit.com and hostballs.com. I can't recommend WebHostingTalk.com any more as it's mostly turned into an advertising/sig spamming forum. -- andrew fabbro and...@fabbro.org
Re: Help: System hang/Lockup using snapshots on Intel i5 NUC?
On Thu, Mar 5, 2020 at 4:48 PM Why 42? The lists account. wrote: > The OpenBSD kernel tells me that there is a serial port / UART (com0 at > isa0 port 0x3f8/8 irq 4: ns16550 ...) but I've taken the NUC to pieces > and I cannot see anything on the board that looks like a serial port > header. I found this Intel documentation about a dual serial port header on the NUCs (and the necessary cable), but I don't know if it applies to your model: https://www.intel.com/content/www/us/en/support/articles/17881/intel-nuc.html If there's no such header on yours, perhaps that serial port is remotely accessible, e.g. with IPMI serial-over-LAN or Intel vPro remote access? -Andrew
Re: FreeBSD daemon(8)-like command for OpenBSD
On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote: > On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote: > > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen > > : > > > > Properly starting up a daemon process requires several steps, > > > > often involving unveil(2), pledge(2), chroot(2), prviledge > > > > dropping, sometimes fork+exec for privilege separation, and so on > > > > > > The process I need to run is written in Clojure and thus runs on the > > > Java Virtual Machine. Do you have any suggestions on how to best go > > > about making it "daemon-like"? I am not sure that I can call unveil(2), > > > pledge(2) and chroot(2) from Clojure without some strange sorcery. > > > > So not related to only Clojure but rather on runtimes that are large > > and unwieldy, this seems to be exactly why plegde() and unveil() came > > into being in the first place, after seeing things that needs to do > > certain privileged operations at some early point, but because of > > design/runtime/hard-to-pledge or whatever has to run with the sum of > > all privileges, all capabilities at all times and at the same time > > being exposed to potential hostile data. > > Yes. I completely understand the motivation behind pledge, unveil and > similar constructs. I also understand that it sort of runs counter to > using one of the world's most secure-by-default operating systems if you > then run an insecure monstrosity on top of it. I was just starting to > like the OpenBSD experience as a user and sysadmin. :-) > > But I also think that it is unrealistic to expect applications to be > written to the same standard as OpenBSD, given the resources needed for > that. Many startups would never get off the ground if that were the > case. > > > I can fully see why Ingo would say "I would not run things like that > > exposed", partly because I figure he actually has a choice to not do > > it, but regardless of what electric fences you like (Selinux, > > capsicum, pledge/unveil, chroots) if you create a huge monolith > > running in an environment which actively prevents you from activating > > any kinds of protections, then I can see how you would see some > > friction. > > I would like to get more information about doing application programming > for an OS like OpenBSD. I understand that if you program your > applications in C, you have readily available pledge/unveil, etc. But > many applications are written in higher-level languages, and in my case > at least, it seems to be nearly impossible to write a secure application > without changing to C or some other language that can easily use > OpenBSD's system calls. And for a mediocre programmer, or just an > inexperienced one, it exposes you to a whole host of other problems that > can lead to worse security and quality. > > The solution is probably just to be a good programmer. ;-) > For the record, I am also interested in information on how pledge(2) and unveil(2) would interact with a "higher level language". I would also be happy to learn more about how they interact with assembly. My conceptual understanding can probably still be improved upon. In the spirit of not demanding to much time from my contemporaries I am especially greatful for pointers to conceptual documentation and to implementation documentation. I have the impression that it seems effective to get a conceptual overview first. [[ I have the suspicion that being a good programmer crucially depends on having conceptual understanding. Maybe it also depends on practice.]] Concretely: Just to start off easy, how can I find conceptual documentation on what an operating system "process" is in OpenBSD and how deeply a libc is tied into that by design? As far as I am aware a process has the "current working directory" associated with it, in order to be able to resolve relative paths and is also where "environment variables" are stored. These remind me of dynamic bindings, at least in spirit. I am only aware of plain C having lexical bindings, in contrast to this. (I am also still fuzzy on how intertwined an operating system and a CPU are. From my superficial understanding, e.g. the operating system has to be aware of the MMU. I am concretely speaking of amd64 territory here.) https://man.openbsd.org/process : did not turn up anything https://man.openbsd.org/pledge : where is further information on what a process is? https://man.openbsd.org/unveil : where is further information on what a process is? Best Regards, Andrew
Re: experience with supermicro based Network Devices for 1Gb/s Ipsec throughput
On 01/10/2019 21:17, Lyndon Nerenberg wrote:
>> SYS-5018A-FTN4
>
> If you have any of these, replace them. They have known buggy CPUs
> and will randomly fail without warning. We replaced about a dozen
> of them after >50% failed within the first year of installation.
I have several of these boards that need RMA'ing. Fingers are crossed,
and holding thumbs, that this gets a positive result.
> Note this isn't an OpenBSD problem -- the 5018As are just bad hardware.
> (They also have APIC interrupt issues, most likely due to a buggy ACPI
> implementation.)
I know a lot about the above bricking issue ("Erratum AVR.54") but I
never heard anything about an ACPI problem. Do you have a link to
further information please?
I also have several servers that were produced *after* the SoC was fixed
(C0 stepping instead of B0). I don't know if any ACPI fixes were
implemented though. It would be good to get some kind of understanding
on this.
> We replaced all our SYS-5018A-FTN4s with SYS-5018D-FN8Ts.
Did the slightly more powerful cores (and potential for much more RAM,
plus other various improvements) in the replacement server compensate
sufficiently for the number of cores being halved?
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
pkg_info(1) man page possible error
Hello, I am running OpenBSD in a virtualbox because I am taking a deeper look into it. I was looking for a list of ports packages and read the man page pkg_info(1). That man page it states, "When browsing through uninstalled packages, running pkg_info -I *.tgz will report a summary line for each package [...]" Note the capital eye 'I'. It says so in the VMs man page as well as at https://man.openbsd.org/pkg_info (All Sections ; All Architectures ; OpenBSD-current) (Timestamp: approx. Fri 24 Jan 2020 10:05:00 PM UTC) When I run the command # pkg_info -I *.tgz I get the result Invalid spec: *.tgz Invalid spec: *.tgz # If I run # pkg_info -l *.tgz # NOTE the little ell instead of capital eye I get something that looks like the list the man page describes. Two columns, first being package name and second being a short one line description. If I run # pkg_info -I I get the result pkg_info: Missing package name(s) Usage: <...> Searching for "openbsd pkg_info -I" with duckduckgo just presented the OpenBSD FAQ and Manual Pages and something about a pkg_info -Q bug. I read the man page's descriptions for options -I and -l and it seems to me that -I (capital eye) *should* work the way the man page exemplifies its use or maybe even without an argument. Maybe I am misinterpreting the descriptions. I do not quite understand why requesting the list of packages including a short description works with -l (small ell), which takes a string as an argument. What other information can I provide to clarify where the problem lies? (It may be the man page, pkg_info, "layer 8" or a combination of these three factors.) # uname -a OpenBSD 6.6 GENERIC#4 amd64 Thank you for your time, Andrew Easton
Re: Userland PCI drivers possible in OpenBSD?
Joseph Mayer wrote: > Is there some way I can implement PCI drivers in userland in OpenBSD? > > On a quick Internet search, see some discussion for Linux and NetBSD > e.g. [1] however nothing in OpenBSD. > > I may be interested in operating some PCI device manually from my own > program (run as root or user) in OpenBSD, and I can see this being of > interest to others also, asking therefore. As others have mentioned, poking at PCI configuration space and raw physical memory from userspace is wildly insecure. However, contrary to popular belief, you can in fact poke at devices from userspace on OpenBSD. The primary user of this special ability is the X server, which has a plethora of userspace drivers for graphics cards. (It's almost as dangerous as the inteldrm(4) mess!) While you really really don't want to do this in production, it's handy for experimenting with PCI devices on a development machine. Without further ado, here's how to do it: 1. Use the 'machdep memory' command in the bootloader to carve out a hole in the system's physical memory map. 2. Set the kern.securelevel sysctl to -1. (Told you it's a bad idea.) 3. Set the machdep.allowaperture systel to 2. 4. Become root. 5. Open /dev/pci%d to access PCI bus number %d, and issue PCIOCREAD/ PCIOCWRITE ioctls to access PCI configuration space. See pci(4) for details and the pcidump(8) source for usage examples. 6. Map the device's base address register(s) to somewhere in physical memory space that isn't in use, such as your memory hole. 7. Open /dev/xf86 and mmap() the section of physical address space that you have mapped your device at. As long as the kernel hasn't "claimed" those addresses (i.e. you're mapping the memory hole that you created at boot time) the mmap() will succeed. See xf86(4) for a bit more explanation. Once you've been successful at exploring your shiny new PCI device, and understand how it works, you can write a proper kernel driver for it so that it can actually be used on a normal system and by non-root users. Normal systems run at securelevel=1 (or 2) for good reason, and ideally are also running with machdep.allowaperture=0. (I shall now don my flameproof suit.) Cheers -Andrew
Re: dhcpd and unbound on a small LAN
On Mon, Jan 6, 2020 at 9:26 AM Sonic wrote:
>
> You have it backwards, let dhcp use the information in unbound to
> assign the reserved address:
> ===
> host alice {
> hardware ethernet 20:9e:02:f5:93:60;
> fixed-address alice.home.lan;
> option host-name "alice";
> }
> ===
This is how I do it too, except simplified further by setting the
use-host-decl-names option at a higher scope (see dhcpd.conf(5)); then
you don't need "option host-name ..." for each host.
> Start unbound before dhcpd in your rc.conf.local (ex):
> ===
> unbound_flags="-c /var/unbound/etc/unbound.conf"
> dhcpd_flags="em0"
> ===
The order of directives in rc.conf.local does not matter, as the order
of base daemons is hardcoded in /etc/rc (and does indeed start unbound
before dhcpd); as a matter of fact, 'rcctl enable foo' will sort the
file! (I personally dislike this behavior, since it moves comment
lines away from the things they're commenting on, but I digress...)
The only order that does matter is words within the pkg_scripts
setting, which orders those relative to each other.
> Make sure your resolv.conf points to unbound so that your system can
> resolve the local dns names.
If your uplink interface interface is configured as DHCP, this will
need to be set in dhclient.conf, e.g. "supersede domain-name-servers
127.0.0.1".
-Andrew
Re: Third server now locked up after reboot due to no keyboard attached
On Sun, Dec 15, 2019 at 12:28 PM Nick Holland wrote: > > Well...yeah. > If the boot loader echoed anything, it's behaving As Desired -- a char at > the command line means "STOP ALL BOOTING, I have something special I want > you to do". > > [...] > However, I think there are a few things you might be able to do to solve > your problem... > > 1) BIOS upgrade. Long shot, but maybe? > 2) BIOS config option? Also a long shot, but since I'd call this a > boot firmware bug, maybe some combination of USB related options would > fix this? Always a good idea. If you have console redirection configured in the BIOS, make sure redirection after boot is *disabled*, and configure the serial console in the bootloader instead. I've seen garbage characters produced by the BIOS console on some systems, but the OS and bootloader usually work better. > 3) a boot.conf file should fix -- simply putting "boot" in /etc/boot.conf > should override anything in the keyboard buffer. Need to "control" the > boot? plug in a keyboard and hold down either CTRL key, and you will be > given the boot> prompt. Note that this is not yet implemented in the UEFI bootloader: https://github.com/openbsd/src/blob/43e343f8aa17502e68dbb74fa3dd463280c74fe5/sys/arch/amd64/stand/efi64/efiboot.c#L514-L519 (Compare pc_getshifts() in .../libsa/bioscons.c, which calls BIOS interrupts. Anyone know the UEFI equivalent?) -Andrew
cron output direct to mbox without smtpd?
Hi, I'm setting up an embedded machine that won't be able to send mail to the internet and it seems excessive to leave smtpd running just so root can receive cron job output, but I can't see a way to cut smtpd out of the delivery chain because mail.local doesn't implement sendmail-style command-line options (in particular it doesn't have the -t option to extract the recipient from the message headers) so I can't use it in place of smtpctl in /etc/mailer.conf. I could probably get cron to mail.local delivery working by editing and recompiling cron to change the popen arguments but that seems like more trouble than it's worth in the long run. Is there some other way to do this? Is there a reason I've missed that this is actually just a bad idea? Thanks for your help, -- Andrew Kanaber
Re: Home NAS
On 15/11/2019 10:11, gwes wrote: On 11/14/19 3:52 PM, Andrew Luke Nesbit wrote: On 15/11/2019 07:44, Raymond, David wrote: I hadn't heard about file corruption on OpenBSD. It would be good to get to the bottom of this if it occurred. I was surprised when I read mention of it too, without any real claim or detailed analysis to back it up. This is why I added my disclaimer about "correcting me if I'm wrong because I don't want to spread incorrect information". [...] There was a thread a couple of months ago started by someone either pretty ignorant or a troll. The consensus answer: no more than any other OS, less than many. Thank you gwes, for the clarification. The thread is vaguely coming back to my memory now. I was dipping in and out of it at the time as I didn't have time to study the details at the time. One size definitely doesn't fit all. That is pretty obvious. I never mentioned a blanket rule, and I assume that OP is able to tailor any suggestion to their needs. Backup strategies depend on user's criteria, cost of design and cost of doing the backups - administration & storage, etc. Sure. I don't have a personal archival storage system yet for long term storage that satisfies my specifications because I don't have the infrastructure and medium yet to store it. I plan on investing in LTO tape but I can not afford the initial cost yet. In an ideal world every version of every file lasts forever. Given real limitations, versioning filesystems can't and don't. Indeed. But having archival snapshots at various points in time increases the _probability_ that the version of the file that you need will be present if+when you need it. If your data are critical, invest in a dozen or more portable USB drives. Cycle them off-site. Reread them (not too often) to check for decay. Yes, this is part of the backup system that I'm designing for my NAS, but it's not so much for archiving. If you have much available, get a modern tape system. Yes, as I mentioned above LTO would be great if+when I can afford it. The backup system used over 50 years ago still suitable for many circumstances looks something like this: daily backups held for 1 month weekly backups held for 6-12 months monthly backups held indefinitely offsite. Hold times vary according to circumstances. I think something like this is a good plan. The backup(8) program can assist this by storing deltas so that more frequent backups only contain deltas from the previous less frequent backup. I've not used backup(8) before, thanks for the suggestion. I will have a look. The compromise between backup storage requirements and granularity of recovery points can be mitigated. The way to do it depends on the type and structure of the data: Some data are really transient and can be left out. Source code control systems (or whatever the name is this week) are a good way for intermittent backups to capture a good history of whatever data is around if it's text. I don't understand how SCM's are supposed to help with this... DBs often have their own built-in backup mechanisms. This underscores the difference between file system-level backups, block-level backups, and (for DBs) application-level backups. In particular I'm trying to figure out a generally applicable way of taking a _consistent_ backup of a disk without resorting to single user mode. I think COW file systems might help in this regard but I don't think anything like this exists in OpenBSD. Binary files can be regenerated if the source *and* environment are backed up. Storing the environment is a tricky problem that I haven't found an entirely satisfactory solution for, yet. been there, mounted the wrong tape... what write protect ring? O yeah... me too. My team inherited a hosted service and upon auditing we discovered its backup system was stranger than fiction. But it was so bizarre that we couldn't determine whether it was _supposed_ to be that way or if our reasoning was flawed. A classic type of problem. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Home NAS
Hi Dave, On 15/11/2019 07:44, Raymond, David wrote: I hadn't heard about file corruption on OpenBSD. It would be good to get to the bottom of this if it occurred. I was surprised when I read mention of it too, without any real claim or detailed analysis to back it up. This is why I added my disclaimer about "correcting me if I'm wrong because I don't want to spread incorrect information". The reason why I brought it up on a public mailing list was to find out if anybody else has heard any inkling _at all_ regarding this, even a skerrick of a mention. I have a feeling I may have even heard about it on this list but I'm not sure. If somebody out there genuinely suspects that this happened then it would be good to know so we can clear it up. Kind regards, Andrew On 11/14/19, U'll Be King of the Stars wrote: On 15/11/2019 04:45, Raymond, David wrote: I have done similar things on Linux for years and am now doing them on OpenBSD. Sounds like what you want to do can be done with a simple rsync script. OpenBSD ffs (ufs) should be stable, it has been around for decades in various incarnations. I have never noticed bit rot in this system, though I imagine it could happen if a disk is gradually going bad. Please correct me if I'm wrong because I don't want to spread incorrect information. A couple of months ago I read a couple of reports of filesystem corruption on OpenBSD. I didn't have time to investigate deeply and I don't know if these issues were even real. Even if they were real I don't know if the problem was due to user error or a defect in the OS. Does anybody know anything about this? That's why multiple backups help. Agreed. See below. You might want to set up a raid5 backup, as this detects parity errors. More complicated though. This is exactly the kind of reason that hybrid volume management systems + filesystems such as Btrfs and ZFS have become popular. I do not know anything about OpenBSD's LVM. One weakness in such as system (ask me how I know!) is that if the NAS goes gradually bad, the errors will propagate to the backup. Using rsync without the --delete option most of the time alleviates this somewhat. Only run with --delete when the backup starts getting full and you are confident that your NAS drive is ok. This is an excellent reason for implementing a system that includes not only backups, but long term storage /archives/ too. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Tools for writers
On 05/11/2019 17:38, Ingo Schwarze wrote: Hi, Hello Ingo! Andrew wrote on Sun, Nov 03, 2019 at 12:56:58PM +: [ Pandoc ] is one of the most useful tools I have ever used. If you are writing any sort of documentation then I *highly* recommend checking it out I strongly oppose that point. There is no need at all to bother with pandoc when you write documentation. I think you shoud re-read that, especially the second sentence. Do you realize how ridiculous it is? Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Skype alternatives for OpenBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/11/2019 10:55, Frank Beuth wrote: > Not sure about the original poster but I would be interested in > any end-to-end encrypted video/audio/chat programs that are > available. Have a look at Tox. It might work out for you on a technical level. I don't use Tox. I got involved with the project's development and I left very quickly. Personally I don't even want to be a user if I can help it. This is my own personal issue. If you check it out I sincerely hope you have a better experience than I did. Sociotechnologically it is an important project and I hope it succeeds on that level in the long run. Andrew - -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEE/ASxpcFcqIVqgGgxgfJdKbhCoRcFAl2+tisACgkQgfJdKbhC oRdBugv+P/BIwuNWxmC0kEDiQUWt/E6TjXDwToMch71w0VsWASzM9dUErBTBMOhM BsW2s4J+vbec9PWlBqKogPcU57OlqnzPQgqiBQiCfsf/405DpSIfQcC/U/ZNTG3W RBiWzXFRKzfO3hbRQq8G5Q+mPB9fOffmJLJDosTDdSiPefdPNuH6ClcTTpi98pEZ 67ZQhTAE1IZp6pB1t124LMAz50VRY7mfPYuZBqLCPzFmpflilB0qjWmoH0T9BgMa hFQl8Yd/Bv5ypDTH3n13SsR9uXBR1wGic5j0XmZbaKtygn2eGfZqKBwLCmt+Cfvm ESLP3lG89hK95KstxIRFbPoWhsp+zuMCooIXr62Ik/a0FqHLw8nj9HQCv4FnAoQY KObNvTXsoQec5ojDoRWfPtM+LtjQJ+pYD6xEMYT04OPTKg5/K+HyOaVwCcZFzqdI IpdnO8TeKjNA/qLDAd3z49xgzet+IJDKUYx380XJDSVENkZcz2FNsIrhghXny4lQ ZA0JuJhZ =QUzB -END PGP SIGNATURE-
Re: Disable ftp in pkg_add syspatch sysupgrade
Hi gents,
Sorry for the slow reply, and thank you for all your responses! :D
Raf, you are correct. It seems that the ftp client is performing an http(s)
downloads.
To me this seems unusual (was expecting 'curl' or 'wget' etc to avoid code
duplication) and confusing? What do you think?
Stuart, thanks for your suggestion. This confirmed the ftp client is using
http(s);
[HOME]root@testbsd1:/local#pgrep -lf ftp
40379 /usr/bin/ftp -o -
http://mirror.bytemark.co.uk/pub/OpenBSD/6.5/packages-stable/amd64/quirks-3.124.tgz
Tom/PJ, Understood. Was just very confused why ftp was getting involved..
Anyway, I have tested this some more, and it looks like the issue is
related to when using "flavors", and looks like maybe their is some sort of
timeout occuring maybe.
- We can see that pkg_add is working fine when specifying packages
explicitly;
[HOME]root@testbsd1:/local#pkg_add sudo--gettext bash htop
quirks-3.124 signed on 2019-10-16T20:27:45Z
[HOME]root@testbsd1:/local#pkg_add vim--no_x11-perl-python3-ruby
unzip--iconv bzip2 git fzf
quirks-3.124 signed on 2019-10-16T20:27:45Z
- But throws errors when I try and use flavours which is critical for
installing python for example (NB; This is a different error to before,
where I was getting 'timeout' instead of 'Invalid argument');
[HOME]root@testbsd1:/local#pkg_add python%2 py-pip python%3 py3-pip
py3-setuptools
quirks-3.124 signed on 2019-10-16T20:27:45Z
http://mirror.bytemark.co.uk/pub/OpenBSD/6.5/packages/amd64/py3-setuptools-40.0.0v0.tgz:
ftp: Receiving HTTP reply: Invalid argument
signify: gzheader truncated
Couldn't install py3-setuptools-40.0.0v0
- This package is accessible as seen here;
[HOME]root@testbsd1:/local#wget
http://mirror.bytemark.co.uk/pub/OpenBSD/6.5/packages/amd64/py3-setuptools-40.0.0v0.tgz
/tmp/
--2019-10-30 14:29:28--
http://mirror.bytemark.co.uk/pub/OpenBSD/6.5/packages/amd64/py3-setuptools-40.0.0v0.tgz
Resolving mirror.bytemark.co.uk (mirror.bytemark.co.uk)... 80.68.83.150,
212.110.163.12, 2001:41c8:20:5e6::150, ...
Connecting to mirror.bytemark.co.uk (mirror.bytemark.co.uk)|80.68.83.150|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 731604 (714K) [application/x-gzip]
Saving to: ‘py3-setuptools-40.0.0v0.tgz’
py3-setuptools-40.0.0v0.tgz
100%[===>]
714.46K 270KB/sin 2.6s
- And works if specified on its own;
[HOME]root@testbsd1:/local#pkg_add py3-setuptools
quirks-3.124 signed on 2019-10-16T20:27:45Z
If I try the line with flavors again "pkg_add python%2 py-pip python%3
py3-pip py3-setuptools" it works..
As others would be crying about this too if it were a wide issue, I thought
this was maybe a bad mirror...
So I have now tried every mirror in the UK, and they all do the same thing
- intermittent issues accessing packages when using flavours..
I am not running squid or any kind of web proxy, http and https are being
passed out with nothing more than standard NAT and a pass rule.
I will try and figure out what is going on. Leave this with me. If I find
anything meanful and useful I will let you know. For now, consider this an
issue with my setup..
PS; has anyone managed to get ftpproxy working in an rdomain?
Thanks for your time and responses.. :)
Andy.
On Wed, Oct 30, 2019 at 9:17 AM PJ wrote:
> Am 30.10.19 um 07:32 schrieb tom ryan:
> > On 2019-10-29 20:19, PJ wrote:
> >> Am 28.10.19 um 23:52 schrieb Stuart Henderson:
> >>> On 2019-10-28, Andy Lemin wrote:
> Hi guys,
>
> Does anyone know if it is possible to completely disable ftp in the
> package management utilities; pkg_add, syspatch, sysupgrade etc?
>
> My PKG_PATH references http:// urls, as does /etc/install. But I
> cannot stop these tools trying to use ftp which does not work! :(
> >>> Can you show some example URLs, for example from "pgrep -lf ftp" while
> >>> trying to use one of these utilities?
> >>>
> >>> The only place I would expect to see ftp:// URLs used
> >> grep ftp /usr/sbin/sysupgrade
> > $ grep -ne ftp -e URL -e MIRROR /usr/sbin/sysupgrade
> > 102:0) MIRROR=$(sed 's/#.*//;/^$/d' /etc/installurl) 2>/dev/null ||
> > 103:MIRROR=https://cdn.openbsd.org/pub/OpenBSD
> > 105:1) MIRROR=$1
> > 117:URL=${MIRROR}/snapshots/${ARCH}/
> > 119:URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
> > 136:unpriv -f SHA256.sig ftp -Vmo SHA256.sig ${URL}SHA256.sig
> > 176:unpriv -f $f ftp -Vmo ${f} ${URL}${f}
> >
> > Your point?
>
> I understand that I misread the question, sorry.
>
>
> >>> is when fetching
> >>> certain distfiles while building some things from ports (and they would
> >>> usually fallback to http://ftp.openbsd.org/pub/OpenBSD/distfiles if
> >>> the ftp fetch failed)..
>
>
Re: BACK TO BASICS
On Fri, Oct 11, 2019 at 9:09 AM wrote: > Deep down, I'm actually so saddened to see the original, and still > performing, UNIX has become so divided first splitting into three > *BSD communities, and then further diluted efforts with GNU and the > Linux kernel... > The Unix landscape was fragmented long, long before Linux or the three modern BSDs even existed. -- andrew fabbro and...@fabbro.org
Re: OpenBSD on AWS - pciide/wd issue
On Wed, Sep 4, 2019 at 12:56 PM Pavel Korovin wrote: > The logs showed where it stuck: > > pciide0:0:0: not ready, st=0x0, err=0x00 > wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying > pciide0:0:0: not ready, st=0x0, err=0x00 > wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying I can reproduce this on my local Xen environment with the latest bsd.rd snapshot (OpenBSD 6.6-beta (RAMDISK_CD) #270: Wed Sep 4 11:46:05 MDT 2019); 6.5 works just fine. > For some reason, the boot volume was recognized also as > wd0 at pciide0 channel 0 drive 0: > and then as > sd0 at scsibus1 targ 0 lun 0: SCSI5 0/direct > > As a quick fix I disabled pciide/wd, the instance booted and runs fine. I noticed that in the problematic snapshot, pciide is listed in dmesg *before* any xen stuff, whereas in 6.5, xen0/xbf0/sd0 are listed first, and pciide comes later and says "channel 0 disabled (no drives)". I believe xbf(4) and xnf(4) disable any emulated devices (e.g. wd0, re0) when they load, so maybe they need to load first? Here's a "known good" dmesg from OpenBSD 6.5 + syspatches (up through 010_frag6ecn): OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056964608 (1008MB) avail mem = 1015353344 (968MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (12 entries) bios0: vendor Xen version "4.4.4_40-61.43.2" date 03/21/2019 bios0: Xen HVM domU acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2494.24 MHz, 06-17-06 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,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 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2493.89 MHz, 06-17-06 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured pvbus0 at mainbus0: Xen 4.4 xen0 at pvbus0: features 0x705, 32 grant table frames, event channel 4 "vfb" at xen0: device/vfb/0 not configured "console" at xen0: device/console/0 not configured xbf0 at xen0 backend 0 channel 6: disk scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 4096MB, 512 bytes/sector, 8388608 sectors xnf0 at xen0 backend 0 channel 7: address 00:16:3e:79:85:28 xnf1 at xen0 backend 0 channel 8: address 00:16:3e:46:21:98 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (70bae60fe9b7d0df.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown -Andrew
Re: What is you motivational to use OpenBSD
On Wed, Aug 28, 2019 at 7:45 AM Mohamed salah wrote: > I wanna put something in discussion, what's your motivational to use > OPENBSD The vastly superior mascot and soundtrack. -- andrew fabbro and...@fabbro.org
Re: perl privilege drop
On Thu, Jul 25, 2019 at 09:35:44AM -0600, Theo de Raadt wrote:
> Andrew Hewus Fresh wrote:
> > https://perldoc.perl.org/5.30.0/functions/chroot.html
> > > NOTE: It is good security practice to do chdir("/")
> > > (chdir to the root directory) immediately after a chroot.
> >
>
> The phrasing "good security practice" is quite dissapointing, when it
> is MANDATORY. Much like saying it is not good practice to wipe your bum.
I filed a ticket with some possibly improved wording, lightly based on
what's below.
https://rt.perl.org/Public/Bug/Display.html?id=134314
> It is mandatory because otherwise a program-user can arrange for cwd
> to be outside the jail, and utilize that fact to pivot, and in some
> program path utilizations the chroot then becomes not just pointless..
> it is worse than normal, because it creates a dual-namespace view of
> the filesystem, that is a condition that program and libraries are not
> prepared to operate in.
l8rZ,
--
andrew - http://afresh1.com
What are the unsurpassable real world weaknesses in OpenBSD,
that you know of?
-- Kevin Chadwick
Lots of fake people attacking the project on the mailing lists makes
them a poor resource for users.
-- Theo de Raadt
Re: perl privilege drop
On Thu, Jul 25, 2019 at 07:16:27AM -0500, Edgar Pettijohn wrote:
>
> On Jul 24, 2019 9:06 PM, Andrew Hewus Fresh wrote:
> >
> > On Sat, Jul 20, 2019 at 07:20:23PM -0500, Edgar Pettijohn wrote:
> > > Is there a standard OpenBSD approved method for dropping privileges in
> > > a perl server? Currently looking into Privileges::Drop, but since it
> > > isn't in base makes me curious if there is a better way.
> >
> >
> > It's relatively easy to do it yourself like I did in this Plack example.
> >
> > https://gist.github.com/afresh1/558fc0b4dfbeab0fbd59
> >
> > use POSIX qw( setuid setgid );
> > chroot $root || die "Couldn't chroot to $root: $!";
> > setgid($gid) || die "Couldn't setgid $group [$gid]: $!";
> > setuid($uid) || die "Couldn't setuid $user [$uid]: $!";
> >
>
> That's too easy. I was expecting it to be more difficult.
It was pointed out to me that I missed the chdir after the chroot that
is required to not have a possible leak.
chroot $root || die "Couldn't chroot to $root: $!";
chdir '/'|| die "Couldn't chdir to '/': $!";
https://perldoc.perl.org/5.30.0/functions/chroot.html
> NOTE: It is good security practice to do chdir("/")
> (chdir to the root directory) immediately after a chroot.
Sorry about that!
>
> Thanks,
>
> Edgar
> > I don't know exactly what you're looking for though, so maybe
> > OpenBSD::Pledge(3p) or OpenBSD::Unveil(3p) are more what you want?
> >
> > http://man.openbsd.org/OpenBSD::Pledge
> > http://man.openbsd.org/OpenBSD::Unveil
> >
> >
> > l8rZ,
> > --
> > andrew - http://afresh1.com
> >
> > ($do || !$do) && undef($try) ; # Master of Perl, Yoda is. H?
> >
--
andrew - http://afresh1.com
Whatever happened to the days when hacking started at the cerebral cortex
and not the keyboard?
-- Sid from UserFriendly.org
Re: perl privilege drop
On Sat, Jul 20, 2019 at 07:20:23PM -0500, Edgar Pettijohn wrote: > Is there a standard OpenBSD approved method for dropping privileges in > a perl server? Currently looking into Privileges::Drop, but since it > isn't in base makes me curious if there is a better way. It's relatively easy to do it yourself like I did in this Plack example. https://gist.github.com/afresh1/558fc0b4dfbeab0fbd59 use POSIX qw( setuid setgid ); chroot $root || die "Couldn't chroot to $root: $!"; setgid($gid) || die "Couldn't setgid $group [$gid]: $!"; setuid($uid) || die "Couldn't setuid $user [$uid]: $!"; I don't know exactly what you're looking for though, so maybe OpenBSD::Pledge(3p) or OpenBSD::Unveil(3p) are more what you want? http://man.openbsd.org/OpenBSD::Pledge http://man.openbsd.org/OpenBSD::Unveil l8rZ, -- andrew - http://afresh1.com ($do || !$do) && undef($try) ; # Master of Perl, Yoda is. H?
Re: SCM
On 22/07/2019 16:13, Raul Miller wrote: Both git and OpenBSD run on patches. That said, OpenBSD has a cultural restriction of requiring people to inspect the patches before incorporating them. Adopting git would be a step away from that practice. Does that help make sense of the current situation? Raul, Австин, I hope you don't mind me jumping in. Raul's answer raises fascinating questions about the nature of software development and SCM. Using _any_ SCM system and having meaningful discussion among developers before integrating changes is much more important than the choice of actual SCM system. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
pflow version 10 not set on boot
I noticed that my pflow device keeps rebooting with Netflow version 5, despite "pflowproto 10" being set in /etc/hostname.pflow0. I'm running OpenBSD 6.5 with the latest patches. ifconfig: pflow0: flags=41 mtu 1448 index 9 priority 0 llprio 3 pflow: sender: [] receiver: []:2055 version: 5 groups: pflow /etc/hostname.pflow0: up flowdst []:2055 flowsrc [] pflowproto 10 After boot, if I manually initiate "sh /etc/netstart pflow0", it then starts using version Netflow v10 as expected. I may be able to add to /etc/rc.local to do this on reboot, but thought I'd see if there was anything else that it could be. Thanks, Andrew
Re: Ansible install Re: Reboot and re-link
On 21/06/2019 19:02, Frank Beuth wrote: > I don't want to re-open the hostilities, but installing OpenBSD via > Ansible is very relevant to my interests. I feel exactly the same way and am surprised that Ansible caused hostilities. Can you send me a link to the thread where this happened please? I want to know why, i.e., pros and cons. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: Installing OpenBSD on Supermicro A2SDi-4C-HLN4F
On 15/06/2019 10:36, Jonathan Gray wrote: > On Sat, Jun 15, 2019 at 09:02:11AM +0100, Richard Laysell wrote: >> >> Hello, >> >> I was trying OpenBSD on a Supermicro A2SDi-4C-HLN4F which uses an Intel >> Atom CPU (Denverton). The board boots but most devices are not >> detected because ACPI can't be enabled. >> >> Does anyone know if this is likely to be supported at some point? > > Try a snapshot. ACPI changes were made for a similiar machine > (Lanner NCA-1510) in May. > > However there is no support for the integrated X553 Ethernet at the > moment. Jonathan, thank you for the update. Richard, I am in the market for one of these boards too, or some other C3000 series model. I'm a big fan of Supermicro's C2000 boards because they are so versatile for low-power applications. They are also excellent home servers due to this and the correspondingly low heat and noise. Of course if you have a C2000 series board you would need to ensure that it doesn't suffer from the notorious Erratum AVR.54 defect [1]. Please could you keep us updated re: your progress of getting OpenBSD installed along with the support status of all devices? If so this would be greatly appreciated. Thanks!! [1] A little-known fact is that if you look through Intel's data sheets and whitepapers you can find similar defects in the stepping errata for other SoC's. In my case I found an almost identical example in a recent Celeron or Pentium J-series SoC. To add to my disappointment, I later discovered, entirely coincidentally, that it was used on the controller boards for a model of Synology NAS that I was considering purchasing. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: The su manual doesn't mention use root account by default
On 13/06/2019 07:17, Theo de Raadt wrote: > Mihai Popescu wrote: > >>> ... if no account is provided, root is the default >> >> I always considered that su is coming from _s_uper _u_ser. But maybe I >> am wrong, I am not from old UNIX days. > > incorrect. > > NAME > su - substitute user identity > I never noticed this before. It's my favorite bit of *nix trivia that defies misguided assumptions since I learned that `/etc` is apparently an initialism for "editible text configuration". Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
syspatch(8) and patches requiring fw_update
In the latest mds errata patch, I noticed that one of the steps is to run fw_update. From briefly looking over the syspatch script, I don't see it calling fw_update once a patch is applied. Would you welcome a diff to add support for this? If so I can look at writing one. It would check against the .sig patch file itself, since the .tgz syspatch binary patch doesn't contain any details about needing to run fw_update. A rough set of steps would be: - Pull .sig patch from mirror and verify signature - Parse for fw_update - Once the patch has been applied, run fw_update Please let me know of any feedback to this approach. Andrew
Re: Problems installing 6.5 on Supermicro X11SDV-8C-TP8 motherboard - can't see/find network interfaces
On 19/05/2019 02:08, Don Jackson wrote: > I recently acquired a Supermicro 1019D-FRN8TP server with a X11SDV-8C-TP8 > motherboard. > > When i attempt to install 6.5, (via PXE or USB), none of the network > interfaces are detected. > A dmesg appears below, followed by a dmesg and ifconfig -a from successful > attempt installing FreeBSD 12.0 > > Any advice/recommendations about how I can get OpenBSD to see the network > interfaces? > I’m hoping there is a BIOS setting that will help, but haven’t found it yet….. Hi Don, I had a very similar problem yesterday. It presented itself after a firmware upgrade. There are many anecdotes on the web about firmware upgrades on Supermicro boards causing these types of problems. I don't know what to suggest apart from the fact that there might be some correlation between firmware and these problems. Also, the X11SDV and C3000 boards are relatively new. They are still not fully supported by many operating systems. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: 6.5 PowerPC Packages
On 09/05/2019 14:56, Allan Streib wrote: > Unless https://www.openbsd.org/plat.html is out of date, it doesn't look > like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. I wonder what is the best way to determine interest in getting OpenBSD to work on POWER8/9? My first thought is to ask around in the OpenBSD and OpenPOWER communities. Then to see if there is any natural rapport between them. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 signature.asc Description: OpenPGP digital signature
Re: 6.5 PowerPC Packages
On 09/05/2019 14:26, Henry Bonath wrote: > I'm not sure how many folks out there are PowerPC users What exactly do you mean by PowerPC? I am a user of Apple PowerBook G4, POWER8, and POWER9. I am new to OpenBSD and I intend to experiment with it on these architectures. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
