Re: Viewing SFP diagnostic data in OpenBSD ?

[David Gwynne]

> On 6 Apr 2019, at 01:54, Rachel Roch  wrote:
> 
> 
> 
> 
> Apr 2, 2019, 11:19 PM by da...@gwynne.id.au:
> 
>> 
>> 
>>> On 3 Apr 2019, at 04:52, Stuart Henderson <>> s...@spacehopper.org 
>>> >> > wrote:
>>> 
>>> On 2019-04-02, Rachel Roch <>> rr...@tutanota.de 
>>> >> > wrote:
>>> 
 Hi,
 
 Hopefully I'm just searching the man pages wrong but I can't seem to find 
 any hints as to how I can view SFP diagnostics in OpenBSD (i.e. light 
 power etc.)
 
 Perhaps someone could kindly point me in the right direction ?
 
 Rachel
 
>>> 
>>> I don't think that code has been written yet.
>>> 
>> 
>> You're right, it hasn't.
>> 
>> Rachel, which nic are you interested in having this on?
>> 
>> dlg
>> 
> 
> Just spotted this email.
> 
> An Intel I350 based NIC made by HotLava  
> (https://hotlavasystems.com/products_gbe.html) 
> 

OK. I made a start on this. Have a look for "sfp module info and diagnostics" 
on tech@, or click on https://marc.info/?l=openbsd-tech=155469738013008=2

We don't have an em(4) here with optics, but a diff doesn't look too bad if 
you're willing to test it.

dlg

Re: 10GBit network performance on OpenBSD 6.4

[Mark Schneider]

Short feedback:

Just for the test I have checked the 10GBit network performance
between two FreeBSD 13.0 servers (both HP DL380g7 machines)
transfering data in both directions

# ---
ironm@fbsdsrv2:~ $ scp ironm@200.0.0.10:/home/ironm/t2.iso t100.iso
Password for ironm@fbsdsrv1:
t2.iso 100% 3626MB 130.2MB/s   00:27

# ---
ironm@fbsdsrv2:~ $ scp obsd2fbsd.iso ironm@200.0.0.10:/home/ironm/t1.iso
Password for ironm@fbsdsrv1:
obsd2fbsd.iso  100% 3626MB 140.4MB/s   00:25
# ---

The ssh performance using 10GBit network connection on FreeBSD 13.0
is approx 7 times higher than the one on OpenBSD 6.4.

Is it the question of the "ix" NIC driver of OpenBSD 6.4?
(X520-DA2 NICs from Intel)

Does one of you achieve good 10Gbit network performance with other 
10Gbit NICs?


Thank you in advance for your hints.

Kind regards
Mark

--
m...@it-infrastrukturen.org


Am 06.04.2019 22:52, schrieb Mark Schneider:

Hi,

Please allow me few questions regarding 10GBit network performance on 
OpenBSD 6.4.
I face quite low network performance  for the Intell X520-DA2 10GBit 
network card.


Test configuration in OpenBSD-Linux-10GBit_net_performance.txt - 
http://paste.debian.net/1076461/
Low transfer rate for scp - OpenBSD-10GBit-perftest.txt - 
http://paste.debian.net/1076460/


Test configuration:
# ---
# OpenBSD 6.4 on HP DL380g7
# -

# 10GBit X520-DA2 NIC
ix0: flags=208843 
mtu 1500
media: Ethernet autoselect (10GbaseSR 
full-duplex,rxpause,txpause)

inet6 fe80::d51e:1b74:17d7:8230%ix0 prefixlen 64 scopeid 0x1
inet 200.0.0.3 netmask 0xff00 broadcast 200.0.0.255

ix1: flags=208843 
mtu 1500
media: Ethernet autoselect (10GbaseSR 
full-duplex,rxpause,txpause)

inet 10.0.0.7 netmask 0xff00 broadcast 10.0.0.255
inet6 fe80::b488:caea:5d6f:9992%ix1 prefixlen 64 scopeid 0x2
# ---

Compare to Linux the 10GBit transfer from/to OpenBSD is few times slower:

# ---
# OpenBSD to Linux (Asus P8BWS)
# -
srvob# iperf3 -c 10.0.0.2
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate
[  5]   0.00-10.00  sec  1.50 GBytes  1.29 Gbits/sec  
sender
[  5]   0.00-10.20  sec  1.50 GBytes  1.27 Gbits/sec  
receiver

# ---


# ---
# Linux (DL380g7) to Linux (Asus P8BWS)
# -
root@kali:~# iperf3 -c 100.0.0.2
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  10.9 GBytes  9.39 Gbits/sec 328 
sender
[  5]   0.00-10.04  sec  10.9 GBytes  9.35 Gbits/sec  
receiver

# ---

The scp transfer rate is like 21MBytes/s only per ssh connection 
(OpenBSD <-> Linux):

# ---
root@kali:~# scp /re*/b*/ka*/kali-linux-kde-2019.1a-*.iso 
ironm@10.0.0.7:/home/ironm/t12.iso

ironm@10.0.0.7's password:
kali-linux-kde-2019.1a-amd64.iso 4%  173MB 
21.5MB/s   02:40 ETA

# ---


The 1GBit cooper based NIC works also slower but reaching almost 40% 
of the max trasfer rate of 1 Gbit:


# ---
# OpenBSD 6.4 (DL380g7 1Gbit NIC) to Linux (DL380g7 1GBit NIC)
# 
srvob# iperf3 -c 170.0.0.10
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate
[  5]   0.00-10.00  sec   471 MBytes   395 Mbits/sec  
sender
[  5]   0.00-10.20  sec   471 MBytes   388 Mbits/sec  
receiver

# ---

# ---
# Linux (Asus P8BWS) to Linux (DL380g7)
# -
root@kali:~# iperf3 -c 192.168.1.122
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bitrate Retr
[  5]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec 183 
sender
[  5]   0.00-10.04  sec  1.09 GBytes   934 Mbits/sec  
receiver

# ---


Thank you in advance for your hints what OpenBSD 6.4 settings do I miss.

Best regards
Mark

Re: ARP issues when using ldpd and MPLS pseudowires

[Henry Bonath]

I just wanted to circle back to this, I have had some test machines running
for the past week, and they have kept their LDP neighbors up the entire
time.
The only ones still with issues are the un-patched 6.4 systems, which I
will upgrade once 6.5 is released.

Thanks Adrian and Thanks DLG!
I love this community!

On Tue, Apr 2, 2019 at 12:24 AM Adrian Close 
wrote:

> Hi Henry,
>
> Le 02/04/2019 13:39, Henry Bonath a écrit :
> > It looks like a patch may have been produced, but I do not know how to
> test
> > it. I'm not sure if I can pull down just a small part of the
> > OpenBSD source, or if the entire OS should be built. (Although I'd love
> to
> > learn how to do this)
> Yup, there was a patch.  It's been in the -current snapshots for a while
> now (thanks dlg@), so you can just pull the latest ISO or whatever from
> snapshots/ and install that to test.  Probably not a bad idea, as I'm
> not 100% sure my problem was the same as yours.
>
> I tested the patch by installing a fresh system from the then-current
> snapshot (without the patch), downloading src.tar.gz and sys.tar.gz from
> 6.4, untarring under /usr/src & /usr/src/sys, using CVS to update that
> source to -current, applying the patch and then building the kernel
> ('bsd').  (There may be better ways, but that's how I did it.)
>
> Then, copy the resulting 'bsd' file to / (keep a copy of the existing
> one!) and reboot.  Simple enough...
>
> It was just a kernel patch so I didn't bother rebuilding the entire
> userland, although that's advisable if you're planning on more extensive
> testing.
>
> Have a look at https://www.openbsd.org/faq/faq5.html for some hints and
> feel free to ping me if you get stuck.
>
> Adrian
>
>

Re: hw.ncpu=1, hw.ncpuonline=1, hw.ncpufound=4

[Otto Moerbeek]

On Sun, Apr 07, 2019 at 01:54:35PM +, Ipsen S Ripsbusker wrote:

> My hw.ncpu and hw.ncpuonline are less than my hw.ncpufound.
> I tried setting hw.smt, but that alone was apparently not enough.
> What should I do if I want to use all 4 CPUs?
> 
> Also, now that I have realized this, I have a theory about a related
> issue, and I would like to know how I can debug it. I am using softraid
> CRYPTO, and I have found that accessing the disk with one process will
> interrupt the other processes accessing the disk. Now I wonder this
> happens because the sole core must switch encryption/decription
> processes for the different files. How could I determine whether this is
> indeed happening?
> 
> More hardware information follows. It is a ThinkPad T530 with
> two SSDs and two corresponding softraid CRYPTO disks.

This type of question *requires* a dmesg.

-Otto

> 
> $ sysctl hw
> hw.machine=amd64
> hw.model=Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
> hw.ncpu=1
> hw.byteorder=1234
> hw.pagesize=4096
> hw.disknames=sd0:c4ae9aa6707fe6a0,sd1:10319ae393cc594d,sd2:72b7961f3a883f2a,sd3:9067e68ce463822c
> hw.diskcount=4
> hw.sensors.cpu0.temp0=44.00 degC
> hw.sensors.acpitz0.temp0=47.00 degC (zone temperature)
> hw.sensors.acpibtn0.indicator0=On (lid open)
> hw.sensors.acpibat0.volt0=11.10 VDC (voltage)
> hw.sensors.acpibat0.volt1=12.11 VDC (current voltage)
> hw.sensors.acpibat0.power0=0.00 W (rate)
> hw.sensors.acpibat0.watthour0=28.20 Wh (last full capacity)
> hw.sensors.acpibat0.watthour1=1.41 Wh (warning capacity)
> hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity)
> hw.sensors.acpibat0.watthour3=28.20 Wh (remaining capacity), OK
> hw.sensors.acpibat0.watthour4=73.26 Wh (design capacity)
> hw.sensors.acpibat0.raw0=0 (battery full), OK
> hw.sensors.acpiac0.indicator0=On (power supply)
> hw.sensors.acpithinkpad0.temp0=47.00 degC
> hw.sensors.acpithinkpad0.temp1=47.00 degC
> hw.sensors.acpithinkpad0.temp2=47.00 degC
> hw.sensors.acpithinkpad0.temp3=47.00 degC
> hw.sensors.acpithinkpad0.temp4=47.00 degC
> hw.sensors.acpithinkpad0.temp5=47.00 degC
> hw.sensors.acpithinkpad0.temp6=47.00 degC
> hw.sensors.acpithinkpad0.temp7=47.00 degC
> hw.sensors.acpithinkpad0.fan0=2121 RPM
> hw.sensors.acpithinkpad0.indicator0=Off (port replicator), UNKNOWN
> hw.sensors.softraid0.drive0=online (sd3), OK
> hw.cpuspeed=2901
> hw.setperf=100
> hw.vendor=LENOVO
> hw.product=2392ASU
> hw.version=ThinkPad T530
> hw.serialno=PK2X772
> hw.uuid=81c1c6e7-7653-cb11-b4d1-97bd37f8963e
> hw.physmem=16845565952
> hw.usermem=16811044864
> hw.ncpufound=4
> hw.allowpowerdown=1
> hw.perfpolicy=auto
> hw.smt=1
> hw.ncpuonline=1
> 

Re: OpenBSD 6.3 syspatch

[Edgar Pettijohn]

On Apr 7, 2019 10:03 AM, Monah Baki  wrote:
>
> Hi all,
>
> I am running OpenBSD 6.3 in AWS, and I want to run sysptach since
> https://www.openbsd.org/errata63.html shows several patches exist.
>
> So on the openbsd 6.3 server I ran the following;
>
> uname -a displays OpenBSD ip-10-0-0-108.ec2.internal 6.3 GENERIC.MP#107
> amd64
>
> ip-10-0-0-108# syspatch -l
> 001_perl
> 002_libtls
> 003_arp
> 004_gif
> 005_httpd
> 006_ipseclen
> 007_libcrypto
> 008_ipsecout
> 009_libcrypto
> 010_intelfpu
> 011_perl
> 012_execsize
> 013_ipsecexpire
> 014_amdlfence
> 016_fpuinit
> 017_fpufork
> 018_vmml1tf
>
> ip-10-0-0-108# syspatch -c
> ip-10-0-0-108#
>
>
> Why there was no results for fix 19-32 for 6.3.
>
> Thanks
> Monah

I suspect your mirror may be missing them. Which mirror do you use?

OpenBSD 6.3 syspatch

[Monah Baki]

Hi all,

I am running OpenBSD 6.3 in AWS, and I want to run sysptach since
https://www.openbsd.org/errata63.html shows several patches exist.

So on the openbsd 6.3 server I ran the following;

uname -a displays OpenBSD ip-10-0-0-108.ec2.internal 6.3 GENERIC.MP#107
amd64

ip-10-0-0-108# syspatch -l
001_perl
002_libtls
003_arp
004_gif
005_httpd
006_ipseclen
007_libcrypto
008_ipsecout
009_libcrypto
010_intelfpu
011_perl
012_execsize
013_ipsecexpire
014_amdlfence
016_fpuinit
017_fpufork
018_vmml1tf

ip-10-0-0-108# syspatch -c
ip-10-0-0-108#


Why there was no results for fix 19-32 for 6.3.

Thanks
Monah

Re: question about unwind

[Peter J. Philipp]

Hi,

hold off on this question I may have located something wrong in my
authoritative dns server that I program and maintain.

dig @yellow.centroid.eu +dnssec 2019.schweinfurtdating.de 

gives a wrong answer and has nothing to do with unwind.  Sorry partially
because it made me look closer, but sorry for the noise.

Regards,
-peter

On Sun, Apr 07, 2019 at 04:06:20PM +0200, Peter J. Philipp wrote:
> Hi,
> 
> A few days ago I had some trouble resolving my website schweinfurtdating.de
> from home.  Chrome running on OpenBSD-current from March 18th would report
> NXDOMAIN.  I had to reload a few times to get the webpage, it was a weird
> experience.  Since I run a very unique dns setup with TSIG'ed BIND nameservers
> at first I thought it was anywhere between application layer and those servers
> inbetween.
> 
> However when I checked schweinfurtdating.de today the image refused to load 
> and I found that very weird.  I happen to run a log of the lookups and found 
> this:
> 
> Apr  7 15:30:09 yellow delphinusdnsd[9644]: request on descriptor 16 
> interface "
> 2001:19f0:6c01:1fad::1" from 2003:cb:3fff:4c23:b7c7:eef2:da93:5f15 (ttl=56, 
> regi
> on=8) for "2019.schweinfurtdating.de." type=(28) class=1, edns0, 
> dnssecok, a
> nswering "2019.schweinfurtdating.de." (54/54) 
>  
> Apr  7 15:30:09 yellow delphinusdnsd[85741]: request on descriptor 3 
> interface "
> 2001:19f0:6c01:1fad::1" from 2003:cb:3fff:4c23:b7c7:eef2:da93:5f15 (ttl=TCP, 
> reg
> ion=8) for "2019.schweinfurtdating.de." type=(28) class=1, edns0, 
> dnssecok,
>  answering "2019.schweinfurtdating.de." (54/56)   
>  
> Apr  7 15:30:09 yellow delphinusdnsd[9644]: request on descriptor 16 
> interface $
> 2001:19f0:6c01:1fad::1" from 2003:cb:3fff:4c23:b7c7:eef2:da93:5f15 (ttl=56, 
> reg$
> on=8) for "de.centroid.eu." type=A(1) class=1, edns0, dnssecok, answering 
> "NXDO$
> AIN" 
> 
> So there is a lookup right after 2019.schweinfurtdating.de from the same IP6 
> that isn't even in my forwarders and my server replied with NXDOMAIN.  I 
> hunted through my html text to see
> where it got de.centroid.eu from and it doesn't exist.  So I'm wondering if
> unwind is somehow generating the lookup for de.centroid.eu falsely and somehow
> influencing chrome?  Perhaps treating a lookup as an NXDOMAIN'ed answer?
> 
> My /etc/unwind.conf file looks like this:
> 
> beta$ more /etc/unwind.conf
> forwarder 192.168.177.3
> 
> And somehow unwind is not preferring the forwarder for some reason.  Is this
> a misconfig on my end?   I want it to always use 192.168.177.3, as otherwise
> the DNS travels through DTAG (telekom.de), and I don't want that.  The log
> does state though it came from DTAG.
> 
> Many questions in one, I'm trying to figure out what went wrong that day and
> this lookup today.
> 
> Regards,
> -peter

question about unwind

[Peter J. Philipp]

Hi,

A few days ago I had some trouble resolving my website schweinfurtdating.de
from home.  Chrome running on OpenBSD-current from March 18th would report
NXDOMAIN.  I had to reload a few times to get the webpage, it was a weird
experience.  Since I run a very unique dns setup with TSIG'ed BIND nameservers
at first I thought it was anywhere between application layer and those servers
inbetween.

However when I checked schweinfurtdating.de today the image refused to load 
and I found that very weird.  I happen to run a log of the lookups and found 
this:

Apr  7 15:30:09 yellow delphinusdnsd[9644]: request on descriptor 16 interface "
2001:19f0:6c01:1fad::1" from 2003:cb:3fff:4c23:b7c7:eef2:da93:5f15 (ttl=56, regi
on=8) for "2019.schweinfurtdating.de." type=(28) class=1, edns0, dnssecok, a
nswering "2019.schweinfurtdating.de." (54/54)  
Apr  7 15:30:09 yellow delphinusdnsd[85741]: request on descriptor 3 interface "
2001:19f0:6c01:1fad::1" from 2003:cb:3fff:4c23:b7c7:eef2:da93:5f15 (ttl=TCP, reg
ion=8) for "2019.schweinfurtdating.de." type=(28) class=1, edns0, dnssecok,
 answering "2019.schweinfurtdating.de." (54/56)
Apr  7 15:30:09 yellow delphinusdnsd[9644]: request on descriptor 16 interface $
2001:19f0:6c01:1fad::1" from 2003:cb:3fff:4c23:b7c7:eef2:da93:5f15 (ttl=56, reg$
on=8) for "de.centroid.eu." type=A(1) class=1, edns0, dnssecok, answering "NXDO$
AIN" 

So there is a lookup right after 2019.schweinfurtdating.de from the same IP6 
that isn't even in my forwarders and my server replied with NXDOMAIN.  I 
hunted through my html text to see
where it got de.centroid.eu from and it doesn't exist.  So I'm wondering if
unwind is somehow generating the lookup for de.centroid.eu falsely and somehow
influencing chrome?  Perhaps treating a lookup as an NXDOMAIN'ed answer?

My /etc/unwind.conf file looks like this:

beta$ more /etc/unwind.conf
forwarder 192.168.177.3

And somehow unwind is not preferring the forwarder for some reason.  Is this
a misconfig on my end?   I want it to always use 192.168.177.3, as otherwise
the DNS travels through DTAG (telekom.de), and I don't want that.  The log
does state though it came from DTAG.

Many questions in one, I'm trying to figure out what went wrong that day and
this lookup today.

Regards,
-peter

hw.ncpu=1, hw.ncpuonline=1, hw.ncpufound=4

[Ipsen S Ripsbusker]

My hw.ncpu and hw.ncpuonline are less than my hw.ncpufound.
I tried setting hw.smt, but that alone was apparently not enough.
What should I do if I want to use all 4 CPUs?

Also, now that I have realized this, I have a theory about a related
issue, and I would like to know how I can debug it. I am using softraid
CRYPTO, and I have found that accessing the disk with one process will
interrupt the other processes accessing the disk. Now I wonder this
happens because the sole core must switch encryption/decription
processes for the different files. How could I determine whether this is
indeed happening?

More hardware information follows. It is a ThinkPad T530 with
two SSDs and two corresponding softraid CRYPTO disks.

$ sysctl hw
hw.machine=amd64
hw.model=Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
hw.ncpu=1
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0:c4ae9aa6707fe6a0,sd1:10319ae393cc594d,sd2:72b7961f3a883f2a,sd3:9067e68ce463822c
hw.diskcount=4
hw.sensors.cpu0.temp0=44.00 degC
hw.sensors.acpitz0.temp0=47.00 degC (zone temperature)
hw.sensors.acpibtn0.indicator0=On (lid open)
hw.sensors.acpibat0.volt0=11.10 VDC (voltage)
hw.sensors.acpibat0.volt1=12.11 VDC (current voltage)
hw.sensors.acpibat0.power0=0.00 W (rate)
hw.sensors.acpibat0.watthour0=28.20 Wh (last full capacity)
hw.sensors.acpibat0.watthour1=1.41 Wh (warning capacity)
hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity)
hw.sensors.acpibat0.watthour3=28.20 Wh (remaining capacity), OK
hw.sensors.acpibat0.watthour4=73.26 Wh (design capacity)
hw.sensors.acpibat0.raw0=0 (battery full), OK
hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.acpithinkpad0.temp0=47.00 degC
hw.sensors.acpithinkpad0.temp1=47.00 degC
hw.sensors.acpithinkpad0.temp2=47.00 degC
hw.sensors.acpithinkpad0.temp3=47.00 degC
hw.sensors.acpithinkpad0.temp4=47.00 degC
hw.sensors.acpithinkpad0.temp5=47.00 degC
hw.sensors.acpithinkpad0.temp6=47.00 degC
hw.sensors.acpithinkpad0.temp7=47.00 degC
hw.sensors.acpithinkpad0.fan0=2121 RPM
hw.sensors.acpithinkpad0.indicator0=Off (port replicator), UNKNOWN
hw.sensors.softraid0.drive0=online (sd3), OK
hw.cpuspeed=2901
hw.setperf=100
hw.vendor=LENOVO
hw.product=2392ASU
hw.version=ThinkPad T530
hw.serialno=PK2X772
hw.uuid=81c1c6e7-7653-cb11-b4d1-97bd37f8963e
hw.physmem=16845565952
hw.usermem=16811044864
hw.ncpufound=4
hw.allowpowerdown=1
hw.perfpolicy=auto
hw.smt=1
hw.ncpuonline=1

pppoe ipv6 default route

[Jérémi Dupin]

Hello,

I configured my dsl modem (D-Link 320b) as a bridge and my OpenBSD router talk 
to my isp with
pppoe.

My hostname.pppoe0 look like the manual :

inet 0.0.0.0 255.255.255.255 NONE \
  pppoedev em0 authproto pap \
  authname 'testcaller' authkey 'donttell' up
dest 0.0.0.1
inet6 eui64
!/sbin/route add default -ifp pppoe0 0.0.0.1
!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0

This work fine but every few days (when the line disconnect), the default ipv6 
route go away (the
ipv4 route stay).

I try to play with pppd options and with the "ip-up" script with no success. 
Here is my pppd
options file :

lock
auth
usehostname

Actually I add ipv6 route hourly. Do you have cleaner solution ?

All the best
Jérémi DUPIN

Re: how run pkg_check with a trusted kernel (a bit of forensics) and how to check kernel integrity.

[Cord]

On Saturday, April 6, 2019 3:30 PM, Marc Espie  wrote:

> On Sun, Mar 31, 2019 at 03:24:58PM +, Cord wrote:
>
> > Hi,
> > I'd like to run pkg_check but from a live usb stick. This because I want to 
> > run a trusted kernel.
> > Maybe I just need to mount the root, mount the other slices and chroot 
> > /bin/ksh ?
> > Also¹, is there a way to download all the installed pkg and check the signs 
> > from them ?
> > Also² , how can I check the kernel integrity ?
> > thank you.
>
> What you're asking for is highly underspecified.
>

I try to explain what I want to do. If I have a kernel rootkit there could be 
some hidden file or the kernel rootkit module itself or some altered binary.
Then I want to boot from a usb stick with installed openbsd that should be 
clean and trusted. Then work with this kernel on the "maybe infected openbsd 
installation" but in a chroot environment. I mean from inside the infected 
system but with the kernel of the live trusted usb stick. Then the first job to 
do is run pkg_check to check the integrity of the installed packages, with 
sha256 hash. pkg_check can also show me the extraneous file with the flag -F. 
Anyway the hashes of the all files that come with the packeage could be altered 
or missing then I'd like to download all the installed packages and extract the 
original and trusted hashes. Then check again the "maybe infected system" to 
verify the integrity from what is installed and what should be installed.
After that I want make some other check. Something like aide or other hids but 
in more basic way:
find / -type f -exec sha256 '{}' ';' >> mysystem.sha256
from three different point of view:
- from the runtime system
- from the live usb stick
- from the live usb stick in a chroot environment
then check the differences from the three snapshot.
Anyway the problem is the kernel. I mean the bare kernel file could not be the 
original.. could be patched and all my previous check could not show anything. 
And because of the relinkg of the kernel I cannot just download a original 
kernel and check the differences with the installed one. Then I ask how can I 
check that the installed kernel  is trusted ?

> You would have to explain your trust model in detail, and what you intend
> to store away for later checking.
>
> A "trusted kernel" won't protect you from a fishy userland in any way...

for fishy you mean a generic userland malware  or anything more specific ?


Thank you, Cord

Re: [PATCH] Remove "Multibooting" in FAQ

[frantisek holop]

tfrohw...@fastmail.com - Sat, 06 April 2019 at 17:45:42
> I run a dual-boot with Windows 10 on the same partition and the

on the same partition?

-f
-- 

Re: [PATCH] Remove "Multibooting" in FAQ

[frantisek holop]

Thomas Frohwein - Sat, 06 April 2019 at 12:54:54
> I remember the following as the steps not mentioned in the FAQ that helped me
> get it to work. All with MBR and Windows 10.
>
> 1. Shrink the main partition in Windows disk manager and create a second
>partition.

the FAQ cannot deal with every possible setup...
having a partition on the disk where you want to put openbsd is kind of
a basic requirement (just like having a computer), and how you get there
is case by case specific.


but why would you want to go back to MBR?
new notebooks with windows 10 come with GPT.

the only real PITA at the moment is that openbsd fdisk cannot add new
GPT partitions only edit existing ones.  many OEM windows notebooks
already come with 4-5 GPT partitions:

1. the 300MB EUFI
2. the 128MB MSR
3. the primary OS partition (normally C:)
4. WinRE (recovery tools)
5. BIOS_RVY (recovery image)
(my notebook even had a data (D:) between 4 and 5...)

so you need to have the partition destined for openbsd present,
then it's possible to edit it in fdisk.

-f
-- 

Re: Broken links on http://www.openiked.org/

[Alex Naumov]

Thanks.

By the way, that would be great to have openiked in www CVS ;-)

Have a nice weekend,
Alex

On Sat, Apr 6, 2019 at 12:32 AM Reyk Floeter  wrote:

> Thanks, I’m afk this weekend but I’ll take care afterwards.
>
> Reyk
>
> > Am 05.04.2019 um 19:24 schrieb Alex Naumov <
> alexander_nau...@opensuse.org>:
> >
> > Hey,
> >
> > it seems openiked.org is not maintained well.
> > 1. Copyright is just until 2015.
> > 2. There are some broken links on it: links to "CD's" and "Posters".
> > 3. Old links-format for man.openbsd.org is used.
> >
> > Cheers,
> > Alex
>
>