Re: OpenBSD 6.1 on Azure

[Brian B]

Better with new lines...

OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 15015542784 (14319MB)
avail mem = 14555783168 (13881MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf8ec0 (216 entries)
bios0: vendor American Megatrends Inc. version "090006" date 05/23/2012
bios0: Microsoft Corporation Virtual Machine
acpi0 at bios0: rev 0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihve0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz, 1394.93 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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,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 110MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz, 1450.45 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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS
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-2673 v3 @ 2.40GHz, 3312.18 MHz
cpu2:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS
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-2673 v3 @ 2.40GHz, 3032.74 MHz
cpu3:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS
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-2673 v3 @ 2.40GHz, 3032.73 MHz
cpu4:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS
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-2673 v3 @ 2.40GHz, 3032.75 MHz
cpu5:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS
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-2673 v3 @ 2.40GHz, 3032.74 MHz
cpu6:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS
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-2673 v3 @ 2.40GHz, 3428.32 MHz
cpu7:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS
cpu7: 256KB 64b/line 8-way L2 cache
cpu7: smt 0, core 7, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
acpicpu4 at acpi0: C1(@1 halt!)
acpicpu5 at acpi0: C1(@1 halt!)
acpicpu6 at acpi0: C1(@1 halt!)
acpicpu7 at acpi0: C1(@1 halt!)
"PNP0303" at acpi0 not configured
"PNP0F03" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0700" at acpi0 not configured
"VMBus" at acpi0 not configured
"Hyper_V_Gen_Counter_V1" at acpi0 not configured
pvbus0 at mainbus0: Hyper-V 6.3
hyperv0 at pvbus0: protocol 3.0, features 0xe7f
hyperv0: heartbeat, kvp, shutdown, timesync
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82443BX" rev 

OpenBSD 6.1 on Azure

[Brian B]

Wanted to share the dmesg of an Azure VM running OpenBSD 6.1.  Great job guys!
Special shout out to Mike Belopuhov for the Hyper-V and Xen work.

OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem
= 15015542784 (14319MB) avail mem = 14555783168 (13881MB) mpath0 at root
scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS
rev. 2.3 @ 0xf8ec0 (216 entries) bios0: vendor American Megatrends Inc.
version "090006" date 05/23/2012 bios0: Microsoft Corporation Virtual Machine
acpi0 at bios0: rev 0 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP WAET
SLIC OEM0 SRAT APIC OEMB acpi0: wakeup devices acpitimer0 at acpi0: 3579545
Hz, 32 bits acpihve0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2673
v3 @ 2.40GHz, 1394.93 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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,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 110MHz cpu1 at mainbus0: apid 1 (application processor) cpu1:
Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz, 1450.45 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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS 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-2673 v3 @ 2.40GHz, 3312.18 MHz cpu2:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS 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-2673 v3 @ 2.40GHz, 3032.74 MHz cpu3:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS 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-2673 v3 @ 2.40GHz, 3032.73 MHz cpu4:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS 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-2673 v3 @ 2.40GHz, 3032.75 MHz cpu5:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS 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-2673 v3 @ 2.40GHz, 3032.74 MHz cpu6:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS 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-2673 v3 @ 2.40GHz, 3428.32 MHz cpu7:
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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,PO
PCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,B
MI2,ERMS cpu7: 256KB 64b/line 8-way L2 cache cpu7: smt 0, core 7, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpiprt0 at
acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1
halt!) acpicpu2 at acpi0: C1(@1 halt!) acpicpu3 at acpi0: C1(@1 halt!)
acpicpu4 at acpi0: C1(@1 halt!) acpicpu5 at acpi0: C1(@1 halt!) acpicpu6 at
acpi0: C1(@1 halt!) acpicpu7 at acpi0: C1(@1 halt!) "PNP0303" at acpi0 not
configured "PNP0F03" at acpi0 not configured "PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured "PNP0700" at acpi0 not configured "VMBus" at
acpi0 not configured "Hyper_V_Gen_Counter_V1" at acpi0 not configured pvbus0
at mainbus0: Hyper-V 6.3 hyperv0 at pvbus0: protocol 3.0, features 0xe7f

Re: OpenBSD 6.1 - bravo

[Mikael]

Also from me, big thanks!

2017-04-12 16:45 GMT+08:00 Clément.J :

> Thank you OpenBSD team for this new release 6.1
> OpenBSD makes me happy every day for so many usages
> so thank you so much everyone for your great work.


2017-04-12 16:45 GMT+08:00 Clément.J :

> Thank you OpenBSD team for this new release 6.1
> OpenBSD makes me happy every day for so many usages
> so thank you so much everyone for your great work.
>
> have a good day
> vive OpenBSD
>
>
> Le 12-04-2017 10:27, Stuart Henderson a écrit :
>
>> On 2017-04-12, Jordon  wrote:
>>
>>> rcctl enable dhcrelay
 rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is
 your routers

>>> address"
>>>
 rcctl start dhcrelay

 and possibly add -d (log to stderr) to see what its doing.


>>> Thank you!  That got it working!  So why is that necessary?  Doesnt
>>> the bridge
>>> just forward everything?  Or are DHCP requests broadcasts that dont
>>> get
>>> forwarded?
>>>
>>
>> It shouldn't be necessary, dhcrelay is normally used when you have a
>> subnet behind a router, and the DHCP server is a separate machine on
>> a
>> different subnet.
>>
>> Could it be a PF rule problem?
>>
>> Normally you would only have an IP address on one member of the
>> bridge,
>> just "up" on the others..

Re: Are mips64 or sparc64 packages for 6.1 released yet?

[Theo de Raadt]

> I'm missing packages for mips64 (for EdgeRouter Lite/ octeon ) or
> sparc64 on official places:

mips64le packages are not built.

There is no hardware, no build cluster, no pkg builder to do it.

BTW, a pkg builder is a real person who cares enough to observe and
control this during the entire 6-month-cycle for the snapshots, so
that release packages are great.  Speaking of other architectures you
probably also use, have you thanked your the pkg builder for the
architectures you care about recently?

I am going to toot their horn a little.

These are the people who build the packages:

alpha   phess...@openbsd.org
amd64   na...@openbsd.org
arm phess...@openbsd.org
hppapiro...@openbsd.org
i386st...@openbsd.org
mips64  v...@openbsd.org
mips64elp...@openbsd.org
powerpc lan...@openbsd.org
sparc64 lan...@openbsd.org

> I can see only amd64, arm, hppa, i386. 

Now that we don't do CDs anymore, the release process is expedited
with less "time shear" pressure on the build group.

The ones you see are the first architectures to finish build.  As each
other architecture finishes, their packages will be signed and arrive
on the mirrors automatically.
 
> For the time being I might get lucky with pkg_add -Dsnap, but I remember
> that base+packages need to match ...

That will probably work.  The ABI didn't change much in the 4 weeks
before release.

Re: Are mips64 or sparc64 packages for 6.1 released yet?

[Theo de Raadt]

> On 12 April 2017 at 12:01, Jan Vlach  wrote:
> > Is this intentional? (Long build times, lack of time ...) Is there a
> > rough guesstimate when things migt be available?
> 
> Have octeon packages ever been built?
> 
> I'm very thankful for the rather regular octeon images. Those must
> take a couple days to build, and we're fortunate to get them once or
> more a week! What a treat! Thank you for this!

A mips64le ports cluster has never been built.

Free firmware for AR9285

[thinkpad-e535-user]

I'm wondering why does Atheros AR9285 need binary firmware on OpenBSD?
According to this wikipedia article [1] it works on Linux and FreeBSD
with some free firmware. Is that in theory possible for OpenBSD to use
it too?

[1] https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers

Re: Are mips64 or sparc64 packages for 6.1 released yet?

[jungle Boogie]

On 12 April 2017 at 12:01, Jan Vlach  wrote:
> Is this intentional? (Long build times, lack of time ...) Is there a
> rough guesstimate when things migt be available?

Have octeon packages ever been built?

I'm very thankful for the rather regular octeon images. Those must
take a couple days to build, and we're fortunate to get them once or
more a week! What a treat! Thank you for this!


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info

Re: ftpsesame package

[Stuart Henderson]

On 2017-04-12, Todd C. Miller  wrote:
> On Wed, 12 Apr 2017 21:27:49 +0200, Olivier Regnier wrote:
>
>> "ftpsesame chroots to "/var/empty" and changes to user "proxy" to drop 
>> privileges. It does keep a file descriptor to both bpf 
>> (4) and pf 
>> (4) so it is 
>> still very powerful."
>
> The "proxy" user was removed, that is almost certainly the problem.
> The port needs a patch to use "_ftp_proxy" instead.

Simplest quick workaround is to re-add the proxy user though. Run
vipw and add this:

proxy:*:71:71::0:0:Proxy Services:/nonexistent:/sbin/nologin

And add to /etc/group:

proxy:*:71:

installing Graphite on OpenBSD 6.0

[Alceu R. de Freitas Jr.]

Hello there,
I was struggling yesterday to try to setup Collectd with Graphite on a OpenBSD 
6.0 running over Virtualbox but couldn't complete the Graphite part of it.
It seems Graphite is not entirely available to OpenBSD (package or ports): I 
was able to find and use ports for Carbon, but that's half the way (it is 
missing the Graphite-web).
I couldn't find documentation about this process for OpenBSD specific (although 
I hit some for FreeBSD and NetBSD).
As an alternative, I check Facett as a frontend, but couldn't find a package or 
ports for it (although there is indeed a distfile for it, so I'm not sure why 
there isn't anything on ports tarball).

All consider, is anybody aware if it is possible to finish the setup, maybe 
using virtualenv to install Graphite-web?
I'm open to other suggestions as well... for this specific project, I'm trying 
setup everything in the same box because well... it is suppose to be a single 
box indeed: https://github.com/glasswalk3r/cpan-openbsd-smoker. I even tried to 
use the Perl CGI available with Collectd, but they are essentially broken 
(generate charts from RRDTool with "garbage" instead of readable characters, 
lot's of warnings about CGI on Perl being deprecated).
Thanks!
Alceu

Re: dmesg for Lenovo ThinkPad x200 w/coreboot

[thinkpad-e535-user]

I've done it too, without FDE for now. My x200 feels good with coreboot
and OpenBSD, there are no random lockups that Scott mentioned.

>Thanks Scott, I've followed your instructions and everything seems to be
>working well on my x200. I'll let you know if I experience the period
>locking you mentioned. We both get this error:
>error: [drm:pid0:intel_pipe_config_compare] *ERROR* mismatch in
>adjusted_mode.flags(DRM_MODE_FLAG_PHSYNC) (expected 0, found 1)
>pipe state doesn't match!
Also I don't have this error, but I have another! Would be nice if
someone told me how to fix it, though I cannot even find what's broken,
if anything.
dmesg follows.

OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2092134400 (1995MB)
avail mem = 2024112128 (1930MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7db38020 (8 entries)
bios0: vendor coreboot version "CBET4000 4.5-1370-g3f111b0" date 03/22/2017
bios0: LENOVO 745584G
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT MCFG TCPA APIC DMAR HPET
acpi0: wakeup devices HDEF(S4) USB1(S4) USB2(S4) USB3(S4) EHC1(S4) USB4(S4) 
USB5(S4) USB6(S4) EHC2(S4) SLT1(S4) SLT2(S4) SLT3(S4) SLT6(S4) LANC(S3) 
LANR(S3) SLPB(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 1600.30 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 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 266MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 1600.06 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEGP)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus 3 (RP03)
acpiprt5 at acpi0: bus 4 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus 5 (PCIB)
acpiec0 at acpi0
acpicpu0 at acpi0
C1: bogo buffer
C2: bogo buffer
C3: bogo buffer: C1(@1 halt!), PSS
acpicpu1 at acpi0
C1: bogo buffer
C2: bogo buffer
C3: bogo buffer: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 99 degC
acpithinkpad0 at acpi0
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "42T4649" serial 20 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: LID_
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"BOOT" at acpi0 not configured
acpidock0 at acpi0: DOCK not docked (0)
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: LCD0
cpu0: Enhanced SpeedStep 1600 MHz: speeds: 2401, 2400, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: msi
inteldrm0: 1280x800, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured
em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M" rev 0x03: msi, address 
de:ad:ba:dc:ab:1e
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 2 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 2 int 17
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 2 int 18
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi
azalia0: codecs: Conexant CX20561
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x03
pci2 at ppb1 bus 2
athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17
athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 01:23:45:67:89:ab
ppb2 at pci0 

Re: Are mips64 or sparc64 packages for 6.1 released yet?

[Christian Weisgerber]

On 2017-04-12, Jan Vlach  wrote:

> I'm missing packages for mips64 (for EdgeRouter Lite/ octeon ) or
> sparc64 on official places:

Packages for alpha, mips64, mips64el, powerpc, and sparc64 are still
being built.

There's a choice.  We can put the release on hold for everybody
until the slow architectures have built their packages, or we can
go ahead with the release and deliver the packages later as they
arrive.  This time we chose the latter.

> Is there a rough guesstimate when things migt be available? 

Two weeks.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: ftpsesame package

[Todd C. Miller]

On Wed, 12 Apr 2017 21:27:49 +0200, Olivier Regnier wrote:

> "ftpsesame chroots to "/var/empty" and changes to user "proxy" to drop 
> privileges. It does keep a file descriptor to both bpf 
> (4) and pf 
> (4) so it is 
> still very powerful."

The "proxy" user was removed, that is almost certainly the problem.
The port needs a patch to use "_ftp_proxy" instead.

 - todd

Re: OpenBSD as a non-routing access point

[Eike Lantzsch]

On Wednesday, 12 April 2017 14:40:28 -04 trondd wrote:
> On Wed, April 12, 2017 4:27 am, Stuart Henderson wrote:
> > On 2017-04-12, Jordon  wrote:
> >>> rcctl enable dhcrelay
> >>> rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is your
> >>> routers
> >> 
> >> address"
> >> 
> >>> rcctl start dhcrelay
> >>> 
> >>> and possibly add -d (log to stderr) to see what its doing.
> >> 
> >> Thank you!  That got it working!  So why is that necessary?  Doesnt the
> >> bridge
> >> just forward everything?  Or are DHCP requests broadcasts that dont get
> >> forwarded?
> > 
> > It shouldn't be necessary, dhcrelay is normally used when you have a
> > subnet behind a router, and the DHCP server is a separate machine on a
> > different subnet.
> > 
> > Could it be a PF rule problem?
> > 
> > Normally you would only have an IP address on one member of the bridge,
> > just "up" on the others..
> 
> I have this problem as well.  DHCP requests go out over the bridge to the
> main interface.  The response comes back to the main interface but never
> goes to the bridge.
> 
Same here. I read somewhere (need to look it up again) that with 6.1 this DHCP 
problem with bridges got solved. I'm on 6.0 right now but will report back as 
soon as I upgraded to 6.1.
My bridge is between athn0, re2 and vether0 on an APU1.
My DHCP server is on another machine on the same network.

> I'm trying to use vmm VMs on a bridge.  I've tried set skip on {bridge
> tap}, and pass quick on {egress bridge tap} proto {tcp udp} from any to
> any port {67 68}
> Also disabling pf altogether.
Tried that too - nogo however.

-- 
Eike Lantzsch ZP6CGE

Zuviel Zucker ist ungesund. Daher:
Tragt den Zuckerberg ab!

Re: OpenBSD as a non-routing access point

[Jordon]

> On Apr 12, 2017, at 3:27 AM, Stuart Henderson  wrote:
>
> On 2017-04-12, Jordon  wrote:
>>> rcctl enable dhcrelay
>>> rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is your
routers
>> address"
>>> rcctl start dhcrelay
>>>
>>> and possibly add -d (log to stderr) to see what its doing.
>>>
>>
>> Thank you!  That got it working!  So why is that necessary?  Doesnt the
bridge
>> just forward everything?  Or are DHCP requests broadcasts that dont get
>> forwarded?
>
> It shouldn't be necessary, dhcrelay is normally used when you have a
> subnet behind a router, and the DHCP server is a separate machine on a
> different subnet.
>
> Could it be a PF rule problem?
>
> Normally you would only have an IP address on one member of the bridge,
> just "up" on the others..
>

I have done nothing with PF on this machine.

Re: OpenBSD as a non-routing access point

[Jordon]

> On Apr 12, 2017, at 1:47 PM, Mihai Popescu  wrote:
>
> Because of titles like this post there is no clear anymore what
> someone is reffering to when one is using words like bridge, switch,
> hub, access point, router, ...
> Add the IPv6 in the mix and you think you understand the spagetti of
internet.
>
> Bleah, looking again at "non-routing access point". What about the "no
> pancake making CPU".
>
> Sorry for the rant.
>

You have a valid point.

When one buys a linksys/netgear/whatever “Wireless Access Point”, it is
often intended to be a full Internet gateway (router, NAT, DHCP, etc) that
also does wifi.

For all examples I found for making an OpenBSD access point, the OpenBSD
machine is used as the main router/DHCP server/gateway/buzzword on the
network.  I have a separate machine (currently running pfSense, though I plan
on switching it to OpenBSD soon) that is handling the routing/NAT/DHCP/etc
functionality on my network.  I just want to see if I can make my openbsd
machine an access point to this network.

I got the hostname.athn0 set up so other devices could connect to it.  I then
though that just bridging it to the ethernet NIC would make it ‘just work’
- whatever comes in one port goes out the other and vice-versa.  It turned out
that DHCP requests weren’t going though.  I saw a tutorial online that
showed enabling the ipforwarding sysctl so i tried that but it made no
difference.  The suggestion here about turning on relayctld is what made this
work for me.  I am guessing that OpenBSD does not forward broadcasts over a
bridged connection.

If there is better terminology for what I am trying to do, I am more than
interested in learning it! :)

Jordon

Re: OpenBSD as a non-routing access point

[Jordon]

> On Apr 12, 2017, at 1:54 AM, Stefan Sperling  wrote:
> 
> On Tue, Apr 11, 2017 at 08:04:45PM -0500, Jordon wrote:
>>   /ets/hostname.athn0
>> media autoselect mode 11n media opt host ap chan 1
> 
> Is there actual whitespace between 'media' and 'opt' and between
> 'host' and 'ap' in your config file? Or is this a copy/paste error?
> 
> It should look like this:
> media autoselect mode 11n mediaopt hostap chan 1
> 

No, that must have been a copy/paste error - sorry!

Jordon

ftpsesame package

[Olivier Regnier]

I runs on single laptop with OpenBSD 6.0 and PF.

I use ftpsesame installed via package for FTP transactions and it works 
fine.


System was upgraded to 6.1 and ftpsesame don't work anymore.

When i run the following command:
$ doas ftpsesame -d -i trunk0

I have this error:
drop_privs: Undefine error:0

"ftpsesame chroots to "/var/empty" and changes to user "proxy" to drop 
privileges. It does keep a file descriptor to both bpf 
(4) and pf 
(4) so it is 
still very powerful."


Is there a solution to resolve this problem?

Regards,
Olivier

Are mips64 or sparc64 packages for 6.1 released yet?

[Jan Vlach]

Hello misc,

I'm missing packages for mips64 (for EdgeRouter Lite/ octeon ) or
sparc64 on official
places:

at least:
http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/
http://ftp.eu.openbsd.org/pub/OpenBSD/6.1/packages/
https://ftp.fr.openbsd.org/pub/OpenBSD/6.1/packages/

I can see only amd64, arm, hppa, i386. 

For the time being I might get lucky with pkg_add -Dsnap, but I remember
that base+packages need to match ...

Is this intentional? (Long build times, lack of time ...) Is there a
rough guesstimate when things migt be available? 

Thank you,
Jan

Re: Intuos Draw (uwacom) question

[Frank Groeneveld]

On Wed, Apr 12, 2017, at 08:16, Peter J. Philipp wrote:
> I'm interested in buying an Wacom Intuos Draw which is supported in
> 6.1.  However when I go to reichelt.de the model that's available says
> CTL-490DW I don't know if DW is supported, can someone let me know?
> 
> https://www.reichelt.de/Grafiktabletts-stifte/WACOM-CTL-490DW/3/index.html?ACTION=3=5=160633=6271=WACOM+CTL-490DW
> 
> Any feedback would be appreciated.
> 
> Regards,
> 
> -peter
> 

Hello Peter,

Yes, that will work. I'm the author of the driver and use it with a
CTL-490DW-N (where -N probably means Dutch). It won't register pressure
levels or proximity. I use the tablet as mouse replacement about 40
hours a week to prevent getting RSI.

Two things of note though:
1. Unplugging while X is running results in the X log getting spammed
(this happens with more devices, search tech@ for wacom). The fix is to
restart X.
2. Once in a while the cursor jumps to the top left corner and back when
you click something. This happens only a few times a day and doesn't
cause me issues, but I want to fix it and haven't been able to so far.
It seems the Linux driver just cuts of the lowest bit of the coordinates
and I haven't figured out yet whether this will fix it or whether they
use a different trick for it.

Regards,

Frank

Re: OpenBSD as a non-routing access point

[Mihai Popescu]

Because of titles like this post there is no clear anymore what
someone is reffering to when one is using words like bridge, switch,
hub, access point, router, ...
Add the IPv6 in the mix and you think you understand the spagetti of internet.

Bleah, looking again at "non-routing access point". What about the "no
pancake making CPU".

Sorry for the rant.

Re: OpenBSD as a non-routing access point

[trondd]

On Wed, April 12, 2017 4:27 am, Stuart Henderson wrote:
> On 2017-04-12, Jordon  wrote:
>>> rcctl enable dhcrelay
>>> rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is your
>>> routers
>> address"
>>> rcctl start dhcrelay
>>>
>>> and possibly add -d (log to stderr) to see what its doing.
>>>
>>
>> Thank you!  That got it working!  So why is that necessary?  Doesnt the
>> bridge
>> just forward everything?  Or are DHCP requests broadcasts that dont get
>> forwarded?
>
> It shouldn't be necessary, dhcrelay is normally used when you have a
> subnet behind a router, and the DHCP server is a separate machine on a
> different subnet.
>
> Could it be a PF rule problem?
>
> Normally you would only have an IP address on one member of the bridge,
> just "up" on the others..
>

I have this problem as well.  DHCP requests go out over the bridge to the
main interface.  The response comes back to the main interface but never
goes to the bridge.

I'm trying to use vmm VMs on a bridge.  I've tried set skip on {bridge
tap}, and pass quick on {egress bridge tap} proto {tcp udp} from any to
any port {67 68}
Also disabling pf altogether.

Re: OpenIKED and Windows 10 Client

[Bobby Johnson]

If you're doing pure certificate auth, not eap I think you need both
certs.  They do need to be installed under the local computer account.
Install the CA cert in the trusted root CA store, put the machine cert in
the personal store.  I also think it may be necessary to put the full
asn1_dn of the server and client certs in the src_id and dst_id lines of
the iked config.


On Wed, Apr 12, 2017 at 6:45 AM, Stuart Henderson 
wrote:

> On 2017-04-12, Markus Rosjat  wrote:
> > Am 12.04.2017 um 11:49 schrieb Martijn van Duren:
> >> On 04/12/17 11:42, Stuart Henderson wrote:
> >>> On 2017-04-11, Markus Rosjat  wrote:
>  I think the problem is with the windows site because it tells me there
>  is no certificate to be found. I added the certificate to local
> machine
>  store -> own certificates (at least in the german UI is no personal
> folder)
> >>>
> >>> I think you're adding this cert to the wrong one of the many cert
> stores
> >>> on Windows. It worked for me in trusted CAs, though there may be a
> better
> >>> option that also works.
> >>>
> >> One thing that also bit me was that I had to put them in the system-wide
> >> store and not in the personal store.
> >>
> >
> > well I put the CA certs in the trusted CA Folder and the cert for the
> > machine in "Eigene Zertifikate" in the local machine store
> >
> > it seems to be a problem on the windows site thought
>
> You only want the CA certificate, not the machine certificate.

Re: OpenIKED and Windows 10 Client

[Stuart Henderson]

On 2017-04-12, Markus Rosjat  wrote:
> Am 12.04.2017 um 11:49 schrieb Martijn van Duren:
>> On 04/12/17 11:42, Stuart Henderson wrote:
>>> On 2017-04-11, Markus Rosjat  wrote:
 I think the problem is with the windows site because it tells me there
 is no certificate to be found. I added the certificate to local machine
 store -> own certificates (at least in the german UI is no personal folder)
>>>
>>> I think you're adding this cert to the wrong one of the many cert stores
>>> on Windows. It worked for me in trusted CAs, though there may be a better
>>> option that also works.
>>>
>> One thing that also bit me was that I had to put them in the system-wide
>> store and not in the personal store.
>>
>
> well I put the CA certs in the trusted CA Folder and the cert for the 
> machine in "Eigene Zertifikate" in the local machine store
>
> it seems to be a problem on the windows site thought

You only want the CA certificate, not the machine certificate.

Re: OpenIKED and Windows 10 Client

[Markus Rosjat]

well I put the CA certs in the trusted CA Folder and the cert for the 
machine in "Eigene Zertifikate" in the local machine store


it seems to be a problem on the windows site thought

regards

markus

Am 12.04.2017 um 11:49 schrieb Martijn van Duren:

On 04/12/17 11:42, Stuart Henderson wrote:

On 2017-04-11, Markus Rosjat  wrote:

I think the problem is with the windows site because it tells me there
is no certificate to be found. I added the certificate to local machine
store -> own certificates (at least in the german UI is no personal folder)


I think you're adding this cert to the wrong one of the many cert stores
on Windows. It worked for me in trusted CAs, though there may be a better
option that also works.


One thing that also bit me was that I had to put them in the system-wide
store and not in the personal store.



--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT

Output of netstat -m shows lower value with higher kern.maxclusters

[Marc Peters]

Hi,

after i updated from 6.0 to 6.1, i saw that kern.maxclusters was raised
and removed our local change to kern.maxclusters.

Although the value is now way higher, the output shows a lower number
than before:

before the upgrade:
~ # sysctl kern.maxclusters
kern.maxclusters=24578

~ # netstat -m
314 mbufs in use:
298 mbufs allocated to data
6 mbufs allocated to packet headers
10 mbufs allocated to socket names and addresses
296/2192/24584 mbuf 2048 byte clusters in use (current/peak/max)
0/8/24584 mbuf 4096 byte clusters in use (current/peak/max)
0/8/24584 mbuf 8192 byte clusters in use (current/peak/max)
0/14/24584 mbuf 9216 byte clusters in use (current/peak/max)
0/10/24580 mbuf 12288 byte clusters in use (current/peak/max)
0/8/24584 mbuf 16384 byte clusters in use (current/peak/max)
0/8/24584 mbuf 65536 byte clusters in use (current/peak/max)
1948 Kbytes allocated to network (34% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


after the upgrade:
~ # sysctl kern.maxclusters
kern.maxclusters=262144

~ # netstat -m
40 mbufs in use:
24 mbufs allocated to data
5 mbufs allocated to packet headers
11 mbufs allocated to socket names and addresses
21/168/64 mbuf 2048 byte clusters in use (current/peak/max)
0/0/120 mbuf 2112 byte clusters in use (current/peak/max)
0/8/64 mbuf 4096 byte clusters in use (current/peak/max)
0/0/64 mbuf 8192 byte clusters in use (current/peak/max)
0/0/112 mbuf 9216 byte clusters in use (current/peak/max)
0/0/80 mbuf 12288 byte clusters in use (current/peak/max)
0/0/64 mbuf 16384 byte clusters in use (current/peak/max)
0/0/64 mbuf 65536 byte clusters in use (current/peak/max)
420 Kbytes allocated to network (12% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


Is this just an output issue, or are the numbers now related to other
values?

Cheers,
Marc

dmesg:
OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 25742729216 (24550MB)
avail mem = 24957874176 (23801MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf7fe000 (127 entries)
bios0: vendor HP version "P68" date 07/02/2013
bios0: HP ProLiant DL360 G7
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP SPCR MCFG HPET  SPMI ERST APIC SRAT 
BERT HEST DMAR SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.61 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,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 3600606060 Hz
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 32 (application processor)
cpu1: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.14 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,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 0, package 1
cpu2 at mainbus0: apid 20 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.13 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,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 10, package 0
cpu3 at mainbus0: apid 52 (application processor)
cpu3: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.13 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,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 10, package 1
cpu4 at mainbus0: apid 2 (application processor)
cpu4: Intel(R) Xeon(R) CPU X5687 @ 3.60GHz, 3600.13 MHz
cpu4:

Re: Adding default IPv6 route fails on 6.1

[Alexander Bochmann]

...on Wed, Apr 12, 2017 at 11:12:28AM +0200, Sterling Archer wrote:
 > On Wed, Apr 12, 2017 at 9:59 AM, Dimitris Papastamos  wrote:
 > > Try this instead:
 > > !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0
 > That did the trick, dhcpcd is receiving router advertisments from
 > my ISP now. Thanks, Dimitris.

On that note - there's several cloud VM providers out there 
who assign a IPv6 network to customer VMs and then expect that 
fe80::1 is used as default gateway.

In those cases, an interface tag is required too, as the 
system will usually have at least one other link-local 
network on the lo0 interface (that's not new in 6.1)... 

So, depending on the interface name, something like this works:

 > # fgrep fe80 /etc/mygate
 > fe80::1%vio0

Alex.

Re: Adding default IPv6 route fails on 6.1

[Stuart Henderson]

On 2017-04-12, Sterling Archer  wrote:
> On Wed, Apr 12, 2017 at 8:50 AM, Stefan Sperling  wrote:
>
>> On Wed, Apr 12, 2017 at 01:20:20AM +0200, Sterling Archer wrote:
>> > Hello everyone.
>> >
>> > After upgrading to 6.1 about an hour ago, I noticed that I didn't have an
>> > IPv6 connection
>> > anymore.
>> >
>> > I use dhcpcd over a pppoe session, which worked fine in 6.0-stable. The
>> > problem seems to
>> > be a failure to add a default inet6 route on the pppoe device. I see this
>> > error in the dmesg
>> > console log:
>> >
>> > "add net default: gateway fe80::: No route to host"
>> >
>> > Did I miss something in the changelog, or is this a bug?
>> >
>> >
>> > Here's the contents of my hostname.pppoe0:
>> >
>> > [sven@puffy ~]$ cat /etc/hostname.pppoe0
>> > description "pppoe session over vlan6"
>> > inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
>> > pppoedev vlan6 authproto pap \
>> > authname 'kennyloggins' authkey 'dangerzone!'
>> > dest 0.0.0.1
>> > inet6 eui64
>> > !/sbin/route add default -ifp pppoe 0.0.0.1
>> > !/sbin/route add -inet6 default -ifp pppoe0 fe80::
>> >
>>
>> Can you add a default route manually once the pppoe session is up or
>> does that not work either?
>>
>
> Sorry, I should have mentioned that, it fails when you attempt to
> manually add it too.

This was due to a change in how the routing table is handled, I'm hoping
it is temporary because it makes things awkward with dynamic addresses.
It's not so bad for v6 where you can use any address in thr correct scope;
v4 is worse as it means you either have to rely on the horrible 0.0.0.1
hack or look up the remote address when you're adding a route for pppoe.

Re: OpenIKED and Windows 10 Client

[Martijn van Duren]

On 04/12/17 11:42, Stuart Henderson wrote:
> On 2017-04-11, Markus Rosjat  wrote:
>> I think the problem is with the windows site because it tells me there 
>> is no certificate to be found. I added the certificate to local machine 
>> store -> own certificates (at least in the german UI is no personal folder)
> 
> I think you're adding this cert to the wrong one of the many cert stores
> on Windows. It worked for me in trusted CAs, though there may be a better
> option that also works.
> 
One thing that also bit me was that I had to put them in the system-wide
store and not in the personal store.

Re: OpenIKED and Windows 10 Client

[Stuart Henderson]

On 2017-04-11, Markus Rosjat  wrote:
> I think the problem is with the windows site because it tells me there 
> is no certificate to be found. I added the certificate to local machine 
> store -> own certificates (at least in the german UI is no personal folder)

I think you're adding this cert to the wrong one of the many cert stores
on Windows. It worked for me in trusted CAs, though there may be a better
option that also works.

Re: Blocking outgoing, non-privacy ext. IPv6 addresses' traffic?

[Paul de Weerd]

On Wed, Apr 12, 2017 at 10:48:50AM +0200, Florian Ermisch wrote:
| Hi everyone,
| 
| is there a way with to identify and filter
| automatically generated, MAC-based IPv6
| addresses in pf?
| I think there was some bit set or flipped in
| the MAC-based or the RFC 4941 privacy
| extensions based addresses. But I then
| still had to match an address based on a
| single bit (and the networks prefix, of
| course).
| Are bitwise matches even possible with
| pf?
| 
| The usecase, of course, is to prevent
| devices too stupid or too poorly configured
| to use the privacy extensions to access
| anything outside the LAN via IPv6.
| 
| Kind regards, Florian

Even if you could, filtering on the global/local bit like you suggest
(bit 6, when the leftmost bit of the host-part of the address is
numbered 0) won't work.  Privacy addresses all have 0 there.  But
EUI64 addresses are based on the MAC address where that same bit is
inverted.  In MAC addresses, that bit means 'locally administered'
when set to 0, 'globally unique' when set to 1 (which sounds a lot
like the global/local stuff in v6, but is completely different).

Here's a vio0 interface on a Linux KVM vm running OpenBSD:

vio0: flags=8843 mtu 1500
lladdr 52:54:00:6c:8e:79

Note the '2' in the second nibble there: this is a locally
administered MAC address.  This bit gets *inverted* when generating an
EUI64 address:

inet6 fe80::5054:ff:fe6c:8e79%vio0 prefixlen 64 scopeid 0x1

So, now you have a 0 in bit 6 of the host part of your EUI64 address.

A more certain way of seeing if an address is EUI64, is to check for
the ff:fe bit in the middle of the host part of the address.  However,
I don't think it's possible to filter on that in pf(4).

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: Adding default IPv6 route fails on 6.1

[Sterling Archer]

On Wed, Apr 12, 2017 at 9:59 AM, Dimitris Papastamos  wrote:

> Try this instead:
>
> !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0
>

That did the trick, dhcpcd is receiving router advertisments from
my ISP now. Thanks, Dimitris.

Re: Adding default IPv6 route fails on 6.1

[Sterling Archer]

On Wed, Apr 12, 2017 at 8:50 AM, Stefan Sperling  wrote:

> On Wed, Apr 12, 2017 at 01:20:20AM +0200, Sterling Archer wrote:
> > Hello everyone.
> >
> > After upgrading to 6.1 about an hour ago, I noticed that I didn't have an
> > IPv6 connection
> > anymore.
> >
> > I use dhcpcd over a pppoe session, which worked fine in 6.0-stable. The
> > problem seems to
> > be a failure to add a default inet6 route on the pppoe device. I see this
> > error in the dmesg
> > console log:
> >
> > "add net default: gateway fe80::: No route to host"
> >
> > Did I miss something in the changelog, or is this a bug?
> >
> >
> > Here's the contents of my hostname.pppoe0:
> >
> > [sven@puffy ~]$ cat /etc/hostname.pppoe0
> > description "pppoe session over vlan6"
> > inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
> > pppoedev vlan6 authproto pap \
> > authname 'kennyloggins' authkey 'dangerzone!'
> > dest 0.0.0.1
> > inet6 eui64
> > !/sbin/route add default -ifp pppoe 0.0.0.1
> > !/sbin/route add -inet6 default -ifp pppoe0 fe80::
> >
>
> Can you add a default route manually once the pppoe session is up or
> does that not work either?
>

Sorry, I should have mentioned that, it fails when you attempt to
manually add it too.

OpenBSD 6.1 - bravo

[Clément . J]

Thank you OpenBSD team for this new release 6.1
OpenBSD makes me happy every day for so many usages
so thank you so much everyone for your great work.

have a good day
vive OpenBSD


Le 12-04-2017 10:27, Stuart Henderson a écrit :

On 2017-04-12, Jordon  wrote:

rcctl enable dhcrelay
rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is
your routers

address"

rcctl start dhcrelay

and possibly add -d (log to stderr) to see what its doing.



Thank you!  That got it working!  So why is that necessary?  Doesnt
the bridge
just forward everything?  Or are DHCP requests broadcasts that dont
get
forwarded?


It shouldn't be necessary, dhcrelay is normally used when you have a
subnet behind a router, and the DHCP server is a separate machine on
a
different subnet.

Could it be a PF rule problem?

Normally you would only have an IP address on one member of the
bridge,
just "up" on the others..

Blocking outgoing, non-privacy ext. IPv6 addresses' traffic?

[Florian Ermisch]

Hi everyone,

is there a way with to identify and filter
automatically generated, MAC-based IPv6
addresses in pf?
I think there was some bit set or flipped in
the MAC-based or the RFC 4941 privacy
extensions based addresses. But I then
still had to match an address based on a
single bit (and the networks prefix, of
course).
Are bitwise matches even possible with
pf?

The usecase, of course, is to prevent
devices too stupid or too poorly configured
to use the privacy extensions to access
anything outside the LAN via IPv6.

Kind regards, Florian

Re: OpenBSD as a non-routing access point

[Stuart Henderson]

On 2017-04-12, Jordon  wrote:
>> rcctl enable dhcrelay
>> rcctl set dhcrelay flags -i athn0 192.168.1.1 "assuming that is your routers
> address"
>> rcctl start dhcrelay
>>
>> and possibly add -d (log to stderr) to see what its doing.
>>
>
> Thank you!  That got it working!  So why is that necessary?  Doesnt the bridge
> just forward everything?  Or are DHCP requests broadcasts that dont get
> forwarded?

It shouldn't be necessary, dhcrelay is normally used when you have a
subnet behind a router, and the DHCP server is a separate machine on a
different subnet.

Could it be a PF rule problem?

Normally you would only have an IP address on one member of the bridge,
just "up" on the others..

Re: Adding default IPv6 route fails on 6.1

[Dimitris Papastamos]

On Wed, Apr 12, 2017 at 01:20:20AM +0200, Sterling Archer wrote:
> Hello everyone.
> 
> After upgrading to 6.1 about an hour ago, I noticed that I didn't have an
> IPv6 connection
> anymore.
> 
> I use dhcpcd over a pppoe session, which worked fine in 6.0-stable. The
> problem seems to
> be a failure to add a default inet6 route on the pppoe device. I see this
> error in the dmesg
> console log:
> 
> "add net default: gateway fe80::: No route to host"
> 
> Did I miss something in the changelog, or is this a bug?
> 
> 
> Here's the contents of my hostname.pppoe0:
> 
> [sven@puffy ~]$ cat /etc/hostname.pppoe0
> description "pppoe session over vlan6"
> inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
> pppoedev vlan6 authproto pap \
> authname 'kennyloggins' authkey 'dangerzone!'
> dest 0.0.0.1
> inet6 eui64
> !/sbin/route add default -ifp pppoe 0.0.0.1
> !/sbin/route add -inet6 default -ifp pppoe0 fe80::

Try this instead:

!/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0

Re: OpenBSD as a non-routing access point

[Stefan Sperling]

On Tue, Apr 11, 2017 at 08:04:45PM -0500, Jordon wrote:
>/ets/hostname.athn0
> media autoselect mode 11n media opt host ap chan 1

Is there actual whitespace between 'media' and 'opt' and between
'host' and 'ap' in your config file? Or is this a copy/paste error?

It should look like this:
 media autoselect mode 11n mediaopt hostap chan 1

Re: Adding default IPv6 route fails on 6.1

[Stefan Sperling]

On Wed, Apr 12, 2017 at 01:20:20AM +0200, Sterling Archer wrote:
> Hello everyone.
> 
> After upgrading to 6.1 about an hour ago, I noticed that I didn't have an
> IPv6 connection
> anymore.
> 
> I use dhcpcd over a pppoe session, which worked fine in 6.0-stable. The
> problem seems to
> be a failure to add a default inet6 route on the pppoe device. I see this
> error in the dmesg
> console log:
> 
> "add net default: gateway fe80::: No route to host"
> 
> Did I miss something in the changelog, or is this a bug?
> 
> 
> Here's the contents of my hostname.pppoe0:
> 
> [sven@puffy ~]$ cat /etc/hostname.pppoe0
> description "pppoe session over vlan6"
> inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \
> pppoedev vlan6 authproto pap \
> authname 'kennyloggins' authkey 'dangerzone!'
> dest 0.0.0.1
> inet6 eui64
> !/sbin/route add default -ifp pppoe 0.0.0.1
> !/sbin/route add -inet6 default -ifp pppoe0 fe80::
> 

Can you add a default route manually once the pppoe session is up or
does that not work either?

Re: Driver support for WLE600vx/802.11ac

[Stefan Sperling]

On Tue, Apr 11, 2017 at 08:34:34PM -0400, Nathan Van Ymeren wrote:
> Hello,
> 
> I am putting together a PCengines machine, and  I need some clarification
> about support in OpenBSD for the WLE600vx wifi card.  This card claims to
> support 802.11a/b/g/n/ac and uses the Qualcomm Atheros QCA9882 chipset.
> According to PCengines, the card requires the ath10k driver, which I am
> unable to find in the OpenBSD manual.
> 
> My understanding is that OpenBSD does not currently support 802.11ac; only
> the 802.11n standard.  Is this correct?
> 
> Assuming that this is correct, if I were to install the WLE600vx, can I use
> it in "n" mode with OpenBSD until "ac" support is implemented, or is the
> card altogether unsupported?
> 
> Thanks very much,
> 
> N
 
ath10k devices are not supported. They need a new driver because Atheros
has changed the driver<->hardware interface with this generation of devices.
This has nothing to do with 11n vs 11ac.

Re: Substitute for other variables in pkg.conf(5)

[bytevolcano]

On Fri, 7 Apr 2017 17:44:30 + (UTC)
Stuart Henderson  wrote:

> On 2017-04-06, 
>  wrote:
> > Since pkg.conf(5) is no longer used, how would you set fullwidth,
> > loglevel, nochecksum, ntogo?
> >
> > In particular, I am interested in fullwidth, loglevel, and ntogo.
> >
> >  
> 
> ntogo is now on "pkg_add -V".
> 
> nochecksum (to stop verifying checksums during pkg_delete) is on by
> default, use "pkg_add -D checksum" to enable verifying these again.
> 
> I think the others have gone.
> 

Thanks Stuart. I will see what I can do about loglevel and fullwidth.
The fullwidth is not a major issue (would be nice though), and I am
guessing loglevel > 1 was never implemented?

Intuos Draw (uwacom) question

[Peter J. Philipp]

I'm interested in buying an Wacom Intuos Draw which is supported in
6.1.  However when I go to reichelt.de the model that's available says
CTL-490DW I don't know if DW is supported, can someone let me know?

https://www.reichelt.de/Grafiktabletts-stifte/WACOM-CTL-490DW/3/index.html?ACTION=3=5=160633=6271=WACOM+CTL-490DW

Any feedback would be appreciated.

Regards,

-peter

Re: pkg_add on OpenBSD 6.1, fresh install

[Maurice McCarthy]

On Tue, Apr 11, 2017 at 04:43:27PM -0600 or thereabouts, Anathae Townsend wrote:
> I have done a fresh install of 6.1 (downloaded it today, from
> ftp.openbsd.org/pub/OpenBSD/6.1/amd64 as the file install61.fs (I live in
> Edmonton, Alberta, that's why I use the source ftp)) and was trying to
> install some packages...
> 
> When I type in pkg_add -v http://ftp.openbsd.org/%m/joe (as an example),
> pkg_add reports joe not found.  If instead I do pkg_add -v
> http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/joe, it works.  
> 
> Admittedly, I am running this from the root login... am I doing something
> wrong?
> 
> Anathae
> 

$ man pkg.conf
...
Special sequences â%a, %c, %m, %v will be expanded to
package architecture, OS version or snapshots,
full mirror pathâand OS version respectively.
... 

"%m" is the _whole _path