No output on com3 post-install

[Laura Smith]

I cannot understand why I am getting no output on com3 post-install of 7.5.

I connect to the USB-serial port, and I can see 7.5 boot of USB, and I can go 
through the install. No problem.

During install, I say "yes" to, do you want to default to com3.

But after the reboot, I see no output after "switching to com3".

Looking at the dmesg, com3 is definitley the right one:
# dmesg | fgrep com
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
com3 at acpi0 FUR0 addr 0xfedc9000/0x1000 irq 3: ns16550, no working fifo
com3: console

And, if I check, the installer has definitley made the required chanages:
# cat /mnt/etc/boot.conf   
stty com3 115200
set tty com3

If I delete those lines from boot.conf (i.e. echo ''> /mnt/etc/boot.conf ), I 
can see the boot messages scroll by, but of course I cannot get the keyboard 
prompt for login.

Where am I going wrong ?

Fix the wording on the 7.5 upgrade page

[Laura Smith]

Could someone kindly fix the wording on the 7.5 upgrade page.

It says "There were several configuration changes and changes in packages that 
may require planning before starting the upgrade."


But the notes say "nothing of note this release", "nothing to remove this 
release",


Thanks!

Re: dmesg hangs 7.4

[Laura Smith]

On Sunday, 10 March 2024 at 11:09, Tobias Fiebig 
 wrote:

> 
> Would still give it a try, esp. given that a large text file cat also
> shows this MTU-y behavior. ;-)
> 
> Still, I acknowledge that I do have a very MTU-hammer-view of network
> things a lot.
> 
> In any case, the issue sounds interesting, and I am curious what you
> will ultimately find.
> 
> 


I'm still working on various avenues of possibility, the network switch the BSD 
box is attached to is one of them, but unlikely becuase all other traffic 
transiting through the switch seems to be just fine.

Re: dmesg hangs 7.4

[Laura Smith]

Thanks for the suggestions Stuart, I'll work on more experimentation next week.



On Saturday, 9 March 2024 at 18:00, Stuart Henderson 
 wrote:

> Can you get dmesg out by another means (most likely, write to a usb stick)?
> 
> Any difference if you install a snapshot?
> 
> Anything special with the network setup?
> 
> Anything odd in dmesg on the box you're ssh'ing from?
> 
> On 2024-03-09, Laura Smith n5d9xq3ti233xiyif...@protonmail.ch wrote:
> 
> > Hi
> > 
> > I've got a fresh install of 7.4 on a new box and am seeing a very weird 
> > problem.
> > 
> > If I enter "dmesg" I get a few lines of output and then it hangs and my ssh 
> > connection gets dropped. I ran syspatch, rebooted and the problem persists.
> > 
> > Example:
> > 
> > # dmesg
> > MX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu19: 32KB 64b/line 8-way D-cache, 64KB 64b/line 8-way I-cache, 2MB 
> > 64b/line 16-way L2 cache, 30MB 64b/line 12-way L3 cache
> > cpu19: smt 0, core 35, package 0
> > cpu20 at mainbus0: apid 72 (application processor)
> > cpu20: 12th Gen Intel(R) Core(TM) i9-12900TE, 3392.18 MHz, 06-97-02, patch 
> > 0025
> > Timeout, server 10.1.2.3 not responding.
> 
> 
> 
> --
> Please keep replies on the mailing list.

Re: dmesg hangs 7.4

[Laura Smith]

Nice idea Tobias, but I forgot to mention both machines are on the same LAN, 
and the LAN is operating with standard MTU, no jumbos.




Sent with Proton Mail secure email.

On Saturday, 9 March 2024 at 17:02, Tobias Fiebig 
 wrote:

> Might be MTU? Can you try what happens with `find /` ?
> 
> If it freezes then, too:
> 
> On both machines:
> 
> ping -s 1252 -D $remote_IP
> 
> if it works, increase by half the way to 1472, try if it still works:
> 
> ping -s 1362 -D $remote_IP
> 
> etc.
> 
> If it does not work, you half the distance to the previously working
> one, e.g.:
> 
> ping -s 1362 -D $remote_IP << works
> 
> ping -s 1417 -D $remote_IP << does not work
> 
> then next:
> 
> ping -s 1390 -D $remote_IP
> 
> If you use IPv6, you need to decrease the starting/end value by 20 and
> use ping6, i.e., as min 1232 and as max 1452; If the hosts cannot reach
> each other directly (NAT), it depends on the path which addr to use;
> Would need traceroutes between the hosts then.
> 
> The assumption would be that you do have an MTU issue on-path there,
> which is not correctly signaled. This only hits as soon as the packets
> get a size larger than the MTU, e.g., when typing dmesg (or find /).
> 
> With best regards,
> Tobias
> 
> On Sat, 2024-03-09 at 16:07 +, Laura Smith wrote:
> 
> > Hi
> > 
> > I've got a fresh install of 7.4 on a new box and am seeing a very
> > weird problem.
> > 
> > If I enter "dmesg" I get a few lines of output and then it hangs and
> > my ssh connection gets dropped. I ran syspatch, rebooted and the
> > problem persists.
> > 
> > Example:
> > 
> > # dmesg
> > MX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-
> > CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2
> > ,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,R
> > DTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SM
> > EP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,
> > WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_A
> > LL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM
> > ,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,XSAVEOPT,XSAVEC,XGETBV1
> > ,XSAVES
> > cpu19: 32KB 64b/line 8-way D-cache, 64KB 64b/line 8-way I-cache, 2MB
> > 64b/line 16-way L2 cache, 30MB 64b/line 12-way L3 cache
> > cpu19: smt 0, core 35, package 0
> > cpu20 at mainbus0: apid 72 (application processor)
> > cpu20: 12th Gen Intel(R) Core(TM) i9-12900TE, 3392.18 MHz, 06-97-02,
> > patch 0025
> > Timeout, server 10.1.2.3 not responding.

Re: dmesg hangs 7.4

[Laura Smith]

Same thing, it hangs :

# cat /dev/urandom | openssl enc -base64 -out foo 
^C
# ls -lah foo
1.5G Mar  9 17:17 foo
# cat foo

Bunch of text, then hang, then dropped "Timeout, server not responding."



Sent with Proton Mail secure email.

On Saturday, 9 March 2024 at 16:55, Mihai Popescu  wrote:

> Just curious, what happens when you do:
> # cat 

dmesg hangs 7.4

[Laura Smith]

Hi

I've got a fresh install of 7.4 on a new box and am seeing a very weird problem.

If I enter "dmesg" I get a few lines of output and then it hangs and my ssh 
connection gets dropped.  I ran syspatch, rebooted and the problem persists.  

Example:

# dmesg
MX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu19: 32KB 64b/line 8-way D-cache, 64KB 64b/line 8-way I-cache, 2MB 64b/line 
16-way L2 cache, 30MB 64b/line 12-way L3 cache
cpu19: smt 0, core 35, package 0
cpu20 at mainbus0: apid 72 (application processor)
cpu20: 12th Gen Intel(R) Core(TM) i9-12900TE, 3392.18 MHz, 06-97-02, patch 
0025
Timeout, server 10.1.2.3 not responding.

We desire more map format compatibility for OPENSOURCE game. C

[Gregory Smith]

sourceforge.net/p/chaosesqueanthology/tickets/2/
We desire more map format compatability so our code can be used using more
maps.

We have found C++ OPENSOURCE (RMS I used the word you do not like: because
you won't help me get contributors at all) code to load UNREAL format 3d
maps. But our engine is in C and we do not know C++ and ALSO:

Anyone who does more than one significant thing in the engine per year goes
crazy.
And we already did 1 significant thing this year (more map compat).

For instance: Lord Havoc became "lady havock" That is insane and white. A
bad thing. He worked on the engine too much.
Cloudwalk had 2 mental breakdowns. Again: same issue. Worked on the engine
too much.

So you see: we make sure we don't work on the engine too much.
So we need you to help.

However we have been told that we will NEVER get any contributors because
we are not "GIRLS NOT BRIDES" dick-chopping faggots.

And if that is the case: if you will not help us because we are NOT
faggots: then you have made an enemy. We hope the muslims win and
re-institute marraige of little girls to men (ashia was a young girl in the
bukari hadiths: which you white, and white adjacant faggots do not like)
(Sahih Bukhari 5:58:236, Sahih Bukhari 7:62:64,Sahih Bukhari 8:73:151)

YHWH allows child brides. It's called virgin marraige. You opensource scum
hate that. You support dick-chopping and faggotry. You support feminism.
You are an enemy of... MMLLLE (as you call us all) (Devarim 22, 28.
greek, hebrew, latin (padia, na'ar, puella)) (moses was a crying na'ar when
pulled from the river: yes white fucks: na'ar means child)

So if you will not help us beause we do not subscribe to your FAGGOT
beliefs.
If that is the reason.
Then you have made an enemy.

In real life.

FUCK YOU.
And FUCK your FreeSoftware faggot coven.
Lying piece of fucking shit.

Marry Little Girls.
Also we'd like Unreal map support in this engine.

Re: Slow relink in 7.4

[Laura Smith]

--- Original Message ---
On Tuesday, October 17th, 2023 at 10:07, David Higgs  wrote:


> I have an underpowered amd64 VPS and attempted to (auto)upgrade it to 7.4.


Just how underpowered is your VPS ?

I've got a few underpowered VPS's (1 or 2 vCPU, 512MB RAM) and they went 
through the 7.4 upgrade without issue ?

Re: OpenBSD 7.4

[Laura Smith]

> I usually track the following file.
> 
> https://cvsweb.openbsd.org/src/etc/root/root.mail
> 


Ironically, that file seems to support the earlier statement made by Peter 
Hansteen that he got shot down for (i.e. "The exact date will not be generally 
known until it happens if recent releases
are anything to go by.").

Peter was absolutely right, and the CVS shows it, the date is constantly 
subject to change until such point as the powers that be call time.

Certainly by all means, track that file on CVS as the "source of truth" but 
ultimately there's no certainty until it happens.

Re: ixl not seeing SFP+ modules ?

[Laura Smith]

--- Original Message ---
On Saturday, April 15th, 2023 at 08:37, Stuart Henderson 
 wrote:



> I have FS and FlexOptix SFP and SFP+ (various LX, SR, LR) in X710-based cards,
> I don't remember what they're vendor-coded as (probably either Intel or Cisco
> for the FS, and either Intel or generic for the FlexOptix).
> 

Unfortunately I don't have any spare Flexoptix hanging around but sounds like 
it might well be worth a go.

Re: ixl not seeing SFP+ modules ?

[Laura Smith]

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, April 14th, 2023 at 21:14, Stuart Henderson 
 wrote:


> ixl can be vendor locked in firmware. also iirc they can be funny about when
> the module was plugged in, if it was hotplugged try rebooting, though vendor
> lock is more likely.
> 

Interesting tid-bit, thanks for that.

I think my ixl is a pure Intel one, but I'll need to go back through my orders 
...

I'll give the box a reboot later today just incase !

ixl not seeing SFP+ modules ?

[Laura Smith]

I have an ixl card (ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: 
port 3, FW 6.0.48442 API 1.7, msix, 4 queues) on OpenBSD that doesn't seem to 
be seeing any of my SFP+ modules.


The modules are all MSA coded and from different manufacturers.


ifconfig ixl shows "status: no carrier" (but light is confirmed as existing 
both ways and all patching has been triple checked).

Additionally "ifconfig ixl transciever" reports "ifconfig: transciever: bad 
value" whilst I believe this should be showing transceiver stats ?


Am I missing something here ?

Re: OpenBSD and AMD EPYC/RYZEN 10gb

[Laura Smith]

--- Original Message ---
On Wednesday, April 12th, 2023 at 16:57, Denis Fondras  
wrote:


> I started to write something that looks like a driver but haven't gone far 
> yet.
> There is no freely available doc about this chipset. The only source is the
> FreeBSD driver and it is meh...


The comments on the FreeBSD driver speaks as being based off the Linux driver ? 
I'm guessing you were unable to trace the "original" driver ? Maybe the quality 
got "lost in translation" ?

Re: OpenBSD and AMD EPYC/RYZEN 10gb

[Laura Smith]

Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, April 12th, 2023 at 16:13, Claudio Jeker 
 wrote:


> These integrated network ports are often disabled. I have not found a
> reasonably priced system that has them exposed. This is an important reason
> why OpenBSD is laking this driver. A developer needs to get such a system.
> None of the supermicro boards with AMD EPYC SoC have those 10G ports
> exposed.
>


Hi Claudio

One I know of : 
https://shop.opnsense.com/dec700-series-opnsense-desktop-security-appliance/

EUR 699 is probably "reasonably priced" for such a system, although of course 
others are of course free to disagree. ;-)

Re: OpenBSD and AMD EPYC/RYZEN 10gb

[Laura Smith]

No worries.

(And for anyone following on-list, I think FreeBSD might have subsequently 
renamed axgbe to something else beginning on ax, I think maybe "axa" as per the 
"history" note on the bottom of this page 
https://www.gsp.com/cgi-bin/man.cgi?section=4=AXP)




Sent with Proton Mail secure email.

--- Original Message ---
On Wednesday, April 12th, 2023 at 15:00, Mischa  wrote:


> Hi Laura,
> 
> Gotcha... I don't have those laying around. :)
> 
> Mischa
> 
> On 2023-04-12 15:54, Laura Smith wrote:
> 
> > Hi Mischa
> > 
> > Thank you for that.
> > 
> > However I think perhaps I was a little unclear in my original post, and
> > for that I apologise.
> > 
> > To be (more) clear, I was not talking about "network cards in AMD
> > computers", I was talking about AMD SoC network ports.
> > 
> > e.g. in FreeBSD land, these are known as "axgbe"
> > (https://reviews.freebsd.org/D25793,
> > https://doc.dpdk.org/guides/nics/axgbe.html)
> > 
> > --- Original Message ---
> > On Wednesday, April 12th, 2023 at 12:45, Mischa open...@mlst.nl
> > wrote:
> > 
> > > Hi Laura,
> > > 
> > > Just received my replacement card (10G RJ45, in stead of SFP+) for the
> > > R6415 EPYC machine.
> > > It works without any problems in 7.3.
> > > 
> > > bnxt0: flags=808843
> > > 
> > > mtu 1500
> > > lladdr 2c:ea:7f:ad:ff:3e
> > > index 3 priority 0 llprio 3
> > > groups: egress
> > > media: Ethernet autoselect (10GbaseT full-duplex,rxpause,txpause)
> > > status: active
> > > inet 192.168.1.107 netmask 0xff00 broadcast 192.168.1.255
> > > 
> > > The dmesg you can find at:
> > > https://dmesgd.nycbug.org/index.cgi?do=view=7047
> > > The chipset for the SFP+ card is the same.
> > > 
> > > Mischa
> > > 
> > > On 2023-04-12 12:01, Laura Smith wrote:
> > > 
> > > > Has anyone had the opportunity to experiment using OpenBSD in
> > > > conjunction with AMD EPYC/RYZEN native 10gb ports ?
> > > > 
> > > > As far as I can see there are no drivers for it in stable ? But maybe
> > > > someone's been playing with it on the bleeding-edge ?
> > > > 
> > > > Thanks !
> > > > 
> > > > Laura

Re: OpenBSD and AMD EPYC/RYZEN 10gb

[Laura Smith]

Hi Mischa

Thank you for that.

However I think perhaps I was a little unclear in my original post, and for 
that I apologise.

To be (more) clear, I was not talking about "network cards in AMD computers", I 
was talking about AMD SoC network ports.

e.g. in FreeBSD land, these are known as "axgbe" 
(https://reviews.freebsd.org/D25793, 
https://doc.dpdk.org/guides/nics/axgbe.html)


--- Original Message ---
On Wednesday, April 12th, 2023 at 12:45, Mischa  wrote:


> Hi Laura,
> 
> Just received my replacement card (10G RJ45, in stead of SFP+) for the
> R6415 EPYC machine.
> It works without any problems in 7.3.
> 
> bnxt0: flags=808843
> 
> mtu 1500
> lladdr 2c:ea:7f:ad:ff:3e
> index 3 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (10GbaseT full-duplex,rxpause,txpause)
> status: active
> inet 192.168.1.107 netmask 0xff00 broadcast 192.168.1.255
> 
> The dmesg you can find at:
> https://dmesgd.nycbug.org/index.cgi?do=view=7047
> The chipset for the SFP+ card is the same.
> 
> Mischa
> 
> On 2023-04-12 12:01, Laura Smith wrote:
> 
> > Has anyone had the opportunity to experiment using OpenBSD in
> > conjunction with AMD EPYC/RYZEN native 10gb ports ?
> > 
> > As far as I can see there are no drivers for it in stable ? But maybe
> > someone's been playing with it on the bleeding-edge ?
> > 
> > Thanks !
> > 
> > Laura

OpenBSD and AMD EPYC/RYZEN 10gb

[Laura Smith]

Has anyone had the opportunity to experiment using OpenBSD in conjunction with 
AMD EPYC/RYZEN native 10gb ports ?

As far as I can see there are no drivers for it in stable ?  But maybe 
someone's been playing with it on the bleeding-edge ?

Thanks !

Laura

Re: Dovecot OpenBSD 7.2 VM

[Brad Smith]

On 11/8/2022 6:50 PM, latin...@vcn.bc.ca wrote:

Hello misc

Is there a problem installing Dovecot? Thanks
I have 2 VMs upgraded working correctly, this is a new installation of
Dovecot at Vultr.

# pkg_add dovecot
quirks-6.42 signed on 2022-10-30T18:56:25Z
Can't install dovecot-2.3.19.1p0v0 because of libraries
|library iconv.7.1 not found
| /usr/local/lib/libiconv.so.7.0 (libiconv-1.16p0): minor is too small
|library sqlite3.37.20 not found
| /usr/local/lib/libsqlite3.so.37.15 (sqlite3-3.38.3): minor is too small
Direct dependencies for dovecot-2.3.19.1p0v0 resolve to icu4c-71.1v0
libstemmer-2.1.0 lz4-1.9.4 xz-5.2.5p1 libexttextcat-3.4.6 sqlite3-3.38.3
bzip2-1.0.8p0 libsodium-1.0.18p1 zstd-1.5.2 libiconv-1.16p0
Full dependency tree is icu4c-71.1v0 libstemmer-2.1.0 lz4-1.9.4 xz-5.2.5p1
sqlite3-3.38.3 libexttextcat-3.4.6 libsodium-1.0.18p1 bzip2-1.0.8p0
libiconv-1.16p0 zstd-1.5.2
Couldn't install dovecot-2.3.19.1p0v0


The system needs to have its packages updated. Those are not 7.2 packages.

Re: Wireless network interface remembering join list across /etc/netstart.

[Julian Smith]

On Tue, 21 Jun 2022 13:47:28 +0200
Stefan Sperling  wrote:

> On Mon, Jun 20, 2022 at 11:41:05PM +0100, Julian Smith wrote:

> > It turned out that i needed to do `ifconfig iwn0 down -joinlist up` to 
> > remove
> > all networks from the join list, as described in ifconfig(8). [I'm not
> > actually sure that the `down` and `up` are necessary.]
> > 
> > Would it be possible and make sense to have /etc/netstart do this
> > automatically for wireless interfaces? Or am i misunderstanding what
> > /etc/netstart is for?  
> 
> You could add the following as the first line of hostname.if if you
> would like netstart to clear out existing networks before adding new
> ones:
> 
> -joinlist

Ah, thanks! That looks like it will solve my problem very neatly.

- Jules

-- 
http://op59.net

Wireless network interface remembering join list across /etc/netstart.

[Julian Smith]

Recently i got really confused after removing a 'join  ... ' line
from /etc/hostname.iwn0, then running `sh /etc/netstart`. This resulted
in reconnection to , even though  was now not mentioned
anywhere in /etc/hostname.iwn0.

Even `ifconfig iwn0 down up` did not change this behaviour.

It turned out that i needed to do `ifconfig iwn0 down -joinlist up` to remove
all networks from the join list, as described in ifconfig(8). [I'm not
actually sure that the `down` and `up` are necessary.]

Would it be possible and make sense to have /etc/netstart do this
automatically for wireless interfaces? Or am i misunderstanding what
/etc/netstart is for?

Thanks for any help,

- Jules

-- 
http://op59.net

Re: Re: What’s new in OpenNSD 7.0 NYC*Bug meeting

[Laura Smith]

pj,

I'm afraid your counter to my post is a fine example of sort the die-hard 
open-sourcer I was referring to.

I'm sure in the world you live in, you think every desktop and server on the 
planet should be running OpenBSD. And that nobody should be using iOS or 
Android based smartphones.

But as I said, you have to sometimes appreciate that reality of life exists.

Sure, your dream goal of introducing the world to Jitsi is great. But, as you 
yourself said :

"Quality takes knowledge, effort and time".

That's already three big problems.  Are you willing to be a volunteer on the 
end of the Helldesk email when people start bombarding with questions because 
they are unfamiliar with whatever open-source conferencing solution you have 
chosen ?

You have carefully ignored the fourth problem: the global presence and 
"CDN-style" experience that the global commercial providers can offer.

As the old saying goes ... sometimes better the devil you know.

Re: What’s new in OpenNSD 7.0 NYC*Bug meeting

[Laura Smith]

‐‐‐ Original Message ‐‐‐
On Tuesday, October 26th, 2021 at 01:38,  wrote:
> I wouldn't trust Zoom any further than I'd trust Skype.

Whilst there are certainly arguments for not trusting Zoom, I think perhaps we 
need to take a step back here.

The reality is that whilst die-hard graybeard open-sourcers take an attitude 
that "if its not open source it doesn't exist" we have to understand what a 
service like Zoom (other similarly large commercial video conferencing 
platforms are available) bring to the table.

In particular they bring two aspects:

1) User familiarity.

Let's face it, one thing COVID has done is exposed the entire world to the joys 
(and frustrations) of web conferencing. The honest truth is that most people 
will have been exposed multiple times to Zoom (and Teams, WebEx and other 
commercial platorms), they'll already have the software on their devices and 
become comfortable with its use.

2) Dealing with geographic dispersion.

The problem with small-scale (or DIY) conferencing is that you do not have the 
worldwide presence. This means you cannot deliver a CDN style experience to 
your delegates where they connect to low-latency to an in-country/in-region 
datacentre and instead they have to connect accross the world to your server.

3) Zoom specific

If you have a paid Zoom account, there are various knobs and dials you can 
tweak in order to help with some of the concerns generally thrown in the 
direction of Zoom (e.g "no China datacentres", E2E encryption etc.).  Not 
saying its perfect, but better than nothing.

Re: Samsung SSD X5 with OpenBSD - possible ?

[Laura Smith]

‐‐‐ Original Message ‐‐‐

On Monday, October 25th, 2021 at 19:15, Stefan Sperling  wrote:

> On Mon, Oct 25, 2021 at 05:45:22PM +, Laura Smith wrote:
>
> > I'm struggling a bit as to what I need to do next here.
> >
> > Any time in the past I've connected a USB stick etc. to OpenBSD, everything 
> > happened automagically in terms of recognition and assigning a /dev/sd.
> >
> > However this time, its different.  This is the only line that appears in 
> > dmesg when I plug it in:
> >
> > ugen0 at uhub0 port 4 "SAMSUNG ELECTRONICS CO., LTD Portable SSD X5" rev 
> > 2.01/4.45 addr 2
> >
> > sysctl hw.disknames remains unchanged
> >
> > Any ideas ?
>
> I would guess that no driver is attaching because this drive requires
>
> Thunderbolt 3 rather than USB 3 (both use a USB-C type connector).

Makes sense, thanks !

Samsung SSD X5 with OpenBSD - possible ?

[Laura Smith]

I'm struggling a bit as to what I need to do next here.

Any time in the past I've connected a USB stick etc. to OpenBSD, everything 
happened automagically in terms of recognition and assigning a /dev/sd.

However this time, its different.  This is the only line that appears in dmesg 
when I plug it in:

ugen0 at uhub0 port 4 "SAMSUNG ELECTRONICS CO., LTD Portable SSD X5" rev 
2.01/4.45 addr 2

sysctl hw.disknames remains unchanged

Any ideas ?

Re: BGPD and source interface

[Laura Smith]

Super, thanks !

Laura

‐‐‐ Original Message ‐‐‐

On Friday, October 1st, 2021 at 13:39, Theo de Raadt  
wrote:

>  route [-T rtable] sourceaddr [-inet|-inet6] [address]
>  route [-T rtable] sourceaddr [-inet|-inet6] -ifp interface
>  Set the preferred source address.  If address is the word
>  "default", 0.0.0.0 or ::, source address will be chosen by
>  the kernel for the matching address family.  When address is
>  omitted, preferred source address is printed if set.  If -ifp
>  is used, source will use IP assigned to interface.  The
>  preferred source will not be used when:
>
>
> o destination is on-link
>
> o source address is assigned to a disabled interface
>
> This is best used as a !route command in a hostname.* file.
>
> Laura Smith n5d9xq3ti233xiyif...@protonmail.ch wrote:
>
> > Could somebody kindly remind me how to force OpenBSD to use the lo0 alias 
> > for outbound traffic ?
> >
> > I've got an OpenBSD instance which is getting its default route via bgpd.
> >
> > ping 8.8.8.8 does not work
> >
> > but
> >
> > ping -I $lo0_alias works
> >
> > How can I tell OpenBSD to use the lo0 as default outbound interface instead 
> > of the LAN IP ?

BGPD and source interface

[Laura Smith]

Could somebody kindly remind me how to force OpenBSD to use the lo0 alias for 
outbound traffic ?

I've got an OpenBSD instance which is getting its default route via bgpd.

ping 8.8.8.8 does not work
but
ping -I $lo0_alias works

How can I tell OpenBSD to use the lo0 as default outbound interface instead of 
the LAN IP ?

Re: Blog comparing open source BGP stacks

[Laura Smith]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Wednesday, August 25th, 2021 at 1:51 PM, Claudio Jeker 
 wrote:

> On Wed, Aug 25, 2021 at 02:01:26PM +0200, Kristjan Komlosi wrote:
>
> > On 24. 08. 21 21:59, Laura Smith wrote:
> >
> > > Would be interesting to hear comments from the community on this 
> > > comparison : 
> > > https://elegantnetwork.github.io/posts/followup-measuring-BGP-stacks/
> > >
> > > N.B. For the record, don't shoot the messenger, I had nothing to do with 
> > > these tests, I just became aware of them via the BIRD list. I am 
> > > particularly interested in the OpenBSD community comments given one 
> > > person on the BIRD list had this to say of OpenBGPD: "OpenBGPd has always 
> > > been a dog.".
> >
> > I'm no expert at all, but I'd imagine that OpenBGPD performs at least
> >
> > somewhat differently on Linux, which seems to be what the author used in the
> >
> > tests. My personal BGP server runs OpenBSD on a 512MB VPS, using about 150MB
> >
> > of RAM with full IPv6 table and routing my traffic just fine, though I can
> >
> > imagine the tables turning very quickly with lots of neighbors, as the
> >
> > benchmark shows. I could try replicating their setup on an OpenBSD system,
> >
> > but I don't have good enough hardware at hand at the moment.
>
> The massive amount of memory used in OpenBGPD comes from the fact that
>
> unlike BIRD OpenBGPD runs with a full Adj-RIB-Out.
>
> The tests result in large amount of prefixes that need to be tracked.
>
> If you have 100 peers announcing 1 random prefixes then you end up with
>
> 100 * 100 * 1 = 100Million elements to manage. This is not a realistic
>
> test since in most cases the number of routes in the Adj-RIB-Out is
>
> limited (even on route servers). In the end for day to day use OpenBGPD
>
> performs well enough for many people. Future releases will focus more on
>
> performance and optimizing Adj-RIB-Out is on the list.
>
>

Thanks for the insight Claudio. Very much appreciated !

Re: Blog comparing open source BGP stacks

[Laura Smith]

‐‐‐ Original Message ‐‐‐

On Wednesday, August 25th, 2021 at 1:01 PM, Kristjan Komlosi 
 wrote:

> On 24. 08. 21 21:59, Laura Smith wrote:
>
> > Would be interesting to hear comments from the community on this comparison 
> > : https://elegantnetwork.github.io/posts/followup-measuring-BGP-stacks/
> >
> > N.B. For the record, don't shoot the messenger, I had nothing to do with 
> > these tests, I just became aware of them via the BIRD list. I am 
> > particularly interested in the OpenBSD community comments given one person 
> > on the BIRD list had this to say of OpenBGPD: "OpenBGPd has always been a 
> > dog.".
>
> I'm no expert at all, but I'd imagine that OpenBGPD performs at least
>
> somewhat differently on Linux, which seems to be what the author used in
>
> the tests.

Yes, the Linux thought never crossed my mind.  But then the only thing I know 
about OpenBGPD on Linux is that due to maintenance complexities it doesn't 
integrate with the routing table which somewhat limits its usability (at least 
in any of my potential use-cases).

Blog comparing open source BGP stacks

[Laura Smith]

Would be interesting to hear comments from the community on this comparison : 
https://elegantnetwork.github.io/posts/followup-measuring-BGP-stacks/

N.B. For the record, don't shoot the messenger, I had nothing to do with these 
tests, I just became aware of them via the BIRD list.  I am particularly 
interested in the OpenBSD community comments given one person on the BIRD list 
had this to say of OpenBGPD: "OpenBGPd has always been a dog.".

Re: literature on tmux

[Laura Smith]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Friday, August 13th, 2021 at 8:07 AM, Jean-Pierre de Villiers 
 wrote:

> > I'd like to learn this program better.
> >
> > I prefer something printed/pressed instead of e-book.
>
> I own a copy of a neat little book published by "The Pragmatic
>
> Programmers" and written by Brian P. Hogan, specifically the 2nd
>
> edition.
>
> Though not as authoritative as the manual, it serves as a pretty decent
>
> summary. At the end of each chapter they also provide a convenient list
>
> of all the keybindings used in that chapter.
>
> More info, and an excerpt or two, on their web page:
>
> https://pragprog.com/titles/bhtmux2/tmux-2/
>
> Regards,
>
> JP


Hopefully they've released a new version with new keybindings ?

I've got a whole load of .tmux.conf files scattered around various servers 
based largely on the contents of that book.  I now get lines of error messages 
because the tmux syntax (or command support) has changed.

Re: 50Gbe

[Brad Smith]

Only bnxt and mcx support 50. Intel chips that do are 800 series, beyond ixl.

On August 11, 2021 5:13:11 p.m. Chris Cappuccio  wrote:


ha...@sdf.org [ha...@sdf.org] wrote:

> Hi folks!
>
> I wonder if OBSD supports 50Gbe network cards. And what is the cable
> standard to support such data transfers ?
>
> Thanks.
>
> --
> The lion and the tiger may be more powerful, but the wolves do not perform
> in the circus

$ apropos 50gb
bnxt(4) - Broadcom NetXtreme-C/E 10/25/40/50Gb Ethernet device

https://man.openbsd.org/bnxt.4


mcx and ixl cards are the most likely 10/25/40/50/100 GbE chips to be well 
supported, bnxt doesn't even support per-CPU queues yet



Sent with Aqua Mail for Android
https://www.mobisystems.com/aqua-mail

Re: libusb1 and Yoctopuce USB sensors

[Julian Smith]

On Mon, 9 Aug 2021 17:35:36 - (UTC)
Stuart Henderson  wrote:

> On 2021-08-08, Julian Smith  wrote:
> > I've been trying to get a yoctopuce (https://www.yoctopuce.com/) USB
> > sensor to work on OpenBSD, but have run into problems.
> >
> > The sensor has Linux code
> > (https://github.com/yoctopuce/yoctolib_cpp.git) that uses libusb, but
> > on OpenBSD using the libusb1 package, libusb_kernel_driver_active() and
> > libusb_detach_kernel_driver() are returning error code -12
> > (LIBUSB_ERROR_NOT_SUPPORTED).
> >
> > I found some rather old advice saying that these errors can be
> > ignored (https://github.com/apple/cups/issues/4088), but then i get an
> > error -12 from libusb_submit_transfer().  
> 
> There's no support for detaching a kernel USB driver from userland.
> 
> If the device is attaching to a driver other than ugen, your first is to
> prevent that and try again. Devices often attach to uhid(4) and libusb
> functionality is very limited there. But that's an easy case to work around,
> there's a UQ_BAD_HID quirk (see /usr/src/sys/dev/usb/usb_quirks.c),
> you can add an entry using that to prevent the vid/pid of your device
> from attaching and build a new kernel, it is then likely to end up on
> ugen(4) and then has a better chance to do what you need.

Many thanks for this, i've set up a separate machine for experimenting,
and built a new kernel as suggested and it all seems to be working now.

I'm still getting -12 from libusb_kernel_driver_active() and
libusb_detach_kernel_driver() but then things seem to work ok so for
example i'm seeing correct-looking CO2 measurements from the device.

Here's the diff:

cvs server: Diffing .
Index: usb_quirks.c
===
RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
retrieving revision 1.78
diff -u -p -r1.78 usb_quirks.c
--- usb_quirks.c24 Mar 2021 02:49:57 -  1.78
+++ usb_quirks.c11 Aug 2021 22:43:20 -
@@ -161,6 +161,9 @@ const struct usbd_quirk_entry {
  { USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_TYPECOVER2,
ANY,{ UQ_ALWAYS_OPEN }},
 
+/* Yoctopuce. */
+ { 0x24e0, 0x008b, ANY, { UQ_BAD_HID }},
+
  { 0, 0, 0, { 0 } }
 };

I tried adding Yoctopuce as vendor 0x24e0 and 0x008b as CO2V2 (it
measures CO2 levels etc) to /usr/src/sys/dev/usb/usbdevs but rebuilding
the kernel didn't seem to force regeneration of
/usr/src/sys/dev/usb/usbdevs.h for some reason, hence the direct use of
0x24e0 and 0x008b in the above patch.

Is the device incorrect when it claims to be a Human Interface Device?
If so i could maybe contact the manufacture.

> 
> > I notice that 'pkg_info -R libusb1' shows just 9 ports depend on
> > libusb1, so i'm wondering whether the libusb1 port is expected to work
> > generally on OpenBSD, or whether it be better to try to use the usb(4)
> > ioctl API?  
> 
> Many more use it via libusb-compat. Support is limited though and there's
> some resistance to doing anything to help userland control of USB devices
> so if it still doesn't work I'd suggest controlling it from another OS
> unless you fancy writing a kernel driver.
> 

Interesting, do you know of somewhere i can read some more about why
userland control of USB is not recommended? Now i've managed to get this
simple USB device working, i'm vaguely wondering about looking at
making a USB terrestrial TV receiver work with Kaffeine on OpenBSD. I
was hoping that doing this in user space might be easier than writing a
kernel driver, though i guess the data rate might be too high?

Thanks,

- Jules

-- 
http://op59.net

libusb1 and Yoctopuce USB sensors

[Julian Smith]

I've been trying to get a yoctopuce (https://www.yoctopuce.com/) USB
sensor to work on OpenBSD, but have run into problems.

The sensor has Linux code
(https://github.com/yoctopuce/yoctolib_cpp.git) that uses libusb, but
on OpenBSD using the libusb1 package, libusb_kernel_driver_active() and
libusb_detach_kernel_driver() are returning error code -12
(LIBUSB_ERROR_NOT_SUPPORTED).

I found some rather old advice saying that these errors can be
ignored (https://github.com/apple/cups/issues/4088), but then i get an
error -12 from libusb_submit_transfer().

I notice that 'pkg_info -R libusb1' shows just 9 ports depend on
libusb1, so i'm wondering whether the libusb1 port is expected to work
generally on OpenBSD, or whether it be better to try to use the usb(4)
ioctl API?

Thanks for any advice,

- Jules

-- 
http://op59.net

Re: Dovecot maildir sync not working after upgrade to 6.9

[Brad Smith]

Hi William,

I would try posting what you have to the Dovecot mailing list and see what 
Aki says.


On May 17, 2021 7:18:35 a.m. William Orr  wrote:


Hey,

I have two mailservers running OpenBSD 6.9, and I use bidirectional
syncing of my maildirs through doveadm, part of dovecot. After the
upgrade, I noticed that the sync process was failing.

Here's a sample run:

kefka|~|02:57:05|0$ doas doveadm sync -u w...@worrbase.com 
remote:sabin.worrbase.com

doveadm(VERSION dsync   3   5): Error: User doesn't exist
dsync-local(worr): Error: read(sabin.worrbase.com) 
failed: EOF (version not received)
dsync-local(worr): Error: Remote command returned 
error 67: /usr/bin/ssh -i /root/.ssh/id_ed25519.dsync sabin.worrbase.com 
/usr/local/bin/dsync-in-wrapper.sh


kefka|~|02:57:08|75$ cat /usr/local/bin/dsync-in-wrapper.sh
#!/bin/ksh
read username
/usr/local/bin/doveadm dsync-server -u "$username"

I ktraced the process, and noticed that in the communication with the
remote mail server, that a bunch of doveadm plugins fail to load. It's
worth noting that these are plugins that are dlopen(3)ed in response to
certain commands sent over the wire, so they don't show up in ldd(1) output.

kefka|~|03:00:08|0$ doas kdump | grep symbol
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_user_module'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_mailbox_get_aclobj'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_mailbox_list_get_backend'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_object_list_init'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_object_list_next'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_backend_rights_match_me'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_rights_get_id'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_object_list_deinit'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_object_get_my_rights'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_rights_update_import'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_mailbox_update_acl'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_lookup_dict_rebuild'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_backend_nonowner_lookups_iter_init'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_backend_nonowner_lookups_iter_next'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_backend_nonowner_lookups_iter_deinit'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_backend_nonowner_lookups_rebuild'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_lookup_dict_is_enabled'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_lookup_dict_iterate_visible_init'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_lookup_dict_iterate_visible_next'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_acl_plugin.so: 
  undefined symbol 'acl_lookup_dict_iterate_visible_deinit'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_quota_plugin.so: 
  undefined symbol 'quota_user_module'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_quota_plugin.so: 
  undefined symbol 'quota_root_get_resources'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib10_doveadm_quota_plugin.so: 
  undefined symbol 'quota_get_resource'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_plugin.so: 
  undefined symbol 'fts_list_backend'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_plugin.so: 
  undefined symbol 'fts_backend_lookup'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_plugin.so: 
  undefined symbol 'fts_backend_lookup_done'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_plugin.so: 
  undefined symbol 'fts_search_args_expand'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_plugin.so: 
  undefined symbol 'fts_language_find'
  "doveadm:/usr/local/lib/dovecot/doveadm/lib20_doveadm_fts_plugin.so: 
  undefined symbol 'fts_user_get_language_list'
  

Re: Remote wipe software

[Oliver Leaver-Smith]

Thanks for your response, a lot to think about sure. I suppose having
some sort of phone home daemon running to know whether or not to dd
itself is probably the best way to at least somewhat destroy itself in a
disaster scenario

> Label them carefully and destroy them when done to prevent very
> unhappy accidents later!

Like Employee_Financial_Data.xlsx?

--
Oliver Leaver-Smith
TZ=Europe/London

Re: Remote wipe software

[Oliver Leaver-Smith]

On Tue Apr 27, 2021 at 10:49 AM BST, Janne Johansson wrote:
> Regardless of OS, the "easiest" setup is where you encrypt the drives
> and wipe by "forgetting" the keys. Then you can dd the disks if it
> makes someone else happy but having FDE and changing the key to
> something random that you don't store, and then doing a normal wipe in
> the simplest of terms would cover a lot of the practical attacks.
>
> For the ones concerned with theoretical and imaginary enemies,
> PXE-booting into a DBAN.iso or similar wiping solutions is probably
> the next step. Also OS-independent.

Thanks Janne. Certainly those are two useful methods for ensuring that
the disk is wipe or the contents are not accessible. The scenario I am
thinking about is say a laptop is left in a suspended state, and
forgotten on a train somewhere. The contents of the drive would be
recoverable in that state unless something remote was to lock it down or
wipe the disk

--
Oliver Leaver-Smith
TZ=Europe/London

Remote wipe software

[Oliver Leaver-Smith]

Hello misc@

I wonder if anyone could recommend remote wipe software for OpenBSD, should 
someone want to start using it in an enterprise setting where such features are 
a requirement?

Thanks in advance,

ols

-- 
Oliver Leaver-Smith
TZ=Europe/London

Possible omission in cflags from pkg-config freeglut

[Julian Smith]

I'm wondering whether pkg-config might not be outputing correct flags
for freeglut.

For example this programme:

#include 
int main(void)
{
return 0;
}

- fails to build with:
cc `pkg-config --cflags --libs freeglut` foo.c

because:

In file included from foo.c:1:
In file included from /usr/local/include/GL/glut.h:17:
/usr/local/include/GL/freeglut_std.h:143:13: fatal error: 'GL/gl.h' file 
not found
#   include 
^
1 error generated.

But it builds ok if we add /usr/X11R6/include to the include path:

cc `pkg-config --cflags --libs freeglut` -I/usr/X11R6/include foo.c


For me, "pkg-config --cflags --libs freeglut" outputs:

-I/usr/local/include -L/usr/local/lib -lglut

So should pkg-config also output "-I/usr/X11R6/include" in this case?


I'm running OpenBSD 6.8 GENERIC.MP#98 amd64


Thanks for any clarification,

- Jules

-- 
http://op59.net

Re: seasons greetings and a network question

[Laura Smith]

‐‐‐ Original Message ‐‐‐
On Sunday, 20 December 2020 10:28, Peter J. Philipp  wrote:


> The story is, that I log time to lives (TTL) with a setsockopt() on my logging
> DNS server. Whenever mail.openbsd.org sends a mail it does not ask its cache
> but does a dns query every time. This is a great beacon on the Internet (at
> least for me) it tells something of the dedication openbsd has for delivering
> the mail from the mailing lists.
>
>

Erm 

Doesn't mail.openbsd.org, alongside most other openbsd servers, originate from 
Theo's basement ?

If so, it tells you nothing "beacon" about the state of the internet.  There 
are many, many, many better projects out there that you can monitor if you wish 
to have a true "beacon" view of what's going on on the internet.

Nor does it tell you anything of openbsd's dedication to anything apart from 
its obstinance in insisting that Theo's basement is the best place to host 
servers and refuse to answer questions from the community in that respect (see 
discussions when Theo came begging for money for electricity or whatever it was 
a few years back).

Still, I'm sure Theo will be happy for you to blow his trumpet for him. ;-)

Re: OpenLDAP under 6.8 - no intermediate certs in chain

[Brad Smith]

On 11/16/2020 12:08 AM, Paul B. Henson wrote:

I just updated one of my servers running 6.7 to 6.8, and am having a
problem with openldap. I have the intermediate cert and root CA in a
file referenced by the openldap config:

TLSCACertificateFile/etc/openldap/cabundle.crt

Under 6.7 with the openldap port from that version, this results in the
chain being served:

Certificate chain
  0 s:CN = ldap-netsvc.pbhware.com
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
  1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
  2 s:O = Digital Signature Trust Co., CN = DST Root CA X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3

However, under 6.8 with the newer openldap 2.4.53 port, only the server
cert itself is being served, not the intermediate or root:

Certificate chain
  0 s:CN = ldap-netsvc.pbhware.com
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

This of course causes clients to fail to validate the server cert :(.

I'm running openldap 2.4.53 on other operating systems and as far as I
know there's no change in behavior with it. So I'm guessing there's an
interoperability issue between openbsd libressl and openldap that's
causing this problem?

Do I need to configure something differently? Any other suggestions?

Thanks much...



I remember seeing this commit recently. Not sure if this is your problem 
or not.


https://marc.info/?l=openbsd-cvs=160511882917510=2

Re: wg - panic: noise_keypair: lock not held

[Laura Smith]

‐‐‐ Original Message ‐‐‐
On Wednesday, 4 November 2020 16:56, Caspar Schutijser  
wrote:

> On Mon, Nov 02, 2020 at 02:55:55PM +, Laura Smith wrote:
>
> > Hi
> > I'm still trying to figure out what triggered this, I think it might have 
> > been running "sh /etc/netstart" after a "hostname.wg" config update, but 
> > I've been unable to reproduce.
> > As a sidenote, I thought "ddb.panic=0" was supposed to prevent these sort 
> > of hanging panics?
> > Nonetheless, I'm pasting the trace here just incase its useful for someone :
> > panic: noise_keypair: lock not held
> > Starting stack trace...
> > panic (81dbfe3d) at panic +0x11d
> > rw_exit_write(88017450) at rw_exit_write+0xb5
> > noise_remote_begin_session(808017350) at  
> > noise_remote_begin_session+0x3c1rw_exit_write(88017320) at 
> > wg_send_response+0x7b
> > wg_handshake(85ed00,d80a7311600) at wg_handshake+0x576
> > wg_handshake_worker(805ed000) at wg_handshake_worker+0x48
> > taskq_thread(8006d900) at taskq_thread+0x81
> > end trace frame:0x0, count:250
> > End of stack trace
>
> A fix for this has been committed, see
> https://marc.info/?l=openbsd-cvs=160415334131043=2
>
> A patch for OpenBSD 6.8 also exists:
> https://ftp.openbsd.org/pub/OpenBSD/patches/6.8/common/004_wg.patch.sig


Thanks Caspar.  Indeed, Gabrial Kihlman kindly pointed out the patch, but 
because I only run -stable in production, I was without the fix.  But the devs 
have kindly pushed it out as an Errata now so its all sorted and life is good 
again with wg(4) !

wg - panic: noise_keypair: lock not held

[Laura Smith]

Hi

I'm still trying to figure out what triggered this, I think it might have been 
running "sh /etc/netstart" after a "hostname.wg" config update, but I've been 
unable to reproduce.

As a sidenote, I thought "ddb.panic=0" was supposed to prevent these sort of 
hanging panics?

Nonetheless, I'm pasting the trace here just incase its useful for someone :

panic: noise_keypair: lock not held
Starting stack trace...
panic (81dbfe3d) at panic +0x11d
rw_exit_write(88017450) at rw_exit_write+0xb5
noise_remote_begin_session(808017350) at  
noise_remote_begin_session+0x3c1rw_exit_write(88017320) at 
wg_send_response+0x7b
wg_handshake(85ed00,d80a7311600) at wg_handshake+0x576
wg_handshake_worker(805ed000) at wg_handshake_worker+0x48
taskq_thread(8006d900) at taskq_thread+0x81
end trace frame:0x0, count:250
End of stack trace

Re: 6.8 - Difficulties getting Wireguard ipv6 working

[Laura Smith]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, 1 November 2020 14:37, Matt Dunwoodie  wrote:

> On Sat, 31 Oct 2020 21:31:50 +
> Laura Smith n5d9xq3ti233xiyif...@protonmail.ch wrote:
>
> > Hi,
> > I currently have a fully functional dual-stack Wireguard instance
> > running on Debian. However given the recent release of OpenBSD 6.8
> > with Wireguard in base, I thought it would be a good opportunity to
> > switch over from the dark side. ;-)
> > Anyway, so on Debian I have a no-NAT setup, with the host announcing
> > the VPN subnets to upstream router. All works great.
> > I'm no stranger to OpenBSD and OpenBGPD, but I've only managed to get
> > 2/3 of the way :
> >
> > -   The OpenBSD host is config fully functional dual-stack,  IPv4 and
> > IPv6 work perfectly
> >
> > -   wg(4) IPv4 config works perfectly, clients can connect and browse
> > the internet
> >
> > -   wg(4) IPv6 config does not work, clients can connect but no
> > routing, not even able to ping loopback IPs or the wg interface IP.
> >
> > -   I have verified upstream routers can ping test loopback IPv6 IPs,
> > so dual-stack BGP is functional
> >
> > -   I have tried a IPv6 only wireguard client config (as shown below)
> > and that has no effect ( i thought maybe a dual-stack client config
> > was the problem with OpenBSD)
> >
>
> Firstly, there should be no issues with any combination of v4+v6
> with wg(4), so I presume it is a misconfiguration somewhere.
>
> Having a quick look at the config, the endpoint should not be the same
> as the inet6 addr on the server wg1. But I might guess that was a
> mistake when sanitising your configs?
>
> Unfortunately, without more information it would be difficult to
> diagnose. Route tables from both ends would be a start. I would also
> suggest doing a tcpdump on wg interfaces on both ends to see where
> traffic is leaving/arriving.
>
> Cheers,
> Matt


Hi Matt

I retried with a different endpoint and it seemed to work this time.

Thanks

Re: pkg_add version scripting ?

[Laura Smith]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, 1 November 2020 12:53, Marc Espie  wrote:

> On Sun, Nov 01, 2020 at 12:23:44PM +, Laura Smith wrote:
>
> > Hi
> > As far as I can tell from the docs, only pkg_info supports spec style ?
> > I am trying to script an OpenBSD setup and as part of that certain packages 
> > need to be installed. For most packages that is not a problem, however, for 
> > example, with gnupg, there are two versions in the 6.8 repo :
> > gnupg-1.4.23p4.tgz
> > gnupg-2.2.23p0.tgz
> > I cannot seem to find a way to tell pkg_add to install >=2  (or better 
> > still, install "the latest" version).
>
> "Better still" to be discussed.
>
> Newer is not always better, especially when some things stop working and
> stuff like that.
>
> It's generally considered that scripting is meant to give you a reliable
> system...
>
> > Any ideas ?
>
> You should read pkg_add(1) more closely.
>
> pkg_add also understands ‘stems’, that is, package names without any
> version specification. For instance, with ‘pkg_add kdelibs’, pkg_add
> will look in the current directory (or the PKG_PATH) for a kdelibs
> package.
>
> pkg_add may ask questions in interactive mode, or error out otherwise.
> Interactive mode is the default on a tty, see options -I/i.
>
> For instance ‘pkg_add screen’ is ambiguous as it matches screen-4.03p6
> and screen-4.03p6-shm.
>
> To avoid ambiguities, pkg_add supports ‘stems with flavors’, that is, a
> stem separated from flavors with a double dash. For instance, the
> previous ambiguity could be resolved by using ‘pkg_add screen--’ (matches
> only the empty flavor) or ‘pkg_add screen--shm’ (matches only the shm
> flavor).
>
> There is also an ambiguity related to ports with multiple branches. For
> instance ‘pkg_add python’ is ambiguous, as there are several versions of
> python in the ports tree. So is ‘pkg_add postfix’. The special form
> ‘pkgname%branch’ can be used to restrict matches to a branch matching the
> pkgpath(7).
>
> The above ambiguities can be resolved using ‘pkg_add postfix%stable’ and
> ‘pkg_add python%3.4’, respectively.
>
> stuff like pkg_add gnupg%gnupg and pkg_add gnupg%gnupg2
> in 6.8, with possibly a bit more to take care of flavors as well.
>
> (note that pkg_info -z will give you the exact specs you want)



I did actually try "pkg_add gnupg%2" but pkg_add didn't like that.  Will go try 
"pkg_add gnupg%gnupg2" instead

pkg_add version scripting ?

[Laura Smith]

Hi

As far as I can tell from the docs, only pkg_info supports spec style ?

I am trying to script an OpenBSD setup and as part of that certain packages 
need to be installed. For most packages that is not a problem, however, for 
example, with gnupg, there are two versions in the 6.8 repo :
gnupg-1.4.23p4.tgz
gnupg-2.2.23p0.tgz

I cannot seem to find a way to tell pkg_add to install >=2  (or better still, 
install "the latest" version).

Any ideas ?

Laura

6.8 - Difficulties getting Wireguard ipv6 working

[Laura Smith]

Hi,

I currently have a fully functional dual-stack Wireguard instance running on 
Debian. However given the recent release of OpenBSD 6.8 with Wireguard in base, 
I thought it would be a good opportunity to switch over from the dark side. ;-)

Anyway, so on Debian I have a no-NAT setup, with the host announcing the VPN 
subnets to upstream router. All works great.

I'm no stranger to OpenBSD and OpenBGPD, but I've only managed to get 2/3 of 
the way :
- The OpenBSD host is config fully functional dual-stack,  IPv4 and IPv6 work 
perfectly
- wg(4) IPv4 config works perfectly, clients can connect and browse the internet
- wg(4) IPv6 config does not work, clients can connect but no routing, not even 
able to ping loopback IPs or the wg interface IP.
- I have verified upstream routers can ping test loopback IPv6 IPs, so 
dual-stack BGP is functional
- I have tried a IPv6 only wireguard client config (as shown below) and that 
has no effect ( i thought maybe a dual-stack client config was the problem with 
OpenBSD)

Config follows:

OPENBSD SERVER
$ cat /etc/sysctl.conf                                                          
                                                     
ddb.panic=0
net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1
$ cat /etc/hostname.wg1                                                         
                                                
inet 192.0.2.1 0xffc0
inet6 2001:db8:::: 64
wgkey secretsquirrel
wgport 12345
wgpeer secretsquirrel wgpsk secretsquirrel wgaip 192.0.2.2/32 wgaip 
2001:db8::::::/128
up
$ doas cat /etc/pf.conf 
  
set skip on {lo,wg}
pass

CLIENT CONFIG

[Interface]
PrivateKey = secretsquirrel
Address = 2001:db8::::::/128
DNS = 2620:fe::fe
[Peer]
PublicKey = secretsquirrel
PresharedKey = secretsquirrel
AllowedIPs = ::/0
Endpoint = [2001:db8::::]:12345

Re: OpenBSD UEFI on QEMU emulator

[Brad Smith]

On 10/22/2020 11:22 PM, Jonathan Gray wrote:

On Thu, Oct 22, 2020 at 10:37:31PM -0400, Brad Smith wrote:

On 10/22/2020 9:59 PM, Kevin Shell wrote:

Hello misc@.

I want to try out OpenBSD UEFI.
How to install OpenBSD with UEFI boot on qemu?

The installer does prompt you during disk setup.

The install68.iso has no UEFI support.

This is not true.

It does not include a fat fs el torito image with efiboot only
cdbr for mbr.


Ya, my bad. I interpreted what he meant there differently. I thought he was
implying there was no EFI support at all post-install. On any X86 hardware
where I don't run Windows I typically keep CSM enabled. As I find I am more
likely to have to boot something that still requires MBR like from a USB key
to do firmware updates, though I have seen some EFI compatible update
images for some things. But I have heard of systems without CSM, since it is
optional. I see how this would be an issue with EFI only environments.

Re: OpenBSD UEFI on QEMU emulator

[Brad Smith]

On 10/22/2020 9:59 PM, Kevin Shell wrote:

Hello misc@.

I want to try out OpenBSD UEFI.
How to install OpenBSD with UEFI boot on qemu?

The installer does prompt you during disk setup.

The install68.iso has no UEFI support.


This is not true.


My following command on Linux can't boot OpenBSD UEFI.

qemu-system-x86_64 -enable-kvm \
-machine q35 \
-cpu host \
-smp cores=4,threads=1 \
-m 1G \
-bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
-drive file=install68.img,format=raw


--
kevin

Re: cmake does not use -O2 for Release builds

[Julian Smith]

On Tue, 6 Oct 2020 13:29:56 - (UTC)
Stuart Henderson  wrote:

> On 2020-10-05, Julian Smith  wrote:
> > It looks like OpenBSD's cmake port patches cmake to remove the use
> > of -O2 in Release and RelWithDebInfo builds -
> > /usr/ports/devel/cmake/patches/patch-Modules_Compiler_GNU_cmake has:
> >
> > -  string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os
> > -DNDEBUG")
> > -  string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
> > -  string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g
> > -DNDEBUG")
> > +  string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -DNDEBUG")
> > +  string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -DNDEBUG")
> > +  string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -g
> > -DNDEBUG")
> >
> > Does anyone know why things are patched in this way?
> >
> >
> > [I think one can force optimisation with (for example):
> >
> > cmake -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG"  ...
> > ]
> >
> >
> > Thanks,
> >
> > - Jules
> >  
> 
> It's setup to work with builds done from ports, which should not
> override whatever optimization level is set by either the user or the
> build infrastructure.
> 
> The downside is that you need to add this yourself for builds from
> outside ports.

Thanks for the explanation.

Would it be worth documenting this in the cmake(1) manpage? If so, i'll
submit a patch.

It's quite confusing to have cmake not optimise by default for Release
or RelWithDeb builds - i built OpenSceneGraph-3.6 while working on
Flightgear and it took a rather long time to figure out why i was
getting such a reduced frame rate.

Thanks,

- Jules

-- 
http://op59.net

cmake does not use -O2 for Release builds

[Julian Smith]

It looks like OpenBSD's cmake port patches cmake to remove the use of
-O2 in Release and RelWithDebInfo builds -
/usr/ports/devel/cmake/patches/patch-Modules_Compiler_GNU_cmake has:

-  string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -Os -DNDEBUG")
-  string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
-  string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
+  string(APPEND CMAKE_${lang}_FLAGS_MINSIZEREL_INIT " -DNDEBUG")
+  string(APPEND CMAKE_${lang}_FLAGS_RELEASE_INIT " -DNDEBUG")
+  string(APPEND CMAKE_${lang}_FLAGS_RELWITHDEBINFO_INIT " -g -DNDEBUG")

Does anyone know why things are patched in this way?


[I think one can force optimisation with (for example):

cmake -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="-O2 -g -DNDEBUG"  ...
]


Thanks,

- Jules

-- 
http://op59.net

Re: Problems with iwn wireless networking

[Julian Smith]

On Mon, 17 Aug 2020 08:14:22 - (UTC)
Stuart Henderson  wrote:

> On 2020-08-15, Julian Smith  wrote:
> >
> > Ok i'll try building a current kernel in the next few days.  
> 
> Kernel and userland (and device firmware) should be in sync. It's
> easier to use a snapshot, you can install to USB stick if you don't
> want to update your main drive.

Thanks for pointing this out.

I've bought a 32GB USB stick, installed OpenBSD-6.7 on it, and made it
mount my origin /home, so the system is basically the same as before.

Unfortunately, i haven't been able to crash the iwn0 device. (I was
intending to reproduce the iwn0 crash then upgrade to a snapshot and see
whether that made any difference.)

I have noticed that when the OpenBSD system is downloading, but only at
a fraction of the available wireless bandwidth, other devices seem to
struggle to get bandwidth. But i'm not sure whether this is significant.

The only difference in the setup i can think of is that i haven't yet
installed all required firmware - i've only run 'fw_update iwn'.

According to fw_update -n, the following firmware needs
installing:

vmm-firmware
inteldrm-firmware
intel-firmware
uvideo-firmware

I'll try installing these one at a time and see whether that provokes
any issues.

Thanks,

- Jules

-- 
http://op59.net

Installing sets from install67.fs on USB stick

[Julian Smith]

I've just run into a slightly confusing situation during an install
using install67.fs on a USB stick, and wondered whether it might be
worth adding something to http://www.openbsd.org/faq/faq4.html
"Installation Guide " to clarify what to do.

I was installing onto a second 32 GB USB stick on a Lenovo x220.

At the "Let's install the sets!" stage, the installer asks:

Location of sets? (disk http nfs or 'done') [http]

At this stage networking was not working due to missing firmware, so i
entered "disk" to use the sets from install67.fs on the install USB
stick.

Then it asks:

Is the disk partition already mounted? [yes]

I wasn't sure about the correct answer here. It turns out that you need
to say "no".

But it then lists the disk on which it is installing OpenBSD
(containing the partitions that were created by the installer earlier):

Available disks are: sd0.

I eventually got things to work by unplugging and re-plugging the USB
install stick before answering "no" to "Is the disk partition already
mounted? [yes]". This feels slightly unsafe of course, but presumably
the installer has copied everything into the ramdisk kernel in memory by
this point?

Thereafter, things worked fine:

Available disks are: sd0 sd1.
Which disk contains the install media? (or 'done') [sd1]
a: 928768 [...]
i: 960 [...]
Available sd1 partitions are: a i
Which sd1 partition has the install sets? (or 'done') [a]
Pathname to the sets? (or 'done') [6.7/amd64]

And the sets were found and installed with no further problems.


Would it be worth me coming up with some text to add to
http://www.openbsd.org/faq/faq4.html explaining this? Or maybe my
installing onto a second USB stick is unusual and might have caused the
issue?


Thanks,

- Jules

-- 
http://op59.net

bgpd config advice needed

[Laura Smith]

Hi,

Let's say I've got a scenario where I've got transit ISPs and peering 
connections.

My general config rule is that I use med to prioritise peering over transit 
(because localpref is too high up in the BGP selection algorithm, so localpref 
is a sledgehammer to crack a nut).

That setup has served me well.  But now with increasing peering connections, 
I'm seeing the wrong peer being selected for a route, e.g. (IPs and ASNs 
obfuscated to protect the innocent) 

*>  N 2001:db8:::/29   2001:db8::::1    100   100 64512 
65500 i
*   N 2001:db8:::/29   2001:db8::::2    100   100 65500 
65500 i

In this example, both 64512 and 65500 are peers (med=100) but obviously 65500 
65500 should be the preferred route.

What options do I have to resolve this sort of tie-break ?  Ideally I'd like to 
find something that would resolve all such instances rather than have to 
introduce config hacks on a per-peer basis.

Thanks

Laura

Re: Problems with iwn wireless networking

[Julian Smith]

On Sat, 15 Aug 2020 11:09:59 +0200
Stefan Sperling  wrote:

> On Sat, Aug 15, 2020 at 09:14:48AM +0100, Julian Smith wrote:
> > I'm seeing fairly frequent (e.g. more than daily) failures from an
> > iwn0 wireless network device, on a Lenovo X230.
> > 
> > dmesg|grep iwn shows:
> > 
> > iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev
> > 0x34: msi, MIMO 2T2R, MoW, address a4:4e:31:43:f1:60 iwn0: fatal
> > firmware error iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: device timeout
> > iwn0: device timeout
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > iwn0: device timeout
> > iwn0: fatal firmware error
> > iwn0: fatal firmware error
> > 
> > Uptime is 6 days, so this is several failures per day on average.
> > 
> > iwn(4) DIAGNOSTICS says that these two types of error 'should not
> > happen'.
> > 
> > Is here anything i can do about this? The machine is a Lenovo X230.
> > 
> > Or is there alternative wireless hardware that i install instead
> > that is known to be reliable?
> > 
> > Full dmesg is below. My kernel has a patch from visa@ to reduce gdb
> > uninterruptible wait problem (see 'gdb in uninterruptible wait'
> > thread on misc), but is otherwise vanilla 6.7.  
> 
> Could you try -current to see if the issue is still present there?

Ok i'll try building a current kernel in the next few days. (Do you
know of any changes that could affect iwn?)

> 
> On 6.7, does forcing 11a or 11g mode work around this? For example:
>   ifconfig iwn0 mode 11g

'mode 11g' doesn't appear to make any difference. 'mode 11a' results in
no connection at all.

Thanks,

- Jules

-- 
http://op59.net

Problems with iwn wireless networking

[Julian Smith]

I'm seeing fairly frequent (e.g. more than daily) failures from an iwn0
wireless network device, on a Lenovo X230.

dmesg|grep iwn shows:

iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
MIMO 2T2R, MoW, address a4:4e:31:43:f1:60
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: device timeout
iwn0: device timeout
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: fatal firmware error
iwn0: device timeout
iwn0: fatal firmware error
iwn0: fatal firmware error

Uptime is 6 days, so this is several failures per day on average.

iwn(4) DIAGNOSTICS says that these two types of error 'should not
happen'.

Is here anything i can do about this? The machine is a Lenovo X230.

Or is there alternative wireless hardware that i install instead that
is known to be reliable?

Full dmesg is below. My kernel has a patch from visa@ to reduce gdb
uninterruptible wait problem (see 'gdb in uninterruptible wait' thread
on misc), but is otherwise vanilla 6.7.

Thanks,

- Jules



OpenBSD 6.7 (GENERIC.MP) #1: Tue Jul 21 09:27:57 BST 2020
jules@jules-obsd:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16972566528 (16186MB)
avail mem = 16445550592 (15683MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (69 entries)
bios0: vendor LENOVO version "G2ETA7WW (2.67 )" date 09/09/2016
bios0: LENOVO 232577G
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! 
UEFI UEFI MSDM SSDT SSDT DMAR UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) 
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.94 MHz, 06-3a-09
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09
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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,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 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 4 (EXP3)
acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(350@80 

Re: Confused by adjfreq(2)

[Julian Smith]

On Mon, 10 Aug 2020 09:53:10 +0200
Otto Moerbeek  wrote:

> On Sun, Aug 09, 2020 at 09:46:00PM +0100, Julian Smith wrote:
> 
> > I've just used adjfreq() directly to correct my hardware clock,
> > which was running an hour ahead of UTC (due to my hardware
> > previously running Windows).
> > 
> > But i've struggled to understand the adjfreq(2) man page, so ended
> > up finding a value for  by trial and error.
> > 
> > I ended up with this code:
> > 
> > double x = 1.5;
> > int64_t newfreq = ((1ll << 32) * 1e9) * x;
> > adjfreq(newfreq, NULL);  
> 
> This does not look like actual code, first arg should be a pointer.

Ah yes, apologies for this, i foolishly hand-wrote the code above in
the post. The actual code i used did pass a pointer:

e = adjfreq(, );

> 
> > 
> > In this table, the second column is the increment in the time as
> > shown by running date(1) twice, over a 10 second period as measured
> > using my phone as a timer, for different values of x:
> > 
> > x  10s
> > -
> > 0  10
> > 0.112
> > 0.25   13
> > 0.515
> > 0.75   17
> > 0.819
> > 0.919
> > 1.021
> > 1.1 1
> > 1.25:   3
> > 1.5:6
> > 1.75:   8
> > 2: 10
> > 2.25:  10
> > 2.5:   10  
> 
> The only user of adjfreq(2) in base is ntpd(8), which caps it's
> adjustments between +/-MAX_FREQUENCY_ADJUST = 128e-5.
> 
> It is very well possible the calculations in the kernel go wrong with
> large(r) values. The API exists for gradual adjustments, not for
> anything big.  Scott Cheloha  has been working
> on the kernel side of things, he might know more, so I Cc'ed him,
> don't know if her reads misc@.

Thanks for doing this.

Using a big adjustment was very convenient for fixing my problem, so it
might be of general use/interest. I guess alternatives would be to get
control early in boot and fix it up; or i think one can tell the OS that
the hardware clock is set to a particular offset from UTC (can't find
the man page for this right now, but i'm sure i came across it when
investigating adjfreq).

Thanks,

- Jules

-- 
http://op59.net

Confused by adjfreq(2)

[Julian Smith]

I've just used adjfreq() directly to correct my hardware clock, which
was running an hour ahead of UTC (due to my hardware previously running
Windows).

But i've struggled to understand the adjfreq(2) man page, so ended up
finding a value for  by trial and error.

I ended up with this code:

double x = 1.5;
int64_t newfreq = ((1ll << 32) * 1e9) * x;
adjfreq(newfreq, NULL);

In this table, the second column is the increment in the time as shown
by running date(1) twice, over a 10 second period as measured using my
phone as a timer, for different values of x:

x  10s
-
0  10
0.112
0.25   13
0.515
0.75   17
0.819
0.919
1.021
1.1 1
1.25:   3
1.5:6
1.75:   8
2: 10
2.25:  10
2.5:   10

So using x=1.5 makes OpenBSD's clock run at 0.6x of real time. I used
this value to correct the one hour error in just over two hours.

But i wonder whether anyone could explain the values in the above
table? The code in src/sys/kern/kern_tc.c:tc_windup() might be
relevant, but i'm not sure what exactly it is doing.

As far as i can tell, the actual int64 values corresponding to the
values of x above are:

x=0.00 newfreq=0
x=0.10 newfreq=4294967296
x=0.25 newfreq=10737418240
x=0.50 newfreq=21474836480
x=0.75 newfreq=32212254720
x=0.80 newfreq=34359738368
x=0.90 newfreq=38654705664
x=1.00 newfreq=42949672960
x=1.10 newfreq=47244640256
x=1.25 newfreq=53687091200
x=1.50 newfreq=64424509440
x=1.75 newfreq=75161927680
x=2.00 newfreq=85899345920
x=2.25 newfreq=-9223372036854775808
x=2.50 newfreq=-9223372036854775808

So these values increase monotonically, except for presumably wrapping
errors for x=2.25 and x=2.5. So how come there is a big difference in
behaviour between x=1.0 (21x) and x=1.1 (1x) ?

Thanks for any help here,

- Jules

-- 
http://op59.net

Re: gdb in uninterruptible wait

[Julian Smith]

On Tue, 21 Jul 2020 19:23:44 +0100
Julian Smith  wrote:

> On Mon, 20 Jul 2020 17:18:19 +0100
> Julian Smith  wrote:
> 
> > On Mon, 20 Jul 2020 15:26:11 +
> > Visa Hankala  wrote:
> >   
> > > On Mon, Jul 20, 2020 at 04:35:12AM +, Visa Hankala wrote:
> > > > On Sun, Jul 19, 2020 at 09:47:54PM +0100, Julian Smith wrote:
> > > >
> > > > > I've been finding egdb and gdb rather easily get stuck in an
> > > > > uninterruptible wait, e.g. when running the 'next' command
> > > > > after hitting a breakpoint.
> > 
> > [...]
> >   
> > > > The single-thread check done by wait4() is non-interruptible.
> > > > When the debugger gets stuck, is it blocked in "suspend" state?
> > > >
> > 
> > ps reports it to be in state 'D'.
> >   
> > > > 
> > > > However, I think there is a bug in the single-thread switch
> > > > code. It looks that ps_singlecount can be decremented too much.
> > > > This probably is a regression of making ps_singlecount unsigned
> > > > and letting single_thread_check() run without the kernel lock.
> > > > 
> > > > The bug might go away if single_thread_check() made sure that
> > > > P_SUSPSINGLE is set before the thread suspends.   
> > > 
> > > Below is an updated patch for testing. It extends the scope of
> > > SCHED_LOCK() so that there are fewer chances of interleaving of
> > > single_thread_set() and single_thread_check().
> > 
> > Many thanks for these patches. I'll try to test in the next couple
> > of days. Though the last time i built an OpenBSD kernel was well
> > over a decade ago, so it might take me a little longer.  
> 
> I managed to build a patched kernel, and it seems to fix the problem -
> i haven't been able to get egdb into an uninterruptable wait state.
> 
> Also, i've been running the patched kernel all day now and it doesn't
> seem to be causing any problems elsewhere.

Unfortunately the same problem has just occurred again. I've run egdb
quite a few times since i updated the kernel, so the patch has
definitely reduced the problem, but it doesn't seem to have eliminated
it.

Let me know if there anything i could do to find out more information.

Thanks,

- Jules

-- 
http://op59.net

Re: ksh very slow compared to bash when running ghostscript's ./configure script

[Julian Smith]

On Wed, 22 Jul 2020 19:09:41 +0200
Theo Buehler  wrote:

> On Wed, Jul 22, 2020 at 07:05:31PM +0200, Theo Buehler wrote:
> > This works around the bug:  
> 
> And this might even be a correct fix:
> 
> diff --git configure.ac configure.ac
> index 0d22ad59b..d27222459 100644
> --- configure.ac
> +++ configure.ac
> @@ -483,7 +483,7 @@ AC_LINK_IFELSE(
>[AC_LANG_PROGRAM([#include ], [
>return(0);
>])],
> -  [CFLAGS_SANITIZE="$CFLAGS"],
> [CFLAGS_SANITIZE="ADDRESS_SANITIZER_NOT_SUPPORTED*"])
> +  [CFLAGS_SANITIZE="$CFLAGS"],
> [CFLAGS_SANITIZE="'ADDRESS_SANITIZER_NOT_SUPPORTED*'"])
>  
>  CFLAGS="$CFLAGS_SAVED"


Ah yes, great, that fixes it independently of any improvement to ksh's
glob code. Many thanks.

I'll try to make this change to ghostpdl's main git repository in the
next few days.


Thanks,

- Jules

-- 
http://op59.net

Re: gdb in uninterruptible wait

[Julian Smith]

On Mon, 20 Jul 2020 17:18:19 +0100
Julian Smith  wrote:

> On Mon, 20 Jul 2020 15:26:11 +
> Visa Hankala  wrote:
> 
> > On Mon, Jul 20, 2020 at 04:35:12AM +, Visa Hankala wrote:  
> > > On Sun, Jul 19, 2020 at 09:47:54PM +0100, Julian Smith wrote:
> > > > I've been finding egdb and gdb rather easily get stuck in an
> > > > uninterruptible wait, e.g. when running the 'next' command after
> > > > hitting a breakpoint.  
> 
> [...]
> 
> > > The single-thread check done by wait4() is non-interruptible.
> > > When the debugger gets stuck, is it blocked in "suspend" state?  
> 
> ps reports it to be in state 'D'.
> 
> > > 
> > > However, I think there is a bug in the single-thread switch code.
> > > It looks that ps_singlecount can be decremented too much. This
> > > probably is a regression of making ps_singlecount unsigned and
> > > letting single_thread_check() run without the kernel lock.
> > > 
> > > The bug might go away if single_thread_check() made sure that
> > > P_SUSPSINGLE is set before the thread suspends. 
> > 
> > Below is an updated patch for testing. It extends the scope of
> > SCHED_LOCK() so that there are fewer chances of interleaving of
> > single_thread_set() and single_thread_check().  
> 
> Many thanks for these patches. I'll try to test in the next couple of
> days. Though the last time i built an OpenBSD kernel was well over a
> decade ago, so it might take me a little longer.

I managed to build a patched kernel, and it seems to fix the problem -
i haven't been able to get egdb into an uninterruptable wait state.

Also, i've been running the patched kernel all day now and it doesn't
seem to be causing any problems elsewhere.

Thanks,

- Jules

-- 
http://op59.net

ksh very slow compared to bash when running ghostscript's ./configure script

[Julian Smith]

It looks like ksh runs much slower than bash with current Ghostscript's
./configure script - for me it takes 20m, compared with 45s under bash.

This is on OpenBSD 6.7 GENERIC.MP#1 amd64. [This kernel has visa@'s
wait4() patch (see recent 'gdb in uninterruptible wait' thread), but
the same problem also occurred last week with the release kernel,
GENERIC.MP#182).]

To reproduce:

git clone https://git.ghostscript.com/ghostpdl.git
cd ghostpdl
AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 CONFIGURE_STYLE=gnu ./autogen.sh

This runs things like autoreconf, then does ./configure. It takes 20m
on my machine, seemingly getting stuck for a a long time after
outputting 'checking compiler/linker address santizer build warnings
support...' and consuming 80% cpu.


Modifying autogen.sh to use /usr/local/bin/bash instead of ksh when
running ./configure, like this:


diff --git a/autogen.sh b/autogen.sh
index 7a0783623..2f6624b10 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -50,4 +50,4 @@ else
echo "running ./configure $@"
 fi
 
-$srcdir/configure "$@" && echo
+/usr/local/bin/bash $srcdir/configure "$@" && echo


- results in the above ./autogen.sh command completing in about 45s for
me. (this is with a clean tree again.)

I don't know what's causing this. Is there some algorithm inside ksh
that could be running into complexity issues somehow?


[A colleague reports that ksh on Linux doesn't run slowly. But i guess
ksh has diverged a lot on OpenBSD/Linux, so that's perhaps not too
surprising.]


Thanks,

- Jules


-- 
http://op59.net

Re: gdb in uninterruptible wait

[Julian Smith]

On Mon, 20 Jul 2020 15:26:11 +
Visa Hankala  wrote:

> On Mon, Jul 20, 2020 at 04:35:12AM +, Visa Hankala wrote:
> > On Sun, Jul 19, 2020 at 09:47:54PM +0100, Julian Smith wrote:  
> > > I've been finding egdb and gdb rather easily get stuck in an
> > > uninterruptible wait, e.g. when running the 'next' command after
> > > hitting a breakpoint.

[...]

> > The single-thread check done by wait4() is non-interruptible.
> > When the debugger gets stuck, is it blocked in "suspend" state?

ps reports it to be in state 'D'.

> > 
> > However, I think there is a bug in the single-thread switch code.
> > It looks that ps_singlecount can be decremented too much. This
> > probably is a regression of making ps_singlecount unsigned and
> > letting single_thread_check() run without the kernel lock.
> > 
> > The bug might go away if single_thread_check() made sure that
> > P_SUSPSINGLE is set before the thread suspends.   
> 
> Below is an updated patch for testing. It extends the scope of
> SCHED_LOCK() so that there are fewer chances of interleaving of
> single_thread_set() and single_thread_check().

Many thanks for these patches. I'll try to test in the next couple of
days. Though the last time i built an OpenBSD kernel was well over a
decade ago, so it might take me a little longer.

Thanks,

- Jules


> 
> One problem is that once single_thread_set() sets ps_single, the other
> threads can enter the suspension code in single_thread_check(). The
> extended lock scope prevents the threads from taking action before
> single_thread_set() has finished with the state updates.
> 
> Index: kern/kern_sig.c
> ===
> RCS file: src/sys/kern/kern_sig.c,v
> retrieving revision 1.258
> diff -u -p -r1.258 kern_sig.c
> --- kern/kern_sig.c   15 Jun 2020 13:18:33 -  1.258
> +++ kern/kern_sig.c   20 Jul 2020 13:29:50 -
> @@ -1915,16 +1915,17 @@ single_thread_check(struct proc *p, int 
>   return (EINTR);
>   }
>  
> + SCHED_LOCK(s);
>   if (atomic_dec_int_nv(>ps_singlecount)
> == 0) wakeup(>ps_singlecount);
>   if (pr->ps_flags & PS_SINGLEEXIT) {
> + SCHED_UNLOCK(s);
>   KERNEL_LOCK();
>   exit1(p, 0, 0, EXIT_THREAD_NOCHECK);
> - KERNEL_UNLOCK();
> + /* NOTREACHED */
>   }
>  
>   /* not exiting and don't need to unwind, so
> suspend */
> - SCHED_LOCK(s);
>   p->p_stat = SSTOP;
>   mi_switch();
>   SCHED_UNLOCK(s);
> @@ -1950,7 +1951,7 @@ single_thread_set(struct proc *p, enum s
>  {
>   struct process *pr = p->p_p;
>   struct proc *q;
> - int error;
> + int error, s;
>  
>   KERNEL_ASSERT_LOCKED();
>   KASSERT(curproc == p);
> @@ -1974,26 +1975,22 @@ single_thread_set(struct proc *p, enum s
>   panic("single_thread_mode = %d", mode);
>  #endif
>   }
> + SCHED_LOCK(s);
>   pr->ps_singlecount = 0;
>   membar_producer();
>   pr->ps_single = p;
>   TAILQ_FOREACH(q, >ps_threads, p_thr_link) {
> - int s;
> -
>   if (q == p)
>   continue;
>   if (q->p_flag & P_WEXIT) {
>   if (mode == SINGLE_EXIT) {
> - SCHED_LOCK(s);
>   if (q->p_stat == SSTOP) {
>   setrunnable(q);
>   atomic_inc_int(>ps_singlecount);
>   }
> - SCHED_UNLOCK(s);
>   }
>   continue;
>   }
> - SCHED_LOCK(s);
>   atomic_setbits_int(>p_flag, P_SUSPSINGLE);
>   switch (q->p_stat) {
>   case SIDL:
> @@ -2027,8 +2024,8 @@ single_thread_set(struct proc *p, enum s
>   signotify(q);
>   break;
>   }
> - SCHED_UNLOCK(s);
>   }
> + SCHED_UNLOCK(s);
>  
>   if (mode != SINGLE_PTRACE)
>   single_thread_wait(pr, 1);
> 
> 



-- 
http://op59.net

gdb in uninterruptible wait

[Julian Smith]

I've been finding egdb and gdb rather easily get stuck in an
uninterruptible wait, e.g. when running the 'next' command after
hitting a breakpoint.

So it's not possible to kill the debuggee or gdb and the only way to
kill the debuggee process and free up its listening sockets seems to be
to reboot the entire system.

Perhaps unsurprisingly one cannot attach a second invocation of gdb to
the uninterruptible gdb, so i don't know for sure what syscall is being
run that is getting stuck.

The debuggee is a local build of the flightgear flight simulator.

Here's the output of ps for the debugger and debuggee:

12419 p0  D0:34.37 egdb -ex handle SIGPIPE noprint nostop -ex set print 
thread-events off -ex set print pretty on -ex run --args 
build-walk/fgfs,clang,debug,opt,co
63921 p0  TX+  0:42.45 
/home/jules/flightgear/build-walk/fgfs,clang,debug,opt,compositor,osg.exe 
--airport=egtk (fgfs,clang,debug)

I've tried using ktrace on egdb, and the kdump output ends like this:

 53950 egdb CALL  wait4(WAIT_ANY,0x7f7e8efc,0<>,0)
 53950 egdb RET   wait4 97562/0x17d1a
 53950 egdb CALL  ptrace(PT_GET_PROCESS_STATE,97562,0x7f7e8ef0,12)
 53950 egdb RET   ptrace 0
 53950 egdb CALL  ptrace(PT_GETREGS,161560,0x7f7e8b40,0)
 53950 egdb RET   ptrace 0
 53950 egdb CALL  
futex(0x6444e37c490,0x82,1,0,0)
 53950 egdb RET   futex 0
 53950 egdb CALL  
futex(0x644bef12740,0x82,1,0,0)
 53950 egdb RET   futex 0
 53950 egdb CALL  ptrace(PT_IO,97562,0x7f7e8a30,0)
 53950 egdb RET   ptrace 0
 53950 egdb CALL  ptrace(PT_IO,97562,0x7f7e8a30,0)
 53950 egdb RET   ptrace 0
 53950 egdb CALL  ptrace(PT_STEP,97562,0x1,0)
 53950 egdb RET   ptrace 0
 53950 egdb CALL  read(6,0x7f7e9187,0x1)
 53950 egdb RET   read -1 errno 35 Resource temporarily unavailable
 53950 egdb CALL  poll(0x6441581e720,3,0)
 53950 egdb STRU  struct pollfd [3] { fd=4, events=0x1, revents=0<> 
} { fd=6, events=0x1, revents=0<> } { fd=10, events=0x1, 
revents=0<> }
 53950 egdb RET   poll 0
 53950 egdb CALL  wait4(WAIT_ANY,0x7f7e8efc,0<>,0)

Assuming that this is the actual end of the ktrace output and there
isn't some missing ktrace output in a buffer somewhere, this looks
like egdb is simply blocked in wait4(), which should be harmless and
certainly not uninterruptable?

Does anyone have any suggestions about how to investigate this further?

I'm running OpenBSD 6.7 GENERIC.MP#182 amd64.

Thanks,

- Jules

-- 
http://op59.net

backtrace_symbols() not showing line numbers, and small patch for backtrace.3 manpage.

[Julian Smith]

For me, backtrace_symbols() does not show line-numbers. Is this the
intended behaviour?

I'm using:
OpenBSD jules-obsd 6.7 GENERIC.MP#182 amd64
libexecinfo-0.3p2v0

With 'cc -g -Wl,--export-dynamic', i'm getting backtraces like:

0x69854ee369  at ./foo.c.exe
0x69854ee477  at ./foo.c.exe
0x69854ee4be  at ./foo.c.exe
0x69854ee13b <__start+315> at ./foo.c.exe

[gdb can show line numbers on the same executable, so the information
is definitely in the executable somewhere.]

I'm testing with this code:


#include 
#include 
#include 
#include 

void bar()
{
void*   bt[20];
char**  strings;
int i;
int d;

d = backtrace(bt, sizeof(bt) / sizeof(bt[0]));
if (d == -1)
errx(1, "backtrace");

strings = backtrace_symbols(bt, d);

if (strings == NULL)
errx(1, "backtrace_symbols");

for (i = 0; i < d; i++)
printf("%s\n", strings[i]);

free(strings);
}

void foo(void)
{
bar();
}

int main(void)
{
foo();
return 0;
}
===

Build with:
cc -g -o foo.c.exe foo.c -I /usr/local/include -g -L /usr/local/lib
-lexecinfo -Wl,--export-dynamic

Run:
./foo.c.exe

Output:
0x69854ee369  at ./foo.c.exe
0x69854ee477  at ./foo.c.exe
0x69854ee4be  at ./foo.c.exe
0x69854ee13b <__start+315> at ./foo.c.exe




Also, here's a small diff for /usr/local/man/man3/backtrace.3, which
makes the code example more directly usable and fixes a misprint of
'\n':

--- /usr/local/man/man3/backtrace.3 Fri May  8 19:49:25 2020
+++ backtrace.3 Fri Jul 17 11:09:15 2020
@@ -63,14 +63,17 @@
 The following code fragment illustrates the use of the backtrace
 functionality:
 .Bd -literal -offset indent
+#include 
+#include 
+
 void
 print_backtrace(void)
 {
-   void*bt[BT_MAX_DEPTH];
+   void*bt[20];
char**strings;
int i, d;
 
-d = backtrace(bt, BT_MAX_DEPTH);
+d = backtrace(bt, sizeof(bt) / sizeof(bt[0]));
if (d == -1)
errx(1, "backtrace");
 
@@ -80,7 +83,7 @@
errx(1, "backtrace_symbols");
 
for (i = 0; i < d; i++)
-   printf("%s\n", strings[i]);
+   printf("%s\\n", strings[i]);
 
free(strings);
 }

Thanks,

- Jules

-- 
http://op59.net

Re: OpenBSD VPS hoster with unlimited/limited nonfiltered traffic

[Oliver Leaver-Smith]

I run a few OpenBSD servers on vultr. They block outbound 25 by default like 
most providers, but as long as you say you aren’t going to spam, they open it 
for you no problem. 1000GB bandwidth on smaller VPS, 6000 on larger ones

-ols
--
Oliver Leaver-Smith
+44(0)114 360 1337
TZ=Europe/London

> On 10 Apr 2020, at 10:52, Martin  wrote:
> 
> I'm looking for relatively cheap VPS with OpenBSD installation support and 
> with ~1Tb of unfiltered traffic. In any words all in/out VPS ports must be 
> opened by default.
> Any recommendations?
> 
> Martin.

Re: Tools for writers

[Oliver Leaver-Smith]

Thanks everyone for recommendations, I think I am just going to use VimOutliner 
for development and outlining. The use case I have is for a novel which should 
require less formatting than a technical book, so I should be able to retrofit 
that after once I have investigated the many tools mentioned in the thread. 

-ols
--
Oliver Leaver-Smith
+44(0)114 360 1337
TZ=Europe/London

Re: Tools for writers

[Oliver Leaver-Smith]

>>> On 2 Nov 2019, at 19:17, STeve Andre'  wrote:
>>>> On 2019-11-02 15:07, Antoine Jacoutot wrote:
>>>>> On Sat, Nov 02, 2019 at 03:04:34PM -0400, STeve Andre' wrote:
>>>> /usr/bin/vi
>>> You obviously never wrote a book.
>>> At least not with the requirements OP asked for. >
>> Actually, I am, right now.  I've found that "formatting" is an
>> annoyance, when writing material.  Get it written, *then* worry
>> about how it looks.  I've done this for more than 40 years when
>> creating documents, reports and such for work.
>> 
>> --STeve Andre'
> 
> I’m inclined to agree with you STeve. For the “writing words in a document” 
> part, nothing beats a distraction-free experience that vi provides. For 
> avoidance of doubt, my query was more around supporting the writing process 
> (outlining, character development) and the formatting (like you say, an after 
> thought most often)
> 
> ~ols
> --
> Oliver Leaver-Smith
> +44(0)114-360-1337
> TZ=Europe/London

Tools for writers

[Oliver Leaver-Smith]

Hello,

What tools do people find useful for writing on OpenBSD? By writing I mean long 
form such as novels and technical books, including plot and character 
development, outlining, and formatting for publishing (not all the same 
application necessarily)

I have found a number which boast Linux support, but not really anything that 
stands out which supports OpenBSD (aside from the obvious LaTeX et al.)

Mich appreciated

 ~ols
--
Oliver Leaver-Smith
+44(0)114-360-1337
TZ=Europe/London

Re: SIGBUS in flightgear / qt / libexpat

[Julian Smith]

Apologies, it turns out that flightgear is in ports.

I'm afraid i didn't think to check as i'd never seen mention of OpenBSD
in the various flightgear lists.

Thanks to Bodie and Zé for emailing me about this, and apologies again
for the noise.

I'm going to have a look at the ports build, flightgear-2016.3.1p4, and
see whether i can make it build a later flightgear.

Thanks,

- Jules


On Sat, 10 Aug 2019 13:55:54 +0100
Julian Smith  wrote:

> I've been trying to build and run the open source flight simulator
> flightgear (https://flightgear.org) on OpenBSD.
> 
> Slightly to my surprise, getting it to build wasn't too difficult.
> 
> But i'm getting a SIGBUS at early on at runtime in code called by Qt.
> 
> I'm unsure how to go about investigating this, so i wonder whether
> anyone here might have come across something similar?
> 
> Here's some info from gdb:
> 
> Backtrace:
> 
> Program received signal SIGBUS, Bus error.
> [Switching to thread 412399]
> 0x07f0523be1a4 in __llvm_retpoline_r11 () from /usr/lib/libexpat.so.12.0
> Current language:  auto; currently minimal
> (gdb) bt
> #0  0x07f0523be1a4 in __llvm_retpoline_r11 () from 
> /usr/lib/libexpat.so.12.0
> #1  0xfffaf8fe in ?? ()
> #2  0x07f0523c1241 in XML_ParseBuffer (parser=Variable "parser" is not 
> available.
> ) at /usr/src/lib/libexpat/lib/xmlparse.c:1740
> #3  0x07f0ee63c4ba in IA__FcConfigParseAndLoad (config=0x7f073cbbe00, 
> name=0x0, complain=1)
> at 
> /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcxml.c:3350
> #4  0x07f0ee641497 in FcInitLoadOwnConfig (config=0x7f073cbbe00) at 
> /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcinit.c:80
> #5  0x07f0ee641730 in IA__FcInitLoadConfigAndFonts () at 
> /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcinit.c:160
> #6  0x07f0ee635edc in FcConfigInit () at 
> /usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fccfg.c:46
> #7  0x07f0c4c82891 in QFontconfigDatabase::populateFontDatabase () from 
> /usr/local/lib/qt5/libQt5XcbQpa.so.1.2
> #8  0x07f107348bc5 in _ZL12initializeDbv () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #9  0x07f107349821 in QFontDatabase::findFont () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #10 0x07f10734ae74 in QFontDatabase::load () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #11 0x07f10730ae65 in QFontPrivate::engineForScript () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #12 0x07f10733f75f in QFontMetricsF::leading () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #13 0x07f10752c843 in qt_format_text () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #14 0x07f10752fb3d in qt_format_text () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #15 0x07f10733eab6 in QFontMetrics::boundingRect () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #16 0x07f10733eb83 in QFontMetrics::size () from 
> /usr/local/lib/qt5/./libQt5Gui.so.2.2
> #17 0x07f056f07b3e in QPushButton::sizeHint () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #18 0x07f056ca1c4e in QWidgetItemV2::updateCacheIfNecessary () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #19 0x07f056ca2319 in QWidgetItemV2::maximumSize () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #20 0x07f056c892df in QBoxLayoutPrivate::setupGeom () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #21 0x07f056c8a6c7 in QBoxLayout::sizeHint () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #22 0x07f056c8a726 in non-virtual thunk to QBoxLayout::sizeHint() const 
> () from /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #23 0x07f056c9ac2c in QLayout::totalSizeHint () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #24 0x07f056cc7438 in QWidget::sizeHint () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #25 0x07f056ca1c4e in QWidgetItemV2::updateCacheIfNecessary () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #26 0x07f056ca2259 in QWidgetItemV2::minimumSize () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #27 0x07f056c962ac in QGridBox::minimumSize () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #28 0x07f056c904cc in QGridLayoutPrivate::setupLayoutData () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #29 0x07f056c914e0 in QGridLayoutPrivate::findSize () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #30 0x07f056c91853 in QGridLayoutPrivate::minimumSize () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #31 0x07f056c93fbe in QGridLayout::minimumSize () from 
> /usr/local/lib/qt5/./libQt5Widgets.so.2.2
> #32 0x07f056c9aae6 in QLayout::totalMinimumSize () from 
> /usr/local/lib/qt5/./libQt5Widgets

SIGBUS in flightgear / qt / libexpat

[Julian Smith]

I've been trying to build and run the open source flight simulator
flightgear (https://flightgear.org) on OpenBSD.

Slightly to my surprise, getting it to build wasn't too difficult.

But i'm getting a SIGBUS at early on at runtime in code called by Qt.

I'm unsure how to go about investigating this, so i wonder whether
anyone here might have come across something similar?

Here's some info from gdb:

Backtrace:

Program received signal SIGBUS, Bus error.
[Switching to thread 412399]
0x07f0523be1a4 in __llvm_retpoline_r11 () from /usr/lib/libexpat.so.12.0
Current language:  auto; currently minimal
(gdb) bt
#0  0x07f0523be1a4 in __llvm_retpoline_r11 () from /usr/lib/libexpat.so.12.0
#1  0xfffaf8fe in ?? ()
#2  0x07f0523c1241 in XML_ParseBuffer (parser=Variable "parser" is not 
available.
) at /usr/src/lib/libexpat/lib/xmlparse.c:1740
#3  0x07f0ee63c4ba in IA__FcConfigParseAndLoad (config=0x7f073cbbe00, 
name=0x0, complain=1)
at 
/usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcxml.c:3350
#4  0x07f0ee641497 in FcInitLoadOwnConfig (config=0x7f073cbbe00) at 
/usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcinit.c:80
#5  0x07f0ee641730 in IA__FcInitLoadConfigAndFonts () at 
/usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fcinit.c:160
#6  0x07f0ee635edc in FcConfigInit () at 
/usr/xenocara/lib/fontconfig/src/../../../dist/fontconfig/src/fccfg.c:46
#7  0x07f0c4c82891 in QFontconfigDatabase::populateFontDatabase () from 
/usr/local/lib/qt5/libQt5XcbQpa.so.1.2
#8  0x07f107348bc5 in _ZL12initializeDbv () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#9  0x07f107349821 in QFontDatabase::findFont () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#10 0x07f10734ae74 in QFontDatabase::load () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#11 0x07f10730ae65 in QFontPrivate::engineForScript () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#12 0x07f10733f75f in QFontMetricsF::leading () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#13 0x07f10752c843 in qt_format_text () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#14 0x07f10752fb3d in qt_format_text () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#15 0x07f10733eab6 in QFontMetrics::boundingRect () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#16 0x07f10733eb83 in QFontMetrics::size () from 
/usr/local/lib/qt5/./libQt5Gui.so.2.2
#17 0x07f056f07b3e in QPushButton::sizeHint () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#18 0x07f056ca1c4e in QWidgetItemV2::updateCacheIfNecessary () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#19 0x07f056ca2319 in QWidgetItemV2::maximumSize () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#20 0x07f056c892df in QBoxLayoutPrivate::setupGeom () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#21 0x07f056c8a6c7 in QBoxLayout::sizeHint () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#22 0x07f056c8a726 in non-virtual thunk to QBoxLayout::sizeHint() const () 
from /usr/local/lib/qt5/./libQt5Widgets.so.2.2
#23 0x07f056c9ac2c in QLayout::totalSizeHint () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#24 0x07f056cc7438 in QWidget::sizeHint () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#25 0x07f056ca1c4e in QWidgetItemV2::updateCacheIfNecessary () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#26 0x07f056ca2259 in QWidgetItemV2::minimumSize () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#27 0x07f056c962ac in QGridBox::minimumSize () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#28 0x07f056c904cc in QGridLayoutPrivate::setupLayoutData () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#29 0x07f056c914e0 in QGridLayoutPrivate::findSize () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#30 0x07f056c91853 in QGridLayoutPrivate::minimumSize () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#31 0x07f056c93fbe in QGridLayout::minimumSize () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#32 0x07f056c9aae6 in QLayout::totalMinimumSize () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#33 0x07f056c9a440 in QLayout::activate () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#34 0x07f056cc6c90 in QWidget::setVisible () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#35 0x07f056f99e70 in QDialog::setVisible () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#36 0x07f056cc5bb4 in QWidget::show () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
#37 0x07f056f9919f in QDialog::exec () from 
/usr/local/lib/qt5/./libQt5Widgets.so.2.2
Die: DW_TAG_ (abbrev = 96, offset = 86893594)
has children: FALSE
attributes:
DW_AT_type (DW_FORM_ref4) constant ref: 86886052 (adjusted)
Dwarf Error: Cannot find type of die [in module 
/home/jules/flightgear/download_and_compile1/install/flightgear/bin/fgfs]
(gdb) 

Threads:

(gdb) info threads
  7 thread 164008  futex () at -:3
  6 thread 558994  futex () at -:3
  5 thread 487113  

TCP wrapper alternative?

[Thomas Smith]

Hi,

I'm considering an option to evaluate connecting IPs before they're evaluated 
by `pf` in order to make some decisions about the "reputation" of a connecting 
IP. Then if that reputation is low enough, some action could either be taken: 
in `pf` to protect the associated application (say by blocking the connection); 
or in the app responsible for the listening port. 

`pf`, unfortunately, isn't able to make routing decisions based on external 
factors (insofar as I understand)--I'm hoping to add some additional (very 
simple) intelligence to that. Just another metric or two for determining if a 
connection is legitimate.

I've been looking into TCP wrappers for OpenBSD but it seems that this 
functionality was removed in version 5. Is my understanding of that correct?

If so, is there an alternate way to achieve what I mentioned?

I know I can use something like sshguard or fail2ban, but I'm looking for a 
much simpler option and one that preferably doesn't rely on tailing log files 
(if there aren't viable alternatives, I may consider these, however). 

~ Tom

Passing %A to spamd.conf exec method

[Thomas Smith]

Hi,

I’m testing a script for spamd’s exec method. In order for the script to work, 
it needs the IP address from spamd.

I tried passing %A to it but that doesn’t seem to work:

module:\
:black:\
:msg="Your address %A was found in module\n\
See blah for details":\
:method=exec:\
:file=/home/user/module/module.py %A:

But this doesn’t seem to be working as nothing is being blocked by this, even 
though nixspam includes the same IP in its list. I have list order set to:

:module:nixspam:

Is there a way to do what I described above?

~ Tom

6.5 stable 'make build' fails in cvs doc

[Allen Smith]

Hi All,

Likely something in my setup as /usr/src and /usr/obj are NFS mounts, but
curious if anyone has any thoughts on what might cause this?

Making all in doc
sed 's,@VERSION\@,1.11.1p1,g' /usr/src/gnu/usr.bin/cvs/doc/CVSvn.texi.in
>/usr/src/gnu/usr.bin/cvs/doc/CVSvn.ttexi/usr/src/gnu/usr.bin/cvs/doc/
cd /usr/src/gnu/usr.bin/cvs &&  true --gnu  doc/Makefile
/bin/sh: cannot create /usr/src/gnu/usr.bin/cvs/doc/CVSvn.ttexi: Permission
denied
*** Error 1 in gnu/usr.bin/cvs/obj/doc (Makefile:467 'CVSvn.texi')
*** Error 1 in gnu/usr.bin/cvs/obj (Makefile:209 'all-recursive')
*** Error 2 in gnu/usr.bin/cvs/obj (Makefile:152 'all')
*** Error 2 in gnu/usr.bin/cvs (Makefile.bsd-wrapper:18 'all')
*** Error 2 in gnu/usr.bin (:48 'all')
*** Error 2 in gnu (:48 'all')
*** Error 2 in . (:48 'all')
*** Error 2 in . (Makefile:95 'do-build')
*** Error 2 in /usr/src (Makefile:74 'build')

Thanks,
-Allen

Re: HTTP SITE DOES NOT REDIRECT

[Oliver Leaver-Smith]

> On 6 Mar 2019, at 06:48, Kihaguru Gathura  wrote:
> 
> is this error justifiable considering the above configuration?

If you curl the http site yourself do you get a 302 to https? If yes, then it’s 
their problem.

Re: Which really small, portable and lightweight system/device is usable running OpenBSD?

[Oliver Leaver-Smith]

This post on misc has further details on GPD Pocket support: 
https://marc.info/?l=openbsd-misc=153582446230820=2
leaversmith.com/privacy

Re: Which really small, portable and lightweight system/device is usable running OpenBSD?

[Oliver Leaver-Smith]

I still have not found a reason to upgrade from my Thinkpad X61s, which has the 
added benefit of having a 4:3 aspect ratio screen too

I get about 5hrs battery life under normal use, which for me is work in the 
terminal and light browsing

It really depends on how small and lightweight you want, as I believe the GPD 
Pocket works apart from sound, suspend, wireless, and a couple of other minor 
bits

leaversmith.com/privacy

Re: Downloadable CIDR network calculator

[Oliver Leaver-Smith]

On Tue, Sep 11, 2018 at 12:39:03PM -0400, Steve Litt wrote:

> The preceding might bring up Python 2.7, which wouldn't work. If
> there's a similar environment variable that either brings up the
> Python3 executable, or nothing at all, that would be better.

Ah yes, apologies for my oversight there, I have `python` symlinked
to python3

`#!/usr/bin/env python3` is indeed possible and probably preferred
over the original alternative I mentioned

ols

leaversmith.com/privacy

Re: Downloadable CIDR network calculator

[Oliver Leaver-Smith]

Nice helpful script, thanks. Didn't run off the bat for me as it expects 
python3 in /usr/bin/

`#!/usr/bin/env python` is more portable 

ols

leaversmith.com/privacy

Re: PF rule - am I being stupid ?

[Bob Smith]

> I think it is caused by the packets blocked having the RST flag set -- a
> consequence of specifying "flags S/SA" in rule @39. Check out man
> pf.conf. Look for section about "flags a/b | any" (line 317 here).

The S/SA wasn't set explicitly my me, its the default.

Out of interest, would this possibly be a PF behaviour change somewhere between 
6.1 and 6.3 ? I'm trying to troubleshoot a VoIP phone that has stopped 
functioning, and the only change has been an upgrade to 6.3.

Re: Equipment for OBSD based firewall

[Bob Smith]

I am a big fan of Decisio (https://www.deciso.com/product-catalog/)

Yes, it comes out of the box with "another BSD" preloaded, but you can easily 
take care of that in a few minutes courtesy of a USB console and a USB key with 
Mr de Raadt's opus magnum on it. ;-)




‐‐‐ Original Message ‐‐‐
On September 4, 2018 12:17 AM, Bogdan Kulbida  wrote:

> Ladies and gentlemen,
>
> I need to build a pf OBSD firewall for a small office. What minimally
> feasible equipment would you recommend in order to achieve this goal?
>
> Thank you!
>
> ---
>
> Best regards,
> Bogdan Kulbida
> Founder and CEO, Konstankino LLC http://konstankino.com
> +1.802.793.8295

PF rule - am I being stupid ?

[Bob Smith]

Hi,

I'm banging my head against a brick wall here trying to figure out why PF (on 
OpenBSD 6.3) is allowing some packets but blocking others ?

Here's the tcpdump:
Sep 05 18:07:45.084191 rule 39/(match) pass in on vlan108: 192.0.2.150.49156 > 
198.51.100.158.20001: udp 47
Sep 05 18:07:45.084220 rule 39/(match) pass out on em2: 192.0.2.150.49156 > 
198.51.100.158.20001: udp 47
Sep 05 18:08:01.136633 rule 39/(match) pass in on vlan108: 192.0.2.150.49157 > 
198.51.100.158.69: 47 RRQ "MainIp5340e.bin"
Sep 05 18:08:01.136661 rule 39/(match) pass out on em2: 192.0.2.150.49157 > 
198.51.100.158.69: 47 RRQ "MainIp5340e.bin"
Sep 05 18:08:25.607885 rule 11/(match) block in on vlan108: 192.0.2.150.6998 > 
198.51.100.158.6801: R 16764161:16764161(0) ack 209207857 win 4224 [tos 0x60]
Sep 05 18:08:27.919688 rule 11/(match) block in on vlan108: 192.0.2.150.6978 > 
198.51.100.158.6802: R 17473283:17473283(0) ack 3296254713 win 4224 [tos 0x60]
Sep 05 18:08:32.594889 rule 11/(match) block in on vlan108: 192.0.2.150.6930 > 
198.51.100.158.6800: R 18671363:18671363(0) ack 3527351279 win 4224 [tos 0x60]

Here are the rules concerned:
@11 block drop log all
@39 pass log quick inet from 192.0.2.150 to 198.51.100.158 flags S/SA

Ultra-portable laptops

[Oliver Leaver-Smith]

Hello

What’s the current landscape for OpenBSD regarding support for 
ultra-portable/pocketable laptops? I’m classing ~7” screen in this category, 
such as the GPD Pocket. 

Does anyone have experience with getting OpenBSD running on such a device?

I understand the limitations of such devices, but as a secondary—or 9th—device 
they’re fine. 

Many thanks,

Oliver
leaversmith.com/privacy

Re: OpenBGPD as route server - correct filter syntax ?

[Bob Smith]

Thanks for your reply.

>
> If you are configuring a route server, you don't want "route-collector yes".
> Or if you want a route collector, it won't advertise any route so your 
> concerns
> are null.


Interesting point. My understanding was that a route server did not make any 
best-path decisions and merely relayed what it was told ? That was my thinking 
behind "route-collector yes".

> This is not needed. Code says (rde_update.c L292) :
>
> if (peer == prefp)
> /* Do not send routes back to sender */
> return (0);
>

That's good news !

OpenBGPD as route server - correct filter syntax ?

[Bob Smith]

Hi,

I'm trying to figure out the most suitable config params transform OpenBGPD 
into a route server.

So far I have :
route-collector yes
transparent-as yes

But my concern is more in the area of suitable filters to prevent loops.

I'm thinking I need something along the lines of :

allow to any peer-as != neighbor-as

But any variation of the above that I try always ends up with a "bgpd -n -f" 
throwing a syntax error.

Ideas most welcome !

Thanks

Bob

Re: x problem after upgrading

[Martin Smith]

On 13/10/2017 15:28, Karel Gardas wrote:

Please add dmesg to your report at all. Also just before 6.2 there was
an update to Intel graphics going in to support KabyLake CPUs. It was
tested quite well and nobody complained. Perhaps you are victim of
this update?

On Fri, Oct 13, 2017 at 3:23 PM, Martin Smith <li...@rakupottery.org.uk> wrote:

I upgraded from 6.1 to 6.2 and I am sure I carried out all the necessary
things that were printed out after it ran, but on attempting to start x I
get the following

uvm_fault(0xd0c544dc, 0xd3a2d000,  0, 1)->e

kernel: page fault trap, code=0

stopped at I915_gem_pwrite_ioctl+0x621:  mov1  0x34(%eax), %eax

ddb>

(all copied out by hand)

and its locked solid, no response to keyboard at all

I must have missed something, can amyone point me in the right direction,
thanks

sorry about that, dmesg below
I dont think I have been bitten by the Kabylake thing, its quite an old 
machine


OpenBSD 6.2 (GENERIC.MP) #166: Tue Oct  3 19:58:05 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
RTC BIOS diagnostic error 11
cpu0: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz ("GenuineIntel" 
686-class) 2.67 GHz
cpu0: 
FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LAHF,PERF,SENSOR

real mem  = 3180867584 (3033MB)
avail mem = 3105812480 (2961MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 08/21/12, BIOS32 rev. 0 @ 0xffea0, SMBIOS rev. 
2.5 @ 0xf0450 (82 entries)

bios0: vendor Dell Inc. version "A14" date 08/21/2012
bios0: Dell Inc. OptiPlex 780
acpi0 at bios0: rev 2
acpi0: TCPA checksum error
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA DMAR SLIC
acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI3(S5) PCI1(S5) 
PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 332MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz ("GenuineIntel" 
686-class) 2.67 GHz
cpu1: 
FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LAHF,PERF,SENSOR

cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz ("GenuineIntel" 
686-class) 2.67 GHz
cpu2: 
FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LAHF,PERF,SENSOR

cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz ("GenuineIntel" 
686-class) 2.67 GHz
cpu3: 
FPU,V86,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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,LAHF,PERF,SENSOR

ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
, remapped to apid 8
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 4 (PCI4)
acpiprt1 at acpi0: bus 2 (PCI2)
acpiprt2 at acpi0: bus 3 (PCI3)
acpiprt3 at acpi0: bus 1 (PCI1)
acpiprt4 at acpi0: bus -1 (PCI5)
acpiprt5 at acpi0: bus -1 (PCI6)
acpiprt6 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(1000@1 mwait.1)
acpicpu1 at acpi0: C1(1000@1 mwait.1)
acpicpu2 at acpi0: C1(1000@1 mwait.1)
acpicpu3 at acpi0: C1(1000@1 mwait.1)
acpibtn0 at acpi0: VBTN
"*pnp0c14" at acpi0 not configured
"PNP0401" at acpi0 not configured
"SMO1200" at acpi0 not configured
bios0: ROM list: 0xc/0xc800! 0xcc800/0x2000! 0xce800/0x1000 
0xcf800/0x800

cpu0: unknown Enhanced SpeedStep CPU, msr 0x0616082206000822
cpu0: using only highest and lowest power states
cpu0: Enhanced SpeedStep 2661 MHz: speeds: 2667, 2000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel Q45 PCIE" rev 0x03: apic 8 int 16
pci1 at ppb0 bus 1
inteldrm0 at pci0 dev 2 function 0 "Intel Q45 Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0: msi
inteldrm0: 1280x1024, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel Q45 Video" rev 0x03 at pci0 dev 2 function 1 not config

x problem after upgrading

[Martin Smith]

I upgraded from 6.1 to 6.2 and I am sure I carried out all the necessary 
things that were printed out after it ran, but on attempting to start x 
I get the following


uvm_fault(0xd0c544dc, 0xd3a2d000,  0, 1)->e

kernel: page fault trap, code=0

stopped at I915_gem_pwrite_ioctl+0x621:  mov1  0x34(%eax), %eax

ddb>

(all copied out by hand)

and its locked solid, no response to keyboard at all

I must have missed something, can amyone point me in the right 
direction, thanks


--

Martin

Re: IPv6 autoconf

[Thomas Smith]

On July 28, 2017 at 3:37:18 PM, Hamza Sheikh (fehr...@codeghar.com) wrote:

I went through the process of creating an OpenBSD-based gateway for my
home network (IPv4 and IPv6). Learned a lot and documented my setup in
a blog post[0]. Maybe it can help troubleshoot your IPv6 setup. Pay
special attention to these sections: (a) cnmac0; (b) dhcp6c; (c) The
"Wrong" Config.

[0] http://codeghar.com/blog/openbsd-network-gateway-on-edgerouter-lite.html


I had been trying wide-dhcpv6—even with no firewall rules enabled, it erred
out—“no route to host” and some other info. I expected that this had to do
with `rtsol` or `inet6 autoconf` not working properly in hostname.em0—but
according to your blog post, it was likely a misconfiguration on my part.

After Mr Archer’s post, instead of giving dhcpcd a shot I tried
isc-dhcp-client—firewall off, it immediately pulled down an ip6 address
from Cox. After making some adjustments to the firewall, it could pull down
one with it enabled as well. Still have a few things to work out now, but
this is a great start!

Thanks for the input guys!

One question…

What would be necessary to bake this functionality into OpenBSD base? IPv6
is pretty ubiquitous nowadays—most ISPs support it, most cloud providers
support it—it seems common enough that much of this functionality should
just work.

I know that “common enough” isn’t a good reason to implement features or
functionality, it just seems like a core capability that should be present.

When I was researching how to set this up, I found many different ways to
do so—some of the information was clearly dated, others not so much. It
would be great to have just configure this via hostname.em0 (or whichever
interface) and have it work.

I’m fairly new to OpenBSD but if there’s something I can do to help with
this, I’m happy to do so if it's within my skillset.

Re: IPv6 autoconf

[Thomas Smith]

On July 27, 2017 at 6:35:23 PM, jungle boogie
(jungleboog...@gmail.com(mailto:jungleboog...@gmail.com)) wrote:

> On 07/27/2017 05:41 PM, Thomas Smith wrote:
> > Hi,
> >
> >
> > Can anyone advise on this please?
> >
>
> What do you see when you do:
> doas sh /etc/netstart

Sanitized output.

% doas sh /etc/netstart
DHCPREQUEST on em0 to 255.255.255.255
DHCPACK from xx.xx.x.x (xx:xx:xx:xx:xx:xx)
bound to  -- renewal in 43199 seconds.

IPv6 autoconf

[Thomas Smith]

Hi,

My ISP (Cox) supports IPv6 and I have this working on a MikroTik
router--it pulls an address and prefix, creates a default route,
creates an address pool for internal clients, etc.

I've been working to configure a similar setup in OpenBSD 6.1 but I've
been unable to even get the outside interface to pull an IPv6 address
from Cox (IPv4 is working properly).

I’ve tried both `inet6 autoconf` and `rtsol` in
/etc/hostname.em0--both have worked in other IPv6 environments I’ve
run OpenBSD in, but neither are working in this context.

Can anyone advise on this please?

Thank you,

~ Tom

Re: Recommendation on OpenBSD host

[Thomas Smith]

Linode works pretty well for me; I understand that some have EC2
working as well, but I’ve not taken the time to try that.

There area a couple of different ways, as well, with Linode to create
base images and speed new server deployments. I personally store my
base images off-line and copy up when I spin up a new VM.

The offer quite a bit of flexibility, and their virtual environment is
all KVM-based now (only legacy VMs are using Xen anymore).

But plan for your own redundancy, backups, etc. This is true with any
provider… But Linode, in particular, doesn’t support live migrations
and such—so if they have server issues and your VM is on that server,
you’re environment would be down otherwise.

On July 25, 2017 at 6:27:47 PM, R0me0 ***
(knight@gmail.com(mailto:knight@gmail.com)) wrote:
> Vultr/Linode I already tested and are good choices.
>
> DigitalOcean - If you used disk encryption, they corrupt your disk

Dynamic IPv6

[Thomas Smith]

My ISP (Cox) supports IPv6 and I have this working on a MikroTik router--it 
pulls an address and prefix, creates a default route, creates an address pool 
for internal client, etc.
I've been working to configure a similar setup in OpenBSD 6.1 and I've been 
unable to even get the outside interface to pull an IPv6 address from Cox.
I've been searching for some time today to find information on how to configure 
this but there are many different "how tos" and not one of them has worked for 
me.
Can anyone point me to some definitive documentation for configuring this in 
OpenBSD? Or advise as to how to set this up?
Seems like it should be a pretty basic thing, but I just can't seem to get it 
right.
I didn't post any sample configs as I've tried many (many) different ways to do 
this today and have removed all of those changes at this point.

Re: FTP during install not working

[Thomas Smith]

> Is the clock on this system correct? OpenBSD 6.1+"s installer uses https
> (at least for architectures which can fit it on the install media) but
> doesn"t handle the case where you have an incorrect clock very well
> (normally the installer tries to fetch the mirror list over https, which
> fails due to invalid OCSP pinning if the clock is more than a couple of
> days out, so you have to type the mirror"s address manually from the
> list on ftp.html and have to use HTTP rather than HTTPS to fetch the
> sets).

I'll check this next install and reply back (I've installed multiple times on 
this same machine and it produces the same issue each time), doing some testing 
before reloading again. Thanks for the suggestion.

> There was an installer bug in 6.1 resulting in the wrong path getting
> written to installurl if you entered the mirror URL manually (this has
> since been fixed). What you did (i.e. editing the file to remove 6.1)
> is the the correct workaround.

Understood. My apologies for posting this to the list--I should've checked it 
first instead of assuming it was part of the same problem.

Re: FTP during install not working

[Thomas Smith]

To add one more thing to this... After the install is completes, I get the 
following error trying to install a package (any package):
$ doas pkg_add zsh
http://ftp.usa.openbsd.org/pub/OpenBSD/6.1/6.1/packages/amd64/: no such dir
Can't find zsh
$ cat /etc/installurl
http://ftp.usa.openbsd.org/pub/OpenBSD/6.1
I edit installurl and remove "6.1" and it works fine.

>  Original Message 
> Subject: FTP during install not working
> Local Time: July 7, 2017 10:16 AM
> UTC Time: July 7, 2017 5:16 PM
> From: inq...@protonmail.com
> To: misc@openbsd.org 
> I'm trying to install OpenBSD 6.1. Selecting the sets location always 
> initially fails with the following:
> Location of sets? (disk http or 'done') [http]
> HTTP proxy URL? (e.g. 'http://proxy:8080', or 'none') [none]
> (Unable to get list from ftp.openbsd.org, but that is OK)
> HTTP Server? (hostname or 'done') ftp.usa.openbsd.org
> Server directory? [pub/OpenBSD/6.1/amd64]
> Unable to connect using https. Use http instead? [no] yes
> It always works fine but only when I manually input the "HTTP Server", and 
> only when using HTTP--HTTPS never works for any mirror, even though I can 
> browse to the given mirror via HTTPS.
> I also dropped to the command line during installation and was unable to 
> connect to ftp.openbsd.org as well, but the alternate above worked fine (as 
> do other mirrors).
> Last time I did a full install was several months ago and the behavior was 
> what I'd expect--the installer downloads the list and provides the 
> appropriate options for mirror selection.
> Please advise.

FTP during install not working

[Thomas Smith]

I'm trying to install OpenBSD 6.1. Selecting the sets location always initially 
fails with the following:
Location of sets? (disk http or 'done') [http]
HTTP proxy URL? (e.g. 'http://proxy:8080', or 'none') [none]
(Unable to get list from ftp.openbsd.org, but that is OK)
HTTP Server? (hostname or 'done') ftp.usa.openbsd.org
Server directory? [pub/OpenBSD/6.1/amd64]
Unable to connect using https. Use http instead? [no] yes
It always works fine but only when I manually input the "HTTP Server", and only 
when using HTTP--HTTPS never works for any mirror, even though I can browse to 
the given mirror via HTTPS.
I also dropped to the command line during installation and was unable to 
connect to ftp.openbsd.org as well, but the alternate above worked fine (as do 
other mirrors).
Last time I did a full install was several months ago and the behavior was what 
I'd expect--the installer downloads the list and provides the appropriate 
options for mirror selection.
Please advise.

dnscrypt-proxy config question

[john smith]

Hello -
How do I config dnscrypt-proxy to use more than 1 resolver?  I understand
how to do theunbound part but what do I put in /etc/rc.conf.local?
Currently I have:
dnscrypt_proxy_flags="-d -E -m 1 -R dnscrypt.eu-dk -a 127.0.0.1:40"

I greatly appreciate any help.

--Doug

Re: Freezing VMs on Bytemark Hosting

[Mark Lee Smith]

Note to self: I shouldn't attempt to reply to emails when I'm tired in the
future. Here is the full dmesg for my host OpenBSD 5.9 -stable running on
vultr, in case it didn't come through in my previous email.

OpenBSD 5.9 (GENERIC) #8: Thu Jul 14 20:12:37 CEST 2016
jas...@stable-59-amd64.mtier.org:
/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC
real mem = 788398080 (751MB)
avail mem = 760397824 (725MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6300 (9 entries)
bios0: vendor SeaBIOS version "rel-1.8.2-0-g33fbe13 by qemu-project.org"
date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Virtual CPU 714389bda930, 2400.39 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOV
BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BM
I1,AVX2,SMEP,BMI2,ERMS,INVPCID,ARAT
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 999MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel
0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <QEMU, QEMU DVD-ROM, 2.5+> ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int
9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address 56:00:00:2d:1c:60
virtio0: apic 0 int 11
virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus2 at vioblk0: 2 targets
sd0 at scsibus2 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct fixed
sd0: 15360MB, 512 bytes/sector, 31457280 sectors
virtio1: apic 0 int 11
virtio2 at pci0 dev 5 function 0 "Qumranet Virtio Memory" rev 0x00
viomb0 at virtio2
virtio2: apic 0 int 10
virtio3 at pci0 dev 6 function 0 "Qumranet Virtio RNG" rev 0x00
viornd0 at virtio3
virtio3: apic 0 int 10
isa0 at pcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 1: density unknown
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
nvram: invalid checksum
uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet"
rev 2.00/0.00 addr 2
uhidev0: iclass 3/0
ums0 at uhidev0: 3 buttons, Z dir
wsmouse1 at ums0 mux 0
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (6d14ab39e519f0a2.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted
clock: unknown CMOS layout


On Sun, 31 Jul 2016 at 01:30 Mark Lee Smith <nety...@gmail.com> wrote:

> Sorry if this message comes as a duplicate, I notice that I didn't CC misc.
>
> Thanks for your response Andrew and Abel.
>
> @Andrew what do you mean by "hangs"? Did the whole machine lock up or was
> it just the network that was down?
>
> @Abel Your dmesg is from OpenBSD 5.7?
>
> Here's the dmesg from OpenBSD 5.9 -stable running on one of the two hosts
> I have on vultr that have been freezing roughly once per week.
>
> This happened again this morning.
>
> Does anyone have any advice on how to proceed and or collect any relevant
> information from the host? I'm available to help as much as possible b

Re: Freezing VMs on Bytemark Hosting

[Mark Lee Smith]

Sorry if this message comes as a duplicate, I notice that I didn't CC misc.

Thanks for your response Andrew and Abel.

@Andrew what do you mean by "hangs"? Did the whole machine lock up or was
it just the network that was down?

@Abel Your dmesg is from OpenBSD 5.7?

Here's the dmesg from OpenBSD 5.9 -stable running on one of the two hosts I
have on vultr that have been freezing roughly once per week.

This happened again this morning.

Does anyone have any advice on how to proceed and or collect any relevant
information from the host? I'm available to help as much as possible but I
don't know where to start.

@Edd It's probably too soon to tell but have you had any luck so far?

OpenBSD 5.9 (GENERIC) #8: Thu Jul 14 20:12:37 CEST 2016
jas...@stable-59-amd64.mtier.org:
/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC
real mem = 788398080 (751MB)
avail mem = 760397824 (725MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6300 (9 entries)
bios0: vendor SeaBIOS version "rel-1.8.2-0-g33fbe13 by qemu-project.org"
date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Virtual CPU 714389bda930, 2400.39 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOV
BE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BM
I1,AVX2,SMEP,BMI2,ERMS,INVPCID,ARAT
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 999MHz
ioapic0 at mainbus0: apid 0

On Fri, 29 Jul 2016 at 15:07 Abel Abraham Camarillo Ojeda <
acam...@verlet.org> wrote:

> On Fri, Jul 29, 2016 at 7:48 AM, Edd Barrett <e...@theunixzoo.co.uk> wrote:
> > On Wed, Jul 27, 2016 at 04:27:00PM +, Mark Lee Smith wrote:
> >> I have a host running OpenBSD 5.9 -stable on Vultr which has been doing
> the
> >> same thing; freezing once a week. Is there any information that I could
> >> provide if/when it happens again?
> >
> > Interesting...
> >
> > Does Vultr use kvm+qemu?
>
> dmesg from vultr attached.
>
> I'm not having problems using it.
>
>
> >
> > At the moment I am trying to narrow down what the freeze could possibly
> > be related to. I really have no idea.
> >
> > I think I am going to throw up another VM and deploy a DEBUG kernel on
> > it, to see if it gives any clues.
> >
> > What have you tried so far btw?
> >
> > --
> > Best Regards
> > Edd Barrett
> >
> > http://www.theunixzoo.co.uk

Re: Freezing VMs on Bytemark Hosting

[Mark Lee Smith]

I have a host running OpenBSD 5.9 -stable on Vultr which has been doing the
same thing; freezing once a week. Is there any information that I could
provide if/when it happens again?

All the best,

Mark

On Tue, 26 Jul 2016, 10:33 Mark Carroll,  wrote:

> On 26 Jul 2016, Edd Barrett wrote:
>
> > I have a support ticket open, but we are not sure if it's an OpenBSD
> > problem, or something on their end. The VM is running 5.9-stable with
> > all patches applied. FWIW, Bytemark uses KVM + Qemu, so this question may
> > extend to ARP networks VMs too(?).
> >
> > Wondering if anyone else here is hosting on Bytemark (or ARP) and had a
> > similar issue, or even a workaround.
>
> I am running vanilla 5.9-stable on Bytemark's BigV, pretty up to date
> with patches, and haven't seen any such problems. Feel free to e-mail
> privately if you want to probe any particular aspects of it.
>
> -- Mark

Re: Syntax error in pf rules

[Adam Smith]

Hi there,

>--- jub...@fastmail.com wrote:
>
>From: Jubjub Jenkins <jub...@fastmail.com>
>To: Adam Smith <ken...@dcemail.com>
>Cc: misc@openbsd.org
>Subject: Re: Syntax error in pf rules
>Date: Wed, 30 Mar 2016 11:25:12 -0700
>
>
>The list owners are fascist anarchists and deem your "democracy" as
>bourgeois.

It's good to know that and that you're one of the fascists raving and 
demonstrating against poor Syrian refugees from war-torn Syria who are trying 
to find refuge in Europe.

People in the Linux community have warned me that there are far-right people 
with extremist views hiding within the OpenBSD community. I won't be surprised 
if you subscribe to the views of Greece's "Golden Dawn", Netherlands' "Partij 
voor de Vrijheid" and Germany's "Pegida" and 

Moreover your writing strongly indicates you're an Islamophobe as well.

In the meantime, please continue to be pro-fascist, anti-democratic and 
Islamophobic in whatever you do.
http://www.DCpages.com