pkg_add - error while reading header / read short file / gzheader truncated

2023-12-07 Thread Joe B
Hello Misc,

I am configuring a couple of laptops for my kids, i had installed 70 with
i3 and gcompris in them, its been a while since the last update so i
decided to make a fresh install.

So I installed 74 in both of them, used the autoinstall so the process was
straightforward as always, rebooted, hw_update, syspatch, everything as
expected.

The problem comes when trying to install a package, i am trying just to of
them: feh and gcompris, in both laptops, and i get the following errors,
they are several since i do a few tries and then the problem goes and comes
at different packages

pkg_add: Ustar [package name, it is different every try, meaning
lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header
https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz:
Read short file

My configuration are:
1 laptop, re0, trying pkg_add feh
1 laptop, iwn0, trying pkg_add gcompris

both with the same results, maybe i should try in another LAN, but could it
be a problem with the CDN server ?

Thank you for your time,

--  Manuel Solis

>>

Hello,

I'm new to openBSD about 3 days old. and I ran into the same issue as
you. I would

pkg_add something and I kept getting the header message. someone on
IRC helped me

Simple. change the cdn to another mirror

look at https://www.openbsd.org/faq/faq15.html#Mirror

Basically You find a mirror probably ftp like I did go to vim or nano
/etc/installurl

delete the cdn add another mirror and re-run the pkg_add you might
need to pkg_delete

the partial and then re-run. pkg_add After all that you might need
pkg_add -u to see if the new mirror

fixes all the other partials


Hope this helps


~ Joe B


Adding multilib target for arm-none-eabi-gcc

2023-01-03 Thread Joe Nelson
I'm cross-compiling for an ST Nucleo F411RE, which requires these CFLAGS:

-mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16

On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match for
them. By comparison, on Debian, it finds 'thumb/v7e-m+fp/hard'.

Is there a way for me to update the port to include more targets, and
reinstall it?

---
System/package information:

* OpenBSD 7.2
* arm-none-eabi-gcc-linaro-7.4.2019.02p0
* arm-none-eabi-newlib-2.2.0.1p1

$ arm-none-eabi-gcc --print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
interwork;@mthumb-interwork
fpu/interwork;@mfloat-abi=hard@mthumb-interwork
thumb/interwork;@mthumb@mthumb-interwork



cdn.openbsd.org stale bsd.mp for amd64 snaps

2022-07-24 Thread joe

Hello,

The amd64 snapshots on cdn.openbsd.org have a stale bsd.mp file, which 
is making sysupgrades fail. The other files are up-to-date. 
ftp.openbsd.org has the correct bsd.mp, so it appears to be a caching 
issue with Fastly. Might need to force a refresh?


Thanks,

--
Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



MNT Pocket Reform - OpenBSD support "in development"

2022-06-28 Thread joe

https://mntre.com/media/reform_md/2022-06-20-introducing-mnt-pocket-reform.html

Looks like a fun little machine, and they claim OpenBSD support is "in 
development." I'm curious, have they contributed any code or resources 
to make OpenBSD run on this device? I'd be more inclined to buy one if 
they are actually contributing to the project.


Thanks,

--
Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: OpenBSD and multitasking

2022-04-25 Thread Joe Gidi
> Hello,
>
> I use OpenBSD amd64 snapshots on the following dmesg hardware.
> The download rate on a browser was slow and I figured out with some
> memory mapped partition that disk transfer rate was slow.
> I can bear this since I'm not into large file transfer business. But
> here is another interesting fact: each time my disk is used by some
> file transfer, all the running applications, mostly GUI based are
> stalling - that includes mostly chromium ( even if it is not chromium
> that it does the disk data transfer).
>
> My questions are: is something incorrectly set up on my computer,
> regarding the multitasking?
> I understand disk operations are slow, but may I say that kernel is
> dragged in that slow transfer too (no DMA, no cache, etc.)?
> Does this happens to all users, but since there are more powerful
> configuration involved the delay is not so noticeable?
>
> I know it is hard to project this, but can someone give me a hint
> about a minimum hardware to allow using chromium with no delays,
> please?
> I know, it should be advisable to get the maximum performance
> hardware, but i'm not in that case.



> sd0 at scsibus1 targ 0 lun 0: 
> naa.5000c5006520feaf
> sd0: 238475MB, 512 bytes/sector, 488397168 sectors

You're running on a Seagate 7200 RPM spinning disk. Migrate to an SSD.
Literally any SSD. I don't know where you are, but here, an equivalent
size generic SATA SSD costs $40 USD and will be exponentially faster for
random read/write and IOPS.

Trying to run heavy modern desktop applications like Chromium from a
spinning disk is an exercise in masochism. You're also running Chromium
with 8 GB of RAM, so it's entirely possible you're running into swap,
which will REALLY kill your performance, especially on a spinning disk...

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



syspatch on raspberry pi 3. new kernel?

2021-10-31 Thread Joe Barnett
I just ran syspatch on my Raspberry Pi 3 running OpenBSD 7.0 and the 
patches initially appeared to have been applied successfully, including 
creating a new kernel and printing the message to reboot to use the new 
kernel.


Upon reboot, motd, dmesg, and "sysctl kern.version" still report what I 
believe to be the original kernel:


OpenBSD 7.0 (GENERIC) #1280: Thu Sep 30 16:31:07 MDT 2021
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC

That said, the new /bsd (and /bsd.booted) are dated today, as would be 
expected following syspatch.  The result of "sha256 /bsd" matches the 
data in /var/db/kernel.SHA256 (file also dated today as would be 
expected).  What else?  I have also run "syspatch -R" to remove the 
updates, rebooted, then ran syspatch again with the same results.  And 
it seems that /etc/motd is not being updated on boot on this system as I 
think usually happens.  /var/run/dmesg.boot does appear to be updated 
with each boot.  /usr/share/relink/kernel/GENERIC.MP/relink.log appears 
normal:


(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0xd4d4d4d4 gapdummy.o
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
${OBJS}

textdatabss dec hex
10566181611208  829392  12006781b7357d
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
rm -f bsd.gdb
mv -f newbsd bsd
install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd

Kernel has been relinked and is active on next reboot.

SHA256 (/bsd) = 
1e457ddd75e56de0b8cc01607a5d0be6903be07ee0c2baeb440e823a253e68a0


Running syspatch on two other systems (an old Alix/i386 and a vm at 
vultr.com) resulted in expected results:


OpenBSD 7.0 (GENERIC) #1: Fri Oct 29 12:02:30 MDT 2021

r...@syspatch-70-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC


OpenBSD 7.0 (GENERIC) #1: Fri Oct 29 12:02:41 MDT 2021

r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC


Any ideas will be greatly appreciated.  Am I missing any steps here?

Thanks,

Joe

Following is the latest dmesg from this rpi3:

OpenBSD 7.0 (GENERIC) #1280: Thu Sep 30 16:31:07 MDT 2021
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC
real mem  = 956735488 (912MB)
avail mem = 894844928 (853MB)
random: boothowto does not indicate good seed
mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 
D-cache

cpu0: 512KB 64b/line 16-way L2 cache
cpu0: CRC32,ASID16
apm0 at mainbus0
efi0 at mainbus0: UEFI 2.8
efi0: Das U-Boot rev 0x20210100
simplefb0 at mainbus0: 656x416, 32bpp
wsdisplay0 at simplefb0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)
"system" at mainbus0 not configured
"axi" at mainbus0 not configured
simplebus0 at mainbus0: "soc"
bcmclock0 at simplebus0
bcmmbox0 at simplebus0
bcmgpio0 at simplebus0
bcmaux0 at simplebus0
bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10
bcmintc0 at simplebus0
bcmrng0 at simplebus0
pluart0 at simplebus0: console
bcmsdhost0 at simplebus0: 250 MHz base clock
sdmmc0 at bcmsdhost0: 4-bit, sd high-speed, mmc high-speed, dma
dwctwo0 at simplebus0
bcmdog0 at simplebus0
bcmtemp0 at simplebus0
"local_intc" at simplebus0 not configured
sdhc0 at simplebus0
sdhc0: SDHC 3.0, 200 MHz base clock
sdmmc1 at sdhc0: 4-bit, sd high-speed, mmc high-speed
simplebus1 at simplebus0: "firmware"
"clocks" at simplebus1 not configured
"expgpio" at simplebus1 not configured
"power" at simplebus0 not configured
"mailbox" at simplebus0 not configured
"gpiomem" at simplebus0 not configured
"fb" at simplebus0 not configured
"vcsm" at simplebus0 not configured
"virtgpio" at simplebus0 not configured
"clocks" at mainbus0 not configured
"phy" at mainbus0 not configured
"arm-pmu" at mainbus0 not configured
agtimer0 at mainbus0: 19200 kHz
"leds" at mainbus0 not configured
"fixedregulator_3v3" at mainbus0 not configured
"fixedregulator_5v0" at mainbus0 not configured
"bootloader" at mainbus0 not configured
dt: 445 probes
usb0 at dwctwo0: USB revision 2.0
sdmmc0: can't enable card
uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev 
2.00/1.00 addr 1
uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard Microsystems 
product 0x9514" rev 2.00/2.00 addr 2

bwfm0 at sdmmc1 function 1
manufacturer 0x02d0, product 0xa9a6 at sdmmc1 function 2 not configured
smsc0 at uhub1 port 1 configuration 1 interface 0 "Standard Microsystems 
SMSC9512/14" rev 2.00/2.00 addr 3

smsc0: address b8:27:eb:8b:a1:c7
ukphy0 at smsc0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x0001f0, model 0x000c
umass0 at uhub1 port 5 configuration 1 interface 0 "Sa

Re: httpd(8) - PHP: More details in error log

2021-10-08 Thread Joe Barnett

On 2021-10-07 18:28, J. K. wrote:

Hi,

I have a question to OpenBSD's httpd and PHP.
Don't know if this is httpd related or PHP.

With the default settings it's hard to debug
error with my PHP script, because under
/var/www/logs/error.log there is no timestamp
or the requested URI. Is there a configuration
for httpd or PHP to get more details in the
error log?

Thanks in advance.

BTW: This is my second mail with the same
context on this list. But had some troubles
with my domain.

Kind regards,

J. K.


My apologies as I am not really answering your question, but here goes.  
My OpenBSD machine running httpd is solely for learning, and it is low 
volume. To simplify debugging, I log both access and errors to 
/var/www/logs/error.log with the following entries in /etc/httpd.conf


log access "error.log"
log error "error.log"
log style forwarded

The access information tells me about URI, timestamp, browser/agent, 
things of that nature.  Along with the errors that are logged in the 
same file, I then can easily associate a PHP error with a URI or 
timestamp.


My php and php-fpm files are unchanged from the defaults.  My guess is 
there are options that can be set in /etc/php-8.0.ini but I have not 
checked nor made any changes to that file. (I have php/fpm 8.0 installed 
on my OpenBSD 6.9 system; you might have different versions installed)


Anyway, this might be helpful for you in the short term -- until you are 
able to more correctly log the information you need.


--
Joe Barnett



Re: 4K display, teeny-tiny things

2021-08-22 Thread Joe Gidi
> Picked up a 4K display (LG 27UPS650) and it's gorgeous. Bright colors,
> crisp, lovely. The console fonts and some application fonts are now
> dialed in WRT size.
>
> But application menu bars have tiny icons and tiny titles, and their
> man pages don't address that. Do those settings live in libraries I'm
> not used to tweaking?
>
> --
>
> Edward Ahlsen-Girard
> Ft Walton Beach, FL

Hi Ed,

The Arch Linux Wiki page on HiDPI is a good resource for this:

https://wiki.archlinux.org/title/HiDPI

Personally, I am using the following settings in my .Xresources file to
scale things to a usable size and get a mouse pointer I can actually see
(I'm using a 4k 27" display as well):

Xft.dpi: 144
Xcursor.size: 32
Xcursor.theme: Adwaita

Hope this helps!

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: MALLOC_STATS [was: Clang sanitizer support]

2021-07-23 Thread Joe Nelson
Otto Moerbeek wrote:
> yeah, MALLOC_STATS is not well maintained... 

What's the relation between the MALLOC_STATS code currently in -stable,
and the code in your mdump [0] project? Are you experimenting with
different approaches?

BTW, thanks for your work on this.

0: https://github.com/omoerbeek/mdump



Re: MALLOC_STATS [was: Clang sanitizer support]

2021-07-23 Thread Joe Nelson
Omar Polo wrote:
> not tried, but compiles :)

Your patch made it compile for me too. With that change I was able to
run through the steps in https://www.drijf.net/malloc/ and detect memory
leaks! Thank you.

What's the process to get your change applied to -current? Should it be
submitted to the tech@ list?



Re: MALLOC_STATS [was: Clang sanitizer support]

2021-07-23 Thread Joe Nelson
Omar Polo wrote:
> There's a built-in mechanisms to check for memory leaks:
> 
>   https://www.drijf.net/malloc/
> 
> don't know if it still applies, I tried only once and was like a couple
> of years ago (if not more).

Thanks for the tip, Omar. I just tried compiling malloc.c with MALLOC_STATS
defined, but I got a compiler error:

clang -O2 -pipe -g -Wimplicit -I/usr/src/lib/libc/include 
-I/usr/src/lib/libc/hidden \
-D__LIBC__  -Werror-implicit-function-declaration -include 
namespace.h   \
-Werror=deprecated-declarations -DAPIWARN -DYP 
-I/usr/src/lib/libc/yp\
-I/usr/src/lib/libc -I/usr/src/lib/libc/gdtoa   
 \
-I/usr/src/lib/libc/arch/amd64/gdtoa -DINFNAN_CHECK 
-DMULTIPLE_THREADS   \
-DNO_FENV_H -DUSE_LOCALE -I/usr/src/lib/libc 
-I/usr/src/lib/libc/citrus  \
-DRESOLVSORT -DFLOATING_POINT -DPRINTF_WIDE_CHAR -DSCANF_WIDE_CHAR 
-DFUTEX  -MD  \
-MP  -c /usr/src/lib/libc/stdlib/malloc.c -o malloc.o

/usr/src/lib/libc/stdlib/malloc.c:1613:14: error: use of undeclared 
identifier 'd'

STATS_SUB(d->malloc_used, roldsz - rnewsz);
  ^
1 error generated.

Malloc source version:
$OpenBSD: malloc.c,v 1.270 2021/04/09 06:05:21 otto Exp $
System:
6.9 stable



Re: Clang sanitizer support

2021-07-20 Thread Joe Nelson
On Fri, Jan 8, 2021, at 5:40 PM, Joe Nelson wrote:
> Hi all, I'd like to use Clang's AddressSanitizer and ThreadSanitizer
> on my OpenBSD development machine.

Following up on this, looks like MALLOC_OPTIONS can help me detect
use-after-free and double free errors. What I'm missing is a way to
detect memory leaks in my programs. Any tips?



Re: The simplest full cray data core with 3 cpu's and a physics hack that makes it work

2021-04-02 Thread Joe Davis


> On 2 Apr 2021, at 14:17, Benjamin Baier  wrote:
> 
> GPT-3 gone wild, or what? Definitely to late for Aprilfools-day.
> 

If it’s GPT-3, it’s slipping.



Installing across two SSDs, encrypted

2021-01-29 Thread Joe Nelson
I'd like to install obsd on a laptop that has one built-in 128GB SSD,
and a 1TB SATA SSD added in a separate bay. Was thinking of putting the
system files on the small drive, and /home, /var, /tmp, and /usr/local
on the big one. I'd like to use full-disk encryption for the big drive.

Two questions. First, will the installer set up the partitions across
the drives for me, or do I need to do a custom procedure with disklabel?
Second, how do I get the OS to prompt me during startup for a
passphrase, and mount the encrypted drive? (It's not the primary drive
with the OS on it, which seems nonstandard.)

Thanks for any help.



Clang sanitizer support

2021-01-08 Thread Joe Nelson
Hi all, I'd like to use Clang's AddressSanitizer and ThreadSanitizer on
my OpenBSD development machine. However, the Clang 10 documentation
lists OpenBSD support for only the UndefinedBehaviorSanitizer.

Does anyone know how hard it would be to port them? Are they absent
because nobody really cares about them, or is it because of a
significant technical challenge to get them on OpenBSD?

Also, are there alternatives to these sanitizers? Valgrind? Running
clang on another OS in vmm(4)? I tried the valgrind package but it
segfaulted immediately when I ran it early last year.


OS support for sanitizers, as reported by the docs:

AddressSanitizer
 * Android ARM
 * FreeBSD i386/x86_64 (tested on FreeBSD 11-current)
 * Linux i386/x86_64 (tested on Ubuntu 12.04)
 * NetBSD i386/x86_64
 * Windows 8.1+ (i386/x86_64)
 * iOS Simulator
 * macOS 10.7 - 10.11 (i386/x86_64)

ThreadSanitizer
 * Android aarch64, x86_64
 * Darwin arm64, x86_64
 * FreeBSD
 * Linux aarch64, x86_64, powerpc64, powerpc64le
 * NetBSD

MemorySanitizer
 * FreeBSD
 * Linux
 * NetBSD

UndefinedBehaviorSanitizer
 * Android
 * FreeBSD
 * Linux
 * NetBSD
 * OpenBSD
 * Windows
 * macOS



Re: AMD Ryzen

2020-06-23 Thread Joe Barnett

On 2020-06-23 08:56, Gregory Edigarov wrote:

Hello,

Can somebody tell me overall impressions/success stories of those 
systems?

I am thinking of buying this system as my next desktop for OpenBSD of
course, so please share.
Most interesting would be dmesgs of some working configurations.
Thanks a lot in advance
--
With best regards,
  Gregory Edigarov


I have a Ryzen 3 3200G sitting on an ASRock B450M-HDV R4.0 with 16GB 
RAM, and it seems to run OpenBSD (6.7) very well.  I added Window Maker 
via packages, along with a few others such as firefox-esr, pidgin, qgis, 
postgresql (both server and client), and a few others, again all from 
packages.  Bear in mind I usually use OpenBSD for network devices rather 
than on the desktop, but my experiment so far with the above system and 
config has been very positive -- very stable and responsive when booted 
into the graphical environment.  This machine has no wifi capability, so 
I cannot comment on that, and I do not have speakers attached, so cannot 
comment on sound support.


This CPU is a somewhat new-ish model with built-in Radeon Vega graphics 
which gave fits to several Linux distros*, but which seems to work right 
out of the box with OpenBSD 6.7.


*latest Debian, and latest Xubuntu experienced trouble on this machine 
when in graphical mode, though the latest regular Ubuntu does work 
nicely with this machine.


Good luck,

Joe

dmesg:
OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 14941401088 (14249MB)
avail mem = 14475939840 (13805MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe6cc0 (24 entries)
bios0: vendor American Megatrends Inc. version "P3.70" date 11/14/2019
bios0: ASRock B450M-HDV R4.0
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT MCFG AAFT HPET 
UEFI SSDT CRAT CDIT SSDT SSDT WSMT
acpi0: wakeup devices GPP0(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) 
GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) GP18(S4) GPP1(S4) PTXH(S4)

acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 3 3200G with Radeon Vega Graphics, 3593.83 MHz, 17-18-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
associative

cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: AMD Ryzen 3 3200G with Radeon Vega Graphics, 3593.21 MHz, 17-18-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
associative

cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: AMD Ryzen 3 3200G with Radeon Vega Graphics, 3593.21 MHz, 17-18-01
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 
64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully 
associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully 
associative

cpu2: smt 0, core 1, package 0
cpu3 a

Re: OpenBSD Readonly File System

2020-06-09 Thread Joe Barnett

On 2020-06-09 00:59, Vertigo Altair wrote:

Hi Misc,
I have a firewall device and I'm using OpenBSD on it. There is an
electricity problem where the device runs. Therefore, I have to run the
"fsck -y" command regularly at startup due to the electricity problem. 
To

overcome this, I want to use readonly file system.
 I know there are some projects like "resflash", but I want to do that
manually.


I have hacked and slashed my way to this kind of configuration for my 
firewall/gateway and a few other machines -- and with what appears to be 
good results.  Please understand this is almost certainly not supported 
by the project.  I have outlined this at the following URL:


https://www.mr72.com/readonlyfs.html

I hope this helps.  Any feedback will be greatly appreciated.

Good luck!

Joe


My partitions like this;

vertigo# df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/sd0a  3.9G489M3.2G13%/
/dev/sd0g 91.8G1.0G   86.2G 1%/mypartition
/dev/sd0d  989M   12.0K940M 0%/tmp
/dev/sd0f  3.9G1.7G2.0G46%/usr
/dev/sd0e  3.9G   46.9M3.6G 1%/var

I want to / and /usr as readonly, I updated /etc/fstab and I made / and
/usr readonly;

vertigo# cat /etc/fstab
ec347fefe8d05509.b none swap sw
ec347fefe8d05509.a / ffs ro 1 1
ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2
ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2
ec347fefe8d05509.f /usr ffs ro,wxallowed,nodev 1 2
ec347fefe8d05509.e /var ffs rw,nodev,nosuid 1 2


On startup following errors comming from /etc/rc; I think errors about
/etc/motd are not so important, but are the errors coming from 
/etc/tty*
can cause any problems? If my method is not correct, what is the best 
way

to do this?


OpenBSD/amd64 BOOTX64 3.50

boot>
booting hd0a:/bsd: 12957000+2753552+327712+0+708608
[807408+128+1024872+749630]=0x1271a18
entry point at 0x1001000
[ using 2583064 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights 
reserved.
Copyright (c) 1995-2020 OpenBSD. All rights reserved.  
https://www.OpenBSD.org


OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4151607296 (3959MB)
avail mem = 4013170688 (3827MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries)
bios0: vendor American Megatrends Inc. version "BAR3NA05" date 
07/23/2018

bios0: NF533 NF533
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT 
UEFI

acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4)
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) Celeron(R) CPU J1900 @ 1.99GHz, 2000.37 MHz, 06-37-09
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-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 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.03 MHz, 06-37-09
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG

Re: relayd + httpd + Django/Rails?

2020-04-23 Thread Joe Ansbach
Now I feel dumb. Didn't need relayd at all - just the "fastcgi" option inside a 
httpd server block.

Jesus christ.


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday 23. April 2020 kl. 04:17, Joe Ansbach 
 wrote:

> Hi,
>
> I got this VPS here where I'm hosting a bunch of static sites for friends and 
> family with httpd (Let's Encrypt). Now, however, I've agreed to host a bunch 
> of Django (Unicorn) and Rails (Puma) apps as well, and I'm starting to think 
> maybe I've bitten off more than I can chew.
>
> Am I on the right path here? Would anybody mind giving me a nudge in the 
> right direction?
>
>  ++--+-+--+
> Internet | pf | relayd   | httpd   | staticsite1.com:8000 |
>  |    | (80/443) | | staticsite2.com:8000 |
>  |    |  | | staticsite3.com:8000 |
>  |    |  | | staticsite4.com:8000 |
>  |    |  | +--+
>  |    |  | Unicorn | djangoapp1.com:7001  |
>  |    |  | | djangoapp2.com:7002  |
>  |    |  | +--+
>  |    |  | Puma    | railsapp1.com:6001   |
>  |    |  | | railsapp2.com:6002   |
>  ++--+-+--+
>
> -
>
> /etc/pf.conf
>
> =
>
> pass in on $ext_if inet proto tcp from any to $ext_if port { 80, 443 } keep 
> state
>
> 
>
> /etc/relayd.conf
>
> =
>
> my_ip="127.0.0.1"
> relayd_port="80"
>
> table  { $my_ip }
> table  { $my_ip }
> table  { $my_ip }
>
> http protocol "httpfilter" {
>   tcp { nodelay, sack, backlog 128 }
>
>   return error
>
>   match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
>   match header set "X-Forwarded-For" value "$REMOTE_ADDR"
>   match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
> }
>
> relay "reverseproxy" {
>   listen on $my_ip port $relayd_port
>
>   protocol "httpfilter"
>
>   forward to  port 8000
> forward to  port 7001
> forward to  port 7002
> forward to  port 6001
> forward to  port 6002
>
> }
>
> --
>
> /etc/httpd.conf
>
> 
>
> server "staticsite1.com" {
>   listen on * port 8000
>   root "/htdocs/staticsite1.com"
>   [...]
> }
>
> server "staticsite1.com" {
>   listen on * tls port 443
>   root "/htdocs/staticsite1.com"
>   [...]
> }
>
> [...]
>
> -
>
> Thanks, Joe




relayd + httpd + Django/Rails?

2020-04-22 Thread Joe Ansbach
Hi,

I got this VPS here where I'm hosting a bunch of static sites for friends and 
family with httpd (Let's Encrypt). Now, however, I've agreed to host a bunch of 
Django (Unicorn) and Rails (Puma) apps as well, and I'm starting to think maybe 
I've bitten off more than I can chew.

Am I on the right path here? Would anybody mind giving me a nudge in the right 
direction?

 ++--+-+--+
Internet | pf | relayd   | httpd   | staticsite1.com:8000 |
 |    | (80/443) | | staticsite2.com:8000 |
 |    |  | | staticsite3.com:8000 |
 |    |  | | staticsite4.com:8000 |
 |    |  | +--+
 |    |  | Unicorn | djangoapp1.com:7001  |
 |    |  | | djangoapp2.com:7002  |
 |    |  | +--+
 |    |  | Puma    | railsapp1.com:6001   |
 |    |  | | railsapp2.com:6002   |
 ++--+-+--+

--

# /etc/pf.conf

pass in on $ext_if inet proto tcp from any to $ext_if port { 80, 443 } keep 
state

--

# /etc/relayd.conf

my_ip="127.0.0.1"
relayd_port="80"

table  { $my_ip }
table  { $my_ip }
table  { $my_ip }

http protocol "httpfilter" {
  tcp { nodelay, sack, backlog 128 }

  return error

  match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
  match header set "X-Forwarded-For" value "$REMOTE_ADDR"
  match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
}

relay "reverseproxy" {
  listen on $my_ip port $relayd_port

  protocol "httpfilter"

  forward to  port 8000
  forward to  port 7001
  forward to  port 7002
  forward to  port 6001
  forward to  port 6002
}

--

# /etc/httpd.conf

server "staticsite1.com" {
  listen on * port 8000
  root "/htdocs/staticsite1.com"
  [...]
}

server "staticsite1.com" {
  listen on * tls port 443
  root "/htdocs/staticsite1.com"
  [...]
}

[...]

--

Thanks, Joe



Re: MITM ?

2020-03-25 Thread Joe Davis
> > What is your opinion ?
> > could be a MITM from my router and a kernel 0day on the tcp/ip stack 
> > implementation ?
> > could be MITMed pkg_add ?
> > the encryption algorithm (AES_128_GCM) behind https is really secure ?
> > Can some code be injected in an encrypted stream ?

An internet connection might not suit your use case. Have you considered
a self imposed air-gap?



amdgpu, Polaris and Firefox

2020-01-25 Thread Joe Gidi
I'm running the latest amd64 snapshot (kernel #619) on a system with a
Radeon RX 550 (Polaris) GPU. glxgears and glxinfo show that OpenGL is
working and Xorg.0.log shows no errors.

When I try to enable OpenGL in Firefox by setting
layers.acceleration.force-enable to true, I see the following errors on
the terminal and https://get.webgl.org reports that WebGL is disabled or
unavailable.

libGL error: MESA-LOADER: failed to open radeonsi (search paths
/usr/X11R6/lib/modules/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths
/usr/X11R6/lib/modules/dri)
libGL error: failed to load driver: swrast
libGL error: MESA-LOADER: failed to open radeonsi (search paths
/usr/X11R6/lib/modules/dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast (search paths
/usr/X11R6/lib/modules/dri)
libGL error: failed to load driver: swrast

And:

Crash Annotation GraphicsCriticalError: |[G0][GFX1-]: [OPENGL] Failed to
init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT
(t=0.34852) [GFX1-]: [OPENGL] Failed to init compositor with reason:
FEATURE_FAILURE_OPENGL_CREATE_CONTEXT
Crash Annotation GraphicsCriticalError: |[G0][GFX1-]: [OPENGL] Failed to
init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT
(t=0.34852) |[G1][GFX1-]: [OPENGL] Failed to init compositor with reason:
FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=0.802629) [GFX1-]: [OPENGL]
Failed to init compositor with reason:
FEATURE_FAILURE_OPENGL_CREATE_CONTEXT
Crash Annotation GraphicsCriticalError: |[G0][GFX1-]: [OPENGL] Failed to
init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT
(t=0.34852) |[G1][GFX1-]: [OPENGL] Failed to init compositor with reason:
FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=0.802629) |[G2][GFX1-]: [OPENGL]
Failed to init compositor with reason:
FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=1.3604) [GFX1-]: [OPENGL] Failed
to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT

Is this already known to be broken, or should I file a full bug report?

Thanks,

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: OpenBSD's extremely poor network/disk performance?

2020-01-08 Thread Joe Greco
On Wed, Jan 08, 2020 at 05:57:37PM +0300, Hamd wrote:
> Under less than 24 hours, after my post, the misc has received 2 or 3 brand
> new questions/posts regarding slow*.

Well, in the case of my issue, I am reasonably certain that this isn't 
an issue with LibreSSL.  I raised it as an issue of simply not knowing
how to get it to do what I need at the speeds it is clearly capable
of, on i386.  It works fine and at approximately OpenSSL speeds on 
amd64.

> The problem is, well, obviously not me, personally.

I beg to differ.

Your repurposing my question for your own ends in an attempt to 
categorize it as an general OpenBSD performance issue is, in my
opinion, full of **it. 

This is not helpful to those of us who are asking legitimate
questions of those who are more familiar with these projects.
I know I've made a dumb mistake of some sort and I was hoping
someone would point it out.

If you do not like the product, don't use it.  Or submit a patch
to fix it.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov



Re: LibreSSL performance issue

2020-01-07 Thread Joe Greco
On Tue, Jan 07, 2020 at 11:06:38AM -0800, Jordan Geoghegan wrote:
> Is there a specific reason you're running i386 instead of amd64? 

Yes, i386 generates substantially smaller images than amd64.

In an environment where you are constrained to the existing available
virtualization capacity and are tasked with making the most of that,
there is no obvious reason why you would build infrastructure devices 
such as a DHCP server using amd64.

We also have a supply of embedded Soekris systems which only run the
i386.

> And why are you testing this on FreeBSD? Wrong mailing list

Probably not.  LibreSSL is intended to be portable, and the LibreSSL 
web site points back to the OpenBSD mailing lists:

https://www.libressl.org/mail.html

"See https://www.openbsd.org/mail.html for more details on posting or
subscribing."

So now over at https://www.openbsd.org/mail.html ...

I would think libre...@openbsd.org would seem the obvious choice of
list.  However, it is listed under

"Developer lists
These lists are for technical discussions of aspects of OpenBSD. They are
NOT for beginners or average users, they are not for problem reporting
(unless you are including a good fix) and they are not for installation
problems. If you have any question about if a message should be posted to
any of these lists, it probably should not. Use misc instead."

So according to the guidelines on the website, my issue didn't fit
libre...@openbsd.org, and there is an instruction to use misc instead.

Besides, it came up as a reply to a message posted on misc.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov



Re: LibreSSL performance issue

2020-01-07 Thread Joe Greco
On Tue, Jan 07, 2020 at 07:50:37PM +0100, Bodie wrote:
> On 7.1.2020 17:26, Joe Greco wrote:
> >On Tue, Jan 07, 2020 at 09:33:46AM -0600, Edgar Pettijohn wrote:
> >>> In reality, when you dig down, often you find that there's another
> >>> reason for the issue.?? I was recently trying to substitute libressl
> >>> into an openssl environment.?? Performance tanked.?? Some checking
> >>> showed the speed of "speed -evp aes-256-gcm" was way off.?? It looked
> >>> to me like it was an issue with not using AES-NI.?? I'm not going to
> >>> blame libressl for that, I just lacked the time to do a deep dive on
> >>> it to figure out what was (hopefully!) configured wrong.?? Probably
> >>> something with ia32cap or whatever the libressl equivalent is.
> >>>
> >>> ... JG
> >>
> >>I believe it has something to do with actually zeroing out memory
> >>before freeing it. Which seems like a good thing to do for crypto
> >>stuff.
> >
> >My apologies.  I posted an insufficient description of the issue as it
> >was intended as an argument refuting the OP.  If we want to discuss my
> >issue, that's fine and I welcome the input.  I normally manage to
> >resolve these things eventually but this stumped me a bit.
> > [...]
> >Now in the third run, calling the host system's OpenSSL but twiddling
> >ia32cap, I get numbers that are very similar to the LibreSSL numbers
> >showing a similar catastrophic performance reduction.  My conclusion
> >is that this is somehow an AES-NI detection issue.  For whatever 
> >reason,
> >FreeBSD's openssl gets it right by default.
> >
> >And the fourth run was "just to see."
> 
> Just WOW
> 
> So you start with blaming OpenBSD for poor performance and then as a 
> "prove"
> you show tests of completely different OS on completely different 
> filesystem
> on God knows which hypervisor and then throw in the mix amd64 vs i386?
> 
> I think Phoronix will hire you ;-)


I did no such thing.  I used a problem I encountered as an example of
how the original poster's implication isn't true.

I did say "I'm not going to blame libressl".

And if anything, if you read for comprehension, I defended OpenBSD.

But now I kinda remember why I participate so rarely on these lists.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov



LibreSSL performance issue (was: Re: OpenBSD's extremely poor network/disk performance?)

2020-01-07 Thread Joe Greco
date unspecified
options:bn(64,32) rc4(8x,mmx) des(long) aes(partial) idea(int) blowfish(ptr) 
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-256-gcm 170523.24k   458955.48k   727327.49k   860676.97k   911040.96k  
 911457.03k

# OPENSSL_ia32cap="+0x202" openssl speed -evp aes-256-gcm
Doing aes-256-gcm for 3s on 16 size blocks: 8813067 aes-256-gcm's in 2.99s
Doing aes-256-gcm for 3s on 64 size blocks: 2483967 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 256 size blocks: 630526 aes-256-gcm's in 3.02s
Doing aes-256-gcm for 3s on 1024 size blocks: 160181 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 8192 size blocks: 20112 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 16384 size blocks: 9988 aes-256-gcm's in 3.01s
OpenSSL 1.1.1d-freebsd  10 Sep 2019
built on: reproducible build, date unspecified
options:bn(64,32) rc4(4x,int) des(long) aes(partial) idea(int) blowfish(ptr) 
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-256-gcm  47125.75k52853.66k53526.10k54533.10k54776.52k  
  54406.11k

# OPENSSL_ia32cap="~0x202" libressl-3.0.2/apps/openssl/openssl spee 
-evp aes-256-gcm
d
WARNING: can't open config file: /usr/local/etc/ssl/openssl.cnf
Doing aes-256-gcm for 3s on 16 size blocks: 9048488 aes-256-gcm's in 2.99s
Doing aes-256-gcm for 3s on 64 size blocks: 2416620 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 256 size blocks: 583915 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 1024 size blocks: 151550 aes-256-gcm's in 3.01s
Doing aes-256-gcm for 3s on 8192 size blocks: 19287 aes-256-gcm's in 3.00s
LibreSSL 3.0.2
built on: date not available
options:bn(64,32) rc4(ptr,int) des(idx,cisc,16,long) aes(partial) idea(int) 
blowfish(idx) 
compiler: information not available
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes
aes-256-gcm  48365.46k51406.29k49682.09k51580.05k52638.66k
--End-FreeBSD-12.1R-i386

So the first run, with LibreSSL, the performance has fallen off
catastrophically.

The next run, calling the host system's shipped OpenSSL, the numbers
return to reasonable, although they are somewhat slower than the amd64
runs.  That's fine.

Now in the third run, calling the host system's OpenSSL but twiddling
ia32cap, I get numbers that are very similar to the LibreSSL numbers
showing a similar catastrophic performance reduction.  My conclusion
is that this is somehow an AES-NI detection issue.  For whatever reason,
FreeBSD's openssl gets it right by default.

And the fourth run was "just to see."

After some more puttering around with it, that's where I got stuck, and
I eventually set it aside as it wasn't a pressing issue.  If anyone has 
any insight into this, feel free to tell me what I've done wrong.  I'm
sure this is simply a configuration thing.

Thanks,

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov



Re: OpenBSD's extremely poor network/disk performance?

2020-01-07 Thread Joe Greco
On Tue, Jan 07, 2020 at 02:47:02PM +, cho...@jtan.com wrote:
> Hamd writes:
> > It's 2020 and it's -still- sad to see OpenBSD -still- has the
> > ... lists full of the uninteresting type of wine and that their
> > twitterings -still- don't include any code.
> 
> Yes. Yes it is.
> 
> Can't say much for the performance of a suite of servers which have
> all been taken down to handle the security threat du jour.

Well, that's kind of ridiculous, that's not generally how threats are
remediated in the real world.

If you take a server down for 15 minutes to apply patches to Insecure-
But-ZippyBSD, once a week, you get 99.85% uptime and presumably it is
performing lots faster during that 99.85%, but admittedly performs at 
zero during the patch process.  Redundancy can cover that in many
cases.

A different argument could be that if you require a particular level of
performance, and you have to deploy more compute resources to get it,
that increases capex and opex, and the end result is a greater level of
e-waste down the road, and perhaps a greater amount of pollution if the
power is generated from "bad" sources.

In reality, when you dig down, often you find that there's another
reason for the issue.  I was recently trying to substitute libressl
into an openssl environment.  Performance tanked.  Some checking
showed the speed of "speed -evp aes-256-gcm" was way off.  It looked 
to me like it was an issue with not using AES-NI.  I'm not going to
blame libressl for that, I just lacked the time to do a deep dive on
it to figure out what was (hopefully!) configured wrong.  Probably
something with ia32cap or whatever the libressl equivalent is.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov



Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230

2019-11-16 Thread Joe Davis
This may come across as a strange question, but is the microphone
disabled in the BIOS? The azalia driver has(had?) some issues with that
before. 

Cheers,
Joe



Re: no keyboard on (I)nstall

2019-11-12 Thread Joe Davis
On Tue, Nov 12, 2019 at 10:12:13AM +0100, Emanuel Berg wrote:
> CPU type AMD Athlon 64 X2 Dual Core Processor 3800+
> 
> Re: BIOS USB options... "USB Legacy Mode
> Support" set to "Auto".
> 
> No BIOS USB speed settings what I can see.
> 
> -- 
> underground experts united
> http://user.it.uu.se/~embe8573
> https://dataswamp.org/~incal
> 

Does the USB keyboard have a USB hub on it, by any chance? 



Re: Tools for writers

2019-11-07 Thread Joe Davis
> Some writers swear on Scrivener. It's proprietary and Mac/Win only, though.

Manuskript[1] looks promising as a foss alternative. Haven't attempted
to build it on OpenBSD. None of the dependencies look to be a major
problem.

Cheers,
Joe

[1]: http://www.theologeek.ch/manuskript/



How to dock laptop more easily

2019-10-13 Thread Joe Nelson
I'd like to write a daemon to change machdep.lidaction and the xrandr output as
an external monitor or power is attached/detached from my laptop. Is there a
way to detect those events from a C program?

Here is how I want the sleep state and output display to change based on
whether power is connected, an external monitor is attached, and the laptop is
open:

PowerMon  Open| SleepDisplay
--+--
xxx   | awakeboth
xx| awakeexternal
x x   | awakelaptop
x | asleep
 xx   | awakeboth
 x| asleep
  x   | awakelaptop
  | asleep

-- 
Joe Nelson  https://begriffs.com



Re: Alix 2d13 and OpenBSD 6.5 Problems

2019-10-02 Thread Joe Barnett

On 2019-10-01 22:46, Sean Kamath wrote:

Hi.

I’m hoping someone either has a cluebat or some helpful suggestions
beyond “reinstall”.

I had an alix 2d13 running OpenBSD 6.3.  I finally got around to
upgrading to 6.4 (via https://www.openbsd.org/faq/upgrade64.html), and
that seemed to go just fine (I used the Upgrading Manually section,
since I don’t have (easy) access to the console).

I let that run for a day, just to make sure all was well, and then
attempted an upgrade to 6.5 (via
https://www.openbsd.org/faq/upgrade65.html), again using the
“Upgrading Manually” section.

This time, between smtpd and relinking the kernel, it appears my Alix
board is quickly running out of memory.  Within a few seconds the sr
rate is in the 20K range.  I stopped the ld for relinking, and killed
SMTPD in order to finish the install (the makedev ALL, sysmerge,
pkg_update -u bits), and that all ran fine.  But about 15-20 minutes
after a reboot, the box just goes off the network, and there’s not
much I can do.

I can download and reinstall 6.5, but was hoping to avoid that pain,
but I just want to make sure 6.5 has no issues on the Alix boards. . .


I cannot comment on the upgrade process, but I have had zero fatal 
issues running 6.5 on my alix2d13 boards.  That said, memory has been 
getting tighter with more recent OpenBSD versions, and swap (as someone 
else suggested) should help.  I love these reliable boards, but they are 
starting to show their age (at least relative to how I use them with 
OpenBSD).




Thanks!  I’d attach dmesg, but the box is dead again. . .  If anyone
wants to dive into what’s going on, just let me know what info you
want to see.

Sean




Re: arm on Tinker Board (rk3288) - currently broken?

2019-09-29 Thread Joe Gidi
> On Fri, Sep 27, 2019 at 08:01:53PM -0400, Joe Gidi wrote:
>> Hello,
>>
>> I've seen a number of recent commits for the rk3288 SoC, so I dug out my
>> Tinker Board and tried to install the latest snapshot (miniroot dated
>> 27-Sep-2019 06:14).
>>
>> I followed the updated directions for this chip:
>>
>>   For systems based on Rockchip RK3288 SoCs:
>>
>>  dd if=/usr/local/share/u-boot/board/idbloader.img \
>>  of=/dev/sdXc seek=64
>>  dd if=/usr/local/share/u-boot/board/u-boot.img \
>>  of=/dev/sdXc seek=16384
>>
>> Unfortunately, when I try to boot, I get:
>>
>> rying to boot from BOOTROM
>> Returning to boot ROM...
>>
>> U-Boot SPL 2019.07 (Sep 25 2019 - 20:12:08 -0600)
>> Trying to boot from MMC1
>> spl: mmc init failed with error: -110
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
>>
>> Is this currently known to be broken, or am I doing something wrong?
>
> tinker-rk3288 was broken in U-Boot 2019.07.  I have just committed an
> update to U-Boot 2019.10-rc4 which corrects this.  Either build
> u-boot-arm from ports or wait till updated packages appear.

Following up to confirm that the updated U-Boot works. I was able to
install and run the latest snap with no issues. Thanks!


-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



arm on Tinker Board (rk3288) - currently broken?

2019-09-27 Thread Joe Gidi
Hello,

I've seen a number of recent commits for the rk3288 SoC, so I dug out my
Tinker Board and tried to install the latest snapshot (miniroot dated
27-Sep-2019 06:14).

I followed the updated directions for this chip:

  For systems based on Rockchip RK3288 SoCs:

dd if=/usr/local/share/u-boot/board/idbloader.img \
of=/dev/sdXc seek=64
dd if=/usr/local/share/u-boot/board/u-boot.img \
of=/dev/sdXc seek=16384

Unfortunately, when I try to boot, I get:

rying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.07 (Sep 25 2019 - 20:12:08 -0600)
Trying to boot from MMC1
spl: mmc init failed with error: -110
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Is this currently known to be broken, or am I doing something wrong?

Thanks,

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



unbound/dns issue (malformed packets?)

2019-09-15 Thread Joe Barnett
, the 
machines are otherwise configured exactly the same.  The APU2 has been 
consistently maintained, and this behavior did start soon after I 
applied the libexpat update via syspatch.  The ALIX machine, however, 
has not been patched (meaning it contains 6.5 as it was at release).  I 
do not know much about the inner workings of DNS, and thinking that, 
perhaps, the packets contain XML and that the recent libexpat update is 
causing issues, I backed the update out of the APU2, but still get the 
same results.  Similarly, swapping the (non-updated) ALIX in place of 
the APU2 results in the same behavior.


Please forgive my verbosity, but I figured more info is probably better 
than less.  My knowledge of DNS and other network services is limited -- 
I hope I have explained this in a way that can be understood.


Thanks,

Joe



Re: dhcrelay

2019-08-30 Thread Joe Cook

Hi,

You will find the answer in the second paragraph of the description for 
the dhcrelay(8) manpage.


It's fantastic that we don't even need the internet to find the answer. 
Happy reading.


Joe

On 30/08/2019 8:21 AM, shadrock uhuru wrote:

hiya
thanks for the reply

hi eveyone
if i have a dhcp server in subnet A connected to interface em0 (lan) and
subnet B connected to interface iwn0 (wireless zone) on the router
with dhcrelay -i em0 running on the router should the wireless subnet be
able?? to get its dhcp address from the dhcp server on the lan ?
No, you would need to run

dhcrelay -i iwn0 

to do that.

finally got that sorted,
but led me to another question
i have two dhcp servers on samba domain controllers,
can a second server-ip address be added like this to dhcrelay

dhcrelay -i iwn0  

i haven't seen any examples like this on the net
shadrock





Re: SAD ( pkg_add does linux like stuff ie: not working, no explanation )

2019-08-28 Thread Joe Gidi


> Maybe obvious ? if so why no message from the software ?
>
> [0]-[web]-[/var/www/logs]
> # pkg_add php_curl
> quirks-3.124 signed on 2019-04-15T12:10:16Z
> Can't find php_curl
> [0]-[web]-[/var/www/logs]
> # cat /etc/installurl
> http://cdn.openbsd.org/pub/OpenBSD
>
> But
>
> [0]-[web]-[/var/www/logs]
> # curl --head
> https://cdn.openbsd.org/pub/OpenBSD/6.5/packages/amd64/php-curl-7.2.17.tgz
> HTTP/2 200
> server: nginx
> content-type: application/octet-stream
> last-modified: Mon, 15 Apr 2019 12:09:10 GMT
> etag: "5cb47466-8e35"
> backend-name: 5GnZ0LBU5CzDw9NCjFbkjI--F_ftp_hostserver_de
> accept-ranges: bytes
> date: Wed, 28 Aug 2019 14:01:52 GMT
> via: 1.1 varnish
> age: 0
> x-served-by: cache-cdg20753-CDG
> x-cache: MISS
> x-cache-hits: 0
> x-timer: S1567000912.203130,VS0,VE54
> content-length: 36405
> [0]-[web]-[/var/www/logs]
> # date
> Wed Aug 28 04:07:24 CEST 2019
>
> LIKE WHY PLEASE ?

Maybe because underscores (_) are not the same as dashes (-)?


-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: openrsync out of memory

2019-08-16 Thread Joe Davis
By the looks of it, openrsync does attempt to map the entire file, from
usr.bin/rsync/uploader.c:

mapsz = st.st_size;
map = mmap(NULL, mapsz, PROT_READ, MAP_SHARED, *fileinfd, 0);

The likely reason for your out of memory error is the default datasize
in login.conf. IIRC on some arches it's set to 768MB by default, which
would allow your 300MB file to transfer, but would cause mmap to fail
upon attempting to map the 1.6GB one.

Increasing the default limits in /etc/login.conf should fix the problem.

Note that rsync (not openrsync), doesn't use mmap for other reasons,
from rsync-3.1.3/fileio.c:

/* This provides functionality somewhat similar to mmap() but using read().
 * It gives sliding window access to a file.  mmap() is not used because of
 * the possibility of another program (such as a mailer) truncating the
 * file thus giving us a SIGBUS. */

Cheers,
Joe



Re: Multiple video cards in X?

2019-06-28 Thread Joe M
Hello,

I have multiple video cards (AMD Radeon) cards working with OpenBSD. I
have 2 monitors connected to each card (HDMI and DVI ports).

The issues are that I can use only fvwm and I cannot move x windows
across the video cards. I can move x windows across monitors connected
to the same video card though.

I tried to hack around the Xenocara codebase to figure out if I can
fix it. During my adventures, I realized that though Xenocara can be
modified to support this, the issue is in the radeon driver
(radeondrm, I think). At that point, I gave up as I did not have the
bandwidth to figure out how radeondrm works.

It took me quite a lot of time to figure out the correct
configuration. I was hoping that I could get cwm to work. But, I could
not. Only fvwm works. I did not bother to dig through why.

joe:10114$ cat /etc/X11/xorg.conf

# get the xorg.conf.firstcard and xorg.conf.secondcard to work
# startx # uses xorg.conf
# cd /etc/X11; start -- :1 -config xorg.conf.secondcard # to get the
second card working
# once both of them work, below is bringing them together to show all
monitors at the same time

# leave out the monitor sections as the X fills up the holes

Section "ServerLayout"
Identifier "Default Layout"
Screen 0 "Screen 0"
Screen 1 "Screen 1" RightOf "Screen 0"
EndSection

Section "Screen"
Identifier "Screen 0"
Device "Card 0"
EndSection

Section "Device"
Identifier "Card 0"
Driver "radeon"
BusID "PCI:1:0:0"
#Option "Monitor-HDMI-0" "HG281D"
Option "Monitor-DVI-0" "AL2223W"
EndSection

Section "Monitor"
Identifier "AL2223W"
Option "LeftOf" "HDMI-0"
EndSection

Section "Screen"
Identifier "Screen 1"
Device "Card 1"
EndSection

Section "Device"
Identifier "Card 1"
Driver "radeon"
BusID "PCI:11:0:0"
EndSection

joe:10131$ tail -5 /home/j/.xsession

# cwm cannot spawn multiple cards
# exec /usr/X11R6/bin/cwm
exec fvwm

Hope it helps.

On Thu, Jun 27, 2019 at 12:38 PM Nick Holland
 wrote:
>
> Hiya.
>
> Before I spend a lot of time on what might be impossible, is it likely I
> could succeed at getting multiple multi-head video cards working on
> OpenBSD (amd64, radeon cards)?
>
> I've got this in the machine:
> OpenBSD 6.5-current (GENERIC.MP) #2: Sun Jun  2 00:29:17 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> ppb2 at pci0 dev 3 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci3 at ppb2 bus 3
> radeondrm0 at pci3 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00
> drm0 at radeondrm0
> radeondrm0: msi
> ppb3 at pci0 dev 7 function 0 "Intel X58 PCIE" rev 0x22: msi
> pci4 at ppb3 bus 4
> radeondrm1 at pci4 dev 0 function 0 "ATI Radeon HD 3450" rev 0x00
> drm1 at radeondrm1
> radeondrm1: msi
> ...
>
> so I got a pair of cards recognized.  Two monitors on one card Just Work
> with X with no xorg.conf file.  xrandr sees the config and seems to
> work, driving the monitors at full resolution.
>
> But the other card is ... idle.
>
> Is it possible to use my other monitors in X on OpenBSD?  Any Broad
> General Tips in doing so?  Man pages to read?  Authoritative tips,
> including "Don't be an idiot, it's easy" to "it's not possible"?
>
> To save 45k per copy of this message, links to dmesg and xorg log:
>
>  http://nickh.org/Xorg.0.log.txt
>  http://nickh.org/dmesg.txt
>
> Nick.
>



Re: Haskell compilation issues

2019-05-19 Thread Joe Nelson
Matthias Kilian wrote:
> I've a really smart solution for the problem: I'll never ever even try
> to give some helpful answer to any of the mails on misc@

Sorry, my message must have sounded snarky. I didn't intend it that
way. Honestly just wanted to help you with your email setup. It can be
complicated, and I've only recently learned about some of this stuff
myself.

Maybe I should have replied off-list originally, but thought the mail
header tip might be useful for other people as well.



Re: Haskell compilation issues

2019-05-18 Thread Joe Nelson
Matthias Kilian wrote:
> ps: please note that I'm not subscribed to misc@ with my 'real'
> mail account, only with a crappy gmail account I'm only reading on
> my tablet (from which I forwarded your mail to my real address). So
> better cc' me if you've any other questions ;-)

FYI, the way you replied to the original message broke the reply chain
in my mail reader (Mutt). You should include an "In-Reply-To" message
header that references the Message-ID of the mail to which you are
replying. I know it might be a little tricky from your tablet setup, but
wanted to bring it to your attention if you weren't aware.

In your particular case it would have been:

In-Reply-To: 




Re: Haskell compilation issues

2019-05-18 Thread Joe Nelson
Omar Polo wrote:
> What I think it's required to compile and run haskell program is to
> wxallow the partition. If you're using the standard layout the /tmp
> and /home should be wxallowed.

Yep, GHC creates binaries with W^X violations. The GHC developers are
working on this problem in [0], but for now Haskell binaries have to be
run from a filesystem mounted as wxallowed.

0: https://gitlab.haskell.org/ghc/ghc/issues/14069



_XSERVTransSocketUNIXAccept: accept() failed

2019-05-14 Thread Joe M
Hello,

These messages are filling up the Xorg.0.log and xenodm.log to
gigabytes and does not allow additional xterm windows to open.

I see these messages in /var/log/Xorg.0.log

joe:10424$ tail Xorg.0.log
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.045] _XSERVTransSocketUNIXAccept: accept() failed


joe:10425$ tail /var/log/xenodm.log
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed

Thanks to #openbsd's epony and oldlaptop, the resolution is to:

1. increase daemon openfiles-max to 2048 and openfiles-cur to 1024 in
/etc/login.conf
2. cap_mkdb /etc/login.conf
3. re-login.

Thanks



Re: Criteria for errata

2019-05-10 Thread Joe M
> > > That's how I understood the bug too, but when I enabled a debug build of 
> > > xenocara and examined the core dump after a crash, I had the same 
> > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug 
> > > report.
> >
> > I dont know much about xenocara, but i think that including dmesg and
> > maybe /var/log/Xorg.0.log output in your mail can't hurt.
> >
>
> I already have a bug report sent to bugs@
>
> https://marc.info/?l=openbsd-bugs=155716824903439=2
>

A few weeks ago, I was told that this fix was added to -current. I
cannot find the email now though.



Patch for X crash on 6.4 and 6.5

2019-04-26 Thread Joe M
Hello,

I had this same issue with 6.4 and 6.5. Applying this patch has fixed
the issue. I am using 2 radeon gpu's.

https://patchwork.freedesktop.org/series/28284/

This is the gdb backtrace of the crashed core file.

joe:10201$ d gdb /usr/X11R6/bin/X Xorg.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.5"...
Core was generated by `Xorg'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.26.1...done.
Loaded symbols for /usr/lib/libpthread.so.26.1
Loaded symbols for /usr/X11R6/bin/X
Symbols already loaded for /usr/lib/libpthread.so.26.1
Reading symbols from /usr/X11R6/lib/libpciaccess.so.2.0...done.
Loaded symbols for /usr/X11R6/lib/libpciaccess.so.2.0
Reading symbols from /usr/X11R6/lib/libdrm.so.7.6...done.
Loaded symbols for /usr/X11R6/lib/libdrm.so.7.6
Reading symbols from /usr/X11R6/lib/libpixman-1.so.36.0...done.
Loaded symbols for /usr/X11R6/lib/libpixman-1.so.36.0
Reading symbols from /usr/X11R6/lib/libXfont2.so.1.0...done.
Loaded symbols for /usr/X11R6/lib/libXfont2.so.1.0
Reading symbols from /usr/X11R6/lib/libfontenc.so.4.0...done.
Loaded symbols for /usr/X11R6/lib/libfontenc.so.4.0
Reading symbols from /usr/X11R6/lib/libfreetype.so.29.0...done.
Loaded symbols for /usr/X11R6/lib/libfreetype.so.29.0
Reading symbols from /usr/lib/libz.so.5.0...done.
Loaded symbols for /usr/lib/libz.so.5.0
Reading symbols from /usr/X11R6/lib/libXau.so.10.0...done.
Loaded symbols for /usr/X11R6/lib/libXau.so.10.0
Reading symbols from /usr/X11R6/lib/libxshmfence.so.0.0...done.
Loaded symbols for /usr/X11R6/lib/libxshmfence.so.0.0
Reading symbols from /usr/X11R6/lib/libXdmcp.so.11.0...done.
Loaded symbols for /usr/X11R6/lib/libXdmcp.so.11.0
Reading symbols from /usr/lib/libkvm.so.17.0...done.
Loaded symbols for /usr/lib/libkvm.so.17.0
Reading symbols from /usr/lib/libm.so.10.1...done.
Loaded symbols for /usr/lib/libm.so.10.1
Reading symbols from /usr/lib/libc.so.95.0...done.
Loaded symbols for /usr/lib/libc.so.95.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
Reading symbols from /usr/X11R6/lib/modules/extensions/libglx.so...done.
Loaded symbols for /usr/X11R6/lib/modules/extensions/libglx.so
Reading symbols from /usr/X11R6/lib/libGL.so.17.1...done.
Loaded symbols for /usr/X11R6/lib/libGL.so.17.1
Reading symbols from /usr/lib/libexpat.so.12.0...done.
Loaded symbols for /usr/lib/libexpat.so.12.0
Reading symbols from /usr/X11R6/lib/libxcb-dri3.so.0.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb-dri3.so.0.1
Reading symbols from /usr/X11R6/lib/libxcb-xfixes.so.1.2...done.
Loaded symbols for /usr/X11R6/lib/libxcb-xfixes.so.1.2
Reading symbols from /usr/X11R6/lib/libxcb-present.so.0.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb-present.so.0.1
Reading symbols from /usr/X11R6/lib/libxcb-sync.so.1.2...done.
Loaded symbols for /usr/X11R6/lib/libxcb-sync.so.1.2
Reading symbols from /usr/X11R6/lib/libglapi.so.0.2...done.
Loaded symbols for /usr/X11R6/lib/libglapi.so.0.2
Reading symbols from /usr/X11R6/lib/libXdamage.so.4.0...done.
Loaded symbols for /usr/X11R6/lib/libXdamage.so.4.0
Reading symbols from /usr/X11R6/lib/libXfixes.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXfixes.so.6.0
Reading symbols from /usr/X11R6/lib/libX11-xcb.so.2.0...done.
Loaded symbols for /usr/X11R6/lib/libX11-xcb.so.2.0
Reading symbols from /usr/X11R6/lib/libxcb-glx.so.1.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb-glx.so.1.1
Reading symbols from /usr/X11R6/lib/libxcb-dri2.so.1.1...done.
Loaded symbols for /usr/X11R6/lib/libxcb-dri2.so.1.1
Reading symbols from /usr/X11R6/lib/libXxf86vm.so.6.0...done.
Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.6.0
Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.13.0
Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.16.1
Reading symbols from /usr/X11R6/lib/libxcb.so.4.0...done.
Loaded symbols for /usr/X11R6/lib/libxcb.so.4.0
Reading symbols from /usr/X11R6/lib/modules/drivers/radeon_drv.so...done.
Loaded symbols for /usr/X11R6/lib/modules/drivers/radeon_drv.so
Reading symbols from /usr/X11R6/lib/libdrm_radeon.so.4.0...done.
Loaded symbols for /usr/X11R6/lib/libdrm_radeon.so.4.0
Reading symbols from /usr/X11R6/lib/libgbm.so.0.3...done.
Loaded symbols for /usr/X11R6/lib/libgbm.so.0.3
Reading symbols from /usr/X11R6/lib/modules/libfb.so...done.
Loaded symbols for /usr/X11R6/lib/modules/libfb.so
Reading symbols from /usr/X11R6/lib/modules/libexa.so...done.
Loaded symbols for /usr/X11R6/lib/modules/libexa.so
Reading symbols from /usr/X11

Re: clocksource tsc sometimes not available within debian vm on OpenBSD 6.4

2019-03-08 Thread Joe M
I have the same issue and have been using this driver. It sets the
correct time every 5 seconds. For this purpose, this solution is a
hack, but, I could not figure out a better solution.

https://github.com/voutilad/virtio_vmmci/issues/1

Also, I noticed that vm clock would be very slow. It loses 28 minutes
for every 30 minutes.

Another thing, watch out regarding tsc=unreliable kernel command line
option, the vm is getting unresponsive with it after an hour or so.



Re: HP OfficeJet 5610 Scanner

2019-02-17 Thread Joe M
> I have this exact model. Were you able to get printing to work?

I do not use it for printing anymore. So, never tried printing with it.



Re: HP OfficeJet 5610 Scanner

2019-02-14 Thread Joe M
It works fine after installing hplip.

For the next person trying this, these commands got it working:

doas pkg_add sane-backends hplip dbus
doas rcctl enable messagebus
doas rcctl start messagebus

scanimage should work fine now.

Thanks



Re: _XSERVTransSocketUNIXAccept: accept() failed

2019-02-14 Thread Joe M
> What were you trying to do when you got these messages?

This happens when I have a bunch of X apps (with windows) open and I
try open another xterm. It appears that there is some limit to the
number of X windows that can be opened. When I try to open another one
after that limit, I get these messages. I checked 'man login.conf' but
nothing seemed relevant. I am not sure if any sysctl values might be
responsible for this behaviour though.

Thanks



_XSERVTransSocketUNIXAccept: accept() failed

2019-02-13 Thread Joe M
Hello,

I see these messages in /var/log/Xorg.0.log

joe:10424$ tail Xorg.0.log
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.044] _XSERVTransSocketUNIXAccept: accept() failed
[2616181.045] _XSERVTransSocketUNIXAccept: accept() failed


joe:10425$ tail /var/log/xenodm.log
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed
_XSERVTransSocketUNIXAccept: accept() failed


Any suggestions on how to figure out why this is happening.

Thanks



Re: HP OfficeJet 5610 Scanner

2019-02-13 Thread Joe M
This is from dmesg

ulpt0 at uhub5 port 1 configuration 1 interface 1 "HP Officejet 5600
series" rev 2.00/1.00 addr 2
ulpt0: using bi-directional mode
ugen1 at uhub5 port 1 configuration 1 "HP Officejet 5600 series" rev
2.00/1.00 addr 2



HP OfficeJet 5610 Scanner

2019-02-13 Thread Joe M
Hello,

I have an HP OfficeJet 5610 All-In-One that worked fine with scanimage on linux.

On Openbsd, sane-find-scanner recognises the device but scanimage
--list-devices cannot find it. Just want to check if anyone has it
working on OpenBSD?

joe:10362$ d sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

could not fetch string descriptor: Input/output error
could not fetch string descriptor: Input/output error
found USB scanner (vendor=0x03f0 [HP], product=0x4f11 [Officejet 5600
series]) at libusb:005:002
found USB scanner (vendor=0x1b1c [Corsair Components, Inc.],
product=0x0c09 [H100i v2]) at libusb:006:003
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.
joe:10370$ d scanimage --list-devices
[bjnp] create_broadcast_socket: ERROR - bind socket to local address
failed - Can't assign requested address
[bjnp] create_broadcast_socket: ERROR - bind socket to local address
failed - Can't assign requested address
[bjnp] create_broadcast_socket: ERROR - bind socket to local address
failed - Can't assign requested address
[bjnp] create_broadcast_socket: ERROR - bind socket to local address
failed - Can't assign requested address
[bjnp] create_broadcast_socket: ERROR - bind socket to local address
failed - Can't assign requested address

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).

Thanks
Joe



Re: drm bug on Dell Inspiron 3721 (6.4release and 6.4 current)

2019-02-08 Thread Joe Davis
I had a similar issue when attempting to boot on an 2011 iMac with a
radeon card. I did track down the location of the bug, but I didn't get
around to reporting it.

As far as I can tell the problem is this line (243, in -current) in 
dev/pci/drm/radeon/radeon_bios.c, in the function radeon_read_bios:

#else
bios = (u8 *)ISA_HOLE_VADDR(0xc);
#endif

It makes the assumption that the system firmware has mapped the graphics
card ROM at 0xC. This works fine on most computers if legacy BIOS
compatiblity is enabled, but breaks on (U)EFI systems which have it 
disabled or unavailable. Apple hardware for instance, if booted in EFI
mode, don't map anything to 0xC and make no attempt to have legacy
BIOS compatibility unless specifically told to boot a legacy bootsector.

I worked around it on that iMac by doing an MBR installation rather than
EFI/GPT. On other hardware, I'd recommend going into your BIOS settings
and ensuring that Legacy BIOS/CSM compatibility is enabled, and it isn't
set to UEFI-only.

A robust fix would have the radeon_get_bios map the ROM into memory
itself instead of relying on the firmware to do it. This is how the
linux code (line 208) works.

Cheers,
Joe



Xorg crash every few days

2018-12-18 Thread Joe M
 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34904 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34905 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34906 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34907 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34908 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34909 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34910 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34911 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34912 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34913 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34914 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
#34915 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X
Segmentation fault (core dumped)

I am attaching my dmesg.

Please let me know if I can provide any more information.
Thanks
Joe
OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018

r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 21417054208 (20424MB)
avail mem = 20758691840 (19797MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb450 (77 entries)
bios0: vendor American Megatrends Inc. version "Ua9" date 03/06/2013
bios0: Gigabyte Technology Co., Ltd. Z68AP-D3
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT DMAR
acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
PXSX(S4) RP04(S4) [...]
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-2600 CPU @ 3.40GHz, 3410.55 MHz, 06-2a-07
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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07
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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07
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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07
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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,

Re: alpine linux under vm? freezes

2018-09-04 Thread Joe Davis
> so is there anything I could do to be able to use the console?

Try setting a lower baud rate in Alpine’s /etc/inittab.

(and in the linux kernel command line)

That’s how I worked around the same issue.

Regards,
Joe



Re: Error adding tunnel to mgre interface

2018-08-05 Thread Joe Cook




On 1/08/2018 7:52 p.m., j...@snoopy.net.nz wrote:

Hi,

I am trying to add a tunnel to an mgre interface.
I can't get past the following error.

$doas ifconfig mgre0 destroy
$doas ifconfig mgre0 create
$doas ifconfig mgre0 tunnel 192.0.2.1 192.0.2.1
ifconfig: SIOCSLIFPHYADDR: Invalid argument
$
$ifconfig mgre
mgre0: flags=8800 mtu 1476
    index 9 priority 0 llprio 3
    encap: vnetid none
    groups: mgre
    tunnel: (unset) ttl 64 nodf
$

This is on a default install with patches up to and including 014.
OpenBSD 6.3 GENERIC.MP#7 amd64

If anyone has had success setting up an mgre interface then I would 
appreciate a little advice.


Regards

Joe



I found the answer in an openbsd-cvs archive.
Ref. https://marc.info/?l=openbsd-cvs=151977078027087=2

Example command.
>$ doas ifconfig mgre0 tunneladdr 192.0.2.1

>$ ifconfig mgre
mgre0: flags=8800 mtu 1476
    index 24 priority 0 llprio 3
    encap: vnetid none
    groups: mgre
    tunnel: inet 192.0.2.1 ttl 64 nodf

Regards

Joe COok





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Error adding tunnel to mgre interface

2018-08-01 Thread joe

Hi,

I am trying to add a tunnel to an mgre interface.
I can't get past the following error.

$doas ifconfig mgre0 destroy
$doas ifconfig mgre0 create
$doas ifconfig mgre0 tunnel 192.0.2.1 192.0.2.1
ifconfig: SIOCSLIFPHYADDR: Invalid argument
$
$ifconfig mgre
mgre0: flags=8800 mtu 1476
index 9 priority 0 llprio 3
encap: vnetid none
groups: mgre
tunnel: (unset) ttl 64 nodf
$

This is on a default install with patches up to and including 014.
OpenBSD 6.3 GENERIC.MP#7 amd64

If anyone has had success setting up an mgre interface then I would 
appreciate a little advice.


Regards

Joe



pf.conf "reply-to" routing parameter seemingly not working?

2018-05-10 Thread Joe Crivello
Hello!

I have a trunk0 interface on a router (#1) that is used for a singular
purpose -- to pass (IPsec protected) traffic for an IPIP tunnel (gif0) to
another router (#2). I have configured PF rules on router #1 that prevent
any other type of traffic from passing on trunk0. There are several routing
table entries that forward to router #2 on gif0.

My objective is to configure an additional pass rule that would allow SSH
traffic destined for router #1 to pass in and out on trunk0.

The problem is that the aforementioned routes on gif0 cause packets sent in
reply to incoming SSH traffic to pass out on gif0 (after passing in on
trunk0). This ends up getting blocked by PF on router #1 because the
state-policy is set to if-bound (which is how I want it). I am trying to
use reply-to to enforce symmetric routing, but it isn't working.

As you will see below, my "reply-to" rule is matched, but the reply is
_still_ routed to gif0:

# tcpdump -nevvpi pflog0 tcp port 22
tcpdump: WARNING: snaplen raised from 116 to 224
tcpdump: listening on pflog0, link-type PFLOG
01:27:46.503040 rule 5/(match) [uid 0, pid 16018] pass in on trunk0: [uid
4294967295, pid 10] [SSH CLIENT IP].57427 > [TRUNK0 IP].22: S [tcp sum
ok] 1707770457:1707770457(0) win 64240  (DF) (ttl 127, id 24244, len 52)
01:27:46.503069 rule 4/(match) [uid 0, pid 16018] block out on gif1: [uid
4294967295, pid 10] [TRUNK0 IP].22 > [SSH CLIENT IP].57427: S [tcp sum
ok] 4100262020:4100262020(0) ack 1707770458 win 16384  (DF) (ttl 64, id 43497, len 52, bad ip
cksum 0! -> d71b)
^C
2 packets received by filter
0 packets dropped by kernel

# pfctl -sr | grep @5
@5 pass in log quick on trunk0 inet proto tcp from any to [TRUNK0 IP] port
= 22 flags S/SA keep state (if-bound) reply-to @trunk0

Router #1 is running OpenBSD 6.2.

Anyone have any idea why this isn't working the way I want it to?

Joe



Re: ICMPv6 Neighbor Advertisement PF Weirdness

2018-04-30 Thread Joe Crivello
I solved the problem described in my last email.

The problem was that we copy pasted the IPv6 address for each vlan
interface, and then changed part of the address for each interface, but
failed to change the prefix length to 64. This meant that each vlan
interface had a different address, but shared the same subnet with other
interfaces. Obviously this resulted in an "unusual" route table -- but it
is unclear to us why the previously described PF problem manifested in the
way it did -- especially given that the ICMPv6 packet used link-local
addresses, and the pass rule did not filter on interface. Seems like it is
possibly a bug.

Joe

On Mon, Apr 30, 2018 at 12:31 PM, Joe Crivello <josephcrive...@gmail.com>
wrote:

> Hello --
>
> While configuring a new firewall, I noticed that pflog0 was showing that
> some ICMPv6 neighbor advertisement packets were being blocked in on vlan51,
> which is a sub-interface of vmx1 (a vmxnet3 interface using VGT). I added a
> PF rule allowing this traffic to pass. However, even after adding the rule
> and flushing all state, the traffic was still being reported as blocked in
> by pflog0. Thinking that there might be something else wrong with the rule
> set, I made the pass rule "quick" and inserted it as the first pass rule in
> the set. This still didn't work.
>
> See below for (1) the first two rules of the rule set (they are the only
> ones that matter in this example), (2) a tcpdump that was run after the
> rule set was applied and states were flushed, showing the blocked traffic,
> and (3) the interface configurations in question.
>
> # pfctl -sr
> FILTER RULES:
> block drop log all label "Block all"
> pass in quick on any inet6 proto ipv6-icmp all icmp6-type neighbradv
>
> # tcpdump -netvvi pflog0 "icmp6 && ip6[40] == 136"
> tcpdump: WARNING: snaplen raised from 116 to 160
> tcpdump: listening on pflog0, link-type PFLOG
> rule 1/(match) [uid 0, pid 91607] block in on vlan51:
> fe80::1905:23c0:fe7a:dcfe > ff02::1: [|icmp6] (len 32, hlim 255)
> ^C
> 7 packets received by filter
> 0 packets dropped by kernel
>
> # ifconfig vmx1
> vmx1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0c:29:50:66:d1
> index 2 priority 0 llprio 3
> media: Ethernet autoselect (10GbaseT)
> status: active
> inet6 fe80::20c:29ff:fe50:66d1%vmx1 prefixlen 64 scopeid 0x2
>
> # ifconfig vlan51
> vlan51: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:0c:29:50:66:d1
> description: 
> index 7 priority 0 llprio 3
> encap: vnetid 51 parent vmx1
> groups: vlan inetusr resolverusr
> media: Ethernet autoselect (10GbaseT)
> status: active
> inet6 fe80::20c:29ff:fe50:66d1%vlan51 prefixlen 64 scopeid 0x7
> inet 10.84.51.1 netmask 0xff00 broadcast 10.84.51.255
> inet6 ::1 prefixlen 56
>
> The firewall is a VMware ESXi 6.5 virtual machine running
> SecurityRouter.org 6.2-lyra -- which is a distribution based on OpenBSD 6.2.
>
> Thinking that this might be a problem with the vmx(4) driver, we changed
> the network interface to emulated E1000e (em(4)), no change. Also tried
> adding "allow-opts" to the pass rule, no change.
>
> I understand this list isn't meant to support SecurityRouter.org's
> distribution of OpenBSD... but does anyone see something obviously wrong
> with my rule set or my expectations of how it should behave? Are there
> known problems with using VGT on VMware ESXi with vmx(4) and em(4) drivers?
> I reviewed the 6.2 errata and didn't see anything pertinent.
>
> Joe
>
>


ICMPv6 Neighbor Advertisement PF Weirdness

2018-04-30 Thread Joe Crivello
Hello --

While configuring a new firewall, I noticed that pflog0 was showing that
some ICMPv6 neighbor advertisement packets were being blocked in on vlan51,
which is a sub-interface of vmx1 (a vmxnet3 interface using VGT). I added a
PF rule allowing this traffic to pass. However, even after adding the rule
and flushing all state, the traffic was still being reported as blocked in
by pflog0. Thinking that there might be something else wrong with the rule
set, I made the pass rule "quick" and inserted it as the first pass rule in
the set. This still didn't work.

See below for (1) the first two rules of the rule set (they are the only
ones that matter in this example), (2) a tcpdump that was run after the
rule set was applied and states were flushed, showing the blocked traffic,
and (3) the interface configurations in question.

# pfctl -sr
FILTER RULES:
block drop log all label "Block all"
pass in quick on any inet6 proto ipv6-icmp all icmp6-type neighbradv

# tcpdump -netvvi pflog0 "icmp6 && ip6[40] == 136"
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
rule 1/(match) [uid 0, pid 91607] block in on vlan51:
fe80::1905:23c0:fe7a:dcfe > ff02::1: [|icmp6] (len 32, hlim 255)
^C
7 packets received by filter
0 packets dropped by kernel

# ifconfig vmx1
vmx1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0c:29:50:66:d1
index 2 priority 0 llprio 3
media: Ethernet autoselect (10GbaseT)
status: active
inet6 fe80::20c:29ff:fe50:66d1%vmx1 prefixlen 64 scopeid 0x2

# ifconfig vlan51
vlan51: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0c:29:50:66:d1
description: 
index 7 priority 0 llprio 3
encap: vnetid 51 parent vmx1
groups: vlan inetusr resolverusr
media: Ethernet autoselect (10GbaseT)
status: active
inet6 fe80::20c:29ff:fe50:66d1%vlan51 prefixlen 64 scopeid 0x7
inet 10.84.51.1 netmask 0xff00 broadcast 10.84.51.255
inet6 ::1 prefixlen 56

The firewall is a VMware ESXi 6.5 virtual machine running
SecurityRouter.org 6.2-lyra -- which is a distribution based on OpenBSD 6.2.

Thinking that this might be a problem with the vmx(4) driver, we changed
the network interface to emulated E1000e (em(4)), no change. Also tried
adding "allow-opts" to the pass rule, no change.

I understand this list isn't meant to support SecurityRouter.org's
distribution of OpenBSD... but does anyone see something obviously wrong
with my rule set or my expectations of how it should behave? Are there
known problems with using VGT on VMware ESXi with vmx(4) and em(4) drivers?
I reviewed the 6.2 errata and didn't see anything pertinent.

Joe


Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?

2018-04-29 Thread Joe Gidi
> On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote:
>>
>> > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote:
>> >> drivers/gpu/drm/amd in linux has over 1.5 million lines of code.
>> Which
>> >> is multiple times larger than the complete OpenBSD kernel source...
>>
>> Thanks for this update!
>>
>> Just to clarify, before I spend a bunch of money on new hardware, should
>> I
>> be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort
>> with
>> this updated driver?
>>
>> Thanks again,
>
> It appears that 'R7 250' can mean either a cape verde or oland radeon
> depending on the model.  Both are GCN parts.
>
> 4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0
> Both claim support for displayport 1.2 which should be able to do
> 4k 60Hz.  HDMI 2.0 seems to only be on later hardware with DCE >= 11
> carrizo (not carrizo-l which is mullins), polaris etc.
>
> With the low end radeons displayport is sometimes only available on
> oem models of cards sold as options for systems marketed as business
> desktops or workstations.
>
> And as mentioned earlier for acceleration you'll currently have to build
> a different version of Mesa than what OpenBSD releases/snapshots ship
> with.

Hi Jonathan,

Thanks for the detailed answer!

As best I can tell from wading through the mess of marketing names and
specifications, accelerated 4k video is currently not an option with
Radeon cards; the older cards don't support high-enough resolutions, and
the newer ones don't have acceleration support yet due to the Mesa
problem. Looks like I might need to buy an Intel machine or wait for the
Mesa issues to get resolved.

Thanks again,
Joe


-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



dmesg for ThinkPad T480s

2018-04-19 Thread joe di castro

This is the dmesg for my new ThinkPad T480s.

Detailed specs:

Intel Core i5-8250U
LG 14.0" WQHD (2560 x 1440) IPS
16 GB DDR4 2400MHz
Integrated Intel® UHD Graphics 620
IR 720p HD Camera with microphone
NO Fingerprint Reader
NO NFC
Smartcard reader
512 GB SSD Samsung PM981 PCIe-NVMe M.2
3 cell Li-Ion 57Wh
65W AC Adapter USB Type-C
Intel Dual Band 8265 Wireless AC & Bluetooth
NO WWAN card
Black


dmesg (running -current):


OpenBSD 6.3-current (GENERIC.MP) #206: Wed Apr 18 10:11:07 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17052938240 (16262MB)
avail mem = 16528203776 (15762MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x9a65 (62 entries)
bios0: vendor LENOVO version "N22ET34W (1.11 )" date 03/13/2018
bios0: LENOVO 20L7CTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT 
SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! 
FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1397.32 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1147.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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: failed to identify
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 969.69 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBPcpu2:
 failed to identify
,SENSOR,ARAT,MELTDOWNcpu3 at mainbus0
: cpu2: 256KB 64b/line apid 6 (application processor)
8-way L2 cache
cpu3: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz
cpu3: FPU,VME,DEcpu2: smt 0, core 2, package 0
,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSCcpu3:
 failed to identify
,FSGSBASE,SGX,BMI1,AVX2cpu4 at mainbus0,SMEP: apid 1 (application processor)
,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line cpu4: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz
cpu4: 8-way L2 cache
FPU,VME,DEcpu3: smt 0, core 3, package 0
,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNTcpu4:
 failed to identify
,DEADLINE,AEScpu5 at mainbus0,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB: 
,RDTSCP,LONGapid 3 (application processor)
,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBPcpu5:
 Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz
cpu5: 

Re: 4-ports router under $150

2018-04-08 Thread Joe Holden
On 08/04/2018 23:16, Rupert Gallagher wrote:
> 963Mbps
> 
> On Sun, Apr 8, 2018 at 18:02, Michael Price  wrote:
> 
>> Was it an apu2c4 by any chance? I was thinking about picking one of those up 
>> and was curious as to what kind of packet rates people were seeing with them.

Obtaining a gig isn't hard, what actual pps can they achieve?



frozen clock on Intel NUC

2017-10-15 Thread Joe Gidi
I have tried to submit this to bugs@ twice in the past two days, once
directly via sendbug and again by webmail, but as far as I can tell, it
has not been accepted. Posting here in the hopes of making some devs aware
of this issue...


>Synopsis:  Recent TSC changes seem to result in frozen clock on Intel NUC
>Category:  kernel
>Environment:
System  : OpenBSD 6.2
Details : OpenBSD 6.2-current (GENERIC.MP) #148: Fri Oct 13 16:30:01
MDT 2017
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
After upgrading to a recent snapshot, I noticed the following line in
dmesg and a frozen clock once the system was up:
acpitimer0: recalibrated TSC frequency -1 Hz
I believe this is due to the recent TSC timecounter changes committed by
mikeb.
>How-To-Repeat:
Happens all the time with current snapshot.
>Fix:
Disabling acpitimer in UKC is enough to bring the system up with a
functional clock.


dmesg:
OpenBSD 6.2-current (GENERIC.MP) #148: Fri Oct 13 16:30:01 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Real mem = 4192968704 (3998MB)
avail mem = 4059029504 (3870MB)
User Kernel Config
UKC> disable acpiti,\^H \^Hmer
387 acpitimer* disabled
UKC> quit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedcb0 (49 entries)
bios0: vendor Intel Corp. version "PYBSWCEL.86A.0058.2016.1102.1842" date
11/02/2016
bios0: Intel Corporation NUC5CPYB
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT TPM2
CSRT SSDT
acpi0: wakeup devices BRCM(S0) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4)
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
acpitimer at acpi0 not configured
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1680.45 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-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 79MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1600.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiec0 at acpi0: not present
acpicpu0 at acpi0
C2: state 6: substate 8 >= num 3
C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0
C2: state 6: substate 8 >= num 3
C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: ID3C, resource for ISP3
acpipwrres1 at acpi0: CLK0, resource for CAMD
acpipwrres2 at acpi0: CLK0
acpipwrres3 at acpi0: CLK1, resource for CAM3
acpipwrres4 at acpi0: USBC, resource for XHC1
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 115 degC
chvgpio0 at acpi0: GPO1 uid 2 addr 0xfed88000/0x8000 irq 48, 59 pins
"ITE8713" at acpi0 not configured
"BCM43241" at acpi0 not configured
sdhc0 at acpi0: SDHC addr 0x81429000/0x1000 irq 47
sdhc0: SDHC 3.0, 200 MHz base clock
sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma
"INTL9C60" at acpi0 not configured
"INTL9C60" at acpi0 not configured
"8086228A" at acpi0 not configured
"8086228A" at acpi0 not configured
dwiic0 at acpi0: I2C6 addr 0x81425000/0x1000 irq 37
iic0 at dwiic0
dwiic1 at acpi0: I2C7 addr 0x81423000/0x1000 irq 38
iic1 at dwiic1
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: SLPB
chvgpio1 at acpi0: GPO0 uid 1 addr 0xfed8/0x8000 irq 49, 56 pins
chvgpio2 at acpi0: GPO2 uid 3 addr 0xfed9/0x8000 irq 50, 24 pins
chvgpio3 at acpi0: GPO3 uid 4 addr 0xfed98000/0x8000 irq 91, 55 pins
"MSFT0101" at acpi0 not configured
"INT3398" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
cpu0: Enhanced SpeedStep 1680 MHz: speeds: 1601, 1600, 1520, 1440, 1360,
1280, 1200, 1120, 1040, 960, 880, 800, 720, 640, 560, 480 MHz
pci0 at mainbus0 bus 0

Re: Blocking users who change their IP address

2017-10-06 Thread Joe Holden

On 05/10/2017 22:39, Eric Johnson wrote:



On Fri, 6 Oct 2017, Mihai Popescu wrote:


I'm at a small Wireless ISP in a small town and have only a Class C block
of addresses.



  [...]



[...]


Very romantic, indeed, but it has nothing to do with OpenBSD.
Are you serious?


Since the primary firewall and the DHCP server (and pretty much everything
else on my end) run on OpenBSD, if there is a way to do it with OpenBSD,
for example with pf, then I think that it should be a very good place to
ask the question.

Of course, if there is no way to address the problem on computers running
OpenBSD, then I did ask in the wrong place.

Based on your response, I assume that OpenBSD must be useless for trying
to solve that problem and I shall have to look elsewhere.

Eric


This is a network infrastructure/design problem you need to either 
isolate customers or filter further down stream, if they're on a 
relatively dumb shared layer2 network you aren't going to be able to fix 
it by the time it gets to the firewall...





Re: Yubikey works on gpg1 but not gpg2

2017-08-09 Thread joe di castro
Hi Carolyn,

I had the same behavior when I tried this on -current but it was working well 
as supposed on -stable

Thus, my first thought was that the current version of the GnuPG 2 package was 
the culprit, but to be sure I tried to see if I could access the smartcard to 
discard first the drivers. So I installed the pcsc-tools package and tried to 
scan the smartcard:

  $ pcsc_scan
  PC/SC device scanner
  ...
  SCardEstablishContext: Service not available.

Now the error was clear, the pcscd daemon wasn't running. The solution was 
easy, enable it and start it:

  # rcctl enable pcscd
  # rcctl start pcscd

And that's it! You need the ccid and pcsc-tools packages installed in order to 
use a smartcard.

P.S. Anyway, both of us could have saved time and troubles if we had read the 
readme file of the package in 

  /usr/local/share/doc/pkg-readmes

where exactly this is explained and also there is an example with a Yubikey. My 
bad, I'm starting with OpenBSD coming from a looong time on Linux  and I don't 
know all the OB' bolts and nuts yet ;)

Regards,



El 7 de agosto de 2017 7:09:32 CEST, Carolyn Saunders  
escribió:
>I have a Yubikey that I'd like to use for gpg and ssh purposes. Running
>"gpg --card-status" works as expected; it brings up the various keys
>attached to the device and other information. However, running "gpg2
>--card-status" just hangs, seemingly forever. What am I missing here?
>Thanks :)



KARL broken on arm64?

2017-08-07 Thread Joe Gidi
I just dusted off my Raspberry Pi 3 and updated to the latest snapshot
(from this morning). /usr/share/compile/GENERIC/relink.log shows:

(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0xd4d4d4d4 gapdummy.o
ld: error: gap.link:11: unknown command ;
ld: error: gap.link:11: LONG(0xd4d4d4d4);
ld: error: gap.link:11:   ^
ld: error: cannot open gapdummy.o: No such file or directory
ld: error: target emulation unknown: -m or at least one .o file required
*** Error 1 in /usr/share/compile/GENERIC (Makefile:529 'newbsd')

Known issue? Worthy of a bug report?

Thanks,

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: Dynamic DNS Client for EasyDNS

2017-08-02 Thread Joe Gidi
> "Joe Gidi" <j...@entropicblur.com> wrote:
>
>> ddclient should fit the bill. It's Perl, it's in ports, and it supports
>> EasyDNS. I've used it for a few years now with no problems.
>>
>> Joe
>
> Thanks for the quick response. Although I really like Ryan Flannery
> answer I think I got this already working.
>
> Joe could you please confirm that I don't need to do anything on EasyDNS
> side if I use ddclient? It looks like after I set up the method of
> updating ip in ddclient.conf and edit the EasyDNS configuration
> paragraph with my username and password I am good to go as it looks like
> ddclient is going to edit zone files for me.
>
> Predrag

I'm using ddclient with a different DNS service, but yes, all I had to do
was set up ddclient.conf and enable ddclient with rcctl.

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: Dynamic DNS Client for EasyDNS

2017-08-02 Thread Joe Gidi
ddclient should fit the bill. It's Perl, it's in ports, and it supports
EasyDNS. I've used it for a few years now with no problems.

Joe

> One of my clients is insisting on using her current ISP with dynamic IP.
> On the another hand we decided to use EasyDNS as our managed DNS
> provider due to my past experiences with them. She bought  DNS pro plan
> which does include among other things Dynamic DNS services. However I
> see that only ez-ipupdate is listed as Dynamic DNS client. Apart of the
> fact that it is not in OpenBSD port tree I see that it is written in C
> (I was hoping for a simple Perl script)
>
> https://sourceforge.net/projects/ez-ipupdate/
>
> and officially untested on anything else besides Linux. I see FreeBSD
> port
>
> https://www.freebsd.org/cgi/ports.cgi?query=ez-ipupdate=all=all
>
> Short of me convincing the client to buy statis IP or porting
> ez-ipupdate to OpenBSD does anyone see any other alternatives?
>
> Best,
> Predrag
>
>


-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried



Re: octeon port, ubiquity edgerouter

2017-07-26 Thread Joe Holden
On 26/07/2017 00:56, jungle Boogie wrote:
> On 25 July 2017 at 15:20, Doggie  wrote:
>> W dniu 2017-07-25 o 19:39, Peter J. Philipp pisze:
>>>
>>> Actually I bought the silent fans.  So I don't have to write any code,
>>> too bad the foxconn fans are a misdesign.  I'll maintenance this router
>>> next week for the new fans.  I'm putting it into production at home
>>> tomorrow though.
>>
>>
>> Thanks for all the details, Peter, and good luck during next steps of your
>> project.
>>
>> I wonder how fast the NIC's will be - using this CPU and still no hardware
>> acceleration.
>>
> 
> Yeah, I'm wondering that too. It's pretty cool this platform is
> becoming more popular to run openBSD on.
> People are willing to take an unknown (right now) performance penalty
> to run openBSD on it and with pf.
> 
> Sounds like ubiquity should just sell it with openBSD loaded on it
> support the project. ;)
> 
As far as the ERL goes, it seems to be limited to about 250Mbps per
interface (only tested with in+out, 2 500 ish total), regardless of
packet size



Re: Jumbo frames on Octeon

2017-06-29 Thread Joe Holden
On 29/06/2017 12:06, Visa Hankala wrote:
> On Tue, Jun 27, 2017 at 07:57:42PM +0100, Joe Holden wrote:
>> It looks like setting the mtu on cnmac interfaces doesn't quite work as
>> expected, whatever the mtu is set to the upper limit appears to be 1510
>> as although it will transmit frames of any arbitary size (e.g 2000
>> bytes), the reply never makes it back (confirmed from an attached box)
>> unless the frame is =< 1510.
> I just committed a patch that lets MTU change happen on the fly
> with cnmac(4).
>
> If you are using release 6.1, you have to temporarily bring down
> the interface, or reboot, when changing MTU on a cnmac(4) interface.
>
Ah excellent, cheers!



Re: Jumbo frames on Octeon

2017-06-27 Thread Joe Holden
On 27/06/2017 19:57, Joe Holden wrote:
> Hi guys,
>
> It looks like setting the mtu on cnmac interfaces doesn't quite work as
> expected, whatever the mtu is set to the upper limit appears to be 1510
> as although it will transmit frames of any arbitary size (e.g 2000
> bytes), the reply never makes it back (confirmed from an attached box)
> unless the frame is =< 1510.
>
> Not sure who looks after octeon these days
>
> Cheers
>
Should probably note, observed on ERL



Jumbo frames on Octeon

2017-06-27 Thread Joe Holden
Hi guys,

It looks like setting the mtu on cnmac interfaces doesn't quite work as
expected, whatever the mtu is set to the upper limit appears to be 1510
as although it will transmit frames of any arbitary size (e.g 2000
bytes), the reply never makes it back (confirmed from an attached box)
unless the frame is =< 1510.

Not sure who looks after octeon these days

Cheers



Re: DNS hijacking (was Re: Is this an intrusion?)

2017-06-18 Thread Joe Holden
On 18/06/2017 10:59, Stuart Henderson wrote:
> On 2017-06-17, Paul Suh  wrote:
>> Folks,=20
>>
>> My understanding of the way that this is done is by returning a CNAME =
>> when the ISP's DNS recursive DNS server would otherwise return a =
>> NXDOMAIN result, followed by a  HTTP 302 when the browser attempts to =
>> reach the host via the bogus CNAME.=20
>>
>> My question is would running my own internal recursive DNS resolver be =
>> sufficient to stop this from happening? (I run my own DNS server anyway, =
>> but I'm curious to see whether it would be sufficient to bypass the =
>> search page redirection stupidity.)=20
> 
> Usually that's enough, but it depends how evil the ISP is.
> 

Should give them a call and have it turned off anyway really...



Re: Is this an intrusion?

2017-06-16 Thread Joe Holden
On 16/06/2017 20:59, Maurice McCarthy wrote:
> On 15/06/17 14:13, Ted Unangst wrote:
>> Maurice McCarthy wrote:
>>> Hi,
>>>
>>> $ xauth list
>>> ...
>>> advancedsearch.virginmedia.com:0  MIT-MAGIC-COOKIE-1  
>>> f3aa08ed0926482c51f5cb386e28a0ea
>>>
>>>
>>> Virgin Media is my ISP. Is this an intrusion into my system please? I
>>> ran xauth remove ... just for the sake  of it anyhow.
>>
>> well, even if it wasn't, you just posted the secret key to a public list, so
>> probably wise to remove it anyway. :)
> 
> Thanks to all that have replied and apologies for the slow response. Had
> to attend to more urgent matters. (Lost the blessed terrestrial TV
> signal!) 
> 
> To TedU, 
> 
> Ooops! ... Well, I moved the .Xauthority file aside and restarted X to
> create a new one. Obviously it has one line with my hostname in it. But 
> 
> $ xauth list
> fresh.yem/unix:0  MIT-MAGIC-COOKIE-1  ... 
> advancedsearch.virginmedia.com:0  MIT-MAGIC-COOKIE-1 ... 
> 
> And only now did I notice that the magic cookie is identical for both
> entries. This mystifies me. (BTW apparently Virgin has historically used
> a bit of DNS hijacking so I bunged this line into /etc/hosts before
> restarting X.
> 
> 127.0.0.1 advancedsearch.virginmedia.com )
> 
> 
> To Peter Hessler, 
> 
> The reverse DNS went like this
> 
> 80.2.249.209 cpc77525-cwma10-2-0-cust208.7-3.cable.virginm.net
> 
> I run most traffic through a vpn but my router is a Virgin SuperHub2, as
> they call it. 
> 
> 
> To Dot Yet,
> 
> I've through system logs etc and nothing seems to look suspicious. Can't
> find any attempts to execute commands nor authenticate. Further the
> remote access port is disabled in the router settings. I've never asked
> Virgin for support in years.
> 
> 
> To Joe Holden,
> 
> Thanks for the tip about NXDOMAIN queries. Don't see where to unset in
> the router but I'm guessing the hosts file entry above should do the
> same thing.
> 
> I'll keep looking around to reassure myself anyhow 
> 
> Thanks to all, 
> Moss

It is done by the VM dns servers, if you visit a domain that doesn't
exist you should be directed to the advanced search page, there *should*
be a link to disable it there, but if not login to your account and
disable it, can't remember what it is called...

Hosts file won't solve the problem really since anything else will also
get the same result



Re: Is this an intrusion?

2017-06-15 Thread Joe Holden
On 15/06/2017 16:47, Dot Yet wrote:
> On Thu, Jun 15, 2017 at 9:12 AM Maurice McCarthy 
> wrote:
> 
>> Hi,
>>
>> $ xauth list
>> ...
>> advancedsearch.virginmedia.com:0  MIT-MAGIC-COOKIE-1
>> f3aa08ed0926482c51f5cb386e28a0ea
>>
>>
>> Virgin Media is my ISP. Is this an intrusion into my system please? I
>> ran xauth remove ... just for the sake  of it anyhow.
>>
>> Thanks
>> Moss
> 
> 
> Maybe. Are there other hints in the system log files, history files around
>> someone trying to authenticate or execute commands? Was there a possibility
>> that there was a screen sharing session done for any kind of support
>> activities (would not be the case as you are already suspecting intrusion).
>>

More likely you typo'd adding a host, advancedsearch is what NXDOMAIN
queries get directed to, just turn it off on my virgin media



Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?

2017-06-01 Thread Joe Gidi
Good news! You can have this already. Go run Linux.

On June 1, 2017 8:42:45 PM EDT, Tinker  wrote:
>Ah - having an interface name naming scheme that, instead of just being
>
>a counter, e.g. CDCE + 0 -> 1 -> ... = "cdce0", denoting the physical 
>slot where the device is connected, e.g. CDCE + USB root-hub: 0 + slot:
>
>17 + address: 4 = "cdceur0s17a4", would do the job too.
>
>On 2017-06-02 00:24, Tinker wrote:
>> Hi,
>> 
>> What I meant was, it's fairly easy for interface numbers (e.g. NIC A
>> as CDCE0 and NIC B as CDCE1) to become exchanged.
>> 
>> With lots of unluck, there could be mechanical stress on USB ports so
>> that they would rearrange spontaneously so NIC B would become CDCE0
>> and NIC A would become CDCE1.
>> 
>> Or more probable, an ignorant user would intentionally replug his
>> devices but the change of order of interfaces would be unintentional
>> to him, and then when he ifconfig/dhclient:s his interfaces, very bad
>> things could happen.
>> 
>> This is not a big deal, but it does add one more thing to think
>about,
>> and in extreme corner cases it could be a security problem - God
>> forbid you'd have a public network on CDCE0 and a private network on
>> CDCE1 and then a little mistake causes everyone's medical records
>etc.
>> to be leaked on the Internet.
>> 
>> 
>> The same would apply to USB serial ports (UART:s) and probably some
>> other hardware -
>> 
>> I was talking to someone who was worried that it (unintended device
>> ordering) could happen even to PCI devices though I guess that's
>> overkill.
>> 
>> His solution is to enforce device names by using different hardware,
>> though that kind of illustrates the problem rather than resolve it,
>> doesn't it.
>> 
>> 
>> OpenBSD leaves IP configuration as manual work to the user so OpenBSD
>> itself won't mess it up for you, so this is not a per-se OpenBSD
>> problem.
>> 
>> But maybe OpenBSD could help people do it right. Interface number
>> hard-binding to a particular device descriptor (MAC/USB serial etc.)
>> would solve it.
>> 
>> Interface name aliasing would work too (hardbound to descriptor).
>> 
>> 
>> Anyhow I just wanted to bring up the potential problem.
>> 
>> (Also Peter - this is not specifically a PF problem, however, how
>> would you use egress as part of the solution?)
>> 
>> Thanks,
>> Tinker
>> 
>> On 2017-05-30 07:04, Peter Hessler wrote:
>>> On 2017 May 29 (Mon) at 02:13:57 + (+), Tinker wrote:
>>> :Hi misc@,
>>> :
>>> :For pluggable devices such as USB NIC:s, is there any way to make 
>>> OpenBSD
>>> :bind a particular device based on its MAC or USB serial number or
>the 
>>> like
>>> :variable, to a particular interface or device filename?
>>> :
>>> :E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external
>
>>> USB
>>> :harddrive with serial number Z as /dev/sd0 and the one with serial 
>>> number A
>>> :as /dev/sd1 (and plugging in other devices would automatically).
>>> :
>>> :(For storage devices there's the DUID-based mounting already
>though, 
>>> so I
>>> :guess those are a non-issue.)
>>> :
>>> :Some things in the OS are specified per interface/device name, e.g.
>
>>> PF rules
>>> :(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1
>..", 
>>> "match
>>> :out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having
>the
>>> :interface numbers garbled on replug may be an unnecessary reason to
>
>>> reboot?
>>> :
>>> :Would be happy to learn any best practice here, thanks,
>>> :Tinker
>>> :
>>> 
>>> match out on egress from 192.168.0.0/16 to any nat-to (egress)
>>>  ^^   
>>> 
>>> the interface group "egress" is added to the interface a default
>route
>>> uses.  Wrapping that with (), will ensure that interface is updated 
>>> when
>>> the default routes uses a different interface.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Small patch for vnconfig/mount_vnd to return the first unused vnd device

2017-04-27 Thread Joe Holden

Might be useful, particularly in scripting...

Behaves like losetup.

Index: sbin/mount_vnd/mount_vnd.c
===
RCS file: /cvs/src/sbin/mount_vnd/mount_vnd.c,v
retrieving revision 1.20
diff -u -p -r1.20 mount_vnd.c
--- sbin/mount_vnd/mount_vnd.c  24 Jan 2016 06:32:33 -  1.20
+++ sbin/mount_vnd/mount_vnd.c  28 Apr 2017 03:24:44 -
@@ -62,6 +62,7 @@
 #define VND_CONFIG 1
 #define VND_UNCONFIG   2
 #define VND_GET3
+#define VND_FIND   4

 int verbose = 0;
 int run_mount_vnd = 0;
@@ -70,12 +71,13 @@ __dead void  usage(void);
 int config(char *, char *, int, struct disklabel *, char *,
 size_t);
 int getinfo(const char *);
+int findfirst(void);
 char   *get_pkcs_key(char *, char *);

 int
 main(int argc, char **argv)
 {
-   int  ch, rv, action, opt_c, opt_k, opt_K, opt_l, opt_u;
+   int  ch, rv, action, opt_c, opt_k, opt_K, opt_l, opt_u, opt_f = 0;
char*key, *mntopts, *rounds, *saltopt;
size_t   keylen = 0;
extern char *__progname;
@@ -88,7 +90,7 @@ main(int argc, char **argv)
key = mntopts = rounds = saltopt = NULL;
action = VND_CONFIG;

-   while ((ch = getopt(argc, argv, "ckK:lo:S:t:uv")) != -1) {
+   while ((ch = getopt(argc, argv, "ckK:lo:S:t:uv:f")) != -1) {
switch (ch) {
case 'c':
opt_c = 1;
@@ -103,6 +105,9 @@ main(int argc, char **argv)
case 'l':
opt_l = 1;
break;
+   case 'f':
+   opt_f = 1;
+   break;
case 'o':
mntopts = optarg;
break;
@@ -133,6 +138,8 @@ main(int argc, char **argv)

if (opt_l)
action = VND_GET;
+   else if (opt_f)
+   action = VND_FIND;
else if (opt_u)
action = VND_UNCONFIG;
else
@@ -173,6 +180,8 @@ main(int argc, char **argv)
rv = config(argv[0], NULL, action, NULL, NULL, 0);
else if (action == VND_GET)
rv = getinfo(argc ? argv[0] : NULL);
+   else if (action == VND_FIND)
+   rv = findfirst();
else
usage();

@@ -290,6 +299,35 @@ query:
close(vd);

return (0);
+}
+
+int
+findfirst(void)
+{
+   char *vname = DEFAULT_VND;
+   int vd;
+   struct vnd_user vnu;
+
+   vd = opendev((char *)vname, O_RDONLY, OPENDEV_PART, NULL);
+   if (vd < 0)
+   err(1, "open: %s", vname);
+
+   vnu.vnu_unit = -1;
+
+query:
+   if (ioctl(vd, VNDIOCGET, ) == -1)
+   err(1, "ioctl: %s", vname);
+
+   if (!vnu.vnu_ino)
+   fprintf(stdout, "vnd%d\n", vnu.vnu_unit);
+   else {
+   vnu.vnu_unit++;
+   goto query;
+   }
+
+   close(vd);
+
+   return (0);
 }

 int

(cvs diff is dumb)



Re: Setting rtable 0 from >1 with ping et al

2017-03-18 Thread Joe Holden

On 18/03/2017 08:21, Florian Obser wrote:

On Thu, Mar 16, 2017 at 07:59:44PM +, Joe Holden wrote:

On 09/03/2017 23:35, Joe Holden wrote:

On 09/03/2017 23:02, Joe Holden wrote:

Hi,

So - it seems that pledge will deny a change of rtable to 0 when using
level SOL_SOCKET and the current rtable is >0, so eg if you're in table
1 and you do ping -V0 it will fail.

Can anyone shed any light on why this is restricted?  Especially since
the same can be achieved with route -T0 exec

Thanks!


Actually, just realised why it doesn't work - it drops privs before
setting rtable, nevermind.


Something like:

Index: sbin/ping/ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.218
diff -u -p -r1.218 ping.c
--- sbin/ping/ping.c22 Feb 2017 13:43:35 -  1.218
+++ sbin/ping/ping.c16 Mar 2017 19:58:28 -
@@ -283,10 +283,6 @@ main(int argc, char *argv[])
uid = getuid();
gid = getgid();
}
-   if (setgroups(1, ) ||
-   setresgid(gid, gid, gid) ||
-   setresuid(uid, uid, uid))
-   err(1, "unable to revoke privs");

preload = 0;
datap = [ECHOLEN + ECHOTMLEN];
@@ -427,6 +423,11 @@ main(int argc, char *argv[])
usage();
}
}
+
+   if (setgroups(1, ) ||
+   setresgid(gid, gid, gid) ||
+   setresuid(uid, uid, uid))
+   err(1, "unable to revoke privs");

argc -= optind;
argv += optind;


perhaps, but haven't closely looked if there is any scope for
escalation or anything during option parsing



This seems... unwise. ping(8) very carefuly tries to do as little as
possible while still having priviledges, i.e. only create raw sockets.

That being said, I don't understand the problem.

1) How do you end up in rtable 1 and need to do something in table 0?
In this instance, the management (sshd, et al) rtable isn't 0 (for a few 
reasons, mostly things that can't operate on an rtable other than 0)



2) you say route -T0 exec works, I don't think so:

$ route -T1 exec /bin/sh
$ route -T0 exec ping 8.8.8.8
route: setrtable: Operation not permitted

setrtable(2) has this:

ERRORS
 The call succeeds unless:
[...]
 [EPERM]The user is not the superuser and the routing table of
the calling process is already set to a non-zero
value.

So this is intentional behaviour.


Setting rtable implies being uid 0, so not really - but:

# ping -V0 127.0.0.1
ping: setsockopt SO_RTABLE: Operation not permitted
# route -T0 exec ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.948 ms

from an rtable other than 0, because the route doesn't use SO_RTABLE so 
doesn't fail




bioctl showing "0% done" on apparently healthy softraid

2017-03-18 Thread Joe Gidi
cpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
"INT3F0D" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 3193 MHz: speeds: 3201, 3200, 3000, 2900, 2700,
2500, 2300, 2200, 2000, 1800, 1700, 1500, 1300, 1100, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v3 Host" rev 0x06
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics P4600" rev 0x06
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1024x768, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi
xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x05: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev
3.00/1.00 addr 1
"Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x05: msi, address
6c:0b:84:09:f9:bd
ehci0 at pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int 17
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x05: msi
azalia1: codecs: Realtek ALC662
audio0 at azalia1
ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xd5
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 8 Series PCIE" rev 0xd5: msi
pci2 at ppb1 bus 2
em1 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
68:05:ca:3a:8e:b2
ppb2 at pci0 dev 28 function 3 "Intel 8 Series PCIE" rev 0xd5: msi
pci3 at ppb2 bus 3
ppb3 at pci3 dev 0 function 0 "ITExpress IT8893E PCIE-PCI" rev 0x41
pci4 at ppb3 bus 4
ehci1 at pci0 dev 29 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int 23
usb2 at ehci1: USB revision 2.0
uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
pcib0 at pci0 dev 31 function 0 "Intel C226 LPC" rev 0x05
ahci0 at pci0 dev 31 function 2 "Intel 8 Series AHCI" rev 0x05: msi, AHCI 1.3
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 6.0Gb/s
ahci0: port 2: 6.0Gb/s
ahci0: port 3: 6.0Gb/s
ahci0: port 4: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, Samsung SSD 850, EMT0> SCSI3 0/direct
fixed naa.5002538d4019e022
sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin
sd1 at scsibus1 targ 1 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct
fixed naa.5000c50079458b1b
sd1: 3815447MB, 512 bytes/sector, 7814037168 sectors
sd2 at scsibus1 targ 2 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct
fixed naa.5000c500799ccc22
sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors
sd3 at scsibus1 targ 3 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct
fixed naa.5000c500794576ca
sd3: 3815447MB, 512 bytes/sector, 7814037168 sectors
cd0 at scsibus1 targ 4 lun 0: <HL-DT-ST, DVD-ROM DTA0N, DC01> ATAPI
5/cdrom removable
ichiic0 at pci0 dev 31 function 3 "Intel 8 Series SMBus" rev 0x05: apic 8
int 18
iic0 at ichiic0
sdtemp0 at iic0 addr 0x19: mcp98243
spdmem0 at iic0 addr 0x51: 4GB DDR3 SDRAM ECC PC3-12800 with thermal sensor
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm disabled by firmware
vmm at mainbus0 not configured
error: [drm:pid0:intel_uncore_check_errors] *ERROR* Unclaimed register
before interrupt
uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching
Hub" rev 2.00/0.05 addr 2
uhub4 at uhub2 port 1 configuration 1 interface 0 "Intel Rate Matching
Hub" rev 2.00/0.05 addr 2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd4 at scsibus3 targ 1 lun 0: <OPENBSD, SR RAID 1, 006> SCSI2 0/direct fixed
sd4: 3815447MB, 512 bytes/sector, 7814036576 sectors
root on sd0a (918dcdbb8c221cb4.a) swap on sd0b dump on sd0b

Thanks,

--
 Joe Gidi
 j...@entropicblur.com

 "You cannot buy skill." -- Ross Seyfried



bioctl showing "0% done" on apparently healthy softraid

2017-03-18 Thread Joe Gidi
.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0 
 acpipwrres1 at acpi0: FN01,
resource for FAN1 
 acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3 
 acpipwrres4 at acpi0: FN04,
resource for FAN4 
 acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC 
 "INT3F0D" at acpi0 not
configured 
 "PNP0501" at acpi0 not configured 
 acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured 
 "PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured 
 "PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured 
 "PNP0C14" at acpi0 not configured
acpivideo0 at acpi0: GFX0 
 acpivout0 at acpivideo0: DD1F 
 cpu0: Enhanced
SpeedStep 3193 MHz: speeds: 3201, 3200, 3000, 2900,
2700, 2500, 2300, 2200,
2000, 1800, 1700, 1500, 1300, 1100, 1000, 800
MHz 
 pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v3 Host" rev 0x06
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics P4600" rev 0x06

 drm0
at inteldrm0 
 inteldrm0: msi 
 inteldrm0: 1024x768, 32bpp 
 wsdisplay0 at
inteldrm0 mux 1: console (std, vt100 emulation) 
 wsdisplay0: screen 1-5 added
(std, vt100 emulation) 
 azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD
Audio" rev 0x06:
msi 
 xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI"
rev 0x05: msi 
 usb0 at xhci0: USB revision 3.0 
 uhub0 at usb0 configuration
1 interface 0 "Intel xHCI root hub" rev
3.00/1.00 addr 1 
 "Intel 8 Series
MEI" rev 0x04 at pci0 dev 22 function 0 not
configured 
 em0 at pci0 dev 25
function 0 "Intel I217-LM" rev 0x05: msi, address
6c:0b:84:09:f9:bd 
 ehci0 at
pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x05: apic 8
int 17 
 usb1 at
ehci0: USB revision 2.0 
 uhub1 at usb1 configuration 1 interface 0 "Intel
EHCI root hub" rev
2.00/1.00 addr 1 
 azalia1 at pci0 dev 27 function 0 "Intel
8 Series HD Audio" rev 0x05:
msi 
 azalia1: codecs: Realtek ALC662 
 audio0 at
azalia1 
 ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xd5 
 pci1
at ppb0 bus 1 
 ppb1 at pci0 dev 28 function 1 "Intel 8 Series PCIE" rev 0xd5:
msi 
 pci2 at ppb1 bus 2 
 em1 at pci2 dev 0 function 0 "Intel 82574L" rev
0x00: msi, address
68:05:ca:3a:8e:b2 
 ppb2 at pci0 dev 28 function 3 "Intel 8
Series PCIE" rev 0xd5: msi 
 pci3 at ppb2 bus 3 
 ppb3 at pci3 dev 0 function
0 "ITExpress IT8893E PCIE-PCI" rev 0x41 
 pci4 at ppb3 bus 4 
 ehci1 at pci0
dev 29 function 0 "Intel 8 Series USB" rev 0x05: apic 8
int 23 
 usb2 at
ehci1: USB revision 2.0 
 uhub2 at usb2 configuration 1 interface 0 "Intel
EHCI root hub" rev
2.00/1.00 addr 1 
 pcib0 at pci0 dev 31 function 0 "Intel
C226 LPC" rev 0x05 
 ahci0 at pci0 dev 31 function 2 "Intel 8 Series AHCI" rev
0x05: msi,
AHCI 1.3 
 ahci0: port 0: 6.0Gb/s 
 ahci0: port 1: 6.0Gb/s 
 ahci0:
port 2: 6.0Gb/s 
 ahci0: port 3: 6.0Gb/s 
 ahci0: port 4: 1.5Gb/s 
 scsibus1
at ahci0: 32 targets 
 sd0 at scsibus1 targ 0 lun 0: <ATA, Samsung SSD 850,
EMT0> SCSI3
0/direct fixed naa.5002538d4019e022 
 sd0: 238475MB, 512
bytes/sector, 488397168 sectors, thin 
 sd1 at scsibus1 targ 1 lun 0: <ATA,
ST4000VN000-1H41, SC46> SCSI3
0/direct fixed naa.5000c50079458b1b 
 sd1:
3815447MB, 512 bytes/sector, 7814037168 sectors 
 sd2 at scsibus1 targ 2 lun
0: <ATA, ST4000VN000-1H41, SC46> SCSI3
0/direct fixed naa.5000c500799ccc22
sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors 
 sd3 at scsibus1 targ 3
lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3
0/direct fixed naa.5000c500794576ca
sd3: 3815447MB, 512 bytes/sector, 7814037168 sectors 
 cd0 at scsibus1 targ 4
lun 0: <HL-DT-ST, DVD-ROM DTA0N, DC01> ATAPI
5/cdrom removable 
 ichiic0 at
pci0 dev 31 function 3 "Intel 8 Series SMBus" rev 0x05:
apic 8 int 18 
 iic0
at ichiic0 
 sdtemp0 at iic0 addr 0x19: mcp98243 
 spdmem0 at iic0 addr 0x51:
4GB DDR3 SDRAM ECC PC3-12800 with thermal
sensor 
 isa0 at pcib0 
 isadma0 at
isa0 
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo 
 com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12 
 pckbd0 at pckbc0 (kbd slot) 
 wskbd0
at pckbd0: console keyboard, using wsdisplay0 
 pcppi0 at isa0 port 0x61
spkr0 at pcppi0 
 vmm disabled by firmware 
 vmm at mainbus0 not configured
error: [drm:pid0:intel_uncore_check_errors] *ERROR* Unclaimed
register before
interrupt 
 uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate
Matching Hub" rev 2.00/0.05 addr 2 
 uhub4 at uhub2 port 1 configuration 1
interface 0 "Intel Rate
Matching Hub" rev 2.00/0.05 addr 2 
 vscsi0 at root
scsibus2 at vscsi0: 256 targets 
 softraid0 at root 
 scsibus3 at softraid0:
256 targets 
 sd4 at scsibus3 targ 1 lun 0: <OPENBSD, SR RAID 1, 006> SCSI2
0/direct fixed 
 sd4: 3815447MB, 512 bytes/sector, 7814036576 sectors 
 root
on sd0a (918dcdbb8c221cb4.a) swap on sd0b dump on sd0b 

-- 
 Joe Gidi
j...@entropicblur.com

 "You cannot buy skill." -- Ross Seyfried



Re: Setting rtable 0 from >1 with ping et al

2017-03-16 Thread Joe Holden

On 09/03/2017 23:35, Joe Holden wrote:

On 09/03/2017 23:02, Joe Holden wrote:

Hi,

So - it seems that pledge will deny a change of rtable to 0 when using
level SOL_SOCKET and the current rtable is >0, so eg if you're in table
1 and you do ping -V0 it will fail.

Can anyone shed any light on why this is restricted?  Especially since
the same can be achieved with route -T0 exec

Thanks!


Actually, just realised why it doesn't work - it drops privs before
setting rtable, nevermind.


Something like:

Index: sbin/ping/ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.218
diff -u -p -r1.218 ping.c
--- sbin/ping/ping.c22 Feb 2017 13:43:35 -  1.218
+++ sbin/ping/ping.c16 Mar 2017 19:58:28 -
@@ -283,10 +283,6 @@ main(int argc, char *argv[])
uid = getuid();
gid = getgid();
}
-   if (setgroups(1, ) ||
-   setresgid(gid, gid, gid) ||
-   setresuid(uid, uid, uid))
-   err(1, "unable to revoke privs");

preload = 0;
datap = [ECHOLEN + ECHOTMLEN];
@@ -427,6 +423,11 @@ main(int argc, char *argv[])
usage();
}
}
+
+   if (setgroups(1, ) ||
+   setresgid(gid, gid, gid) ||
+   setresuid(uid, uid, uid))
+   err(1, "unable to revoke privs");

argc -= optind;
argv += optind;


perhaps, but haven't closely looked if there is any scope for escalation 
or anything during option parsing




Hey

2017-03-11 Thread Joe Nosay
What's up, people?
Compatibility should be equivalent to the architecture being used.
Whatever the scenario, there will always be the necessity of creating layers
of abstraction for security. One could create a jailed/chroot environment
for the compat layer. The next step would be creating a virtual and
headless machine.
SSH keys would need to be created. Create files in other jailed
environments.
Connect to the jailed environment from the desktop.

Yes, that is a lot, and, just on one side.

People use the excuse of, "I need an incentive."

No. You are going to do it when you want.

Anyway,
may all of you have a blessed and goodly day.



Re: Setting rtable 0 from >1 with ping et al

2017-03-09 Thread Joe Holden

On 09/03/2017 23:02, Joe Holden wrote:

Hi,

So - it seems that pledge will deny a change of rtable to 0 when using
level SOL_SOCKET and the current rtable is >0, so eg if you're in table
1 and you do ping -V0 it will fail.

Can anyone shed any light on why this is restricted?  Especially since
the same can be achieved with route -T0 exec

Thanks!

Actually, just realised why it doesn't work - it drops privs before 
setting rtable, nevermind.




Setting rtable 0 from >1 with ping et al

2017-03-09 Thread Joe Holden

Hi,

So - it seems that pledge will deny a change of rtable to 0 when using 
level SOL_SOCKET and the current rtable is >0, so eg if you're in table 
1 and you do ping -V0 it will fail.


Can anyone shed any light on why this is restricted?  Especially since 
the same can be achieved with route -T0 exec


Thanks!



Re: Bizarre arp entry corruption

2017-03-09 Thread Joe Holden

On 09/03/2017 11:51, Martin Pieuchot wrote:

On 07/03/17(Tue) 19:38, Joe Holden wrote:

On 12/12/2016 16:55, Joe Holden wrote:

On 12/12/2016 10:27, Martin Pieuchot wrote:

On 11/12/16(Sun) 00:50, Joe Holden wrote:

On 10/12/2016 08:43, Mihai Popescu wrote:

seeing some bizarre behaviour on one box, on one specific interface:


Hello,

This looks like some stupid TV game, where contesters are given some
clues from time to time and they have to guess what is the real shit.

Do post your FULL dmesg and configurations for network if you really
want someone to even think at your issue. Isn't that obvious?

Bye!



Appreciate the useless response (but still better than nothing!), the
affected box has since been reverted to older snapshot and thus no more
debugging can be done - someone else will have to do it.


I'd appreciate to see the output of 'netstat -rnf inet' when it is
relevant.  Without that information it's hard to understand.

But there's a bug somewhere, it has to be fixed.


Not that dmesg is even relevant since it is a userland bug not a kernel
problem but anyway:


It's a kernel problem.


I'll see if I can recreate it but I'm not holding my breath - it only
breaks once BGP loaded the table which leads me to thing it is actually
bgpd that is updating the llinfo with bogus info and even though I have
a feed in my lab it doesn't do the same thing.


Ok so, inadvertantly recreated this (pretty much exactly the same) issue on
a lab/test setup:

For the purposes of debug, ignore the fact that the interfaces are tap
interfaces, they're still emulated ethernet...

Wall of text incoming, various info...

box#1:

tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d1:be:f3
index 7 priority 0 llprio 3
groups: tap
status: active
inet 172.20.230.72 netmask 0xfffe

box#2:

tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d1:cf:92
index 7 priority 0 llprio 3
groups: tap
status: active
inet 172.20.230.73 netmask 0xfffe

All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows
the following:

Host Ethernet AddressNetif Expire Flags
172.20.230.7200:00:00:00:20:12   ? 12m30s

# route -n get 172.20.230.72
   route to: 172.20.230.72
destination: 172.20.230.72
   mask: 255.255.255.255
  interface: tap1
 if address: 172.20.230.73
   priority: 3 ()
  flags: <UP,HOST,DONE,LLINFO,CLONED,CACHED>
 use   mtuexpire
  20 0   702

flags destination  gateway  lpref   med aspath origin
IS*>  172.20.230.72/31 172.20.230.64  200 0 i

.64 is the loopback on one of its connected boxes that doesn't have broken
entries

tcpdump looks ok, afterwards:

19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73
19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73
19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3

but the correct entry is never installed, after I delete the broken arp
entry it never readds a new one.

This only happens with redist connected as far as I can tell, but bgpd
probably shouldn't be able to mangle arp entries and prevent the correct one
being added.


Here's the fix.

Index: net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.232
diff -u -p -r1.232 rtsock.c
--- net/rtsock.c7 Mar 2017 09:23:27 -   1.232
+++ net/rtsock.c8 Mar 2017 16:06:22 -
@@ -895,10 +895,22 @@ rtm_output(struct rt_msghdr *rtm, struct
}
}
 change:
-   if (info->rti_info[RTAX_GATEWAY] != NULL && (error =
-   rt_setgate(rt, info->rti_info[RTAX_GATEWAY],
-   tableid)))
-   break;
+   if (info->rti_info[RTAX_GATEWAY] != NULL) {
+   /*
+* When updating the gateway, make sure it's
+* valid.
+*/
+   if (!newgate && rt->rt_gateway->sa_family !=
+   info->rti_info[RTAX_GATEWAY]->sa_family) {
+   error = EINVAL;
+   break;
+   }
+
+   error = rt_setgate(rt,
+   info->rti_info[RTAX_GATEWAY], tableid);
+   if (error)
+   break;
+   }
 #ifdef MPLS
if ((rtm->rtm_flags & RTF_M

Re: Bizarre arp entry corruption

2017-03-07 Thread Joe Holden

On 12/12/2016 16:55, Joe Holden wrote:

On 12/12/2016 10:27, Martin Pieuchot wrote:

On 11/12/16(Sun) 00:50, Joe Holden wrote:

On 10/12/2016 08:43, Mihai Popescu wrote:

seeing some bizarre behaviour on one box, on one specific interface:


Hello,

This looks like some stupid TV game, where contesters are given some
clues from time to time and they have to guess what is the real shit.

Do post your FULL dmesg and configurations for network if you really
want someone to even think at your issue. Isn't that obvious?

Bye!



Appreciate the useless response (but still better than nothing!), the
affected box has since been reverted to older snapshot and thus no more
debugging can be done - someone else will have to do it.


I'd appreciate to see the output of 'netstat -rnf inet' when it is
relevant.  Without that information it's hard to understand.

But there's a bug somewhere, it has to be fixed.


Not that dmesg is even relevant since it is a userland bug not a kernel
problem but anyway:


It's a kernel problem.


I'll see if I can recreate it but I'm not holding my breath - it only
breaks once BGP loaded the table which leads me to thing it is actually
bgpd that is updating the llinfo with bogus info and even though I have
a feed in my lab it doesn't do the same thing.

Ok so, inadvertantly recreated this (pretty much exactly the same) issue 
on a lab/test setup:


For the purposes of debug, ignore the fact that the interfaces are tap 
interfaces, they're still emulated ethernet...


Wall of text incoming, various info...

box#1:

tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d1:be:f3
index 7 priority 0 llprio 3
groups: tap
status: active
inet 172.20.230.72 netmask 0xfffe

box#2:

tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr fe:e1:ba:d1:cf:92
index 7 priority 0 llprio 3
groups: tap
status: active
inet 172.20.230.73 netmask 0xfffe

All is fine after starting ospfd, but as soon as I start bgpd, box#2 
shows the following:


Host Ethernet AddressNetif Expire 
Flags

172.20.230.7200:00:00:00:20:12   ? 12m30s

# route -n get 172.20.230.72
   route to: 172.20.230.72
destination: 172.20.230.72
   mask: 255.255.255.255
  interface: tap1
 if address: 172.20.230.73
   priority: 3 ()
  flags: <UP,HOST,DONE,LLINFO,CLONED,CACHED>
 use   mtuexpire
  20 0   702

flags destination  gateway  lpref   med aspath origin
IS*>  172.20.230.72/31 172.20.230.64  200 0 i

.64 is the loopback on one of its connected boxes that doesn't have 
broken entries


tcpdump looks ok, afterwards:

19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73
19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3
19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73
19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3

but the correct entry is never installed, after I delete the broken arp 
entry it never readds a new one.


This only happens with redist connected as far as I can tell, but bgpd 
probably shouldn't be able to mangle arp entries and prevent the correct 
one being added.


If someone thinks they can diag/fix it then hit me up off-list and I can 
fire over ssh details.


Thanks



Re: Raspberry Pi 3 booting from USB

2017-03-05 Thread Joe Gidi
I was stuck at that point for a while. Make sure you have everything you need
to boot on the DOS partition of your USB drive; mine was missing u-boot.bin.
Are you using the bootcode.bin and start.elf files from Raspbian?


On March 5, 2017 9:25:59 AM EST, Otto Moerbeek  wrote:
>On Mon, Mar 06, 2017 at 12:36:55AM +1100, Jonathan Gray wrote:
>
>> The arm64 miniroot and bsd.rd already include fixup.dat and dtbs
>> from https://github.com/raspberrypi/firmware/tree/master/boot
>>
>> There is no need to manually change them.
>
>I managed to get usb booting to work on a external powered device, bus
>powered so far is not working for me.
>
>Also, I need to keep the sd card in, I might have done something
>wrong with the setting of the vars. If I leave the sd card out nothing
>happens on power up.
>
>By telling u-boot to prefer usb0 over mmc0 I got usb booting to work:
>
>setenv boot_targets usb0 mmc0 pxe dhcp
>saveenv
>
>   -Otto

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: Raspberry Pi 3 booting from USB

2017-03-05 Thread Joe Gidi
In the case of my admittedly Frankensteined system, it was needed. The files
from Raspbian were different. I will do a clean install when the next snap
comes out with the latest firmware, DTBs, etc.

Do you know why u-boot.bin didn't make it to my USB drive during installation
and had to be manually added?

Thanks,

On March 5, 2017 8:36:55 AM EST, Jonathan Gray <j...@jsg.id.au> wrote:
>The arm64 miniroot and bsd.rd already include fixup.dat and dtbs
>from https://github.com/raspberrypi/firmware/tree/master/boot
>
>There is no need to manually change them.
>
>On Sun, Mar 05, 2017 at 08:21:56AM -0500, Joe Gidi wrote:
>> >From further tinkering, I discovered that my Pi was only recognizing
>128 MB of
>> RAM until I switched to using the DTB and fixup.dat files from
>Raspbian. Seems
>> that those /boot/ files should be kept in sync.
>>
>> Thanks for all your work on this new platform!
>>
>> On March 5, 2017 3:36:16 AM EST, Jonathan Gray <j...@jsg.id.au> wrote:
>> >On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote:
>> >> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:
>> >>
>> >> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
>> >> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
>> >> > >
>> >> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a
>USB
>> >device
>> >> > > > might be
>> >> > > > possible, I decided to find out how deep the rabbit hole is.
>> >> > > > As it turns out,
>> >> > > > it's currently a bit convoluted, but it can be made
>> >> > > > to work with OpenBSD.
>> >> > > > First off, USB boot support is just now getting fully ironed
>> >out.
>> >> > > > You'll need
>> >> > > > to update the firmware on your Pi to make it work. I
>> >> > > > installed the latest
>> >> > > > (2017-03-02) Raspbian image to an SD card and
>> >> > > > booted the Pi from that. While
>> >> > > > booted in Raspbian, update the
>> >> > > > firmware:
>> >> > > >
>> >> > > > sudo apt-get update
>> >> > > > sudo apt-get
>> >> > > > install rpi-update
>> >> > > > sudo rpi-update
>> >> > > >
>> >> > > > It's then necessary to actually enable USB
>> >> > > > boot support. Add the
>> >> > > > following 2 lines to /boot/config.txt to enable USB boot
>> >> > > > mode and set
>> >> > > > a 5-second timeout to allow time for USB device
>initialization:
>> >> > > > program_usb_boot_mode=1
>> >> > > > program_usb_boot_timeout=1
>> >> > > >
>> >> > > > NOTE: Apparently these
>> >> > > > variables are set in the Pi's OTP memory, which
>> >> > > > means once they're set, they
>> >> > > > can't ever be unset.
>> >> > > >
>> >> > > > Reboot for the changes to take effect. At this point the
>> >> > > > Pi should be
>> >> > > > ready to support USB booting.
>> >> > > >
>> >> > > > While you still have a working
>> >> > > > Raspbian install, grab a copy of the
>> >> > > > /boot/bootcode.bin and /boot/start.elf
>> >> > > > files for later use; apparently
>> >> > > > we need these special versions of those two
>> >> > > > files for USB boot
>> >> > > > support. At this point we're done with Raspbian and can
>> >> > > > shut it down
>> >> > > > to install OpenBSD.
>> >> > > >
>> >> > > > Next, write the OpenBSD miniroot60.fs to an
>> >> > > > SD card, plug in your USB
>> >> > > > drive, and boot the Pi. You should be greeted with
>> >> > > > the usual OpenBSD
>> >> > > > installer, and you should be able to install to your USB
>> >> > > > drive
>> >> > > > (probably sd0). Once the installer is done, run 'halt',
>unplug
>> >the Pi,
>> >> > > > and remove the SD card and USB drive.
>> >> > > >
>> >> >

Re: Raspberry Pi 3 booting from USB

2017-03-05 Thread Joe Gidi
>From further tinkering, I discovered that my Pi was only recognizing 128 MB of
RAM until I switched to using the DTB and fixup.dat files from Raspbian. Seems
that those /boot/ files should be kept in sync.

Thanks for all your work on this new platform!

On March 5, 2017 3:36:16 AM EST, Jonathan Gray <j...@jsg.id.au> wrote:
>On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote:
>> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:
>>
>> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
>> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
>> > >
>> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB
>device
>> > > > might be
>> > > > possible, I decided to find out how deep the rabbit hole is.
>> > > > As it turns out,
>> > > > it's currently a bit convoluted, but it can be made
>> > > > to work with OpenBSD.
>> > > > First off, USB boot support is just now getting fully ironed
>out.
>> > > > You'll need
>> > > > to update the firmware on your Pi to make it work. I
>> > > > installed the latest
>> > > > (2017-03-02) Raspbian image to an SD card and
>> > > > booted the Pi from that. While
>> > > > booted in Raspbian, update the
>> > > > firmware:
>> > > >
>> > > > sudo apt-get update
>> > > > sudo apt-get
>> > > > install rpi-update
>> > > > sudo rpi-update
>> > > >
>> > > > It's then necessary to actually enable USB
>> > > > boot support. Add the
>> > > > following 2 lines to /boot/config.txt to enable USB boot
>> > > > mode and set
>> > > > a 5-second timeout to allow time for USB device initialization:
>> > > > program_usb_boot_mode=1
>> > > > program_usb_boot_timeout=1
>> > > >
>> > > > NOTE: Apparently these
>> > > > variables are set in the Pi's OTP memory, which
>> > > > means once they're set, they
>> > > > can't ever be unset.
>> > > >
>> > > > Reboot for the changes to take effect. At this point the
>> > > > Pi should be
>> > > > ready to support USB booting.
>> > > >
>> > > > While you still have a working
>> > > > Raspbian install, grab a copy of the
>> > > > /boot/bootcode.bin and /boot/start.elf
>> > > > files for later use; apparently
>> > > > we need these special versions of those two
>> > > > files for USB boot
>> > > > support. At this point we're done with Raspbian and can
>> > > > shut it down
>> > > > to install OpenBSD.
>> > > >
>> > > > Next, write the OpenBSD miniroot60.fs to an
>> > > > SD card, plug in your USB
>> > > > drive, and boot the Pi. You should be greeted with
>> > > > the usual OpenBSD
>> > > > installer, and you should be able to install to your USB
>> > > > drive
>> > > > (probably sd0). Once the installer is done, run 'halt', unplug
>the Pi,
>> > > > and remove the SD card and USB drive.
>> > > >
>> > > > To make your USB drive bootable, you'll
>> > > > need to plug it into another
>> > > > system and mount its 'i' partition (the FAT32
>> > > > boot partition) to make
>> > > > a few changes. Replace the bootcode.bin and start.elf
>> > > > files with the
>> > > > ones from Raspbian, and add the u-boot.bin file from the 'i'
>> > > > partition
>> > > > of your miniroot60.fs SD card.
>> > > >
>> > > > With those changes made, your Pi
>> > > > should be able to boot OpenBSD
>> > > > directly from a USB drive with no SD card
>> > > > needed. Note that it seems
>> > > > to take around 10 seconds for the Pi to reach the
>> > > > OpenBSD bootloader
>> > > > and fire up the kernel.
>> > > >
>> > > > Hope this information is helpful
>> > > > to someone...
>> > > >
>> > > > --
>> > > >  Joe Gidi
>> > > >  j...@entropicblur.com
>> > > >
>> > > >  "You cannot buy skill."
>> > > > -- Ross Seyfried
>

Re: Raspberry Pi 3 booting from USB

2017-03-04 Thread Joe Gidi
Wow, apologies for the horrible line breaks inserted by this mail
client...
-- 
 Joe Gidi
 j...@entropicblur.com

 "You cannot buy skill." -- Ross Seyfried
- Original Message -----
From: "Joe Gidi" <j...@entropicblur.com>
To:
misc@openbsd.org
Cc: 
Sent: Sat, 04 Mar 2017 18:40:57 -0500
Subject: Raspberry
Pi 3 booting from USB
 After jsg@ mentioned that booting a Raspberry Pi 3 from
a USB device
 might be
 possible, I decided to find out how deep the rabbit
hole is.
 As it turns out,
 it's currently a bit convoluted, but it can be
made
 to work with OpenBSD.
 First off, USB boot support is just now getting
fully ironed out.
 You'll need
 to update the firmware on your Pi to make it
work. I
 installed the latest
 (2017-03-02) Raspbian image to an SD card and
booted the Pi from that. While
 booted in Raspbian, update the
 firmware:
sudo apt-get update
 sudo apt-get
 install rpi-update
 sudo rpi-update

 It's
then necessary to actually enable USB
 boot support. Add the
 following 2
lines to /boot/config.txt to enable USB boot
 mode and set
 a 5-second timeout
to allow time for USB device initialization:
 program_usb_boot_mode=1
program_usb_boot_timeout=1

 NOTE: Apparently these
 variables are set in the
Pi's OTP memory, which
 means once they're set, they
 can't ever be unset.
Reboot for the changes to take effect. At this point the
 Pi should be
 ready
to support USB booting.

 While you still have a working
 Raspbian install,
grab a copy of the
 /boot/bootcode.bin and /boot/start.elf
 files for later
use; apparently
 we need these special versions of those two
 files for USB
boot
 support. At this point we're done with Raspbian and can
 shut it down
to install OpenBSD.

 Next, write the OpenBSD miniroot60.fs to an
 SD card,
plug in your USB
 drive, and boot the Pi. You should be greeted with
 the
usual OpenBSD
 installer, and you should be able to install to your USB
 drive
(probably sd0). Once the installer is done, run 'halt', unplug the
Pi,
 and
remove the SD card and USB drive.

 To make your USB drive bootable, you'll
need to plug it into another
 system and mount its 'i' partition (the FAT32
boot partition) to make
 a few changes. Replace the bootcode.bin and start.elf
files with the
 ones from Raspbian, and add the u-boot.bin file from the 'i'
partition
 of your miniroot60.fs SD card.

 With those changes made, your Pi
should be able to boot OpenBSD
 directly from a USB drive with no SD card
needed. Note that it seems
 to take around 10 seconds for the Pi to reach the
OpenBSD bootloader
 and fire up the kernel.

 Hope this information is helpful
to someone...

 -- 
 Joe Gidi
 j...@entropicblur.com

 "You cannot buy skill."
-- Ross Seyfried



Raspberry Pi 3 booting from USB

2017-03-04 Thread Joe Gidi
After jsg@ mentioned that booting a Raspberry Pi 3 from a USB device
might be
possible, I decided to find out how deep the rabbit hole is.
As it turns out,
it's currently a bit convoluted, but it can be made
to work with OpenBSD.
First off, USB boot support is just now getting fully ironed out.
You'll need
to update the firmware on your Pi to make it work. I
installed the latest
(2017-03-02) Raspbian image to an SD card and
booted the Pi from that. While
booted in Raspbian, update the
firmware:

sudo apt-get update
sudo apt-get
install rpi-update
sudo rpi-update

It's then necessary to actually enable USB
boot support. Add the
following 2 lines to /boot/config.txt to enable USB boot
mode and set
a 5-second timeout to allow time for USB device initialization:
program_usb_boot_mode=1
program_usb_boot_timeout=1

NOTE: Apparently these
variables are set in the Pi's OTP memory, which
means once they're set, they
can't ever be unset.

Reboot for the changes to take effect. At this point the
Pi should be
ready to support USB booting.

While you still have a working
Raspbian install, grab a copy of the
/boot/bootcode.bin and /boot/start.elf
files for later use; apparently
we need these special versions of those two
files for USB boot
support. At this point we're done with Raspbian and can
shut it down
to install OpenBSD.

Next, write the OpenBSD miniroot60.fs to an
SD card, plug in your USB
drive, and boot the Pi. You should be greeted with
the usual OpenBSD
installer, and you should be able to install to your USB
drive
(probably sd0). Once the installer is done, run 'halt', unplug the Pi,
and remove the SD card and USB drive.

To make your USB drive bootable, you'll
need to plug it into another
system and mount its 'i' partition (the FAT32
boot partition) to make
a few changes. Replace the bootcode.bin and start.elf
files with the
ones from Raspbian, and add the u-boot.bin file from the 'i'
partition
of your miniroot60.fs SD card.

With those changes made, your Pi
should be able to boot OpenBSD
directly from a USB drive with no SD card
needed. Note that it seems
to take around 10 seconds for the Pi to reach the
OpenBSD bootloader
and fire up the kernel.

Hope this information is helpful
to someone...

-- 
 Joe Gidi
 j...@entropicblur.com

 "You cannot buy skill."
-- Ross Seyfried



arm64 Raspberry Pi 3 - no disks available?

2017-03-01 Thread Joe Gidi
I know the arm64 port is still in its early days and under heavy
development,
but I'm trying to install the most recent available
snapshot and running into
a problem.

I wrote the miniroot60.fs to an SD card and powered up the system.
Serial console works fine, and the installer functions as usual, up
until:
Available disks are: none.
Which disk is the root disk? ('?' for details)
Indeed, dmesg shows no sd devices, even though it just booted from
sd0:
OpenBSD 6.0-current (RAMDISK) #0: Tue Feb 28 15:58:10 AEDT 2017
   
j...@arm64.jsg.id.au:/usr/src/sys/arch/arm64/compile/RAMDISK
real mem  =
989855744 (944MB)
avail mem = 928395264 (885MB)
mainbus0 at root: Raspberry Pi
3 Model B Rev 1.2
simplebus0 at mainbus0: "soc"
bcmintc0 at simplebus0
bcmdog0
at simplebus0
pluart0 at simplebus0
com0 at simplebus0: ns16550, no working
fifo
com0: console
dwctwo0 at simplebus0
agtimer0 at simplebus0: tick rate
19200 KHz
simplebus1 at mainbus0: "clocks"
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev
2.00/1.00 addr 1
uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard
Microsystems product 0x9514" rev 2.00/2.00 addr 2
smsc0 at uhub1 port 1
configuration 1 interface 0 "Standard
Microsystems SMSC9512/14" rev 2.00/2.00
addr 3
smsc0: address b8:27:eb:02:4e:20
ukphy0 at smsc0 phy 1: Generic IEEE
802.3u media interface, rev. 3:
OUI 0x0001f0, model 0x000c
bootfile: sd0a:/bsd
boot device: lookup sd0a:/bsd failed 
WARNING: CHECK AND RESET THE DATE!

Is
this expected at this point? Should I be trying to install to
another device,
like a USB hard drive?

Thanks for any hints.

-- 
 Joe Gidi
j...@entropicblur.com

 "You cannot buy skill." -- Ross Seyfried



What is the future of the multicast routing daemons in OpenBSD?

2017-01-01 Thread Joe Crivello
I am wondering about the future of the multicast routing daemons in base on
OpenBSD -- is the future in mrouted(8), or dvmrpd(8), or something else? I
am aware that dvmrpd(8) is the newer codebase -- but when I have tried to
use it in practice I have had consistent problems with the daemon crashing
under normal scenarios.

In my most recent dvmrpd test scenario, I set net.inet.ip.mforwarding to 1,
created the following dvmrpd.conf configuration file, ran the daemon in
debug mode and then started the Windows version of the Sonos Controller
application on, in this scenario, VLAN 3 (which immediately makes dvmrpd
crash):

# cat dvmrpd.conf
group {
  interface vlan3
  interface vlan5
}

# dvmrpd -dvf /etc/dvmrpd.conf
startup
kmr_init: interface vlan5
kmr_init: interface vlan3
fsm_if: event 'UP' resulted in action 'START' and changing state for
interface vlan5 from 'DOWN' to 'QUERIER'
fsm_if: event 'UP' resulted in action 'START' and changing state for
interface vlan3 from 'DOWN' to 'QUERIER'
rt_insert: inserting route 10.82.5.0/24
rt_insert: inserting route 10.82.3.0/24
send_igmp_query: interface vlan5
send_igmp_query: interface vlan3
[... START SONOS CONTROLLER ON VLAN 3 ...]
mfc_start_expire_timer: group 239.255.255.250
mfc_start_prune_timer: group 239.255.255.250
fatal in dvmrpe: unknown neighbor to send prune
mrt_add_mfc: interface 13, group 239.255.255.250
fatal in rde: pipe closed
fatal in parent: pipe closed

Initially, the daemon _appears_ to be running fine, until I start the Sonos
Controller application at the point indicated above, when the daemon
immediately outputs the errors shown above and exits. The culprit packet
that appears to cause dvmrpd to crash is a SSDP discovery packet sent by
the Sonos Controller application to 239.255.255.250 (see below):

tcpdump: listening on vlan3, link-type EN10MB
17:45:10.417081 10.82.3.1 > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id
23931, len 28)
17:45:10.417103 10.82.3.1 > 224.0.0.4: igmp dvmrp Probe
genid 2257873240 [tos 0xc0] [ttl 1] (id 35152, len 32)
17:45:19.248851 10.82.3.100 > 239.255.255.250: igmp nreport 239.255.255.250
[ttl 1] (id 31513, len 32, optlen=4 IPOPT-148{4})
17:45:20.426728 10.82.3.1 > 224.0.0.4: igmp dvmrp Probe
genid 2257873240 [tos 0xc0] [ttl 1] (id 41676, len 32)
[... START SONOS CONTROLLER ON VLAN 3 ...]
17:45:25.376993 10.82.3.100.1901 > 239.255.255.250.1900: udp 230 (ttl 4, id
31514, len 258)

I have had relatively more success with mrouted(8). It seems to work in
most of the scenarios I have used it in, although in one case I have not
been able to get it to work on one particular piece of hardware for no
discernible reason -- no errors, no warnings found anywhere, it just fails
to route multicast packets. mrouted(8) has a significant limitation though
-- it only supports 32 VIFs on the entire system. If you have more than 32
virtual interfaces it will ignore the 33rd interface and beyond (the system
decides the ordering of the interfaces).

I can't use igmpproxy from ports because I require multiple "upstream"
interfaces.

I have been thinking about jumping into the code to try to address these
issues, but I'm not sure where to direct my efforts. I am inclined to focus
on the crash in dvmrpd -- but it's not clear from anything I have read that
dvmrpd is the future of multicast routing in OpenBSD. I have briefly looked
into the feasibility of increasing the number of VIFs supported by mrouted,
and it looks like that may be non-trivial, and it seems even less likely
that mrouted is the future of multicast routing on OpenBSD. I am also
troubled by the no error, no warning failure of mrouted on the system I
described above -- wouldn't even know where to start with that one.

Thanks in advance for any advice on this subject...

Joe Crivello



Re: Bizarre arp entry corruption

2016-12-12 Thread Joe Holden

On 12/12/2016 10:27, Martin Pieuchot wrote:

On 11/12/16(Sun) 00:50, Joe Holden wrote:

On 10/12/2016 08:43, Mihai Popescu wrote:

seeing some bizarre behaviour on one box, on one specific interface:


Hello,

This looks like some stupid TV game, where contesters are given some
clues from time to time and they have to guess what is the real shit.

Do post your FULL dmesg and configurations for network if you really
want someone to even think at your issue. Isn't that obvious?

Bye!



Appreciate the useless response (but still better than nothing!), the
affected box has since been reverted to older snapshot and thus no more
debugging can be done - someone else will have to do it.


I'd appreciate to see the output of 'netstat -rnf inet' when it is
relevant.  Without that information it's hard to understand.

But there's a bug somewhere, it has to be fixed.


Not that dmesg is even relevant since it is a userland bug not a kernel
problem but anyway:


It's a kernel problem.

I'll see if I can recreate it but I'm not holding my breath - it only 
breaks once BGP loaded the table which leads me to thing it is actually 
bgpd that is updating the llinfo with bogus info and even though I have 
a feed in my lab it doesn't do the same thing.




Re: Bizarre arp entry corruption

2016-12-10 Thread Joe Holden

On 10/12/2016 08:43, Mihai Popescu wrote:

seeing some bizarre behaviour on one box, on one specific interface:


Hello,

This looks like some stupid TV game, where contesters are given some
clues from time to time and they have to guess what is the real shit.

Do post your FULL dmesg and configurations for network if you really
want someone to even think at your issue. Isn't that obvious?

Bye!



Appreciate the useless response (but still better than nothing!), the 
affected box has since been reverted to older snapshot and thus no more 
debugging can be done - someone else will have to do it.


Not that dmesg is even relevant since it is a userland bug not a kernel 
problem but anyway:


OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec  7 12:07:13 MST 2016
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4273471488 (4075MB)
avail mem = 4139397120 (3947MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9d000 (74 entries)
bios0: vendor American Megatrends Inc. version "1ADQW068" date 11/16/2010
bios0: Sun Microsystems SUN FIRE X4150
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S5
acpi0: tables DSDT FACP APIC SPCR MCFG SSDT OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices SPE4(S1) SPE2(S1) SPE1(S1) P8PC(S1) P0P1(S1) 
UAR1(S1) P0P5(S1) P0P6(S1) P0P7(S1) NPE4(S1) NPE5(S1) NPE6(S1) NPE7(S1) 
USB0(S1) USB1(S1) USB2(S1) [...]

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 E5450 @ 3.00GHz, 4189.89 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR

cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 332MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.51 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR

cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.51 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR

cpu2: 6MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.52 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR

cpu3: 6MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec8, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (NPES)
acpiprt2 at acpi0: bus 2 (SPE4)
acpiprt3 at acpi0: bus -1 (SPE2)
acpiprt4 at acpi0: bus 3 (SPE1)
acpiprt5 at acpi0: bus 4 (P8PC)
acpiprt6 at acpi0: bus 15 (P0P1)
acpiprt7 at acpi0: bus -1 (P0P5)
acpiprt8 at acpi0: bus -1 (P0P6)
acpiprt9 at acpi0: bus -1 (P0P7)
acpiprt10 at acpi0: bus 7 (NPE4)
acpiprt11 at acpi0: bus 11 (NPE5)
acpiprt12 at acpi0: bus 12 (NPE6)
acpiprt13 at acpi0: bus 13 (NPE7)
acpiprt14 at acpi0: bus 14 (P0P4)
acpiprt15 at acpi0: bus -1 (BR1E)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
"PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
"IPI0001" at acpi0 not configured
ipmi at mainbus0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 5000P Host" rev 0xb1
ppb0 at pci0 dev 2 function 0 "Intel 5000 PCIE" rev 0xb1
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01
pci2 at ppb1 bus 2
ppb2 at pci2 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01
pci3 at ppb2 bus 3
ppb3 at pci2 dev 2 function 0 "Intel 6321ESB PCIE" rev 0x01
pci4 at ppb3 bus 4
em0 at pci4 dev 0 function 0 "Intel 80003ES2" rev 0x01: msi, address 
00:23:8b:57:b4:9e
em1 at pci4 dev 0 function 1 "Intel 80003ES2" rev 0x01: msi, address 
00:23:8b:57:b4:9f

ppb4 at pci1 dev 0 function 3 "Intel 6321ESB PCIE-PCIX" rev 0x01
pci5 at ppb4 bus 5
ppb5 at pci0 dev 3 function 0 "Intel 5000 PCIE" rev 0xb1
pci6 at ppb5 bus 

Re: Bizarre arp entry corruption

2016-12-09 Thread Joe Holden

On 08/12/2016 14:35, Joe Holden wrote:

On 08/12/2016 13:56, Joe Holden wrote:

Hi guys,

I've just updated a couple of boxes to the Dec 7th snapshot and I'm
seeing some bizarre behaviour on one box, on one specific interface:

The box in question is an OSPF and BGP speaker, and the following
happens when booted:

After OSPF and BGP tables load, a couple of minutes later the following
appear:

Dec  8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0
Dec  8 06:33:03 edge-pe-2 last message repeated 2 times
Dec  8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp
information

Then some seconds later:

Dec  8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0

At this point the arp entry for the neighbour in question has been
updated so that the lladdr is all zeros and the interface is simply '?'
according to arp -n.

The box it is paired with that has a pretty much identical config
doesn't exhibit the same problem and this only occurs on the single em0
interface (the box has about 6 active in total, mix of em and ix).


I should clarify that this isn't CARP, but rather the box it is directly
connected to.


OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec  7 12:07:13 MST 2016
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


I don't see any odd behaviour on the wire, according to pcap the who-has
and associated reply is seen once as expected with the correct lladdr,
but at some point it gets overwritten with the above.

Previous kernel was about 2 months old which leaves a large number of
commits to check through - I can't see anything that might cause this
from a quick look though so I was hoping someone might have an idea.

For now i've had to add a static arp entry with permanent to prevent it
misbehaving but that has stopped working at least once so far.

I also have limited debug ability as the box is part of a live network
and obviously it causes disruption, and I can't recreate it in a lab
with identical configurations.

Any pointers appreciated!

Cheers


Actually looks like it breaks when BGP comes up, a route -nvd get  
looks ok, but what else should I be checking?


After it breaks it doesn't seem to want to do any arp resolution on the 
interface until it I do down/up...




Re: Bizarre arp entry corruption

2016-12-08 Thread Joe Holden

On 08/12/2016 13:56, Joe Holden wrote:

Hi guys,

I've just updated a couple of boxes to the Dec 7th snapshot and I'm
seeing some bizarre behaviour on one box, on one specific interface:

The box in question is an OSPF and BGP speaker, and the following
happens when booted:

After OSPF and BGP tables load, a couple of minutes later the following
appear:

Dec  8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0
Dec  8 06:33:03 edge-pe-2 last message repeated 2 times
Dec  8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp
information

Then some seconds later:

Dec  8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0

At this point the arp entry for the neighbour in question has been
updated so that the lladdr is all zeros and the interface is simply '?'
according to arp -n.

The box it is paired with that has a pretty much identical config
doesn't exhibit the same problem and this only occurs on the single em0
interface (the box has about 6 active in total, mix of em and ix).

I should clarify that this isn't CARP, but rather the box it is directly 
connected to.



OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec  7 12:07:13 MST 2016
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


I don't see any odd behaviour on the wire, according to pcap the who-has
and associated reply is seen once as expected with the correct lladdr,
but at some point it gets overwritten with the above.

Previous kernel was about 2 months old which leaves a large number of
commits to check through - I can't see anything that might cause this
from a quick look though so I was hoping someone might have an idea.

For now i've had to add a static arp entry with permanent to prevent it
misbehaving but that has stopped working at least once so far.

I also have limited debug ability as the box is part of a live network
and obviously it causes disruption, and I can't recreate it in a lab
with identical configurations.

Any pointers appreciated!

Cheers




Bizarre arp entry corruption

2016-12-08 Thread Joe Holden

Hi guys,

I've just updated a couple of boxes to the Dec 7th snapshot and I'm 
seeing some bizarre behaviour on one box, on one specific interface:


The box in question is an OSPF and BGP speaker, and the following 
happens when booted:


After OSPF and BGP tables load, a couple of minutes later the following 
appear:


Dec  8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0
Dec  8 06:33:03 edge-pe-2 last message repeated 2 times
Dec  8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp 
information


Then some seconds later:

Dec  8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0

At this point the arp entry for the neighbour in question has been 
updated so that the lladdr is all zeros and the interface is simply '?' 
according to arp -n.


The box it is paired with that has a pretty much identical config 
doesn't exhibit the same problem and this only occurs on the single em0 
interface (the box has about 6 active in total, mix of em and ix).


OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec  7 12:07:13 MST 2016
bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


I don't see any odd behaviour on the wire, according to pcap the who-has 
and associated reply is seen once as expected with the correct lladdr, 
but at some point it gets overwritten with the above.


Previous kernel was about 2 months old which leaves a large number of 
commits to check through - I can't see anything that might cause this 
from a quick look though so I was hoping someone might have an idea.


For now i've had to add a static arp entry with permanent to prevent it 
misbehaving but that has stopped working at least once so far.


I also have limited debug ability as the box is part of a live network 
and obviously it causes disruption, and I can't recreate it in a lab 
with identical configurations.


Any pointers appreciated!

Cheers



Re: High loadavg on recent snapshots?

2016-12-02 Thread Joe Holden

On 02/12/2016 12:45, Otto Moerbeek wrote:

On Fri, Dec 02, 2016 at 09:55:23AM +, Joe Holden wrote:


Hi guys,

Is anyone else seeing abnormally high load averages on recent snapshots?

Seeing load reported as ~1 on idle machines (both VM and physical, amd64 and
octeon):

 9:48AM  up 34 mins, 1 user, load averages: 1.21, 1.13, 1.01
(octeon snapshot as of 30th Nov)


This is known and due to a different way some kernel threads operate.
Maybe a bit unexpected, but not harmful, the processor(s) as seen in
top(1) should be idle most if the time.

-Otto

Yeah - not concerned just a huge increase in idle average that doesn't 
correlate to any activity compared to snapshots from a week or so ago






Another example on KVM guest:

USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
root 1  0.0  0.1   416   496 ??  Is 6:54PM0:01.23 /sbin/init
root 50624  0.0  0.1   632   536 ??  Is 6:55PM0:00.38 dhclient:
vio2 [priv] (dhclient)
_dhcp42339  0.0  0.1   736   696 ??  Isp6:55PM0:00.19 dhclient:
vio2 (dhclient)
root 26736  0.0  0.4   364  1976 ??  Isp6:55PM0:00.27 syslogd:
[priv] (syslogd)
_syslogd  7398  0.0  0.3   968  1488 ??  Sp 6:55PM0:00.68
/usr/sbin/syslogd
root 64373  0.0  0.3   872  1452 ??  Is 6:55PM0:00.12
/usr/sbin/sshd
root 38751  0.0  0.2   676  1188 ??  Isp6:55PM0:00.35
/usr/sbin/cron
root 80570  0.0  0.7   980  3396 ??  Ss 9:20PM0:54.17 sshd:
root@ttyp0 (sshd)
root 30271  0.0  0.1   612   744 p0  Ssp9:20PM0:00.34 -ksh (ksh)
root 84509  0.0  0.1   356   412 p0  R+p/0  4:03AM0:00.00 ps -auxw
root 99508  0.0  0.1   608   736 00  Is+p   6:55PM0:02.80 -ksh (ksh)

 4:03AM  up  9:09, 2 users, load averages: 1.26, 1.18, 1.11

(amd64 snapshot as of 27th Nov)

Thanks




High loadavg on recent snapshots?

2016-12-02 Thread Joe Holden

Hi guys,

Is anyone else seeing abnormally high load averages on recent snapshots?

Seeing load reported as ~1 on idle machines (both VM and physical, amd64 
and octeon):


 9:48AM  up 34 mins, 1 user, load averages: 1.21, 1.13, 1.01
(octeon snapshot as of 30th Nov)

Another example on KVM guest:

USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
root 1  0.0  0.1   416   496 ??  Is 6:54PM0:01.23 /sbin/init
root 50624  0.0  0.1   632   536 ??  Is 6:55PM0:00.38 
dhclient: vio2 [priv] (dhclient)
_dhcp42339  0.0  0.1   736   696 ??  Isp6:55PM0:00.19 
dhclient: vio2 (dhclient)
root 26736  0.0  0.4   364  1976 ??  Isp6:55PM0:00.27 
syslogd: [priv] (syslogd)
_syslogd  7398  0.0  0.3   968  1488 ??  Sp 6:55PM0:00.68 
/usr/sbin/syslogd
root 64373  0.0  0.3   872  1452 ??  Is 6:55PM0:00.12 
/usr/sbin/sshd
root 38751  0.0  0.2   676  1188 ??  Isp6:55PM0:00.35 
/usr/sbin/cron
root 80570  0.0  0.7   980  3396 ??  Ss 9:20PM0:54.17 sshd: 
root@ttyp0 (sshd)

root 30271  0.0  0.1   612   744 p0  Ssp9:20PM0:00.34 -ksh (ksh)
root 84509  0.0  0.1   356   412 p0  R+p/0  4:03AM0:00.00 ps -auxw
root 99508  0.0  0.1   608   736 00  Is+p   6:55PM0:02.80 -ksh (ksh)

 4:03AM  up  9:09, 2 users, load averages: 1.26, 1.18, 1.11

(amd64 snapshot as of 27th Nov)

Thanks



  1   2   3   4   5   >