Re: No packages found for 7.5 snapshot on arm64

2024-03-09 Thread Jason Tubnor 
Try -D snap

Cheers

Sent from my iPhone

> On 9 Mar 2024, at 6:31 pm, ofthecentury  wrote:
> 
> I had a similar problem this week, for amd64.
> The 'packages/amd64' folder on the OpenBSD
> mirrors for 7.5 snapshot is also empty. So I
> just manually set PKG_PATH to 7.4 packages
> folder for the time being.
> 
>> On Sat, Mar 9, 2024 at 2:15 PM Dmitry Matveyev  wrote:
>> 
>> Hi,
>> 
>> I was running an OpenBSD with this description of the iso: OpenBSD
>> 7.4-current 2023-11-03 (arm64). A week ago I started getting an error
>> trying to install any package:
>> 
>> # pkg_add -Uvi colorls
>> Update candidates: quirks-7.12 -> quirks-7.12
>> Update candidates: updatedb-0p0 -> updatedb-0p0
>> quirks-7.12 signed on 2024-03-05T14:52:30Z
>> Can't install colorls-7.4 because of libraries
>> |library c.99.0 not found
>> | /usr/lib/libc.so.98.0 (system): bad major
>> Couldn't install colorls-7.4
>> 
>> Here I have an older version whereas the package requires a newer
>> version.
>> 
>> I've read that it might be due to using -current and that I need to
>> upgrade my system to the latest snapshot. I have run sysupgrade and now
>> uname says that I'm on OpenBSD 7.5 GENERIC.MP#128 arm64. And now I can't
>> install anything at all because pkg_add complains that it can't find a
>> directory https://ftp.hostserver.de/pub/OpenBSD/7.5/packages/aarch64/. I
>> have checked several mirrors at https://www.openbsd.org/ftp.html and
>> they indeed don't have any packages under 7.5.
>> 
>> How do I fix this?
>> 
>

Re: Panic in 7.2 and snapshots at boot due to acpi bios error

2023-01-23 Thread Jason Tubnor 




From: owner-m...@openbsd.org  on behalf of Jeff Roach 

Sent: Monday, 23 January 2023 9:08 PM
To: misc@openbsd.org 
Subject: Panic in 7.2 and snapshots at boot due to acpi bios error 
 
Hi!  Really love OpenBSD and would like to get it working on my Samsung
Galaxy Book Flex2 Alpha.  NP730QDA-KA3US.  Just offering this up because I
can't send a dmesg.  

I believe it may be a bug in the acpi bios code for which there is no
firmware update.  It boots, linux, win 10/11, net and freebsds fine with
acpi errors.  


We hit this in the Lenovo ThinkStation m70s Gen 3 during hardware validation. A 
workaround was provided and allowed for more data to be sent but the workaround 
was not deemed to be acceptable.

Here is the original bug and thread:

https://marc.info/?l=openbsd-bugs=166674319711567=2

Good to see that it isn't only a Lenovo thing.

Re: after upgrade to 6.9, iked does not pass traffic

2021-05-27 Thread Jason Tubnor 



I have a vpn from a Windows machine to a network behind an OpenBSD router. It 
was working fine until I upgraded the router to 6.9 (amd64).
The VPN is still coming up fine, but the traffic is blocked somehow. Using 
tcpdump on the interface protected by the router (vlan0 in my case), I see the 
ping requests from the remote vpn address, and the ping replies, but on enc0 I 
only see the requests. I confirmed that pf is not blocking packets.

doas tcpdump -nni enc0
tcpdump: listening on enc0, link-type ENC
08:48:05.289341 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 
192.168.9.101: icmp: echo request (encap)
08:48:09.914843 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 
192.168.9.101: icmp: echo request (encap)
08:48:14.914988 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 
192.168.9.101: icmp: echo request (encap)
08:48:19.915348 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 
192.168.9.101: icmp: echo request (encap)
^C
4 packets received by filter
0 packets dropped by kernel

tcpdump -nni vlan0 host 192.168.9.208
tcpdump: listening on vlan0, link-type EN10MB
09:12:21.467671 192.168.9.208 > 192.168.9.101: icmp: echo request
09:12:21.468371 arp who-has 192.168.9.208 tell 192.168.9.101
09:12:21.468386 arp reply 192.168.9.208 is-at ec:eb:b8:5d:94:a0
09:12:21.468937 192.168.9.101 > 192.168.9.208: icmp: echo reply
09:12:21.468961 192.168.9.101 > 192.168.9.208: icmp: echo reply
09:12:26.410587 192.168.9.208 > 192.168.9.101: icmp: echo request
09:12:26.411144 192.168.9.101 > 192.168.9.208: icmp: echo reply
09:12:26.411168 192.168.9.101 > 192.168.9.208: icmp: echo reply
09:12:31.414257 192.168.9.208 > 192.168.9.101: icmp: echo request

It looks like 'keep state (if-bound)' iked.conf(5) is not present or being 
respected on the return traffic to the VPN device/firewall from your internal 
network.  ICMP traffic is coming into the VPN device encrypted, being decrypted 
and passed to the destination.  The destination responds back but the VPN 
device is not taking those responses and pushing them back through enc0.

We have updated a number of IKEv2 devices already without issue.  Our testing 
environment where we are trying out different configurations and scenarios also 
working fine.

Cheers,

Jason.

Re: Redistribution between ospfd and ripd

2020-11-29 Thread Jason Tubnor 
On Sat, 28 Nov 2020 at 11:14, Sebastian Benoit  wrote:

> Hi,
>
>
>
>   route add -label FOOBAR 172.16.1.0/24 172.16.2.5
>   route show -label FOOBAR
>
> I am only aware of these mechanisms to set labels on routes added by
> routing daemons:
>
> bgpd (rtlabel  keyword in filter "set")
> ospfd/ospf6d (rtlabel label external-tag number)
>
> Neither would help in your situation.
>
> Can you explain a bit more what you are planing to do?
>

Thanks for that Benno.  I did see another rtlabel reference in ifconfig(8)
but I don't think that will work as expected either
https://man.openbsd.org/ifconfig#rtlabel

During the migration, there will be OpenBSD routers in the network that
will have some routes coming in from OSPF and RIPv2 so both daemons will be
running on these hosts so network segments can continue to talk to each
other.  In the usual commercial offerings, you simply imply what you want
to redistribute and this can be another routing protocol, static, connected
etc. as the routing stack is aware of other protocols being used.

| OSPF 0.0.0.1 | <-> | OpenBSD Router | <-> | RIPv2 |

Cheers.

Redistribution between ospfd and ripd

2020-11-24 Thread Jason Tubnor 
Hi,

We are planning for migration from ripd to ospf, however both protocols
will need to work together as the migration rolls through.

I was looking at the 'redistribute rtlabel' option, even after digging into
the code, it is unclear how this would work to bring other dynamic routes
on the same host to be redistributed by a different routing protocol.

A valid, but not very clean solution would be to add:

redistribute 10.0.0/8
redistribute 172.16.0/12
redistribute 192.168.0/16

To both ospfd.conf and ripd.conf

What am I missing here or is there a far more elegant way to achieve this?

Thanks,

Jason.

iked(8) bad-ip-version 7 (encap) error after 6.4 upgrade

2018-10-18 Thread Jason Tubnor 
I am preparing a bug report but just wanted to flag an issue that I
discovered after a 6.3 to 6.4 uplift of an iked(8) endpoint.

We overlay vxlan(4) on top of iked(8) to provide seamless connectivity to
site offices.  I have uplifted our test endpoint to 6.4 and discovered that
traffic had tanked, basically 99% of packets were being dropped.
Investigations showed it isn't an iked(8) issue as the P-t-P traffic is
moving as expected and not throwing the error.  As soon as you send traffic
over the unicast vxlan tunnel, that is when you see the error.  Here is a
capture from enc0 on the endpoint:

09:14:42.281342 (authentic,confidential): SPI 0xa093378e: ipcomp
192.168.1.1 > 192.168.1.2 cpi 0x0BCE flags 0 next 4
09:14:42.281396 (authentic,confidential): SPI 0x0bce: 192.168.1.1.4789
> 192.168.1.2.4789: vxlan 35: 10.1.1.1 > 10.1.1.2: icmp: echo request [tos
0x10] (encap)
09:14:42.281430 (unprotected): SPI 0x1a63: 192.168.1.2.4789 >
192.168.1.1.4789: vxlan 35: 10.1.1.2 > 10.1.1.1: icmp: echo reply [tos
0x10] (encap)
09:14:42.281631 (authentic,confidential): SPI 0x03096f78: bad-ip-version 7
(encap)

Any configuration advice would be appreciated if it isn't a bug.  FYI the
main termination device is still 6.3#10

Cheers.

Jason.

Re: SNMP reporting on VXLAN interfaces

2018-08-16 Thread Jason Tubnor 
On Fri, 17 Aug 2018 at 11:48, David Gwynne  wrote:

> On Thu, Aug 16, 2018 at 10:51:25AM +1000, Jason Tubnor wrote:
>
> >
> > Am I missing something here or could it be a potential bug in the VXLAN
> > code in how it reports into snmpd?
>
> The vxlan driver counts something that the network stack does for it
> now. The diff below fixes the problem if you want to try it, but I will
> be committing it soon.
>
>
>

Thanks David.  You got it committed quicker than I could patch it.  I can
confirm that it is now reporting correctly.  Thanks for your help.

Cheers,

Jason.

SNMP reporting on VXLAN interfaces

2018-08-15 Thread Jason Tubnor 
Hi,

Not sure if anyone else here is using SNMP for obtaining VXLAN(4) adapter
throughput but after some testing (clamping with PF queues), I have
discovered that throughput on VXLAN interfaces via SNMP are reporting
exactly double the data throughput than what is measured either through
iperf or pfctl -vvsq .  Regular interfaces on the machine below (vmx) are
reporting correctly.

Am I missing something here or could it be a potential bug in the VXLAN
code in how it reports into snmpd?

Thanks,

Jason.



dmesg

OpenBSD 6.3 (GENERIC.MP) #8: Sat Aug  4 16:56:56 CEST 2018
r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 17163026432 (16367MB)
avail mem = 16635793408 (15865MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 04/14/2014
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3)
S16F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3)
PE50(S3) S1F0(S3) [...]
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 E5-2640 v3 @ 2.60GHz, 2600.19 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
acpitimer0: recalibrated TSC frequency 259020 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 65MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.00 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 4 (application processor)
cpu4: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz
cpu4:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 4, package 0
cpu5 at mainbus0: apid 5 (application processor)
cpu5: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz
cpu5:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 0, core 5, package 0
cpu6 at mainbus0: apid 6 (application processor)
cpu6: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz
cpu6:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu6: 256KB 64b/line 8-way L2 cache
cpu6: smt 0, core 6, package 0
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, 2600.01 MHz
cpu7:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu7: 256KB 64b/line 8-way L2 cache
cpu7: smt 0, core 7, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0 addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpihpet0: recalibrated TSC frequency 255290 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)

Re: Topics for revised PF and networking tutorial

2017-04-10 Thread Jason Tubnor 
On 8 April 2017 at 07:41, Mihai Popescu  wrote:

> I don;t want to offend you folks, but I'm curious and I will ask: is
> this BSDCon so useful? Does it pay the efforts?
>
> If someone has time and knowledge to do a PF tutorial he/she can do it
> and post. Do you need the Con?
>
>
I'm traveling 17000km+ to go to the conference.  This is my second time.
Like other return attendees, tutors and presenters, I get a lot out of
these conferences and the networking (excuse the pun) that comes out of it.

I've been to other conferences like Cisco Live etc, they charge way, way,
way more for the average punter and I don't get anywhere near as much out
of those flashy conferences than I get from BSDCan.  There is nothing quite
like quizzing the minds of advanced users and the developers of the tools
that we so often use in person.  Those conversations are invaluable and
something you just can't get via a mailing list.

Re: OpenBSD 6.1-snapshot boot issues in bhyve

2017-04-05 Thread Jason Tubnor 
On 5 April 2017 at 13:07, Theo de Raadt  wrote:

>
> > cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.87 MHz
> > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
> CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,
> PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16,xTPR,PCID,DCA,
> SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,
> NXE,PAGE1GB,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
> > cpu0: 256KB 64b/line 8-way L2 cache
>
> (see SDBG in the long line above?)
>
> In that case the emulation of that cpu must support the feature it
> claims to support, either by having the hardware do it, or by having
> the vm code emulate it.  It must emulate the MSR's associated with
> the feature.
>
> Or, not make the claim.
>
> bhyve appears to be passing down feature bits from the host cpu
> without sanitizing them.
>
> I wonder what other features they are passing down some of them
> are not really safe
>

Just a follow-up.  New hardware has arrived.  This is not a wide ranging
issue and appears to only affect some models of CPUs.  Below is the output
from a bhyve guest running on an Atom C2758 SoC, no modification was made
to the bhyve startup:

OpenBSD 6.1 (GENERIC.MP) #0: Wed Apr  5 08:47:48 AEST 2017
mrbuil...@cybermen.ar18.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1056964608 (1008MB)
avail mem = 1021227008 (973MB)
warning: no entropy supplied by boot loader
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (10 entries)
bios0: vendor BHYVE version "1.00" date 03/14/2014
bios0: bhyve BHYVE
acpi0 at bios0: rev 2
acpi0: sleep states S5
acpi0: tables DSDT APIC FACP HPET MCFG
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2400.13 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,CX16,xTPR,SSE4
.1,SSE4.2,MOVBE,POPCNT,AES,RDRAND,HV,NXE,LONG,LAHF,3DNOWP,ITSC,ERMS,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 2400132000 Hz
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 134MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2408.75 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,CX16,xTPR,SSE4
.1,SSE4.2,MOVBE,POPCNT,AES,RDRAND,HV,NXE,LONG,LAHF,3DNOWP,ITSC,ERMS,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 0, package 1
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1000 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PC00)
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured
pvbus0 at mainbus0: bhyve
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 unknown vendor 0x1275 product 0x1275 rev 0x00
ahci0 at pci0 dev 4 function 0 "Intel 82801H AHCI" rev 0x00: apic 0 int 16,
AHCI 1.3
ahci0: port 0: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
fixed t10.ATA_BHYVE_SATA_DISK_BHYVE-ABF0-1147-4A70
sd0: 9216MB, 512 bytes/sector, 18874368 sectors, thin
virtio0 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address 00:a0:98:81:81:c6
virtio0: msix shared
pcib0 at pci0 dev 31 function 0 "Intel 82371SB ISA" rev 0x00
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0 mux 1
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
/dev/ksyms: Symbol table not valid.
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (1eb522b194b459a8.a) swap on sd0b dump on sd0b

--

By applying the -w flag for bhyve start on the original machine, 6.1 starts
as expected:

Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.1 (RAMDISK_CD) #19: Sat Apr  1 13:49:18 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 251658240 (240MB)
avail mem = 240402432 (229MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (10 entries)
bios0: vendor BHYVE version "1.00" date 03/14/2014
bios0: bhyve BHYVE
acpi0 at bios0: rev 2
acpi0: tables DSDT APIC FACP HPET MCFG
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot

Re: Topics for revised PF and networking tutorial

2017-04-05 Thread Jason Tubnor 
Without hijacking this thread completely, but touching on some of the
elements discussed above (and I think these are great inclusions for the
tutorial).

We have implemented a variety of queues to manage our internet links and
ikev2 VPNs tunnels to remote offices.  We have also done something similar
for our public wireless like the schedule example above.

I'll be giving an overview of this and other cool stuff provided by OpenBSD
that we use during my BSDCan 2017 talk titled BSD in 60 Days.  Hope to see
you there!

OpenBSD 6.1-snapshot boot issues in bhyve

2017-04-04 Thread Jason Tubnor 
Hi,

Just wondering if anyone else is seeing the same issue I am booting a
6.1-snapshot in bhyve?  In preparation for the 6.1 pending release, I have
tried to spin up 6.1-snap to iron out any issues in bhyve but I don't get
very far into the installation process:



Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.1 (RAMDISK_CD) #19: Sat Apr  1 13:49:18 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 251658240 (240MB)
avail mem = 240402432 (229MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (10 entries)
bios0: vendor BHYVE version "1.00" date 03/14/2014
bios0: bhyve BHYVE
acpi0 at bios0: rev 2
acpi0: tables DSDT APIC FACP HPET MCFG
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.87 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16
,xTPR,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PA
GE1GB,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
rdmsr to register 0xc80 on vcpu 0
 fatal protection fault in supervisor mode
trap type 4 code 0 rip 811c1d17 cs 8 rflags 202 cr2  0 cpl e rsp
81a05940
panic: trap type 4, code=0, pc=811c1d17

The operating system has halted.
Please press any key to reboot.

-

Is anyone able to shed light on this?  I can confirm that 6.0-stable
installed and runs fine as a guest on this host:

-
OpenBSD 6.0 (GENERIC.MP) #2: Wed Oct 12 07:46:27 AEDT 2016
mrbuil...@cybermen.ar18.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2130030592 (2031MB)
avail mem = 2061062144 (1965MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7fb6a000 (10 entries)
bios0: vendor BHYVE version "1.00" date 03/14/2014
acpi0 at bios0: rev 2
acpi0: sleep states S5
acpi0: tables DSDT FACP HPET APIC MCFG SPCR
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 1000 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3491.95 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,FMA3,CX16,xTPR
,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB
,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 134MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, 3499.42 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,FMA3,CX16,xTPR
,PCID,DCA,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB
,LONG,LAHF,ABM,ITSC,FSGSBASE,BMI1,AVX2,BMI2,ERMS,INVPCID,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 0, package 1
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PC00)
"PNP0303" at acpi0 not configured
"PNP0F03" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured
pvbus0 at mainbus0: bhyve
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 unknown vendor 0x1275 product 0x1275 rev 0x00
unknown vendor 0xfb5d product 0x40fb (class display subclass VGA, rev 0x00)
at pci0 dev 2 function 0 not configured
ahci0 at pci0 dev 3 function 0 "Intel 82801H AHCI" rev 0x00: apic 2 int 16,
AHCI 1.3
ahci0: port 0: 6.0Gb/s
scsibus1 at ahci0: 32 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom
removable
ahci1 at pci0 dev 4 function 0 "Intel 82801H AHCI" rev 0x00: apic 2 int 17,
AHCI 1.3
ahci1: port 0: 6.0Gb/s
scsibus2 at ahci1: 32 targets
sd0 at scsibus2 targ 0 lun 0:  SCSI3 0/direct
fixed t10.ATA_BHYVE_SATA_DISK_BHYVE-4AF5-4FB1-76AA
sd0: 9216MB, 512 bytes/sector, 18874368 sectors, thin
virtio0 at pci0 dev 5 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address 00:a0:98:81:81:c6
virtio0: msix shared
virtio1 at pci0 dev 6 function 0 "Qumranet Virtio Network" rev 0x00
vio1 at virtio1: address 00:a0:98:6d:12:d0
virtio1: msix shared
pcib0 at pci0 dev 31 function 0 "Intel 82371SB ISA" rev 0x00
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5

Typo error in OpenBSD 6.0 Errata 6 patch file

2016-09-17 Thread Jason Tubnor 
Hi,

Just picked up a typo in in the
http://ftp.openbsd.org/pub/OpenBSD/patches/6.0/common/006_iked.patch.sig
errata file.  While there is a patch below, it will need to be re-issued
with an updated signify signature.

Cheers!


--- 006_iked.patch.sig.orig Sun Sep 18 12:05:38 2016
+++ 006_iked.patch.sig  Sun Sep 18 12:05:56 2016
@@ -7,7 +7,7 @@ During parsing of the iked(8) configuration, a variabl
 mistake, disabling Pre-Shared key authentication.

 Apply by doing:
-signify -Vep /etc/signify/openbsd-60-base.pub -x 005_iked.patch.sig \
+signify -Vep /etc/signify/openbsd-60-base.pub -x 006_iked.patch.sig \
 -m - | (cd /usr/src && patch -p0)

 And then rebuild and install iked:

Re: Anyone experienced with 4G/LTE modems?

2015-11-03 Thread Jason Tubnor 
On 4 November 2015 at 07:31, Alan Corey  wrote:

> Anybody have good experiences with any of the currently available
> 4G/LTE modems that start around $30 on eBay, mostly by Huawei?  I
> won't have a real internet connection for at least a year.  Right now
>

You might want to see if the chipset you are looking at lines up with
support under the umsm(4) device [ see
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/umsm.4?query=umsm=4
].  Personally I don't have any of these (I tether to my HTC One when I
need internet on the go) but I have heard that everything works as intended
with supported devices.  At $30, I don't think it is much of a risk to give
it a shot, much cheaper to burn out than phones.

Cheers,

Jason.

Re: queueing example on pf.conf man page

2015-11-03 Thread Jason Tubnor 
On 4 November 2015 at 13:09, Glenn Faustino 
wrote:


> I notice that under queueing section of the pf.conf man page the total
> child queues bandwidth exceed what's defined in the parent. rootq was
> defined with 100M bandwidth and the child queues defined http 60M, mail
> 10M, ssh 20M and std 20M.
>
>
> Can the bandwidth on the child queues exceed what's defined in the parent?
>

While pf(4) will let you define and load queues that exceed the parent (top
level) queue, when you start to load up your queues, you'll get congestion
defeating the purpose of queuing.  To what point, depends on your
environment.

Maybe the pf.conf(5) man page needs to be adjusted to reflect the statement
below and set the std queue to 10M (but that is up to the project to
decide):

"All bandwidth values must be specified as an absolute value.  The
suffixes K, M, and G are used to represent bits, kilobits, megabits, and
gigabits per second, respectively.  The value must not exceed the
interface bandwidth."

Cheers.

Re: ipsec via iked

2015-11-02 Thread Jason Tubnor 
On 3 November 2015 at 03:14, Sébastien Morand  wrote:

> Hi,
>
> I set up an ipsec VPN via iked.
>
>
>
> The point is that the server has to know my home network (192.168.100.0/24
> ).
> How to make it works wherever my laptop is?
>
> I tried with config address options but can't make it work.
>

While not an endorsed FAQ or man page from the project, this:
http://puffysecurity.com/wiki/openikedoffshore.html should give you a few
tips on how to achieve this.  The man page (iked.conf) and the references
for pf within it should be enough to work it out.  But from my observations
of your ikev2 configs, you are making it a little more complex than it
needs to.

Cheers.

Re: iked & nat-t problem (no keep alive)

2015-11-02 Thread Jason Tubnor 
On 19 October 2015 at 21:49, igyht  wrote:

> I am testing iked on OpenBSD phobos 5.7 GENERIC#738 i386, I think there is
> keep-alive problem when use with NAT-T,
> detailed configurations are:
>
>
>
> http://daemonforums.org/showthread.php?t=9446
>
>
>
> I think, iked & nat-t need some kind of "keep alive", but I can't find it
> in
> iked.conf configuration. Any idea?
>
>
>
Keep alive is not really the best way to do it and from memory, the RFC
states it shouldn't be done (though I think the NAT-T RFC stated it could,
but might be getting a whole lot of them mixed up).

To keep your link alive, it is easier to be done at the firewall level.
Depending on your firewall or NAT device you can configure to use what is
known as 'static-port'.  Good firewalls like PF use upper port
ransomisation for NAT connections, as you have found out, the state expires
and when you try to send data again, the firewall sets up a new UDP 4500
link but return responses will be back to the original client port, not the
new one that is setup - thus dropped packets and you need to re-initialise
the link.  The RFC states that the client (active) is not allowed to send
the server (passive) the new return port to prevent DDoS occurring on the
server.

The best way I have found to solve this problem is configuring a match rule
specifically for NAT outbound to remote [any] 4500 static-port (see man 5
pf.conf), leaving good port ransomisation in place for all other traffic.
Seems the network admins leave static-port matching on on Cisco routers so
I haven't had any issues when connecting through these.

Cheers,

Jason.

-- 
"If my calculations are correct, when this baby hits 88MPH, you're gonna to
see some serious shit" - Emmett "Doc" Brown

PF Queuing of NAT-T IKEv2 ESP Traffic

2015-11-02 Thread Jason Tubnor 
Hi All,

Can anyone verify (based on my diagram below) if they have had success with
queuing IKEv2 return traffic from the "Server".  I have been able to use
IKEv2 based tagging and doing it (as described in iked.conf(5)) when NAT-T
isn't used and when traffic is 'pass out' from the IKEv2 "Client", but
never for NAT-T connections from the "Server".  Looking at tcpdumps of the
$ext_if on the "Server", there is never any independent egress ESP traffic
from the "Server", it all passes over the original "pass in" connection to
the server on port 4500, back to the "Client" via the "NAT GW".

As enc(4) is not queue-able, using tagging and queuing of ESP flows is the
best option (as excellently documented in iked.conf(5)) but in a NAT-T
setup, the ESP flows are 'udpencap' into the NAT-T transport and the
individual flows don't actually touch the external interface.

For road worriers, this probably isn't a problem but in my case I need to
be able to use tagging of the IKEv2 flows to budget traffic and ensure QoS
of certain network traffic.

Controlling at the network entry points is not an option as I have no
control over the network gear (3rd party management by the ISP).

Am I doing it wrong? Is this something that wasn't thought of in the
OpenIKED implementation? Or is queuing coming to enc(4) real soon?


+---++-+pppoe0
 +--+
|Client ||NAT GW   |130.40.2.3| IKEv2
Server |
| 192.168.1.101 | -> | 192.168.1.1 | > Internet > |
10.0.1.1/8 | --> Big Internal
+---++-+
 202.140.3.50+--+ Network /8
   em0

Thanks in advance,

Jason.

Re: IKED and encapsulated peers

2015-10-05 Thread Jason Tubnor 
On 5 October 2015 at 22:00, Jason Tubnor <ja...@tubnor.net> wrote:

>
> Solved!
>
>
> I have attached a man 5 iked.conf patch that clears up an example used in
> the man page.
>

The gz diff was stripped by demime, here is the flat text patch file.

Cheers,

Jason.

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of iked.conf.5.patch]

Re: IKED and encapsulated peers

2015-10-05 Thread Jason Tubnor 
On 3 October 2015 at 14:40, Jason Tubnor <ja...@tubnor.net> wrote:

> Hi,
>
> Based on man 5 iked.conf the following should setup technically 4 flows
> (reversing and setting active on the corresponding peer):
>
>
>
Solved!

Main gateway:

# cat /etc/iked.conf
ikev2 esp from 192.168.232.128 to 192.168.232.129 \
from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.129 psk
"HelloWorld"

# ipsecctl -sa
FLOWS:
flow esp in from 192.168.232.129 to 192.168.232.128 peer 192.168.232.129
srcid FQDN/hovpn.local dstid FQDN/rovpn.local type use
flow esp out from 192.168.232.128 to 192.168.232.129 peer 192.168.232.129
srcid FQDN/hovpn.local dstid FQDN/rovpn.local type require
flow esp in from 192.168.72.0/24 to 192.168.1.0/24 peer 192.168.232.129
srcid FQDN/hovpn.local dstid FQDN/rovpn.local type use
flow esp out from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.129
srcid FQDN/hovpn.local dstid FQDN/rovpn.local type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0x01d084c7 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0xf055afa1 auth
hmac-sha2-256 enc aes-256



Remote gateway (that initiates connection):

# cat /etc/iked.conf
ikev2 active esp from 192.168.232.129 to 192.168.232.128 \
from 192.168.72.0/24 to 192.168.1.0/24 peer 192.168.232.128 psk
"HelloWorld"

# ipsecctl -sa
FLOWS:
flow esp in from 192.168.232.128 to 192.168.232.129 peer 192.168.232.128
srcid FQDN/rovpn.local dstid FQDN/hovpn.local type use
flow esp out from 192.168.232.129 to 192.168.232.128 peer 192.168.232.128
srcid FQDN/rovpn.local dstid FQDN/hovpn.local type require
flow esp in from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.128
srcid FQDN/rovpn.local dstid FQDN/hovpn.local type use
flow esp out from 192.168.72.0/24 to 192.168.1.0/24 peer 192.168.232.128
srcid FQDN/rovpn.local dstid FQDN/hovpn.local type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0x01d084c7 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0xf055afa1 auth
hmac-sha2-256 enc aes-256

--

I have attached a man 5 iked.conf patch that clears up an example used in
the man page.


Cheers,

Jason.

[demime 1.01d removed an attachment of type application/x-gzip which had a name 
of iked.conf.5.patch.gz]

Re: IKED and encapsulated peers

2015-10-04 Thread Jason Tubnor 
On 3 October 2015 at 14:40, Jason Tubnor <ja...@tubnor.net> wrote:

> Hi,
>
>
> Here is the ipsecctl flows:
>
>
>
Sorry, I copied in the flows from the wrong server (testing all different
ways trying to get things to work).  Here is the ipsecctl to match the
iked.conf listed:

# ipsecctl -sa
FLOWS:
flow esp in from 192.168.72.0/24 to 192.168.1.0/24 peer 192.168.232.129
srcid FQDN/hovpn.local dstid FQDN/rovpn.local type use
flow esp out from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.129
srcid FQDN/hovpn.local dstid FQDN/rovpn.local type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0x1d3ef308 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0x22b8b189 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0xb8b060e1 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0xbda3e596 auth
hmac-sha2-256 enc aes-256

Cheers,

Jason

IKED and encapsulated peers

2015-10-02 Thread Jason Tubnor 
Hi,

Based on man 5 iked.conf the following should setup technically 4 flows
(reversing and setting active on the corresponding peer):

/etc/iked.conf

ikev2 esp from 192.168.232.128 to 192.168.232.129 psk "HelloWorld"
ikev2 esp from 192.168.1.0/24 to 192.168.72.0/24 peer 192.168.232.129 psk
"HelloWorld"

The site to site flow (2nd rule) works as intended over the encapsulated
interface. However, the 1st rule will not encapsulate the ICMP traffic when
pinging from the opposite peer (peer 192.168.232.129 used below):

# ping 192.168.232.128
PING 192.168.232.128 (192.168.232.128): 56 data bytes
Oct 03 14:21:13.493860 rule 3/(match) block in on em0: 192.168.232.128 >
192.168.232.129: icmp: echo reply

Here is the ipsecctl flows:

# ipsecctl -sa
FLOWS:
flow esp in from 192.168.72.0/24 to 192.168.111.0/24 peer 192.168.232.129
srcid FQDN/hovpn.local dstid FQDN/rovpn.local type use
flow esp out from 192.168.111.0/24 to 192.168.72.0/24 peer 192.168.232.129
srcid FQDN/hovpn.local dstid FQDN/rovpn.local type require
flow esp out from ::/0 to ::/0 type deny

SAD:
esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0x09a48897 auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.232.128 to 192.168.232.129 spi 0x55ef5dfe auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0x99bd11bb auth
hmac-sha2-256 enc aes-256
esp tunnel from 192.168.232.129 to 192.168.232.128 spi 0xf5e4357a auth
hmac-sha2-256 enc aes-256

*Note:  If I don't have the 1st IKED rule, then the SAD looks correct (only
2 lines, not 4 and still works for the above FLOWS).

I'm sort at a loss with this.  Now I don't mind if those 192.168.232.x
interfaces are encapsulated at the end of the day as all critical traffic
will go over the internal network flows, though for monitoring, I'd rather
end point gateway tests to remain encapsulated.  Any pointers on where to
look will be greatly appreciated, I've been through the man pages and mail
lists many times trying to work out where I am potentially going wrong.

Thanks in advance.

Jason.

dmesg

OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar  8 11:04:17 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 520028160 (495MB)
avail mem = 502321152 (479MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (364 entries)
bios0: vendor Phoenix Technologies LTD version "6.00" date 07/31/2013
bios0: VMware, Inc. VMware Virtual Platform
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET
acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S3F0(S3)
S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F0(S3) S9F0(S3) S10F(S3) S11F(S3)
S12F(S3) S13F(S3) [...]
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) Core(TM) i7-3630QM CPU @ 2.40GHz, 2394.21 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 65MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2393.62 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0 addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpibat0 at acpi0: BAT1 not present
acpibat1 at acpi0: BAT2 not present
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: LID_
vmt0 at mainbus0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01
ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08
pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel
0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus
disabled
"VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured
vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00

Re: spamd pf rules

2015-06-11 Thread Jason Tubnor 
As Okan stated, your 5.6 man page is still correct for 5.7.  It is
only of issue when you move to 5.8-Release in November.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/pf.conf.5?query=pf%2econf
- -current and 5.8, use/will use divert-to

(Can't give you a link to the online pf.conf man page for 5.7 as it
hasn't been snapped for 5.7-release) My man pages on my 5.7 hosts
specify rdr-to

Cheers,

Jason.


On 11 June 2015 at 11:51, Edgar Pettijohn III ed...@pettijohn-web.com wrote:
 On Jun 10, 2015, at 3:59 PM, Okan Demirmen wrote:

 On Wed 2015.06.10 at 15:43 -0500, Edgar Pettijohn III wrote:
 I've been using spamd for a while now.  I was looking through my pf.conf 
 and noticed that I had the following rules in regards to spamd.

 table spamd-white persist
 table nospamd persist file /etc/mail/nospamd
 pass in log on egress proto tcp from any to any port smtp \
 rdr-to 127.0.0.1 port spamd
 pass in on egress proto tcp from nospamd to any port smtp
 pass in on egress proto tcp from spamd-white to any port smtp
 pass out log on egress proto tcp to any port smtp

 Everything seems to work correctly, but I was thinking the rdr-to rule was 
 wrong so I looked at spamd(8) and it shows a divert-to rule instead.  When 
 I change it to divert-to I get the following error:

 # pfctl -vf /etc/pf.conf

 /etc/pf.conf:19: address family mismatch for divert
 pfctl: Syntax error in config file: pf rules not loaded

 What should I do to fix this.  Is the rdr-to rule sufficient or do I need 
 to change it?

 Depends. 5.7 and prior used rdr-to; and -current switched to divert-to.

 http://www.openbsd.org/faq/current.html#20150518

 Thanks

 I guess I missed that line.  However, I think my system is out of whack.  I 
 upgraded to 5.7, but the spamd man page is from 5.6.  Thanks for the lead.

 Edgar





-- 
If my calculations are correct, when this baby hits 88MPH, you're
gonna to see some serious shit - Emmett Doc Brown

Re: vnconfig crypto alternative

2014-11-25 Thread Jason Tubnor 
On 25 November 2014 at 18:58, David Vasek va...@fido.cz wrote:


 did not look neither efficient, nor healthy. Try dd if=/dev/zero
 of=/dev/rsd1c bs=1m while watching systat/iostat at the same time. Is it
 still the case?

So here are the findings.  The test is virtualised but below is the
baseline into a vnd container (no crypt etc) GENERIC 5.6-current
amd64:

# dd if=/dev/zero of=/dev/rvnd0a bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 41.652 secs (25174524 bytes/sec)

The results for vnd container using crypt (noticed ~20% cpu utilisation):

# dd if=/dev/zero of=/dev/rvnd0a bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 59.270 secs (17691307 bytes/sec)

Crypto softraid inside a vnd container (noticed ~8% cpu utilisation):

# dd if=/dev/zero of=/dev/rsd2a bs=1m count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 87.422 secs (11994340 bytes/sec)

I'll continue using vnd crypt container based on advice from theo@ .
Performance is not a real issue for this small amount of data that is
not accessed often in my use case so I wasn't too concerned either
way, just wanted to make sure I was on a valid supported path.

vnconfig crypto alternative

2014-11-24 Thread Jason Tubnor 
With crypto being deprecated (and possibly removed in future versions
- depending on dev direction) from vnconfig, would the following be
assumed one way of providing an encrypted container?

To create 200MB encrypted container:

sudo dd if=/dev/zero of=/var/encrypt/container.encrypt bs=1m count=200
sudo chmod 600 /var/encrypt/container.encrypt
sudo vnconfig vnd0 /var/encrypt/container.encrypt
printf a\n\n\n\nRAID\nw\nq\n\n | sudo disklabel -E vnd0
sudo bioctl -c C -l vnd0a softraid0
## Enter your secret passphrase here
sudo dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
printf a\n\n\n\n4.2BSD\nw\nq\n\n | sudo disklabel -E sd1
sudo newfs /dev/rsd1a
sudo mount /dev/sd1a /encrypt
##
sudo umount /encrypt
sudo bioctl -d sd1
sudo vnconfig -u vnd0


Then to re-use:

sudo vnconfig vnd0 /var/encrypt/container.encrypt
sudo bioctl -c C -l vnd0a softraid0
## Enter your secret passphrase here
sudo mount /dev/sd1a /encrypt
##
sudo umount /encrypt
sudo bioctl -d sd1
sudo vnconfig -u vnd0

rc.conf issue on upgrade from 5.5 to 5.6

2014-10-09 Thread Jason Tubnor 
Hi,

I was just testing upgrades prior to the 5.6 release and noticed items
in the rc.conf.local were being ignored.  A bit of digging, I noticed,
rc.subr had some changes and more importantly there were quite a few
changes to rc.conf.

Cutting to the chase, replacing rc.conf from the upgraded 5.5 machine
with the 5.6_BASE fixed the issue and items were being picked up in
the rc.conf.local again.

Just thought I would point it out as rc.conf isn't replaced when using
the upgrade feature in the 5.6 release.

Cheers,

Jason.

Re: ifconfig command for IPv6 tunnel

2014-08-20 Thread Jason Tubnor 
Forgot to reply-all yesterday (only sent to Charles) to keep the
thread in-sync with the rest of the conversation (don't nuke me for
stating the obvious + added the rtadvd/route6d)

On 20 August 2014 13:40, Charles Musser cmus...@sonic.net wrote:

 ifconfig gif0 tunnel 50.1.94.112 72.52.104.74
 ifconfig gif0 inet6 alias 2001:470:1f04:204::2 2001:470:1f04:204::1 prefixlen 
 128
 route -n add -inet6 default 2001:470:1f04:204::1


Spot on there Chuck.  That is how I have mine set up.

Don't forget to change in your /etc/sysctl.conf file:

net.inet6.icmp6.rediraccept=1   # 1=Accept IPv6 ICMP redirects (for hosts)
net.inet6.ip6.forwarding=1  # 1=Permit forwarding (routing) of IPv6 packets

(note the removal of the comment #)

You will also need to tweek your /etc/pf.conf rule set.  Here is a
rough guide, mileage may vary:

icmp6_types={ unreach, timex, paramprob, echoreq, routeradv,
routersol, neighbradv, neighbrsol }   # Only want these ICMP6 types

block return# default that probably exists in your environment -
nothing to come in unless explicitly defined below (IPv4 and IPv6)

pass out on gif0 inet6# Allow for all ICMP6 traffic
out - you may not want to do this but whatever works for you
pass inet6 proto icmp6 icmp6-type $icmp6_types  # Allow
ICMP6 of types defined above to move in and out freely
pass on vmx0 inet6# Allowing traffic in and out of internal network.



Then you'll need to setup the rtadvd daemon to hand out your /64 to
your internal clients (/etc/rtadvd.conf):

default:\
   :rdnss=ipv6 of your internal DNS server or server
that you use:\
   :dnssl=search domain:

vmx0:\  #  This is my internal interface, yours may be different
   :addr=your /64 subnet prefix:::prefixlen#64:tc=default:


Now enable all that to serve your internal clients (/etc/rc.conf.local):

rtadvd_flags=vmx0
route6d_flags=

That should be about it.

-- 
Roads?  Where we're going, we don't need roads - Emmett Doc Brown

Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src

2014-08-17 Thread Jason Tubnor 
On 2 June 2014 10:23, Ted Unangst t...@tedunangst.com wrote:


 Part of the deprecation / migration process is identifying the weird
 ways people use vnd and finding solutions for them. But as we've seen,
 people never move forward without the occasional push.


So the most appropriate way to use vnd(4) as an encrypted container
going forward would be to lay down softraid(4) CRYPTO inside it to
achieve a like-for-like outcome or would this be over-complicating
things?  I have had success in testing this use case but I am aware it
may not be supported.

Re: Has any one had any problem with install50.iso?

2011-11-03 Thread Jason Tubnor 
Hi Johan,

Have you checked the SHA256 sig with the iso?  They can be found here:
http://ftp.openbsd.org/pub/OpenBSD/5.0/arch/SHA256

If you don't have an OpenBSD installation already running to use the sha256
command, you can pick up tools over on sourceforge
http://md5deep.sourceforge.net/ that can help you out with whatever
platform you are running.

Cheers,

Jason.

-- 
Roads?  Where we're going, we don't need roads - Dr. Emmett Doc Brown