Re: Tor daemon is unable to connect to the Tor network

[Matt Wehowsky]

On 2023-03-12 09:53 AM, Stuart Henderson wrote:
> I don't think the problem you're seeing is related to login.conf but a
> few comments on that,
>
> ...
>
> I suggest removing login.conf.db (it is not created by default) and not
> using cap_mkdb, to avoid any problems with the db file getting out of
> sync after other changes. You probably want to override openfiles-cur as
> well, not just -max.

Done. Thanks for the insight, Stuart.

> Note any daemon-specific config here will only be used automatically if
> you're running it via rcctl or the rc.d script. (If you run it "by hand"
> you can set the login class with su -c or sudo -c).

I’m aware of that, but thank you for clarification nonetheless.

> It doesn't help your problem with obfs4proxy but snowflake_proxy is for
> providing access to others; you want snowflake_client (it's in -current
> but was not built in the package until after 7.2-release).

Thank you for the heads up! That was quite a revelation to me that this
particular package gets shipped with three binaries for different
purposes—should’ve taken advantage of pkg_info’s -L option, my bad.

I’ve just upgraded to 7.3-beta and updated the snowflake_proxy package
to version 2.5.1; here’s the updated contents of my torrc file:

  $ grep '^[A-Z]' /etc/tor/torrc
  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor
  UseBridges 1
  ClientTransportPlugin snowflake exec /usr/local/bin/snowflake_client
  Bridge snowflake 192.0.2.3:1 
url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ 
front=cdn.sstatic.net 
ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478

Tor keeps spewing logs of the same kind, however. Nothing has changed. I
have no idea as to what else can be done to make Tor start building
circuits.

I would’ve posted on Tor mailing lists if I had experienced the same
issues on my GNU/Linux machine as well as on my Android device, but
things appear to be working there just fine. Can you or anybody else
reading this message give me some insight into ways of finding the root
of the problem? I’m at a loss here. Many thanks in advance.

Tor daemon is unable to connect to the Tor network

[Matt Wehowsky]

Hey @misc,

Here’s a brief rundown of what I’ve been dealing with:

  * tor(1) works flawlessly on my GNU/Linux machine with the exact same
torrc configuration file, yet it fails miserably on my 64-bit
netbook (amd64) running -current branch of OpenBSD 7.2

  * Raised the value of kern.maxfiles to 16000 and increased the maximum
number of open files Tor daemon can utilise, running cap_mkdb(1) on
the login.conf(5) file afterwards

  * Attempted to connect to the Tor network by using obfuscated bridges
as well as by giving snowflake proxy a shot—nothing has changed

  * Tried disabling the firewall—to no avail

Since tor(1) works as expected on my GNU/Linux machine, I assume it’s
not about the configuration file being invalid or something like that,
though I tried using the vanilla torrc as well as making changes to it
in a gradual way. Here goes the first snippet:

  $ grep '^[A-Z]' /etc/tor/torrc
  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor

Here’s the second one in which I’m using obfs4proxy(1) without
specifying any bridges:

  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor
  ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy --enableLogging 
--logLevel=DEBUG

Here’s the third one, using snowflake:

  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor
  ClientTransportPlugin snowflake exec /usr/local/bin/snowflake_proxy
  UseBridges 1
  Bridge snowflake 192.0.2.3:1 
url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ 
front=cdn.sstatic.net 
ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478

And here goes the final snippet:

  Log notice syslog
  RunAsDaemon 1
  DataDirectory /var/tor
  User _tor
  UseBridges 1
  ClientTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy --enableLogging 
--logLevel=DEBUG
  Bridge obfs4 123.456...
  Bridge obfs4 123.456...
  Bridge obfs4 123.456...

NTP daemon states that clock is synchronised:

  $ grep 'clock is now' /var/log/daemon | tail -1
  Mar 11 08:56:18 net ntpd[31223]: clock is now synced

Some logs produced by obfs4proxy(1):

  # cat /var/tor/pt_state/obfs4proxy.log
  2023/03/11 09:12:29 [NOTICE]: obfs4proxy-0.0.14 - launched
  2023/03/11 09:12:29 [INFO]: obfs4proxy - initializing client transport 
listeners
  2023/03/11 09:12:29 [INFO]: obfs4 - registered listener: 127.0.0.1:27287
  2023/03/11 09:12:29 [INFO]: obfs4proxy - accepting connections

Weirdly enough, snowflake appears to be working, but tor(1) is still
unable to start building circuits:

  $ grep 'snowflake_proxy' /var/log/daemon | tail -1
  Mar 11 10:32:36 net snowflake_proxy[29766]: 2023/03/11 10:32:36 In the last 
1h0m0s, there were 15 connections. Traffic Relayed IN 36748 KB, OUT 7983 KB.

Some details of the tor class from login.conf(5):

  $ sed -n '/^tor:/,/^$/p' /etc/login.conf
  tor:\
  :openfiles-max=8192:\
  :tc=daemon:

Finally, here’s the Tor-related snippet taken from /var/log/daemon:

  Mar 11 10:45:11 net Tor[60413]: Tor 0.4.7.13 running on OpenBSD with Libevent 
2.1.12-stable, OpenSSL LibreSSL 3.7.1, Zlib 1.2.13, Liblzma N/A, Libzstd N/A 
and Unknown N/A as libc.
  Mar 11 10:45:11 net Tor[60413]: Tor can't help you if you use it wrong! Learn 
how to be safe at https://support.torproject.org/faq/staying-anonymous/
  Mar 11 10:45:11 net Tor[60413]: Read configuration file "/etc/tor/torrc".
  Mar 11 10:45:11 net Tor[60413]: Opening Socks listener on 127.0.0.1:9050
  Mar 11 10:45:11 net Tor[60413]: Opened Socks listener connection (ready) on 
127.0.0.1:9050
  Mar 11 10:45:11 net Tor[60413]: Parsing GEOIP IPv4 file 
/usr/local/share/tor/geoip.
  Mar 11 10:45:12 net Tor[60413]: Parsing GEOIP IPv6 file 
/usr/local/share/tor/geoip6.
  Mar 11 10:45:14 net Tor[60413]: We were built to run on a 64-bit CPU, with 
OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks 
accelerated support for the NIST P-224 and P-256 groups. Building openssl with 
such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) 
would make ECDH much faster.
  Mar 11 10:45:14 net Tor[60413]: Bootstrapped 0% (starting): Starting
  Mar 11 10:45:20 net Tor[60413]: Starting with guard context "bridges"
  Mar 11 10:45:20 net Tor[60413]: Delaying directory fetches: No running bridges

I would like to reiterate that the firewall has remained being turned
off over the course of these shenanigans, so it’s not about firewall
being the culprit; it’s not about torrc file being invalid either. As
for obfs4proxy(1), it seems to be accepting incoming connections along
with the snowflake proxy.

I realise that such issues keep arising due to my limited knowledge of
the nuts and bolts of the OS, but I look forward to expanding it by
asking for clues and possible hints here on the ma

OpenBGDP IPv6 ignoring set localpref parameter

[Matt]

Hello list,

 

I've run across an interesting issue which I think might be something I did
wrong but here goes. Below is my configuration file for bgpd.conf. I will
also give you the interface configurations for the two tunnels that I am
running. When I show the RIB using bgpctl show rib, I notice that the set
localpref parameter is not being applied properly to IPv6.

 

#/etc/hostname.wg0

wgkey 

wgpeer  wgendpoint 47.87.173.98 21764 wgaip
192.168.220.190/32 wgaip 172.20.53.98/32 wgaip 172.20.0.0/14 wgaip
fe80::ade1 wgaip fe80::ade0 wgaip fd00::/8 wgpka 20

inet 192.168.220.190/32

inet6 fe80::ade1%wg0

descr "TO-KIOUBIT"

up

!route add -host 172.20.53.98 192.168.220.190

!route add -inet6 fe80::ade0 fe80::ade1%wg0

!route add -inet6 fd00::/8 fe80::ade1%wg0

 

#/etc/hostname.gre0

172.21.83.84 172.21.83.85

tunnel 173.49.42.100 81.2.241.46

descr "TO-NOP.HU"

up

!ifconfig gre0 inet6 fd40:cc1e:c0de::252 fd40:cc1e:c0de::251

 

#/etc/bgpd.conf

ASN="4242421764"

 

AS $ASN

router-id 192.168.220.190

 

prefix-set mynetworks {

172.20.165.192/27

fd0b:7449:62d2::/48

}

 

prefix-set nothankyou {

10.0.0.0/8

}

 

network prefix-set mynetworks set large-community $ASN:1:1

 

 

group "kioubit" {

set localpref 20

neighbor 172.20.53.98 {

remote-as 4242423914

descr "TO-KIOUBIT-IPV4-US2"

}

 

neighbor fe80::ade0 {

remote-as 4242423914

descr "TO-KIOUBIT-IPV6-US2"

}

}

 

group "mc36" {

   set localpref 10

neighbor 172.21.83.85 {

remote-as 4242421955

descr "TO-NOP.HU-IPV4"

}

 

neighbor fd40:cc1e:c0de::251 {

   remote-as 4242421955

descr "TO-NOP.HU-IPV6"

set localpref 10

}

}

 

deny quick from ebgp prefix-set mynetworks or-longer

deny quick from ebgp prefix-set nothankyou or-longer

deny quick from any max-as-len 8

 

allow to ebgp prefix-set mynetworks large-community $ASN:1:1

allow from ebgp ovs valid

 

match from ebgp set { large-community delete $ASN:*:* }

match from any community GRACEFUL_SHUTDOWN set { localpref 0 }

 

include "/etc/roa-set.conf"

 

When I type bgpctl show rib, I see that the route selected for IPv6 traffic
is going through the neighbor fd40:cc1e:c0de::251 and not fe80::ade0.
Ideally, I'd rather have IPv6 go through the neighbor fe80::ade0 as that one
is on my continent. Below is an example from the show rib statement. I don't
even know why the fe80::ade0 address is not even showing up in the output.

 

*>  V fd00:bb:5bf3::/48fd40:cc1e:c0de::25110 0 4242421955
4242423088 4242420549 i

V fd00:bb:5bf3::/48:: 20 0 4242423914
4242420549 i

 

I have verified that the neighbor fe80::ade0 is actually getting a
connection and sending me route updates. Here is an example:

 

V fdff:feed:c0de::/48  :: 20 0 4242423914 4242420585
4242422980 210074 64719 65043 4242420138 i

 

Any ideas?

 

Thanks,

Matt 

Re: Using OpenBSD as an L2TP client with A&A ISP

[Matt Dainty]

* Stuart Henderson  [2021-10-26 11:35:06]:
> On 2021-10-26, Matt Dainty  wrote:
> > I'm currently using OpenBSD with an Andrews & Arnold vDSL connection so I 
> > have
> > a pppoe(4) interface, etc. and this works for IPv4 & IPv6.
> >
> > The problem is because of the rubbish rural Openreach infrastructure here in
> > the UK I only get a stable 3.5 Mb/s, however another ISP (Voneus) has been
> > installing fibre in the area and can offer a 100+ Mb/s connection, but it 
> > looks
> > like their network is all sorts of CGNAT and they don't seem to offer IPv6
> > addresses.
> > 
> > So I figured I'll just use the A&A L2TP relay service and use this new fast
> > connection to tunnel all of my traffic between the two ISPs and maintain the
> > IPv4 & IPv6 addesses that A&A have assigned to me on my vDSL connection.
> >
> > Has anyone done this with OpenBSD? I understand xl2tpd is in ports but does
> 
> This (aaisp l2tp) is exactly why I wrote the port for xl2tpd, though in
> my case it was only for emergency use while a line was down.
> 
> > everything work through the tunnel, including IPv6? I saw mention about 8-9
> > years ago that the pppd(8) that xl2tpd uses doesn't do IPv6. Is that still 
> > the
> > case?
> 
> Yes that's still the case about pppd(8) and IPv6. Unfortunately pppd(8)
> upstream removed most OS support somewhere after the version we
> currently have so updating it is decidedly non-trivial (I think there
> might have been a few versions between ours, last real update in '98,
> and the last one with BSD support, but it's quite far from what
> upstream has now).

NetBSD looks like it has an IPv6-aware ppp(4) and pppd(8) but I haven't
peeked at the source at all, that's just from the man pages, I was still
at the stage of figuring out if this was even viable.

> AFAIK the only ppp code in OpenBSD that supports IPv6 inside PPP is pppoe(4).

I taught pppoe(4) about RFC 4638 which I've relied on since, but that was
9+ years ago so I've lost my familiarity with that code.

I'll have a look at the sources and do some research.

Cheers

Matt

Using OpenBSD as an L2TP client with A&A ISP

[Matt Dainty]

I'm currently using OpenBSD with an Andrews & Arnold vDSL connection so I have
a pppoe(4) interface, etc. and this works for IPv4 & IPv6.

The problem is because of the rubbish rural Openreach infrastructure here in
the UK I only get a stable 3.5 Mb/s, however another ISP (Voneus) has been
installing fibre in the area and can offer a 100+ Mb/s connection, but it looks
like their network is all sorts of CGNAT and they don't seem to offer IPv6
addresses.

So I figured I'll just use the A&A L2TP relay service and use this new fast
connection to tunnel all of my traffic between the two ISPs and maintain the
IPv4 & IPv6 addesses that A&A have assigned to me on my vDSL connection.

Has anyone done this with OpenBSD? I understand xl2tpd is in ports but does
everything work through the tunnel, including IPv6? I saw mention about 8-9
years ago that the pppd(8) that xl2tpd uses doesn't do IPv6. Is that still the
case?

Thanks

Matt

Trying to disable acpitz

[Matt Stark]

I'm trying to install OpenBSD 7.0 on a Dell Wyse 3040 (Intel Atom x86_64,
eMMC). Rebooting after the install hangs at the line:

acpitz on acpi0

Using boot -c results in the usb keyboard input not working at the
UKC> prompt. I can disable acpitz on a kernel running in a virtualmachine
and copy the kernel over, but then it hangs at the prompt:

root device:

Again with no usb keyboard input (boot -a results in the same).

I've tried both USB 2.0 and 3.0 ports with two different functioning USB 
keyboards
which work at the boot> prompt and during install, just not at the
UKC>/root device: prompts. PS/2 keyboard input and serial input are not
available on this hardware. The root device is eMMC, which is probably why
the kernel built in the virtual machine can't find the path/UID of the root
device. In the BIOS, there don't appear to be any options related to
enabling/disabling ACPI, temperature monitoring or a "legacy" USB mode.

Is there another way to install a kernel on this machine with acpitz disabled?
Alternatively, is there another way of specifying the root device?

dmesg from bsd.rd:

OpenBSD 7.0 (RAMDISK_CD) #219: Thu Sep 30 14:32:42 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 2039537664 (1945MB)
avail mem = 1973768192 (1882MB)
random: good seed from bootblocks
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7a9f4000 (50 entries)
bios0: vendor Dell Inc. version "1.2.5" date 08/20/2018
bios0: Dell Inc. Wyse 3040 Thin Client
acpi0 at bios0: ACPI 5.0
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI SSDT HPET SSDT 
SSDT SSDT LPIT BCFG PRAM BGRT CSRT WDAT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1440.33 MHz, 06-4c-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: apic clock running at 79MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
"INT33A4" at acpi0 not configured
sdhc0 at acpi0 SDHA addr 0x9152b000/0x1000 irq 45
sdhc0: SDHC 3.0, 200 MHz base clock
sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, ddr52, dma
"INTL9C60" at acpi0 not configured
"INTL9C60" at acpi0 not configured
"8086228A" at acpi0 not configured
dwiic0 at acpi0 I2C1 addr 0x91526000/0x1000 irq 32
iic0 at dwiic0
dwiic1 at acpi0 I2C2 addr 0x91524000/0x1000 irq 33
iic1 at dwiic1
"10EC5672" at iic1 addr 0x1c not configured
dwiic2 at acpi0 I2C3 addr 0x91522000/0x1000 irq 34
iic2 at dwiic2
dwiic3 at acpi0 I2C6 addr 0x9152/0x1000 irq 37
iic3 at dwiic3
dwiic4 at acpi0 I2C7 addr 0x9151e000/0x1000 irq 38
iic4 at dwiic4
chvgpio0 at acpi0 GPO1 uid 2 addr 0xfed88000/0x8000 irq 48, 59 pins
"INT33F5" at iic4 addr 0x5e not configured
"808622A8" at acpi0 not configured
acpicmos0 at acpi0
"PNP0C0C" at acpi0 not configured
chvgpio1 at acpi0 GPO0 uid 1 addr 0xfed8/0x8000 irq 49, 56 pins
chvgpio2 at acpi0 GPO2 uid 3 addr 0xfed9/0x8000 irq 50, 24 pins
chvgpio3 at acpi0 GPO3 uid 4 addr 0xfed98000/0x8000 irq 91, 55 pins
chvgpio4 at acpi0 GPO4 uid 5
"INT33BD" at acpi0 not configured
"ACPI000C" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT3400" at acpi0 not configured
"INT3403" at acpi0 not configured
"INT3406" at acpi0 not configured
"INT3403" at acpi0 not configured
acpicpu at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not con

Re: WireGuard host crashes roughly every week

[Matt P.]

Thanks so much Matt!

It works! I've reenabled PersistantKeepalive overnight and mbufs are staying 
low.

The failed handshakes are still occurring, "ifconfig wg0 debug" filled my dmesg 
with hundreds of lines like:

> wg0: Handshake for peer 10 did not complete after 5 seconds, retrying (try 6)
> wg0: Sending handshake initiation to peer 10
> wg0: Zeroing out keys for peer 10

But I don't have any evidence that this is hurting anything :)

--Matt

> On Aug 4, 2021, at 5:36 AM, Matt Dunwoodie  wrote:
> 
> On Tue, 3 Aug 2021 13:02:15 -0500
> "Matt P."  wrote:
> 
>> Hi Stuart!
>> 
>> Your advice lead me to discover, the issue happens only with the
>> "PersistantKeepalive = 25" option I had enabled on each wg-quick
>> peer. Looks like you could recreate it by making a few no-address
>> peers with this option enabled.
> 
> Hi Matt,
> 
> This insight was very helpful. It looks like mbufs are not freed if
> we're sending to a peer with no endpoint. Specifically, "wg_send" is
> expected to free the mbuf if there is an error sending. This (untested)
> patch should fix it.
> 
> Cheers,
> Matt
> 
> diff --git if_wg.c if_wg.c
> index 18333eda4cb..5f4319558ab 100644
> --- if_wg.c
> +++ if_wg.c
> @@ -810,6 +810,7 @@ wg_send(struct wg_softc *sc, struct wg_endpoint *e, 
> struct mbuf *m)
>IPPROTO_IPV6);
> #endif
>} else {
> +m_freem(m);
>return EAFNOSUPPORT;
>}
> 

Re: WireGuard host crashes roughly every week

[Matt Dunwoodie]

On Tue, 3 Aug 2021 13:02:15 -0500
"Matt P."  wrote:

> Hi Stuart!
> 
> Your advice lead me to discover, the issue happens only with the
> "PersistantKeepalive = 25" option I had enabled on each wg-quick
> peer. Looks like you could recreate it by making a few no-address
> peers with this option enabled.

Hi Matt,

This insight was very helpful. It looks like mbufs are not freed if
we're sending to a peer with no endpoint. Specifically, "wg_send" is
expected to free the mbuf if there is an error sending. This (untested)
patch should fix it.

Cheers,
Matt

diff --git if_wg.c if_wg.c
index 18333eda4cb..5f4319558ab 100644
--- if_wg.c
+++ if_wg.c
@@ -810,6 +810,7 @@ wg_send(struct wg_softc *sc, struct wg_endpoint *e, struct 
mbuf *m)
IPPROTO_IPV6);
 #endif
} else {
+   m_freem(m);
return EAFNOSUPPORT;
}
 

Re: WireGuard host crashes roughly every week

[Matt P.]

complete after 5 seconds, retrying (try 3)
> wg0: Sending handshake initiation to peer 0
> wg0: Handshake for peer 0 did not complete after 5 seconds, retrying (try 4)
> wg0: Sending handshake initiation to peer 0
> wg0: Handshake for peer 0 did not complete after 5 seconds, retrying (try 5)
> wg0: Sending handshake initiation to peer 0
> wg0: Retrying handshake with peer 0 because we stopped hearing back after 15 
> seconds
> wg0: Handshake for peer 0 did not complete after 5 seconds, retrying (try 2)
> wg0: Sending handshake initiation to peer 0
> wg0: Handshake for peer 0 did not complete after 5 seconds, retrying (try 3)
> wg0: Sending handshake initiation to peer 0

Again, no wasted mbufs happening with the above handshakes. Only the ones 
happening with PersistantKeepalive enabled.

I think that's the problem found, but here's the other info requested.

The summary of my setup is like this. The Wireguard server is configured to let 
my devices VPN to my home network, both for accessing local network devices, 
and for connecting to the internet through the tunnel. My ISP-provided router 
forwards a public port to the Wireguard server so they can connect.

As you saw in the config file, Peers can come from any IP address and are 
usually not connected.

I have pf configured to forward the traffic:

> # wireguard
> # open wireguard port
> pass in on $ext_if proto udp from any to any port $wg_port
> # allow communication between wireguard peers
> pass on $wg_if
> # allow clients connected to wg0 to tunnel their outside world traffic
> pass out on $ext_if inet from ($wg_if:network) nat-to ($ext_if:0)

And below is the rest of my dmesg.

Thanks,
--Matt

> OpenBSD 6.9 (GENERIC.MP) #3: Mon Jun  7 08:21:26 MDT 2021
>   
> r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1996484608 (1903MB)
> avail mem = 1920663552 (1831MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7ee89040 (13 entries)
> bios0: vendor coreboot version "v4.13.0.2" date 12/23/2020
> bios0: PC Engines apu4
> acpi0 at bios0: ACPI 6.0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET
> acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) 
> UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD GX-412TC SOC, 998.27 MHz, 16-30-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-01
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD GX-412TC SOC, 998.17 MHz, 16-30-01
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu2: DTLB 40 4KB

Re: WireGuard host crashes roughly every week

[Matt P.]

Hi Todd!

You're right, the number of mbufs on the machine in question is steadily 
climbing.

This is a few minutes after a reboot, with an RC script starting wireguard 
automatically:

> 27836 mbufs in use:
> 27827 mbufs allocated to data
> 3 mbufs allocated to packet headers
> 6 mbufs allocated to socket names and addresses
> 0/16 mbuf 2048 byte clusters in use (current/peak)
> 20/75 mbuf 2112 byte clusters in use (current/peak)
> 0/8 mbuf 4096 byte clusters in use (current/peak)
> 0/0 mbuf 8192 byte clusters in use (current/peak)
> 0/0 mbuf 9216 byte clusters in use (current/peak)
> 0/0 mbuf 12288 byte clusters in use (current/peak)
> 0/0 mbuf 16384 byte clusters in use (current/peak)
> 0/0 mbuf 65536 byte clusters in use (current/peak)
> 7192/7192/524288 Kbytes allocated to network (current/peak/max)
> 0 requests for memory denied
> 0 requests for memory delayed
> 0 calls to protocol drain routines

And then, just a second or two later:

> 27874 mbufs in use:
> 27863 mbufs allocated to data
> 5 mbufs allocated to packet headers
> 6 mbufs allocated to socket names and addresses
> 0/16 mbuf 2048 byte clusters in use (current/peak)
> 20/75 mbuf 2112 byte clusters in use (current/peak)
> 0/8 mbuf 4096 byte clusters in use (current/peak)
> 0/0 mbuf 8192 byte clusters in use (current/peak)
> 0/0 mbuf 9216 byte clusters in use (current/peak)
> 0/0 mbuf 12288 byte clusters in use (current/peak)
> 0/0 mbuf 16384 byte clusters in use (current/peak)
> 0/0 mbuf 65536 byte clusters in use (current/peak)
> 7204/7204/524288 Kbytes allocated to network (current/peak/max)
> 0 requests for memory denied
> 0 requests for memory delayed
> 0 calls to protocol drain routines

>From the nearly identical Pi (sans wireguard):

> 72 mbufs in use:
> 42 mbufs allocated to data
> 1 mbuf allocated to packet headers
> 29 mbufs allocated to socket names and addresses
> 12/64 mbuf 2048 byte clusters in use (current/peak)
> 0/0 mbuf 2112 byte clusters in use (current/peak)
> 0/8 mbuf 4096 byte clusters in use (current/peak)
> 0/0 mbuf 8192 byte clusters in use (current/peak)
> 0/0 mbuf 9216 byte clusters in use (current/peak)
> 0/0 mbuf 12288 byte clusters in use (current/peak)
> 0/0 mbuf 16384 byte clusters in use (current/peak)
> 0/0 mbuf 65536 byte clusters in use (current/peak)
> 216/216/131072 Kbytes allocated to network (current/peak/max)
> 0 requests for memory denied
> 0 requests for memory delayed
> 0 calls to protocol drain routines


I tried disabling the wg startup. When I start the box I have very few mbufs 
(around 50) like on the other machine. Once I start wireguard manually it 
begins climbing again, though the number is nowhere near the "27836 mbufs in 
use" like when it loads at boot.

When I stop wireguard (with wg-quick, destroying the interface), the number of 
mbufs stays where it is but stops climbing.

What should I do next?

--Matt

> On Jul 30, 2021, at 9:31 AM, Todd C. Miller  wrote:
> On Thu, 29 Jul 2021 20:09:12 -0500, "Matt P." wrote:
> 
>> I have an OpenBSD box that breaks after a week or so of running. All network 
>> traffic stops reaching the box. If I look at the screen or serial output, I c
>> an get the "login:" prompt, and when I enter my name I get prompted for a pas
>> sword, but once I enter a password it hangs. Key presses and control codes st
>> ill show on the screen, but the login never succeeds or fails. I thought cont
>> rol-C might cause it to go back to the login prompt, but it doesn't. I have t
>> o hard reboot the box to get it back.
> 
> This may be due to a memory leak.  You could monitor the output of
> "netstat -m" and also "vmstat -m" and watch for memory use increasing
> over time.  The number of mbufs in use reported by "netstat -m"
> should be relatively stable.
> 
> - todd

WireGuard host crashes roughly every week

[Matt P.]

Hi all.

I have an OpenBSD box that breaks after a week or so of running. All network 
traffic stops reaching the box. If I look at the screen or serial output, I can 
get the "login:" prompt, and when I enter my name I get prompted for a 
password, but once I enter a password it hangs. Key presses and control codes 
still show on the screen, but the login never succeeds or fails. I thought 
control-C might cause it to go back to the login prompt, but it doesn't. I have 
to hard reboot the box to get it back.

This box runs a Wireguard server accessible from the internet, and I think it's 
related to the crashing. I used to run the same WireGuard configuration on a 
different OpenBSD machine (a Raspberry Pi instead of x64), and the same 
crashing would happen. I blamed the crashing on the Pi port of OpenBSD, which 
is why I switched machines, but it stopped happening on the Pi and started on 
the x64 box.

I'm a newbie at systems administration, and don't know where to go from here. 
There's no kernel panics to send, and I didn't see anything in the log files 
about the crash. What should I do?

--Matt

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Matt Dowle]

On Thu, Jun 24, 2021 at 10:41 PM Sebastien Marie  wrote:

> On Thu, Jun 24, 2021 at 08:04:37PM -0600, Matt Dowle wrote:
> >
> > > It is NOT 16 years old.  You keep saying that.  There is a different
> > development
> > process involved here which has upsides and downsides and which I don't
> > expect
> > you will understand.
> >
> > That's right. I don't understand.
> > Could you explain it then, or point me to a document that explains what
> > your development process is?
> > Putting two and two together, it seems that it is 16 years plus a bunch
> of
> > cherry picked bug fixes backported over a very many years. If that's what
> > you do, whilst I understand that can make some sense to keep patching
> say 5
> > year old libraries, at some point it becomes too old and too risky.
> >
>
> I am not sure to understand why our zlib version (which might be
> called a maintained fork from 16 years old version) would be more
> risky than pushing a newer version just because 'it is newer'.
>

There are limits here: 'new' and 'old' need to be defined. I agree with you
that upgrading to bleeding edge (releases under say 1 year old) regularly
may not be a good idea. I think that may be what you have in mind by 'new'.
But, in this particular case, the 'newest' version of zlib is 4 years old.
And, there have been no bug fixes since that release, too. That's quite
different to 'just because it is newer'. A lot of eyes and usage has been
on that zlib version 1.2.11 in the last 4 years.

The longer you continue a maintained fork, the bigger the time lag between
the patches you are taking from later versions and backporting them to 16
years ago. The bigger the time lag the risker it is. Because the bug fixes
in later versions of zlib were made and tested (by zlib devs, and people
using those later versions) with those fixes in those later versions of
zlib, not 1.2.3 from 16 years ago. The act of backporting bug fixes to
earlier versions is not risk free. There are a lot of eyes and dependencies
using the zlib versions in the form that they have been released. I guess
there are not so many eyes and usage of your maintained fork. These reasons
are why I said your maintained fork, in this particular case of the
baseline being 16 years ago, is riskier. Not because I was naive to assume
the latest one is always better. I did not say that all your maintained
forks are risker. I'm just saying there's a limit and having a 16-year old
baseline for a maintained fork is beyond that limit, and therefore riskier.

We are not hostile to make changes, but at least please told us what
> should be changed/adjusted and why it is important for your
> use-case. And if it doesn't hurt us too, changes will be done: patches
> are accepted.
>

I already replied on that point in this thread to Theo.

Best, Matt


> Thanks.
> --
> Sebastien Marie
>

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Matt Dowle]

> So feisty.

Seriously?

On Thu, Jun 24, 2021 at 8:33 PM Theo de Raadt  wrote:

> Matt Dowle  wrote:
>
> > That's right. I don't understand.
> > Could you explain it then, or point me to a document that explains what
> > your development process is?
> > Putting two and two together, it seems that it is 16 years plus a bunch
> of
> > cherry picked bug fixes backported over a very many years. If that's what
> > you do, whilst I understand that can make some sense to keep patching
> say 5
> > year old libraries, at some point it becomes too old and too risky.
>
> So feisty.
>

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Matt Dowle]

> I don't know either.
> That is what I am asking.

I'm not going to spend more time investigating a bug fix in zlib made 15
years ago. If that's what your policy is, then we have provided plentiful
pointers for you to do so.

> Yes, you keep saying we should just throw the new code in, and you keep
not explaining what the actual problem is.

You keep paraphrasing me: I didn't say "throw the new code in".

You complained it was "pages and pages", but I have linked to what the
problem is and what the fix was. That is not the same as me "not explaining
what the problem is".

You keep asking me to spend even more time on this, and not recognizing
that we have already sunk time into this.

> It is NOT 16 years old.  You keep saying that.  There is a different
development
process involved here which has upsides and downsides and which I don't
expect
you will understand.

That's right. I don't understand.
Could you explain it then, or point me to a document that explains what
your development process is?
Putting two and two together, it seems that it is 16 years plus a bunch of
cherry picked bug fixes backported over a very many years. If that's what
you do, whilst I understand that can make some sense to keep patching say 5
year old libraries, at some point it becomes too old and too risky.

Matt

On Thu, Jun 24, 2021 at 7:27 PM Theo de Raadt  wrote:

> Matt Dowle  wrote:
>
> > Theo,
> >
> > > Instead, we got pages and pages that summarize to "must
> > update", and doesn't explain what the bug is or what the fix is.
> >
> > > If only we had an explanation of what is actually wrong and needs
> fixing
> >
> > We know it was this news item from 1.2.3.1 (released 16 August 2006)
> > https://zlib.net/ChangeLog.txt :
> > - Take into account wrapper variations in deflateBound()
> > but I don't know which commit that was.
>
> I don't know either.
>
> That is what I am asking.
>
> But you don't know and keep repeating:
>
> > Yes it would be appreciated if OpenBSD upgraded to zlib 1.2.11 which at
> 4 years old
> > seems reasonably old. Using a 16-year old version of a library such as
> zlib, however,
> > seems too old to me: at that age it's starting to become unreasonable to
> expect other
> > open-source maintainers such as myself to support.
>
> Yes, you keep saying we should just throw the new code in, and you keep
> not explaining what the actual problem is.
>
> It is NOT 16 years old.  You keep saying that.  There is a different
> development
> process involved here which has upsides and downsides and which I don't
> expect
> you will understand.
>

Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Matt Dowle]

Theo,

> Instead, we got pages and pages that summarize to "must
update", and doesn't explain what the bug is or what the fix is.

> If only we had an explanation of what is actually wrong and needs fixing

We know it was this news item from 1.2.3.1 (released 16 August 2006)
https://zlib.net/ChangeLog.txt :
- Take into account wrapper variations in deflateBound()
but I don't know which commit that was.

We have already worked around it on our side.

Yes it would be appreciated if OpenBSD upgraded to zlib 1.2.11 which at 4
years old seems reasonably old. Using a 16-year old version of a library
such as zlib, however, seems too old to me: at that age it's starting to
become unreasonable to expect other open-source maintainers such as myself
to support.

Best, Matt

On Thu, Jun 24, 2021 at 3:46 PM Theo de Raadt  wrote:

> Dave Voutila  wrote:
>
> > Theo de Raadt writes:
> >
> > > Dave Voutila  wrote:
> > >
> > >> Theo de Raadt writes:
> > >>
> > >> >> I think the easiest path here is to incorporate the new upstream
> into a
> > >> >> port, unless someone is familiar with zlib and can cherrypick out
> the
> > >> >> commit(s) that resolve the issue. (I didn't find zlib in ports
> already.)
> > >> >
> > >> > That is completely impossible.  It must be in base.  There are 3
> copies
> > >> > in base -- userland, kernel, and bootblocks.  They must be kept in
> sync.
> > >>
> > >> Not saying to replace what's in base, but have a different version in
> > >> ports available for ports. I was thinking along the lines of egcc or
> > >> eopenssl in that the port co-exists with base and ports that need them
> > >> need tweaking to use them.
> > >
> > > You've got to be kidding.  In what world does it help to require -I and
> > > -l lines all over the place, or else everything breaks.
> >
> > I'm in 100% agreement it sucks and it's something I believe is already
> > done for ports that require OpenSSL. /shrug. My thinking was instead of
> > having to test all of base across all archs with any potential fix, we
> > could isolate the change to maybe the R port if other R packages or
> > whatever have run into this.
> >
> > But I'm not volunteering to do either so I'll stop beating this horse
> > now before it never walks again.
>
> This is crazy.  It is probably a 2-3 line fix.  If only we had an
> explanation of what is actually wrong and needs fixing...
>

Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?

[Matt Dowle]

Hi,

Is it intentional or is there any good reason that OpenBSD 6.9 released May
2021 uses a 16 year old version of zlib (v1.2.3; July 2005)?  The latest
version v1.2.11 (Jan 2017) is 4 years old.

Background here: https://github.com/Rdatatable/data.table/pull/5049

Best,
Matt
Maintainer of data.table in R

Re: 4G mini PCI-e modem support?

[Matt Dainty]

* Patrick Wildt  [2021-01-08 11:17:18]:
> Am Fri, Jan 08, 2021 at 02:29:02PM + schrieb Peter Kay:
> > There appear to be no 4G modem support at the moment, specifically a
> > mini PCI-e one so I can stick it in a PC engines apu4d4 and have a
> > backup connection.
> > 
> > Presuming a driver would need to be written, but just checking if I've
> > missed anything?
> 
> There's umb(4).  It supports USB's MBIM standard.  There are some MBIM
> compatible chips around, one for instance is this one:
> 
> https://www.varia-store.com/de/produkt/87272-simcom-sim7600e-h-mpcie-eu-lte-cat-4-modul.html
> 
> You'll probably need to switch it into MBIM mode once via a specific
> AT-command over the serial, but otherwise it should do.
> 
> I'm sure there are plenty of other MBIM-compatible devices, this is just
> the one from the top of my head.

Does this SIMCom card work under OpenBSD with umb(4)? I can see its device
IDs were added to umsm(4) in 2018.

I'm also looking for a mini PCIe 4G/LTE card to put in an APU4. I'm not
sure an M.2 card will fit into the standard case with the added height of
the M.2 <-> mini PCIe adapter so I'd prefer to just get a mini PCIe device
and avoid the extra adapter. Are there any other umb(4)-compatible devices
in a mini PCIe form factor I can look for that will work in Europe?

Matt

Re: 6.8 - Difficulties getting Wireguard ipv6 working

[Matt Dunwoodie]

On Sat, 31 Oct 2020 21:31:50 +
Laura Smith  wrote:

> Hi,
> 
> I currently have a fully functional dual-stack Wireguard instance
> running on Debian. However given the recent release of OpenBSD 6.8
> with Wireguard in base, I thought it would be a good opportunity to
> switch over from the dark side. ;-)
> 
> Anyway, so on Debian I have a no-NAT setup, with the host announcing
> the VPN subnets to upstream router. All works great.
> 
> I'm no stranger to OpenBSD and OpenBGPD, but I've only managed to get
> 2/3 of the way :
> - The OpenBSD host is config fully functional dual-stack,  IPv4 and
> IPv6 work perfectly
> - wg(4) IPv4 config works perfectly, clients can connect and browse
> the internet
> - wg(4) IPv6 config does not work, clients can connect but no
> routing, not even able to ping loopback IPs or the wg interface IP.
> - I have verified upstream routers can ping test loopback IPv6 IPs,
> so dual-stack BGP is functional
> - I have tried a IPv6 only wireguard client config (as shown below)
> and that has no effect ( i thought maybe a dual-stack client config
> was the problem with OpenBSD)

Firstly, there should be no issues with any combination of v4+v6
with wg(4), so I presume it is a misconfiguration somewhere.

Having a quick look at the config, the endpoint should not be the same
as the inet6 addr on the server wg1. But I might guess that was a
mistake when sanitising your configs?

Unfortunately, without more information it would be difficult to
diagnose. Route tables from both ends would be a start. I would also
suggest doing a tcpdump on wg interfaces on both ends to see where
traffic is leaving/arriving.

Cheers,
Matt

Re: wg(4) listen on a specific interface / address

[Matt Dunwoodie]

On Tue, 27 Oct 2020 22:36:38 +0100
Pierre Emeriaud  wrote:

> Howdy misc@,
> 
> I have a fairly complicated setup with lots of interfaces, a couple of
> rdomains etc.
> 
> I'd like wireguard to listen only on an IP address, not all. But if my
> understanding of ifconfig(8) is correct, this doesn't seem possible
> currently:
> 
> wgport port
>  Set the UDP port that the tunnel operates on.  _The
> interface will bind to INADDR_ANY and IN6ADDR_ANY_INIT._
> 
> I guess this the reason for the following behaviour?
> 
> $ doas ifconfig wg0 wgport 53
> ifconfig: SIOCSWG: Address already in use
> (the error message is generic I guess - but confusing imho)
> 
> $ netstat -natfinet | grep 53
> tcp  0  0  127.0.0.1.53   *.*
> LISTEN udp  0  0  127.0.0.1.53   *.*
> 
> $  netstat -T1 -natfinet | grep 53
> udp  0  0  127.0.0.1.53   *.*
> 
> Is there a way to circumvent this restriction? (is there a reason
> behind it maybe?)

A lot has been said already, however I should clarify things.

wg(4)'s primary goal is to provide a secure network tunnel. We have no
desire to obfuscating or manipulating traffic to bypass restrictive
firewalls, which appears to be what you want to use port 53 for.

Why INADDR_ANY (and IN6ADDR_ANY_INIT)? We listen on all interfaces to
discard any notion of trusting IP addresses and rely entirely on the
crypto to authenticate packets. This ties directly the "roaming" feature
of WireGuard [1]. As Theo mentioned we don't want to monitor for
addressing changes, so INADDR_ANY is correct.

Why no configuration knob for bind address? Well, this is a "simple"
VPN and prides itself on minimising unnecessary configuration while
still achieving it's primary goals. Allowing configuration of the bind
address opens a whole can of complexity worms, including configuration
failure modes and security issues that we don't have consensus on. The
behaviour exhibited on wg(4) is also consistent with implementations of
WireGuard on other platforms. This has been discussed before: [2][3].

Finally, if you want to continue using port 53, bind wg first, then
unwind. Alternatively rdr-to rules will work and I'm guessing your
didn't do any debugging to figure out why your rules weren't working as
expected. If your goal is to bypass restrictive firewalls, you may also
want to add ports 123, 4500, 5060 to your redirect rules, but keep in
mind you're abusing software in ways it wasn't designed for so support
is minimal. I imagine it would look something like the following (with
wg(4) listening on port 53535 on the same rdomain):

pass in on $wan proto udp to (self) \
  port { 53, 123, 4500, 5060 } rdr-to 127.0.0.1 port 53535

Cheers,
Matt

[1] https://www.wireguard.com/#built-in-roaming
[2] https://lists.zx2c4.com/pipermail/wireguard/2017-May/001280.html
[3] https://lists.zx2c4.com/pipermail/wireguard/2018-June/003013.html

Re: wireguard listen in other rdomain?

[Matt Dunwoodie]

On Tue, 11 Aug 2020 17:46:05 -0500
Abel Abraham Camarillo Ojeda  wrote:

> Hi to all,
> 
> (unsure if this if for tech@ or misc@)

Probably better suited for misc, moved there.

> I'm using wireguard interfaces but I see that no matter what
> domain I put the interface:
> 
> # ifconfig wg0 rdomain X
> 
> It always listens in rdomain 0 (default),
> is this expected?, is there any way to listen in another rdomain?
> I want to expose several wg interfaces all listening in same port but
> there's not option to listen in another ip address:
> 
>  wgport port
>  Set the UDP port that the tunnel operates on.  The
>  interface will
>  bind to INADDR_ANY and IN6ADDR_ANY_INIT.  If no port is
>  configured, one will be chosen automatically.
> 
> I tried creating several wg interfaces with different wgport and using
> pf udp redirections but source address selection gets very messy...
> 
> Ideas?

Have a look at "wgrtable" in ifconfig(8) to listen in another rdomain.

However, I'd like to know the reason for wanting multiple interfaces
and why they should be listening on the same port. Perhaps there is
a better solution than rdomains and pf redirections.

Cheers,
Matt

Re: Lenovo V130, boot failed with error "entry point at 0x1001000"

[Matt Kunkel]

Here is the offending patch.  -current boots fine with it removed:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/stand/efiboot/exec_i386.c.diff?r1=1.2&r2=1.3&f=h

Appears bootx64.efi is carrying some board specific workaround for
HP / Computrace that breaks many others, including tianocore. Guess 
I'll submit a patch to reverse it since I don't have an Elitebook to
test with?

As a workaround, mount the efi partition and copy in boot64.efi from
6.6.

-Matt Kunkel

June 23, 2020 2:16 PM, "Sven Wolf"  wrote:

> Hi,
> 
> also after the new installation of the current snapshot the system stops with 
> "entry point at
> 0x1001000".
> It's interesting, that a installation via bsd.rd is possible. But after that 
> the system doesn't
> boot via bsd.mp/bsd.sp.
> 
> Best regards,
> Sven
> 
> On 6/21/20 8:55 PM, Sven Wolf wrote:
> 
>> Hi,
>> the update of the loader didn't help.
>> I've updated the bootx64.efi from 3.48 to 3.52. But the current kernel > 
>> doesn't load. I'll try a
>> re-installation.
>> Maybe @Otto can explain why the start of bsd.rd is possible and the > start 
>> of bsd.sp/bsd.mp is not
>> possible. Maybe I can build a custom kernel.
>> Best regards,
>> Sven
>>> On 6/21/20 8:33 PM, Sven Wolf wrote:
>>> Hi,
>>> 
>>> I found the same issue in a thread some weeks ago.
>>> https://marc.info/?l=openbsd-misc&m=159039904132502&w=2
>>> 
>>> I'll test an reinstall/older loader. Boot from mbr isn't an option :(
>>> 
>>> Best regards,
>>> Sven
>>> 
>>> On 6/21/20 8:20 PM, Sven Wolf wrote:
>> 
>> Hi,
>> 
>> I've upgraded my Lenovo V130 from snapshot 6.6 (April 2020) to the >>> 
>> snapshot from 2020-06-20.
>> The boot via boot.rd is always possible.
>> But when I load bsd.sp or bsd.rd the boot process stops with the >>> error 
>> "entry point 0x1001000".
>> Do you have an idea how I can fix this >>> error?
>> In the past I did't have any problem with openbsd on this machine.
>> 
>> I'll try tomorrow the next snapshot.
>> 
>> Thanks and best regards,
>> Sven
>> 
>>>

6.7 EFI boot failure on amd64 since 12/2019 commit (entry point at 0x1001000)

[Matt Kunkel]

Since the 6.7 release there have been a few mentions of EFI boot 
failure on amd64. The most common resolution has been to use legacy 
boot. My T440P is running coreboot/TianoCore. The only way to legacy 
boot requires re-flashing the chips via SOIC8 bus pirate. 

Bisecting bootloader commits since 6.6 exposes the breaking commit for 
my laptop on: /src/sys/arch/amd64/stand/efiboot/exec_i386.c

===
date: 2019/12/12 13:09:35; author: bluhm; state: Exp; lines: +33 -1; 
commitid: tGTjnCkwobU1X16m;

"On a HP EliteBook 830 G6 the Computrace executable is located in
the area where the boot loader copies the kernel. Its EfiLoaderCode
is write protected, so the boot loader hangs in memmove(). As we
may use this memory after calling EFI ExitBootServices(), change
the protection bit to writeable in the page table."
===

GitHub: 
https://github.com/openbsd/src/commit/53d61855c6bc9c8ed81d22219d891ee26d918d21#diff-a927f4d9c71ab27dd3e00a136f5679d6

If I roll back prior to that commit, BOOTX64.EFI is fine.
Past that commit, it hangs ` entry point at 0x1001000 `.

Admittedly I'm not familiar with the guts of EFI and am unlikely to
develop a fix. Are there any other ways I can help troubleshoot? 
(Is it possible to run bootx64.efi in lldb?)


For those of you that have experienced this problem, please try compiling
/src/sys/arch/amd64/stand/efiboot/ prior to 2019/12/12. I can provide a 
compiled binary if you reach out directly. 

If this msg belongs in bugs, I can send it there as well. There are other 
recent mentions of this problem on -misc.


Thank you,
Matt Kunkel

Re: Faking the same LAN over the Internet

[Matt Schwartz]

I think as long as one side of the tunnel is not doing NAT then you would
be okay. For a while I had an IPSEC VPN going between my cloud server and
my home desktop so that I could access my home desktop remotely and it
worked well. Although, I have never tried any layer two tunneling. Report
back and let us know how it goes. EtherIP might be simpler to set up.

On Fri, Apr 3, 2020 at 11:51 AM Chris Rawnsley  wrote:

> Many thanks for all the suggestions, folks.
>
> I think I will have a play around with egre(4) and etherip(4) paired
> with iked(8) first and then move on to OpenVPN if all else fails. I
> will try to simulate the network layout with vmm(4) and hopefully
> report back in a few days.
>
>
> On Wed, 1 Apr 2020, at 18:47, Tom Smyth wrote:
> > Gre is great and fast and a hell of a lot faster than OpenVPN...
> > However and it is a Big However...
> > Gre does not typically work Across NATs
>
> On my side of the link I have an APU2 with OpenBSD working as a
> gateway and, potentially, managing this tunnelling too. As I have
> not got into details yet, would the NAT issue be avoided if one side
> of the tunnel has a public IP?
>
> --
> Chris Rawnsley
>
>

Re: Faking the same LAN over the Internet

[Matt Schwartz]

You could also consider using etherip(4). I think the etherip(4) interface
might be more NAT tolerant but I am not really sure.

www.openbsd.org copyright notice

[Matt Schwartz]

Just saw today that the copyright notice on the website is from
1996-2017. You guys might want to update it to 2018. :-)
-Matt

Re: [patch] 6.3 relayd.conf(5) man page correction

[Matt Schwartz]

Hi Jason,

When I have a moment later today I will look into it. I wasn't using the 
exact example from the man page because I was only proxying for one 
host. Since I did not have check hosts setup, that might have been the 
cause.


Thanks


On 4/8/2018 10:19 AM, Jason McIntyre wrote:

On Sat, Mar 24, 2018 at 09:51:59AM -0400, Matt Schwartz wrote:

Hi tech@,

One small correction to relayd.conf(5). In the examples section for
TLS acceleration, the configuration option match hash "sessid" results
in a syntax error. Diff below.

Thanks,
Matt


hi.

i'm having trouble getting anyone to look at this. i don;t use relayd
myself, so it's not obvious to me. can i just check - are you using that
*exact* example from the man page? if so, can you mail me the exact
errors you get.

if not, what are you using?

i tried running the example in the man page and got a different error.
so it's not clear to me if that section is meant to be stand-alone or
not.

jmc


Index: relayd.conf.5
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v
retrieving revision 1.182
diff -u -p -r1.182 relayd.conf.5
--- relayd.conf.5   29 Nov 2017 21:17:51 -  1.182
+++ relayd.conf.5   24 Mar 2018 13:47:17 -
@@ -1484,7 +1484,6 @@ http protocol "https" {
 match header set "Keep-Alive" value "$TIMEOUT"

 match query hash "sessid"
-   match hash "sessid"

 pass
 block path "/cgi-bin/index.cgi" value "*command=*"

Re: Issues with relayd

[Matt Schwartz]

Thanks for the reply, Claudio. Damnit Batman! I knew I forgot to give 
you some relevant data. Sorry 'bout that. Here is my relayd.conf file. 
It's nothing spectacular. Relayd is proxying my Ghost Blog.


http protocol https {
    match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
    match request header append "X-Forwarded-By" \
    value "$SERVER_ADDR:$SERVER_PORT"
    match request header append "X-Forwarded-Proto" value "https"
    match request header set "Keep-Alive" value "$TIMEOUT"

    tcp { nodelay, sack, socket buffer 65536, backlog 128 }

    tls { no tlsv1.0, ciphers HIGH }
    tls no session tickets
}

relay ghost {
    listen on vio0 port 443 tls
    protocol https
    forward to 127.0.0.1 port 2368
}

On 4/7/2018 3:32 AM, Claudio Jeker wrote:

On Fri, Apr 06, 2018 at 09:28:01AM -0400, Matt Schwartz wrote:

Hi misc@

I am running relayd as a reverse TLS proxy on OpenBSD 6.3 release with the
GENERIC kernel. I have noticed two issues that happen: (1) netstat reports
that the Recv-q for the ip protocol steadily climbs and never goes back to 0
unless I restart relayd and (2) I am getting a lot of spurious TLS handshake
errors that I can't pin down. I am running relayd with relayd -vv logging.
Below is output from my relayd.log and dmesg.


Not sure what the problem is with the IP Recv-q without looking at the
config. For the TLS errors, relayd in 6.3 logs a bit more that's all.

Issues with relayd

[Matt Schwartz]

Hi misc@

I am running relayd as a reverse TLS proxy on OpenBSD 6.3 release with 
the GENERIC kernel. I have noticed two issues that happen: (1) netstat 
reports that the Recv-q for the ip protocol steadily climbs and never 
goes back to 0 unless I restart relayd and (2) I am getting a lot of 
spurious TLS handshake errors that I can't pin down. I am running relayd 
with relayd -vv logging. Below is output from my relayd.log and dmesg.


Thanks,

Matt

/var/log/relayd:

Apr  5 23:45:43 panther relayd[94018]: startup
Apr  5 23:46:08 panther relayd[43579]: relay_tls_transaction: session 1: 
scheduling on EV_READ
Apr  5 23:46:08 panther relayd[43579]: relay ghost, tls session 1 
established (1 active)
Apr  5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 2: 
scheduling on EV_READ
Apr  5 23:46:15 panther relayd[43579]: relay ghost, tls session 2 
established (1 active)
Apr  5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 3: 
scheduling on EV_READ
Apr  5 23:46:15 panther relayd[43579]: relay ghost, tls session 3 
established (1 active)
Apr  5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 4: 
scheduling on EV_READ
Apr  5 23:46:15 panther relayd[11143]: relay_tls_transaction: session 1: 
scheduling on EV_READ
Apr  5 23:46:15 panther relayd[43579]: relay ghost, tls session 4 
established (2 active)
Apr  5 23:46:15 panther relayd[11143]: relay ghost, tls session 1 
established (1 active)
Apr  5 23:46:21 panther relayd[11143]: relay_tls_transaction: session 2: 
scheduling on EV_READ
Apr  5 23:46:22 panther relayd[11143]: relay ghost, tls session 2 
established (1 active)
Apr  5 23:47:04 panther relayd[11143]: relay_tls_transaction: session 3: 
scheduling on EV_READ
Apr  5 23:47:04 panther relayd[11143]: relay ghost, tls session 3 
established (1 active)
Apr  5 23:47:09 panther relayd[11143]: relay_tls_transaction: session 4: 
scheduling on EV_READ
Apr  5 23:47:09 panther relayd[11143]: relay ghost, tls session 4 
established (2 active)
Apr  5 23:47:09 panther relayd[73657]: relay_tls_transaction: session 1: 
scheduling on EV_READ
Apr  5 23:47:09 panther relayd[11143]: relay_tls_transaction: session 5: 
scheduling on EV_READ
Apr  5 23:47:09 panther relayd[73657]: relay ghost, tls session 1 
established (1 active)
Apr  5 23:47:09 panther relayd[11143]: relay ghost, tls session 5 
established (1 active)
Apr  5 23:48:23 panther relayd[73657]: relay_tls_transaction: session 2: 
scheduling on EV_READ
Apr  5 23:48:23 panther relayd[73657]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402610B:SSL 
routines:ACCEPT_SR_CLNT_HELLO:wrong version number
Apr  5 23:48:23 panther relayd[73657]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:23 panther relayd[73657]: relay_tls_transaction: session 3: 
scheduling on EV_READ
Apr  5 23:48:23 panther relayd[73657]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402710B:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number
Apr  5 23:48:23 panther relayd[73657]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:24 panther relayd[73657]: relay_tls_transaction: session 4: 
scheduling on EV_READ
Apr  5 23:48:24 panther relayd[73657]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402710B:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number
Apr  5 23:48:24 panther relayd[73657]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:24 panther relayd[43579]: relay_tls_transaction: session 5: 
scheduling on EV_READ
Apr  5 23:48:24 panther relayd[43579]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402710B:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number
Apr  5 23:48:24 panther relayd[43579]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:24 panther relayd[73657]: relay_tls_transaction: session 5: 
scheduling on EV_READ
Apr  5 23:48:24 panther relayd[73657]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402710B:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number
Apr  5 23:48:24 panther relayd[73657]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:24 panther relayd[43579]: relay_tls_transaction: session 6: 
scheduling on EV_READ
Apr  5 23:48:24 panther relayd[43579]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: unexpected EOF
Apr  5 23:48:24 panther relayd[43579]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:25 panther relayd[43579]: relay_tls_transaction: session 7: 
scheduling on EV_READ
Apr  5 23:48:25 panther relayd[43579]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:140270C1:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher
Apr  5 23:48:25 panther relayd[43579]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:25 panther relayd[11143]: relay_tls_transaction: session 6: 
scheduling on EV_READ
Apr  5 

Re: httpd howto redirect port 80 to 443 in vm

[Matt M]

Why not use a .htaccess redirect?

https://www.sslshopper.com/apache-redirect-http-to-https.html

On Thu, Mar 1, 2018 at 7:18 AM Bryan Harris  wrote:

> Alternate?: go back to original config and change
>
> server "default"
>
> to
>
> server "example.com"
>
> And maybe an alias for "www.example.com."
>
> Just a thought.
>
> V/r,
> Bryan
>
-- 
There's no place like 127.0.0.1

Re: fsck: CANNOT READ: BLK 4235468160

[Matt M]

I just saw you mentioned you are using the disk inside of virtualbox. Does
this same thing happen if you use the disk natively?


On Mon, Jan 8, 2018 at 8:52 AM Matt M  wrote:

> With disks, the blocks can change. There can be any number of reasons for
> this, from the actual physical platters going bad to the read heads not
> functioning properly, or the memory on the disk going bad. SSD is a
> different story, in my experience when it begins to go the behavior becomes
> really erratic and inconsistent. You could try replacing cables, but you
> are probably looking at replacing the disk.
>
>
> On Sat, Jan 6, 2018 at 9:12 PM STeve Andre'  wrote:
>
>> When you enter the realm of hardware errors, anything can happen.  If
>> you are lucky you will see the same hard and soft errors every time you
>> cross a bad sector, but I have seen many cases wildly varying block
>> numbers on really sick disks.  And yes, bad cables and USB interfaces
>> can be a problem too.  Try wiggling the cable disk the disk stable and
>> see if you can produce errors.
>>
>> Try doing a read with that USB hardware on another disk, too. That will
>> tell you something.  I'll bet that the disk is bad.  If it stops
>> producing errors, don't forgive it!  Get a new one.
>>
>> --STeve Andre'
>>
>> On 01/06/18 21:45, Maximilian Pichler wrote:
>> > Hi,
>> >
>> > I'm running fsck on an external USB hard drive, using OpenBSD 6.2
>> > inside VirtualBox on MacOS.
>> >
>> > On each run it gives a handful of "CANNOT READ: BLK ..." messages, but
>> > the block numbers reported are different (!) each time.
>> >
>> > If the disk is damaged, shouldn't the problematic blocks be
>> > consistent? Does this point to a communication problem with the disk
>> > (e.g. faulty USB cable)? Or is this a hopelessly unstable situation
>> > given the general screwiness of USB over VirtualBox/Mac OS...?
>> >
>> > Also, does answering "y" to "CANNOT READ" modify the disk contents?
>> >
>> > Thanks for any insights!
>> >
>> > Max
>> >
>> >
>> > xhci0 at pci0 dev 12 function 0 "Intel 7 Series xHCI" rev 0x00: apic 2
>> int 20
>> > usb0 at xhci0: USB revision 3.0
>> > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
>> > 3.00/1.00 addr 1
>> > umass0 at uhub0 port 9 configuration 1 interface 0 "Seagate Expansion"
>> > rev 3.00/0.00 addr 2
>> > umass0: using SCSI over Bulk-Only
>> > scsibus4 at umass0: 2 targets, initiator 0
>> > sd0 at scsibus4 targ 1 lun 0:  SCSI4 0/direct
>> fixed
>> > sd0: 3815447MB, 512 bytes/sector, 7814037167 <(781)%20403-7167> sectors
>> >
>> > $ doas fsck /dev/sd0a
>> > ** /dev/rsd0a
>> > ** Last Mounted on /home/max/mnt
>> > ** Phase 1 - Check Blocks and Sizes
>> >
>> > CANNOT READ: BLK 4235468160 <(423)%20546-8160>
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4128081280 <(412)%20808-1280>
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > CANNOT READ: BLK 4194986880 <(419)%20498-6880>
>> > CONTINUE? [Fyn?] y
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > ** Phase 2 - Check Pathnames
>> >
>> > CANNOT READ: BLK 4195146384 <(419)%20514-6384>
>> > CONTINUE? [Fyn?] y
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > ** Phase 3 - Check Connectivity
>> > ** Phase 4 - Check Reference Counts
>> > ** Phase 5 - Check Cyl groups
>> > 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
>> > blocks, 0.0% fragmentation)
>> >
>> > MARK FILE SYSTEM CLEAN? [Fyn?] y
>> >
>> >
>> > * FILE SYSTEM WAS MODIFIED *
>> >
>> >
>> > $ doas fsck -f /dev/sd0a
>> > ** /dev/rsd0a
>> > ** File system is already clean
>> > ** Last Mounted on /home/max/mnt
>> > ** Phase 1 - Check Blocks and Sizes
>> >
>> > CANNOT READ: BLK 4236615424 <(423)%20661-5424>
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > ** Phase 2 - Check Pathnames
>> >
>> > CANNOT READ: BLK 3732315520
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4161885792
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4201995728
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4202008160
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> >
>> > CANNOT READ: BLK 4202013680
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > ** Phase 3 - Check Connectivity
>> > ** Phase 4 - Check Reference Counts
>> > ** Phase 5 - Check Cyl groups
>> >
>> > CANNOT READ: BLK 5011229824
>> > CONTINUE? [Fyn?] y
>> >
>> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
>> > 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
>> > blocks, 0.0% fragmentation)
>> >
>> >
>>
>>
>
> --
> There's no place like 127.0.0.1
>


-- 
There's no place like 127.0.0.1

Re: fsck: CANNOT READ: BLK 4235468160

[Matt M]

With disks, the blocks can change. There can be any number of reasons for
this, from the actual physical platters going bad to the read heads not
functioning properly, or the memory on the disk going bad. SSD is a
different story, in my experience when it begins to go the behavior becomes
really erratic and inconsistent. You could try replacing cables, but you
are probably looking at replacing the disk.


On Sat, Jan 6, 2018 at 9:12 PM STeve Andre'  wrote:

> When you enter the realm of hardware errors, anything can happen.  If
> you are lucky you will see the same hard and soft errors every time you
> cross a bad sector, but I have seen many cases wildly varying block
> numbers on really sick disks.  And yes, bad cables and USB interfaces
> can be a problem too.  Try wiggling the cable disk the disk stable and
> see if you can produce errors.
>
> Try doing a read with that USB hardware on another disk, too. That will
> tell you something.  I'll bet that the disk is bad.  If it stops
> producing errors, don't forgive it!  Get a new one.
>
> --STeve Andre'
>
> On 01/06/18 21:45, Maximilian Pichler wrote:
> > Hi,
> >
> > I'm running fsck on an external USB hard drive, using OpenBSD 6.2
> > inside VirtualBox on MacOS.
> >
> > On each run it gives a handful of "CANNOT READ: BLK ..." messages, but
> > the block numbers reported are different (!) each time.
> >
> > If the disk is damaged, shouldn't the problematic blocks be
> > consistent? Does this point to a communication problem with the disk
> > (e.g. faulty USB cable)? Or is this a hopelessly unstable situation
> > given the general screwiness of USB over VirtualBox/Mac OS...?
> >
> > Also, does answering "y" to "CANNOT READ" modify the disk contents?
> >
> > Thanks for any insights!
> >
> > Max
> >
> >
> > xhci0 at pci0 dev 12 function 0 "Intel 7 Series xHCI" rev 0x00: apic 2
> int 20
> > usb0 at xhci0: USB revision 3.0
> > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
> > 3.00/1.00 addr 1
> > umass0 at uhub0 port 9 configuration 1 interface 0 "Seagate Expansion"
> > rev 3.00/0.00 addr 2
> > umass0: using SCSI over Bulk-Only
> > scsibus4 at umass0: 2 targets, initiator 0
> > sd0 at scsibus4 targ 1 lun 0:  SCSI4 0/direct
> fixed
> > sd0: 3815447MB, 512 bytes/sector, 7814037167 <(781)%20403-7167> sectors
> >
> > $ doas fsck /dev/sd0a
> > ** /dev/rsd0a
> > ** Last Mounted on /home/max/mnt
> > ** Phase 1 - Check Blocks and Sizes
> >
> > CANNOT READ: BLK 4235468160 <(423)%20546-8160>
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4128081280 <(412)%20808-1280>
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > CANNOT READ: BLK 4194986880 <(419)%20498-6880>
> > CONTINUE? [Fyn?] y
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > ** Phase 2 - Check Pathnames
> >
> > CANNOT READ: BLK 4195146384 <(419)%20514-6384>
> > CONTINUE? [Fyn?] y
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> > 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
> > blocks, 0.0% fragmentation)
> >
> > MARK FILE SYSTEM CLEAN? [Fyn?] y
> >
> >
> > * FILE SYSTEM WAS MODIFIED *
> >
> >
> > $ doas fsck -f /dev/sd0a
> > ** /dev/rsd0a
> > ** File system is already clean
> > ** Last Mounted on /home/max/mnt
> > ** Phase 1 - Check Blocks and Sizes
> >
> > CANNOT READ: BLK 4236615424 <(423)%20661-5424>
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > ** Phase 2 - Check Pathnames
> >
> > CANNOT READ: BLK 3732315520
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4161885792
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4201995728
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4202008160
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> >
> > CANNOT READ: BLK 4202013680
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> >
> > CANNOT READ: BLK 5011229824
> > CONTINUE? [Fyn?] y
> >
> > THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> > 614222 files, 408012667 used, 76524122 free (3658 frags, 9565058
> > blocks, 0.0% fragmentation)
> >
> >
>
>

-- 
There's no place like 127.0.0.1

Re: Problems import ctypes in Python on 6.1

[Matt Hamilton]

OK, I think I fixed this. Seems some un-marked dependancy needed updating. But 
forcing all packages to be updated with: 

pkg_add -D installed -u

has cause python to start working again.

-Matt

> On 7 Aug 2017, at 14:19, Matt Hamilton  wrote:
> 
> Hi All,
>  I upgraded a machine to 6.1 and now having trouble importing the ctypes 
> module in python2.7. I've tried reinstalling the python package, no luck. I'm 
> running this with /usr mounted wxallowed.
> 
> Any ideas?
> 
>>>> import ctypes
> # trying ctypes.so
> # trying ctypesmodule.so
> # trying ctypes.py
> # trying ctypes.pyc
> import ctypes # directory /usr/local/lib/python2.7/ctypes
> # trying /usr/local/lib/python2.7/ctypes/__init__.so
> # trying /usr/local/lib/python2.7/ctypes/__init__module.so
> # trying /usr/local/lib/python2.7/ctypes/__init__.py
> # /usr/local/lib/python2.7/ctypes/__init__.pyc matches 
> /usr/local/lib/python2.7/ctypes/__init__.py
> import ctypes # precompiled from /usr/local/lib/python2.7/ctypes/__init__.pyc
> # trying /usr/local/lib/python2.7/ctypes/os.so
> # trying /usr/local/lib/python2.7/ctypes/osmodule.so
> # trying /usr/local/lib/python2.7/ctypes/os.py
> # trying /usr/local/lib/python2.7/ctypes/os.pyc
> # trying /usr/local/lib/python2.7/ctypes/sys.so
> # trying /usr/local/lib/python2.7/ctypes/sysmodule.so
> # trying /usr/local/lib/python2.7/ctypes/sys.py
> # trying /usr/local/lib/python2.7/ctypes/sys.pyc
> # trying /usr/local/lib/python2.7/ctypes/_ctypes.so
> # trying /usr/local/lib/python2.7/ctypes/_ctypesmodule.so
> # trying /usr/local/lib/python2.7/ctypes/_ctypes.py
> # trying /usr/local/lib/python2.7/ctypes/_ctypes.pyc
> # trying _ctypes.so
> # trying _ctypesmodule.so
> # trying _ctypes.py
> # trying _ctypes.pyc
> # trying /usr/local/lib/python2.7/_ctypes.so
> # trying /usr/local/lib/python2.7/_ctypesmodule.so
> # trying /usr/local/lib/python2.7/_ctypes.py
> # trying /usr/local/lib/python2.7/_ctypes.pyc
> # trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.so
> # trying /usr/local/lib/python2.7/plat-openbsd6/_ctypesmodule.so
> # trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.py
> # trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.pyc
> # trying /usr/local/lib/python2.7/lib-dynload/_ctypes.so
> dlopen("/usr/local/lib/python2.7/lib-dynload/_ctypes.so", 2);
> #   clear[1] _os
> #   clear[1] _sys
> #   clear[2] __file__
> #   clear[2] __package__
> #   clear[2] __path__
> #   clear[2] __name__
> #   clear[2] __version__
> #   clear[2] __doc__
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "/usr/local/lib/python2.7/ctypes/__init__.py", line 7, in 
>from _ctypes import Union, Structure, Array
> ImportError: Cannot load specified object
>>>> 
> 
> # ls -l /usr/local/lib/python2.7/lib-dynload/_ctypes.so
> -rwxr-xr-x  1 root  bin  151375 Apr  1 21:51 
> /usr/local/lib/python2.7/lib-dynload/_ctypes.so
> # file /usr/local/lib/python2.7/lib-dynload/_ctypes.so
> /usr/local/lib/python2.7/lib-dynload/_ctypes.so: ELF 64-bit LSB shared 
> object, x86-64, version 1
> 
> # uname -a
> OpenBSD krang.quernus.co.uk 6.1 GENERIC#0 amd64
> 
> # mount
> /dev/sd0a on / type ffs (local)
> /dev/sd0g on /home type ffs (local, nodev, nosuid)
> mfs:71126 on /tmp type mfs (asynchronous, local, nodev, noexec, nosuid, 
> size=102400 512-blocks)
> /dev/sd0f on /usr type ffs (local, nodev, wxallowed)
> /dev/sd0e on /var type ffs (local, noatime, nodev, nosuid)
> 
> -Matt
> 
> — 
> Matt Hamilton
> Quernus
> m...@quernus.co.uk
> +44 117 325 3025
> 64 Easton Business Centre
> Felix Road, Easton
> Bristol, BS5 0HE
> 
> Quernus Ltd is a company registered in England and Wales. Registered number: 
> 09076246
> 


— 
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
64 Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number: 
09076246

Problems import ctypes in Python on 6.1

[Matt Hamilton]

Hi All,
  I upgraded a machine to 6.1 and now having trouble importing the ctypes 
module in python2.7. I've tried reinstalling the python package, no luck. I'm 
running this with /usr mounted wxallowed.

Any ideas?

>>> import ctypes
# trying ctypes.so
# trying ctypesmodule.so
# trying ctypes.py
# trying ctypes.pyc
import ctypes # directory /usr/local/lib/python2.7/ctypes
# trying /usr/local/lib/python2.7/ctypes/__init__.so
# trying /usr/local/lib/python2.7/ctypes/__init__module.so
# trying /usr/local/lib/python2.7/ctypes/__init__.py
# /usr/local/lib/python2.7/ctypes/__init__.pyc matches 
/usr/local/lib/python2.7/ctypes/__init__.py
import ctypes # precompiled from /usr/local/lib/python2.7/ctypes/__init__.pyc
# trying /usr/local/lib/python2.7/ctypes/os.so
# trying /usr/local/lib/python2.7/ctypes/osmodule.so
# trying /usr/local/lib/python2.7/ctypes/os.py
# trying /usr/local/lib/python2.7/ctypes/os.pyc
# trying /usr/local/lib/python2.7/ctypes/sys.so
# trying /usr/local/lib/python2.7/ctypes/sysmodule.so
# trying /usr/local/lib/python2.7/ctypes/sys.py
# trying /usr/local/lib/python2.7/ctypes/sys.pyc
# trying /usr/local/lib/python2.7/ctypes/_ctypes.so
# trying /usr/local/lib/python2.7/ctypes/_ctypesmodule.so
# trying /usr/local/lib/python2.7/ctypes/_ctypes.py
# trying /usr/local/lib/python2.7/ctypes/_ctypes.pyc
# trying _ctypes.so
# trying _ctypesmodule.so
# trying _ctypes.py
# trying _ctypes.pyc
# trying /usr/local/lib/python2.7/_ctypes.so
# trying /usr/local/lib/python2.7/_ctypesmodule.so
# trying /usr/local/lib/python2.7/_ctypes.py
# trying /usr/local/lib/python2.7/_ctypes.pyc
# trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.so
# trying /usr/local/lib/python2.7/plat-openbsd6/_ctypesmodule.so
# trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.py
# trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.pyc
# trying /usr/local/lib/python2.7/lib-dynload/_ctypes.so
dlopen("/usr/local/lib/python2.7/lib-dynload/_ctypes.so", 2);
#   clear[1] _os
#   clear[1] _sys
#   clear[2] __file__
#   clear[2] __package__
#   clear[2] __path__
#   clear[2] __name__
#   clear[2] __version__
#   clear[2] __doc__
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/ctypes/__init__.py", line 7, in 
from _ctypes import Union, Structure, Array
ImportError: Cannot load specified object
>>> 

# ls -l /usr/local/lib/python2.7/lib-dynload/_ctypes.so
-rwxr-xr-x  1 root  bin  151375 Apr  1 21:51 
/usr/local/lib/python2.7/lib-dynload/_ctypes.so
# file /usr/local/lib/python2.7/lib-dynload/_ctypes.so
/usr/local/lib/python2.7/lib-dynload/_ctypes.so: ELF 64-bit LSB shared object, 
x86-64, version 1

# uname -a
OpenBSD krang.quernus.co.uk 6.1 GENERIC#0 amd64

# mount
/dev/sd0a on / type ffs (local)
/dev/sd0g on /home type ffs (local, nodev, nosuid)
mfs:71126 on /tmp type mfs (asynchronous, local, nodev, noexec, nosuid, 
size=102400 512-blocks)
/dev/sd0f on /usr type ffs (local, nodev, wxallowed)
/dev/sd0e on /var type ffs (local, noatime, nodev, nosuid)

-Matt

— 
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
64 Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number: 
09076246

Re: ETE - ETA

[Matt M]

ETA is a sort of "universally" recognized and used form. To be technical,
ETA and ETE would be synonymous in this case anyway.

The time to wait till arrival (eta) would correspond exactly with the time
it takes to complete the process (enroute).

On Sun, Jan 22, 2017 at 8:30 AM jean-francois  wrote:

> Hi,
>
> I always wondered what was ETA for during the installation process.
>
> As of today, I noticed this should read ETE as for Estimated Time Enroute.
>
> ETA stands for Estimated Time of Arrival and is therefore more or less
> constant.
>
> Regards

OpenBGPD support for BGP-MPLS VPN with IPv6

[Matt Kassawara]

Hi,

Do any plans exist to implement the BGP-MPLS IP VPN extension for IPv6 VPN
(RFC 4659) in OpenBGPD?

Thanks,
Matt

Re: openiked + rc.conf.local

[Matt Behrens]

On Sep 26, 2016, at 2:26 PM, Infoomatic  wrote:

>> Do you get any more output if you do "rcctl -f -d start iked"?

> the output is:
> doing _rc_parse_conf
> doing _rc_quirks
> iked_flags empty, using default ><
> doing _rc_parse_conf /var/run/rc.d/iked
> doing _rc_quirks
> doing rc_check
> iked
> doing rc_pre
> configuration OK
>
> and then the terminal is blocked again

This looks similar to a problem I filed a bug on; see
https://marc.info/?l=openbsd-bugs&m=147463700507932&w=2


My workaround for now is to edit /etc/rc.d/iked and uncomment the `return 0`.
The line with `${daemon} -n ${daemon_flags}` has iked do a config test, which
appears to not exit cleanly.

iked config test hanging on 6.0

[Matt Behrens]

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

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

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

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

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

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

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

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

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

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

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

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

# ikectl ca CA create

ikectl.conf:

user username passive

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

Re: the balance between OpenBSD and life

[Matt M]

On Sat, May 28, 2016 at 7:31 AM Teng Zhang  wrote:

> I can't adjust  the time for OpenBSD and my life appropriately. Could you
> please share your experience with me about how you adjust your time between
> OpenBSD and your life.
> thanks for any reply.
>
>
If OpenBSD is consuming so much of your time that it is interfering with
life, then maybe leave OpenBSD alone for a while and come back when life in
general isn't needing your full attention, Maybe run OpenBSD for your
server or desktop, but don't consume yourself with it - if it works, it
works - and it should work without having to constantly babysit or tweak it.

I am a musician, and if I could I would easily spend 12+ hours per day
playing, composing, recording and mixing music. But I have a job and
family, so music takes a second seat to that. There are times where I can't
even pick up an instrument for days at a time. That's life. But I always
come back to it whenever I get the chance, and sometimes I have the time to
focus heavily on music. OpenBSD should be no different for you.

Re: bioctl disk encryption

[Matt Schwartz]

Okay, I wasn't screaming - cheering on a great operating system, most
definitely. I'll dig into the source code a bit to see what I can learn.

On Apr 9, 2016 9:12 PM, "Jiri B" wrote:
>
> On Sat, Apr 09, 2016 at 08:18:11PM -0400, Matt Schwartz wrote:
> > I really like the bioctl full disk encryption feature. I would love to
see
> > it extended to support multiple users/passkeys. I once worked with a
> > commercial full disk encryption product that allowed this and could
even be
> > managed over a network. Coming up with a solution to manage encryption
keys
> > over a network is trivial but I'd love to see the full disk encryption
> > extended to support multiple users with individual passkeys.
> >
> > Thanks for listening!
>
> This is not how things work in OpenBSD. So you are screaming 'do that work
> for me!!!'. Understand the reality, it's hobbist project mostly, there are
> not paid by you or any big corporation (yes, there's some funding).
>
> So send your own diffs or do not expect your wish to become reality. There
> are more important things to work on (if you at least follow recent
OpenBSD
> development - SMP, threads/performance,...).
>
> j.

bioctl disk encryption

[Matt Schwartz]

I really like the bioctl full disk encryption feature. I would love to see
it extended to support multiple users/passkeys. I once worked with a
commercial full disk encryption product that allowed this and could even be
managed over a network. Coming up with a solution to manage encryption keys
over a network is trivial but I'd love to see the full disk encryption
extended to support multiple users with individual passkeys.

Thanks for listening!

BGP MPLS VPN Question

[Matt Schwartz]

Is it possible to setup a multi-site BGP MPLS VPN? Currently, I have it
working great between two sites running OpenBSD 5.9-current. I tried adding
a third site to my simulation but it hasn't worked. The third site I have
sharing the same MPLS label and routing domain. Is this where I am going
wrong? Do I need to create a separate routing domain for the third site,
another mpe interface with different MPLS label, and create static routes
between the rdomains?

Thank you again,
Matt

Re: ipsec ipcomp howto - OpenBSD 5.7

[Matt Schwartz]

ipcomp has not been implemented in ipsec/isakmpd. I've gotten it to work
quite well with iked. iked is the key management daemon for IKEv2.

On Thu, Mar 17, 2016 at 6:00 PM, Motty Cruz wrote:

> configuring ipsec.conf with ipcomp seem to be difficult then I thought. I
> enable ipcomp
> # sysctl -a | grep ipcomp
> net.inet.ipcomp.enable=1
>
> ipcomp is enabled on both gateways. Here is ipsec.conf:
>
> flow ipcomp from 10.10.10.0/24 to 10.10.2.0/24 \
>peer 192.168.1.57
>
> ike esp from 10.10.10.0/24 to 10.10.2.0/24 \
> peer 192.168.1.57 \
> main auth hmac-sha2-256 enc 3des group modp1024 lifetime 86400 \
> quick auth hmac-sha2-256 enc 3des lifetime 86400 \
> psk f15490b4ebc2bfc41a9a009509c91ceb443547f6
>
> my local LAN 10.10.10.0/24
> remote LAN 10.10.2.0/24
>
> # ipsecctl -s all
> FLOWS:
> flow esp in from 10.10.2.0/24 to 10.10.10.0/24 peer 192.168.1.57 type
> require
> flow esp out from 10.10.10.0/24 to 10.10.2.0/24 peer 192.168.1.57 type
> require
>
> SAD:
> esp tunnel from 192.168.1.57 to 192.168.125.157 spi 0xc259f59d auth
> hmac-sha2-256 enc 3des-cbc
> esp tunnel from 192.168.125.157 to 192.168.1.57 spi 0xe9b1976d auth
> hmac-sha2-256 enc 3des-cbc
> #
>
>
> any ideas? documentation man ipsec.conf has poor information about ipcomp,
> in my point of view.

Re: openbsd.org, openssh.com server(s) down

[Matt Schwartz]

Seems like there might be an outage. I cannot reach either openbsd.org or
openssh.com.

On Mar 15, 2016 9:32 AM, "Rudolf Sykora" wrote:
>
> Hello,
>
> is it only I who cannot connect to either
> of openbsd.org and openssh.com, or
> is the server down?
>
> Thanks
> Ruda

bgpd not importing routes from rdomain 1

[Matt Schwartz]

I am running OpenBSD 5.8 Release and I have a very simple BGP MPLS VPN
setup. I'm close to getting it to work but for bgpd. I think I have my
bgpd.conf setup correctly but I'm still having difficulty. Below I gave as
much diagnostic info as I could think of. Kindly let me know if I am
missing anything.

Thanks again for your time and attention,
Matt

#bgpctl show fib table 1
flags: * = valid, B = BGP, C = Connected, S = Static, D = Dynamic
   N = BGP Nexthop reachable via this route
   r = reject route, b = blackhole route

flags prio destination  gateway

#bgpctl show interfaces
Interface  Nexthop state  Flags  Link state
mpe0   ok UP unknown
lo1ok UP unknown
lo0ok UP unknown
enc0   invalid   active
em2ok UP Ethernet, unknown, 1000 MBit/s
em1ok UP Ethernet, unknown, 1000 MBit/s
em0ok UP Ethernet, unknown, 1000 MBit/s

#bgpctl show nei
BGP neighbor is 10.254.254.3, remote AS 65001
 Description: PE2
  BGP version 4, remote router-id 10.254.254.3
  BGP state = Established, up for 00:01:52
  Last read 00:00:22, holdtime 90s, keepalive interval 30s
  Neighbor capabilities:
Multiprotocol extensions: IPv4 unicast, IPv4 vpn
Route Refresh
Graceful Restart: Timeout: 90, restarted, IPv4 unicast, IPv4 vpn
4-byte AS numbers

  Message statistics:
  Sent   Received
  Opens   1  1
  Notifications  0  0
  Updates1  1
  Keepalives4  4
  Route Refresh  0  0
  Total 6  6

  Update statistics:
  Sent   Received
  Updates  0  0
  Withdraws0  0
  End-of-Rib   1  1

  Local host:  10.254.254.2, Local port:  11361
  Remote host: 10.254.254.3, Remote port:   179

#cat /etc/bgpd.conf:
router-id 10.254.254.2
AS 65001

rdomain 1 {
descr CUSTOMER1
rd 65001:1
import-target rt 65001:1
export-target rt 65001:1
depend on mpe0
network 172.16.1.0/24
network 0.0.0.0/0
}
group ibgp {
announce IPv4 unicast
announce IPv4 vpn
local-address 10.254.254.2
remote-as 65001
neighbor 10.254.254.3 {
descr PE2
}
}

#bgpd -d -v
startup
rereading config
route decision engine ready
session engine ready
new ktable rdomain_0 for rtableid 0
listening on 0.0.0.0
listening on ::
SE reconfigured
neighbor 10.254.254.3 (PE2): state change None -> Idle, reason: None
neighbor 10.254.254.3 (PE2): state change Idle -> Connect, reason: Start
RDE reconfigured
neighbor 10.254.254.3 (PE2): state change Connect -> OpenSent, reason:
Connection opened
neighbor 10.254.254.3 (PE2): state change OpenSent -> OpenConfirm, reason:
OPEN message received
neighbor 10.254.254.3 (PE2): state change OpenConfirm -> Established,
reason: KEEPALIVE message received

Re: bgpd network connected

[Matt Schwartz]

It looks like I spoke too soon because routes are not being added at all
when using rdomains. It doesn't matter if I use network inet connected or
specify network x.x.x.x/x, the rib comes up empty for the rdomain. Bgpctl
won't let you inject routes into a different routing table other than the
default. Frustrating because I'm so close to getting BGP MPLS VPN to work.
Of course it still could be me but I've looked at this 6 ways to Saturday
and I'm at a loss.

> On Mar 9, 2016 6:00 AM, "Tony Sarendal" wrote:
>
> >
> >
> > 2016-03-08 15:38 GMT+01:00 Matt Schwartz:
> >>
> >> I did not even know it was broken?
> >>
> >> On Mar 8, 2016 1:26 AM, "Tony Sarendal" wrote:
> >> >
> >> > Is there any chance of getting "network inet connected" fixed to 5.9
?
> >> >
> >> > Regards Tony
> >>
> >
> >
> > Adding a new vlan interface:
> >
> > beer# cat /etc/bgpd.conf
> > AS 65001
> > network inet connected
> > beer# bgpctl show rib
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags destination  gateway  lpref   med aspath origin
> > AI*>  172.29.1.0/240.0.0.0100 0 i
> > beer# ifconfig vlan69 create
> > beer# ifconfig vlan69 1.1.1.1/30 vlandev em0 vlan 69 up
> > beer# bgpctl show rib
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags destination  gateway  lpref   med aspath origin
> > AI*>  172.29.1.0/240.0.0.0100 0 i
> > beer# /etc/rc.d/bgpd restart
> > beer# bgpctl show rib
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags destination  gateway  lpref   med aspath origin
> > AI*>  1.1.1.0/30   0.0.0.0100 0 i
> > AI*>  172.29.1.0/240.0.0.0100 0 i
> > beer#
> >
> >
> > Regards Tony

Re: BGPD not adding routes

[Matt Schwartz]

Yes, it does make some sense. I'm going to have to take a deeper dive into
understanding routing domains and virtual routing tables. I noticed a good
article on packetmischief.ca which seems to provide a good overview. Thanks
again for your help.

Matt

On Mar 8, 2016 2:17 AM, "Claudio Jeker" wrote:
>
> On Mon, Mar 07, 2016 at 11:29:48AM -0500, Matt Schwartz wrote:
> > Thank you much, Claudio! That was the ticket. I had put my depend on
mpe0
> > in the wrong place. I was mostly using your mpls example. Dumb
questions:
> > Why do you not create a default route in rdomain 1 on the 2nd PE in your
> > mpls example network? Why do you not have network 0.0.0.0/0 on the 2nd
PE?
> > Thanks for helping me with my understanding gaps.
> >
>
> From the top of my memory the idea is that the 2nd PE gets the default
> route from the 1st PE similar to a client connecting via MPLS VPN to a
> ISP. Does this make sense?
>
> --
> :wq Claudio

Re: bgpd network connected

[Matt Schwartz]

I did not even know it was broken?

On Mar 8, 2016 1:26 AM, "Tony Sarendal" wrote:
>
> Is there any chance of getting "network inet connected" fixed to 5.9 ?
>
> Regards Tony

Re: BGPD not adding routes

[Matt Schwartz]

Thank you much, Claudio! That was the ticket. I had put my depend on mpe0
in the wrong place. I was mostly using your mpls example. Dumb questions:
Why do you not create a default route in rdomain 1 on the 2nd PE in your
mpls example network? Why do you not have network 0.0.0.0/0 on the 2nd PE?
Thanks for helping me with my understanding gaps.

Matt

BGPD not adding routes

[Matt Schwartz]

Hello @misc,

I am running OpenBSD 5.8 release and I am finding that BGPD is not adding
routes. When I type bgpctl show rib, I don't see any routes added. Did I
goof up this configuration? Below are my bgpd.conf files. I do not even see
any routes added when I run route -T1 show. I have no problems with my OSPF
and LDPD setup.

/etc/bgpd.conf
router-id 10.254.254.1
AS 65001
rdomain 1 {
 descr CUSTOMER1
 rd 65001:1
 import-target rt 65001:1
 export-target rt 65001:1
 network inet connected
 network 0.0.0.0/0
}
group ibgp {
 announce IPv4 unicast
 announce IPv4 vpn
 remote-as 65001
 depend on mpe0
 local-address 10.254.254.1
 neighbor 10.254.254.2 {
  descr PE2
 }
}

/etc/bgpd.conf
router-id 10.254.254.2
AS 65001
rdomain 1 {
 descr CUSTOMER1
 rd 65001:1
 import-target rt 65001:1
 export-target rt 65001:1
 network inet connected
}
group ibgp {
 announce IPv4 unicast
 announce IPv4 vpn
 remote-as 65001
 depend on mpe0
 local-address 10.254.254.2
 neighbor 10.254.254.1 {
  descr PE1
 }
}

Thanks much,
Matt

Re: 5.8: uvideo has support for Logitech QuickCam Pro 5000 but ugen0 attaches instead

[Matt Adams]

On 15/01/16 05:44 AM, Martin Pieuchot wrote:

Could you test the diff? Does it work?

I haven't had a chance but I will as soon as I can. Thanks!

Matt

Re: 5.8: uvideo has support for Logitech QuickCam Pro 5000 but ugen0 attaches instead

[Matt Adams]

On 05/01/16 05:10 AM, Martin Pieuchot wrote:

On 03/01/16(Sun) 23:18, Matt Adams wrote:

Hi,

I noted that uvideo has support for the Logitech QuickCam Pro 5000 - a piece
of hardware that I have. However, ugen appears to attach to this device
instead of allowing the special firmware (installed via "# fw_install
uvideo") to configure /dev/video0 or /dev/video1, even though those two
device files are present in the system.

For example:

-bash-4.3$ luvcview
luvcview version 2.0
Video driver: x11
A window manager is available
video /dev/video0
ERROR opening V4L interface
: Device not configured

Is there something that I am missing here or is my webcam not actually
supported?

Could you paste the output of "lsusb -v" for your webcam?  lsusb(1) is
part of the usbutils package.


lsusb -v as follows (webcam portion only):

Bus 001 Device 002: ID 046d:08c5 Logitech, Inc. QuickCam Pro 5000
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 1
  bMaxPacketSize064
  idVendor   0x046d Logitech, Inc.
  idProduct  0x08c5 QuickCam Pro 5000
  bcdDevice0.05
  iManufacturer   0
  iProduct0
  iSerial 2 87C33093
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 1267
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 0
  bInterfaceCount 2
  bFunctionClass255 Vendor Specific Class
  bFunctionSubClass   3
  bFunctionProtocol   0
  iFunction   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  1
  bInterfaceProtocol  0
  iInterface  0
  ** UNRECOGNIZED:  0d 24 01 00 01 6a 00 00 6c dc 02 01 01
  ** UNRECOGNIZED:  12 24 02 01 01 02 00 00 00 00 00 00 00 00 03 0e 
00 00

  ** UNRECOGNIZED:  0b 24 05 02 01 00 40 02 7b 17 00
  ** UNRECOGNIZED:  1c 24 06 03 82 06 61 63 70 50 ab 49 b8 cc b3 85 
5e 8d 22 1d 00 01 02 03 ff ff 1f 00
  ** UNRECOGNIZED:  1b 24 06 04 82 06 61 63 70 50 ab 49 b8 cc b3 85 
5e 8d 22 1e 00 01 03 02 7f 01 00

  ** UNRECOGNIZED:  09 24 03 05 01 01 00 04 00
  ** UNRECOGNIZED:  20 41 01 08 82 06 61 63 70 50 ab 49 b8 cc b3 85 
5e 8d 22 51 03 01 04 03 19 00 00 00 00 00 00 00
  ** UNRECOGNIZED:  20 41 01 0a 82 06 61 63 70 50 ab 49 b8 cc b3 85 
5e 8d 22 52 01 01 04 03 00 40 00 00 00 00 00 00

  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87  EP 7 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0010  1x 16 bytes
bInterval   8
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  2
  bInterfaceProtocol  0
  iInterface  0
  ** UNRECOGNIZED:  10 24 01 03 a9 02 81 00 05 02 01 00 01 04 00 04
  ** UNRECOGNIZED:  0b 24 06 01 09 01 03 00 00 00 00
  ** UNRECOGNIZED:  32 24 07 01 00 a0 00 78 00 00 70 17 00 00 a0 8c 
00 00 96 00 00 15 16 05 00 06 15 16 05 00 80 1a 06 00 20 a1 07 00 2a 2c 
0a 00 40 42 0f 00 80 84 1e 00
  ** UNRECOGNIZED:  32 24 07 02 00 b0 00 90 00 00 f0 1e 00 00 a0 b9 
00 00 c6 00 00 15 16 05 00 06 15 16 05 00 80 1a 06 00 20 a1 07 00 2a 2c 
0a 00 40 42 0f 00 80 84 1e 00
  ** UNRECOGNIZED:  32 24 07 03 00 40 01 f0 00 00 c0 5d 00 00 80 32 
02 00 58 02 00 2a 2c 0a 00 06 15 16 05 00 80 1a 06 00 20 a1 07 00 2a 2c 
0a 00 40 42 0f 00 80 84 1e 00
  ** UNRECOGNIZED:  32 24 07 04 00 60 01 20 01 00 c0 7b 00 00 80 e6 
02 00 18 03 00 15 16 05 00 06 15 16 05 00 80 1a 06 00 20 a1 07 00 2a 2c 
0a 00 40 42 0f 00 80 84 1e 00
  ** UNRECOGNIZED:  32 24 07 05 00 b0 01 f0 00 00 90 7e 00 00 60 f7 
02 00 2a 03 00 15 16 05 00 06 15 16 05 00 80 1a 06 00 20 a1 07 00 2a 2c 
0a 00 40 42 0f 00 80 84 1e 00
  ** UNRECOGNIZED:  32 24 07 06 00 e0 01 68 01 00 f0 d2 00 00 a0 f1 
04 00 46 05 00 15 16 05 00 06 15 16 05 00 80 1a 06 00 20 a1 07 00 2a 2c 
0a 00 40 42 0f 00 80 84 1e 00
  ** UNRECOGNIZED:  32 24 07 07 00 00 02 20 01 00 00 b

5.8: uvideo has support for Logitech QuickCam Pro 5000 but ugen0 attaches instead

[Matt Adams]

Hi,

I noted that uvideo has support for the Logitech QuickCam Pro 5000 - a 
piece of hardware that I have. However, ugen appears to attach to this 
device instead of allowing the special firmware (installed via "# 
fw_install uvideo") to configure /dev/video0 or /dev/video1, even though 
those two device files are present in the system.


For example:

-bash-4.3$ luvcview
luvcview version 2.0
Video driver: x11
A window manager is available
video /dev/video0
ERROR opening V4L interface
: Device not configured

Is there something that I am missing here or is my webcam not actually 
supported?


-bash-4.3$ ls -l /dev/video*
lrwxr-xr-x  1 root  wheel 6 Dec 24 00:09 /dev/video -> video0
crw-rw-rw-  1 root  wheel   44,   0 Dec 24 00:09 /dev/video0
crw-rw-rw-  1 root  wheel   44,   1 Dec 24 00:09 /dev/video1

Thanks,

Matt

-- usbdevs -v below

Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), 
Intel(0x8086), rev 1.00

 port 1 powered
 port 2 powered
 port 3 addr 2: high speed, self powered, config 1, product 
0x2514(0x2514), Standard Microsystems(0x0424), rev 0.00

  port 1 powered
  port 2 powered
 port 4 powered
Controller /dev/usb1:
addr 1: high speed, self powered, config 1, EHCI root hub(0x), 
Intel(0x8086), rev 1.00

 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 addr 2: high speed, power 500 mA, config 1, QuickCam Pro 
5000(0x08c5), Logitech(0x046d), rev 0.05, iSerialNumber 87C33093

 port 6 powered
 port 7 powered
 port 8 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00

 port 1 powered
 port 2 addr 2: full speed, self powered, config 1, product 
0x7000(0x7000), ATEN International(0x0557), rev 1.00
  port 1 addr 3: low speed, power 100 mA, config 1, Type 6 
Keyboard(0x0005), Fujitsu Component(0x0430), rev 1.02

  port 2 powered
  port 3 powered
  port 4 powered
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00

 port 1 powered
 port 2 powered
Controller /dev/usb4:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00

 port 1 powered
 port 2 powered
Controller /dev/usb5:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00

 port 1 powered
 port 2 powered
Controller /dev/usb6:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00

 port 1 powered
 port 2 addr 2: low speed, self powered, config 1, Back-UPS RS 1300 LCD 
FW:838.H5 .D USB FW:H5(0x0002), American Power Conversion(0x051d), rev 
1.01, iSerialNumber JB0721002454

Controller /dev/usb7:
addr 1: full speed, self powered, config 1, UHCI root hub(0x), 
Intel(0x8086), rev 1.00

 port 1 powered
 port 2 powered


-- dmesg below

OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 25739890688 (24547MB)
avail mem = 24955904000 (23799MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xcf49c000 (85 entries)
bios0: vendor Dell Inc. version "6.4.0" date 07/23/2013
bios0: Dell Inc. PowerEdge T710
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST 
BERT EINJ SRAT TCPA SSDT

acpi0: wakeup devices PCI0(S5) PCI1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.46 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

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

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.00 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu2: 256KB 

Re: 5.8: Cannot communicate with iDrac6 once OpenBSD boots (Broadcom BCM5709 via bnx)

[Matt Adams]

Thank you for the explanation (Stuart) and helpful patch (Ted). I will 
try something like that until I have the opportunity to upgrade to 
iDrac6 Enterprise (dedicated NIC).


Cheers,

Matt

5.8: Cannot communicate with iDrac6 once OpenBSD boots (Broadcom BCM5709 via bnx)

[Matt Adams]

Hello,

I have a Dell T710 server with a 4-port Broadcom BCM5709 NIC that hosts 
iDrac6 via port 1. The iDrac configuration has this port set up with a 
unique MAC and static IP. This port is supposed to be shared with the 
operating system and under Linux I have no problems continuing to access 
iDrac once the OS has loaded.


I would like to continue to use iDrac however OpenBSD is doing something 
to prevent it from being accessed once it boots.


Is there something that I can to do tell OpenBSD to NOT configure bnx0? 
I am hoping this might avoid whatever is happening to the iDrac 
configuration once OpenBSD launches.


It would be great if I could keep bnx1, bnx2 and bnx3 accessible to OpenBSD.

Thanks,

Matt

-- dmesg below

OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 25739890688 (24547MB)
avail mem = 24955904000 (23799MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xcf49c000 (85 entries)
bios0: vendor Dell Inc. version "6.4.0" date 07/23/2013
bios0: Dell Inc. PowerEdge T710
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST 
BERT EINJ SRAT TCPA SSDT

acpi0: wakeup devices PCI0(S5) PCI1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.43 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

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

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.00 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 16 (application processor)
cpu3: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.00 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 8, package 0
cpu4 at mainbus0: apid 18 (application processor)
cpu4: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.00 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 9, package 0
cpu5 at mainbus0: apid 20 (application processor)
cpu5: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.00 MHz
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 0, core 10, package 0
cpu6 at mainbus0: apid 1 (application processor)
cpu6: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.00 MHz
cpu6: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu6: 256KB 64b/line 8-way L2 cache
cpu6: smt 1, core 0, package 0
cpu7 at mainbus0: apid 3 (application processor)
cpu7: Intel(R) Xeon(R) CPU X5680 @ 3.33GHz, 3458.00 MHz
cpu7: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3

Re: FreeBSD or OpenBSD for my (server/router) purposes? (Total n00b)

[Matt Hamilton]

> On 28 Sep 2015, at 04:23, Eric Furman  wrote:
>
> And then he states; "For me, this is a very nice blend
> of security, manageability and convenience for my use-case."
> This statement clearly demonstrates that he believes his
> setup is secure. When, in fact, it is not.
> That's why the security implications were brought up.
> Hope this helps.


Interesting interpretation of the word 'blend' there.

There is no such this as 'secure' in absolute terms. Attempting to believe
this is just delusional. As I stated, and as you clearly quoted be staying,
this a blend of security, manageability and convenience for *my use case*.

I can see plenty of potential use-cases for OpenBSD running in a VM on a
hypervisor for intra-vlan routing for VMs and general network utility. This
has nothing at all to do with hypervisor security or the X86 architecture.

> On 28 Sep 2015, at 01:34, Eric Furman  wrote:
>
> OK, I read your blog. I see you are running this on x86 hardware.
> X86 hardware provides NO real hardware virtualization.
> You are clueless. Your VM and OpenBSD in the configuration
> gives you NO added security. Just convenience. If that's all
> you care about, fine, but don't delude yourself into thinking
> that you are somehow adding security by running OpenBSD
> in this fashion.
> VM's give you no added security unless you are running them
> on hardware that has been designed for that purpose, such
> as IBM mainframes or the AS400. Probably some others
> I'm leaving out, but NOT x86 hardware.
> Just search for VM and security on the internets and see
> what comes up. Secure they are not.


You state you have read my blog, that I am running this setup on x86 hardware,
and that I am clueless. You then mention AS/400 and IBM Mainframes. Really?!
Am I also clueless in thinking my little HP Microserver can compete with hot
swap CPUs? Did you really actually read my blog post? In what completely
insane parallel universe does one compare a few hundred dollars worth of x86
kit occupying about 8 litres of space and quietly sipping a few tens of watts
of power to even the most entry level iSeries or zSeries? I think this shows
just how far off the mark this thread has come.

-Matt

—
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
64 Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number:
09076246

Re: FreeBSD or OpenBSD for my (server/router) purposes? (Total n00b)

[Matt Hamilton]

> On 27 Sep 2015, at 22:57, Theo de Raadt  wrote:
> 
>>> On 27 Sep 2015, at 22:38, Eric Furman  wrote:
>>> 
>>> You really don't get it. Running OpenBSD in a VM gives you no
>>> security benefits of OpenBSD. Your base security will be your
>>> host, in this case FreeBSD. And on top of that you are running
>>> a very complex piece of software, the VM. Who knows what
>>> security holes are in it.
>> 
>> 
>> I do get it. I guess you wrote this before reading my last reply. That
>> explains the situation.
>> 
>> Yes, the base security will be my host. Putting an OpenBSD VM on there
>> does not (IMHO) significantly decrease the security of that host. I
>> agree that it is adding complexities and there could be potentially
>> unforeseen security issues due to the combination. e.g. something like
>> OpenBSD's ability to generate random number could somehow be
>> affected by the underlying VM that would not be present on bare metal.
> 
> Any additional code you run, beyond the minimum, increases your exposure

Indeed. Which is why you are typing this on a typewriter, right? I mean, I 
don’t know what editor you use, emacs, vi, mg, whatever… but that is additional 
code right? That has increased your attack surface. But you deem that an 
appropriate compromise to absolute security as you want feature and convenience.

> You are so clueless.  It's amazing.


No. The fact that I have tried an experiment and have a setup that has 
different priorities on it’s requirements to someone else’s setup or 
requirements is not clueless. It is different. OpenBSD just does not offer the 
functionality (e.g. a large, redundant filesystem, ala ZFS) I need to get the 
job I want to do done on it’s own. So I need additional software to achieve 
that. End of story. Yes it is a larger attack surface, yes it is added 
complexity. I fully understand that. But I need additional software to achieve 
my end goals.

This thread started with someone who is starting to learn and wanted to know 
which OS, OpenBSD or FreeBSD would be best for their requirements. I don’t feel 
putting forward an idea that you could run OpenBSD as a VM and have both is so 
unreasonable.

-Matt

— 
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
49b Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number: 
09076246

Re: FreeBSD or OpenBSD for my (server/router) purposes? (Total n00b)

[Matt Hamilton]

> On 27 Sep 2015, at 22:38, Eric Furman  wrote:
>
> You really don't get it. Running OpenBSD in a VM gives you no
> security benefits of OpenBSD. Your base security will be your
> host, in this case FreeBSD. And on top of that you are running
> a very complex piece of software, the VM. Who knows what
> security holes are in it.


I do get it. I guess you wrote this before reading my last reply. That
explains the situation.

Yes, the base security will be my host. Putting an OpenBSD VM on there does
not (IMHO) significantly decrease the security of that host. I agree that it
is adding complexities and there could be potentially unforeseen security
issues due to the combination. e.g. something like OpenBSD’s ability to
generate random number could somehow be affected by the underlying VM that
would not be present on bare metal.

Here is the actual blog post I wrote a while back about the setup:

https://www.quernus.co.uk/2015/07/27/openbsd-as-freebsd-router/
<https://www.quernus.co.uk/2015/07/27/openbsd-as-freebsd-router/>

The main goal of running OpenBSD in a VM was to provide easier configured and
more convenient IPSEC tunnel termination than FreeBSD can offer out of the
box.

-Matt


—
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
49b Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number:
09076246

Re: FreeBSD or OpenBSD for my (server/router) purposes? (Total n00b)

[Matt Hamilton]

> On 27 Sep 2015, at 18:35, Quartz mailto:qua...@sneakertech.com>> wrote:
>
>> In what way? If you mean the hypervisor does not provide adequate
separation
>> between VMs then that is not really an issue as I control the host and all
>> VMs. If any are compromised then I have bigger issues.
>
> The most secure system should be the host, not the guest. A super secure
guest inside a VM doesn't help much if the insecure host is compromised.

Indeed.

But that doesn’t matter in my scenario. I want a FreeBSD machine connected
to the net. Whether or not it contains an OpenBSD VM in it as a guest
doesn’t (IMHO) significantly affect it’s security.

-Matt


—
Matt Hamilton
Quernus
m...@quernus.co.uk <mailto:m...@quernus.co.uk>
+44 117 325 3025
49b Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number:
09076246

Re: FreeBSD or OpenBSD for my (server/router) purposes? (Total n00b)

[Matt Hamilton]

> On 27 Sep 2015, at 18:01, Theo de Raadt  wrote:
>
>> Quernus  wrote:
>>> On 27 Sep 2015, at 16:10, Stuart Henderson  wrote:
>>>
>>>> On 2015-09-27, Quernus  wrote:
>>>>
>>>> I actually run OpenBSD in a VM on FreeBSD using bhyve which gives me the
>> best
>>>> of both worlds.
>>>
>>> This has an impact on security, of course.
>>
>> In what way? If you mean the hypervisor does not provide adequate
separation
>> between VMs then that is not really an issue as I control the host and all
>> VMs. If any are compromised then I have bigger issues.
>
> We don't need to make precise claims about which parts will break, nor
> how.

I’m not asking that. I was just curious as to what the basis was for the
‘this has an impact of security’ statement with no context or backup of
the statement.

> The problem here is the process of gluing all-the-parts together
> without evaluating what is oging on.  You need not talk about big
> issues once things go worng -- you do have big issues right from the
> start, just like everyone else.
>
> Once you hook a system up to the internet, it is the internet that is
> trying to push the buttons of the system.

Indeed, hence the statement ‘This has an impact on security, of course’
could be applied to attaching any software or hardware of any kind to any kind
of network. Writing this email ‘has an impact on security, of course’.
Opening my front door in the morning 'has an impact on security, of course’.
It is a uselessly vague statement on it’s own.

> By combining many disparate pieces together, you require all those
> layers of software to make the right decisions, and never make wrong
> decisions.  You require all the programmers to be largely infallable.
>
> You are testing all the parts at once.
>
> There's a general rule which may apply here:
>
>More software, more bugs.
>
> It is clear that your priority is on gaining more operational
> features, rather than greater quality.

Yup. Alas, utopia doesn’t exist. We all have to make compromises and
prioritise our requirements and trade offs. For me, this is a very nice blend
of security, manageability and convenience for my use-case. YMMV.

> I know lots of people are doing the same.  Anyways, good luck with it
> long term.

Thanks! I’m blogging about how it is turning out. So far seems to be working
pretty nicely.

-Matt

—
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
49b Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number:
09076246

Re: ipsec tunnel over IPv6

[Matt Hamilton]

Nevermind! Worked it out… I spotted that the pings I were doing from the
gateways were using the source address of the external interface, which was
not part of the SA.

explicitly adding the source address of the *internal* interface means it now
looks good:

# traceroute6 -s 2001:470:1f1d:301::1  2001:41c8:11a:5::1
traceroute6 to 2001:41c8:11a:5::1 (2001:41c8:11a:5::1) from
2001:470:1f1d:301::1, 64 hops max, 60 byte packets
 1  2001:41c8:11a:5::1 (2001:41c8:11a:5::1)  32.884 ms  32.795 ms  32.316 ms
#

-Matt

> On 23 Sep 2015, at 22:31, Matt Hamilton  wrote:
>
> Hi all,
>  I’ve just tried to set up an IPSec tunnel between two IPv6 networks, over
IPv6 between the OpenBSD gateways. Isakmpd seems to have set the SAs up, but
traffic is not flowing over the tunnel.
>
> A ipsec.conf:
>
> ike dynamic esp from 2001:470:1f1d:301::/64 to 2001:41c8:11a:5::/64 local
2001:470:1f1c:301::2 peer 2001:41c8:11a::1 \
> main auth hmac-sha1  enc aes group modp1024 \
> quick auth hmac-sha1 enc aes \
> srcid 2001:470:1f1c:301::2 dstid 2001:41c8:11a::1 \
> psk secret
>
> B ipsec.conf:
>
> ike dynamic esp from 2001:41c8:11a:5::/64 to 2001:470:1f1d:301::/64 local
2001:41c8:11a::1 peer 2001:470:1f1c:301::2 \
> main auth hmac-sha1  enc aes group modp1024 \
> quick auth hmac-sha1 enc aes \
> srcid 2001:41c8:11a::1 dstid 2001:470:1f1c:301::2 \
> psk secret
>
> A ipsecctl -sa:
>
> # ipsecctl -sa
> FLOWS:
> flow esp in from 2001:41c8:11a:5::/64 to 2001:470:1f1d:301::/64 peer
2001:41c8:11a::1 srcid 2001:470:1f1c:301::2/128 dstid 2001:41c8:11a::1/128
type use
> flow esp out from 2001:470:1f1d:301::/64 to 2001:41c8:11a:5::/64 peer
2001:41c8:11a::1 srcid 2001:470:1f1c:301::2/128 dstid 2001:41c8:11a::1/128
type require
>
> SAD:
> esp tunnel from 2001:470:1f1c:301::2 to 2001:41c8:11a::1 spi 0x74ed3662 auth
hmac-sha1 enc aes
> esp tunnel from 2001:41c8:11a::1 to 2001:470:1f1c:301::2 spi 0x7b1c75cd auth
hmac-sha1 enc aes
>
> B ipsecctl -sa:
>
> FLOWS:
> flow esp in from 2001:470:1f1d:301::/64 to 2001:41c8:11a:5::/64 peer
2001:470:1f1c:301::2 srcid 2001:41c8:11a::1/128 dstid 2001:470:1f1c:301::2/128
type use
> flow esp out from 2001:41c8:11a:5::/64 to 2001:470:1f1d:301::/64 peer
2001:470:1f1c:301::2 srcid 2001:41c8:11a::1/128 dstid 2001:470:1f1c:301::2/128
type require
>
> SAD:
> esp tunnel from 2001:470:1f1c:301::2 to 2001:41c8:11a::1 spi 0x74ed3662 auth
hmac-sha1 enc aes
> esp tunnel from 2001:41c8:11a::1 to 2001:470:1f1c:301::2 spi 0x7b1c75cd auth
hmac-sha1 enc aes
>
>
> A ping from A to B:
> # ping6 2001:41c8:11a:5::1
> PING6(56=40+8+8 bytes) 2001:470:1f1c:301::2 --> 2001:41c8:11a:5::1
> 16 bytes from 2001:41c8:11a:5::1, icmp_seq=0 hlim=57 time=31.905 ms
> 16 bytes from 2001:41c8:11a:5::1, icmp_seq=1 hlim=57 time=31.843 ms
> 16 bytes from 2001:41c8:11a:5::1, icmp_seq=2 hlim=57 time=31.709 ms
> ^C
> --- 2001:41c8:11a:5::1 ping6 statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 31.709/31.819/31.905/0.082 ms
>
> The ping works, but it is *not* going over the tunnel. tcpdump is not
showing the traffic via enc0 or any ESP traffic on the external interface.
Traceroute6 also shows all intermediate hops, i.e. no tunnel.
>
> Is it because, being IPv6, the networks on each end can route to each other
(as opposed to on IPv4 normally they are RFC1918 networks) so OpenBSD send the
packets the ‘easy’ route?
>
> -Matt
>
> —
> Matt Hamilton
> Quernus
> m...@quernus.co.uk
> +44 117 325 3025
> 49b Easton Business Centre
> Felix Road, Easton
> Bristol, BS5 0HE
>
> Quernus Ltd is a company registered in England and Wales. Registered number:
09076246
>


—
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
49b Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number:
09076246

ipsec tunnel over IPv6

[Matt Hamilton]

Hi all,
  I’ve just tried to set up an IPSec tunnel between two IPv6 networks, over 
IPv6 between the OpenBSD gateways. Isakmpd seems to have set the SAs up, but 
traffic is not flowing over the tunnel.

A ipsec.conf:

ike dynamic esp from 2001:470:1f1d:301::/64 to 2001:41c8:11a:5::/64 local 
2001:470:1f1c:301::2 peer 2001:41c8:11a::1 \
 main auth hmac-sha1  enc aes group modp1024 \
 quick auth hmac-sha1 enc aes \
 srcid 2001:470:1f1c:301::2 dstid 2001:41c8:11a::1 \
 psk secret

B ipsec.conf:

ike dynamic esp from 2001:41c8:11a:5::/64 to 2001:470:1f1d:301::/64 local 
2001:41c8:11a::1 peer 2001:470:1f1c:301::2 \
 main auth hmac-sha1  enc aes group modp1024 \
 quick auth hmac-sha1 enc aes \
 srcid 2001:41c8:11a::1 dstid 2001:470:1f1c:301::2 \
 psk secret

A ipsecctl -sa:

# ipsecctl -sa  


FLOWS:
flow esp in from 2001:41c8:11a:5::/64 to 2001:470:1f1d:301::/64 peer 
2001:41c8:11a::1 srcid 2001:470:1f1c:301::2/128 dstid 2001:41c8:11a::1/128 type 
use
flow esp out from 2001:470:1f1d:301::/64 to 2001:41c8:11a:5::/64 peer 
2001:41c8:11a::1 srcid 2001:470:1f1c:301::2/128 dstid 2001:41c8:11a::1/128 type 
require

SAD:
esp tunnel from 2001:470:1f1c:301::2 to 2001:41c8:11a::1 spi 0x74ed3662 auth 
hmac-sha1 enc aes
esp tunnel from 2001:41c8:11a::1 to 2001:470:1f1c:301::2 spi 0x7b1c75cd auth 
hmac-sha1 enc aes

B ipsecctl -sa:

FLOWS:
flow esp in from 2001:470:1f1d:301::/64 to 2001:41c8:11a:5::/64 peer 
2001:470:1f1c:301::2 srcid 2001:41c8:11a::1/128 dstid 2001:470:1f1c:301::2/128 
type use
flow esp out from 2001:41c8:11a:5::/64 to 2001:470:1f1d:301::/64 peer 
2001:470:1f1c:301::2 srcid 2001:41c8:11a::1/128 dstid 2001:470:1f1c:301::2/128 
type require

SAD:
esp tunnel from 2001:470:1f1c:301::2 to 2001:41c8:11a::1 spi 0x74ed3662 auth 
hmac-sha1 enc aes
esp tunnel from 2001:41c8:11a::1 to 2001:470:1f1c:301::2 spi 0x7b1c75cd auth 
hmac-sha1 enc aes


A ping from A to B:
# ping6 2001:41c8:11a:5::1 
PING6(56=40+8+8 bytes) 2001:470:1f1c:301::2 --> 2001:41c8:11a:5::1
16 bytes from 2001:41c8:11a:5::1, icmp_seq=0 hlim=57 time=31.905 ms
16 bytes from 2001:41c8:11a:5::1, icmp_seq=1 hlim=57 time=31.843 ms
16 bytes from 2001:41c8:11a:5::1, icmp_seq=2 hlim=57 time=31.709 ms
^C
--- 2001:41c8:11a:5::1 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 31.709/31.819/31.905/0.082 ms

The ping works, but it is *not* going over the tunnel. tcpdump is not showing 
the traffic via enc0 or any ESP traffic on the external interface. Traceroute6 
also shows all intermediate hops, i.e. no tunnel.

Is it because, being IPv6, the networks on each end can route to each other (as 
opposed to on IPv4 normally they are RFC1918 networks) so OpenBSD send the 
packets the ‘easy’ route?

-Matt

— 
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
49b Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number: 
09076246

route6d issues

[Matt Hamilton]

Hi All,
  Just setting up my first ipv6 network on 5.7/amd64 and I’m trying to get 
route6d working on two hosts. But it is not able to transmit messages it seems:

20:35:11: Send(gif1): info(3) to ff02:9::9.521
sendmsg: Invalid argument
20:35:11: Send(gif0): info(3) to ff02:5::9.521
sendmsg: Invalid argument
20:35:11: Send(vio1): info(5) to ff02:2::9.521
sendmsg: Invalid argument
20:35:11: Send(vio0): info(4) to ff02:1::9.521
sendmsg: Invalid argument

I seem to be able to ping the multicast address and get some responses:

# ping6 ff02:1::9 
PING6(56=40+8+8 bytes) fe80::2a0:98ff:fe52:db56%vio0 --> ff02:1::9
16 bytes from fe80::2a0:98ff:fe52:db56%vio0, icmp_seq=0 hlim=64 time=0.045 ms
16 bytes from fe80::2a0:98ff:fe52:db56%vio0, icmp_seq=1 hlim=64 time=0.048 ms
^C
--- ff02:1::9 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.045/0.046/0.048/0.001 ms

I’ve got mforwarding enabled:

# sysctl -a | grep net.inet6.ip6 
net.inet6.ip6.forwarding=1
net.inet6.ip6.redirect=1
net.inet6.ip6.hlim=64
net.inet6.ip6.mrtproto=103
net.inet6.ip6.maxfragpackets=200
net.inet6.ip6.log_interval=5
net.inet6.ip6.hdrnestlimit=10
net.inet6.ip6.dad_count=1
net.inet6.ip6.auto_flowlabel=1
net.inet6.ip6.defmcasthlim=1
net.inet6.ip6.use_deprecated=1
net.inet6.ip6.rr_prune=5
net.inet6.ip6.v6only=1
net.inet6.ip6.maxfrags=200
net.inet6.ip6.mforwarding=1
net.inet6.ip6.multipath=1
net.inet6.ip6.multicast_mtudisc=0
net.inet6.ip6.neighborgcthresh=2048
net.inet6.ip6.maxifprefixes=16
net.inet6.ip6.maxifdefrouters=16
net.inet6.ip6.maxdynroutes=4096
net.inet6.ip6.dad_pending=0
net.inet6.ip6.mtudisctimeout=600
net.inet6.ip6.ifq.len=0
net.inet6.ip6.ifq.maxlen=256
net.inet6.ip6.ifq.drops=0

I’ve not got any pf rules blocking outbound traffic at all.

Any ideas what to check next?

-Matt

— 
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
49b Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number: 
09076246

How to lookup ICMP nat addresses with pf ioctl DIOCNATLOOK

[Matt Gessner]

 
When receiving ICMP packets via divert, which have been received from a NAT 
interface, how does one fill in the struct pfioc_natlook to get the information 
on the NAT’d host?

Given ‘struct pfioc_natlook nl;’ I have filled in nl as follows: 

memset nl to zero first
nl.saddr = ip header src addr field from the received packet
nl.daddr = ip header dest addr field from the received packet
nl.af = AF_INET
nl.proto = IPPROTO_ICMP

for nl.direction, I’ve tried both PF_IN and PF_OUT
for nl.sport and nl.dport, I’ve tried
nl.sport = ICMP type
nl.dport = ICMP code
and
nl.sport = ICMP code
nl.dport = ICMP type

In all cases, ioctl(pffd, DIOCNATLOOK, &nl) returns -1.

Thanks.

Matt

Re: My computer suddenly turned itself off.

[Matt M]

Sudden power offs are often indicative of heat issues, especially on
laptops. Does it power right back on and stay on for a long time? If not I
would suspect heat. If it does stay on, it may be a power management bug, a
bad power source or possibly a failing power supply in the machine.
 If it won't power back on right away, or won't stay on till it sits for a
while, try cleaning the cpu fan - they collect a lot of dust.


On Wednesday, January 21, 2015, Joel Rees  wrote:

> I'm looking under /var/log, but not seeing any logfiles to give me any
> clues.
>
> What information should I post? I have /var/log/messages from the
> moment of the crash, but it's about 36K.
>
> dmesg:
> ---
> OpenBSD 5.5-stable (GENERIC) #0: Sat Dec 13 14:38:02 JST 2014
> r...@ob.reiisi.homedns.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: AMD Sempron(tm) 2600+ ("AuthenticAMD" 686-class, 256KB L2 cache)
> 1.84 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
> real mem  = 737636352 (703MB)
> avail mem = 713281536 (680MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 07/28/04, BIOS32 rev. 0 @
> 0xfbaa0, SMBIOS rev. 2.3 @ 0xf0800 (33 entries)
> bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 07/28/2004
> bios0: MICRO-STAR INTERNATIONAL CO., LTD KM266-8237
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC
> acpi0: wakeup devices SLPB(S5) USB0(S1) USB1(S1) USB2(S1) USB3(S1)
> USB4(S1) USB5(S1) USB6(S1) USB7(S1) LAN0(S5) UAR1(S5) LPT1(S5)
> ECP1(S5) PCI0(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 333MHz
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 3, 24 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0
> acpitz0 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: PWRB
> acpibtn1 at acpi0: SLPB
> bios0: ROM list: 0xc/0x7e00 0xc8000/0x1a00!
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "VIA VT8378 PCI" rev 0x00
> viaagp0 at pchb0: v3
> agp0 at viaagp0: aperture at 0xe000, size 0x1000
> ppb0 at pci0 dev 1 function 0 "VIA VT8377 AGP" rev 0x00
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 "VIA VT8378 VGA" rev 0x01
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> pciide0 at pci0 dev 7 function 0 "ITExpress IT8212F" rev 0x13: DMA,
> channel 0 wired to native-PCI, channel 1 wired to native-PCI
> pciide0: using apic 2 int 18 for native-PCI interrupt
> wd0 at pciide0 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA48, 156334MB, 320173056 sectors
> wd1 at pciide0 channel 0 drive 1: 
> wd1: 16-sector PIO, LBA48, 305245MB, 625142448 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
> wd1(pciide0:0:1): using PIO mode 0
> pciide1 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x06: ATA133,
> channel 0 configured to compatibility, channel 1 configured to
> compatibility
> wd2 at pciide1 channel 0 drive 0: 
> wd2: 16-sector PIO, LBA, 78167MB, 160086528 sectors
> wd2(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
> atapiscsi0 at pciide1 channel 1 drive 0
> scsibus0 at atapiscsi0: 2 targets
> cd0 at scsibus0 targ 0 lun 0:  ATAPI
> 5/cdrom removable
> cd0(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 3
> uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x81: apic 2 int 21
> uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x81: apic 2 int 21
> uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0x81: apic 2 int 21
> uhci3 at pci0 dev 16 function 3 "VIA VT83C572 USB" rev 0x81: apic 2 int 21
> ehci0 at pci0 dev 16 function 4 "VIA VT6202 USB" rev 0x86: apic 2 int 21
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "VIA EHCI root hub" rev 2.00/1.00 addr 1
> viapm0 at pci0 dev 17 function 0 "VIA VT8237 ISA" rev 0x00: SMI
> iic0 at viapm0
> iic0: addr 0x2f 00=00 01=07 02=00 03=00 04=07 05=00 06=00 07=00 14=14
> 15=62 16=03 17=02 words 00=00ff 01=07ff 02=00ff 03=00ff 04=07ff
> 05=00ff 06=00ff 07=00ff
> spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM non-parity PC2700CL2.5
> spdmem1 at iic0 addr 0x51: 256MB DDR SDRAM non-parity PC2700CL2.5
> auvia0 at pci0 dev 17 function 5 "VIA VT8233 AC97" rev 0x60: apic 2 int 22
> ac97: codec id 0x56494170 (VIA Technologies VT1617)
> ac97: codec features headphone, 18 bit DAC, 18 bit ADC, KS Waves 3D
> audio0 at auvia0
> vr0 at pci0 dev 18 function 0 "VIA RhineII-2" rev 0x78: apic 2 int 23,
> address 00:11:09:b4:08:41
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 8: OUI
> 0x004063, model 0x0032
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 "VIA UHCI root hub" rev 1.00/1.00 addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 "VIA UHCI root hub" rev 1.00/1.00 addr 1
> usb3 at

Re: OpenBSD embedded? (was: OpenBSD 5.6-current on ASUS Chromebox)

[Matt]

> The lovable scamp Ted Unangst posted about a box with dual broadcoms, Atom 
> CPU, DDR3 RAM, etc for $129 on his blog:
> 
> http://www.tedunangst.com/flak/post/new-home-router
> 
> -Chester 
> 
> "Enjoy those tacos now, for in a thousand years they will be illegal! Ha ha 
> ha ha-I think we all know why."  - Benjamin Franklin



My ideal would be to find an inexpensive, VLAN-capable (802.1q) switch (ideally 
Gigabit - we now have local broadband exceeding 100Mbps).

Then, we’re not constrained by the number of ethernet ports on our device of 
choice, or whether we can shoe-horn in another NIC.

My typical ports allocations on the VLAN switch:
1 - OpenBSD device
2 - DSL/Cable modem (upstream)
3 - LAN
4 - Wireless access point

Thoughts?

Matt

Re: TCP checksum problems with NAT (maybe vlans/tun)

[Matt Hamilton]

I've been further looking at this, trying to work out where to 'fix'
it.

Various options seem to be:

1) Get the tun interface to re-calculate the TCP checksums
2) Get pf to have a flag telling it to calculate the checksums always
for a given rule
3) Get OpenVPN to calculate the checksums at some point

However I've managed to come up with a simpler scenario that does
not involve NAT and that still fails.

I have a bridge with two members:

bridge0:
  bnx0 (192.168.1.1/24)
  tun0

tun0 has OpenVPN running on it to some endpoint, but this could be any
other type of tunnel.

the IP of the OpenBSD box is assigned to the bnx0 interface. I am on a
laptop on the other end of the bridged OpenVPN link with IP address
192.168.1.145.

# arp -n 192.168.1.145
? (192.168.1.145) at 2a:ff:11:02:ea:76 on bnx0

# ifconfig bridge0 | grep 2a:ff:11:02:ea:76
2a:ff:11:02:ea:76 tun0 1 flags=0<>

# route -n get 192.168.1.145
   route to: 192.168.1.145
destination: 192.168.1.145
  interface: bnx0
 if address: 192.168.1.1
   priority: 8 (static)
  flags: 
 use   mtuexpire
 540 0L 1189 

I *can't* get a TCP connection from my laptop (192.168.1.145) to the
OpenBSD box (192.168.1.1). The TCP checksums are invalid. 

Based on the info above it would seem that the routing table thinks
the packet should be routed to bnx0 based on the IP address. bnx0
supports HW tcp checksums, so the OS does not create the checksum
itself.

But the packet never goes out bnx0, it is picked up by the bridge and
sent down tun0 instead. tun interfaces do no recompute the tcp
checksum and so by the time the packet gets to my laptop the checksum
has never been correctly calculated and my laptop ignores the packet.

So what do we need to do to fix this? Is getting the tun interface to
calculate the checksums the way to go?

-Matt

Re: TCP checksum problems with NAT (maybe vlans/tun)

[Matt Hamilton]

Matt Hamilton  netsight.co.uk> writes:

> 
> Hi All,
>   I just been upgrading a router from OpenBSD 5.1 to 5.4 and hit a
>  big problem

Doh! I meant 5.5, not 5.4.

Digging about it looks like the following change by Henning may 
shed some light:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c
?rev=1.837&content-type=text/x-cvsweb-markup&f=h

Specifically the comment:

"in all output pathes, very late, if we figure out the outbound
interface
 doesn't have hw cksum offloading, do the cksum in software. this 
especially makes the bridge path behave like a regular output path"

Now, if I have a bridge, with two members, one that can do 
offloading (bnx) and one that can't (tun), what happens? And anyway
which is the output interface anyway?

e.g. if I had the following setup:

# cat /etc/hostname.vlan101
vlan 101 vlandev trunk0
description "Office network"
-inet6
up

# cat /etc/hostname.carp101 
carpdev vlan101
vhid 101
pass secret
advskew 100
inet 192.168.87.1 255.255.255.0
description "Office Network"
-inet6

# cat /etc/hostname.tun0
link0 up
description "OpenVPN tunnel interface"

# cat /etc/hostname.bridge0 
add vlan101
add tun0
up
description "OpenVPN bridge for tun and vlan101"


When a packet is destined to 192.168.87.10 which is on the end 
of the OpenVPN tunnel, ie according to bridge0 it is on tun0... 
what is the outbound interface according to PF and the code 
that makes the decision Henning talks about above?

-Matt

TCP checksum problems with NAT (maybe vlans/tun)

[Matt Hamilton]

Hi All,
  I just been upgrading a router from OpenBSD 5.1 to 5.4 and hit a big problem
I'm finding that in certain circumstance TCP packets have incorrect checksums.
I know some checksum work was done recently, so maybe something has
gone awry (or I've missed something simple).

I have OpenVPN listening on a CARP interface which is on top of a VLAN
interface, which is on top of a Trunk (LACP) interface on top of a pair of
bnx interfaces.

The VPN connection itself sets up just fine. It is a bridging setup with tun0 
in a bridge group with another vlan interface. Once connected I can ping 
everything just fine. Packets going out of the router to certain places go
through NAT. 

However TCP connections that go via NAT don't work. TCP connections that
take *exactly* the same physical and logic network path, but are not NATd
work just fine.

Running tcpdump on various interfaces shows that the TCP checksum is
invalid by the time the OpenVPN client machine gets it. It is correct when it
hits the inbound interface on the OpenBSD 5.4 box. It shows invalid on its
way out the tun interface. And it is invalid when it comes out the other end
of the VPN tunnel.

So my guessing is that when PF is rewriting the headers it is not (correctly)
calculating the checksum. The checksum *is* different before and after NAT,
so I'm guessing it is attempting to recalculate the checksum but getting it
wrong. 

If that packet was then to go out a physical interface (e.g. bnx) then I guess 
the NIC would put the correct checksum back on. But as it is instead being
sent down a tun interface that it is not getting corrected at all.

Does this sound like a likely hypothesis to anyone who knows the changes
that were made?

-Matt

PF queuing max bandwidth

[Matt Carey]

While trying to upgrade a pf ruleset from 5.4 to 5.5 and make use of the new 
queuing system, I'm running into an issue where the traffic isn't getting 
throttled to what I set for a max on a given queue.

Below is the old ruleset that works well under 5.4:
altq on trunk0 bandwidth 9.70Mb hfsc queue { q_voip, q_normal}
queue q_voip bandwidth 1Mb hfsc(realtime 1Mb)
queue q_normal bandwidth 8.70Mb qlimit 500 hfsc(default red ecn upperlimit 
8.70Mb)

Belw is the new ruleset that I have for 5.5:
queue std on trunk0 bandwidth 10M, max 10M
queue q_voip parent std bandwidth 1M, min 1M qlimit 500
queue q_normal parent std bandwidth 8M, max 8M default qlimit 500


When looking at the measured throughput on the q_normal queue it isn't being 
ceilinged @ the 8MB from the config:
# pfctl - -s queue 

queue std on trunk0 bandwidth 10M, max 10M qlimit 50
  [ pkts:          0  bytes:          0  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/ 50 ]
  [ measured:     0.0 packets/s, 0 b/s ]
queue q_voip parent std on trunk0 bandwidth 1M, min 1M qlimit 500
  [ pkts:         90  bytes:      57032  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/500 ]
  [ measured:     3.4 packets/s, 19.38Kb/s ]
queue q_normal parent std on trunk0 bandwidth 8M, max 8M default qlimit 500
  [ pkts:     101676  bytes:   98995630  dropped pkts:      0 bytes:      0 ]
  [ qlength:   0/500 ]
  [ measured:  1192.5 packets/s, 9.32Mb/s ]

The interface config is pretty simple, 2 ports bundled together into a LACP 
trunk then WAN hangs off a vlan on that trunk. Any help would be appreciated.

Re: 5.5 CDs arriving

[Matt Behrens]

On Apr 30, 2014, at 12:56 PM, Dave Anderson  wrote:

> Just got mine, near Boston, Mass.

Mine arrived in Grand Rapids, MI yesterday.

> My thanks to everyone involved.

And mine as well!

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Oerrs on vlan interfaces

[Matt Carey]

I'm trying to track down the source of what is causing output errors on vlan
interfaces for 2 separate physical systems.  For example when looking at
netstat between 2 different runs the values are always incrementing:

#
netstat -s -f inet -I vlan800 && echo && sleep 5 && netstat -s -f inet -I
vlan800 
Name    Mtu   Network     Address              Ipkts Ierrs    Opkts
Oerrs Colls
vlan800 1500        00:1c:23:e1:cf:48 187689428     0
148043392 262767     0

Name    Mtu   Network     Address              Ipkts
Ierrs    Opkts Oerrs Colls
vlan800 1500        00:1c:23:e1:cf:48
187691085     0 148044677 262770     0


Name    Mtu   Network     Address
             Ipkts Ierrs    Opkts Oerrs Colls
vlan200 1500      
 00:1c:23:e1:cf:48 18139570     0 18645286 40217     0
vlan300 1500    
   00:1c:23:e1:cf:48  2562460     0  3460373  2720     0

vlan500 1500  
     00:1c:23:e1:cf:48 112356993     0 141163651 158443     0



The hardware
is 2 Dell PowerEdge 860 servers using the onboard Broadcom BCM5721 NICs. Each
system is attached to a different Procurve switch with the 2 onboard NICs in a
LACP trunk configuration. The 2 systems are setup in an HA configuration using
carp/pf that runs very well.  When looking for any type of issues on the
switch ports they come back clean for all uplinks to the Dells:
  Errors
(Since boot or last clear) :                                    
   FCS Rx    
     : 0                  Drops Rx        : 0                 
   Alignment Rx
   : 0                  Collisions Tx   : 0                 
   Runts Rx      
 : 0                  Late Colln Tx   : 0                 
   Giants Rx      
: 0                  Excessive Colln : 0                 
   Total Rx Errors :
0                  Deferred Tx     : 0                 

The same behavior is
mimicked on both systems as the counters start incrementing when failing over
the carp interfaces between the peers. Another oddity that is the physical
interfaces show no output errors just input errors:

# netstat -ni
Name    Mtu
  Network     Address              Ipkts Ierrs    Opkts Oerrs Colls
bge0  
 1500        00:1c:23:e1:cf:48 284587839 103261 120699706     0     0
bge0    1500  fe80::%bge0 fe80::21c:23ff:fe 284587839 103261 120699706     0  
  0
bge1    1500        00:1c:23:e1:cf:48 61755734   193 233219963     0
    0
bge1    1500  fe80::%bge1 fe80::21c:23ff:fe 61755734   193 233219963    
0     0
...
trunk0  1500        00:1c:23:e1:cf:48 346220631     0
353798619   167     0
trunk0  1500  192.168.201 192.168.201.23    346220631  
  0 353798619   167     0
trunk0  1500  fe80::%trun fe80::21c:23ff:fe
346220631     0 353798619   167     0
...

Any advice would be appreciated on
what else to look for that is causing these errors.

Regards,
Matt

Additional
info if it helps:
# netstat -sn  
ip:
        461996032 total packets received
        21 bad header checksums
        0 with size smaller than minimum
     
  0 with data size < data length
        0 with header length < data size
   
    0 with data length < header length
        0 with bad options
        0
with incorrect version number
        0 fragments received
        0 fragments
dropped (duplicates or out of space)
        0 malformed fragments dropped
   
    0 fragments dropped after timeout
        0 packets reassembled ok
       
136026433 packets for this host
        0 packets for unknown/unsupported
protocol
        324667376 packets forwarded
        550005 packets not
forwardable
        0 redirects sent
        11050218 packets sent from this
host
        192 packets sent with fabricated ip header
        0 output
packets dropped due to no bufs, etc.
        0 output packets discarded due to
no route
        187636 output datagrams fragmented
        187734 fragments
created
        17589 datagrams that can't be fragmented
        0 fragment
floods
        0 packets with ip length > max ip packet size
        0
tunneling packets that can't find gif
        0 datagrams with bad address in
header
        347724405 input datagrams checksum-processed by hardware
     
  356771381 output datagrams checksum-processed by hardware
        410308
multicast packets which we don't join
icmp:
        1171928 calls to
icmp_error
        0 errors not generated because old message was icmp
       
Output packet histogram:
                echo reply: 295802
               
destination unreachable: 1143260
                time exceeded: 4
        0
messages with bad code fields
        0 messages < minimum length
        46
bad checksums
        4 messages with bad length
        64 echo requests to
broadcast/multicast rejected
        Input packet histogram:
               
echo reply: 22496
                destination unreachable: 22342
             
  source quench: 17
                routing redirect: 172
               
echo: 295866
                time exceeded: 1172
        295802 message
responses generated
ig

Re: Upgrade path from 4.1?

[Matt M]

Your best option would be to backup data and configs, and reinstall fresh.
There are so many releases between 4.1 and 5.4 that you're going to spend a
lot of time just to get to -current or -stable 5.4, while you're still
gonna have to modify config files that have changes since 4.1 that it
probably wouldn't be worth the time and effort. As far as skipping
versions, first you're gonna have a lot of issues going straight from 4.1
to 5.4. If you just look at the changelogs between each version, you'll see
a lot of things have been removed or considered defunct, and configuration
for services may have changed dramatically (pf and softraid, for example).

Do yourself the favor and save the headaches by just reloading fresh and
porting over any configs.


On Thu, Feb 6, 2014 at 4:49 AM, davy  wrote:

> Hi,
>
> I've recently was asked to take over the maintenance of an old OpenBSD
> machine, which has not been updated in the last 7 years.
>
> Currently the machine has been running for close to 1000 days on 4.1. It
> has been a while since I worked with OpenBSD (shame on me), and I'm really
> not sure what the best way would be to upgrade this machine, knowning I
> don't have a serial or local access to the box.
>
> Can I do a 4.1 -> 5.4 in one shot?
>
> thx!
> Davy

Cisco routers

[Matt M]

This may not be the most appropriate place to ask, but I figured a lot of
you are using Cisco on your networks.

I am beginning to study for the CCNA and I want to purchase at least one
Cisco router and a switch for a home lab. I don't want to spend a lot of
money unnecessarily, and have been looking at the 2600 routers. Since I
don't know anything about Cisco hardware, I don't know if this is too old,
if it still applies in the industry, what I might be lacking in the IOS and
the hardware capabilities, etc.

What would you guys recommend for a starter lab that will give me what I
need to apply to real-world networks?

PF port forwarding issue

[Matt M]

I am using PF on 5.4-stable to NAT and firewall my network, but I can't get
port forwarding to work. All requests end up at the OpenBSD box and go no
further. For instance, I opened port 22 in PF to forward to a Centos box,
but ssh on the openbsd box still takes the request. Port 80 isn't working
at all, as there is no apache on the openbsd box. PF is running on
192.168.2.160 and apache is on 192.168.2.170. I can access apache by
directly connecting to 192.168.2.170

Thanks for any help.

PF.conf
---
ext_if = "dc0"
int_if = "vr0"

icmp_types="echoreq"

#OPTIONS
set block-policy return
set loginterface egress
set skip on lo

#default block incoming traffic
block in log

#PORT FORWARDING
pass in on egress proto tcp from any to any port 22 rdr-to 192.168.2.170
port 22
pass in on egress proto tcp from any to any port 80 rdr-to 192.168.2.170
port 80

#NAT the entire network
match out on egress inet from !(egress:network) to any nat-to (egress:0)

#pass outgoing traffic through firewall with no checking
pass out quick

#antispoof protection
antispoof quick for { lo $int_if }

pass in inet proto icmp all icmp-type $icmp_types

Re: Is my 5.4 CD ok?

[Matt M]

There isn't any reason all the packages couldn't fit on a cd. Most are just
a few bytes to a few kb, and a small number are into a few MB. Browsing the
package list (for i386), it looks like the largest one might be 4mb.

You should set your pkg path to the cd if you want to install from there,
*export PKG_PATH=/mnt/cdrom/5.4/packages/`machine -a`/*(change to
the mount point of your cdrom)

Personally, I prefer to just set the pkg path to an http mirror as it is
just as fast, or often faster, than cdrom and I don't have to have the cd
on hand.


On Thu, Jan 16, 2014 at 7:28 PM, Mario  wrote:

> Hi list.
>
> I know you are all busy discussing electricity issues but maybe one of you
> can take a moment to answer this.
>
> Browsing my new CDs for first time ever, I am a little confused and I am
> seeking clarification.  Is the following normal?  Because when I think
> about it, can really over 14,000  packages (amd64 + hppa) fit on a CD.  I
> am puzzled.
>
> marst:349$ pwd
> /mnt/5.4/packages/amd64
> marst:350$ ls -l
> total 25238
> -r--r--r--  1 root  wheel  539 Aug  5 17:25 TRANS.TBL
> -r--r--r--  1 root  wheel   125468 Jul 29 13:26 bzip2-1.0.6p0.tgz
> -r--r--r--  1 root  wheel   674979 Jul 29 13:26 curl-7.26.0p3.tgz
> -r--r--r--  1 root  wheel  7556487 Jul 29 13:26 gettext-0.18.2p3.tgz
> -r--r--r--  1 root  wheel  2012934 Jul 29 13:26 gnupg-1.4.13p0.tgz
> -r--r--r--  1 root  wheel  159 Aug  5 17:22 index.txt
> -r--r--r--  1 root  wheel  1521545 Jul 29 13:26 libiconv-1.14p0.tgz
> -r--r--r--  1 root  wheel   264257 Jul 29 13:26 libidn-1.27.tgz
> -r--r--r--  1 root  wheel   280021 Jul 29 13:26 rsync-3.0.9p3.tgz
> -r--r--r--  1 root  wheel   165840 Jul 29 13:26 unzip-6.0p2.tgz
> -r--r--r--  1 root  wheel   322276 Jul 29 13:26 xz-5.0.5.tgz
> marst:351$
>
> I guess the question is are all the binaries supposed to be on CD because
> if I follow instructions as per booklet:
>
> % su
> Password : 
> # mount /dev/cd0a /mnt
> # /mnt/5.4/packages/amd64
> # pkg_add emacs-21.4p23.tgz
>
> That's not working.  Well it worked when my $PKG_PATH was still set on ftp
> but I suppose PKG_PATH is supposed to be set to the CD path.
>
> Also nowhere on CD2 I can find the soundtrack.  I suppose that should be
> easy.  I would really need a song at the moment.
>
> --
> Mario

Re: Virtualize or bare-metal?

[Matt M]

I personally wouldn't advise using a single bare-metal machine just for
dhcp, a separate one for dns, a separate one for sendmail etc. Seems like a
huge waste of resources to me. My opinion is that you would fare better, as
was suggested earlier, to use some of the other bare-metal machines for
more intensive tasks like Apache. And, I always like to have a spare box or
two to experiment with different things on, so I would keep one just for
that if it were me. Virtualizing is great for testing and experimenting,
but sometimes you can't beat a real machine for that.


On Tue, Jan 14, 2014 at 12:50 AM, Christopher Ahrens wrote:

> Matthew Weigel wrote:
>
>> On 1/13/2014 9:11 PM, Christopher Ahrens wrote:
>>
>>> Jack Woehr wrote:
>>>
 Christopher Ahrens wrote:

>
> Wish I could split everything off to physical, but all I have for
> space for is a mini-rack that fits under my desk in my apartment
>

 Sounds like you have answered your own question!


>>> What I meant by bare-metal was if I should run a bunch of services on
>>> the same
>>> installation of OpenBSD.
>>>
>>
>> Well, hardware failures on a small pool of machines are still hardware
>> failures on a small pool of machines, whether you have virtual servers or
>> not.
>>
>> For security, chroot (especially with privilege separation) accomplishes
>> a lot
>> of what virtualization claims to offer, with a much longer history of
>> auditing
>> and better understood weaknesses.
>>
>> It is usually easier, in my experience, to manage one system running many
>> services in individual chroot environments than to manage many (virtual)
>> systems.  Files in chroot environments will sometimes need to be updated
>> when
>> you change the main system, but in my experience this is a much easier
>> task to
>> identify and manage than applying those changes en masse to a collection
>> of
>> virtual hosts.  Plus, there will be plenty of system updates to the main
>> system that don't need to trickle down to the chroot environments, but
>> will
>> almost always need to be applied individually to each virtual host.
>>
>> You may still want to physically separate some concerns if you have enough
>> machines (e.g., build machines vs. service machines, spreading out
>> disk-intensive services, etc.), but in general I don't think
>> virtualization
>> will particularly help you.
>>
>>
>
> OK, I think I'll try loading multiple services onto single machines, I'm
> thinking that I could always just attach a bunch of carp interfaces (one
> for each service) to the machine then if I want to move that service to
> another machine (Virtual or physical) I just destroy the carp interface and
> recreate it on the new one.
>
> At this point my plan is to use a pair of machines for a specific category
> (to allow for a machine failure or allow for update cycles with no
> downtime), each pair would handle one of Public internet services
> (external-facing DNS, Public Web server, SMTP filtering), internal services
> (Internal DNS, LDAP, CA), or business applications (Wiki, Mail Store / IMAP
> access, source code control).  The last two boxes used as spare and to test
> virtualization options.
>
> I am just not using a single machine for multiple roles (I cut my teeth on
> Windows 2000/2003 and picked up some bad habits and obsolete advice)

Re: VPN Between OpenBSD and iOS

[Matt Carlson]

mxb,

I tried that and I'm getting the same results. Any other ideas? What does
your npppd.conf look like?

Thanks,

Matt


On Fri, Jan 3, 2014 at 8:03 AM, mxb  wrote:

> I successfully connected my iOS 7.0.4 to an OpenBSD 5.4 (this is
> pre-release). My ipsec.conf for L2TP is this:
>
> ike passive esp transport \
> proto udp from $local_gw to any port 1701 \
>  main auth "hmac-sha1" enc "3des" group modp1024 \
>  quick auth "hmac-sha1" enc "aes" \
> psk “ReallyweakPassword”
>
>
>
> On 31 dec 2013, at 05:01, Mike Pistone  wrote:
>
> > Strangely enough I am having the exact same problem.  OPENBSD 5.4, etc.
> >
> > Phase I works once I tweaked my isakmp settings to match IOS7's
> capabilities
> > (no modp2048 mainly), but I get the same messages Matt does on phase II.
> >
> >
> > I have a npppd PPTP tunnel to the same server that works fine.
> > It is just L2TP/IPSEC that has the issues.
> >
> >
> > Mike

Re: VPN Between OpenBSD and iOS

[Matt Carlson]

Jeff,

Here you go:

$ grep -v ^# /etc/npppd/npppd.conf


authentication LOCAL type local {

users-file "/etc/npppd/npppd-users"

}

tunnel L2TP_ipv4 protocol l2tp {

listen on 0.0.0.0

}

ipcp IPCP {

pool-address 10.0.0.2-10.0.0.254

dns-servers 8.8.8.8

}

interface pppx0 address 10.0.0.1 ipcp IPCP

bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx0

Thanks,

Matt


On Mon, Dec 30, 2013 at 4:10 PM, Jeff Goettsch wrote:

> What does your npppd.conf look like?
>
>
>
> --
> Jeff Goettsch
> Agricultural and Resource Economics
> http://agecon.ucdavis.edu/
> 530-752-2219
>
>
> On 12/29/13 5:58 PM, Matt Carlson wrote:
>
>> Hello,
>>
>> I'm trying to get my iPhone with iOS 7.0.4 to connect to my OpenBSD
>> VPN server. If I understand the problem correctly, it's unable to
>> negotiate phase 2. I'd welcome any pointers.
>>
>> Below, I've provided the output of uname, rc.conf.local, ipsec.conf,
>> messages, isakmpd.pcap. I changed a couple IP addresses and FQDNs
>> (e.g. 10.a.b.c) and I removed some line from /var/log/messages and
>> replaced them with "", since this is already fairly long.
>>
>> I welcome any suggestions/recommendations.
>>
>> Thanks,
>>
>> Matt
>>
>> # uname -a
>> OpenBSD carbon.my.domain 5.4 GENERIC#37 i386
>> # cat /etc/rc.conf.local
>>
>>
>> ipsec=YES
>> isakmpd_flags="-Kv"
>> ftpproxy_flags=""
>> ntpd_flags=
>> pppd_flags=""
>> route6d_flags=""
>> named_flags=""
>> # grep -v ^# /etc/ipsec.conf
>>
>>
>> ike passive esp transport \
>> proto udp \
>> from any to any port 1701 \
>> main auth "hmac-sha1" enc "aes" group modp1024 \
>> quick auth "hmac-sha1" enc "aes-256" \
>> psk "1"
>> # cat /var/log/messages
>> 
>> Dec 29 16:31:23 carbon named[6427]: starting BIND 9.4.2-P2
>> Dec 29 16:31:24 carbon named[6427]: command channel listening on
>> 127.0.0.1#953
>> Dec 29 16:31:24 carbon named[6427]: command channel listening on ::1#953
>> Dec 29 16:31:24 carbon named[6427]: running
>> Dec 29 16:31:26 carbon isakmpd[595]: isakmpd: starting
>> Dec 29 16:31:29 carbon npppd[22659]: Starting npppd pid=22659
>> version=5.0.0
>> Dec 29 16:31:30 carbon isakmpd[28467]: log_packet_init: starting IKE
>> packet
>> capture to file "/var/run/isakmpd.pcap"
>> Dec 29 16:31:30 carbon npppd[22659]: Load configuration
>> from='/etc/npppd/npppd.conf' successfully.
>> 
>> Dec 29 16:32:58 carbon isakmpd[28467]: isakmpd: phase 1 done (as
>> responder): initiator id 10.a.b.c, responder id 69.g.h.i, src: 69.g.h.i
>> dst: 166.d.e.f
>> Dec 29 16:32:59 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:32:59 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:02 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:02 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:06 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:06 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:09 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:09 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:12 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:12 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:16 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
>> proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
>> Dec 29 16:33:16 carbon isakmpd[28467]: dropped message from 166.d.e.f port
>> 48970 due to notification type INVALID_ID_INFORMATION
>> Dec 29 16:33:19 carbon isakmpd[28467]: responde

Re: VPN Between OpenBSD and iOS

[Matt Carlson]

Yasuoka,

I tried that just now and it doesn't seem to make a difference.

Thanks,

Matt


On Mon, Dec 30, 2013 at 7:34 PM, YASUOKA Masahiko wrote:

> Hi,
>
> On Sun, 29 Dec 2013 20:58:03 -0500
> Matt Carlson  wrote:
> > # grep -v ^# /etc/ipsec.conf
> >
> >
> > ike passive esp transport \
> >proto udp \
> >from any to any port 1701 \
> >main auth "hmac-sha1" enc "aes" group modp1024 \
> >quick auth "hmac-sha1" enc "aes-256" \
> >psk "1"
>
> AFAIK, fixed IP address should be used for the source address.
>
> Does changing
>
> from any to any port 1701 \
>
> to
>
> from "69.g.h.i" to any port 1701 \
>
> fix the problem?
>
> --yasuoka

VPN Between OpenBSD and iOS

[Matt Carlson]

Hello,

I'm trying to get my iPhone with iOS 7.0.4 to connect to my OpenBSD
VPN server. If I understand the problem correctly, it's unable to
negotiate phase 2. I'd welcome any pointers.

Below, I've provided the output of uname, rc.conf.local, ipsec.conf,
messages, isakmpd.pcap. I changed a couple IP addresses and FQDNs
(e.g. 10.a.b.c) and I removed some line from /var/log/messages and
replaced them with "", since this is already fairly long.

I welcome any suggestions/recommendations.

Thanks,

Matt

# uname -a
OpenBSD carbon.my.domain 5.4 GENERIC#37 i386
# cat /etc/rc.conf.local


ipsec=YES
isakmpd_flags="-Kv"
ftpproxy_flags=""
ntpd_flags=
pppd_flags=""
route6d_flags=""
named_flags=""
# grep -v ^# /etc/ipsec.conf


ike passive esp transport \
   proto udp \
   from any to any port 1701 \
   main auth "hmac-sha1" enc "aes" group modp1024 \
   quick auth "hmac-sha1" enc "aes-256" \
   psk "1"
# cat /var/log/messages

Dec 29 16:31:23 carbon named[6427]: starting BIND 9.4.2-P2
Dec 29 16:31:24 carbon named[6427]: command channel listening on
127.0.0.1#953
Dec 29 16:31:24 carbon named[6427]: command channel listening on ::1#953
Dec 29 16:31:24 carbon named[6427]: running
Dec 29 16:31:26 carbon isakmpd[595]: isakmpd: starting
Dec 29 16:31:29 carbon npppd[22659]: Starting npppd pid=22659 version=5.0.0
Dec 29 16:31:30 carbon isakmpd[28467]: log_packet_init: starting IKE packet
capture to file "/var/run/isakmpd.pcap"
Dec 29 16:31:30 carbon npppd[22659]: Load configuration
from='/etc/npppd/npppd.conf' successfully.

Dec 29 16:32:58 carbon isakmpd[28467]: isakmpd: phase 1 done (as
responder): initiator id 10.a.b.c, responder id 69.g.h.i, src: 69.g.h.i
dst: 166.d.e.f
Dec 29 16:32:59 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:32:59 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:02 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:02 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:06 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:06 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:09 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:09 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:12 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:12 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:16 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:16 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:19 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:19 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:22 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:22 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:25 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:25 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:29 carbon isakmpd[28467]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 10.a.b.c, responder id 69.g.h.i
Dec 29 16:33:29 carbon isakmpd[28467]: dropped message from 166.d.e.f port
48970 due to notification type INVALID_ID_INFORMATION
Dec 29 16:33:29 carbon isakmpd[28467]: isakmpd: Peer 166.d.e.f made us
delete live SA peer-default for proto 1, initiator id: 10.a.b.c, responder
id: 69.g.h.i
# tcpdump -vvr /var/run/isakmpd.pcap
tcpdump: WARNING: snaplen raised from 116 to 65536
16:32:57.256488 mobile-166-d-e-f.mycingular.net.6885 >
c-69.g.h.i.hsd1.va.comcast.net.isakmp: [udp sum ok] isakmp v1.0 exchang

Setting relayd outbound source address/using existing NAT rules

[Matt Carey]

In an attempt to use relayd as an outbound http "proxy", which is just needed
to do URL filtering rather then content caching, I'm finding that the outbound
connections are being sourced from the IP of the external interface of the
firewall rather then the carp interface that the pf NAT rules are using for
other traffic. 

For example if the following IP scheme is used/pf rules are
in place:
ext_if="1.1.1.1"
carp_if="1.1.1.2" 
int_if="172.31.1.1"
match out on
$ext_if inet from $int_if:network to any nat-to 1.1.1.2 label "NAT [OUT] -
Desktop"
pass in log quick on $int_if proto tcp from $int_if:network to any
port http divert-to 127.0.0.1 port 8080

/etc/relayd.conf:
http protocol
httpfilter {
    return error
    label "URL filtered!"
   
request url filter "www.example.com/"
}

relay httpproxy {
    listen on
127.0.0.1 port 8080
    forward to destination
}

When the divert line in
/etc/pf.conf is commented out then the traffic on the WAN/external interface
is sourced from 1.1.1.2, however when the traffic is diverted to relayd then
the traffic is sourced from 1.1.1.1. Ideally I'd like the traffic to source
from the typical NAT interface, as when the carp interface is failed over to
the peer firewall those sessions in the state table are preserved. With squid
I found that this can be accomplished by using the tcp_outgoing_address
attribute to force the traffic to be sourced from a given address.

Any
help/advice would be appreciated.

Regards,
Matt

Re: pflow packets before state expires

[Matt Hamilton]

sven falempin  gmail.com> writes:

> 
> The manual say the information is extracted from the state table.
> So you should have seen the info.
> 
> First: are you sure the information wasnt in the udp pflow packets ? maybe
> the collector was wrong.
> Second: man says < controlled by the mtu.>>

The problem is that (I believe) that the pflow packet is not generated until
the state expires from pf. In the case of the scp transfer I saw that was not
for several days. Meaning I had no accounting/reporting of this data
transfer until it ended and the state expired. At which point the entire
data transferred during that state's life was counted as if it happened now.

-Matt

pflow packets before state expires

[Matt Hamilton]

Hi All,
  We use pflow with pf to export packets to a collector for billing/monitoring
purposes. The problem we have is that someone at the weekend had a very
long running scp connection over several days that transferred a TB
of data.  The data was not logged via pflow until the state expired, so
then showed a massive spike when the state expired.

Anyone know any way around this? Is it possible to get pf/pflow to 
export more regularly? Or set some timeout? I'm guessing not due
to the architecture, and unless I force pf states to timeout then I'm
stuck? But thought I'd ask in case anyone knew of a way.

Thanks
-Matt

Re: pf and apache

[Matt Morrow]

Thanks everyone. Seems to be working from outside, so for now I'll just go
with the direct ip of the server when I need to access it internally.

On Fri, Mar 1, 2013 at 11:22 AM, Pawel Jurusz wrote:

> Hello,
>
> If You are using only redirections, source host will receive SYN-ACK
> from 192.168.1.70, but there was not previously SYN to this address, so
> source host will send TCP Reset. Solution may be:
>
> pass in on $int_if proto tcp from $int_if:network to any port 80 rdr-to
> 192.168.1.70
> pass out on $int_if proto tcp from $int_if:network to any port 80
> received-on $int_if nat-to $int_if
>
>
> W dniu 01.03.2013 06:07, Matt Morrow pisze:
> > I have pf running on an openbsd box handling port forwarding. All ports
> > seem to forward ok except for port 80.
> >
> > Apache is running on a slackware box. I can access apache just fine
> > internally by using the ip address of that server (192.168.1.70), but if
> I
> > access the ip of the openbsd box (192.168.1.60) I just get an error that
> > the server is not available. It should be forwarding port 80 to the
> > slackware box.
> >
> > Here is my pf.conf
> > -
> > ext_if = "rl0"
> > int_if = "em0"
> >
> > icmp_types="echoreq"
> > set block-policy return
> > set loginterface egress
> >
> > set skip on lo
> > match out on egress inet from !(egress:network) to any nat-to (egress:0)
> > block in log
> > pass out log quick
> > antispoof quick for { lo $int_if }
> >
> > #
> > #   port forwarding
> > #
> > pass in on $ext_if proto tcp from any to any port 80 rdr-to 192.168.1.70
> > port 80
> > pass in on $int_if proto tcp from any to any port 80 rdr-to 192.168.1.70
> > port 80
> > pass in on $ext_if proto tcp from any to any port 6699 rdr-to
> 192.168.1.60
> > port 22
> > pass in on $ext_if proto tcp from any to any port 51413 rdr-to
> > 192.168.1.105 port 51413
> > pass in on $ext_if proto udp from any to any port 51413 rdr-to
> > 192.168.1.105 port 51413
> > pass in on $int_if proto udp from any to any port 58846 rdr-to
> > 192.168.1.101 port 6881
> > pass in on $ext_if proto tcp from any to any port 9000 rdr-to
> 192.168.1.105
> > port 81
> >
> > 
> > #pass in log (all) inet proto icmp all icmp-type $icmp_types
> > pass in log (all) on $int_if

Re: pf and apache

[Matt Morrow]

I'm doing the rdr-to on both interfaces. But, I have other ports that rdr
just fine internally, so that's why I think something else is going on. For
example, I have ssh on 6699 and I can access that both internally and
externally.

On Thu, Feb 28, 2013 at 11:46 PM, Andy Bradford
wrote:

> Thus said Matt Morrow on Thu, 28 Feb 2013 23:07:30 -0600:
>
> > Apache is  running on a slackware  box. I can access  apache just fine
> > internally by using the ip  address of that server (192.168.1.70), but
> > if I  access the ip  of the openbsd box  (192.168.1.60) I just  get an
> > error that the  server is not available. It should  be forwarding port
> > 80 to the slackware box.
>
> I'm going to  guess from your description that you  are trying to rdr-to
> on the same interface. The documentation says:
>
>  Redirections cannot reflect packets  back through the interface
>  they arrive on, they can  only be redirected to hosts connected
>  to different interfaces or to the firewall itself.
>
> The next section discusses using NAT... might be what you're after.
>
> Andy
> --
> TAI64 timestamp: 4000513040c3

Re: Security and ignorance from the major ISPs

[Matt Morrow]

I have to agree on all these points. PF is the absolute best firewall I've
used on any platform. Not only is it the simplest to configure but it has
superior logging facilities.

I'd much rather not have any ISP tell me what traffic I can or cannot
receive. If you do that, say goodbye to open internet access or they'll do
what other unnamed ISPs are currently doing  *ahem*comast*ahem* and tell
you how much data you can use, what mail ports are open - nevermind if you
use any third party mail servers, what times of the day you get more
bandwidth, etc.

Learning how to setup your own security is beneficial for all anyway.

On Thu, Feb 14, 2013 at 7:02 PM, Scott McEachern wrote:

> On 02/14/13 18:20, Daniel Bertrand wrote:
>
>> I was wondering what your stance is about the constant hack attempts on
>> machines on our ISP networks.. I see CONSTANT scanning for ports from all
>> over the world, mostly from Italy, Russia, and China.
>>
>
> Everyone does.  You can find lists of IP ranges on a per-country basis on
> the 'net and block specific countries if you wish. However, unless you're
> running services open to the public (eg. web servers) there isn't much
> point.  (Even if you are, some would argue blocking by country is useless
> anyway.)
>
>  Every firewall/router product that I have purchased has been compromised
>> so far.
>>
>
> Yes, pf on OpenBSD kicks ass.  pf ported to other OSes is always behind
> the times, sometimes way behind.
>
>  Is there really a secure, trustworthy adaptive filtering firewall
>> configuration for each OS configuration out there?
>>
>
> When you're connected to the Internet, it's all about TCP/IP, which is OS
> agnostic.  What matters are the services you want to be accessible.
>
>  Most people who are on the net are completely oblivious and helpless when
>> it comes to this constant trolling for access, they have no idea what to do
>> to secure their machines.
>>
>
> Most (but not all) home routers (DSL modems) filter automatically which
> protects to some degree.  From there, your mileage will vary. But you are
> right that most people don't realize they are under constant attack.  (Try
> "block log all" to get the full picture.)
>
>  Shaw has neglected me and left me for dead when I ask for better control
>> and protection from malicious attackers.
>>
>
> Like Ryan Freeman said on tech, "you want the isp selectively blocking
> traffic for you?  i don't.", you don't want your ISP filtering for you
> because then what you receive is at _their_ discretion, not yours.
>
> Since you referred to Shaw, I take it you're in Canada?  I haven't dealt
> with Shaw, but I once tried Bell for a month or two a few years back and
> they most certainly do port filtering.  For example, I was unable to run my
> own mail server because they blocked port 25/smtp.
>
> Your idea of "left for dead" is actually desirable if you want to control
> your own connection.  I left Bell and switched to Teksavvy because of it.
>  I didn't need Bell "looking out for my best interests", thank-you very
> much.
>
> If you want to discuss this further about your specific setup, please
> contact me privately.
>
>  What do I do to make sure I don't spend money on new hardware but get a
>> PF configuration that I can trust besides "block in all"?
>>
>> Are there published rulesets for Mac/Windows etc. that we can just drop
>> into our pf.conf and /etc/pf.anchors/ directory?
>>
>
> A firewall ruleset is unique to each site.  You're going to have to build
> your own by looking at the pf FAQ (http://www.openbsd.org/faq/**
> pf/index.html ) and looking at
> examples. There is no "one size fits all".  Your question is like asking "I
> need a vehicle.  What should I buy?"  However, like beck@ said on tech,
> "block all" is a good place to start.  After that it depends entirely on
> your _specific_ needs.
>
> --
> Scott McEachern
>
> https://www.blackstaff.ca

Re: new computer

[Matt Morrow]

You do realize the typical life of a battery is about a year? The life of a
battery, when it has reached its expected and standard life does not
reflect the quality of a pc. At any rate, it's not my intention to debate
the quality of a particular brand or OEM. But, I like to defend a product
when misguided information is posted as an absolute or as fact.

On Thu, Jan 10, 2013 at 1:11 AM, K.André Braselmann wrote:

> Buy a refurbished ThinkPad, still better older ThinkPad than
> > shitty plastic Acer/Asus crapbook.
> >
> > jirib
> >
> > I've got 3 pieces of them in the basement. After 1095 days (warranty in
> germany: 3 yrs)
> battery is dead (spare 100€) and the rest will also give up in the next
> half year.
> Seems to be the "El cheapo Canon printer business model". Usually they got
> exactly ONE BIOS update.
> Bought several used ThinkPads and everyone is happy. In Germany about
> 200-300€
>
> André

Re: new computer

[Matt Morrow]

Your comments about asus are strictly personal opinion. I've owned an Asus
laptop for more than a year and it has been rock solid. I've knocked it
onto the floor a couple of times, it has been banged around and it's still
going strong. Also cheaper than a thinkpad.


>
> Buy a refurbished ThinkPad, still better older ThinkPad than
> shitty plastic Acer/Asus crapbook.
>
> jirib

5.2 ospfd and carp

[Matt Hamilton]

Hi All,
  From what I've read previously I've seen that ospfd will advertise
routes on carp interfaces that are in the BACKUP state. Is this
still the case these days with 5.2? Whilst I'm sure I can do some
magic with ifstated, I just wanted to make sure I'm not solving
something that is already fixed.

My use-case is that I have a pair of routers that have many vlan
interfaces shared between them via carp for resilience. These routers
then communicate with the rest of the network via ospf. They use
'redistribute connected' to distribute the subnets on the vlan
interfaces. If an entire router fails then obviously the backup route
is there in OSPF, but if for some reason there is a carp failover for
other reasons and ospfd is still running on the backup router then the
rest of the ospf neighbours don't know to use the route to the backup
carp router (which is now master).

-Matt

Re: pf and torrenting

[Matt Morrow]

*I am trying to get torrenting to work but I can't seem to get any packets
to go through. Tcpdump shows attempted activity and nothing blocked,but the
torrent client itself doesn't seem to be receiving anything from any
torrent I have tried.
The torrent client is using port 58846

>From the pf.conf:
---

ext_if="rl0"




pass in on $ext_if proto tcp from any to any port 58846 rdr-to
192.168.1.101 port 58846*
---

Thanks everyone who responded. I got it working by switching to
transmission.

pf and torrenting

[Matt M.]

I am trying to get torrenting to work but I can't seem to get any 
packets to go through. Tcpdump shows attempted activity and nothing 
blocked,but the torrent client itself doesn't seem to be receiving 
anything from any torrent I have tried.

The torrent client is using port 58846

From the pf.conf:
---

ext_if="rl0"




pass in on $ext_if proto tcp from any to any port 58846 rdr-to 
192.168.1.101 port 58846

Re: openbsd host halted with unknown acpi event

[Matt M.]

On 10/31/2012 11:05 AM, Rares Aioanei wrote:

On Wed, Oct 31, 2012 at 10:28:35AM +0400, Sergey Bronnikov wrote:

Yesterday I have found an unpleasent bug in OpenBSD.

I started two virtual machines in qemu with netbsd and building
source inside each virtual machine.
After about 10 min laptop become overheated just below the keyboard,
Xorg was shutdowned and host halted with following messages on console:

/bsd: acpithinkpad0: unknown event 0x6022
/bsd: acpitz1: critical temperature exceeded 100C (3732K), shutting down

Is described above load critical for openbsd?
What is an event 0x6022? I didn't find such event in dumped acpi tables.


You said that you felt heat just below the keyboard. As a tech, I know 
that overheating can cause all sorts of random errors and will power off 
your machine. Typically if it is strictly heat related, your pc will not 
come back on for at least a couple of minutes, after it has had time to 
cool off, or will power back on immediately and then power right back off.


Open your laptop if you can, clean dust off the fans and vents, and it 
should help. I would also advise to get a laptop cooler - they are only 
a few dollars and help a lot.

Upgrade to 5.2?

[Matt M.]

Yesterday I upgraded from 5.1-release to -current. Is there any need to 
upgrade to 5.2-release? Could this cause issues since -current is really 
newer than what's on the 5.2 media?

OpenBSD upgrade guide 5.2?

[Matt Morrow]

Does anyone know when the upgrade guides are usually posted? I know we're a
couple of weeks away from the release, but I also thought I read that 5.2
cds had already been shipped to some locations, which would imply that it's
pretty much ready for release? I figured I'd take some time to look over it
ahead of time.

OpenBSD 5.1 Raid 10

[Matt Morrow]

I cannot find anything anywhere to indicate whether softraid supports raid
10, and if so, how it is done. Can anyone shed any light? I'm working with
4 disks. I want to stripe the first 2, and mirror on the second set.

Re: PF issues help plz

[Matt Morrow]

Sweet, thanks much! Keep state resolved it.

Thanks again everyone for looking.

On Sat, Oct 13, 2012 at 10:45 AM, mxb  wrote:

>
> You should "keep state", then pkts matching will also pass in/out.
>
> On 13 okt 2012, at 17:19, Matt Morrow  wrote:
>
> pass in quick on $internal
> pass out quick log on $external

Re: PF issues help plz

[Matt Morrow]

Thanks for looking.

/etc/mygate:
   192.168.1.60

/etc/resolv.conf:
 search tx.rr.com
 nameserver 209.18.47.61
 nameserver 209.18.47.62

I have dhcp pushing 8.8.8.8 and 8.8.4.4 to the workstations.
For kicks, I changed dns on the openbsd box to 8.8.8.8 and 8.8.4.4 and no
changes occured in routing. Also, remember, I cannot ping an IP addresses
on the openbsd box either, so something outside of DNS is an issue.

The only reason I didnt upgrade to a later openbsd is because I had raid0
configured, and had a heck of a time getting it working on the newer
released because of the changes with raid in the kernel.

On Sat, Oct 13, 2012 at 10:36 AM, Peter N. M. Hansteen wrote:

> Matt Morrow  writes:
>
> > Ive setup my openbsd box as a router and everything works great except
> for
> > 2 things: the openbsd box itself isn't routing for itself but all
> machines
> > behind it work just fine with dns and routing. At the openbsd box, if I
> try
> > to ping anything by dns, it will sit for about 10 minutes then error that
> > it could not find the host. Pinging any IP will just time out, and
> > connections to my openbsd box (ssh for instance) from any internal
> machine
> > are very slow to make initial connection.
>
> Obviuosly, your name resolution config is incorrect.  The place to start
> would be to study the contents of /etc/resolv.conf on your gateway and
> compare to what the other machines have (if they have better name
> resolution, that is).  The ssh slowness problem is likely related. Your
> sshd is trying to check forward and reverse hostname to IP address
> mapping for hosts that contact it.  IIRC this can be disabled in your
> sshd config, but the better solution is probably to make sure those
> names resolve for your gateway, either by sticking the mappings in the
> gateway's /etc/hosts or actually putting them in your zones or a view,
> whatever fits your setup.
>
> > My configuration is this:
> > OpenBSD 3.8 with two network cards, rl0 (dhcp) connected directly to my
> > cable modem, bce0 (192.168.1.60) connected to a null hub.
>
> OpenBSD 3.8 is seriously old (released November 1st, 2005). It would
> help immensely if you upgrade to a still-supported version. People tend
> to forget the specifics of older releases.
>
> But anyway, I don't think the problem here is PF, more likely you need
> to check your DNS-related settings.  Seeing that you're on a dhcp setup,
> it's eve possible your ISP's name server addresses changed and a simple
> 'dhclient rl0' will give you better resolv.conf content.
>
> - Peter
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

PF issues help plz

[Matt Morrow]

Ive setup my openbsd box as a router and everything works great except for
2 things: the openbsd box itself isn't routing for itself but all machines
behind it work just fine with dns and routing. At the openbsd box, if I try
to ping anything by dns, it will sit for about 10 minutes then error that
it could not find the host. Pinging any IP will just time out, and
connections to my openbsd box (ssh for instance) from any internal machine
are very slow to make initial connection.

My configuration is this:
OpenBSD 3.8 with two network cards, rl0 (dhcp) connected directly to my
cable modem, bce0 (192.168.1.60) connected to a null hub.

Thanks in advance for any assistance.

pf.conf
###
internal="bce0"
external="rl0"

scrub in all

nat on $external from !($external) to any -> ($external:0)

set skip on lo

#
#  Port forwarding
#
rdr on $external proto tcp from any to any port 22 tag SSH -> 192.168.1.60
port 22

no rdr

pass in quick log on $external tagged SSH
pass out quick on $external tagged SSH

###
block in on $external

antispoof log quick for lo0 inet
pass quick on lo0 all
block in quick on $external from any to 255.255.255.255

block log on $external all
block in from no-route to any
block out log quick on $external from ! $external to any
pass out on $external proto tcp from ($external) to any flags S/SA modulate
state queue ( q_defl,q_pri )

pass out on $external proto udp from ($external) to any keep state queue
(q_defl)
pass out on $external inet proto icmp from ($external) to any keep state
pass in quick on $internal
pass out quick log on $external

Re: Make build on powerpc 7455b: Executables are broken

[matt]

On 10/05/12 03:16, Martin Pieuchot wrote:

On 04/10/12(Thu) 22:44, matt wrote:

I assume I or my hardware is doing something stupid and obvious.
I've been trying to successfully build OpenBSD for the first time on
a 2002 G4 (Mirror Drive Door) dual 1ghz. The RAM is new, and
slightly faster than the bus speed demands (pc3200 instead of
pc2700). Processer is a PowerPC 7455B.

I am following the guide for building OpenBSD from source to the
letter (Although a misread is not out of the question!). First I use
cvs to checkout the sources for -CURRENT (Including Xenocara and
Ports, but I've never gotten that far). The kernel builds fine, and
I install it and reboot. On an earlier attempt, I verified it was
installing properly by changing WS_KERNEL_BG.

I am starting from the latest snapshot and sources, and have tried
multiple cvs revisions and gone through two latest snapshots.

Filebin link for the 7.3mb script log of my build attempt is
here:http://filebin.ca/I1aLqmsKata/buildlog

I did use -j4, but the problem is the same without it. The result:

---

install -c -o root -g bin -m 444  /usr/src/bin/md5/sha256.1
/usr/share/man/man1/sha256.1
*** Signal 6 in target maninstall

Stop in /usr/src/bin/md5:
  Received signal 6 (line 71 of ,
  target maninstall: @l=/usr/share/man/man1/cksum.1;
t=/usr/share/man/man1/sum.1;  echo $t -\> $l;  rm -f $t; ln $l $t;)
*** Error code 2 in target realinstall

Stop in /usr/src/bin:
  Exit status 2 (line 48 of , target realinstall)
*** Error code 2 in target realinstall

Stop in /usr/src:
  Exit status 2 (line 48 of , target realinstall)
*** Error code 2 in target build

Stop in /usr/src:
  Exit status 2 (line 85 of Makefile, target build)

---

All executables installed before that give "Abort trap" signal 6
results. The system can barely be used, and once logout occurs, the
system is hosed. No login is possible, nothing can be executed,
single user mode does not work.

It looks like I am somehow getting broken executables and when ln is
called after its installation, it aborts. I assume that line is the
first time an installed executable is called, but I'm not sure why
my executables are aborting.

It's still logged in if anyone has any ideas other than rm -rf /,
which aborts :)

I guess this is related to the fact that you are using macppc snapshots,
they are PIE but not all the share/mk bits are committed until someone
fix PIE for socppc. Until then, stick to the snaps ;)

M.

Thanks. It's good to know it's something special being done to build the 
macppc snaps that's not in CVS and not something with the hardware or 
the operator. Snaps are running great.


Matt

Make build on powerpc 7455b: Executables are broken

[matt]

I assume I or my hardware is doing something stupid and obvious. I've 
been trying to successfully build OpenBSD for the first time on a 2002 
G4 (Mirror Drive Door) dual 1ghz. The RAM is new, and slightly faster 
than the bus speed demands (pc3200 instead of pc2700). Processer is a 
PowerPC 7455B.


I am following the guide for building OpenBSD from source to the letter 
(Although a misread is not out of the question!). First I use cvs to 
checkout the sources for -CURRENT (Including Xenocara and Ports, but 
I've never gotten that far). The kernel builds fine, and I install it 
and reboot. On an earlier attempt, I verified it was installing properly 
by changing WS_KERNEL_BG.


I am starting from the latest snapshot and sources, and have tried 
multiple cvs revisions and gone through two latest snapshots.


Filebin link for the 7.3mb script log of my build attempt is 
here:http://filebin.ca/I1aLqmsKata/buildlog


I did use -j4, but the problem is the same without it. The result:

---

install -c -o root -g bin -m 444  /usr/src/bin/md5/sha256.1 
/usr/share/man/man1/sha256.1

*** Signal 6 in target maninstall

Stop in /usr/src/bin/md5:
 Received signal 6 (line 71 of ,
 target maninstall: @l=/usr/share/man/man1/cksum.1; 
t=/usr/share/man/man1/sum.1;  echo $t -\> $l;  rm -f $t; ln $l $t;)

*** Error code 2 in target realinstall

Stop in /usr/src/bin:
 Exit status 2 (line 48 of , target realinstall)
*** Error code 2 in target realinstall

Stop in /usr/src:
 Exit status 2 (line 48 of , target realinstall)
*** Error code 2 in target build

Stop in /usr/src:
 Exit status 2 (line 85 of Makefile, target build)

---

All executables installed before that give "Abort trap" signal 6 
results. The system can barely be used, and once logout occurs, the 
system is hosed. No login is possible, nothing can be executed, single 
user mode does not work.


It looks like I am somehow getting broken executables and when ln is 
called after its installation, it aborts. I assume that line is the 
first time an installed executable is called, but I'm not sure why my 
executables are aborting.


It's still logged in if anyone has any ideas other than rm -rf /, which 
aborts :)


Matt