Re: Openbsd 7.1 installation - disk boot record
Well, I installed 7.0 (*not* 7.1) on my desktop (old Haswell mobo) - it rendered computer unstartable (not unbootable). Mobo hung so hard it couldn't even enter the BIOS. I think I was lucky I didn't install it on my PCIe-card NVMe... It would be shitty to need it hot-plugged to a working computer to fix. I was able to do that as Michael did (unplug, boot other OS, hot-plug, wipe OpenBSD partition, fix UEFI order). And I'm pretty used to fact, that a bootable pendrive with OpenBSD installer (.fs image) renders old HP laptops (ProBooks, EliteBooks from 2-ish gen Cores era) unbootable in the very same way (hard lock, can't enter BIOS). I suppose this behavior might have some common root cause. -- Paweł Kraszewski GPG key: E030 A049 9C33 C1E9 28EA 50C9 821F DA62 0A90 D330 Tel: +48(604)777447 czw., 28 kwi 2022 o 03:37 napisał(a): > > > Hello, > > > > Today I tried to do a fresh install of openbsd 7.1. (from usb pendrive). I > > tried to do a very basic install (accepting the default - without network > > - with sets from disk) and when getting to the root disk question I used > > (W)hole disk MBR. Everything went through smoothly, however when rebooting > > the system the initial boot sequence goes into an endless loop > > (manufacture logo appearing again and again) - also cannot enter bios > > setup anymore. Had to remove the ssd, connect via usb and dd with zero the > > first mb. Tried several things i.e. changing bios options, upgrading bios > > to latest version, using uefi etc nothing worked. Always same endless boot > > loop. > > > > After some time I found a work around by installing from the 7.0 > > installation image and then upgrading to 7.1. Everything works now. > > > > Does anyone know why this might be happening? It would seem that changes > > to fdisk did change the MBR (or how it is written) which at least on my > > machine - old dell e7240 - is preventing it from booting. > > > > Any help is highly appreciated. > > > > Thanks, Michael > > > > P. S. Not sure if this is a bug and if it should be reported. > > > > Hello > > I had a similar situation with an old Dell: > > The installation of 7.1 went correctly, but when i did a reboot; the > machine said that there were not a disk! > > Then i tried to install 7.0 and the installer gave me a > point! in the > section available disk. > > Is there a form to reestablish the MBR using the installer? > > PD: > Testing i deleted the loop partition with Gparted, and added different new > mbr. Nothing changed. > > Thanks OpenBSD team I feel happy using 7.1 on 3 vms. > > Curiosity question: > 2 of my vms show UTC with # date, and 1 shows the local time; during the > installation, i marked local time Canada/Pacifi; in all of them, which i > can see with: # > date -z Canada/Pacific. > > Thanks. > > >
Re: tcpdump rotating issue with newsyslog
First: as others mentioned, tcpdump isn't suited for output rotation via tools like newsyslog. Even if you manage to restart it with new log, you'll probably skip some packets. You might implement some sort of overlap (you start tcpdump to a new file, *then* you kill the old one and write a tool to seamlessly merge flows) Second: Non-OpenBSD tcpdump support -C/-G/-W options that do the rotation automatically (size- and age-based). I don't know if it may be backported. Third: Are you sure you want long-running tcpdump? Perhaps netflow could be enough... See pflow(4) + nfcapd(1). The latter does autorotation and can call compressor afterwards. -- Paweł Kraszewski GPG key: E030 A049 9C33 C1E9 28EA 50C9 821F DA62 0A90 D330
Re: ipsec traffic is dropped between two machines
Problem with service working after cross-pinging the other sides seems like some stateful firewall that needs a nudge from inside. -- Paweł Kraszewski
Re: Re : iked + sasyncd + carp - doesn't take over
I have some more info (this time from physical machines): After a switchover I can see incoming flow on enc0 on the new master, and it IS decoded correctly. It is just not pushed out into the protected network. Additionally, the replay counters seem to be all in sync except for one - return tunnel to client on a backup node has replay counter inreased by 16384 (for example replay: rpl 167 on master and replay: rpl 16551 on backup). -- Paweł Kraszewski
Re: Re : iked + sasyncd + carp - doesn't take over
Things look like that: When cluster is up and client is connected: 1/ output of "ipsecctl -v -sa" is perfectly in sync between nodes. 2/ output of "pfctll -sstates" is sync between nodes within 1s delay (as expected) 3/ output of "ikectl sh sa" is *not* in sync between nodes. Passive node has null output (I don't know if expected) I run both sasyncd and iked with -vv, so logging is beefy. Connection seen from ACTIVE side: Mar 4 12:33:57 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: recv IKE_SA_INIT req 0 peer 192.168.1.46:39248 local 192.168.1.160:500, 716 by tes, policy 'win7' Mar 4 12:33:57 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_sa_responder_dh: want dh CURVE25519, KE has ECP_256 Mar 4 12:33:57 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_resp_recv: failed to negotiate IKE SA Mar 4 12:33:57 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_add_error: INVALID_KE_PAYLOAD Mar 4 12:33:57 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: send IKE_SA_INIT res 0 peer 192.168.1.46:39248 local 192.168.1.160:500, 38 byt es Mar 4 12:33:57 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: recv IKE_SA_INIT req 0 peer 192.168.1.46:39248 local 192.168.1.160:500, 684 by tes, policy 'win7' Mar 4 12:33:57 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: send IKE_SA_INIT res 0 peer 192.168.1.46:39248 local 192.168.1.160:500, 239 by tes Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: recv IKE_AUTH req 1 peer 192.168.1.46:43052 local 192.168.1.160:4500, 413 byte s, policy 'win7' Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_pld_eap: REQUEST id 0 length 5 EAP-IDENTITY Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: send IKE_AUTH res 1 peer 192.168.1.46:43052 local 192.168.1.160:4500, 1301 byt es, NAT-T Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: recv IKE_AUTH req 2 peer 192.168.1.46:43052 local 192.168.1.160:4500, 70 bytes , policy 'win7' Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_pld_eap: RESPONSE id 0 length 9 EAP-IDENTITY Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_pld_eap: REQUEST id 1 length 31 EAP-MSCHAP_V2 Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: eap_parse: MSCHAP_V2 CHALLENGE id 1 length 26 valuesize 16 name '_iked' length 5 Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: send IKE_AUTH res 2 peer 192.168.1.46:43052 local 192.168.1.160:4500, 92 bytes , NAT-T Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: recv IKE_AUTH req 3 peer 192.168.1.46:43052 local 192.168.1.160:4500, 124 byte s, policy 'win7' Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_pld_eap: RESPONSE id 1 length 63 EAP-MSCHAP_V2 Mar 4 12:33:58 ipsec1 iked[6487]: eap_parse: MSCHAP_V2 RESPONSE id 1 length 58 valuesize 49 name 'test' name-length 4 Mar 4 12:33:58 ipsec1 iked[6487]: ikev2_resp_ike_eap_mschap: 'test' authenticated Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_pld_eap: REQUEST id 2 length 61 EAP-MSCHAP_V2 Mar 4 12:33:58 ipsec1 iked[6487]: eap_parse: MSCHAP_V2 SUCCESS request id 1 length 56 message 'S=A8F1DF4F002779CC93AB39252353681F96C B M=Welcome' message-len 52 Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: send IKE_AUTH res 3 peer 192.168.1.46:43052 local 192.168.1.160:4500, 122 byte s, NAT-T Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: recv IKE_AUTH req 4 peer 192.168.1.46:43052 local 192.168.1.160:4500, 67 bytes , policy 'win7' Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_pld_eap: RESPONSE id 2 length 6 EAP-MSCHAP_V2 Mar 4 12:33:58 ipsec1 iked[6487]: eap_parse: MSCHAP_V2 SUCCESS response Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_pld_eap: SUCCESS id 2 length 4 Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: send IKE_AUTH res 4 peer 192.168.1.46:43052 local 192.168.1.160:4500, 65 bytes , NAT-T Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: recv IKE_AUTH req 5 peer 192.168.1.46:43052 local 192.168.1.160:4500, 97 bytes , policy 'win7' Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: assigned address 10.1.0.190 to FQDN/test Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: send IKE_AUTH res 5 peer 192.168.1.46:43052 local 192.168.1.160:4500, 213 byte s, NAT-T Mar 4 12:33:58 ipsec1 sasyncd[3474]: net_send_messages: msg 0x62f175f8000 len 336 ref 1 to peer 10.0.1.162 Mar 4 12:33:58 ipsec1 sasyncd[3474]: net_send_messages: freeing msg 0x62f175f8000 Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_childsa_enable: loaded SPIs: 0xe56d3eef, 0x2f538456 (enc aes-128-gcm) Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: ikev2_childsa_enable: loaded flows: ESP-10.0.0.0/24=10.1.0.190/32(0) Mar 4 12:33:58 ipsec1 iked[6487]: spi=0x47c4ccf08d9d8699: established peer 192.168.1.46:43052[FQDN/test] local 192.168.1.160:4500[FQDN/v pn.my.domain] assigned 10.1.0.190 policy 'win7' as responder (enc aes-128-gcm group curve25519 prf hmac-sha2-256) Mar
iked + sasyncd + carp - doesn't take over
Hello!
I'm trying to build a redundant IPSEC VPN concentrator.
What have I done by now:
* I have a working CARP. Verified from each side. 1-2 pings lost.
Works as expected.
* I have a working iked deployment. Test client can connect, sees
internal network as expected.
* I have a working pfsync. Pf states are replicated between nodes.
* I have a working sasyncd. Flows and SADs are replicated between nodes.
What doesn't work:
When the client is connected to a virtual CARP endpoint and I perform
a switchover, the new master doesn't pick up the communication.
NAT-t packages do come to a valid host, they are just not processed.
Iked compains with "ikev2_child_sa_acquire: flow wasn't found"
The full relevant configuration files follow:
Topology:
2 Identical Qemu's, OpenBSD 7.0, no conflicting MAC addresses
em0-s bridged together -> (WAN) -> strongswan on mobile phone
em1-s bridged together -> (LAN) -> IP to ping from mobile
em2-s bridged together -> (sync)
-
sysctl.conf
net.inet.carp.preempt=1
net.inet.ip.forwarding=1
-
hostname.carp0 (differences with | , hosts A|B)
inet 192.168.1.160 255.255.255.0 192.168.1.255 \
carpdev em0 \
group VPN \
pass passwd \
vhid 1 \
advskew 0|100
-
hostname.carp1
inet 10.0.0.254 255.255.255.0 10.0.0.255 \
carpdev em1 \
group VPN \
pass passwd \
vhid 2 \
advskew 0|100
-
hostname.em0
inet 192.168.1.161|162 255.255.255.0 NONE
-
hostname.em1
inet 10.0.0.161|162 255.255.255.0 NONE
-
hostname.em2
inet 10.0.1.161|162 255.255.255.0
-
hostname.enc0
inet 10.1.0.254 255.255.255.0
-
hostname.pfsync0
up \
syncdev em2 \
syncpeer 10.0.1.162|161
-
iked.conf
user "test" "password123"
set mobike
set enforcesingleikesa
set passive
ikev2 "VPN" esp \
from 10.0.0.0/24 to dynamic \
local 192.168.1.160 \
srcid vpn.my.domain \
eap "mschap-v2" \
config address 10.1.0.0/24 \
tag "$name-$id"
-
sasyncd.conf
peer 10.0.1.162|161
control iked
group VPN
interface carp0
listen on em2
sharedkey TAKEN_FROM_EXAMPLE
-
rc.conf.local
iked_flags=
ipsec=YES
sasyncd_flags=
ntpd_flags=NO
-
pf.conf
set skip on lo
pass quick on { em2 } proto pfsync keep state (no-sync)
pass on { em0 em1 } proto carp keep state (no-sync)
block return # block stateless traffic
pass # establish keep-state
block return in on ! lo0 proto tcp to port 6000:6010
block return out log proto {tcp udp} user _pbuild
pass in on em0 proto udp from any to (em0) port {isakmp, ipsec-nat-t}
tag IKED keep state
pass in on em0 proto esp from any to (em0) tag IKED keep state
pass in on em0 from (em0:network) to any
pass in on em1 from (em1:network) to any
pass in on em2 from (em2:network) to any
-
What do I miss?
Best regards,
--
Paweł Kraszewski
Re: HP notebook and wired temperatures
> The HP machines tend to have very complicated AML with heavy SMI and > EC dependencies. Another vendor which leans this way sometimes is > Sony. > > Some machines do have AML bugs, and the Microsoft/Intel ACPI code > bases certainly have workarounds for those problems. > > Some machines simply use corner areas of ACPI that we handle > incorrectly. It takes a lot of effort to find these corner cases and > handle them correctly. I'm digging through Google to find exact error on FreeBSD I enountered, exact walkaround that (sort of) helped and suspected cause. I remember faintly it was AML construction that failed. -[tick tock]- Cant't find it, sorry. I don't remember exact panic data that helped me find solution. But AFAIR cure was to disable acpica driver. OTOH, It is BSD that is right. BSDs keep in line with standards. It is HP that screws things up (for years). I understand - mountain won't come to BSD, it is BSD that shall go to the the mountain. This is politics. I hate politics. I have a dream: someone at HP would say "We are dumbasses. Let's fix BIOS and be such no more". Paul -- P.S. And as Theo & the crew is on thread: thanks for OpenBSD as a whole. Thanks for keeping it small. Thanks for keeping it simple. Thanks for keeping it powerful. Thanks for manual being so ingenious.
Re: HP notebook and wired temperatures
2013/6/7 Sven Gaerner : > Thanks, I guessed it's an ACPI problem and not an OpenBSD one. But I > thought one can tell OpenBSD to ignore that useless values. I stuggle with HP crap at work - pretty recent and expensive one. FreeBSD just hangs hard during bootup. There is an "official" solution - disable ACPI part dealing with SMP and run OS single-core :) And still BSD shows rather hellish temps. That's why I strongly discourage co-workers, friends and family to buy _any_ HP devices. > Telling HP that they implemented ACPI the wrong way is IMHO useless. They > just don't care. And the notebook is about 6.5 years old. Their standard answer is "Yes, we know. All three users of BSD are indignant". Paul
Re: HP notebook and wired temperatures
2013/6/7 Sven Gaerner : > I installed OpenBSD 5.3 i386 on my HP nc6400 notebook. Now when booting > the system, the kernel prints > acpitz3: critical temperate exceeded (3290 C): shutting down. > > This temperature (3290 C) is shown after starting a system that was > powered off for several hours. After finishing the installation the > reported temperature was about 4180 C. > > The other BSDs also report wired temperates but not that high. Some > years ago Linux reported about 55 C for the CPU which seems to be > a more realistic value. This is just a next chapter of never-ending story of HP screwing up ACPI tables. This is not OS's fault - it just shows what hardware sends. Send an email to HP telling them to fix this crap (broken for well over 10 years). Greets, Paul.
