Re: pkg_add -vV slow progression
On Mon, Sep 18, 2023 at 7:09 PM Otto Moerbeek wrote: > > On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote: > > > Hello, > > > > Is there any recent major change in base packages or pkg_add? > > I ask because the pkg_add -vV is slower than usual at each package, > > most of the time spent in Extracting ... phase. > > I use amd64 recent snapshot. I checked my disk and https downloads, > > they are fine. > > > > Thank you. > > > > Maybe the switching off of softdep? But that's been a while already, > and you don't say if had that enabled. > > -Otto No softdep enabled! I will try another mirror next time, like Stuart said. I checked that mirror with a plain download inside a browser, it was fine, maybe things go bad after some repetitive downloads, I had this before. Thanks.
PHP scattered crosswalk..
Hello everyone and Stuart in particular, I just grasped that after my station upgrade to 7.3 my PHP situation is the following: Information for inst:php-8.0.29 Required by: pecl80-imagick-3.7.0p1 pecl80-memcached-3.2.0p0 and more.. Information for inst:php-8.1.21 Required by: pear-utils-1.10.19p3 And it doesn appear to me the best as from inst:php-8.0.29 depend all my PHP extensions and two pecl and from inst:php-8.1.21 depends only the pear-utils (and PHP extensions repositiory) if I'm not wrong, nice uh? What is your best suggestion, I could try to go ahead with inst:php-8.0.29 as my working environment and not caring too much about pear requirements, or it is better to try to fix situation upgrading everything to php-8.1.21? Thanks in advance, -- Daniele Bonini
Re: pfsync/rdomain broken on -current (works on 7.3)
On 9/18/23 8:59 PM, Stuart Henderson wrote:
On 2023-09-18, Mark Patruck wrote:
i've already wrote to dlg@, but also want to know if others see
the same behavior or at least inform about it.
pfsync(4) in combination with rdomain(4) doesn't work anymore on
a fresh -current. I see packets on pfsync0, but nothing leaves
the machine, so no states are synchronised.
pfsync had a big rewrite between 7.3 and -current. Setting rtableid
in the packet header was present in the 7.3 version but dropped in the
rewrite; can you try this?
Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.321
diff -u -p -r1.321 if_pfsync.c
--- if_pfsync.c 16 Sep 2023 09:33:27 - 1.321
+++ if_pfsync.c 18 Sep 2023 18:59:14 -
@@ -1537,6 +1537,7 @@ pfsync_sendout(struct pfsync_softc *sc,
imo.imo_ifidx = sc->sc_sync_ifidx;
imo.imo_ttl = PFSYNC_DFLTTL;
imo.imo_loop = 0;
+ m->m_pkthdr.ph_rtableid = sc->sc_if.if_rdomain;
if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &imo, NULL, 0) == 0) {
counters_pkt(sc->sc_if.if_counters, ifc_opackets,
The diff works fine on two of my systems. Traffic is flowing
between syncdevs again. Thanks Stuart.
--
Mark Patruck ( mark at wrapped.cx )
GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51
https://www.wrapped.cx
Re: pkg_add -vV slow progression
On 2023-09-18, Otto Moerbeek wrote: > On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote: > >> Hello, >> >> Is there any recent major change in base packages or pkg_add? >> I ask because the pkg_add -vV is slower than usual at each package, >> most of the time spent in Extracting ... phase. >> I use amd64 recent snapshot. I checked my disk and https downloads, >> they are fine. >> >> Thank you. >> > > Maybe the switching off of softdep? But that's been a while already, > and you don't say if had that enabled. Does it make a difference if you use a different mirror? -- Please keep replies on the mailing list.
Re: pfsync/rdomain broken on -current (works on 7.3)
On 2023-09-18, Mark Patruck wrote:
> i've already wrote to dlg@, but also want to know if others see
> the same behavior or at least inform about it.
>
> pfsync(4) in combination with rdomain(4) doesn't work anymore on
> a fresh -current. I see packets on pfsync0, but nothing leaves
> the machine, so no states are synchronised.
pfsync had a big rewrite between 7.3 and -current. Setting rtableid
in the packet header was present in the 7.3 version but dropped in the
rewrite; can you try this?
Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.321
diff -u -p -r1.321 if_pfsync.c
--- if_pfsync.c 16 Sep 2023 09:33:27 - 1.321
+++ if_pfsync.c 18 Sep 2023 18:59:14 -
@@ -1537,6 +1537,7 @@ pfsync_sendout(struct pfsync_softc *sc,
imo.imo_ifidx = sc->sc_sync_ifidx;
imo.imo_ttl = PFSYNC_DFLTTL;
imo.imo_loop = 0;
+ m->m_pkthdr.ph_rtableid = sc->sc_if.if_rdomain;
if (ip_output(m, NULL, NULL, IP_RAWOUTPUT, &imo, NULL, 0) == 0) {
counters_pkt(sc->sc_if.if_counters, ifc_opackets,
Re: pkg_add -vV slow progression
On Sun, Sep 17, 2023 at 09:17:58PM +0300, Mihai Popescu wrote: > Hello, > > Is there any recent major change in base packages or pkg_add? > I ask because the pkg_add -vV is slower than usual at each package, > most of the time spent in Extracting ... phase. > I use amd64 recent snapshot. I checked my disk and https downloads, > they are fine. > > Thank you. > Maybe the switching off of softdep? But that's been a while already, and you don't say if had that enabled. -Otto
pfsync/rdomain broken on -current (works on 7.3)
Hi, i've already wrote to dlg@, but also want to know if others see the same behavior or at least inform about it. pfsync(4) in combination with rdomain(4) doesn't work anymore on a fresh -current. I see packets on pfsync0, but nothing leaves the machine, so no states are synchronised. For example (w/ or w/o vlan(4) doesn't make a difference) - pfsync0 in rdomain 5 (configured with syncdev vlan5 and syncpeer, so no multicast traffic) - vlan5 in rdomain 5 - lo5 in rdomain 5 - pf(4) is passing pfsync traffic With tcpdump i only see packets on pfsync0 Sep 18 11:41:52.207074 PFSYNCv69 len 212 but nothing on vlan5. Besides that, the kernel prints the following message every sec, so it seems pfsync(4) is not rdomain aware anymore. /bsd: vlan5: trying to send packet on wrong domain. if 5 vs. mbuf 0 I've tested with 7.3 and here it works. Sep 18 11:56:19.142731 52:59:06:94:af:12 52:01:45:47:1c:34 0800 142: 192.168.5.1: PFSYNCv6 len 108act UPD ST COMP count 1 ... (DF) [tos 0x10] -Mark -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
Re: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header
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(&peer->p_remote, &data->r_idx, &nonce, data->buf, plaintext_len); nonce = htole64(nonce); /* Wire format is little endian. */
RISCV - port to Mango Pi MQ-Pro (D1)
Hi, I've been working a little bit on making OpenBSD run on Mango Pi, I haven't succeeded yet, but I think we're close. My patches are here: https://github.com/pbug44/openbsd-src/tree/MANGOPI it's a forked version of OpenBSD src with a "MANGOPI" branch. I used to send patches around to several OpenBSD devs but now it's probably better to have a repo for it. If you have this hardware and want OpenBSD running on it, help us! If you don't know how to program perhaps you can build-test. I haven't merged this patch yet, but I'll be working on this (it was compiling on a sept. 1st version of -current). A Mango Pi was sent to OpenBSD but came back to me after some time waiting to be picked up at a postal outlet. I don't know why they didn't call the OpenBSD dev, the number was on the address. Or perhaps they did and he was on vacation at the time. I still want to give this to the OpenBSD dev that I sent it to, unless he doesn't want it, I still want to give this to OpenBSD. OpenBSD, contact me with new postal address information. Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: Compulab's Fitlet3: Intel's Elkhart Atom X6425E with MARVELL PHY 88E1512 Ethernet
… ok; thank you for the quick reply. von meinem Kläwwerfon gesendet > Am 15.09.2023 um 21:54 schrieb Stefan Sperling : > On Fri, Sep 15, 2023 at 04:55:42PM +0200, Wolfgang Oelerich wrote: >> Hello, >> >> recently, I „inherited“ one of Compulab‘s Fitlet3. I received it with >> Linux Mint installed and found all 4 available Ethernet ports working: >> 2 of its extensional FACET card and 2 of Intel‘s Elkhart Lake Atom X6425E >> with MARVELL-type PHY „88E1512" at Atom's PCIe bus (see link below). >> >> Now, I tried a clean install of OpenBSD 7.3/AMD64 which smoothly worked >> out but only the FACET card Ethernet ports have been recognized properly. >> While assuming BIOS is ok since Linux Mint worked I am wondering how far >> the hardware combination of X6425E/MARVELL PHY 88E1512 is already set to >> be working or if there is some driver or other Kernel level code not >> available yet. > > Elkhart Lake Ethernet will require PCI attachment code to be written > for dwqe(4). There is interest in getting this working but it will take > time. Definitely won't be ready for OpenBSD 7.4. Maybe 7.5.
