Re: OT: Test new email conf

[Daniele B.]

Darling, they know me as an ethical guy.
So, my true blogs are usually offline cause the italo-american
meritocracy and their "liberty".., I'm really sorry for the business...

NB: I suggest you to adopt true western names to make your tricks,
indeed, they are so cool

-Dan

Mar 5, 2024 20:20:36 Mizsei Zoltán :

> Please consider to start a blog about your adventures. Thanks.
> 
> Regards,
> -ext

Re: OT: Test new email conf

[Mizsei Zoltán]

Please consider to start a blog about your adventures. Thanks.

Regards,
-ext

Daniele B. írta 2024. márc.. 5, K-n 18:58 órakor:
> The past days I was managing to try it
> the admin interface of BookMyName (iliad) and
> sorry for the wanted advertisement.. (it is affordable)
> Suddenly I found myself in front of a
> transliteral (from the French) saying very
> closed to the following:
>
> "Please fill in a backup email address
> (attention by suppling an email address different to
> the registration email you are admitting
> to currently use more than one email address!)".
>
> I personally felt faintened, almost doomed..
>
> -Dan
>
> Mar 2, 2024 07:54:55 Nowarez Market :
>
>> Hello,
>>
>> You can take it like a *curtesy email* to disclose my new email address.
>> Kindly thxs and take care of the pacman..

-- 
--Z--

Re: OT: Test new email conf

[Daniele B.]

The past days I was managing to try it
the admin interface of BookMyName (iliad) and
sorry for the wanted advertisement.. (it is affordable)
Suddenly I found myself in front of a
transliteral (from the French) saying very
closed to the following:

"Please fill in a backup email address
(attention by suppling an email address different to
the registration email you are admitting
to currently use more than one email address!)".

I personally felt faintened, almost doomed..

-Dan

Mar 2, 2024 07:54:55 Nowarez Market :

> Hello,
>
> You can take it like a *curtesy email* to disclose my new email address.
> Kindly thxs and take care of the pacman..

OT: Test new email conf

[Nowarez Market]

Hello,

You can take it like a *curtesy email* to disclose my new email address.
Kindly thxs and take care of the pacman..


> N0\/\/@r€Z
> --
>    /\/\@rk€T

Please test: wg(4): drop "while (!ifq_empty())" hack in wg_peer_destroy()

[Vitaliy Makkoveev]

Hi,

wg(4) stores reference to peer in the outgoing mbuf. Since it doesn't
use reference counting, to make the `peer' dereference safe within
wg_qstart(), wg_peer_destroy() has the following delay loop:

NET_LOCK();
while (!ifq_empty(>sc_if.if_snd)) {
/*
 * XXX: `if_snd' of stopped interface could still
 * contain packets
 */
if (!ISSET(sc->sc_if.if_flags, IFF_RUNNING)) {
ifq_purge(>sc_if.if_snd);
continue;
}
NET_UNLOCK();
tsleep_nsec(, PWAIT, "wg_ifq", 1000);
NET_LOCK();
}
NET_UNLOCK();

Regardless on exclusive netlock acquisistion which stops packet
processing, this loop also could became infinite on huge traffic. I
want to remove it. Unfortunately, we can't use reference counting for
outgoing packets because they could stuck within `if_snd' of stopped
interface. These packets will be removed on interface destruction, so
the reference of `peer' will never be released.

There is another way: to do wg_aip_lookup() for each packet within
wg_qstart(). This diff implements it. Obviously, wg_aip_lookup()
provides some performance impact, so I'm asking for help with testing
this diff on configuration with huge amount of peers and traffic
pressure. I'm interesting what is the performance impact and is the
performance impact acceptable. Of course any other help with testing is
also welcomed.

Also, this diff restores pf(4) delay option for wg(4) interfaces.

Index: sys/net/if_wg.c
===
RCS file: /cvs/src/sys/net/if_wg.c,v
retrieving revision 1.36
diff -u -p -r1.36 if_wg.c
--- sys/net/if_wg.c 18 Jan 2024 08:46:41 -  1.36
+++ sys/net/if_wg.c 19 Jan 2024 13:45:06 -
@@ -507,22 +507,6 @@ wg_peer_destroy(struct wg_peer *peer)
 
noise_remote_clear(>p_remote);
 
-   NET_LOCK();
-   while (!ifq_empty(>sc_if.if_snd)) {
-   /*
-* XXX: `if_snd' of stopped interface could still
-* contain packets
-*/
-   if (!ISSET(sc->sc_if.if_flags, IFF_RUNNING)) {
-   ifq_purge(>sc_if.if_snd);
-   continue;
-   }
-   NET_UNLOCK();
-   tsleep_nsec(, PWAIT, "wg_ifq", 1000);
-   NET_LOCK();
-   }
-   NET_UNLOCK();
-
taskq_barrier(wg_crypt_taskq);
taskq_barrier(net_tq(sc->sc_if.if_index));
 
@@ -2092,20 +2076,39 @@ wg_qstart(struct ifqueue *ifq)
struct ifnet*ifp = ifq->ifq_if;
struct wg_softc *sc = ifp->if_softc;
struct wg_peer  *peer;
-   struct wg_tag   *t;
struct mbuf *m;
SLIST_HEAD(,wg_peer) start_list;
 
SLIST_INIT(_list);
 
+   rw_enter_read(>sc_lock);
/*
 * We should be OK to modify p_start_list, p_start_onlist in this
 * function as there should only be one ifp->if_qstart invoked at a
 * time.
 */
while ((m = ifq_dequeue(ifq)) != NULL) {
-   t = wg_tag_get(m);
-   peer = t->t_peer;
+   switch (m->m_pkthdr.ph_family) {
+   case AF_INET:
+   peer = wg_aip_lookup(sc->sc_aip4,
+   (m, struct ip *)->ip_dst);
+   break;
+#ifdef INET6
+   case AF_INET6:
+   peer = wg_aip_lookup(sc->sc_aip6,
+   (m, struct ip6_hdr *)->ip6_dst);
+   break;
+#endif
+   default:
+   m_freem(m);
+   continue;
+   }
+
+   if (peer == NULL) {
+   m_freem(m);
+   continue;
+   }
+
if (mq_push(>p_stage_queue, m) != 0)
counters_inc(ifp->if_counters, ifc_oqdrops);
if (!peer->p_start_onlist) {
@@ -2120,6 +2123,8 @@ wg_qstart(struct ifqueue *ifq)
wg_timers_event_want_initiation(>p_timers);
peer->p_start_onlist = 0;
}
+   rw_exit_read(>sc_lock);
+
task_add(wg_crypt_taskq, >sc_encap);
 }
 
@@ -2175,19 +2180,6 @@ wg_output(struct ifnet *ifp, struct mbuf
if (m->m_pkthdr.ph_loopcnt++ > M_MAXLOOP) {
DPRINTF(sc, "Packet looped\n");
ret = ELOOP;
-   goto error;
-   }
-
-   /*
-* As we hold a reference to peer in the mbuf, we can't handle a
-* delayed packet without doing some refcnting. If a peer is removed
-* while a delayed holds a reference, bad things will happen. For the
-* time being, delayed packets are unsupported. This may be fixed with
-* another aip_lookup in wg_qstart, or refcnting as mentioned 

[m...@openbsd.org: Please test; midi(4): make midi{read,write}_filtops mp safe]

[Vitaliy Makkoveev]

Hi,

I'm searching help with midi(4) testing. If someone could test this
diff, let me know.

- Forwarded message from Vitaliy Makkoveev  -

Date: Sun, 24 Sep 2023 23:03:54 +0300
From: Vitaliy Makkoveev 
To: t...@openbsd.org
Subject: Please test; midi(4): make midi{read,write}_filtops mp safe

Please test this diff, I have no midi(4) devices.

midi(4) already uses `audio_lock' mutex(9) for filterops, but they are
still kernel locked. Wipe out old selwakeup API and make them MP safe.
knote_locked(9) will not grab kernel lock, so call it directly from
interrupt handlers instead of scheduling software interrupts.

Index: sys/dev/midi.c
===
RCS file: /cvs/src/sys/dev/midi.c,v
retrieving revision 1.55
diff -u -p -r1.55 midi.c
--- sys/dev/midi.c  2 Jul 2022 08:50:41 -   1.55
+++ sys/dev/midi.c  24 Sep 2023 19:57:56 -
@@ -31,7 +31,6 @@
 #include 
 #include 
 
-#define IPL_SOFTMIDI   IPL_SOFTNET
 #define DEVNAME(sc)((sc)->dev.dv_xname)
 
 intmidiopen(dev_t, int, int, struct proc *);
@@ -65,41 +64,38 @@ struct cfdriver midi_cd = {
 
 void filt_midiwdetach(struct knote *);
 int filt_midiwrite(struct knote *, long);
+int filt_midimodify(struct kevent *, struct knote *);
+int filt_midiprocess(struct knote *, struct kevent *);
 
 const struct filterops midiwrite_filtops = {
-   .f_flags= FILTEROP_ISFD,
+   .f_flags= FILTEROP_ISFD | FILTEROP_MPSAFE,
.f_attach   = NULL,
.f_detach   = filt_midiwdetach,
.f_event= filt_midiwrite,
+   .f_modify   = filt_midimodify,
+   .f_process  = filt_midiprocess,
 };
 
 void filt_midirdetach(struct knote *);
 int filt_midiread(struct knote *, long);
 
 const struct filterops midiread_filtops = {
-   .f_flags= FILTEROP_ISFD,
+   .f_flags= FILTEROP_ISFD | FILTEROP_MPSAFE,
.f_attach   = NULL,
.f_detach   = filt_midirdetach,
.f_event= filt_midiread,
+   .f_modify   = filt_midimodify,
+   .f_process  = filt_midiprocess,
 };
 
 void
-midi_buf_wakeup(void *addr)
+midi_buf_wakeup(struct midi_buffer *buf)
 {
-   struct midi_buffer *buf = addr;
-
if (buf->blocking) {
wakeup(>blocking);
buf->blocking = 0;
}
-   /*
-* As long as selwakeup() grabs the KERNEL_LOCK() make sure it is
-* already held here to avoid lock ordering problems with `audio_lock'
-*/
-   KERNEL_ASSERT_LOCKED();
-   mtx_enter(_lock);
-   selwakeup(>sel);
-   mtx_leave(_lock);
+   knote_locked(>klist, 0);
 }
 
 void
@@ -117,13 +113,7 @@ midi_iintr(void *addr, int data)
 
MIDIBUF_WRITE(mb, data);
 
-   /*
-* As long as selwakeup() needs to be protected by the
-* KERNEL_LOCK() we have to delay the wakeup to another
-* context to keep the interrupt context KERNEL_LOCK()
-* free.
-*/
-   softintr_schedule(sc->inbuf.softintr);
+   midi_buf_wakeup(mb);
 }
 
 int
@@ -226,14 +216,7 @@ void
 midi_out_stop(struct midi_softc *sc)
 {
sc->isbusy = 0;
-
-   /*
-* As long as selwakeup() needs to be protected by the
-* KERNEL_LOCK() we have to delay the wakeup to another
-* context to keep the interrupt context KERNEL_LOCK()
-* free.
-*/
-   softintr_schedule(sc->outbuf.softintr);
+   midi_buf_wakeup(>outbuf);
 }
 
 void
@@ -342,11 +325,11 @@ midikqfilter(dev_t dev, struct knote *kn
error = 0;
switch (kn->kn_filter) {
case EVFILT_READ:
-   klist = >inbuf.sel.si_note;
+   klist = >inbuf.klist;
kn->kn_fop = _filtops;
break;
case EVFILT_WRITE:
-   klist = >outbuf.sel.si_note;
+   klist = >outbuf.klist;
kn->kn_fop = _filtops;
break;
default:
@@ -355,9 +338,7 @@ midikqfilter(dev_t dev, struct knote *kn
}
kn->kn_hook = (void *)sc;
 
-   mtx_enter(_lock);
-   klist_insert_locked(klist, kn);
-   mtx_leave(_lock);
+   klist_insert(klist, kn);
 done:
device_unref(>dev);
return error;
@@ -368,24 +349,15 @@ filt_midirdetach(struct knote *kn)
 {
struct midi_softc *sc = (struct midi_softc *)kn->kn_hook;
 
-   mtx_enter(_lock);
-   klist_remove_locked(>inbuf.sel.si_note, kn);
-   mtx_leave(_lock);
+   klist_remove(>inbuf.klist, kn);
 }
 
 int
 filt_midiread(struct knote *kn, long hint)
 {
struct midi_softc *sc = (struct midi_softc *)kn->kn_hook;
-   int retval;
-
-   if ((hint & NOTE_SUBMIT) == 0)
-   mtx_enter(_lock);
-   retval = !MIDIBUF_ISEMPTY(>inbuf);
-   if ((hint & NOTE_SUBMIT) == 0)
-   mtx_leave(_lock);
 
-   r

SOLVED! Checksum test for "package" failed

[Computer Planet]

It was damaged, despite having just taken it out of the package, the secure 
digital...
Thanks for all, Ernesto.

On Friday, 19-05-2023 at 11:48 Computer Planet wrote:
> Hi Guys, OpenBSD 7.3 arm64.
> Given that I've never had problems installing OpenBSD, any version, any 
> architecture. 
> I install it on Pine64 Rock64 to make VPN, sometimes even 3/4 times a day.
> This morning, for the first time, during the online installation phase, just 
> on a Pine64 Rock64, 
> it fails to verify the checksum of the packages... for all the packages.
> I've been trying and trying, still the same problem.
> Yesterday, on the same type of SBC and in the same way, installed 3 times 
> without any problems, from this morning this message:
> Checksum test for "package" failed. Continue anyway?
> Could someone give me some advice please...?
> 
> P.S.: About the installation, I've always used this "repository": 
> ftp.openbsd.org
> 
> Thanks for Reply.
> 
> 

Re: Checksum test for "package" failed

[Stuart Henderson]

On 2023-05-19, Computer Planet  wrote:
> Hi Guys, OpenBSD 7.3 arm64.
> Given that I've never had problems installing OpenBSD, any version, any 
> architecture. 
> I install it on Pine64 Rock64 to make VPN, sometimes even 3/4 times a day.
> This morning, for the first time, during the online installation phase, just 
> on a Pine64 Rock64, 
> it fails to verify the checksum of the packages... for all the packages.
> I've been trying and trying, still the same problem.
> Yesterday, on the same type of SBC and in the same way, installed 3 times 
> without any problems, from this morning this message:
> Checksum test for "package" failed. Continue anyway?
> Could someone give me some advice please...?
>
> P.S.: About the installation, I've always used this "repository": 
> ftp.openbsd.org

Is this 7.3 release, or a -current snapshot?

If it's a snapshot, try a newer one.

Checksum test for "package" failed

[Computer Planet]

Hi Guys, OpenBSD 7.3 arm64.
Given that I've never had problems installing OpenBSD, any version, any 
architecture. 
I install it on Pine64 Rock64 to make VPN, sometimes even 3/4 times a day.
This morning, for the first time, during the online installation phase, just on 
a Pine64 Rock64, 
it fails to verify the checksum of the packages... for all the packages.
I've been trying and trying, still the same problem.
Yesterday, on the same type of SBC and in the same way, installed 3 times 
without any problems, from this morning this message:
Checksum test for "package" failed. Continue anyway?
Could someone give me some advice please...?

P.S.: About the installation, I've always used this "repository": 
ftp.openbsd.org

Thanks for Reply.

Re: gdb segfaults setting breakpoint on a Rust test

[Luke A. Call]

Thank you!

On 2023-03-24 14:10:50-0600, Todd C. Miller  wrote:
> On Fri, 24 Mar 2023 13:10:08 -0600, "Luke A. Call" wrote:
> 
> > Hi.  When I run this on the binary of a test in my Rust
> > application, then run these commands in gdb, I get the following output
> > which ends with Segmentation Fault:
> 
> The in-tree gdb is old, you should try the egdb package instead.
> 
>  - todd
> 

Re: gdb segfaults setting breakpoint on a Rust test

[Todd C . Miller]

On Fri, 24 Mar 2023 13:10:08 -0600, "Luke A. Call" wrote:

> Hi.  When I run this on the binary of a test in my Rust
> application, then run these commands in gdb, I get the following output
> which ends with Segmentation Fault:

The in-tree gdb is old, you should try the egdb package instead.

 - todd

gdb segfaults setting breakpoint on a Rust test

[Luke A. Call]

Hi.  When I run this on the binary of a test in my Rust
application, then run these commands in gdb, I get the following output
which ends with Segmentation Fault:


nemodel-ac769fda48f1a333
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "amd64-unknown-openbsd7.2"...
(gdb) start
Breakpoint 1 at 0x30f9e4
Starting program:
/home/lacall/proj/om/core/target/debug/deps/onemodel-ac769fda48f1a333 
Breakpoint 1 at 0xb6d041be9e4
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be
2) [in module /usr/libexec/ld.so]
0x0b6d041be9e4 in main () from
/home/lacall/proj/om/core/target/debug/deps/onemodel-ac769fda48f1a333
(gdb) dir /home/lacall/proj/om/core/src/
Source directories searched: /home/lacall/proj/om/core/src:$cdir:$cwd
(gdb) dir /home/lacall/proj/om/core/src/model
Source directories searched:
/home/lacall/proj/om/core/src/model:/home/lacall/proj/om/core/src:$cdir:$cwd
(gdb) dir /home/lacall/proj/om/core/src/controllers 
Source directories searched:
/home/lacall/proj/om/core/src/controllers:/home/lacall/proj/om/core/src/model:/home/lacall/proj/om/core/src:$cdir:$cwd
(gdb) b util.rs:1057
Segmentation fault
@:~/<...>/target/debug/deps
$

I'm on obsd 7.2 stable and am not a C programmer, unfortunately.

If, prior to setting the breakpoint, I just do the "run" command, it
successfully runs the test to completion (which shows an intentional 
test failure for now).

Luke Call

Here is /var/run/dmesg.boot (dmesg itself is just messages about my
usb mouse attaching/detaching).

uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
wsmouse0 detached
ums0 detached
uhidev0 detached
uhidev0 at uhub0 port 4 configuration 1 interface 0 "Logitech USB Optical 
Mouse" rev 2.00/72.00 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
wsmouse0 detached
ums0 detached
uhidev0 detached
uhidev0 at uhub0 port 4 configuration 1 interface 0 "Logitech USB Optical 
Mouse" rev 2.00/72.00 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
syncing disks... done
OpenBSD 7.2 (GENERIC.MP) #7: Sat Feb 25 14:07:58 MST 2023

r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16029159424 (15286MB)
avail mem = 15525961728 (14806MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf90 (49 entries)
bios0: vendor American Megatrends Inc. version "204" date 11/20/2014
bios0: ASUSTeK COMPUTER INC. X550ZA
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ECDT MCFG MSDM HPET UEFI SSDT SSDT CRAT SSDT 
SSDT SSDT SSDT
acpi0: wakeup devices LOM_(S4) SBAZ(S4) ECIR(S4) OHC1(S4) EHC1(S4) OHC2(S4) 
EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) ODD8(S3) GLAN(S4) 
LID_(S5) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2496.19 MHz, 15-30-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT
cpu0: 16KB 64b/line 4-way D-cache, 96KB 64b/line 3-way I-cache
cpu0: 2MB 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 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.35 MHz, 15-30-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,ITSC,FSGSBASE,BMI1,XSAVEOPT
cpu1: 16KB 64b/line 4-way D-cache, 96KB 64b/line 3-way I-cache
cpu1: 2MB 64b/line 16-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.35 MHz, 15-30-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA

Re: A speed test with Iperf , Relayd and PF

[Stuart Henderson]

On 2022-05-13, Fabrizio Francione  wrote:
> Code:
> tcp connection fixup {
>    tcp nodelay
> }
> 
> relay IPERF_TEST{
>    listen on 10.10.10.2 port 6740
>    forward to 192.168.20.9 port 6670
>    protocol fixup
> }
> With IPERF I obtain a speed of 144Mbps .

Why use nodelay? That disables Nagle and is normally only wanted for 
interactive protocols like SSH. High chance that will be slowing
things down.

https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm 

> If instead, I deactivate the relayd function and using a simple PF
> redirecting with
>
> Code:
>
> pass in on em0 proto {tcp} from any to em0 port 6740 rdr-to 192.168.20.9
> port 6670
>
> I obtain a speed of 892 Mbps.

rdr-to and relayd TCP proxies are totally different things.


-- 
Please keep replies on the mailing list.

Re: disk i/o test

[Brian Brombacher]

> On Mar 7, 2022, at 12:10 PM, Brian Brombacher  wrote:
> 
> Hi Mihai,
> 
> Not exactly related to disk speed, but have you cranked up the following 
> sysctl to see if it helps?
> 
> sysctl kern.bufcachepercentage=9
> 
> I put an entry in /etc/sysctl.conf for persistence.
> 
> This will cause up to 90% of system memory to be used as a unified buffer 
> cache for disk access.  Not sure if that helps but I use that value on every 
> install, including desktop and servers.  I can’t remember if the default 
> value has changed in the past 10 years but I always go with 90%.


I was helped off-list with this information, there is a memory threshold on 
amd64 that affects the behavior of the sysctl.  If you have more than 4 gb of 
memory, the sysctl isn’t important.


> 
> -Brian
> 
>>> On Mar 7, 2022, at 6:17 AM, Mihai Popescu  wrote:
>>> 
>>> On Mon, Mar 7, 2022 at 8:46 AM Janne Johansson  wrote:
>>> 
>>> Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu :
 
 Since this thread is moving slowly in another direction, let me
>>> 
>>> True
>>> 
 reiterate my situation again: I am running a browser (mostly chromium)
 and the computer slows down on downloads. Since I've checked the
 downloads rates, I observed they are slow than my maximum 500Mbps for
 the line.
 I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the
 Chromium has 30 seconds delays in everything i do.
>>> 
>>> I would make sure it is not some kind of DNS thing, 30 second delays
>>> sounds A LOT
>>> like trying a "dead" resolver 3 times with 10 secs in between, before
>>> moving to a "working" one.
>> 
>> By "delay" I mean the time passed from clicking on some Chromium menu
>> and the actual display of that menu. Even using a tty is slow, login
>> . password  in that disk intense usage period.
>> Tried Debian and FreeBSD, all are able to write disk and do graphics.
>> That ZFS on FreeBSD is mind blowing, I hope it's reliable too.
>> 
>> All I wanted was to compare my hardware and disk speeds with someone
>> running OpenBSD: simple dmesg <-> speed report match, but I think I
>> hit a taboo again.
>> Found some discussions on misc@ about that, no clear answer. I think I
>> will close this thread and see what this ZFS is about :-) .
>> 
>> Thank you all.
>>> 
>>> --
>>> May the most significant bit of your life be positive.
>> 
> 

Re: disk i/o test

[Brian Brombacher]

Correction: 

kern.bufcachepercentage=90

> On Mar 7, 2022, at 12:07 PM, Brian Brombacher  wrote:
> 
> Hi Mihai,
> 
> Not exactly related to disk speed, but have you cranked up the following 
> sysctl to see if it helps?
> 
> sysctl kern.bufcachepercentage=9
> 
> I put an entry in /etc/sysctl.conf for persistence.
> 
> This will cause up to 90% of system memory to be used as a unified buffer 
> cache for disk access.  Not sure if that helps but I use that value on every 
> install, including desktop and servers.  I can’t remember if the default 
> value has changed in the past 10 years but I always go with 90%.
> 
> -Brian
> 
>>> On Mar 7, 2022, at 6:17 AM, Mihai Popescu  wrote:
>>> 
>>> On Mon, Mar 7, 2022 at 8:46 AM Janne Johansson  wrote:
>>> 
>>> Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu :
 
 Since this thread is moving slowly in another direction, let me
>>> 
>>> True
>>> 
 reiterate my situation again: I am running a browser (mostly chromium)
 and the computer slows down on downloads. Since I've checked the
 downloads rates, I observed they are slow than my maximum 500Mbps for
 the line.
 I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the
 Chromium has 30 seconds delays in everything i do.
>>> 
>>> I would make sure it is not some kind of DNS thing, 30 second delays
>>> sounds A LOT
>>> like trying a "dead" resolver 3 times with 10 secs in between, before
>>> moving to a "working" one.
>> 
>> By "delay" I mean the time passed from clicking on some Chromium menu
>> and the actual display of that menu. Even using a tty is slow, login
>> . password  in that disk intense usage period.
>> Tried Debian and FreeBSD, all are able to write disk and do graphics.
>> That ZFS on FreeBSD is mind blowing, I hope it's reliable too.
>> 
>> All I wanted was to compare my hardware and disk speeds with someone
>> running OpenBSD: simple dmesg <-> speed report match, but I think I
>> hit a taboo again.
>> Found some discussions on misc@ about that, no clear answer. I think I
>> will close this thread and see what this ZFS is about :-) .
>> 
>> Thank you all.
>>> 
>>> --
>>> May the most significant bit of your life be positive.
>> 

Re: disk i/o test

[Brian Brombacher]

Hi Mihai,

Not exactly related to disk speed, but have you cranked up the following sysctl 
to see if it helps?

sysctl kern.bufcachepercentage=9

I put an entry in /etc/sysctl.conf for persistence.

This will cause up to 90% of system memory to be used as a unified buffer cache 
for disk access.  Not sure if that helps but I use that value on every install, 
including desktop and servers.  I can’t remember if the default value has 
changed in the past 10 years but I always go with 90%.

-Brian

> On Mar 7, 2022, at 6:17 AM, Mihai Popescu  wrote:
> 
> On Mon, Mar 7, 2022 at 8:46 AM Janne Johansson  wrote:
>> 
>> Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu :
>>> 
>>> Since this thread is moving slowly in another direction, let me
>> 
>> True
>> 
>>> reiterate my situation again: I am running a browser (mostly chromium)
>>> and the computer slows down on downloads. Since I've checked the
>>> downloads rates, I observed they are slow than my maximum 500Mbps for
>>> the line.
>>> I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the
>>> Chromium has 30 seconds delays in everything i do.
>> 
>> I would make sure it is not some kind of DNS thing, 30 second delays
>> sounds A LOT
>> like trying a "dead" resolver 3 times with 10 secs in between, before
>> moving to a "working" one.
> 
> By "delay" I mean the time passed from clicking on some Chromium menu
> and the actual display of that menu. Even using a tty is slow, login
> . password  in that disk intense usage period.
> Tried Debian and FreeBSD, all are able to write disk and do graphics.
> That ZFS on FreeBSD is mind blowing, I hope it's reliable too.
> 
> All I wanted was to compare my hardware and disk speeds with someone
> running OpenBSD: simple dmesg <-> speed report match, but I think I
> hit a taboo again.
> Found some discussions on misc@ about that, no clear answer. I think I
> will close this thread and see what this ZFS is about :-) .
> 
> Thank you all.
>> 
>> --
>> May the most significant bit of your life be positive.
> 

Re: disk i/o test

[Mihai Popescu]

On Mon, Mar 7, 2022 at 8:46 AM Janne Johansson  wrote:
>
> Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu :
> >
> > Since this thread is moving slowly in another direction, let me
>
> True
>
> > reiterate my situation again: I am running a browser (mostly chromium)
> > and the computer slows down on downloads. Since I've checked the
> > downloads rates, I observed they are slow than my maximum 500Mbps for
> > the line.
> > I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the
> > Chromium has 30 seconds delays in everything i do.
>
> I would make sure it is not some kind of DNS thing, 30 second delays
> sounds A LOT
> like trying a "dead" resolver 3 times with 10 secs in between, before
> moving to a "working" one.

By "delay" I mean the time passed from clicking on some Chromium menu
and the actual display of that menu. Even using a tty is slow, login
. password  in that disk intense usage period.
Tried Debian and FreeBSD, all are able to write disk and do graphics.
That ZFS on FreeBSD is mind blowing, I hope it's reliable too.

All I wanted was to compare my hardware and disk speeds with someone
running OpenBSD: simple dmesg <-> speed report match, but I think I
hit a taboo again.
Found some discussions on misc@ about that, no clear answer. I think I
will close this thread and see what this ZFS is about :-) .

Thank you all.
>
> --
> May the most significant bit of your life be positive.

Re: disk i/o test

[Janne Johansson]

Den sön 6 mars 2022 kl 16:41 skrev Mihai Popescu :
>
> Since this thread is moving slowly in another direction, let me

True

> reiterate my situation again: I am running a browser (mostly chromium)
> and the computer slows down on downloads. Since I've checked the
> downloads rates, I observed they are slow than my maximum 500Mbps for
> the line.
> I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the
> Chromium has 30 seconds delays in everything i do.

I would make sure it is not some kind of DNS thing, 30 second delays
sounds A LOT
like trying a "dead" resolver 3 times with 10 secs in between, before
moving to a "working" one.

-- 
May the most significant bit of your life be positive.

Re: disk i/o test

[Brian Brombacher]

> On Mar 6, 2022, at 7:41 AM, Mihai Popescu  wrote:
> 
> Since this thread is moving slowly in another direction, let me
> reiterate my situation again: I am running a browser (mostly chromium)
> and the computer slows down on downloads. Since I've checked the
> downloads rates, I observed they are slow than my maximum 500Mbps for
> the line.
> I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the
> Chromium has 30 seconds delays in everything i do.
> 
> As a suggestion from Stuart, I was trying to separate tests for
> downloading and disk write. The disk looks slow.

Is the disk brand new?  If I missed this somewhere, apologies.

If it’s not new, how confident are you that the region of disk where chromium 
is writing data to disk has not suffered from any reallocations at the physical 
layer?  I find read and write performance to spinning disks is highly regulated 
by physical layout more than anything else.  For linear access, of course.

Getting 41 MB/sec on an old disk depending on the region you are accessing is 
not out of my expectations, if the disk has reallocations in the region 
accessed.

Reallocations occur when the physical media is no longer usable within 
thresholds so a new sector/area is allocated elsewhere on the disk and mapped.  
This causes seeks for what you consider a linear access.  The hardware does 
this for you and you can’t stop it nor should you want to.

Solution: Get SSD’s.


> I tried both Debian 11 and Ubuntu and the download and disk write
> jumps to 500Mbps without problems. And no, I cannot tolerate Linux
> enough to use it as a daily OS, so don't bother to recommend it. I
> cannot attain this in OpenBSD. Maybe that is the maximum possible for
> my hardware. Just asking, for the moment i can live with this delays.
> I was curious if someone with similar hardware can do better.
> 
> OpenBSD 7.1-beta (GENERIC.MP) #401: Thu Mar  3 12:48:28 MST 2022
>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 7711543296 (7354MB)
> avail mem = 7460630528 (7115MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe86ed (64 entries)
> bios0: vendor Hewlett-Packard version "K06 v02.77" date 03/22/2018
> bios0: Hewlett-Packard HP Compaq Pro 6305 SFF
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT MSDM TCPA IVRS SSDT SSDT CRAT
> acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) PE20(S4)
> PE21(S4) PE22(S4) BNIC(S4) PE23(S4) BR12(S4) BR14(S4) OHC1(S3)
> EHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 16 (boot processor)
> cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.47 MHz, 15-10-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
> cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB

Re: disk i/o test

[Mihai Popescu]

Since this thread is moving slowly in another direction, let me
reiterate my situation again: I am running a browser (mostly chromium)
and the computer slows down on downloads. Since I've checked the
downloads rates, I observed they are slow than my maximum 500Mbps for
the line.
I can reach 320Mbps maximum, but mostly it stays at 280Mbps and the
Chromium has 30 seconds delays in everything i do.

As a suggestion from Stuart, I was trying to separate tests for
downloading and disk write. The disk looks slow.
I tried both Debian 11 and Ubuntu and the download and disk write
jumps to 500Mbps without problems. And no, I cannot tolerate Linux
enough to use it as a daily OS, so don't bother to recommend it. I
cannot attain this in OpenBSD. Maybe that is the maximum possible for
my hardware. Just asking, for the moment i can live with this delays.
I was curious if someone with similar hardware can do better.

OpenBSD 7.1-beta (GENERIC.MP) #401: Thu Mar  3 12:48:28 MST 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7711543296 (7354MB)
avail mem = 7460630528 (7115MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe86ed (64 entries)
bios0: vendor Hewlett-Packard version "K06 v02.77" date 03/22/2018
bios0: Hewlett-Packard HP Compaq Pro 6305 SFF
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT MSDM TCPA IVRS SSDT SSDT CRAT
acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) PE20(S4)
PE21(S4) PE22(S4) BNIC(S4) PE23(S4) BR12(S4) BR14(S4) OHC1(S3)
EHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 16 (boot processor)
cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.47 MHz, 15-10-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache
cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 17 (application processor)
cpu1: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.06 MHz, 15-10-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache
cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 18 (application processor)
cpu2: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.06 MHz, 15-10-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache
cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: disabling user TSC (skew=206)
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 19 (application processor)
cpu3: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.06 MHz, 15-10-01
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB
cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB
64b/line 16-way L2 cache
cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative
cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
acpimcfg0 

Re: disk i/o test

[Stuart Henderson]

On 2022-03-06, Alceu Rodrigues de Freitas Junior  
wrote:
>
>
> Em 05/03/2022 15:29, Janne Johansson escreveu:
>
>> It can work the other way around also, using free RAM on the
>> hypervisor to create
>> a larger write cache than the VM itself can have.
>
> That would improve performance, but at the cost of losing data.
>
> Not sure if already suggested, but depending on the nature of data (ETL, 
> for example, would be acceptable), using MFS as file system would have 
> much better performance.

Don't over-estimate the capabilities of MFS, it is not particularly fast.

Ignoring VM (and I don't know how things behave there) but on physical
hardware I often see faster writes to even just plain SATA SSDs than to
MFS.


-- 
Please keep replies on the mailing list.

Re: disk i/o test

[Mihai Popescu]

> > Besides this, are my values too low or just the expected ones?
>
> It seems the throughput is bad. The small IO test showed good numbers
> for iops, but the second test (and I guess other people's suggestion
> to try dd from /dev/zero) will show that you seem to have a "thin
> wire" from the drive to the computer, it seeks fast but transfers data
> slowly.
>

Well, i dit the dd stuff and post result before, but i think it is
still low for expectations.
This is the second AMD based computer with "transfer" problems and no
clear explanation.
Could be the hardware, could be the driver, i really cannot figure out.

I think i will jump in Intel's boat next time, I know there are some
problems too, but at least their CPU are the most used and maybe have
fixes.

Thank you for your time.

Re: disk i/o test

[Janne Johansson]

Den tors 3 mars 2022 kl 18:10 skrev Mihai Popescu :
>
> > https://openports.pl/path/benchmarks/fio
> > To test perf on many small IO (measuring iops basically) run:
> >
> > fio --name=random-write --rw=write --bs=4k --numjobs=2 --size=1g
> > --iodepth=16 --runtime=60 --time_based --end_fsync=1
>

> Run status group 0 (all jobs):
>   WRITE: bw=12.5MiB/s (13.1MB/s), 6370KiB/s-6438KiB/s
> (6523kB/s-6592kB/s), io=754MiB (791MB), run=60305-60305msec
>
>
> > To test large-IO perf:
> >
> > fio --name=random-write --rw=write --bs=1M --numjobs=1 --size=1g
> > --iodepth=1 --runtime=60 --time_based --end_fsync=1
>   WRITE: bw=18.9MiB/s (19.8MB/s), 18.9MiB/s-18.9MiB/s
> (19.8MB/s-19.8MB/s), io=1138MiB (1193MB), run=60364-60364msec
>
> >
> > Look for the result in the post-run report,
> > for small IO it can be
> >   write: IOPS=37.8k, BW=148MiB/s (155MB/s)
> > and for larger writes
> >  write: IOPS=253, BW=253MiB/s (266MB/s)
> >
>
> Not really like your report, did you run it on another OS or cited from 
> memory?

No, ran it on an openbsd VM.
Still, there would have been absolutely zero chance that my random
setup would match yours exactly so it was not meant as a measuring
stick on what is everyones acceptable level, only how to interpret
differences between large IO throughput and small IO latency/iops
values.

> Besides this, are my values too low or just the expected ones?

It seems the throughput is bad. The small IO test showed good numbers
for iops, but the second test (and I guess other people's suggestion
to try dd from /dev/zero) will show that you seem to have a "thin
wire" from the drive to the computer, it seeks fast but transfers data
slowly.

You might want to test the large IO test again with iodepth 1 and only
one thread just to see if it is caused by the drive jumping between
serving data from different places, so asking for a single stream
might give you the "optimal" transfer speed for a non-busy drive.

The numbers you did get were somewhat like when I bought an
IDE->CompactFlash adapter for my firewalls. The CF disk had "zero"
seek times which is good for cvs updates and so on, but still a low
ovreall transfer speed since CFs were just not anything like modern
ssd/nvme flash drives. Also, IDE being what it is puts limits on
concurrency when it comes to IO.


-- 
May the most significant bit of your life be positive.

Re: disk i/o test

[Jan Stary]

On Mar 03 10:11:07, n...@holland-consulting.net wrote:
> noatime is a nice little kick with seemingly
> zero consequences (it does defeat a standard Unix file system feature,
> but I've not come across anything that uses file access time stamps).

I remember some shells reporting "new mail"
based on the atime of /var/mail/$USER

Re: disk i/o test

[Mihai Popescu]

> https://openports.pl/path/benchmarks/fio
> To test perf on many small IO (measuring iops basically) run:
>
> fio --name=random-write --rw=write --bs=4k --numjobs=2 --size=1g
> --iodepth=16 --runtime=60 --time_based --end_fsync=1

fio-3.26
Starting 2 threads
Jobs: 2 (f=2): [F(2)][100.0%][w=6502KiB/s][w=1625 IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=96172096: Thu Mar  3
19:01:51 2022
  write: IOPS=1592, BW=6370KiB/s (6523kB/s)(375MiB/60305msec); 0 zone resets
clat (usec): min=3, max=531908, avg=622.66, stdev=11014.61
 lat (usec): min=4, max=531908, avg=623.30, stdev=11014.61
clat percentiles (usec):
 |  1.00th=[ 5],  5.00th=[ 5], 10.00th=[ 6], 20.00th=[ 6],
 | 30.00th=[ 6], 40.00th=[ 7], 50.00th=[ 7], 60.00th=[ 7],
 | 70.00th=[ 7], 80.00th=[10], 90.00th=[   101], 95.00th=[   111],
 | 99.00th=[   127], 99.50th=[   141], 99.90th=[221250], 99.95th=[240124],
 | 99.99th=[270533]
   bw (  KiB/s): min= 1783, max=17482, per=50.07%, avg=6413.82,
stdev=3737.49, samples=119
   iops: min=  445, max= 4370, avg=1603.28, stdev=934.38, samples=119
  lat (usec)   : 4=0.07%, 10=80.84%, 20=3.70%, 50=0.48%, 100=4.84%
  lat (usec)   : 250=9.71%
  lat (msec)   : 50=0.01%, 100=0.11%, 250=0.22%, 500=0.03%, 750=0.01%
  cpu  : usr=0.38%, sys=3.18%, ctx=352, majf=0, minf=3
  IO depths: 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued rwts: total=0,96040,0,0 short=0,0,0,0 dropped=0,0,0,0
 latency   : target=0, window=0, percentile=100.00%, depth=16
random-write: (groupid=0, jobs=1): err= 0: pid=-1958487488: Thu Mar  3
19:01:51 2022
  write: IOPS=1609, BW=6438KiB/s (6592kB/s)(379MiB/60305msec); 0 zone resets
clat (usec): min=3, max=531873, avg=616.18, stdev=10954.39
 lat (usec): min=4, max=531873, avg=616.80, stdev=10954.38
clat percentiles (usec):
 |  1.00th=[ 5],  5.00th=[ 5], 10.00th=[ 6], 20.00th=[ 6],
 | 30.00th=[ 6], 40.00th=[ 7], 50.00th=[ 7], 60.00th=[ 7],
 | 70.00th=[ 9], 80.00th=[56], 90.00th=[60], 95.00th=[64],
 | 99.00th=[   120], 99.50th=[   130], 99.90th=[221250], 99.95th=[240124],
 | 99.99th=[267387]
   bw (  KiB/s): min= 1791, max=17603, per=50.60%, avg=6481.80,
stdev=3808.08, samples=119
   iops: min=  447, max= 4400, avg=1620.29, stdev=952.06, samples=119
  lat (usec)   : 4=0.23%, 10=74.48%, 20=1.27%, 50=0.54%, 100=21.89%
  lat (usec)   : 250=1.24%
  lat (msec)   : 50=0.01%, 100=0.10%, 250=0.22%, 500=0.03%, 750=0.01%
  cpu  : usr=0.25%, sys=3.15%, ctx=351, majf=0, minf=3
  IO depths: 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
 submit: 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued rwts: total=0,97056,0,0 short=0,0,0,0 dropped=0,0,0,0
 latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
  WRITE: bw=12.5MiB/s (13.1MB/s), 6370KiB/s-6438KiB/s
(6523kB/s-6592kB/s), io=754MiB (791MB), run=60305-60305msec


>
> To test large-IO perf:
>
> fio --name=random-write --rw=write --bs=1M --numjobs=1 --size=1g
> --iodepth=1 --runtime=60 --time_based --end_fsync=1

fio: this platform does not support process shared mutexes, forcing
use of threads. Use the 'thread' option to get rid of this warning.
random-write: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W)
1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1
fio-3.26
Starting 1 thread
Jobs: 1 (f=1): [W(1)][100.0%][w=9124KiB/s][w=8 IOPS][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=-1257487296: Thu Mar  3
19:06:55 2022
  write: IOPS=18, BW=18.9MiB/s (19.8MB/s)(1138MiB/60364msec); 0 zone resets
clat (usec): min=676, max=365152, avg=52717.28, stdev=77225.34
 lat (usec): min=723, max=365213, avg=52776.70, stdev=77225.59
clat percentiles (usec):
 |  1.00th=[   701],  5.00th=[  1745], 10.00th=[  1926], 20.00th=[  1975],
 | 30.00th=[  2040], 40.00th=[  2180], 50.00th=[  2343], 60.00th=[ 48497],
 | 70.00th=[ 51643], 80.00th=[ 64750], 90.00th=[206570], 95.00th=[231736],
 | 99.00th=[267387], 99.50th=[299893], 99.90th=[350225], 99.95th=[367002],
 | 99.99th=[367002]
   bw (  KiB/s): min= 4096, max=44259, per=100.00%, avg=19452.77,
stdev=13520.95, samples=118
   iops: min=4, max=   43, avg=18.68, stdev=13.28, samples=118
  lat (usec)   : 750=4.04%, 1000=0.09%
  lat (msec)   : 2=20.65%, 4=28.65%, 20=0.09%, 50=13.80%, 100=16.08%
  lat (msec)   : 250=14.41%, 500=2.20%
  cpu  : usr=0.10%, sys=3.59%, ctx=542, majf=0, minf=3
  IO depths: 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0

Re: disk i/o test

[Mihai Popescu]

On Thu, Mar 3, 2022 at 3:08 PM Jan Klemkow  wrote:
>
> On Thu, Mar 03, 2022 at 02:59:33PM +0200, Mihai Popescu wrote:
> > 2. Can you suggest a sane disk I/O benchmark, writing from RAM to disk
> > (i.e. cp /dev/null )?
>
> /dev/null will act as an empty file.  you have to use /dev/zero.
>
> i do my test with this command:
>
> dd if=/dev/zero of=test10g.dat bs=1m count=10240 conv=fsync

$ time dd if=/dev/zero of=test10g.dat bs=1m count=10240 conv=fsync
10240+0 records in
10240+0 records out
10737418240 bytes transferred in 260.289 secs (41251827 bytes/sec)
4m20.32s real 0m00.01s user 0m17.70s system

Is it too low? Is it expected?
More info are here:
https://marc.info/?l=openbsd-misc=164548029214340=2

Re: disk i/o test

[Stuart Henderson]

On 2022-03-03, Nick Holland  wrote:
> You mention "legacy" options in the BIOS, you may be running an old
> machine.  But also look at softdep and noatime mount options, softdep
> is a HUGE performance gain, noatime is a nice little kick with seemingly

softdep can help if you are working on larger numbers of files but won't
help for, say, writes to one big file.

(but it can also turn some io errors, which the machine might possibly
otherwise recover from, into hard crashes)

the effect is usually quite a lot smaller on SSDs.

Re: disk i/o test

[Raul Miller]

On Thu, Mar 3, 2022 at 10:13 AM Nick Holland
 wrote:
> You mention "legacy" options in the BIOS, you may be running an old
> machine.  But also look at softdep and noatime mount options, softdep
> is a HUGE performance gain, noatime is a nice little kick with seemingly
> zero consequences (it does defeat a standard Unix file system feature,
> but I've not come across anything that uses file access time stamps).

Forensics (mostly useful on production machines with well understood
use patterns and software -- atime is rarely useful even there, but
that's true of most forensic issues and tools).

--
Raul

Re: disk i/o test

[Nick Holland]

On 3/3/22 7:59 AM, Mihai Popescu wrote:

Hello,

I am trying to test some disk i/o speeds and I am stumbled on two questions:
1. Does it matter if I set in BIOS Legacy or AHCI for the drive,
regarding the read/write performance?


anywhere between "big difference" and "OH WOW, I CAN'T BELIEVE THEY EVEN
PROVIDE THIS LEGACY OPTION!".  Really, you don't want to use "legacy".
Cool thing, you can ignore the BIOS warnings about changing the setting
and being no longer able to boot, OpenBSD handles that well.


2. Can you suggest a sane disk I/O benchmark, writing from RAM to disk
(i.e. cp /dev/null )?


really, your best benchmark is your work you need to do.  But if you are
looking for repeatable benchmarks, dd'ing FROM /dev/zero or TO /dev/null
is a starting point (use a larger block size than the default -- "bs=1m"
gives you easy to read info info out of "pkill -info dd", but also
consider untaring ports.tar.gz or src.tar.gz.


I am on snapshots for amd64 and I think i have a really slow writing
to disk on OpenBSD only.


You mention "legacy" options in the BIOS, you may be running an old
machine.  But also look at softdep and noatime mount options, softdep
is a HUGE performance gain, noatime is a nice little kick with seemingly
zero consequences (it does defeat a standard Unix file system feature,
but I've not come across anything that uses file access time stamps).

Nick.

Re: disk i/o test

[Janne Johansson]

Den tors 3 mars 2022 kl 14:02 skrev Mihai Popescu :
> I am trying to test some disk i/o speeds and I am stumbled on two questions:
> 1. Does it matter if I set in BIOS Legacy or AHCI for the drive,
> regarding the read/write performance?

Probably yes. AHCI will be better if it works.

> 2. Can you suggest a sane disk I/O benchmark, writing from RAM to disk
> (i.e. cp /dev/null )?
>

https://openports.pl/path/benchmarks/fio
To test perf on many small IO (measuring iops basically) run:

fio --name=random-write --rw=write --bs=4k --numjobs=2 --size=1g
--iodepth=16 --runtime=60 --time_based --end_fsync=1

To test large-IO perf:

fio --name=random-write --rw=write --bs=1M --numjobs=1 --size=1g
--iodepth=1 --runtime=60 --time_based --end_fsync=1

Look for the result in the post-run report,
for small IO it can be
  write: IOPS=37.8k, BW=148MiB/s (155MB/s)
and for larger writes
 write: IOPS=253, BW=253MiB/s (266MB/s)

> I am on snapshots for amd64 and I think i have a really slow writing
> to disk on OpenBSD only.

Might be worth testing mount flags like softdep or (shudder) async if
the data is backed up and not very important.

-- 
May the most significant bit of your life be positive.

disk i/o test

[Mihai Popescu]

Hello,

I am trying to test some disk i/o speeds and I am stumbled on two questions:
1. Does it matter if I set in BIOS Legacy or AHCI for the drive,
regarding the read/write performance?
2. Can you suggest a sane disk I/O benchmark, writing from RAM to disk
(i.e. cp /dev/null )?

I am on snapshots for amd64 and I think i have a really slow writing
to disk on OpenBSD only.

Thank you.

Re: How to split (A/B) test landing pages using httpd(8)

[Rafael Possamai]

>Does anyone know if it's possible to rotate/alternate between two
>files for the same given request path, using just httpd?

It might be a cleaner implementation if you use relayd(8) to load balance 
requests, there's also relayctl(8) which you could use to gather diagnostics, 
etc.

Personally, I have never attempted this with httpd alone.

How to split (A/B) test landing pages using httpd(8)

[Clint Pachl]

Does anyone know if it's possible to rotate/alternate between two
files for the same given request path, using just httpd?

For example, I want to split test two pages: /test/A & /test/B. I would
like to serve half of the traffic to each for the request path /test/.

Ideally, I would like to do an internal rewrite of the request. And be
able to log which file was actually served to the client.

Here's what I have so far, but I would like to avoid the redirect and
URL change on the client.

# httpd.conf: A/B test

location "/test/*[0-4]" {
request rewrite "/test/A"
}
location "/test/*[5-9]" {
request rewrite "/test/B"
}
location "/test/" {
block return 302 "$DOCUMENT_URI$REMOTE_PORT"
}


I'm using OpenBSD 6.8. I see there is a "not found" directive in 6.9.
Maybe something like that could provide possibilities?

Re: C99 math functions ilogb, ilogbf fail test

[Yuki Kimoto]

Thank you. Andrew Hewus Fresh

It seems like fixed ilogb and ilogbf bugs in OpenBSD 6.8.


SPVM_Util.t test failing seem like srand.

This should be skipped in OpenBSD.


2021年2月10日(水) 14:40 Andrew Hewus Fresh :

> On Wed, Feb 10, 2021 at 01:58:37PM +0900, Yuki Kimoto wrote:
> > I'm Yuki Kimoto. I'm Perl CPAN Author.
>
> Hello, I too am a CPAN author, it's a nice group of folks to be a part
> of.  I do need to do a better job of maintaining my modules though.
>
> > I'm currently writing a module SPVM in Perl that binds C99 math
> functions.
> >
> > SPVM - Static Perl Virtual Machine. Fast Calculation, Fast Array
> Operation,
> > and Easy C/C++ Binding. - metacpan.org <https://metacpan.org/pod/SPVM>
>
> Very exciting!
>
>
> > In CPAN testers, some tests failed. that seems like ilogb and ilogbf
> >
> > CPAN Testers Reports: FAIL SPVM-0.0932 5.30.2 OpenBSD
> > <
> http://www.cpantesters.org/cpan/report/1b13d240-6ad5-11eb-84bc-edd243e66a77
> >
>
> Unfortunately that test is from an out-of-support version of perl and
> the build doesn't seem to like the "-j8" that my smoker uses so I can't
> find any useful reports.
>
> http://www.cpantesters.org/cpan/report/b876eef8-6a0f-11eb-b536-bba28fda8de9
>
>
> > If you have information for these function bugs, can you tell me?
>
>
> Also with all the warning noise in that log it's hard to know quite what
> is going wrong.  A simpler and smaller snippet of what isn't working
>
> I did try running these tests again on my laptop running a recent
> snapshot of OpenBSD and there were still a few failures, but not nearly
> as many.
>
> t/default/SPVM_Util.t     (Wstat: 256 Tests: 115 Failed: 1)
>   Failed test:  38
>   Non-zero exit status: 1
> t/precompile/SPVM_Util.t  (Wstat: 256 Tests: 115 Failed: 1)
>   Failed test:  38
>   Non-zero exit status: 1
> Files=193, Tests=3587, 269 wallclock secs ( 1.11 usr  1.95 sys + 203.14
> cusr 48.67 csys = 254.87 CPU)
> Result: FAIL
> Failed 2/193 test programs. 2/3587 subtests failed.
>
>
> Attached is a script(1) log of those tests, perhaps you will be able to
> pull more detail from those.
>
> l8rZ,
> --
> andrew - http://afresh1.com
>
> Software doesn't do what you want it to do, it does what you tell it do.
>   -- Stefan G. Weichinger.
>

C99 math functions ilogb, ilogbf fail test

[Yuki Kimoto]

Hi,

I'm Yuki Kimoto. I'm Perl CPAN Author.

I'm currently writing a module SPVM in Perl that binds C99 math functions.

SPVM - Static Perl Virtual Machine. Fast Calculation, Fast Array Operation,
and Easy C/C++ Binding. - metacpan.org 

In CPAN testers, some tests failed. that seems like ilogb and ilogbf

CPAN Testers Reports: FAIL SPVM-0.0932 5.30.2 OpenBSD


If you have information for these function bugs, can you tell me?

Re: amdgpu test ends up with blank screen

[Jens A. Griepentrog]

Dear Listeners,

Two releases later I have tried out my Radeon RX 570 Nitro+ 8GB graphics 
card on a similar mainboard (Supermicro X9SRA), and it works fine!

Sorry, but only now I have found out that some pins of one of the
E5 processor sockets of the original X9DRi-F mainboard were damaged.
(Onboard graphics works but no dedicated graphic card. Probably
neither the AMD graphics card nor the amdgpu driver caused the problem.)
For the sake of completeness, I will append the dmesg for the new setup.

Thank you and with best regards,
Jens

OpenBSD 6.8 (GENERIC.MP) #2: Sat Dec  5 07:17:48 MST 2020

r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 68666306560 (65485MB)
avail mem = 66570280960 (63486MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec700 (113 entries)
bios0: vendor American Megatrends Inc. version "3.2" date 01/16/2015
bios0: Supermicro X9SRA/X9SRA-3
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC HPET SSDT MCFG DMAR EINJ ERST HEST BERT
acpi0: wakeup devices PS2K(S4) PS2M(S4) P0P9(S1) EUSB(S4) USBE(S4) 
PEX0(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) NPE4(S4) NPE5(S4) NPE6(S4) 
NPE7(S4) NPE8(S4) NPE9(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.32 MHz, 06-3e-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04
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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 10 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 0, 

Re: axen - need working USB NIC using axen to test driver change

[Pratik Vyas]

* gwes  [2020-05-03 19:10:35 -0400]:

> Currently axen.c has its PHY address hardwired to 3.
> I have a StarTech which has the PHY at 0.
> The driver currently searches for all PHYs connected to the MII
> and then ignores the result.
> I want to test my fix on devices which work now.
> 
> Can anyone point me to a USB NIC which works with axen?
> thanks
> Geoff Steckel
> 

Hi Goeff,

I have an USB axen(4) branded as amazon basics.  It works.
happy to test your diff! :)

>From dmesg:
axen0 at uhub0 port 12 configuration 1 interface 0 "ASIX Elec. Corp. AX88179" 
rev 3.00/1.00 addr 5
axen0: AX88179, address 00:50:b6:1c:1d:fa
rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 PHY, rev. 5

>From lsusb:
Bus 000 Device 005: ID 0b95:1790 ASIX Electronics Corp.

--
Pratik

Re: axen - need working USB NIC using axen to test driver change

[Carl Trachte]

On Sun, May 3, 2020 at 4:12 PM gwes  wrote:

> Currently axen.c has its PHY address hardwired to 3.
> I have a StarTech which has the PHY at 0.
> The driver currently searches for all PHYs connected to the MII
> and then ignores the result.
> I want to test my fix on devices which work now.
>
> Can anyone point me to a USB NIC which works with axen?
> thanks
> Geoff Steckel
>

I’m using the StarTech usb 3.0 one on the ThinkPad X1 Carbon. I don’t have
the machine booted up at the moment but I’m running OpenBSD 6.6 and it
works with the axen driver.

I also purchased a usb 2.0 one - this is recognized as an axen device but
it did not work on the ThinkPad X1.  I have not yet tried it on another
older laptop.

>
>

axen - need working USB NIC using axen to test driver change

[gwes]

Currently axen.c has its PHY address hardwired to 3.
I have a StarTech which has the PHY at 0.
The driver currently searches for all PHYs connected to the MII
and then ignores the result.
I want to test my fix on devices which work now.

Can anyone point me to a USB NIC which works with axen?
thanks
Geoff Steckel

Re: How to test for FORTIFY_SOURCE?

[Ingo Schwarze]

Hi Luke,

Luke A. Call wrote on Wed, Mar 18, 2020 at 12:54:10PM -0600:
> On 03-18 19:22, Ingo Schwarze wrote:
>> Theo de Raadt wrote:

>>> Ingo -- I think using man.openbsd.org as a "testbed for all possible
>>> man page hierarchies" incorrect.

>> It was never a testbed, but a production service with several parts
>> provided nowhere else (well, at least until FreeBSD followed our
>> lead and started providing something very similar).
>> 
>> For example, for DragonFly, Illumos, and NetBSD, semantic searching
>> is neither supported by their native apropos(1) on the command line
>> nor by their own websites.
>> 
>> But since you have a point that such services hardly belong
>> on *.openbsd.org, they are now on *.bsd.lv, where misunderstandings
>> like the one witnessed above are unlikely to happen.

> Providing a simple link from the man.openbsd.org page to the services
> on *.bsd.lv might help those who are used to looking in the old
> location, while avoiding possible "which bsd" confusion (maybe called 
> "Some other systems' manuals", or such).  Especially for those not
> reading this thread.  Just a thought.

Makes sense, done.

Note that in addition to man.openbsd.org, man.bsd.lv is now also
up and running, but the latter will only contain release manual
pages for a number of systems (including OpenBSD) but not
OpenBSD-current.

Yours,
  Ingo

Re: How to test for FORTIFY_SOURCE?

[lists]

Wed, 18 Mar 2020 11:55:53 -0400 Jeffrey Walton 
> On Wed, Mar 18, 2020 at 11:25 AM Andreas Kusalananda Kähäri
>  wrote:
> >
> > On Wed, Mar 18, 2020 at 10:59:21AM -0400, Jeffrey Walton wrote:  
> > > On Wed, Mar 18, 2020 at 4:26 AM Stuart Henderson  
> > > wrote:  
> > > >
> > > > On 2020-03-18, Jeffrey Walton  wrote:  
> > > > > According to 
> > > > > https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
> > > > > OpenBSD implements glibc bounds checking on certain functions. I am
> > > > > trying to detect FORTIFY_SOURCE without looking up operating system
> > > > > names and versions.  
> > > >
> > > > That is a NetBSD manual page, it does not apply to OpenBSD.  
> > >
> > > Thanks.
> > >
> > > I may be splitting hairs, but the pages title clearly says it is an
> > > OpenBSD man page.  
> >
> > I have no real connection to the OpenBSD project other than being a long
> > time user, and I have an interest in documentation.
> >
> > It says, at the top of the page, it says "OpenBSD manual page server",
> > i.e. it's a manual page server hosted by the OpenBSD project.  The
> > link that you mention contains the string "NetBSD-8.1" and the name
> > of the manual that you're looking at is "security — NetBSD security
> > features".  Also, "NetBSD-8.1" is repeated in the page footer and the
> > string "NetBSD" occurs many times throughout the page while "OpenBSD"
> > really only occurs once.  
> 
> Hovering the mouse over the open tab says "security(7) - OpenBSD man
> pages". I double checked it when I saw the references to NetBSD.
> 
> Regarding the references to NetBSD, I thought your sed went sideways.
> I assumed OpenBSD and NetBSD were collaborating and shared code and
> docs in some places.
> 
> Figuring out why the sed was broken was not my task at hand. I was on
> the site to figure out why my test for FORTIFY_SOURCE was failing. The
> admins can figure that out why the document conversion is not working
> they notice it.
> 
> Jeff
> 

Hi Jeffrey,

I find the ability to check other manual pages so valuable.  People are aware
when they make a mistake, it's theirs for not checking what they are actually
looking at.  Instead of blaming the service available for confusing them like
it's so popular online these days.  The confusion is yours, just please don't
request service degradation for the rest of us because ot that.  These online
manual pages are useful, let's all keep our eyes open and honest about it ;-)

Kind regards,
Anton Lazarov
MScEng EECSIT

Re: How to test for FORTIFY_SOURCE?

[Luke A. Call]

On 03-18 20:29, Ingo Schwarze wrote:
> I have definitely collaborated with at least these NetBSD developers
> in the past:

And a lame but sincere thanks to Ingo, Theo, and everyone else, 
for the impressive work freely given, and for patiently tolerating 
the rest of us.

Re: How to test for FORTIFY_SOURCE?

[Ingo Schwarze]

Hi,

Theo de Raadt wrote on Wed, Mar 18, 2020 at 12:44:03PM -0600:
> Ingo Schwarze  wrote:
>> Jeffrey Walton wrote on Wed, Mar 18, 2020 at 11:55:53AM -0400:

>>> I assumed OpenBSD and NetBSD were collaborating and shared code
>>> and docs in some places.

>> To a limited extent, that is true.

> To a limited extent, it is true that birds and fish are friends.
> 
> In other words, it is untrue.  There isn't collaboration.

I have definitely collaborated with at least these NetBSD developers
in the past:

 * Joerg Sonnenberger (joerg@)
 * Thomas Klausner (wiz@)
 * Christos Zoulas (christos@)

"Collaboration" in the sense that there was consistent working
together on joint projects for months, with Joerg even for years.
Besides, Sevan Janiyan (sevan@) has been one of the most prolific
mandoc release testers for four years now, to the point that i might
call that collaboration.  Eight other NetBSD developers have provided
minor contributions over the years, the overall effect of which
also feels like systematic collaboration to me.

Similar effects exist for FreeBSD (bapt@) and Debian (stapelberg@)
and to a lesser degree for Illumos (Yuri Pankov) and Void Linux (Leah
Neukirchen).

I even attended a mini-hackathon organized by a NetBSD developer
in the past, and the code both the NetBSD developer and i wrote
there is still part of both OpenBSD and NetBSD.  That is certainly
worth being called collaboration.

> And there isn't sharing.  At best there is freely given stuff which
> is sometimes taken.  I propose not using the word "share" since people
> may believe it is one of the stronger meanings of the word.  At best
> it is the weakest meaning.

It seems true that "freely give" is not as easily misunderstood
as "share".

Yours,
  Ingo

Re: How to test for FORTIFY_SOURCE?

[Luke A. Call]

On 03-18 19:22, Ingo Schwarze wrote:
> > Ingo -- I think using man.openbsd.org as a "testbed for all possible
> > man page hierarchies" incorrect.
> 
> It was never a testbed, but a production service with several parts
> provided nowhere else (well, at least until FreeBSD followed our
> lead and started providing something very similar).
> 
> For example, for DragonFly, Illumos, and NetBSD, semantic searching
> is neither supported by their native apropos(1) on the command line
> nor by their own websites.
> 
> But since you have a point that such services hardly belong
> on *.openbsd.org, they are now on *.bsd.lv, where misunderstandings
> like the one witnessed above are unlikely to happen.

Providing a simple link from the man.openbsd.org page to the services
on *.bsd.lv might help those who are used to looking in the old
location, while avoiding possible "which bsd" confusion (maybe called 
"Some other systems' manuals", or such).  Especially for those not
reading this thread.  Just a thought.


-- 
Luke Call
My thoughts:  http://lukecall.net  (updated 2020-03-13)

Re: How to test for FORTIFY_SOURCE?

[Theo de Raadt]

Ingo Schwarze  wrote:

> Hi Jeffrey,
> 
> Jeffrey Walton wrote on Wed, Mar 18, 2020 at 11:55:53AM -0400:
> 
> > I assumed OpenBSD and NetBSD were collaborating and shared code and
> > docs in some places.
> 
> To a limited extent, that is true.

To a limited extent, it is true that birds and fish are friends.

In other words, it is untrue.  There isn't collaboration.  And there
isn't sharing.  At best there is freely given stuff which is sometimes
taken.  I propose not using the word "share" since people may believe it
is one of the stronger meanings of the word.  At best it is the weakest
meaning.

Re: How to test for FORTIFY_SOURCE?

[Ingo Schwarze]

Hi Jeffrey,

Jeffrey Walton wrote on Wed, Mar 18, 2020 at 11:55:53AM -0400:

> I assumed OpenBSD and NetBSD were collaborating and shared code and
> docs in some places.

To a limited extent, that is true.

For example, NetBSD includes mandoc(1) which is predominantly
developed on OpenBSD while OpenBSD includes editline(7) which
is predominantly developed on NetBSD.

But that doesn't mean either system slavishly copies changes
from the other, nor that components both contain work in
exactly the same way.  Developers of both systems use their
own judgement to decide what to merge from the other system,
and when.

So please do use the documentation from the right system even
for those components that are very similar on both, or you will
sooner or later stumble over some subtle difference.

Yours,
  Ingo

Re: How to test for FORTIFY_SOURCE?

[Ingo Schwarze]

Hi Theo,

Theo de Raadt wrote on Wed, Mar 18, 2020 at 09:06:25AM -0600:
> Jeffrey Walton  wrote:

>> What is the purpose of supplying man pages for the wrong operating
>> system?

The purpose is to make it simpler to compare how different systems
work without having to jump back and forth among different sites
using different URI schemes and running different software.  Also,
the man.cgi(8) from the mandoc toolset is way better than the software
running on netbsd.gw.com, leaf.dragonflybsd.org, illumos.org, and
man7.org, which provide neither semantic searching nor tagging/deep
linking of comparable quality.

Note that www.freebsd.org now also runs the man.cgi(8) from the
mandoc toolset - after several years hoping to switch to it, they
finally did it.

>> It wastes people's time and breaks search. This search does
>> not produce expected results:
>> https://www.google.com/search?q=FORTIFY_SOURCE+site%3Aopenbsd.org.

Do not search the web for software documentation.  That's a bad idea
in the first place.  You are likely to end up with documentation for
the wrong version of the software in question, which is exactly
what happened to you here.  Use autoritative documentation for the
system you are interested in, instead.

>> If you really want to confuse folks, maybe OpenSD can supply
>> Windows man pages.

> I'm going to stand up and agree.

You have a point that non-OpenBSD manual pages are better served
from the *portable* mandoc site than from man.openbsd.org.
So i just deleted the non-OpenBSD lines from manpath.conf
on man.openbsd.org.

For now, comparing different systems can be done here:

  https://mandoc.bsd.lv/cgi-bin/man.cgi/

That URI is quite ugly, i'll try to figure out whether i can move
that to simply man.bsd.lv.

> Ingo -- I think using man.openbsd.org as a "testbed for all possible
> man page hierarchies" incorrect.

It was never a testbed, but a production service with several parts
provided nowhere else (well, at least until FreeBSD followed our
lead and started providing something very similar).

For example, for DragonFly, Illumos, and NetBSD, semantic searching
is neither supported by their native apropos(1) on the command line
nor by their own websites.

But since you have a point that such services hardly belong
on *.openbsd.org, they are now on *.bsd.lv, where misunderstandings
like the one witnessed above are unlikely to happen.

Yours,
  Ingo

Re: How to test for FORTIFY_SOURCE?

[Stuart Henderson]

On 2020/03/18 11:55, Jeffrey Walton wrote:
> On Wed, Mar 18, 2020 at 11:25 AM Andreas Kusalananda Kähäri
>  wrote:
> >
> > On Wed, Mar 18, 2020 at 10:59:21AM -0400, Jeffrey Walton wrote:
> > > On Wed, Mar 18, 2020 at 4:26 AM Stuart Henderson  
> > > wrote:
> > > >
> > > > On 2020-03-18, Jeffrey Walton  wrote:
> > > > > According to 
> > > > > https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
> > > > > OpenBSD implements glibc bounds checking on certain functions. I am
> > > > > trying to detect FORTIFY_SOURCE without looking up operating system
> > > > > names and versions.
> > > >
> > > > That is a NetBSD manual page, it does not apply to OpenBSD.
> > >
> > > Thanks.
> > >
> > > I may be splitting hairs, but the pages title clearly says it is an
> > > OpenBSD man page.
> >
> > I have no real connection to the OpenBSD project other than being a long
> > time user, and I have an interest in documentation.
> >
> > It says, at the top of the page, it says "OpenBSD manual page server",
> > i.e. it's a manual page server hosted by the OpenBSD project.  The
> > link that you mention contains the string "NetBSD-8.1" and the name
> > of the manual that you're looking at is "security — NetBSD security
> > features".  Also, "NetBSD-8.1" is repeated in the page footer and the
> > string "NetBSD" occurs many times throughout the page while "OpenBSD"
> > really only occurs once.
> 
> Hovering the mouse over the open tab says "security(7) - OpenBSD man
> pages". I double checked it when I saw the references to NetBSD.
> 
> Regarding the references to NetBSD, I thought your sed went sideways.
> I assumed OpenBSD and NetBSD were collaborating and shared code and
> docs in some places.
> 
> Figuring out why the sed was broken was not my task at hand. I was on
> the site to figure out why my test for FORTIFY_SOURCE was failing. The
> admins can figure that out why the document conversion is not working
> they notice it.
> 
> Jeff

Since OpenBSD does not have FORTIFY_SOURCE it is correct that your test
for it is failing on OpenBSD.

Re: How to test for FORTIFY_SOURCE?

[Jeffrey Walton]

On Wed, Mar 18, 2020 at 11:25 AM Andreas Kusalananda Kähäri
 wrote:
>
> On Wed, Mar 18, 2020 at 10:59:21AM -0400, Jeffrey Walton wrote:
> > On Wed, Mar 18, 2020 at 4:26 AM Stuart Henderson  
> > wrote:
> > >
> > > On 2020-03-18, Jeffrey Walton  wrote:
> > > > According to 
> > > > https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
> > > > OpenBSD implements glibc bounds checking on certain functions. I am
> > > > trying to detect FORTIFY_SOURCE without looking up operating system
> > > > names and versions.
> > >
> > > That is a NetBSD manual page, it does not apply to OpenBSD.
> >
> > Thanks.
> >
> > I may be splitting hairs, but the pages title clearly says it is an
> > OpenBSD man page.
>
> I have no real connection to the OpenBSD project other than being a long
> time user, and I have an interest in documentation.
>
> It says, at the top of the page, it says "OpenBSD manual page server",
> i.e. it's a manual page server hosted by the OpenBSD project.  The
> link that you mention contains the string "NetBSD-8.1" and the name
> of the manual that you're looking at is "security — NetBSD security
> features".  Also, "NetBSD-8.1" is repeated in the page footer and the
> string "NetBSD" occurs many times throughout the page while "OpenBSD"
> really only occurs once.

Hovering the mouse over the open tab says "security(7) - OpenBSD man
pages". I double checked it when I saw the references to NetBSD.

Regarding the references to NetBSD, I thought your sed went sideways.
I assumed OpenBSD and NetBSD were collaborating and shared code and
docs in some places.

Figuring out why the sed was broken was not my task at hand. I was on
the site to figure out why my test for FORTIFY_SOURCE was failing. The
admins can figure that out why the document conversion is not working
they notice it.

Jeff

Re: How to test for FORTIFY_SOURCE?

[Andreas Kusalananda Kähäri]

On Wed, Mar 18, 2020 at 10:59:21AM -0400, Jeffrey Walton wrote:
> On Wed, Mar 18, 2020 at 4:26 AM Stuart Henderson  wrote:
> >
> > On 2020-03-18, Jeffrey Walton  wrote:
> > > According to https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
> > > OpenBSD implements glibc bounds checking on certain functions. I am
> > > trying to detect FORTIFY_SOURCE without looking up operating system
> > > names and versions.
> >
> > That is a NetBSD manual page, it does not apply to OpenBSD.
> 
> Thanks.
> 
> I may be splitting hairs, but the pages title clearly says it is an
> OpenBSD man page.

I have no real connection to the OpenBSD project other than being a long
time user, and I have an interest in documentation.

It says, at the top of the page, it says "OpenBSD manual page server",
i.e. it's a manual page server hosted by the OpenBSD project.  The
link that you mention contains the string "NetBSD-8.1" and the name
of the manual that you're looking at is "security — NetBSD security
features".  Also, "NetBSD-8.1" is repeated in the page footer and the
string "NetBSD" occurs many times throughout the page while "OpenBSD"
really only occurs once.

> 
> What is the purpose of supplying man pages for the wrong operating
> system? It wastes people's time and breaks search. This search does
> not produce expected results:
> https://www.google.com/search?q=FORTIFY_SOURCE+site%3Aopenbsd.org.
> 
> If you really want to confuse folks, maybe OpenSD can supply Windows man 
> pages.
> 
> Jeff

It's debatable whether the manuals for systems other than OpenBSD should
be hosted at man.openbsd.org, but citing "confusion" is probably not a
reason to stop providing these.  If you want uptodate manuals for the
system that you're using, I hope that you're using the man(1) command on
the command line and taht you don't rely on the correctness of manuals
found on the web.

I don't think Windows has manuals in man or mandoc format that are free
to host.

-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.

Re: How to test for FORTIFY_SOURCE?

[Martijn van Duren]

On 3/18/20 3:59 PM, Jeffrey Walton wrote:
> On Wed, Mar 18, 2020 at 4:26 AM Stuart Henderson  wrote:
>>
>> On 2020-03-18, Jeffrey Walton  wrote:
>>> According to https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
>>> OpenBSD implements glibc bounds checking on certain functions. I am
>>> trying to detect FORTIFY_SOURCE without looking up operating system
>>> names and versions.
>>
>> That is a NetBSD manual page, it does not apply to OpenBSD.
> 
> Thanks.
> 
> I may be splitting hairs, but the pages title clearly says it is an
> OpenBSD man page.
> 
> What is the purpose of supplying man pages for the wrong operating
> system? It wastes people's time and breaks search. This search does
> not produce expected results:
> https://www.google.com/search?q=FORTIFY_SOURCE+site%3Aopenbsd.org.
> 
> If you really want to confuse folks, maybe OpenSD can supply Windows man 
> pages.
> 
> Jeff
> 
What do you mean?
Do you mean "OpenBSD manual page server", which clearly states OpenBSD's
the just the server.
>From the NAME section: "security — NetBSD security features"
>From the DESCRIPTION section: "NetBSD supports a variety of security
features"
>From the footer: "May 21, 2016 NetBSD-8.1"

On the entire page OpenBSD is only mentioned once, NetBSD 16 times, not
including the drop down menu allowing you to select your operating
system + version of choice.

To me this feels similar to someone coming to the list and asking why
they can't find snmpctl on their OpenBSD 6.6 machine, because some
search engine send them to a 6.5 or older page.

Re: How to test for FORTIFY_SOURCE?

[Theo de Raadt]

Jeffrey Walton  wrote:

> On Wed, Mar 18, 2020 at 4:26 AM Stuart Henderson  wrote:
> >
> > On 2020-03-18, Jeffrey Walton  wrote:
> > > According to https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
> > > OpenBSD implements glibc bounds checking on certain functions. I am
> > > trying to detect FORTIFY_SOURCE without looking up operating system
> > > names and versions.
> >
> > That is a NetBSD manual page, it does not apply to OpenBSD.
> 
> Thanks.
> 
> I may be splitting hairs, but the pages title clearly says it is an
> OpenBSD man page.
> 
> What is the purpose of supplying man pages for the wrong operating
> system? It wastes people's time and breaks search. This search does
> not produce expected results:
> https://www.google.com/search?q=FORTIFY_SOURCE+site%3Aopenbsd.org.
> 
> If you really want to confuse folks, maybe OpenSD can supply Windows man 
> pages.

I'm going to stand up and agree.

Ingo -- I think using man.openbsd.org as a "testbed for all possible man
page hierarchies" incorrect.

Re: How to test for FORTIFY_SOURCE?

[Jeffrey Walton]

On Wed, Mar 18, 2020 at 4:26 AM Stuart Henderson  wrote:
>
> On 2020-03-18, Jeffrey Walton  wrote:
> > According to https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
> > OpenBSD implements glibc bounds checking on certain functions. I am
> > trying to detect FORTIFY_SOURCE without looking up operating system
> > names and versions.
>
> That is a NetBSD manual page, it does not apply to OpenBSD.

Thanks.

I may be splitting hairs, but the pages title clearly says it is an
OpenBSD man page.

What is the purpose of supplying man pages for the wrong operating
system? It wastes people's time and breaks search. This search does
not produce expected results:
https://www.google.com/search?q=FORTIFY_SOURCE+site%3Aopenbsd.org.

If you really want to confuse folks, maybe OpenSD can supply Windows man pages.

Jeff

Re: How to test for FORTIFY_SOURCE?

[Stuart Henderson]

On 2020-03-18, Jeffrey Walton  wrote:
> According to https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
> OpenBSD implements glibc bounds checking on certain functions. I am
> trying to detect FORTIFY_SOURCE without looking up operating system
> names and versions.

That is a NetBSD manual page, it does not apply to OpenBSD.

How to test for FORTIFY_SOURCE?

[Jeffrey Walton]

According to https://man.openbsd.org/NetBSD-8.1/security.7#FORTIFY_SOURCE
OpenBSD implements glibc bounds checking on certain functions. I am
trying to detect FORTIFY_SOURCE without looking up operating system
names and versions.

The following code works for Linux, but fails under OpenBSD (it is
part of an autoconf test):

#include 
int main(int argc, char** argv)
{
  [char msg[16];]
  #[strcpy(msg, argv[0]);]
  #[return (int)(msg[0] & ~msg[1]);]
  [memcpy(msg, argv[0], strlen(argv[0]));]
  [return msg[0] != msg[strlen(argv[0])-1];]
}

I then compile it and scan for the fortified function call:

if $CC -D_FORTIFY_SOURCE=2 $CPPFLAGS -O2 $CFLAGS fortify_test.c -o
fortify_test.exe;
then
  count=`readelf --relocs fortify_test.exe | grep -i -c '_chk'`
  if test "$count" -ne 0; then
AC_MSG_RESULT([yes]); NSD_CPPFLAGS="$NSD_CPPFLAGS -D_FORTIFY_SOURCE=2"
  else
AC_MSG_RESULT([no])
  fi
fi

The problem is, OpenBSD is not using the fortified function even
though the destination buffer size can be deduced:

$ readelf --relocs fortify_test.exe | grep -i -c '_chk'
0

And:

$ readelf --relocs fortify_test.exe

Relocation section '.rela.dyn' at offset 0x488 contains 2 entries:
  Offset  Info   Type   Sym. ValueSym. Name + Addend
2168  0008 R_X86_64_RELATIVE13e0
2160  00030006 R_X86_64_GLOB_DAT 
_Jv_RegisterClasses + 0

Relocation section '.rela.plt' at offset 0x4b8 contains 7 entries:
  Offset  Info   Type   Sym. ValueSym. Name + Addend
2188  00010007 R_X86_64_JUMP_SLO  _csu_finish + 0
2190  00020007 R_X86_64_JUMP_SLO  exit + 0
2198  00030007 R_X86_64_JUMP_SLO 
_Jv_RegisterClasses + 0
21a0  00040007 R_X86_64_JUMP_SLO  atexit + 0
21a8  00050007 R_X86_64_JUMP_SLO  strlen + 0
21b0  00060007 R_X86_64_JUMP_SLO  memcpy + 0
21b8  00070007 R_X86_64_JUMP_SLO 
__stack_smash_handler + 0

I expect to see memcpy_chk or strcpy_chk.

Do I have a misunderstanding of OpenBSD's implementation?

If someone could point out what is wrong I would greatly appreciate it.

amdgpu test ends up with blank screen

[Jens A. Griepentrog]

Dear Listeners,

I have tried out to run Radeon RX 570 Nitro+ 8GB graphics card
on Supermicro X9DRi-F mainboard, see the dmesg output below.
(There is no Xorg.log to send ...) Messages stop with black
screen just before

initializing kernel modesetting (POLARIS10 0x1002:0x67DF 0x1DA2:0xE366 
0xEF).

amdgpu_irq_add_domain: stub
amdgpu_device_resize_fb_bar: stub
amdgpu: [powerplay] Failed to retrieve minimum clocks.
amdgpu0: 1600x1200, 32bpp
wsdisplay1 at amdgpu0
wsdisplay1: screen 0-5 added (std, vt100 emulation)

... machine still responsive over network ... clean shutdown
... graphics card removed ... switched back to onboard graphics

With best regards and many thanks to the developers,
Jens

OpenBSD 6.6 (GENERIC.MP) #3: Thu Nov 21 03:20:01 MST 2019

r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 274826579968 (262095MB)
avail mem = 266484756480 (254139MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec0c0 (136 entries)
bios0: vendor American Megatrends Inc. version "3.3" date 07/12/2018
bios0: Supermicro X9DR3-F
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG SRAT SLIT HPET PRAD SPMI SSDT 
EINJ ERST HEST BERT DMAR
acpi0: wakeup devices P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PEX1(S1) 
PEX2(S1) PEX3(S1) PEX4(S1) PEX5(S1) PEX6(S1) PEX7(S1) NPE1(S1) NPE2(S1) 
GBE_(S4) I350(S4) NPE3(S1) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz, 2200.33 MHz, 06-2d-07
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz, 2200.01 MHz, 06-2d-07
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz, 2200.01 MHz, 06-2d-07
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,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz, 2200.01 MHz, 06-2d-07
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz, 2200.01 MHz, 06-2d-07
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 10 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz, 2200.01 MHz, 06-2d-07
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 0, core 5, package 0
cpu6 at mainbus0: apid 12 

Test suites for netcat

[Shreeasish Kumar]

Is there a test suite available for netcat?
Specifically for testing for functional correctness.
I'm playing around with pledges and it would be interesting
to know how pledges are tested as well.

Thanks

Re: please ignore -- final test ?????? in posts

[Larry Hynes]

niya <niyal...@gmail.com> wrote:
> 
> 
> On 16/03/2018 12:51, Larry Hynes wrote:
> > Hi
> >
> > niya <niyal...@gmail.com> wrote:
> >> if anybody does read this post
> >>
> >> i'm trying to narrow down why i'm getting rows of ??
> >>
> >> when i cut and paste information from the console to my mail client
> >>
> >> i use thunderbird to compose my mail
> >>
> >>
> >> #test VM
> >> vm "base-vm" {
> >>       boot "/bsd"
> > Your messages include non-breaking spaces (' ')[0], which are possibly
> > showing as '?' for you.
> >
> > For example, in the line above
> >
> >      boot "/bsd"
> >
> > that line is preceded by seven non-breaking spaces.
> >
> > So it is possible that when you cut and paste information to your
> > mail client it represents those characters as '?'.
> >
> > [0]: https://unicode-table.com/en/00A0/
> 
> Hi Larry
> thanks for the reply
> do you have a suggestion how i would fix this before posting and messing 
> up the mail received by the list ?
> shadrock

Hi

I don't know enough about your local setup to make any suggestions.
(A simple solution would be to find and replace all non-breaking
spaces on any mails you send.)

Re: please ignore -- final test ?????? in posts

[niya]

On 16/03/2018 12:51, Larry Hynes wrote:

Hi

niya <niyal...@gmail.com> wrote:

if anybody does read this post

i'm trying to narrow down why i'm getting rows of ??

when i cut and paste information from the console to my mail client

i use thunderbird to compose my mail


#test VM
vm "base-vm" {
      boot "/bsd"

Your messages include non-breaking spaces (' ')[0], which are possibly
showing as '?' for you.

For example, in the line above

     boot "/bsd"

that line is preceded by seven non-breaking spaces.

So it is possible that when you cut and paste information to your
mail client it represents those characters as '?'.

[0]: https://unicode-table.com/en/00A0/


Hi Larry
thanks for the reply
do you have a suggestion how i would fix this before posting and messing 
up the mail received by the list ?

shadrock

please ignore -- final test ?????? in posts

[niya]

if anybody does read this post

i'm trying to narrow down why i'm getting rows of ??

when i cut and paste information from the console to my mail client

i use thunderbird to compose my mail


#test VM
vm "base-vm" {
    boot "/bsd"
    enable
    owner alarm
    memory 256M
    disk $img_home vmm_base6.3.img
    interface { switch "local"
    lladdr fe:e1:bb:d1:a8:9d }
    }


switch "local" {
    interface bridge0
}

ifconfig

bridge0: flags=41<UP,RUNNING>
    description: switch1-local
    index 4 llprio 3
    groups: bridge
    priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 
proto rstp

    vether0 flags=3<LEARNING,DISCOVER>
    port 5 ifpriority 0 ifcost 0
    tap0 flags=3<LEARNING,DISCOVER>
    port 7 ifpriority 0 ifcost 0
vether0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    lladdr fe:e1:ba:d0:35:c9
    index 5 priority 0 llprio 3
    groups: vether
    media: Ethernet autoselect
    status: active
    inet 10.13.37.1 netmask 0xff00 broadcast 10.13.37.255
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
    index 6 priority 0 llprio 3
    groups: pflog
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    lladdr fe:e1:ba:d1:41:23
    description: vm1-if0-base-vm
    index 7 priority 0 llprio 3
    groups: tap
    status: active

 cat /etc/dhcpd.conf
option  domain-name "vmm.tissisat.co.uk";
option  domain-name-servers 10.2.1.6, 10.2.1.8;

subnet 10.13.37.0 netmask 255.255.255.0 {
    option routers 10.13.37.1;

    range 10.13.37.32 10.13.37.127;

host base {
    hardware ethernet   fe:e1:bb:d1:a8:9d;
    fixed-address 10.13.37.203;
    }
}

please ignore -- just a test

[niya]

switch "local" {
    interface bridge0
}

# Test VM
vm "test-vm" {
    disable
    owner alarm
    memory 256M
    disk "/home/alarm/vmm_network/vmm_base6.3.img"
    interface { switch "local"
    lladdr  fe:e1:bb:d1:6d:8d }
    }

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Kevin Chadwick]

On Thu, 12 Oct 2017 18:16:02 +


> See https://marc.info/?l=openbsd-cvs=150783205404965

Nice, Thankyou

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Robert Peichaer]

On Tue, Oct 10, 2017 at 06:35:49PM +, Kevin Chadwick wrote:
> On Wed, 27 Sep 2017 21:43:48 -0500
> 
> 
> > Why is this happening, and is there anything that I should do to
> > correct
> > 
> 
> The system has been getting more and more dynamic to make attackers
> fumble in the dark.
> 
> > the "Permission denied" error?
> 
> If you prefer then add: 
> 
> /sbin/mount -uo noexec /tmp 
> 
> to /etc/rc.local
> 
> The new pledge powers that have been mentioned recently potentially make
> noexec more useful ;)
> 
> I am moving all potentially problematic fstab changes such as ro
> to /etc/rc.local (/sbin/mount -urf /), letting the devs use the system
> during boot as they would their own system.

See https://marc.info/?l=openbsd-cvs=150783205404965

-- 
-=[rpe]=-

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Theo de Raadt]

You own all the pieces.

> RO /usr also breaks the shiny new kernel relinking.
> 
> So the best I have come up with is crontab lines
> 
> @reboot sleep 60 mount -urf /usr
> 
> The 60 may be too short on very old systems.
> 
> Perhaps it's time to drop the ro but I'm quite attached to my security
> blanket, lol ;)
> 

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Kevin Chadwick]

On Tue, 10 Oct 2017 19:35:49 +0100


> From: Kevin Chadwick <m8il1i...@gmail.com>
> To: misc@openbsd.org
> Subject: Re: reordering libraries:/etc/rc[443]: ./test-ld.so:
> Permission  denied Date: Tue, 10 Oct 2017 19:35:49 +0100
> 
> On Wed, 27 Sep 2017 21:43:48 -0500
> 
> 
> > Why is this happening, and is there anything that I should do to
> > correct
> >   
> 
> The system has been getting more and more dynamic to make attackers
> fumble in the dark.
> 
> > the "Permission denied" error?  
> 
> If you prefer then add: 
> 
> /sbin/mount -uo noexec /tmp 
> 
> to /etc/rc.local
> 
> The new pledge powers that have been mentioned recently potentially
> make noexec more useful ;)
> 
> I am moving all potentially problematic fstab changes such as ro
> to /etc/rc.local (/sbin/mount -urf /), letting the devs use the system
> during boot as they would their own system.

RO /usr also breaks the shiny new kernel relinking.

So the best I have come up with is crontab lines

@reboot sleep 60 mount -urf /usr

The 60 may be too short on very old systems.

Perhaps it's time to drop the ro but I'm quite attached to my security
blanket, lol ;)

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Kevin Chadwick]

On Wed, 27 Sep 2017 21:43:48 -0500


> Why is this happening, and is there anything that I should do to
> correct
> 

The system has been getting more and more dynamic to make attackers
fumble in the dark.

> the "Permission denied" error?

If you prefer then add: 

/sbin/mount -uo noexec /tmp 

to /etc/rc.local

The new pledge powers that have been mentioned recently potentially make
noexec more useful ;)

I am moving all potentially problematic fstab changes such as ro
to /etc/rc.local (/sbin/mount -urf /), letting the devs use the system
during boot as they would their own system.

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Renaud Allard]

On 09/28/2017 06:34 AM, Philip Guenther wrote:
> On Wed, 27 Sep 2017, Theodore Wynnychenko wrote:
> ...
>> Thank you for the information.  I removed the “noexec” flag from fstab 
>> and the error has disappeared.
>>
>> But, I am also surprised by the requirement that /tmp _not_ be mounted 
>> noexec for this to function correctly.  I recall reading that it was 
>> best to mount filesystems with the most restrictive settings possible 
>> for that specific filesystem, and that /tmp should be mounted with 
>> (essentially) nothing set (ie: nodev, nosuid, noexec).
>>
>> Am I incorrect or has something changed in this regard?
>>
>> It seems to me that, as a general rule, making /tmp noexec is a good 
>> thing from a security standpoint; but I admit that I don’t know enough 
>> about this to be sure.
>>
>> Anyway, I just added a line to rc.local to remount temp as noexec at the 
>> end of the boot so that rc would work without errors and that /tmp is 
>> noexec once the system is up.
> 
> To quote a co-worker: "What problem are you trying to solve?"
> Or, in this case: What attack/threat vector are you trying to block?
> 
> What on your system is running with (a) ability to exec (think pledge(2)), 
> *and* (b) access to /tmp but *without* write access to other directories 
> (like $HOME) that aren't mounted noexec?
> 
> If the answer is "nothing", then marking /tmp as noexec is only annoying 
> you.
> 
> 

Sorry to revive an "old" post, but I am trying to understand the logic.

On a desktop, I fully agree with you, it's generally useless.

But on my servers, I have a lot of processes which can write into their
home directories, but those directories are noexec as well. Why would
you need to allow any process to exec things that are not in controlled
paths? As an example, let's say I have dovecot running, why would I let
dovecot run anything besides its own processes that have been written by
root and it cannot modify? Many exploits try to drop binaries into /tmp
by default.

Also, remounting /tmp noexec doesn't work if your /tmp is mfs AFAIK.

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Philip Guenther]

On Wed, 27 Sep 2017, Theodore Wynnychenko wrote:
...
> Thank you for the information.  I removed the “noexec” flag from fstab 
> and the error has disappeared.
> 
> But, I am also surprised by the requirement that /tmp _not_ be mounted 
> noexec for this to function correctly.  I recall reading that it was 
> best to mount filesystems with the most restrictive settings possible 
> for that specific filesystem, and that /tmp should be mounted with 
> (essentially) nothing set (ie: nodev, nosuid, noexec).
> 
> Am I incorrect or has something changed in this regard?
>
> It seems to me that, as a general rule, making /tmp noexec is a good 
> thing from a security standpoint; but I admit that I don’t know enough 
> about this to be sure.
> 
> Anyway, I just added a line to rc.local to remount temp as noexec at the 
> end of the boot so that rc would work without errors and that /tmp is 
> noexec once the system is up.

To quote a co-worker: "What problem are you trying to solve?"
Or, in this case: What attack/threat vector are you trying to block?

What on your system is running with (a) ability to exec (think pledge(2)), 
*and* (b) access to /tmp but *without* write access to other directories 
(like $HOME) that aren't mounted noexec?

If the answer is "nothing", then marking /tmp as noexec is only annoying 
you.


Philip Guenther

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Theodore Wynnychenko]

On Sep 25, 2017, at 9:31 PM, Philip Guenther <guent...@gmail.com> wrote:

On Mon, 25 Sep 2017, Theodore Wynnychenko wrote:



I noticed this message in the dmesg after updating -current yesterday.



I am not sure what it means.



There is no file "test-ld.so" anywhere on the system that I can find.

I also see that it appears this part of rc was just committed in the

last few weeks.



Why is this happening, and is there anything that I should do to correct

the "Permission denied" error?



It means that after /etc/rc had built a new ld.so, when it tried to test
it by running the test-ld.so program (which is packaged inside
/usr/libdata/ld.so.a), it failed with that error, EACCES.

My guess is that you're hitting this:

[EACCES]   The new process file is on a filesystem mounted with
   execution disabled (MNT_NOEXEC in ).

If you're mounting /tmp with the noexec flag, then stop doing that.


Philip Guenther





Thank you for the information.  I removed the “noexec” flag from fstab and the 
error has disappeared.



But, I am also surprised by the requirement that /tmp _not_ be mounted noexec 
for this to function correctly.  I recall reading that it was best to mount 
filesystems with the most restrictive settings possible for that specific 
filesystem, and that /tmp should be mounted with (essentially) nothing set (ie: 
nodev, nosuid, noexec).



Am I incorrect or has something changed in this regard?



It seems to me that, as a general rule, making /tmp noexec is a good thing from 
a security standpoint; but I admit that I don’t know enough about this to be 
sure.



Anyway, I just added a line to rc.local to remount temp as noexec at the end of 
the boot so that rc would work without errors and that /tmp is noexec once the 
system is up.



Is that bad?



Thanks



---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Jiri B]

On Mon, Sep 25, 2017 at 07:31:15PM -0700, Philip Guenther wrote:
> If you're mounting /tmp with the noexec flag, then stop doing that.

What? IIUC this is long existing recommendation. If /etc/rc needs
exec /tmp that it should change it by itself for libs reordering and
then switch back to what an user has defined in /etc/fstab.

j.

Re: reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Philip Guenther]

On Mon, 25 Sep 2017, Theodore Wynnychenko wrote:
> I noticed this message in the dmesg after updating -current yesterday.
> 
> I am not sure what it means.
>
> There is no file "test-ld.so" anywhere on the system that I can find.  
> I also see that it appears this part of rc was just committed in the 
> last few weeks.
> 
> Why is this happening, and is there anything that I should do to correct 
> the "Permission denied" error?

It means that after /etc/rc had built a new ld.so, when it tried to test 
it by running the test-ld.so program (which is packaged inside 
/usr/libdata/ld.so.a), it failed with that error, EACCES.

My guess is that you're hitting this:

 [EACCES]   The new process file is on a filesystem mounted with
execution disabled (MNT_NOEXEC in ).

If you're mounting /tmp with the noexec flag, then stop doing that.


Philip Guenther

reordering libraries:/etc/rc[443]: ./test-ld.so: Permission denied

[Theodore Wynnychenko]

Hello

I noticed this message in the dmesg after updating -current yesterday.

I am not sure what it means.

There is no file "test-ld.so" anywhere on the system that I can find.  I also
see that it appears this part of rc was just committed in the last few weeks.

Why is this happening, and is there anything that I should do to correct the
"Permission denied" error?


Thank you.
Ted



---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: touchpad input driver: test results

[Martin Pieuchot]

Thanks for your work Ulf.

By the way I brought a new laptop, X1 Carbon gen2 for you from Toronto.

It's a gift from deraadt@.  It has a soft-button synaptics and a USB
touchscreen.

Cheers,
Martin


On 20/08/17(Sun) 22:17, Ulf Brosziewski wrote:
> As people might want to know what they have worked for, it's probably
> time for a summary of the first test results and my conclusions.
> (But please don't get that wrong: more tests and reports are and will be
> welcome.)
> 
> Hardware:  Most tests were made with (PS/2) Synaptics touchpads, and it
> seems there are no problems with common models of "OpenBSD laptops".
> Few quirks and bugs have been reported for older and less common ones,
> and concern things that should be handled by the hardware driver.  Alps
> and Elantech models are rare, and it looks like most Mac users are on
> holiday.
> 
> Driver mechanisms:  No serious problem has come up.  It has been
> observed that there are (too) long delays between the start of a scroll
> gesture and the first scroll event.  I'm already testing an improved
> version of the handler.  There will still be a short delay, because
> it reduces the risk that you produce scroll events unintentionally.
> 
> Features:  Not surprisingly, some people are missing certain features.
> What has been mentioned is 1) "disable-while-typing", 2) edge areas
> (where initial contacts don't move the pointer or generate tap events),
> 3) multi-finger clicks, and 4) "coasting" (that is, scrolling continues
> for some time after the scrolling fingers have been lifted).  Up to now
> my impression is that 1) and/or 2) could be prominent, maybe 3).
> However, there are no decisions about additional features yet, each one
> would need some care.
> 
> 1) and 2) are different approaches to the same task: suppressing outputs
> of accidental contacts, usually palm or thumb contacts, so in this
> context one might also think of: 5) palm and thumb detection based on
> contact width, pressure, and other attributes, perhaps.  1) is based on
> a simple principle, but it needs coordination with another driver, and I
> am not sure whether it is a good solution, or despair.  What's a
> reasonable timeout here?  If it's too short, it only mitigates the
> problem, if it's too long, it can be a nuisance.  5) might work well for
> some users, with some touchpads, but it may be difficult to find useful
> generalizations.  I'm currently checking variants of 2), the basic
> mechanism is already present in the driver (it's required for software
> buttons and edge scroll areas).  But again, it's too early for
> conclusions, and surely we want to avoid a patchwork of half-general and
> half-successful solutions.
> 
> Default configuration:  The defaults, including the "hidden" ones, seem
> to be acceptable for many models.  I will increase the default scroll
> speed (moderately).  In some cases, the height of the button area on
> clickpads is problematic.  This is not as trivial as it may seem.
> Coordinate limits are not always correct, and resolution values can be
> unreliable - if they are present at all.  There is actually a good deal
> of guess work in the configuration.  Improving that will need more work
> on the hardware drivers.
> 
> As I have written, not all touchpad drivers cooperate with the input
> driver up to now.  I hope this will change soon.  It's not ready yet,
> but some work on imt/hidmt has already been done, with help of Remi.
> 
> Thanks again for the friendly, competent, and helpful feedback!
> 
> 
> On 07/31/2017 11:02 PM, Ulf Brosziewski wrote:
> > In the long run the synaptics driver, which handles touchpad inputs in
> > X, may be a dead end of the input framework, and it's time to prepare
> > an alternative.  The kernel contains an internal touchpad input driver
> > now, it's a part of wsmouse(4).  It provides standard features -
> > two-finger/edge scrolling, software buttons for clickpads, tapping -
> > and various kinds of plankton required for usability.
> > 
> > If you have a new snapshot (from July 27 or later) on a laptop with a
> > Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with
> > tests [...]
> 

Re: touchpad input driver: test results

[Ulf Brosziewski]

As people might want to know what they have worked for, it's probably
time for a summary of the first test results and my conclusions.
(But please don't get that wrong: more tests and reports are and will be
welcome.)

Hardware:  Most tests were made with (PS/2) Synaptics touchpads, and it
seems there are no problems with common models of "OpenBSD laptops".
Few quirks and bugs have been reported for older and less common ones,
and concern things that should be handled by the hardware driver.  Alps
and Elantech models are rare, and it looks like most Mac users are on
holiday.

Driver mechanisms:  No serious problem has come up.  It has been
observed that there are (too) long delays between the start of a scroll
gesture and the first scroll event.  I'm already testing an improved
version of the handler.  There will still be a short delay, because
it reduces the risk that you produce scroll events unintentionally.

Features:  Not surprisingly, some people are missing certain features.
What has been mentioned is 1) "disable-while-typing", 2) edge areas
(where initial contacts don't move the pointer or generate tap events),
3) multi-finger clicks, and 4) "coasting" (that is, scrolling continues
for some time after the scrolling fingers have been lifted).  Up to now
my impression is that 1) and/or 2) could be prominent, maybe 3).
However, there are no decisions about additional features yet, each one
would need some care.

1) and 2) are different approaches to the same task: suppressing outputs
of accidental contacts, usually palm or thumb contacts, so in this
context one might also think of: 5) palm and thumb detection based on
contact width, pressure, and other attributes, perhaps.  1) is based on
a simple principle, but it needs coordination with another driver, and I
am not sure whether it is a good solution, or despair.  What's a
reasonable timeout here?  If it's too short, it only mitigates the
problem, if it's too long, it can be a nuisance.  5) might work well for
some users, with some touchpads, but it may be difficult to find useful
generalizations.  I'm currently checking variants of 2), the basic
mechanism is already present in the driver (it's required for software
buttons and edge scroll areas).  But again, it's too early for
conclusions, and surely we want to avoid a patchwork of half-general and
half-successful solutions.

Default configuration:  The defaults, including the "hidden" ones, seem
to be acceptable for many models.  I will increase the default scroll
speed (moderately).  In some cases, the height of the button area on
clickpads is problematic.  This is not as trivial as it may seem.
Coordinate limits are not always correct, and resolution values can be
unreliable - if they are present at all.  There is actually a good deal
of guess work in the configuration.  Improving that will need more work
on the hardware drivers.

As I have written, not all touchpad drivers cooperate with the input
driver up to now.  I hope this will change soon.  It's not ready yet,
but some work on imt/hidmt has already been done, with help of Remi.

Thanks again for the friendly, competent, and helpful feedback!


On 07/31/2017 11:02 PM, Ulf Brosziewski wrote:
> In the long run the synaptics driver, which handles touchpad inputs in
> X, may be a dead end of the input framework, and it's time to prepare
> an alternative.  The kernel contains an internal touchpad input driver
> now, it's a part of wsmouse(4).  It provides standard features -
> two-finger/edge scrolling, software buttons for clickpads, tapping -
> and various kinds of plankton required for usability.
> 
> If you have a new snapshot (from July 27 or later) on a laptop with a
> Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with
> tests [...]

unit test for openiked

[Agoston Toth]

Hello!
Could you please help me out if you have any unit or function test suites for 
openiked?I could not find it in CVS.

Regards, Agoston

Re: Any network simulators to test openbgpd?

[Solène Rapenne]

Le 2017-02-12 20:25, Karthik Veeragoni a écrit :

Hi all,

I'm looking for any freely available or commercial network simulators 
or

emulators
to test Openbgpd by using any of them.

And I would also like to know on what other poplar platforms/operating
systems, openbgpd is being used in the current market or can be used.

As per the following thread:
https://www.inex.ie/pipermail/ixpmanager/2015-April/000496.html , it is
said the implementing openbgpd on Freebsd is not so secure. What is the
current status of using openbgpd on Freebsd?

Any suggestions are welcome.


Thanks & Regards,
Karthik V


Hello,
you can join dn42 network https://dn42.net/Home

Any network simulators to test openbgpd?

[Karthik Veeragoni]

Hi all,

I'm looking for any freely available or commercial network simulators or
emulators
to test Openbgpd by using any of them.

And I would also like to know on what other poplar platforms/operating
systems, openbgpd is being used in the current market or can be used.

As per the following thread:
https://www.inex.ie/pipermail/ixpmanager/2015-April/000496.html , it is
said the implementing openbgpd on Freebsd is not so secure. What is the
current status of using openbgpd on Freebsd?

Any suggestions are welcome.


Thanks & Regards,
Karthik V

How to test BGP fail Over

[Nagarjun G]

Hi All,

We have openbgpd running having peered with 2 ISP's.
I am trying to test the failover with one of the ISP.
To test this, I changed bgpd.conf file to comment the entry for one of the
ISP and reloaded conf file and behaves as expected.
I think I can also use bgpctl command to bring down one of the ISP's and
test.
But what is the best way to test like when a real outage happens.
Do I need to contact the ISP to make the peer down ?


Regards,
Nagarjun

Fw: RE: RE: OpenBSD PaX Test question

[Peter Janos]

if anyone interested, correction for the pax topic Sent: Tuesday, October
11, 2016 at 3:57 PM
From: "W. Dean Freeman" <wdfree...@acumensecurity.net>
To: "'Peter Janos'" <peterjan...@mail.com>
Subject: RE: RE: OpenBSD PaX Test questionIncreasing the stack gap size
isn't necessarily bad or good. Basically,
you're adjusting the run-time value of a gap page that gets inserted at
the
top of a new stack frame, so that when an attacker is analyzing a binary
and
attempting to write an exploit, there is an unknown-at-compile-time
number of
bytes which have to be included when building the exploit and attempting
to
over-write the return address to the previous stack frame. It's just one
of a
series of mitigations against buffer overflows (like stack canaries, W^X,
etc.
You're also here adjusting the amount of room there is to play with when
randomzing addresses for ASLR, at least as is my understanding.

So, I doubt it hurts anything, but given the general strength of ASLR,
stack
gaps, stack cookies, the new W^X feature, etc. I'm not sure it's really
necessary. If you really want to play with something fun that may ferret
out
bugs either in your code or in things you get from ports, turn on memory
junking in the /etc/malloc.conf. For a discussion on some fun around
that,
see here:

https://www.youtube.com/watch?v=YYf1U0xcHmk

To the second question, there isn't any magic to what I'm doing in that
program and between screenshots from GDB and a description of what's
going on,
you should be able to reconstruct it. There are three basic tests:
1. Attempt to mmap(2) a page of memory with permissions
PROT_WRITE|PROT_EXEC
** on OpenBSD, this will cause the program to abort. On HardenedBSD or
NetBSD, you'll get a writable page of memory back
** If you get the page back, I put a bit of do-nothing shell code into
the
mapped buffer, then write a function pointer to it and attempt to execute
in
order to cause a page fault there and record the violation is caught
properly,
proving that I didn't get W|X memory
2. attempt to map a page of memory as writable then mprotect() to W|X.
With
PaX, the page stays writable. OpenBSD will abort the processes here
** I did share a version with Red Hat through technical community
channels,
which included proof via live shell code that even if you turn off
execmem
allocation in SELinux, that you get no protection around mprotect and can
still get a shell here.
3. Attempt to map a page of memory as executable and then mprotect() to
W|X.
Again, OpenBSD will abort this but PaX just gives you back what you had
originally

I may be able to share the tool, but it basically just does a subset of
what
is in the paxtest, geared directly at three sub-cases for one security
functional requirement which isn't even mandatory right now. However,
RedHat
didn't want to burn political capital with the Linux kernel devs pushing
for
it when OpenBSD didn't even turn it on. Now that they have, there may be
a
better case to be made in that regard.

-
W. Dean Freeman, CISSP, CSSLP, GCIH
Lead Security Engineer
Mobile: +1.8048158786
wdfree...@acumensecurity.net
http://www.acumensecurity.net

-Original Message-
From: Peter Janos [mailto:peterjan...@mail.com]
Sent: Tuesday, October 11, 2016 2:23 AM
To: W. Dean Freeman <wdfree...@acumensecurity.net>
Subject: Re: RE: OpenBSD PaX Test question

Only two question:

==

1) Increasing kern.stackgap_random=262144 to
kern.stackgap_random=16777216
increases the "14 quality bits" to "20 quality bits".

Stack randomization test (SEGMEXEC) : 20 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 20 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 20 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 20 quality bits (guessed

is this a wise thing to do? Does setting the kern.stackgap_random to
16777216
increases security?

==

2) Can we have the cc-memtest binary or source? Or it is not public.
http://blog.acumensecurity.net/revisiting-wx-with-openbsd-6-0/

==

Many Thanks!

> Sent: Monday, October 10, 2016 at 5:46 PM
> From: "W. Dean Freeman" <wdfree...@acumensecurity.net>
> To: "'Peter Janos'" <peterjan...@mail.com>
> Subject: RE: OpenBSD PaX Test question
>
> Sure, go ahead.
>
>
>
>
>
>
>
> From: Peter Janos [mailto:peterjan...@mail.com]
> Sent: Monday, October 10, 2016 11:46 AM
> To: W. Dean Freeman <wdfree...@acumensecurity.net>
> Subject: Re: OpenBSD PaX Test question
>
>
>
> can I post this as an anser on stackexchange?
>
> Thank you!
>
> Sent: Monday, October 10, 2016 at 4:36 PM
> From: "W. Dean Freeman" <wdfree...@acumensecurity.net
> <mailto:wdfree...@acumensecurity.net> >
> To: peterjan...@mail.com <mailto:peterj

Re: VMM test

[Mike Larkin]

On Wed, Oct 12, 2016 at 05:17:19PM +0200, Lampshade wrote:
> >> Hi Everybody,
> >>
> >> I would like to give a try to vmm. If I do so, which os can I expect
> >> to make it work? openbsd ok I guess. Linux? Windows?
> 
> >OpenBSD only, as of now.
> 
> Does it support both i386 and amd64 OpenBSDs guests?
> 

yes

Re: VMM test

[Lampshade]

>> Hi Everybody,
>>
>> I would like to give a try to vmm. If I do so, which os can I expect
>> to make it work? openbsd ok I guess. Linux? Windows?

>OpenBSD only, as of now.

Does it support both i386 and amd64 OpenBSDs guests?

Re: VMM test

[David Coppa]

On Wed, Oct 12, 2016 at 1:06 PM, Sébastien Morand 
wrote:
> Hi Everybody,
>
> I would like to give a try to vmm. If I do so, which os can I expect
> to make it work? openbsd ok I guess. Linux? Windows?

OpenBSD only, as of now.

VMM test

[Sébastien Morand]

Hi Everybody,

I would like to give a try to vmm. If I do so, which os can I expect
to make it work? openbsd ok I guess. Linux? Windows?

Thanks by advance,
Sebastien

Re: iked config test hanging on 6.0

[binder.christ...@gmx.de]

2 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, 
version 1.0, legacy support

ehci2 at pci0 dev 22 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb2 at ehci2: USB revision 2.0
uhub2 at usb2 "ATI EHCI root hub" rev 2.00/1.00 addr 1
pchb1 at pci0 dev 24 function 0 "AMD AMD64 14h Link Cfg" rev 0x43
pchb2 at pci0 dev 24 function 1 "AMD AMD64 14h Address Map" rev 0x00
pchb3 at pci0 dev 24 function 2 "AMD AMD64 14h DRAM Cfg" rev 0x00
km0 at pci0 dev 24 function 3 "AMD AMD64 14h Misc Cfg" rev 0x00
pchb4 at pci0 dev 24 function 4 "AMD AMD64 14h CPU Power" rev 0x00
pchb5 at pci0 dev 24 function 5 "AMD AMD64 14h Reserved" rev 0x00
pchb6 at pci0 dev 24 function 6 "AMD AMD64 14h NB Power" rev 0x00
pchb7 at pci0 dev 24 function 7 "AMD AMD64 14h Reserved" rev 0x00
usb3 at ohci0: USB revision 1.0
uhub3 at usb3 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb4 at ohci1: USB revision 1.0
uhub4 at usb4 "ATI OHCI root hub" rev 1.00/1.00 addr 1
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
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x52
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb5 at ohci2: USB revision 1.0
uhub5 at usb5 "ATI OHCI root hub" rev 1.00/1.00 addr 1
usb6 at ohci3: USB revision 1.0
uhub6 at usb6 "ATI OHCI root hub" rev 1.00/1.00 addr 1
umass0 at uhub2 port 1 configuration 1 interface 0 "Generic Flash Card 
Reader/Writer" rev 2.01/1.00 addr 2

umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: <Multiple, Card Reader, 1.00> SCSI2 
0/direct removable serial.058f6366058F63666485

vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (46428bab0feda7f9.a) swap on sd0b dump on sd0b
pppoe0: received unexpected PADO
#


Am 02.09.2016 um 01:52 schrieb Matt Behrens:

I've tried this on a few different systems now, one upgraded from 5.9 to 6.0
with the install CD, one a brand-new 6.0 install. The former is running as a
hosted VM at Vultr, the latter a VMware Fusion machine.

I'm not sure if this is a problem just in a virtual machine context, but I
don't have any physical hardware available to check it on at the moment. As
such, I'm not confident I have a bug, and would appreciate comments from the
community on whether they experience the same problem.

The iked config test in /etc/rc.d/iked hangs fairly reliably. I've ktraced it
and it looks like this when hanging, stopping at the wait4:

  91211 iked CALL  write(2,0x7b37a13ec73,0x11)
  91211 iked GIO   fd 2 wrote 17 bytes
"configuration OK
"
  91211 iked RET   write 17/0x11
  91211 iked CALL  kbind(0x7f7ce4f8,24,0x2e9d25833eef97c0)
  91211 iked RET   kbind 0
  91211 iked CALL  kill(-91211,SIGTERM)
  91211 iked RET   kill -1 errno 3 No such process
  91211 iked CALL  kill(-84806,SIGTERM)
  91211 iked RET   kill -1 errno 3 No such process
  91211 iked CALL  kill(-90967,SIGTERM)
  91211 iked RET   kill -1 errno 3 No such process
  91211 iked CALL  kill(-50484,SIGTERM)
  91211 iked RET   kill -1 errno 3 No such process
  91211 iked CALL  kbind(0x7f7ce4f8,24,0x2e9d25833eef97c0)
  91211 iked RET   kbind 0
  91211 iked CALL  wait4(WAIT_ANY,0,0<>,0)

The kill pids are all valid pids (one is the process itself), and earlier in
the ktrace output they were fork results:

  91211 iked CALL  fork()
  91211 iked RET   fork 90967/0x16357
  91211 iked CALL  fork()
  91211 iked RET   fork 84806/0x14b46
  91211 iked CALL  fork()
  91211 iked RET   fork 50484/0xc534

On the Vultr VM, if I run with -d (e.g. rcctl -df start iked), it starts fine.
It seems like this is because iked -n is allowed to output "configuration OK"
to the console. This doesn't work on the VMware Fusion machine.

I can run iked -n just fine without any problem, though on the Vultr machine
sometimes it prints exits for the privsep processes, and not predictably:

# iked -n
configuration OK
ca exiting, pid 8933
# iked -n
configuration OK
ca exiting, pid 46440
# iked -n
configuration OK
ca exiting, pid 99924
# iked -n
configuration OK
ca exiting, pid 57315
ikev2 exiting, pid 38805

On the VMware machine, it always just prints "configuration OK".

Commenting out the config test in /etc/rc.d/iked appears to be a viable
workaround.

To reproduce this on the brand-new VMware machine, I created a basic "road
warrior" config similar to the one I run on the Vultr machine:

# ikectl ca CA create

ikectl.conf:

user username passive

ikev2 'configuration' passive esp \
from 0.0.0.0/0 to 10.0.0.0/24 local any peer any \
src vpn.local \
eap "mschap-v2" \
config address 10.0.0.1 \
config name-server 8.8.8.8

iked config test hanging on 6.0

[Matt Behrens]

I've tried this on a few different systems now, one upgraded from 5.9 to 6.0
with the install CD, one a brand-new 6.0 install. The former is running as a
hosted VM at Vultr, the latter a VMware Fusion machine.

I'm not sure if this is a problem just in a virtual machine context, but I
don't have any physical hardware available to check it on at the moment. As
such, I'm not confident I have a bug, and would appreciate comments from the
community on whether they experience the same problem.

The iked config test in /etc/rc.d/iked hangs fairly reliably. I've ktraced it
and it looks like this when hanging, stopping at the wait4:

 91211 iked CALL  write(2,0x7b37a13ec73,0x11)
 91211 iked GIO   fd 2 wrote 17 bytes
   "configuration OK
   "
 91211 iked RET   write 17/0x11
 91211 iked CALL  kbind(0x7f7ce4f8,24,0x2e9d25833eef97c0)
 91211 iked RET   kbind 0
 91211 iked CALL  kill(-91211,SIGTERM)
 91211 iked RET   kill -1 errno 3 No such process
 91211 iked CALL  kill(-84806,SIGTERM)
 91211 iked RET   kill -1 errno 3 No such process
 91211 iked CALL  kill(-90967,SIGTERM)
 91211 iked RET   kill -1 errno 3 No such process
 91211 iked CALL  kill(-50484,SIGTERM)
 91211 iked RET   kill -1 errno 3 No such process
 91211 iked CALL  kbind(0x7f7ce4f8,24,0x2e9d25833eef97c0)
 91211 iked RET   kbind 0
 91211 iked CALL  wait4(WAIT_ANY,0,0<>,0)

The kill pids are all valid pids (one is the process itself), and earlier in
the ktrace output they were fork results:

 91211 iked CALL  fork()
 91211 iked RET   fork 90967/0x16357
 91211 iked CALL  fork()
 91211 iked RET   fork 84806/0x14b46
 91211 iked CALL  fork()
 91211 iked RET   fork 50484/0xc534

On the Vultr VM, if I run with -d (e.g. rcctl -df start iked), it starts fine.
It seems like this is because iked -n is allowed to output "configuration OK"
to the console. This doesn't work on the VMware Fusion machine.

I can run iked -n just fine without any problem, though on the Vultr machine
sometimes it prints exits for the privsep processes, and not predictably:

# iked -n
configuration OK
ca exiting, pid 8933
# iked -n
configuration OK
ca exiting, pid 46440
# iked -n
configuration OK
ca exiting, pid 99924
# iked -n
configuration OK
ca exiting, pid 57315
ikev2 exiting, pid 38805

On the VMware machine, it always just prints "configuration OK".

Commenting out the config test in /etc/rc.d/iked appears to be a viable
workaround.

To reproduce this on the brand-new VMware machine, I created a basic "road
warrior" config similar to the one I run on the Vultr machine:

# ikectl ca CA create

ikectl.conf:

user username passive

ikev2 'configuration' passive esp \
from 0.0.0.0/0 to 10.0.0.0/24 local any peer any \
src vpn.local \
eap "mschap-v2" \
config address 10.0.0.1 \
config name-server 8.8.8.8

Re: Test

[Francois Pussault]

OK

> 
> From: Jiří Navrátil <j...@navratil.cz>
> Sent: Fri Jul 29 16:23:17 CEST 2016
> To: Edgar Pettijohn <ed...@pettijohn-web.com>
> Subject: Re: Test
>
>
> received
>
> ---
> Jiří Navrátil
>
> 29. 7. 2016 v 16:09, Edgar Pettijohn <ed...@pettijohn-web.com>:
>
> > I think the mailing list server is blocking me. This is just a test to
> confirm
> > this theory. Sorry for the noise.
> >
> > Edgar
> >
> > Sent from my iPhone
>


Cordialement
Francois Pussault
10 chemin de négo saoumos
apt 202 - bat 2
31300 Toulouse
+33 6 17 230 820
fpussa...@contactoffice.fr

Re: Test

[Jiří Navrátil]

received

---
Jiří Navrátil

29. 7. 2016 v 16:09, Edgar Pettijohn <ed...@pettijohn-web.com>:

> I think the mailing list server is blocking me. This is just a test to
confirm
> this theory. Sorry for the noise.
>
> Edgar
>
> Sent from my iPhone

Test

[Edgar Pettijohn]

I think the mailing list server is blocking me. This is just a test to confirm
this theory. Sorry for the noise.

Edgar

Sent from my iPhone

libstdc++ (bug?) / libc++ (cant test)

[sven falempin]

Dear openbsd users,

Today i had to patch a cpp program like this

-  (*_obj).insert(p);
+
+  size_t s = _obj->erase( key );
+  //fprintf(stderr, "wtf %d\n", s); //ANNO 2016 LIBC++ NEW WAY...
+
+  _obj->insert(p);

_obj is define like this
class Foo { std::shared_ptr<  std::map< std::vector , Foo> > }


new C++14 is integrating an upsert or whatever, i did not read the last
patches on
gnu libstdc++

This occurs this the last patch of g++.

I wanted to try clang/llvm but figure, well if i want that on openbsd
i ll have to not sleep next week end.

Unless i miss something.

I share this , in case you encounter some crazy bug on a cpp program..

and it s another cent, in the lets get rid of gnu jar.

Cheers.

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: How to test radius server

[Stuart Henderson]

On 2015-11-25, freeu...@ruggedinbox.com  wrote:
> I read the /etc/npppd/npppd.conf
> It's ok. except radius:)

Can you explain what you're trying to do?

> client 192.168.0.0:/24 {
> secret "secret"
> msgauth-required yes
> }
> module set radius "secret" "testing123"

"module set radius" is for proxying to another RADIUS server.

If you want to authenticate users locally (system passwords) you can
use the "bsdauth" module.

> where is in username...

The username (and password) are sent by the PPP client. npppd takes
them and sends to the RADIUS server requesting authentication.

How to test radius server

[freeunix]

I read the /etc/npppd/npppd.conf
It's ok. except radius:)

"man npppd.conf" say:
authentication RADIUS type radius {
username-suffix "@example.com"

authentication-server {
address 192.168.0.1 secret "hogehoge"
}

}

then, I couldn't find /etc/radiusd.conf
I check the "man -k radius".
"man radiusd.conf" say:

client 192.168.0.0:/24 {
secret "secret"
msgauth-required yes
}
module set radius "secret" "testing123"


Wow, I must chenge the npppd.conf and radiusd.conf.

1.
npppd.conf:
authentication-server {
address 192.168.0.1 secret "hogehoge"
}

radiusd.conf:
client 192.168.0.0:/24 {
secret "secret"
msgauth-required yes
}
module set radius "secret" "hogehoge"


2.
npppd.conf:
authentication-server {
address 192.168.0.1 secret "hogehoge"
}

radiusd.conf:
client 192.168.0.0:/24 {
secret "secret"
msgauth-required yes
}
module set radius "hogehoge" "testing123"

where is in username...
It didn't to see... easy to understanding by "man npppd.conf" "man 
radiusd.conf".

these exanmple aren't reciprocal.

good manual is "to see one time, can do it!"

Re: Question - test lab

[Miod Vallat]

> General hints for picking up an alpha:
[...]
> If you intend to be in the same room as the machine, pick a workstation
> model and not a server.

DS25 are supposed to be deskside workstations, but their noise level
fits in the `server' category.

Re: Question - test lab

[Christian Weisgerber]

On 2015-09-09, "Bryan C. Everly" <br...@bceassociates.com> wrote:

> I'm trying to put together a multiple CPU architecture test lab for
> work I'm doing on some ports and I have the following:
>
> * Thinkpad T21 (i386)
> * Powerbook G4 (32-bit PPC)
> * Sun Blade 100 (sparc64)
> * Thinkpad x220 (amd64)
>
> I'm wondering if anyone could recommend a low-cost Alpha or PA-RISC
> machine for me to add to this?

General hints for picking up an alpha:

Make sure the machine has an SRM console, i.e., boots to a ">>>"
prompt.  Some models only support AlphaBIOS or ARC(BIOS) and these
don't run BSD.

CPU generations:
21064: Skip.  They are far too slow.
21164: If you're happy with the speed of the Blade 100, then these
   are in the same ballpark.
21264: Nowadays there's probably no point in bothering with anything
   less.

If you intend to be in the same room as the machine, pick a workstation
model and not a server.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Question - test lab

[Bryan C. Everly]

Hi

I'm trying to put together a multiple CPU architecture test lab for
work I'm doing on some ports and I have the following:

* Thinkpad T21 (i386)
* Powerbook G4 (32-bit PPC)
* Sun Blade 100 (sparc64)
* Thinkpad x220 (amd64)

I'm wondering if anyone could recommend a low-cost Alpha or PA-RISC
machine for me to add to this?  I'm planning on an EdgeRouter for the
MIPS 64-bit CPU.

Thanks,
Bryan

Re: Are nc -lu /dev/zero /dev/null a good throughput test?

[Raimundo Santos]

On 21 July 2014 18:17, Giancarlo Razzolini grazzol...@gmail.com wrote:

 I've noticed
 similar performance and, in some cases, better than vio(4) when using
 the host's pci passthrough and assigning a real hardware to the VM. But

Hello Giancarlo,

thank you for your time.

I am at a very bleeding edge (or awkward) project of putting almost all
machines of a little WISP into a virtualized system.

My concern mainly touches packets and bits flows, storage is not one.
XenServer has very nice facilities, but is a pain to tailor it in network
area (well, almost in all areas: lots of long commands which are hard to
remember, tricks that could vanish with updates, ...). The amount of work
to tune it is equal or more than to use libvirt, so I am dropping it.

Ubuntu Server 14.04 came out with qemu-kvm 2.0.0, with newer host VirtIO
implementations in many areas. I am on my way to test it. I dislike Ubuntu
as a Server, but I am not in that project to take much pain to manage the
hosts, compile that sadly GNU-crafted things and so on, therefore if Ubuntu
give me good performance, I will take it.

Can you tell me where are you using qemu-kvm 2.0.0 and how you manage it
(upgrades, etc.)?

 you shouldn't expected very great performance between VM's hosted in the
 same host, unless you're using linux's macvtap with a switch that
 supports VEPA. Using bridge is slow. I suggest you create a virtual
 network and assign an interface for each of your VM's that need
 communicating, and also use vio(4) on the guest OS.

As you stated before, I expect a lot more performance from PCI passthrough,
and things like clients bandwidth enforcement will depend on it. I will try
as match as possible to let that main traffic outside host internal
networks.

Have you played with Open vSwitch as a bridging facility?

My client (the WISP) is very excited about turning off that old machines,
but, while I am enjoying the challenge, am I too with three foot behind the
line of excitement when the subject are reliability and scalability of the
solution. Nonetheless, it is an experimental.

And someone could think: why OpenBSD? Well, have you ever tried setting
RIPv2 in other OSes? The more general answer: it Just Works for almost all
things I need to setup. The only thing that I can not figure out how to do
is the WISP's clients contracted bandwidth enforcement.

Cheers,
Raimundo Santos

Re: Are nc -lu /dev/zero /dev/null a good throughput test?

[Giancarlo Razzolini]

Em 22-07-2014 19:20, Raimundo Santos escreveu:
 XenServer has very nice facilities, but is a pain to tailor it in
 network area (well, almost in all areas: lots of long commands which
 are hard to remember, tricks that could vanish with updates, ...). The
 amount of work to tune it is equal or more than to use libvirt, so I
 am dropping it.
Libvirt has support for Xen. I just found it easier to use KVM because
it is not invasive to the guest os as Xen is. The virtio, virt mem
balloon and others just increase performance if the guest os has them.
But it does not impede it's use. Xen is very well suited for running
many machines of the same kind and with the same io/throughput needs. I
find KVM is more well suited for heterogeneous environments.
 Ubuntu Server 14.04 came out with qemu-kvm 2.0.0, with newer host
 VirtIO implementations in many areas. I am on my way to test it. I
 dislike Ubuntu as a Server, but I am not in that project to take much
 pain to manage the hosts, compile that sadly GNU-crafted things and so
 on, therefore if Ubuntu give me good performance, I will take it.
I use ubuntu as server for many years now. Of course you can get bit in
the hand every now and then (specially when upgrading from release to
release), but if you use some kind of version control for your
configuration files, the impact is minimal. It has almost the perfect
balance between stability and bleeding edge.
 Can you tell me where are you using qemu-kvm 2.0.0 and how you manage
 it (upgrades, etc.)?
Yes, I'm using 2.0.0. I manage it using the virt-manager. Since I don't
use more advanced features such as host migration, failover, etc, I find
it the perfect tool. Every now and then I need to edit the qemu xml
machine files by hand, but it's well documented. I upgrade the host
system as often as I can (I don't trust unattended upgrades, even well
configured). And for the guests, in the case of OpenBSD, I use the mtier
stable packages and kernel updates.
 Have you played with Open vSwitch as a bridging facility?
I didn't had the chance yet.
 And someone could think: why OpenBSD? Well, have you ever tried
 setting RIPv2 in other OSes?
Yes. I've played with it on other OSes. On linux quagga does the job
reasonably. But please, try OSPF, if possible, on your network. RIP
should really R.I.P.
 The more general answer: it Just Works for almost all things I need to
 setup. The only thing that I can not figure out how to do is the
 WISP's clients contracted bandwidth enforcement.
Well, pf has a very good bandwidth scheduler and some changes on 5.5
improved and simplified the system a lot. And you can use pflow(4) with
nfsen to provide some kind accounting, if you don't want to implement a
radius system.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Are nc -lu /dev/zero /dev/null a good throughput test?

[Giancarlo Razzolini]

Em 20-07-2014 19:44, Adam Thompson escreveu:
 FWIW, you're almost certainly going to be CPU-bound.  I can't get more
 than ~200Mbps on an emulated em(4) interface under ProxmoxVE (KVM
 1.7.1) between two VMs running on the same host.  Granted, the CPUs
 are slowish (2.2GHz Xeon L5520).  I get better throughput using vio(4)
 but then I have to reboot the VMs once every 2 or 3 days to prevent
 them from locking up hard.
Adam,

I've been using vio(4) for quite some time now, with long uptimes in
my vm machines, and never experienced lock ups. I've been using since
5.4. Now I'm running qemu-kvm 2.0.0. Now, to the OP question, I've been
using a mix of tcpbench and iperf and also been using statistical data
from libvirt, to measure the performance of my VM's. I've noticed
similar performance and, in some cases, better than vio(4) when using
the host's pci passthrough and assigning a real hardware to the VM. But
you shouldn't expected very great performance between VM's hosted in the
same host, unless you're using linux's macvtap with a switch that
supports VEPA. Using bridge is slow. I suggest you create a virtual
network and assign an interface for each of your VM's that need
communicating, and also use vio(4) on the guest OS.

Cheers,

--
Giancarlo Razzolini
GPG: 4096R/77B981BC

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Are nc -lu /dev/zero /dev/null a good throughput test?

[Raimundo Santos]

On 19 July 2014 21:22, Sean Kamath kam...@moltingpenguin.com wrote:

 Are you counting all those zeros to make sure they all came through?

 'cause TCP is guaranteed delivery, in order.  UDP guarantees nothing.

Hello Sean!

Why counting?

My guess, and therefore the start of my reasoning and later questioning
here, is that all those zeroes inside and UDP could flood the virtual
network structure.

May be you are confusing nc(1) with wc(1).

Re: Are nc -lu /dev/zero /dev/null a good throughput test?

[Raimundo Santos]

On 19 July 2014 21:28, Philip Guenther guent...@gmail.com wrote:

  tcpbench(1) - TCP/UDP benchmarking and measurement tool

Oh, just beneath my eyes, in the base install. Thank you, Philip.

May I loose time comparing tcpbench(1) with iperf?

Re: Are nc -lu /dev/zero /dev/null a good throughput test?

[Adam Thompson]

On 14-07-20 04:57 PM, Raimundo Santos wrote:

On 19 July 2014 21:22, Sean Kamath kam...@moltingpenguin.com wrote:

Are you counting all those zeros to make sure they all came through?

'cause TCP is guaranteed delivery, in order.  UDP guarantees nothing.

Hello Sean!

Why counting?

My guess, and therefore the start of my reasoning and later questioning
here, is that all those zeroes inside and UDP could flood the virtual
network structure.

May be you are confusing nc(1) with wc(1).


No, what he meant was that using nc -u can produce false results.
The sender can send as many packets as its CPU can possibly send, even 
if 99.9% of those packets are getting dropped by the receiver; the 
sender still thinks it successfully send a bazillion bytes per second 
even though it's a meaningless number.

t
I didn't know tcpbench(1) was in base, either... I always install and 
use iperf.
I would expect both tcpbench and iperf to return very similar results.  
(Note that the results probably won't be perfectly identical, that's 
normal.)


Using the -u flag to tcpbench(1) over a ~20Mbps radio link, the client 
reports throghput of 181Mbps, which is impossible.  The server reports, 
simultaneously, 26Mbps.  Both of these cannot be simultaneously true, 
right?  Except they can - the client really is sending 181Mbps of 
traffic, the server really is receiving 26Mbps of traffic.  What 
happened to the other 155Mbps of traffic?  Dropped on the floor, 
probably by the radio.
That's why you should run TCP benchmarks, or else be very careful with 
UDP benchmarks...  Remember, too, that any out-of-order packets will 
kill real-world performance, and UDP has no guarantees about those, either.


FWIW, you're almost certainly going to be CPU-bound.  I can't get more 
than ~200Mbps on an emulated em(4) interface under ProxmoxVE (KVM 1.7.1) 
between two VMs running on the same host.  Granted, the CPUs are slowish 
(2.2GHz Xeon L5520).  I get better throughput using vio(4) but then I 
have to reboot the VMs once every 2 or 3 days to prevent them from 
locking up hard.


Previous testing with VMware produced similar results circa OpenBSD 
v5.0.  Some other guests were able to get ~2Gbps on the same VM stack, 
at the time.
It is - almost by definition - impossible to flood the virtual network 
infrastructure without running out of CPU cycles in the guests first.  
It might be possible if the vSwitch is single-threaded, and you're 
running on a many-core CPU with each VM pegging its core(s) doing 
network I/O... but even then, remember that the vSwitch doesn't have to 
do any layer-3 processing, so it has much less work to do than the guest 
network stack.


Where you do have to worry about running out of bandwidth is the switch 
handling traffic between your hypervisors, or more realistically, the 
network interface(s) leading from your host to said switch.
Load-balancing (VMware ESXi  v5.1) and LAGs (everywhere/everything 
else) are your friends here, unless you have the budget to install 
10Gbps switches...


--
-Adam Thompson
 athom...@athompso.net