Re: bwfm bcm43569

[Janne Johansson]

Den fre 28 juni 2019 kl 06:45 skrev Joseph Mayer <
joseph.ma...@protonmail.com>:

> point today (due to not using block device multiqueueing and I get the
> impression that the disk/IO subsystem is mostly not parallellized, for
> some usecases also the 3GB buffer cap limit matters).
>

That last point is solved in current,
My box now says:

Memory: Real: 361M/15G act/tot Free: 899M Cache: 14G Swap: 0K/81M

and some go even further:
https://twitter.com/mlarkin2012/status/1136821764959350784

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

Re: SAD ( pkg_add does linux like stuff ie: not working, no explanation )

[Janne Johansson]

Den ons 28 aug. 2019 kl 16:06 skrev sven falempin :

> Maybe obvious ? if so why no message from the software ?
> # pkg_add php_curl
> [URLHERE] php-curl-7.2.17.tgz
>
> 
> LIKE WHY PLEASE ?
>

Given that the difference probably is - versus _ and that last sentence in
all caps, I'd say your problem is that the keyboard gives you shift or
CAPSLOCK at the wrong moments.

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

Re: How can I remove sets installed by sysupgrade?

[Janne Johansson]

>
>  My reasoning behind NOT installing the X, Comp and Game sets have
> little
> to do with saving space, although I am using an 8GB SSD. I learned in my
> research that one of the most fundamental ways to improve network/system
> security is to minimize the attack surface by not installing unneeded
> software. If it isn't installed, any potential vulnerabilities, known or
> not, are irrelevant.
>

What is not irrelevant is the person/program that somehow has a shell on
your box can paste the required 500 bytes of hex data into "openssl base64
-d" to get a binary on your system, so removing the Comp set is one of
those "it would be super hard for me to imagine what I need to run a local
privilege escalation so it must require all these tools" whereas the
hackers that do own other boxes will already have the short_ASM_sequence*
tested locally and only need to get those over the same path the exploit
took in order to get a better foothold on your machine.

So removing comp sets just mean you can't patch locally when a scary
advisory comes out, it also means you need to special-case your sysupgrades
and those two choices will probably mean you will stay vulnerable for a
longer time just because you hoped leaving cc(1),as(1) and battlestar(6)
out of the box will "save" you.

Yes, I can imagine some few scenarios where it might, but as the other
reply you already got says, when you make your own box a surprise to
administer and reason about, you are making it worse already so the
comparisons about what choice is safer doesn't even start from the same
level.

*) SEE ALSO: https://en.wikipedia.org/wiki/SQL_Slammer

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

Re: SCM

[Janne Johansson]

Den mån 22 juli 2019 kl 17:05 skrev Австин Ким :

> Hi,
>
> As someone completely new to OpenBSD the one immediate first impression
> that most peculiarly sticks out like a sore thumb to me is the Project’s
> use of CVS for source code management.   I am curious why the Project
> continues to use CVS and/or if developers have in the past considered
> migrating the codebase to a distributed SCM system like Mercurial which
> IMHO might make branching and merging easier on developers, especially more
> recent developers coming out of universities.  Is it because the Project
> prefers using a centralized versus distributed SCM system?  Or is it just
> because that’s just the way it has always been done and why change that?
> And would migration to something like hg be a possibility in the future
> that might possibly lower the psychological barrier of entry for newer
> developers?  (And btw this is meant as a sincere question with no intention
> to start a contentious debate; really just asking out of curiosity because
> seeing CVS diffs in the mailing lists was what visually jumped out most
> prominently to me for the first time; I’m sure after spending more time
> with OpenBSD it could be something I could just get used to.)
> Thanks for all the wonderful responses to my previous post which really
> helped me gain a better understanding of the Project!
>


As Nick Holland wrote here on the same topic:
https://marc.info/?l=openbsd-misc=136724343006024=2
the last quote is kind of telling it all:
---
Want to sell OpenBSD on an alternative?  Find a product that was really
crappy, switched development tools, and suddenly started rivaling
OpenBSD for quality for no reason other than the switch of development
tools.
---

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

Re: Did I install correctly the openbsd?

[Janne Johansson]

Den ons 10 juli 2019 kl 02:16 skrev SOUL_OF_ROOT 55 :

> I installed openbsd 6.5 in Virtualbox for Windows 7, the following
> screenshots show it:
> I tried to install openbsd according to the following video:
> Did I install correctly the openbsd?
>

Good tip on reporting when things didn't go as planned:
"What did you do, what did you expect would happen, and what happened
instead"
Try that next time.

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

Re: Home NAS

[Janne Johansson]

Den lör 16 nov. 2019 kl 22:49 skrev Karel Gardas :

> > I tried a home NAS with ZFS, then BTRFS. Those filesystems needs tons of
> RAM (~1 GB of RAM by TB of disk), preferably ECC.
>
> For NAS you prefer ECC anyway and 1 GB RAM consumption per 1 TB of drive
> is urban legend probably passed by folks using deduplication.


Or people who do not want to swap while doing extensive fsck of huge
partitions with lots of small files in them.
Most recommendations are based on all corner cases and not just the
happy-case when you stash a single movie on a nas over the home network.

Yes, dedup uses ram most of the time if it can, but other things do too.
Also, "excess" ram in these cases turn into read caches so its not lost on
you either.

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

Re: build error on octeon, 6.6

[Janne Johansson]

Den ons 6 nov. 2019 kl 23:36 skrev Christian Groessler :

> Hi,
> I've installed OpenBSD 6.6 on an EdgeRouter Lite. I wanted to rebuild
> the system.
>
> Maybe the machine has too little memory?
>
> routie$ swapctl -lk
> Device  1K-blocks UsedAvail Capacity  Priority
> /dev/sd0b  22077035824   18494616%0
> routie$
> routie$ sysctl -a | grep physmem
> hw.physmem=536870912
>

A while back when I needed/wanted to build ports-llvm on ERL, I added some
8G of swap over NFS (to an ssd-x86_64 server) which helps with large builds.
Takes ages, but works.

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

Re: build error on octeon, 6.6

[Janne Johansson]

I wonder if this part is relevant:
c++: error: unable to execute command

Is there any permissions on /net that prevents execution?

I seems it wants to run stuff from here:

...
*** Error 254 in
/net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM
(:67 'AMDGPUTargetMachine.o': @c++ -O2 -pipe -...)
*** Error 1 in /net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang


> I've noticed that my /tmp partition might be too small (64M). I'm going
> to reinstall with bigger /tmp (1GB) and try again...
>


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

Re: SIGBUS on octeon for my program

[Janne Johansson]

There was a fix recently for the stack getting unaligned committed just
recently, do you have that?
If not, test on current.


Den ons 27 nov. 2019 kl 14:48 skrev Peter J. Philipp :

> Hi,
>
> My DNS program gets a SIGBUS when I execute it.  I have ktraced it, upped
> limits and searched in the mips64 source for answers, could this be a
> compiler
> problem?
>
> ktrace->
>  41651 dddctl   CALL  connect(6,0xfcacb0,16)
>  41651 dddctl   STRU  struct sockaddr { AF_INET, 192.168.177.2:10053 }
>  41651 dddctl   RET   connect 0
>  41651 dddctl   CALL  kbind(0xfc9b48,24,0x801d30cbade359aa)
>  41651 dddctl   RET   kbind 0
>  41651 dddctl   PSIG  SIGBUS SIG_DFL code BUS_ADRALN<1> addr=0xfca17d
> trapno=0
>  82637 dddctl   RET   wait4 41651/0xa2b3
> <---
>
> The SIGBUS code ADRALN I have found in /sys/arch/mips64/mips64/trap.c
> around
> line 463 on OpenBSD 6.6:
>
> >
> case T_ADDR_ERR_LD+T_USER:  /* misaligned or kseg access */
> case T_ADDR_ERR_ST+T_USER:  /* misaligned or kseg access */
> ucode = 0;  /* XXX should be PROT_something */
> signal = SIGBUS;
> sicode = BUS_ADRALN;
> break;
> <---
>
> I have also set the stack ulimit to 32K but no relief.  I'm stuck,
> wondering
> if you guys can help with interpreting this.
>
> My program can be downloaded with
>
> ftp https://delphinusdns.org/download/snapshot/delphinusdnsd-snapshot.tgz
>
> Where it's remade at midnight CET every day.
>
> As far as I know it should work on macppc although this particular function
> wasn't tested on macppc.  And it works on amd64 as I run this delphinusdnsd
> in production on my personal nameservers.  Getting this working on octeon
> would broaden my test network.
>
> Best Regards,
> -peter
>
>

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

Re: Following patch or stable branch on Octeon

[Janne Johansson]

>
>  I was under impression that original octeon
> (mips64) packages were built on SGI hardware which is no longer
> supported so I was curios about new build machines. I am fully aware
> that mips64 packages are available for 6.6 even though I try to stick
> for most part with tools from the base.
>

Mips64 is the cpu arch, octeon is just one of the implementations of a
mips64 machine, so a package from any mips64 box would work (except
little-endian mips64le ones from loongson).
As for the original question, I do collect a bunch of octeons and go with
-current/snaps on them. The very far-apart breaks I experience are less a
problem than the joy of getting improvements quickly.
Almost all crashes get fixes (or reverts) in a day or so. Also, the more
often you upgrade your snaps, the easier it gets to back a few days worth
of kernel, as opposed to only updating once per year and then finding some
issue (like the sppp stack frame bug in 6.6 for octeons).

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

Re: bad ip cksum 0! -> in enc interface

[Janne Johansson]

Den ons 5 feb. 2020 kl 21:01 skrev Riccardo Giuntoli :

> If i sniff traffic over enc0 interface I found a strange error about ip
> chksum:
>
>  (DF) (ttl 63, id 43164, len 52) (DF) (ttl 64, id 18753, len 72, bad ip
> cksum 0! -> c48a)
> This is the error as you can review.
>
> I cannot find solution in Internet and the real think is that in many
> others post people copy and paste packets and this error is visible but no
> one think that is in effect an error or do not speak about.
>

You often see 0 in packet checksum fields if the packet is heading out on a
device
which claims to do ipv4 checksum offloading in hardware. In such cases, the
OS will
not spend time doing software checksums, but the hardware will do it just
before the
packet leaves for the network, so that is why the software sniffer will see
0 there, but
the remote end (you do look for errors from both ends, right?) will see
something else
there.

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

Re: Process Isolation

[Janne Johansson]

Den tors 6 feb. 2020 kl 10:22 skrev Charlie Burnett :

> Sorry if this has been answered before but I couldn't find a satisfactory
> answer searching for it, and this is more of an academic question. So
> security focused Linux distros like Qubes go to extremes to
> compartmentalize/isolate any and all programs it can. FreeBSD has it's jail
> program which is seemingly the gold standard for process isolation when you
> can't be bothered to go to the extent Qubes does. I've been trying to read
> as much OpenBSD source as I can as I find some of the security tricks
> y'all've come up with damn interesting. I know that once upon a time we had
> sysjail, but nowadays we have just have chroot which most systems do. What
> is OpenBSD's solution to this? I'm sure I've read through it I just didn't
> realize the purpose.
>
> I apologize if this was a question I've somehow missed the answer to!
>

Almost looks like you missed the question while posting the answer.
You list some-linux does X, fbsd does Y, obsd does Z (which you find damn
interesting!) and then ask "what is openbsds solution to this?".

As of now, Z is the list of mitigations openbsd does, and that is.. the
solution to "this".

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

Re: bad ip cksum 0! -> in enc interface

[Janne Johansson]

Den ons 5 feb. 2020 kl 21:01 skrev Riccardo Giuntoli :

> I'm setting up a roadwarrior type ikev2 secure connection from .es to .uk.
> root@ganesha:/etc# cat hostname.enc0
>
> root@smigol:/etc# cat hostname.enc0
> inet 172.16.44.2/32
> up
>

Why are you setting up hostname.enc0?
What guide is recommending you to do that?


> I cannot find solution in Internet and the real think is that in many
> others post people copy and paste packets and this error is visible but no
> one think that is in effect an error or do not speak about.
>

Please set a vpn up like the openbsd faq on IPSec VPNs shows, and take it
from there.
It never mentions adding ip to enc0 (and that is not the purpose of enc0)
so I don't see why you should.

enc(4) is a debug and filtering tool not a config part of vpns.

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

Re: FreeBSD daemon(8)-like command for OpenBSD

[Janne Johansson]

Den fre 31 jan. 2020 kl 11:48 skrev Andrew Easton :

> On Fri, Jan 31, 2020 at 10:47:17AM +0100, Patrick Kristiansen wrote:
> > On Fri, Jan 31, 2020, at 09:29, Janne Johansson wrote:
> > > Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen <
> patr...@tamstrup.dk>:
> > > >  > Properly starting up a daemon process requires several steps,
> > > >  > often involving unveil(2), pledge(2), chroot(2), prviledge
> > > >  > dropping, sometimes fork+exec for privilege separation, and so on
> > > >
> > > >  The process I need to run is written in Clojure and thus runs on the
> > > >  Java Virtual Machine. Do you have any suggestions on how to best go
> > > >  about making it "daemon-like"? I am not sure that I can call
> unveil(2),
> > > >  pledge(2) and chroot(2) from Clojure without some strange sorcery.
>
>
For the record, I am also interested in information on how pledge(2) and
> unveil(2) would interact with a "higher level language".


man OpenBSD::Pledge will show how you call pledge from perl (if you accept
that as a higher level language in this case), and it works mostly because
perl will not silently have tons of secret underlying operations so that
when
you ask perl to concatenate two strings, it will not open sockets and pipe
them to itself in order to do that, or write them to $TEMPDIR or some other
possible construct in order to make a simple operation suddenly require
file system access or socket binding capacity. The more weird (or generic)
your runtime is, the less chances will you get to be able to say "from now
on, I will not open any more files, sockets or call reboot()" because the
runtime may just do one of those, when garbage collecting or something.



> I would also
> be happy to learn more about how they interact with assembly.
>

I'm sure they interact equally well as with C, given that the C program that
calls pledge/unveil at that time is assembler.


> Concretely:
> Just to start off easy, how can I find conceptual documentation on
> what an operating system "process" is in OpenBSD and how deeply a libc
> is tied into that by design? As far as I am aware a process has the
>

libc isn't all that tied to a process, it's just that libc contains some
very neat
and useful functions (like wrapping calloc() over malloc()/mmap() so the
kernel
only exposes one single way for a process to allocate memory, but libc can
still
implement realloc(), calloc() and so on for you, using normal code and the
give-me-some-pages-of-RAM syscall.


> "current working directory" associated with it, in order to be able to
> resolve relative paths and is also where "environment variables" are
> stored.


Well, you can still reach the environment without libc, but libc makes it
easier for you, just like with the something*alloc() routines.


>
> (I am also still fuzzy on how intertwined an operating system and a CPU
> are. From my superficial understanding, e.g.  the operating system has
> to be aware of the MMU.


I think that is a completely separate dimension, but yes, given that the OS
controls and commands the MMU to do various things, it most certainly
is "aware" of it.

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

Re: FreeBSD daemon(8)-like command for OpenBSD

[Janne Johansson]

Den tors 30 jan. 2020 kl 21:08 skrev Patrick Kristiansen <
patr...@tamstrup.dk>:

> > Properly starting up a daemon process requires several steps, often
> > involving unveil(2), pledge(2), chroot(2), prviledge dropping,
> > sometimes fork+exec for privilege separation, and so on
>
> The process I need to run is written in Clojure and thus runs on the
> Java Virtual Machine. Do you have any suggestions on how to best go
> about making it "daemon-like"? I am not sure that I can call unveil(2),
> pledge(2) and chroot(2) from Clojure without some strange sorcery.


So not related to only Clojure but rather on runtimes that are large and
unwieldy,
this seems to be exactly why plegde() and unveil() came into being in
the first place, after seeing things that needs to do certain privileged
operations
at some early point, but because of design/runtime/hard-to-pledge or
whatever has
to run with the sum of all privileges, all capabilities at all times and at
the same time being exposed to potential hostile data.

I can fully see why Ingo would say "I would not run things like that
exposed",
partly because I figure he actually has a choice to not do it, but
regardless
of what electric fences you like (Selinux, capsicum, pledge/unveil, chroots)
if you create a huge monolith running in an environment which actively
prevents you from activating any kinds of protections, then I can see how
you would see some friction.

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

Re: How to hide my server's IP?

[Janne Johansson]

>
> Not sure I understand the whole hierarchy and flatness analogy, I'm very
> new to all of this, but what do I tell those who claim that this leaking of
> the IP poses a security risk and that they therefore should go with FreeBSD
> jails instead?
>

Use a VM if you need to win over "checkboxing security"

And refine the risk strategies, since the above conversation seem to be
centered around the concept of a hacker that

1. Someone successfully attacks your site over the internet, using your
outward facing IP A.A.A.A
2. Manages to run code on your webserver
3. May or may not divinate your internal IP B.B.B.B from that code.
4. The communicates information back to a server of their choice, perhaps
using a third (external) ip C.C.C.C or not

If you think #3 is the only important part, in a scenario where point 1,2
and 4 allows for full communication using the cirtcuit created using
A.A.A.A and C.C.C.C and full code execution inside your environment,
then you are not doing a very good job at risk assessment.

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

Re: How to hide my server's IP?

[Janne Johansson]

Den mån 3 feb. 2020 kl 07:18 skrev Frank Beuth :

> Otherwise it would be possible for an attacker to, for example, hack
> your webapp to have it phone home to some external server controlled by
> the attacker.


..and in the request logs see where the request comes from so this
information is available here,
combined with the ip used for the actual hack. But the existence of
"ifconfig" means nothing to this
scenario, you can blindly send a icmp, udp or tcp packet to
packet-collectors-R-us.com and see the
ip there. There is exactly zero need to first figure out the local ip and
only then send out blind packets
to your collector.


> The attacker would thereby be able to find your IP
> address.
>

By the time your opponent is running code on your server, this piece of
information is probably the least interesting part of the whole puzzle.

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

Re: VLAN or aliases or? best way to isolate untrustable hosts in a small network

[Janne Johansson]

Den ons 5 feb. 2020 kl 13:07 skrev Denis :

> I've made two VLANs to automatically assign random IPs from a pool by
> dhcpd:
>

[...]


> # /etc/hostname.vlan101
> description 'WLAN attached untrusted hosts'
> inet 192.168.156.0/24 255.255.255.0 vlandev run0
>

VLANs and wifi sounds like a non-starter.

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

Re: IPsec and MTU / fragmentation

[Janne Johansson]

Den tis 11 feb. 2020 kl 10:25 skrev Simen Stavdal :

>  tunnel will be able to fragment all incoming ip before sending it into the
> ipsec, which will not fragment for you.
> The clients will not have to change, nor any other protocol that sends ip
> via the double-tunnel.>
>
> If a client and a server set up a new conversation over tcp.
> They both have an MTU of 1500 and DF=1
> How will you fragment this, even being a L3 tunnel?
>

You don't fragment DF=1 packets, you send "Fragmentation Needed and Don't
Fragment was Set" back if they don't fit, like any L3 box would do
regardless and they adapt or fail.
That is what you should get for setting DF=1

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

Re: IPsec and MTU / fragmentation

[Janne Johansson]

Den mån 10 feb. 2020 kl 20:53 skrev Simen Stavdal :

> I think the more complete solution is to run some gif/gre inside ipsec and
>> set low-enough MTU on that one, so it can correctly fragment incoming
>> packets, and optionally rebuild the packets at the remote end, while also
>> giving you an idea of "state" on the link so you optionally can run things
>> like routing daemons or something that cares about and acts on tunnel
>> state. This would cause even lower MTU, but still allow all kinds of
>> traffic and not just the "popular" one.
>>
>
> So, how will your client/server know about this lower mtu? And df bit is
> set more often than not, so fragmentation is now allowed in a lot of cases.
> This is exactly the problem that started this thread...
>
>>
>>
If the inner gif/gre tunnel has a lower mtu, then it being a layer-3 tunnel
will be able to fragment all incoming ip before sending it into the ipsec,
which will not fragment for you.
The clients will not have to change, nor any other protocol that sends ip
via the double-tunnel.

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

Re: IPsec and MTU / fragmentation

[Janne Johansson]

Den mån 10 feb. 2020 kl 18:18 skrev Peter Müller :

> Hello Lucas,
> as far as I understood, setting MTU on encN interfaces is not supported
> since it is not mentioned by enc(4) and setting it manually fails:
>
> > machine# ifconfig enc0 mtu 1500
> > ifconfig: SIOCSIFMTU: Inappropriate ioctl for device
>

enc(4) interfaces are not to ipsec, what tun(4) is for OpenVPN.
It is not a config device per tunnel.

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

Re: IPsec and MTU / fragmentation

[Janne Johansson]

Den mån 10 feb. 2020 kl 11:58 skrev Simen Stavdal :

> Hi Lucas,
> Have you tried to manipulate the mss during conversation setup?
> This is done with the max-mss directive in pf.conf.
> Basically, it takes the three way handshake, and overrides the MSS value in
> the handshake to something lower than the default.
>

This might fix the http/ssh issues one might see, because both of those run
over TCP, but MSS fixups will not correct large UDP or icmp packets, or any
other non-TCP protocol one might run over that ipsec, so making sure the
traffic is below the MTU should be the end goal, not fixing 90% with pf.

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

Re: strange dmesg

[Janne Johansson]

Den lör 8 feb. 2020 kl 11:31 skrev :

> Hi,
> I have some strange output from dmesg, what could be ?
> At the follwoing link I've posted some screenshots:
> https://postimg.cc/gallery/1o4wsaw74/
>

dmesg is contained in a memory buffer with (hopefully) room for more than
one dmesg, so you can get
previous versions listed when you run it. If the memory gets slightly
corrupted during reboots,
I guess the "other" dmesgs can come out as garbage, based on how memory
gets reused or
reallocated in the time between reboot and next boot when the OS isn't in
control of the
RAM.

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

Re: IPsec and MTU / fragmentation

[Janne Johansson]

Den mån 10 feb. 2020 kl 12:15 skrev Simen Stavdal :

> True, but issue was related to downloading over http, which is over tcp.
> So, if http is your only concern I would go for this option.
>

To me, it sounds just a bit like "let this person notice the other errors
later".


> Most clients are configured with an MTU of their physical NIC
> capabilities, and sometimes even with jumbo support.
> MTU is a property of the OS in both ends, while MSS is a property of the
> packets that can be adjusted in-flight.
>
>
MTU is strictly a property of each and every interface in all the hops
between you and your endpoint and equally strictly is mss a property of
_tcp_ packets that can be adjusted. If you run another ipsec inside this
first ipsec tunnel-with-mss-fixed that second one would break, since ESP/AH
is not tcp and will not do the 3way handshake where PF can fix mss for it.
Or mosh, wireguard, or http/3 since they run over UDP.

Not trying to nitpick everything, but internet wasn't built on 1500 MTU
ethernet everywhere, in the old bad days you might go over PPP (576) or
SLIP (296) links at times and it still worked, so if your setups today
break if someone in your path limits you to 1476 or so, then we have
regressed quite a bit since the crap internet days.


> So, if you want to fix the MTU, you will have to configure that on the
> conversation parters and not in pf.
> So, while we agree on the principals, how do you suggest MTU is changed?
>

PMTU discovery would be one method, yes. Middle boxes that will not drop
icmp is part if this of course.


> Statically configured on each host? DHCP option?
>

This depends a bit on where you place your ipsec gw of course, but if you
can't set it on the tunnel (since ipsec on obsd isn't like openvpn or
gif/gre) you might need to set it on the interface where you take in the
traffic, if you can't set it on all clients going via the gw, which is a
believable scenario.


> This might fix the http/ssh issues one might see, because both of those
>> run over TCP, but MSS fixups will not correct large UDP or icmp packets, or
>> any other non-TCP protocol one might run over that ipsec, so making sure
>> the traffic is below the MTU should be the end goal, not fixing 90% with
>> pf.
>>
>

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

Re: IPsec and MTU / fragmentation

[Janne Johansson]

Den mån 10 feb. 2020 kl 16:27 skrev Simen Stavdal :

> This is more a discussion about scalability and practical implementation.
> We both know that PMTU will work partly at best, your entire path back
> must support this, and also, the "offending" client must allow inbound
> control messages on their host firewall for this to work.
> And even if the packets are received by the client, will it support and
> adjust MSS? I have seen a lot of clients not adhering to standards.
>
> Modifying thousands of clients (via dhcp options for instance) to use a
> fixed MTU will affect other applications too (if you choose to go that
> route), not just the ones that need to traverse a tight ipsec tunnel.
> Would you adjust all your clients just because you had a single path using
> SLIP in your network?
>

I would want for noone to ever have to know the complete path, slip or no
slip.


> Point is, there is no perfect solution to this issue, there are just
> different ways of solving bits and bobs on the way.
> Adjust mss will work just fine for all tcp protocols, and no, not for UDP
> because it does not use a three way handshake (no MSS to adjust).
> In my opinion, max-mss works very well in most cases, especially when you
> have full control of the tunnel you are using (as is the case of Lucas'
> original question).
> We use it extensively in many of our applications in my workplace, and as
> of yet has not represented any big issues, so it is a practically good way
> to solve this issue.
>

I think the more complete solution is to run some gif/gre inside ipsec and
set low-enough MTU on that one, so it can correctly fragment incoming
packets, and optionally rebuild the packets at the remote end, while also
giving you an idea of "state" on the link so you optionally can run things
like routing daemons or something that cares about and acts on tunnel
state. This would cause even lower MTU, but still allow all kinds of
traffic and not just the "popular" one.

I am somewhat trying to care for the ones that make a site-2-site ipsec
which may work for the initial setup, and later find out that more than one
non-tcp kind of traffic doesn't work without understanding why ssh,http
works but not list-of-things-like
mosh,wireguard,quic,yet-another-layer-of-ipsec,hosting-udp-game doesn't.

As for UDP, there are options here too in pf.conf (like no-df), but
> personally I have not tested this, but it would be fun to try. It says it
> supports IPv4 (which would include TCP, UDP and ICMP).
> Would be interesting to find if UDP enforces DF in most cases.
>

no-df in PF more or less controls if it will silently drop fragments that
arrive which has DF set. Linux used/uses to send such udp, for much
enjoyment. "noone else should fragment, but I just did and you as the
packet checker can't know who did"

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

Re: Awaiting a diff [was: Re: File systems...]

[Janne Johansson]

Den tors 9 jan. 2020 kl 02:11 skrev Ingo Schwarze :

>
> Are you aware that even Bob Beck@ is seriously scared of some
> parts of our file system code, and of touching some parts of it?
> Yes, this Bob Beck, who isn't really all that easily scared:
>
>   https://www.youtube.com/watch?v=GnBbhXBDmwU
>
> One of our most senior developers, regularly and continuously
> contributing since 1997, and among those who understand our
> file system code best.
>

And here I thought you would post thib@s talk literally named
"Things that makes Bob scream" from the f2k9/Slackathon conf:

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

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

Re: Awaiting a diff [was: Re: File systems...]

[Janne Johansson]

Den fre 10 jan. 2020 kl 10:55 skrev Consus :

> On 20:06 Thu 09 Jan, Marc Espie wrote:
> > It's been that way for ages. But no-one volunteered
> > to work on this.
>
> Anyone even knows about this? Aside from OpenBSD developers (who have
> their plates full already) how an average person can find out that there
> is rusty piece of code that should be taken care of?
>

By using the parts that OpenBSD is made up of, and not automatically moving
to other OSes as soon as you leave the comfort zone.
Guess that is how many ports gets added. $prg exist for $other_os but not
OpenBSD, someone does the work to make it run on OpenBSD and there you go.

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

Re: Compiler warning in ctype.h

[Janne Johansson]

Den fre 6 mars 2020 kl 12:29 skrev Thomas de Grivel :

> Hello,
>
> I was using base gcc but switching to base clang fixes the warnings on
> -current at least.
> Is base gcc not supported anymore ?
>

I think you are supposed to use whatever gets used when you call "cc" on
the OpenBSD platform you are on, and if need be, get gcc from ports for an
uptodate version of it.
Since arches are moving from gcc into clang (at various speeds), its not
unthinkable for some of them to have both over the transition, but the
"supported" one is always the binary that gets run if you use "cc" for
compiler and nothing else.

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

Re: S3 Virge support on IBM T23 for 6.6

[Janne Johansson]

Den ons 15 apr. 2020 kl 23:29 skrev Paolo Aglialoro :

> Is this a hint that soon i386 architecture will be deprecated?
> Considering that supported hw (at least graphics) is going more and more to
> overlap with amd64, at the very end i386 would remain only for some
> routerboards.
>

i386 has seen a fair share of deprecations, from the actual 386 CPUs and
486s without FPU, to machines with 8,16,32,64M ram for whom reordering libs
and kernel isn't really doable with recent OpenBSD releases.

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

Re: List a package's dependencies

[Janne Johansson]

Den mån 20 apr. 2020 kl 15:08 skrev Marc Espie :

> On Sun, Apr 19, 2020 at 04:36:48PM +0200, Ingo Schwarze wrote:
> > Part of that is due to the unavoidable complexity
> > of the system.  Other parts may be influenced by the fact that
> > espie@ is not tedu@.
>
> I don't think tedu would do much better... or we would have a ports tree
> with only the 100 ports he's using, and nothing more.
>

My guess is i stuck running 6.3 on his SH machine:
https://ftp.eu.openbsd.org/pub/OpenBSD/6.3/packages/sh/

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

Re: S3 Virge support on IBM T23 for 6.6

[Janne Johansson]

Den tors 16 apr. 2020 kl 18:24 skrev Paolo Aglialoro :

> Thanks Janne for the tech insight.
> So, but for routerboards/CLI boxen, considering that this recent move
> hinders GUI for most P3s, the really viable ones remain P3s/K7s with
> different graphics boards (mostly desktop/tower) and early P4s without
> em64t.


If there was a huge userbase with tons of GUI i386s needing life support,
then perhaps they
can form a group and do the heavy lifting, since many hands make work light.
If there is one box in a corner with S3 virge, then it can just stop
updating and have a
$25 box firewall it off the internet so you can get away with having it
unpatched where it runs with its GUI.

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

Re: Regarding randomized times in crontab

[Janne Johansson]

Den tors 16 apr. 2020 kl 20:22 skrev Andreas Kusalananda Kähäri <
andreas.kah...@abc.se>:

> On Thu, Apr 16, 2020 at 11:14:59AM -0600, Theo de Raadt wrote:
> > That is a lot of words to cover a simple concept:
> >
> > The specific random values are selected when cron(5) loads
> > the crontab file. New numbers are chosen when crontab -e is used.
> > If you understand that, the conclusions are obvious.
>
> Ah. Good. Then I know the restrictions.  The random times are random,
> but fixed for the lifetime of the cron daemon (or until the crontab is
> reloaded due to being edited).
>

It would be very weird otherwise, if the 24h random example was used, then
it chose 00:01,
ran your "bin/true" command and then re-randomized, it would most certainly
end up wanting
to run again, perhaps twice or more. So if it re-randomized after each
execution
it would have to keep a 24h timer going (in your example, a per-week, a
per-month timer also)
to make sure the newly randomized 11:12 time is actually tomorrows 11:12
and not the upcoming
one in this day. Also, re-randomization would also mean it could start your
one hour backup at 23:59
and once more in 00:01 the next day, which would cause lots of unexpected
chaos for anyone expecting
a daily one-hour job to not collide with itself.

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

Re: socket I/O on openbsd

[Janne Johansson]

You're still not telling what it is, where it came from, what it does.
Noone here can mind read you. We will not admit we can see what is on your
monitor, so .. step up to the challenge and show your work.

https://i.imgur.com/ArfmbAf.gif


Den ons 22 apr. 2020 kl 08:09 skrev Gustavo Rios :

> apx_connect is an wrapper for connect.
> apx_shutdown is an wrapper for shutdown
>
> Em qua., 22 de abr. de 2020 às 02:09, Stuart Longland
>  escreveu:
> >
> > On 22/4/20 11:48 am, Gustavo Rios wrote:
> > > Dear gentleman,
> > >
> > > i have the an ANSI C code that do the following:
> > >
> > > 0. open a socket
> > > 1. write data to the socket
> > > 2. close the writing end of the socket
> > > 3. read data from the socket
> > > 4. close the read end of the socket
> > >
> > > The the step number 4 returns an error, why ?
> > >
> > > Here it is (Only the relevant part of the code )
> > >
> > > if (!r) r = apx_connect(s, );
> > > if (!r) r = pmp_set(, 1ul, );
> > > if (!r) r = pmpsend(s, );
> > > if (!r) r = apx_shutdown(s, shut_wr);
> > > if (!r) r = pmprecv(, s, );
> > > if (!r) r = apx_shutdown(s, shut_rd);
> > >
> >
> > Dumb question this way…
> >
> > > vk4msl-gap$ man apx_connect
> > > man: No entry for apx_connect in the manual.
> > > vk4msl-gap$ man apx_shutdown
> > > man: No entry for apx_shutdown in the manual.
> >
> > what's `apx_connect` and `apx_shutdown`?  There's some library here you
> > are not telling us about.
> > --
> > Stuart Longland (aka Redhatter, VK4MSL)
> >
> > I haven't lost my mind...
> >   ...it's backed up on a tape somewhere.
>
>

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

Re: fw_update verify firmware?

[Janne Johansson]

Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen <
mogens-jen...@protonmail.com>:

> Normally I would just assume that fetched files are verified, but maybe
> in the case with fw_update, the rationale is that firmware files are
> binary blobs so we can't know if they are malicious anyway, therefore
> no reason to bother with verification.
>

It would be sad to mixup the fact that something is signed with a sort of
guarantee that it is without faults or without malice.
The signature proves it didn't change in transport since it was published,
nothing more.

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

Re: Routing and forwarding: directly connected computers

[Janne Johansson]

Den tors 3 sep. 2020 kl 14:55 skrev Ernest Stewart <
erneststewar...@hotmail.com>:

> I was actually wondering about using netmask 0x for the external
> interface. As you noted, they are different networks, I just wanted to be
> able to use any 192.168/16 ip address in the internal network and use
> nat-to and rdr-to in Computer1 so every packet going to or from the ISP
> router comes from or goes to 192.168.1.10 (and block everything else).
>
> But still, that (external connections) is the last thing I am going to
> test. At the moment not even a ping from two directly connected computers
> that are actually sending and receiving the packets (according to tcpdump
> in both computers) seems to work...
>

The setup for computer01 is still weird, it thinks it has 4 interfaces on
the same identical network, because all the nets overlap,  except it
doesn't overlap physically because they are on separate cards. Just grab
any "how to build networks guide" and start using separate network
numbering for separate networks and things will work out better. The fifth
network card which points to your ISP device is smaller, but still inside
those 4 others, which also is a bad choice.

The way comp01 is set up on your first mail makes it equally valid for it
to send out a packet on any of the 5 network cards to try to reach
192.168.1.254 for instance. This is of course not how you set up a box with
5 networks (even if "the network" is just a cable from comp1-re1 to
comp2-re0)

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

Re: Routing and forwarding: directly connected computers

[Janne Johansson]

Den tors 3 sep. 2020 kl 17:01 skrev Ernest Stewart <
erneststewar...@hotmail.com>:

> I forgot to say, in every computer I have /etc/sysctl.conf with
> "net.inet.ip.forwarding=1".
>
> And I insist, what shocks me the most is that tcpdump shows in both
> computers the right icmp packets but ping says 100% packets lost.
>

This part has far too little detail to be relevant. Sorry.
We can not divine from remote which of the interfaces you listened to, and
what you saw.

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

Re: Routing and forwarding: directly connected computers

[Janne Johansson]

Den tors 3 sep. 2020 kl 11:39 skrev Ernest Stewart <
erneststewar...@hotmail.com>:

> I have a local network with 5 computers:
>
> computer1)
> /etc/hostname.re0: 192.168.1.10 0xff00
>

Different netmask here?


> /etc/hostname.re1: 192.168.2.11 0x
> /etc/hostname.re2: 192.168.2.12 0x
> /etc/hostname.re3: 192.168.2.13 0x
> /etc/mygate:
> 192.168.1.1
>
>
> computer2)
> /etc/hostname.re0: 192.168.1.11 0x
>

..compared to here.


> /etc/hostname.re1: 192.168.2.14 0x
> /etc/mygate:
> 192.168.2.11
>
> computer3)
> /etc/hostname.re0: 192.168.1.12 0x
> /etc/mygate:
> 192.168.2.12
>
> computer4)
> /etc/hostname.re0: 192.168.1.13 0x
> /etc/mygate:
> 192.168.2.13
>
>
> computer5)
> /etc/hostname.re0: 192.168.1.14 0x
> /etc/mygate:
> 192.168.2.14
>
>
> Computer1's physical connections are like this:
> re0->ISP router(192.168.1.1)
>

Seems like you chose overlapping networks for your "internal" things and
the ISP router network. Don't do that.


> re1->Computer2 re0
> re2->Computer3 re0
> re3->Computer4 re0
>
> Computer2's re1 is connected to Computer5's re0.
>
>
-- 
May the most significant bit of your life be positive.

Re: Microsoft's war on plain text email in open source

[Janne Johansson]

Den ons 26 aug. 2020 kl 21:17 skrev Mike Hammett :

> Text-only was great in 1985.
> Mike Hammett
> Intelligent Computing Solutions
> Midwest Internet Exchange
> The Brothers WISP
>

Being able to publish and/or send a really small file from computer A to
computer B unchanged in this day and age is still a required feat if you
want to appear as an internet professional.
It doesn't matter if it was "change spaces to tabs", "html made carriage
returns where a space was found" or if it was "make two - - chars into one
single utf-8 -- token" or "spell check/correction edited fnd_trgl_dsk() to
find_triangle_disk()" in your C function. You did not ship what you had
produced in that diff.

If you can't send data 100% with the tools of your choice, the blame is on
you, not on the recipient who did the checking FOR YOU and notified you
about mangled transmissions.

So when your file integrity check or vpn software says "we dropped the
incoming data due to broken checksums", the correct answer is not for the
receiving end to disable checksums. Really.
To even have to tell this to people...

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

Re: OpenBSD 6.7 and ffs2 FAQs

[Janne Johansson]

Den tors 28 maj 2020 kl 07:51 skrev Matthias :

> On a fresh 6.7 installation, mount(8) shows 'type ffs'. Is there any way
> to figure out the version number?
>
>
https://undeadly.org/cgi?action=article;sid=20200326083657

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

Re: Filling a 4TB Disk with Random Data

[Janne Johansson]

Den mån 1 juni 2020 kl 16:01 skrev Justin Noor :

> Hi Misc,
> Has anyone ever filled a 4TB disk with random data and/or zeros with
> OpenBSD?
> How long did it take? What did you use (dd, openssl)? Can you share the
> command that you used?
>

My /dev/random on decent x86_64 give out more or less same amount of data
(around 200MB/s) as spinning drives will accept, so you might aswell just
dd random to the raw device for it. At this speed, you are looking at ~5
hours of fun.

https://www.wolframalpha.com/input/?i=4+terabyte+at+200MB%2Fs

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

Re: dhcpd synchronization: leases recovery after downtime

[Janne Johansson]

Den lör 18 juli 2020 kl 23:28 skrev Guy Godfroy :

> Hello,
>
> I am using two routers on OpenBSD (called mulder and scully), and I wish
> to make dhcpd listen on a carp interface between both of them. I am
> using the synchronization mechanism:
>

I noticed the same issue long time ago, but settled for just running two
unconnected dhcpds and made sure that
1) all fixed replies exist on both (and clients don't mind getting two
answers, they pick the first and stop listening for any extra replies)
and
2) dhcpd checks that ip's don't reply to ping (or exist in arp?) before
handing out an ip from a dynamic range

and this seems to cover most of my concerns, no client would get a
different offer from both dhcpds and ack both, and putting as many fixed
entries as possible on important hosts to make sure they would work in any
case.

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

Re: Should/will OpenBSD support ODROID-C4 board? (ARM A55)

[Janne Johansson]

Den tors 6 aug. 2020 kl 18:40 skrev :

> Hardkernel, a Korean company, make an alternative to the Raspberry Pi, the
> latest being the 'Odroid C4', CPU manufactured by Amlogic (American).
> I owned an ODROID board in the past and was impressed with the hardware.
> However, the software support for Linux is majorly lacking, and so quite
> buggy
> (basic things like USB, ethernet) unless using their self-released
> old-patched-up kernels.
>
> But perhaps this is an opportunity for OpenBSD? I don't know how much work
> it is
> to port OpenBSD to an ARM board, or if Hardkernel do a good job of making
> this
> task easy. I noticed the ODROID-N2 is supported by OpenBSD, which would
> give
> an indication (but the N2 has an A73 and so Spectre bugs).
>

Well, it is somewhat sad if they can't even get decent code in mainline for
linux, which I assume
was their intended target OS, the chances of getting support (or code, ha!)
for OpenBSD
seems very slim, or getting decent docs (which if they existed would have
allowed linux
to run fine on them too?) for the stuff around the cpu.

So it might get to work, but I would probably not have my hopes up too much
if it already did not
make it on linux.

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

Re: Adding more syspatch platform.

[Janne Johansson]

Den ons 12 aug. 2020 kl 00:50 skrev Predrag Punosevac :

> Theo de Raadt  wrote:
> > No, it is a question of which additional platform, you avoided that
> > didn't you
>
> octeon is the only one I can think of.
>

I would volunteer doing the work and dedicating two octeons of mine for
building syspatches for the supported releases, I have enough of them for
it.

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

Re: static IPv6 setup is not working stable

[Janne Johansson]

I have a setup where the virtualization (KVM) combined with the networking
does present a IPv6 def-gw as both an fe80:: and
the more normal 2001:a:b:c:d::1/64 and where the 2001-v6 ip works far
better on virtual machines due to redundancy mac sync things on the network
side, and since the ndp list showed the fe80::1 had a VRRP/CARP-lookalike
mac, it could be the same.

In my case both bsd and linux IPv6-using VMs suffer from ndp "drops" where
it can take seconds for the discovery to figure the mac address out again
after a drop.

So if you can divine what the "real" v6 ip is of the default-gw, try
setting this hard in the conf or /etc/mygate and retry v6.


Den tors 6 aug. 2020 kl 14:46 skrev Matthias Schmidt :

> Hi,
>
> * kug1977 wrote:
> >
> > Is this something wrong configured on OpenBSD server or is this something
> > the provider has to check on the gateway side?
>
> I also have a VM at the exact same provider (netcup) and face
> the same problem.  Since all of my VMs at different providers are
> identical (base install + conf via ansible) and I don't see the issue at
> other providers (IONOS, Hetzner) I suspect it has nothing to do with
> OpenBSD...
>

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

Re: static IPv6 setup is not working stable

[Janne Johansson]

No, I think in my case it is Juniper multichassis LAG (link aggregation
groups) getting confused by identical fe80::x for multiple local v6
networks, or something to that effect.

How does the traceroute6's look when it "works"? If you get a "real" v6
there you might (ab)use that as the gw ip?


Den tors 6 aug. 2020 kl 16:04 skrev kug1977 :

> Unfortuanatly, the Provider netcup doesn’t give out IPv6 gw address
> configuration other than fe80::1, so I cannot check these. But all
> virtualization there is based on KVM, too. So I guess the issue is with KVM?
>
>
> > On 06 Aug 2020, at 15:51, Janne Johansson  wrote:
> >
> > I have a setup where the virtualization (KVM) combined with the
> networking does present a IPv6 def-gw as both an fe80:: here> and the more normal 2001:a:b:c:d::1/64 and where the 2001-v6 ip works
> far better on virtual machines due to redundancy mac sync things on the
> network side, and since the ndp list showed the fe80::1 had a
> VRRP/CARP-lookalike mac, it could be the same.
> >
> > In my case both bsd and linux IPv6-using VMs suffer from ndp "drops"
> where it can take seconds for the discovery to figure the mac address out
> again after a drop.
> >
> > So if you can divine what the "real" v6 ip is of the default-gw, try
> setting this hard in the conf or /etc/mygate and retry v6.
> >
> >
> > Den tors 6 aug. 2020 kl 14:46 skrev Matthias Schmidt :
> > Hi,
> >
> > * kug1977 wrote:
> > >
> > > Is this something wrong configured on OpenBSD server or is this
> something
> > > the provider has to check on the gateway side?
> >
> > I also have a VM at the exact same provider (netcup) and face
> > the same problem.  Since all of my VMs at different providers are
> > identical (base install + conf via ansible) and I don't see the issue at
> > other providers (IONOS, Hetzner) I suspect it has nothing to do with
> > OpenBSD...
> >
> > --
> > May the most significant bit of your life be positive.
>
>

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

Re: New tool to (quickly) check for available package upgrades

[Janne Johansson]

Den ons 17 juni 2020 kl 17:04 skrev Marc Espie :

>
> > > > > The concept you need to understand is snapshot shearing.
> > > > > A full package snapshot is large enough that it's hard to
> guarantee that
> > > > > you will have a full snapshot on a mirror at any point in time.
> > > > > In fact, you will sometimes encounter a mix of two snapshots (not
> that often,
> > > > > recently, but still)
> > > > > Hence, the decision to not have a central index for all packages,
> but to
> > > > > keep (and trust) the actual meta-info within the packages proper.
> > > >
> > > > Sorry, I guess I should've responded to this as well. Isn't snapshot
> shearing going to be a problem regardless of the existence of a single
> central-index? For instance, pkg_add notices a chromium update, which
> requires a newer version of a dependency that hasn't been propagated to the
> mirror yet.
>
> > Even with snapshot shearing though, having this index file could provide
> a substantial speed upgrade. Instead of having to check *all* installed
> package's header for updates, you could use the index to know the subset of
> packages that you expect to have actually changed, and only download
> *those* packages' headers. If the expected "combined" sha of a given
> package doesn't match the index's version, then the mirror is clearly out
> of sync and we could abort an update as usual.
>
>
Do think of what you call "the index file" in terms of "I check/replace
some 100+G of snapshots and packages every 24h", at which point do you
replace that single file, before, under or after none,most,all packages for
your arch are replaced? Will it be synced when the copying passes "i" for
"index.txt" in that packages folder?

What happens if a sync gets cut off, restarted and/or if two syncs suddenly
run into eachother and replace files as they go?

What if a new batch of amd64/i386 files appears while one of the ongoing
syncs run, do you restart over and hope yet another new one doesn't appear
while that one is running?

This is the reality of snapshot package today:

du -sh snapshots/packages/*
34.5G snapshots/packages/aarch64
52.4G snapshots/packages/amd64
18.4G snapshots/packages/arm
44.1G snapshots/packages/i386
24.1G snapshots/packages/mips64
10.2G snapshots/packages/mips64el
26.7G snapshots/packages/powerpc
25.4G snapshots/packages/sparc64

Whatever limitations Marcs design has, it makes it possible for us
mirror admins to sync with some kind of best-effort while still giving most
openbsd users the ability to have pkg_add -u leave you with a working
package eco-system on a daily basis. If the cost is that it takes 40
minutes at night from crontab, then I would not trade a greppable file for
losing some or a lot of the above-mentioned gotchas that the current system
somehow actually handles.

Now if someone invents a decent piece of code to use http connection
pooling, quic/http3/rsync or whatever to speed up getting the required
info, I'm sure we mirror admins would be happy to add/edit our server
programs to serve it.

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

Re: Filling a 4TB Disk with Random Data

[Janne Johansson]

Den fre 5 juni 2020 kl 09:23 skrev Roderick :

> Is not there a SCSI command "sanitize" for that?
> Can be issued with OpenBSD?
> Perhaps his disc supports it.
>

Then again, if you count how many hours it will take to securely erase a
disk, one might doubt the option of "just run this command and it will do
the same in 10 seconds". Might work, might not work. Both will result in a
drive that is hard to read out old data from, but which option gives
confidence?

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

Re: pf filtering on bridge totally blown my mind

[Janne Johansson]

Den fre 27 nov. 2020 kl 10:08 skrev kasak :

> Mine configuration requires to use a brigde:
> I have files:
>


> gater:~$ doas pfctl -sr
> block return all
> pass all flags S/SA
> block drop in on em0 all
> pass out on em0 inet from 172.16.0.0/12 to any flags S/SA nat-to
> 212.233.112.10
> pass in log on bridge0 inet proto tcp from ! 172.16.0.5 to any port =
> 123 flags S/SA rdr-to 127.0.0.1
> pass in log on bridge0 inet proto udp from ! 172.16.0.5 to any port =
> 123 rdr-to 127.0.0.1
>
> pflog doesn't log anything too
>

> Is there some secret, I've failed to found in man?
>
>
Put the "log" keyword on all pass and block rules, the missing packets will
be hitting some rule, and perhaps not the one you did not expect.

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

Re: support new

[Janne Johansson]

There is some,

"We offer the server management service. We work on the deployment and
management of servers with open source technologies such as CentOS, Debian,
FreeBSD, OpenBSD and Ubuntu Server."

Den ons 9 dec. 2020 kl 13:03 skrev Ingo Schwarze :

> Hi,
>
> AMG Labs wrote on Tue, Dec 08, 2020 at 03:55:52PM -0300:
>
> > 0
> > C Brazil
> > P RS
> > T Santo Antonio da Patrulha
> > Z 95500-000
> > O AMG Labs
> > I Angelito Monteiro Goulart
> > A Av. Cel Victor Villa Verde 126/301
> > M cont...@amglabs.net
> > U https://www.amglabs.net/
> > B +55 51 92000 7613
> > X
> > N We are a software development and server management company
> > operating in the market since 2014. We work with the development of
> > customized web systems and the deployment and management of servers
> > based on open source technologies such as CentOS, Debian, FreeBSD,
> > OpenBSD and Ubuntu Server.
>
> Unless i'm mistaken, there is no mention of OpenBSD on your website.
>
> The web hosting offers appear to be for Linux and Windows only, and
> dedicated servers seem to be offered with Linux, Windows, and MacOS X.
>
> Yours,
>   Ingo
>
>

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

Re: PayPal pool for developer M1 Mac mini for OpenBSD port

[Janne Johansson]

Den tors 3 dec. 2020 kl 02:21 skrev Mihai Popescu :

> I have only good wishes for the project, but I still don't get one thing:
> why do some people start to behave oddly whenever Apple comes into
> discussion.
>

It could also be that if it becomes operable, it is quite a useful machine,
whereas sticking to Pine64 experiment boards and FruityPi clones does quite
limit the usefulness even if they are all aarch64s.

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

Re: support new

[Janne Johansson]

Hint to Ingo, the "vpn" section.

;)


Den mån 14 dec. 2020 kl 15:15 skrev porte, su :

> 0
> C Brazil
> P Ceará
> T FORTALEZA
> Z 60410442
> O MDFSoftware
> I Oliveira Filho, D. A.
> A Av. Eduardo Girão 355
> M supo...@mdfsoftware.com.br
> U http://www.mdfsoftware.com.br/
> B +55-85-9-89739017
> X +55-85-9-96110010
> N Auditoria, Desenvolvimento, Suporte comercial para FreeBSD e
> OpenBSD, gateways de Internet, firewalls em cluster, sistemas de
> deteco de intruso e VPNs.
>
>

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

Re: www.openbsd.org unreachable for a few days

[Janne Johansson]

Den tis 15 dec. 2020 kl 13:00 skrev Ottavio Caruso <
ottavio2006-usenet2...@yahoo.com>:

> Hi,
> I asked on Freenode#OpenBSD and apparently it's only me, but I haven't
> been able to access www.openbsd.org for a few days.
>
> $ traceroute 129.128.5.194
> traceroute to 129.128.5.194 (129.128.5.194), 30 hops max, 60 byte packets
>
>
...


> 11  40ge1-3.core1.lon2.he.net (195.66.224.21)  35.068 ms
> 100ge4-1.core1.nyc4.he.net (72.52.92.166)  101.075 ms  86.105 ms


I heard a similar complaint elsewhere and that was going over he.net also,
whereas I could reach it in the mean time, going over shawn to ualbert.ca
and onwards, so I guess he.net is presently bad at routing to the correct
places.

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

Re: openssl s_client gives "called a function you should not call"

[Janne Johansson]

Den tors 12 nov. 2020 kl 22:15 skrev Paul de Weerd :

> While trying to debug my smtpd setup, I got the error "called a
> function you should not call" from openssl s_client:
>
> $ openssl s_client -starttls smtp -connect localhost:587
> 
> EHLO 
>


> RCPT TO: 
> RENEGOTIATING
>



> Is this something openssl s_client doesn't support?  I notice that
> "RENEGOTIATING" only comes after sending the RCPT TO: command to the
> server.  Futzing around with other commands before sending RCPT TO:
> didn't get to RENEGOTIATING.  Am I doing something wrong?  Should I be
> using some other tool?
>

I think anything starting with capital R in that case (s_client) gets
parsed as RENEGOTIATING.
As for why openssl complains about it is unknown to me, but that gotcha is
old at least.

from 2012:
https://serverfault.com/questions/336617/postfix-tls-over-smtp-rcpt-to-prompts-renegotiation-then-554-5-5-1-error-no-v

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

Re: gcc: error trying to exec 'cc1': execvp: no such file or directory

[Janne Johansson]

Den fre 20 nov. 2020 kl 15:09 skrev Roderick :

> > obsolete even on your 6.7 install.. i386 has been a default clang arch
> > since OpenBSD /6.2/.
>
> Clang was default, gcc may be obsolete, but /usr/bin/gcc is till now
> there, broken. In the upgrade instructions is not mentioned to delete
> it:
>

Regardless of when and how defaults changed, the openbsd system compiler is
and was always
"cc".

Used to be gcc 2, then 3, then 4, then clang and no one had to change
anything as long as use cc and not calling gcc/clang directly.

The system makes sure the correct stuff is called if you use cc at all
times.

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

Re: Set environment variable for non-interactive shell

[Janne Johansson]

Check init files in /etc, and not only those for csh, since that is not
default for all users.
The manpage for the shell would be a good place to learn which global
configuration files are run.


Den fre 6 nov. 2020 kl 12:27 skrev Kirill Peskov :

> Hi All,
>
> I'm currently trying to figure out, how to set global environment
> variable, valid for multiple users including root, so Ansible will be
> able to accept it as "fact" for both root and non-root users. I've
> already tried to play with .cshrc files and /etc/rc.local, nothing
> worked so far, looks like I'm missing something important.
>
> Thanx in advance,
>
> Kirill
>
>
>

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

Re: Bootable USB stick using dd on OpenBSD

[Janne Johansson]

Den tis 26 jan. 2021 kl 14:11 skrev Ivan :
> I wonder why I have to make of=... being equal to some partition instead of 
> the whole memstick?
> Why does man page example tells to use of=/dev/rsd1c but not of=/dev/rsd1? 
> And why does it use exactly 'c' partition but not 'a', does that matter?

http://www.openbsd.org/faq/faq14.html#intro

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

Re: OpenBSD 6.9 ports upgrade failures

[Janne Johansson]

Den ons 12 maj 2021 kl 11:29 skrev Артём Мазуров :
> Hello.
> I'm trying to upgrade ports after upgrading os to 6.9, but I get a lot
> >|library ssl.48.2 not found
> >| /usr/lib/libssl.so.48.1 (system): minor is too small
> >| /usr/lib/libssl.so.49.0 (system): bad major

This usually means the pkg_add URL is wrong, perhaps because you have
something version-specific in PKG_PATH or /etc/installurl that points
to the wrong place, compared to your OS version.

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

Re: amd and 2GB limit

[Janne Johansson]

Could be amd(8) and nfsv2 limits too..

Den lör 3 juli 2021 11:23Stuart Longland  skrev:

> On Sat, 3 Jul 2021 01:28:17 -0300
> Gustavo Rios  wrote:
>
> > Is there this limit yet in amd ?
>
> … on AMD64?
> … on RAM?
> … on disk?
> Maximum or minimum?
>
> I've got an AMD64 machine here that's got more than 2GB of both RAM and
> disk… so no if there's a maximum limit, it's a lot bigger than that.
> Limiting RAM or disk to 2GB in 2021 would be ludicrous, so I'm a bit
> confused by your question.
>
> Please be less vague.
> --
> Stuart Longland (aka Redhatter, VK4MSL)
>
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
>
>

Re: Remote wipe software

[Janne Johansson]

Den tis 27 apr. 2021 kl 11:44 skrev 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,

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.

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

Re: Default partitions allocate only 1GB to /

[Janne Johansson]

Den sön 28 feb. 2021 kl 14:51 skrev :
> I deleted the file and `pkg_add libreoffice` worked as expected.
> Post-install I still have 746MB free in /, according to `df -h`.
>
> This makes little sense to me. Why should deleting a 20MB file on a
> filesystem with >700MB free space be sufficient for the install to go
> through? Especially when the install obviously doesn't need that much
> space on the filesystem in question?
>
> (space available in /usr/local went from 11.4G, pre-install, to 10.8G,
> post-install... was `pkg_add` trying to stage files in /, even though
> /tmp is a separate filesystem?)

Is /var a filesystem of its own? Otherwise it could be /var/tmp or
some other place under /var which is used for unpacking packages.

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

Re: Technical Documentation - CARP

[Janne Johansson]

Den tis 13 apr. 2021 kl 10:29 skrev jannick Weiss :
> Hello,my name is Jannick Weiss and i am currently in the process of taking
> my education as a datatechnician. As part of my education i have to do a
> presentation on a self-elected subject and i have chosen to talk about CARP.
>
> It is my understanding that it is you (OpenBSD) that have developed CARP.
> I am having trouble finding information about CARP, such as the different
> states the protocol goes through or how the election of the master node
> works specifically.
> If you can provide any documentation on CARP it would be greatly
> appreciated.

https://www.openbsd.org/events.html lists a few talks some 15 years
ago which focused on PF and Carp, those might help.

Googling "openbsd carp design" turned this PDF up,
https://core.ac.uk/download/pdf/17210042.pdf from 2006 which perhaps
dives a bit deeper.



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

Re: How does bsd.upgrade work?

[Janne Johansson]

https://marc.info/?l=openbsd-tech=138829898720574=2
and
https://marc.info/?l=openbsd-tech=139013674405106=2
might help.

Den tors 21 okt. 2021 kl 14:26 skrev Raul Miller :
>
> A couple minutes of looking things up suggest
> https://marc.info/?l=openbsd-tech=141807224826859 as a plausible
> starting point for that kind of inquiry.
>
> Take care,
>
> --
> Raul
>
> On Thu, Oct 21, 2021 at 8:15 AM  wrote:
> >
> > On Tue, Oct 19, 2021 at 09:32:21PM +0100, Stuart Henderson wrote:
> > >> That's intentional.
> > >
> > >OK. Since you didn't realise this breaks sysupgrade you might also
> > >not realise it weakens RNG initialisation, it is not recommended
> >
> > Where can I read more about this?
> >
>


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

Re: How does bsd.upgrade work?

[Janne Johansson]

> >For an unusual setup you may need to look into how the
> >install/upgrade script works, see /usr/src/distrib/miniroot.
>
> /usr/src/ is empty on my machine.
>

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/
helps with that, if you don't want to install sources but still need
to see them.

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

Re: Question about cryptography software compatibility on OpenBSD

[Janne Johansson]

Den fre 15 okt. 2021 kl 11:01 skrev soko.tica :
> Hello list,
> I have a question about cryptography software compatibility on OpenBSD.
> I have a wild guess about the answer, but I need it to be more reliable.
> The target audience are lawyers, since I want to launch a legal battle in

Then you need lawyer-speak, not answers from technical people.
Those two overlap very little.

> My wild guess is as follows:
> 1) OpenBSD includes cryptography capabilities/software in its kernel.

yes, some.

> 2) Most other operating systems had not included cryptography
> capabilities/software in its kernel.

Depends on when "had" is in time. Nowadays, they probably all do.

> 3) Providers of public digital signatures offer software (a
> one-size-fits-all Java “blob”) that should add cryptography capabilities to
> the operating system.

No, they don't add it to the OS, they expose crypto functionality to
other programs. Big difference.

I know of no OS that would reach out to java in order to get crypto
inside the kernel, and if it's not in the kernel, then any other
random program would not necessarily pick up that there is a bad/evil
blob installed somewhere that gives you poor crypto unless it actively
looks for it, so just by adding java-crypto-something in a folder it
might not be used by anything else that doesn't specifically ask for
exactly this.

> 4) OpenBSD doesn’t allow such technically inferior software to meddle with
> its superior cryptography capabilities included in kernel.

Value added statement, and mostly irrelevant to court cases I guess.

> 5) The proper technical solution would be that providers of public digital
> signatures offer digital signatures adjusted to OpenBSD technical
> solutions, including offering software not being under the minimal
> cryptography standards of OpenBSD. (A side note, hash function of all
> offered public digital signatures in Serbia are SHA-1.)
> Am I somewhere wrong in my wild guess?

Yes, you are assuming too much in the last part.

It is not impossible for other OSes to have
better,faster,more-formally-verified,more-legal-where-I-am-located
crypto routines in their OSes which might be a preferred solution
somewhere.
While openbsd has the crypto it requires for its needs, those needs
are not guaranteed to (always) overlap with all the other requirements
that are set in different places around the world. One example could
be russian computers wanting certain algorithms like GOST in various
forms, or US computers needing FIPS-140 validation even if that in
certain cases lowers the overall security (hard to get fixes and
patches into such a setup)

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

Re: Question about cryptography software compatibility on OpenBSD

[Janne Johansson]

> > > 3) Providers of public digital signatures offer software (a
> > > one-size-fits-all Java “blob”) that should add cryptography capabilities
> > to
> > > the operating system.

> >
> > This is important. Thank you. Let me rephrase my wild guess:
>
> 3.1) An OS (OpenBSD or other) may have cryptography capabilities included
> in the kernel.

Yes.

> 3.2) An OS that doesn't have cryptography capabilities included in the
> kernel may provide cryptography software, not being included in the kernel,
> fit and apt for use on the specific OS.

This is where you seem to be missing that LOTS AND LOTS of programs use
crypto from external libraries.
They call openssl, they use NSS/NSPR, programs link against
gnutls, java code use java libs, go code use go crypto and so on.

> 3.3) Forcing the blind use of proprietary
> java-crypto-one_size_fits_all-blob is technically possible, but it is a bad
> practice since:
> 3.3.1) it may downgrade crypto functionality existing in an OS as described
> under 3.1 and 3.2
> 3.3.2) it may compromise and expose to the attacks not only the digital
> signature, but the operating system itself
> 3.3.3) for a number of other reasons (updates, licensing issues, etc.)

Those last subpoints work both ways.

A brought-along crypto primitive can be controlled by
the person installing the program in ways you can't with the OS,
so it is, like so much else, a tradeoff. If you don't control the OS and what
crypto primitives it has, bringing along your own might be "safer" than to
trust some OS to have a stable interface forever and ever.


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

Re: Kernel dump and secure boot with KARL

[Janne Johansson]

Den tis 5 okt. 2021 kl 06:35 skrev Arka Sharma :
> Also suppose we have a crash and dump is generated, how does KARL impact
> gdb when the core file is opened ?

It would not affect this at all.

It is exactly as hard or as easy to debug a core file from something
compiled with
cc -o bsd obj1.o obj2.o obj3.o
as with something compiled with
cc -o bsd obj2.o obj3.o obj1.o

The relinking is done so that exploit code that knows how to find an
address inside obj1 will not be able to jump into obj2 by taking the
obj1 address and adding 83743 bytes to it and expect to land at a
certain place in obj2. In the first case it would work, in the second
it would not.

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

Re: how to recover a corrupted disk

[Janne Johansson]

Den ons 1 dec. 2021 kl 09:12 skrev Sandeep Gupta :
>  I am running OpenBSD 7.0 on RPi4. I accidentally removed the usb
> cable connecting the sata ssd to the RPi4.
>  Well OpenBSD froze and upon reboot I got the very comforting
> Synchronous Exception  message.
>  Thankfully, I have another RPi4 running OpenBSD. I can mount the
> corrupted disk ( did the  necessary backups). I did fsck on all the
> partitions.
>  All partitions except for /dev/rsd1c and /dev/rsd1i are clean.
>  For /dev/rsd1c , I get  "BAD SUPER BLOCK: MAGIC NUMBER WRONG".

The "c" partition is not meant to hold filesystems, it is the device
used to talk to "the whole disk" for fdisk and such tools.

>  For /dev/rsd1i, I get "UNEXPECTED INCONSISTENCY".

If you had any non-bsd filesystems (like a small MSDOS/FAT partition
for booting/firmware/arm blob stuff), it will end up as sdXi (and
j,k,l, and so on if you have more than one foreign fs), so if that is
the case, then it is not unexpected to see FFS' fsck have issues with
FAT filesystems.

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

Re: how to recover a corrupted disk

[Janne Johansson]

Den ons 1 dec. 2021 kl 11:09 skrev Sandeep Gupta :
> @Peter, @Janne: Thanks for the infos. Newfs seemed promising but it
> seems like the disk is beyond repair :(.
> I did newfs -N and got quite a few location of superblocks:
> Then I tried
> fsck_ffs -b #blockid /dev/rsd1c

You should *NOT* newfs or fsck against the "C" partition.


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

Re: Are there any OpenBSD Kernel/Architecture Books?

[Janne Johansson]

Den tis 21 dec. 2021 kl 02:14 skrev Thomas Windisch
:
> What resources would be a good primer on the OpenBSD kernel and general
> architecture and give me a good understanding of the internals?
>
> FreeBSD has this:
>
> https://docs-legacy.freebsd.org/doc/13.0-RELEASE/usr/local/share/doc/freebsd/en_US.ISO8859-1/books/arch-handbook/book.html
>
> I understand that in OpenBSD there is the mantra that source code is
> documentation. But as a beginner I'm afraid that I do need something
> explicit that would allow me read the source code in an effective manner.

For general kernel code, The Design and Implementation of the 4.4BSD
Operating System,
and for network/driver code, Stevens TCP/IP Illustrated Volume 2 is a
really good choice.

Even if it doesn't match 100%, when you "get" those books and how code
is/was written,
it will be far easier to get into the OpenBSD codebase.

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

Re: running a process under nologin user

[Janne Johansson]

Den mån 22 nov. 2021 kl 06:27 skrev Sandeep Gupta :
> The httpd server runs under user www. In my web deployment setup, the
> httpd server communicates over uWSGI/gunicorn server over unix domain
> sockets.
> I am not able to launch uwsgi (or gunicorn) server under www user.
> The command
> "doas -u www " gives error
> "operation not permitted".  As root, trying to lauch a shell "su www
> -l /bin/bash" returns "The account is currently not available".
> Whats the recommended way to launch process under www?


machine# su -s /bin/sh www
machine$ id
uid=67(www) gid=67(www) groups=67(www)
machine$

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

Re: disk i/o test

[Janne Johansson]

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

True

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

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

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

Re: Cannot pass the OpenBSD bridge.

[Janne Johansson]

Den fre 11 mars 2022 kl 10:23 skrev T K :
> Hi list
> Please forgive me my incompetence, but I have no further idea
> how to manage setup I try to arrange.
> I have fujitsu futro box with 2 ethetnet cards, OpenBSD 7.0.
> I would like to set that box up as a filtering bridge.
> I guess it is quite common schema:
> Lan boxes(windows) > network switch>>network
> switch>host1,host2,host3 etc.
> Config is made according to manuals, the book of pf and so on:
> /etc/hostname.bridge0: add re0 add bge0 blocknonip re0 blocknonip em0

em0 ?

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

Re: boot and ddb

[Janne Johansson]

Den tors 10 mars 2022 kl 09:57 skrev rtw0 dtw0 :
> Hi,
> (reboot) after install opens dbb > showing UID 0 as loading is halted.
>
> Where may I find info for debugging with ddb?

http://man.openbsd.org/crash
and
https://www.openbsd.org/ddb.html
might be of some help to get started,

http://man.openbsd.org/ddb.4

on how to manage ddb itself.

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

Re: who is writing to a deleted file?

[Janne Johansson]

Den fre 18 mars 2022 kl 16:29 skrev Harald Dunkel :
> something on my gateway (7.0) is hiding disk space, AFAICS:
>
> # du -hs /
> 3.4G/
> # df -h /
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/sd0a 31.5G5.6G   24.3G19%/
>
> How can I find out which process is eating up disk space, without
> killing it, of course?

fstat(8) can help,

# fstat | sort -n -k 9
to get the largest open file at the bottom, third column is the PID.


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

Re: disk i/o test

[Janne Johansson]

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

Probably yes. AHCI will be better if it works.

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

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

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

To test large-IO perf:

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

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

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

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

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

Re: disk i/o test

[Janne Johansson]

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

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

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

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

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

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

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


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

Re: openbsd, softraid recovery (I have password)

[Janne Johansson]

Den sön 3 apr. 2022 kl 15:58 skrev harold :

For anyone else that wants to experiment with dual/triple-booting:

> I lost data due to misunderstanding
> I tell you more :
> a/ I had windows and linux mint 18 (gpt/efi)
> b/ I add openbsd to these double systems. Now three. Grub2 manages it.

[ skipping a bit in the middle ]

> password, recognize it. Slice looks empty. Df shows only few kb files.
> Data is gone. No backup.

If you are doing weird triple OS-on-same-harddrive experiments, either
1) do not stash important data at all on any of them and just use it
to learn something
or
2) make very sure you have working backups of everything important to you

There is very little in between, apart from tears when people skip
this advice. 8-(

No, I can't help get this data back, but I can at least hope to tell
just one user more, that tested backups are very important,
*especially* when doing experimental setups with the disk and
partitions around it.

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

Re: How to track system changes?

[Janne Johansson]

Den tis 5 apr. 2022 kl 03:20 skrev Eric Thomas :
> Very valuable insights. That’s a great idea.
> The rysnc script was ksh/bash or cron? Ideally I’d like to use Python to 
> tackle something like this but I’m not against learning shell.

Sounds a lot like rsnapshot (available in ports), the end result
should be the same on the remote, and there you can look for changed
entries.


> > Something I came up with which worked out really well at my employer was
> > a backup system that used rsync and the --link-dest option to make a useful



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

Re: BOGUS behavior on 6.9 Spark vs. 6.9 amd64

[Janne Johansson]

Den tis 5 apr. 2022 kl 13:46 skrev Duncan Patton a Campbell
:
> I have 6.9 installed on an amd64 and a sparc64.  On the amd tar/gzip etc. 
> work as
> always, producing .gz files that can be uncompressed with gunzip.
>
> But on the sparc64, things go sideways.  Instead of calling the gzip it is
> invoking xz (which is a bogon of another era).  Why is this?  How can
> I return the sparc to normal behavior?

I suggest checking the PATH and "which gzip" to see if the sparc is
calling out to a non-system binary when you run "gzip".

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

Re: Cross-build ARM64 on AMD64. Any starting pointers?

[Janne Johansson]

Den fre 25 mars 2022 kl 09:23 skrev Slava Voronzoff :
> Hello, I want to build ARM64 on my OpenBSD/amd64 machine. Any suggestions
> on there to start with? I spent some time in qemu-aarch64, but while it is
> working it is obviously pretty slow.

http://www.openbsd.org/faq/faq5.html search for "cross"

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

Re: What happened to www/art on CVSWeb? Why is it empty?

[Janne Johansson]

Aren't they under images/ ?

Den tors 10 feb. 2022 17:53Marc Espie  skrev:

> On Thu, Feb 10, 2022 at 11:25:40AM -0500, Nick Holland wrote:
> > On 2/10/22 6:34 AM, Kacper Wilgus wrote:
> > > I tried to download some artwork from these pages:
> > >
> > > https://www.openbsd.org/art1.html
> > > https://www.openbsd.org/art2.html
> > > https://www.openbsd.org/art3.html
> > >
> > > But only the first one has an image, the rest of them give me 404
> > > errors and I swear they used to be there just a year ago. And the
> > > wayback machine proves this. Was it an error, or copyright issues?
> > > It seems wierd it was just snapped out of existence without any
> warning.
> > >
> >
> > art[123].html hasn't been referenced from the main page since OpenBSD 5.8
> > (see the removal in version 1.686 of index.html, and they are not
> currently
> > referenced in any page on the website other than art[123].html so I think
> > it is safe to say it was not being maintained and deleted at some point.
> >
> > I have no other info than it looks like the "problem" is more the
> > continued existence of art[123].html more than the missing images.
> >
> > Nick.
> >
> >
> A quick look at the full cvs repository shows a few .jpg and QUITE a few
> .gif in the Attic.
>
> Just saying ;)
>
>

Re: IKEV2 two devices can connect but only one can make traffic

[Janne Johansson]

Den tis 12 apr. 2022 kl 15:30 skrev Łukasz Moskała :
> I remember talking with network engineer at one company I used to work at.
> We used fortigate firewalls, and I asked why are we using SSLVPN instead of 
> ipsec-based vpn, as both were supported.
> He said something along the lines of "ipsec does not work when there are two 
> devices connecting from the same IP so this would be issue for us when two 
> admins were on the same public wifi, or lived together"
> I don't know if this is specific to fortinet's implementation, or if it's 
> issue with ipsec itself, as I never used ipsec in anything else than 
> site-to-site connection.

Some ipsec implementations require that IKE (v1?) negotiation comes
with source udp port 500, and since two clients behind one NAT can't
both map their outgoing packets (or even one of them) to this single
port, it is not possible to have two nat'ed clients behind same
external IP.

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

Re: pf documentation

[Janne Johansson]

Den tors 7 apr. 2022 kl 11:12 skrev Steve Litt :
>
> Hi all,
>
> I need some easy beginner's pf documentation as well as some
> intermediate pf documentation. I plan to make an OpenBSD/pf firewall. I
> haven't done this in ten years, and imagine pf and the process of
> turning OpenBSD into a firewall have changed in that time.

Might be worth looking around the OpenBSD webpage, perhaps it has a
section with Frequently Asked Questions that contain PF information
one might learn from?


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

Re: desire for journaled filesystem

[Janne Johansson]

Den tis 5 sep. 2023 kl 20:53 skrev John Holland :
>
> I have a backup that is at least 2 days old offsite at a friend’s house. It 
> would be a bit of a pain to go retrieve it, but I could do that.
>
>  Short of that, I have 4000+ files in lost+found with names like #1094827. 
> What can I do with those? I tried running “file” on the first 50 via xargs 
> and they mostly at least purport to be some sort of intact file. How can I 
> determine what they are? Please don’t suggest that I manually use “file” and 
> then an appropriate program to examine each one in turn
>

Those "files" are fragments of files, named after the inode number,
which you get when fsck finds a not-complete chain of
directory-entry/filename -> inode -> linked list of file-contents.

While fsck can't figure out the filename and where in the directory
structure it is meant to belong, or possibly if it is only some part
of a whole file, it will give you a chance to recover at least partial
contents from the lost+found folder. Sometimes this might be awesome
if you can dig out some key or pw needed for something super
important, sometimes you get half of a database file and that is
probably close to zero usefulness.

That said, if it was (as written later) browser cache and partial
downloads, it is not very surprising that data files exist which are
not yet linked during the download, or temp files unlinked for later
deletion by the FS, had the computer not crashed. If you had something
like zfs, those half-written or half-deleted files might just have
been totally missing instead of ending up in lost+found, since they
represent a point-in-time in which the FS is not in a consistent
state, so the end result would mostly have been the same, this data is
not visible under your home account after the crash.

Journaling has some great advantages, like write aggregation if your
journal can be placed on a faster device and when it comes to quick
checkups after crashes, an empty journal often means the fs was not in
a broken state and probably needs less or no total checkup by fsck
tools, which is nice.
It will not fix a half-downloaded ISO or unlinked temp files that you
for some reason want to look at afterwards, nor will the journal fix
any kind of broken sectors, though checksumming file systems will of
course help you find the errors before handing the bad sectors over to
your applications.

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

Re: desire for journaled filesystem

[Janne Johansson]

Den fre 8 sep. 2023 kl 03:47 skrev Steve Litt :
>
> My main computer is Void Linux. If I had to restore from backup every
> time the disks became mildly messed up, all my time would be spent
> backing up and restoring.
>
> I remember back in the 90's and early 00's before journalling every
> system crash was grounds for an ulcer.

Then again, ext2-3-4 run in asynch mode for all operations, which is
why e2fsck takes such a long time, the act of creating a new file
needs at least four operations (allocating space for contents, adding
filename entry to directory, creating inode for metadata and writing
out the actual contents).

If you run async file systems, these can happen in any random order,
and if you have a crash while files are being created (and deleted)
any of these may or may not have happened. BSD ffs does these mostly
in order (where softdep can change/delay some of them) which means
that fsck for ffs can know that if step 3 isn't done, step 4 will not
have started either.

For e2fsck, all possible combinations must be explored. Adding to
this, ext filesystems don't seem to have any kind of way to express "I
found an unchecked error so I am in need of a detailed fsck", which is
why dists using ext2 would have "magic" files like touching /autofsck
and removing said file in order to indicate if last shutdown was good
or bad.

Even with this simplistic method, they would STILL force fsck every
100 days or 58 reboots, because well, you can't tell if there ever was
an error during the last 100 days, since there is no method to mark
the known-broken fs as needing fsck.

In the light of this, the need for a journal (even at the cost of
slightly more IO at times) becomes obvious. The fine folks over at the
penguin camp will rather write to a journal "I am about to create
/tmp/tmp.FSGSGRg3", then send those four operations, then clear the
journal entry again, just so the middle 4 ops can be async, than
"suffer" some ordering in the file system operations.

Now, bsd can run softdep which speeds some writes up, at some cost and
some added risk, and you can certainly mount async and have really
large risks added, but for each of those two steps, I would make very
sure that I had either useless data, or (as suggested) good backups in
place.

As Nick wrote, bsd people tend to like the fact that when your IO
subsystem says "the data is on the disk", it actually is there. Ext4
had a nice period* when "on the disk" meant "it will be on disk in 2
and a half minutes" even for atomic operations. You can imagine how
many people managed to have issues or lose power in the span of 150
seconds. I think they shortened the time, but the amount of tears
needed for the "go fast even if you go in the wrong direction" crowd
to change their minds was quite large.

To me, it is like usb writing speeds. OpenBSD will have dog slow
speed. But it will also allow you to unmount the device when the write
is finished. Other common OSes will tell you "done!" in a few seconds,
then the stick is still blinking, and you ask to unmount and then it
still takes this long amount of time because it was just lying to you
about the writes being finished. If I am to wait 30 seconds to write a
large ISO to my stick, I'd rather have the computer show me it is
working, instead of hoping I would write the file in "three" seconds
and then read comics for 27 seconds before unmounting so I don't
notice the discrepancy.

*)  
https://www.pointsoftware.ch/2014/02/05/linux-filesystems-part-4-ext4-vs-ext3-and-why-delayed-allocation-is-bad/

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

Re: Bind address for wireguard

[Janne Johansson]

Den tis 29 aug. 2023 kl 17:10 skrev Samuel Jayden :
> Is it possible to bind source address on wireguard as the source address of
> the connection?
> Thanks.

There isn't such an option now, outgoing udp will choose the interface
which currently is deemed "best" on which the destination IP can be
reached. If you search with google, you will find similar questions on
the wireguard mail list from many years ago, and similar answers.

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

Re: reorder_kernel: failed

[Janne Johansson]

Den tis 17 okt. 2023 kl 16:49 skrev Karel Lucas :

> Hi all,
>
> After a new installation of openBSD 7.4 I received the following
> message: "reorder_kernel: failed -- see
> /usr/share/relink/kernel/GENERIC.MP/relink.log". That turns out to be a
> zlib compressed data file, and I don't know how to unpack or read it.
> Does anyone know how I can do that?
>
>
>
If it actually is a zlib compressed file, then "zcat" or "zless" should
work fine.

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

Re: What could cause high CPU load averages (no actual CPU usage)?

[Janne Johansson]

>
> > I process that is started every 5 seconds and exits after 10ms
> > computation can cause the load to go up by 1. It just matters if it runs
> > during the sampling time or not.  This is why the load avarage is not
> > accurate, it is an indication and if the value is below the number of
> CPUs
> > you may well see quantization errors.
> >
> > So yes, maybe there is something going on but even top -s .1 -I will
> have a
> > hard time to show it to you. It may be too h interestingsmall of a blib
> to spot.
>
> Ah, interesting. Any idea on how to measure/catch something like that? How
> would one find such a process?
>

If you have such a process (and see "load 1.0" in top) you don't have a
load problem on this computer, so "finding" it becomes irrational.

This means that you are chasing a symptom but where you lack an actual
problem. If your cpu is busy 10ms every 5 seconds it is basically idle, and
the small percentage you see is totally within measurement error margins.
But load is a very bad measurement tool as previously stated in this thread.

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

Re: How to break and smash things

[Janne Johansson]

Den tors 26 okt. 2023 kl 07:51 skrev Maria Morisot :

> But I really want to help the project. I like the idea of trying to break
> things and get them to malfunction in order to expose bugs that have been
> overlooked.
>
> I have a pretty good understanding of randomness and know about the
> concept of fuzzing. I've done testing in my software courses and know a
> little about writing code for explicit bad cases. But my schooling was very
> lax and was easy to get A's so I didn't put much effort in.
>

https://undeadly.org/cgi?action=article;sid=20150121093259

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

Re: xfce

[Janne Johansson]

Den ons 25 okt. 2023 kl 13:22 skrev Maria Morisot :

> I know for a fact that something is broken in either xenocara or the main
> system, I can reproduce a kernel panic by running xfce, I've enountered it
> many times. But I don't know how to trap it before it faults in order to
> see what is going on.
>

https://www.openbsd.org/report.html might give a few hints.


> My solution was just to ignore it and run cwm but I want to try to fix it.
> I don't know how though.
>

If no details in any report are visible, then the chances of the bug being
fixed seems very low.

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

Re: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header

[Janne Johansson]

Den sön 17 sep. 2023 kl 09:19 skrev Andrew Lemin :

> Hi,
>
> I have been testing the Wireguard implementation on OpenBSD and noticed
> that the ToS field is not being copied from the inner unencrypted header to
> the outer Wireguard header, resulting in ALL packets going into the same PF
> Prio / Queue.
>

I think the original wireguard implementation defines it as a feature:
You can see the lines at
https://github.com/WireGuard/wireguard-linux/blob/stable/drivers/net/wireguard/send.c#L373
they skip bringing it along to not leak that information to the outside.

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

Re: Speed: dump/restore vs rsync

[Janne Johansson]

Den fre 22 sep. 2023 kl 20:17 skrev vitmau...@gmail.com :

> Hi,
>
> I used the command "cd /SRC && dump 0f - . | (cd /DST && restore -rf - )"
> as suggested by the "Disk Setup" section of the FAQ to transfer everything
> from one of my old hard disks to the one that should replace it. However,
> I'm stuck with something around 35 megabytes/s of speed transfer (measured
> using "systat -h io") following this path. If I use rsync, I get something
> around 70 megabytes/s (measured by both the "--progress" option and
> systat). Am I missing something? Is this to be expected?
>

While I can't comment on the actual numbers, one thing one could consider
when restoring (from any medium/type) into a new empty file system is that
you can mount the destination fs async during the restore in order to speed
it up a bit.

While running with async all the time is not a good idea, the reasoning
here is that if you get a half-restore (from some error you can fix) you
would want to restart the restore fully anyhow, so in that case async isn't
a problem while restoring. Then you need to remount or unmount the async so
that you are really sure it flushes all writes before you start running on
it, or rebooting.

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

Re: OpenBSD 7.3 found a process with PID 0

[Janne Johansson]

>
> How could be that there is a process with PID 0 before init?
> Probably I'm missing something about OpenBSD core.
>

As for this small part of the mystery, even init starts out as a skeleton
process created early by the kernel, which then does an exec() of
/sbin/init so that whatever program lies there on disk replaces the
skeleton and retains its pid. When you know that part, it would not be
unimaginable to have the kernel create another process (the swapper in this
case) even before that happens.

After init-from-disk runs, all other processes must in some way be a
descendant of it, but that "rule" does not cover the first two pids at
least, which you can later see are the only ones without randomized pids.

For the rest of your questions, others have chipped in already.

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

Re: groups new

[Janne Johansson]

Den tors 5 okt. 2023 kl 09:43 skrev Matti :

> It's not official, and I am trying to gain visibility by having it on the
> openbsd site. I am the first member.
>

Perhaps try to help getting the HelBUG restarted again, there should be
some people there who like BSD.

http://helbug.fi/
https://twitter.com/helbsdusergroup

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

Re: Supporting the OpenBSD Project through a Registered Charity

[Janne Johansson]

Den tis 29 aug. 2023 kl 13:45 skrev Katherine Mcmillan :
> I'm wondering if there are any registered charities (in Canada, or frankly, 
> any country!) dedicated to promoting/supporting OpenBSD?
>

https://www.openbsdfoundation.org/

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

Re: OpenBSD and multitasking

[Janne Johansson]

Den tis 26 apr. 2022 kl 22:50 skrev Mihai Popescu :
> $ time dd if=/dev/zero of=test10g.dat bs=1m count=10240 conv=fsync
> 10737418240 bytes transferred in 260.289 secs (41251827 bytes/sec)
> $ time dd if=/dev/zero of=test10g.dat bs=1m count=10240 conv=fsync
> 10737418240 bytes transferred in 24.006 secs (447266094 bytes/sec)
>
> The test is done using a mechanical disk and a ssd one. I think the
> dude telling that some entry level ssd have the same performance like
> mechanical disks is the same with the one telling ssd will wear very
> fast. My mistake to believe it without testing.

Even if the best-case transfer speeds were the same, the zero seek
times of ssds will make a huge difference when dealing with all other
kinds of IO than "super large linear writes", which is basically 99.9%
of all IO you do when using the computer.

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

Re: shmmax

[Janne Johansson]

> As my system is still fast and running properly after this tweak I need
> to ask if you think that sysupgrade requires or will (I doubt) any
> special value for shmmax?

If it required a special setting, it would set that special setting.

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

Re: shmmax

[Janne Johansson]

>  I'm here asking what
> it is exactly the meaning for 'shared memory' here, and if implying
> that it is eventually the max memory allocable to the graphic card is
> correct.

No. This is not related to graphics card memory

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

Re: Historical Reasons For Default NAT Source Port Modification

[Janne Johansson]

Den mån 16 maj 2022 kl 10:35 skrev Elias Carter :
> OpenBSD/PF defaults to randomizing the source port whereas
> Linux/IPTables defaults to trying to keep the source port.
>
> I have found that preserving the source port if possible works better
> out of the box when hosting publicly accessable UDP applications
> within a private network. Randomizing the source port of UDP replies
> will most likely cause the reply to be blocked by the requestor's
> network. Of course you can create a PF rule for your UDP application
> with `static-port`, but it requires a more in depth understanding of
> how NAT and UDP applications interact to get it to work.
>
> One possible advantage of randomizing source ports is that it helps
> prevent fingerprinting of the devices behind the NAT? Are there any
> other reasons?

I don't know the original thought, but if the source UDP port has
strict requirements, then you should really handle it strictly and not
just "bet" on the first consumer to have it work, and the second,third
and so on will fail.

Lets take old IKEv1 as an example, it wants to make the phase 1
negotiations to UDP destination port 500, while some IKE daemons
implement a check that the source UDP port is also 500. In case the
NAT tries to use the same port, the first client to ipsec against a
remote host will succeed, but a second client running at the same time
would get a source port from the "pool" of random UDP ports, and hence
stop working.

I think this would cause even bigger issues than having both get
random ports to begin with, so that you can act on it immediately
(setting NAT-T or something else in this case) and not when the
service starts to become used by more than your first test laptop.

While I can see the appeal of trying, it still means the service is
not really made to work for more than one client from that same NAT
pool. Might be fine if you aim for "bill and bob and jenny who works
from home" coming in from separate home broadband connections or
whatever, but it quickly breaks down for any larger cases than that.
It is rather uncommon for UDP services to make demands of the source
port and for them to have expectations about the ports, so when this
happens I think one needs to see and act on it right away, and that
would not happen if it "sometimes work" based on luck or timing or "I
was first into the office so I got todays slot at 08.01 to 08.02
before the udp session times out in the fw".

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

Re: best place to put export variables

[Janne Johansson]

> > I want to export XDG_CACHE_HOME variable used by Xorg.
> > What is the best place (file or ?) to export this variable?
> > I remember i used some file to export a long time ago PS1 variable.
> > Should I use ~/.login file or is it a better way to export this xorg 
> > variable?

> Everywhere online (Linux users mainly) were saying to put it in
> .profile, which did not work on OpenBSD.  What ended up working for me
> is putting it in .xsession.  So I assume that is a good place for any
> export command like this.

Well, .profile is a shell init file setting, so if you read advice
from people who are running another shell than you are, then their
solutions will not work. It is not (primarily) about what OS you are
using, but which shell you have, and which files it will read and
parse at startup. .xsession will also work, in the graphical
environments, and for QT that might be implied of course.

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