Re: What's good safe PPC/MIPS/SPARC networking hardware with open firmware that works well with OpenBSD? Many ethernet plugs and 1U rack mount = bonus.

[Tinker]

On 2016-02-28 05:26, Karel Gardas wrote:

Open firmware? What do you mean by that precisely?


Or just as little firmware as possible, just to minimize that as attack 
vector.



Anyway, while asking such question it would also help if you tell
something about intended usage scenario of such box(es). fw?/app
server?/storage?/nas? etc.


Network infrastructure, so, among those categories it would be FW.


What hardware is advisable here?


On Sat, Feb 27, 2016 at 11:10 PM, Tinker  wrote:

Hi!

What's good PPC/MIPS/SPARC networking hardware with open firmware that 
works

well with OpenBSD?

Minimalistic for minimizing attack surface.

(Many ethernet ports would be a bonus. 1U rack mount would be a bonus. 
ECC

would be a bonus.)

Thanks!
Tinker

IKE phase 2 failing, but don't see any obvious problem

[Andrew Lester]

Hi all,

I'm working on bringing up a remote-access L2TP + IPSec VPN on an OpenBSD 5.8
workstation. Note that this system is the client side L2TP LAC, not a
server-side L2TP LNS. Therefore I am using xl2tpd instead of npppd, which will
only handle server-side configurations. My issue actually seems unrelated to
the underlying tunneling protocol. I'm running into an IKE phase 2 failure,
specifically when first moving into quick mode.

My OpenBSD system sends the first quick mode message that contains its
advertised remote and local network information. In this case, it's very
simple as it's simply the traffic between what will become the L2TP endpoints,
so:
proto usb from 1.1.1.1 to 2.2.2.2 port 1701

1.1.1.1 is my local IP and 2.2.2.2 is the remote endpoint. When my system
sends this as the ID information in the quick mode message however, the remote
endpoint responds with: INVALID ID INFORMATION. I've tried a variety of
things, but I can't determine what's wrong here. Phase 1 completes without
issue. Below is the isakmpd.pcap output showing the failure:

08:32:37.154146 1.1.1.1.4500 > 2.2.2.2.4500: [bad udp cksum e7bc! -> 3d4d]
udpencap: isakmp v1.0 exchange QUICK_MODE
cookie: -> msgid: d8e18d0e len: 148
payload: HASH len: 24
payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 40 proposal: 1 proto: IPSEC_ESP spisz: 4
xforms: 1 SPI: 0xdad40d72
payload: TRANSFORM len: 28
transform: 1 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 3600
attribute ENCAPSULATION_MODE = TUNNEL
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
attribute KEY_LENGTH = 128
payload: NONCE len: 20
payload: ID len: 12 proto: 17 port: 0 type: IPV4_ADDR = 1.1.1.1
payload: ID len: 12 proto: 17 port: 1701 type: IPV4_ADDR = 2.2.2.2
[ttl 0] (id 1, len 180)

08:32:37.167755 2.2.2.2.4500 > 1.1.1.1.500: [bad udp cksum a74b! -> a767]
udpencap: isakmp v1.0 exchange INFO
cookie: -> msgid: 16fb376e len: 76
payload: HASH len: 24
payload: NOTIFICATION len: 16
notification: INVALID ID INFORMATION [ttl 0] (id 1, len 108)


Perhaps another set of eyes might catch what I have not. Any input would be
greatly appreciated. :)


Warm regards,
Andrew

Estudia un curso de Postgrado en Chile desde cualquier lugar.

[UOnline - Educaci�n permanente]

Vea esta información en su navegador

Re: What's good safe PPC/MIPS/SPARC networking hardware with open firmware that works well with OpenBSD? Many ethernet plugs and 1U rack mount = bonus.

[Karel Gardas]

Open firmware? What do you mean by that precisely?

Anyway, while asking such question it would also help if you tell
something about intended usage scenario of such box(es). fw?/app
server?/storage?/nas? etc.

On Sat, Feb 27, 2016 at 11:10 PM, Tinker  wrote:
> Hi!
>
> What's good PPC/MIPS/SPARC networking hardware with open firmware that works
> well with OpenBSD?
>
> Minimalistic for minimizing attack surface.
>
> (Many ethernet ports would be a bonus. 1U rack mount would be a bonus. ECC
> would be a bonus.)
>
> Thanks!
> Tinker

Re: Again SNMP: No UCD-SNMP-MIB found

[Stuart Henderson]

On 2016-02-26, Alex Naumov  wrote:
> Hello,
>
> just want to ask why our snmpd(8) doesn't understand MIBs from UCD-SNMP-MIB.
> Is there some workaround?
>
> I need information about CPU and Memory usage...
>
>
> OpenBSD 5.6 GENERIC#274 i386
> net-snmp-5.7.2.1p2

snmpd(8) aka /usr/sbin/snmpd is *not* Net-SNMP. It generally prefers
standard MIBs where possible, the UCD/NetSNMP ones are generally
not used (except that UCD-DISKIO-MIB *is* used, I don't think there
was a good alternative standard MIB for this).

For Memory/CPU use, look in the Host Resources MIB (RFC 2790):
HOST-RESOURCES-MIB::hrStorageTable
HOST-RESOURCES-MIB::hrProcessorTable

Examples:

snmptable -v2c -c public localhost hrStorageTable
snmptable -v2c -c public localhost hrProcessorTable
snmpget -v2c -c public localhost 
hrStorage{Descr,AllocationUnits,Size,Used}.{1,2}
snmpwalk -v2c -c public localhost hrProcessorLoad

LibreNMS, for one, can pick these up directly.

(There is also /usr/local/sbin/snmpd / /etc/rc.d/netsnmpd -
this is still needed in some special situations, but snmpd(8)
is more trustworthy).

What's good safe PPC/MIPS/SPARC networking hardware with open firmware that works well with OpenBSD? Many ethernet plugs and 1U rack mount = bonus.

[Tinker]

Hi!

What's good PPC/MIPS/SPARC networking hardware with open firmware that 
works well with OpenBSD?


Minimalistic for minimizing attack surface.

(Many ethernet ports would be a bonus. 1U rack mount would be a bonus. 
ECC would be a bonus.)


Thanks!
Tinker

Re: sndiod fallback trouble

[Michael Reed]

On 02/27/16 04:15, Alexandre Ratchov wrote:

A nicer approach would be to handle this in sndiod by allowing
sub-devices (aka -s options) to change their device (aka -f
option).  The advantage of doing it in sndiod is that later this
could happen dynamically (ex.  unplug usb cable and programs
migrate to another device).


So, if I had program A connected to snd/0 (backed by rsnd/1), and
rsnd/1 was unplugged during playback, then snd/0's backing device
would be changed to rsnd/0?

I might be misunderstanding you, but that sounds like a really nice
idea ("trunk-like", as Matej said).

OpenSSL/IPsec certificate creation error or error in man pages

[igor.kos]

I have created certificates in accordance to isakmpd man page:

# env CERTIP=10.0.0.1 openssl x509 -req \
 -days 365 -in 10.0.0.1.csr \
 -CA /etc/ssl/ca.crt -CAkey /etc/ssl/private/ca.key \
 -CAcreateserial -extfile /etc/ssl/x509v3.cnf \
 -extensions x509v3_IPAddr -out 10.0.0.1.crt

But in certificate there is no 10.0.0.1 IP addr, instead there is:

openssl x509 -in /etc/isakmpd/certs/10.0.0.1.crt -text

.something.
X509v3 extensions:
X509v3 Subject Alternative Name:
IP Address:0.0.0.0
somethnig else


So, 10.0.0.1 defined as: env CERTIP=10.0.0.1 is not here. That is,
because in /etc/ssl/x509v3.cnf is defined 0.0.0.0:

# default settings
CERTPATHLEN = 1
CERTUSAGE   = digitalSignature,keyCertSign,cRLSign
EXTCERTUSAGE= serverAuth,clientAuth
CERTIP  = 0.0.0.0
CERTFQDN= nohost.nodomain

Value of CERTIP in x509v3 is important. We can change value in
/etc/ssl/x509v3.cnf and put CERTIP = 10.0.0.1 (ie our IP addr)

But then, procedure mentioned in man pages is not correct.

Re: What are the disadvantages of soft updates?

[Lampshade]

Hello
Given that one could change options for filesystem such as sync to async
without remounting using mount -u -o options /what /where
is this possible to disable softdep on the fly (without unmounting)?

Second question:
Does mounting fs with softdep *and* sync options is secure?


For example now I have:
mount | grep usr
/dev/sd1e on /usr type ffs (local, nodev, synchronous, softdep)
and could have this
mount | grep usr
/dev/sd1e on /usr type ffs (local, softdep)

Re: how to send email via Mail

[Craig Skinner]

G'day Eric,

On 2016-02-26 Fri 14:52 PM |, Eric Furman wrote:
> 
> What Nick was trying to say was, "If you do not understand internet
> e-mail from end-to-end please do not run an e-mail server."

Yes.

> There is a lot more to it than just installing some packages.

Yes, he'll need at least:
*) 1 static IP address
*) a hosted registered domain name he can control
*) properly configured reverse DNS from the ISP
*) loads of time to learn

> When you setup a mis-configured e-mail system you don't just
> suffer. Everybody suffers.
> An amateur running an e-mail server is MUCH more likely to become
> a SPAM bot. And, no it is not worth it.
>

Children make a mess when learning to eat.

When learning to ride a bike, people fall off.

Learning to sail often ends in being towed to port.

When I was an apprentice engineer in the navy,
and I made an arse of welding something, my tradesman would say,
"Don't worry: He who's never fucked up, has never made fuck all."

Learning to run a mail server won't be easy, nor quick, nor perfect,
but it could be an adventure, despite the funny fuckups along the way.

Cheers!
-- 
Frodo: Come on, Sam. Remember what Bilbo used to say: "It's a dangerous
business, Frodo, going out your door. You step onto the road, and if you
don't keep your feet, there's no knowing where you might be swept off
to."

Re: Firefox W^X isn't a part of Pwn2Own contest

[Lampshade]

About X.Org isolation I have heard of
Xpra - "screen for X11"
but haven't used this yet.

Re: Remote access VPN on OpenBSD workstation...

[Stuart Henderson]

On 2016-02-27, Andrew Lester  wrote:
> For simplicity sake I'm not yet concerned about getting the IPSec layer
> operational, which seems slightly more straightforward. Is there a way to
> configure npppd as a LAC client or does it only function as an LNS? If the
> latter, is there other software available that can act as a native LAC client
> on OpenBSD? This is in reference to OpenBSD 5.8 stable.

Unfortunately npppd is currently server-only (for all supported protocols).
You might get somewhere with xl2tpd from ports, which uses pppd(8) for the
actual session handling, it's a bit awkward to setup and performance will
not be all that great on OpenBSD but as of 5.8 should pass packets ok.

Re: how to send email via Mail

[Roderick]

On Fri, 26 Feb 2016, Steffen Nurpmeso wrote:


But it's shit [pipes in mail(1)].  You cannot say "rawpipe" etc.
It is not flexible, not configurable, it is dumb and cannot really be
used for anything real,


It is very flexible. The inflated programs with cool features do not
allow you to use the features in another way as the ones expected by
the developer. You can complain that it is not "configuarable" so that
you can use it comfortably, but exactly the flexibility is the advantage.



I disagree, because a mail handling system needs to be able to
handle mail.  I agree with lpr, it is good to have a printer that
understands postscript. [...]


The question is, for what do we need lpr/lpd. I think mainly, for two
things: (1) for handling the line printer daemon protocol, and
(2) for managing the printer queue. If you use the computer alone and
the printer is attached to your computer, you do not need lpr/lpd.
You can just print file.ps with:

"cat file.ps | ps2lj4l > /dev/lpt0"

where ps2lj4l is a filter that transforms the format of file.ps to
the language of the printer, it is the program you put in "if" of
printcap. Ghostscript helps you to make the filter, if you want to
print postscript files.

The filter is not an issue of lpr/lpd, lpr/lpd is abstracted from
the language of the printer and the format of the file. The purpose
of lpr/lpd is to manage effectively the queue under race conditions
in a busy printer. Perhaps one can abstract it more, make a
daemon specialized in managing queues of tasks that may be
anything (printer, fax, mail, etc), but this would not be traditional,
standard unix/bsd. There must be a compromise.

You can say, mail(1), lpr/lpd, ed are obsolte programs of the 70s
and should be deleted from base. It would be a catastrophe for
many people.

The first time I was in front of a vt100 connected to a unix
system (SunOS=BSD), I was helpless and begun using ed. It reminded
me "sos" from Tops 10 that I used before (in teletypes).
After a while I begun using emacs that I use till now for writing
bigger things, but I use mainly vi for configuration files.
For what do we have "ed" in base if we have also "vi" in base?
Can we delete it? Should be it inflated with new features?
No! I use "ed" for example in scripts, and "sed" is not always
an alternative. Can you imagine putting emacs or vi in a script?
There are many uses of these old, meager programs.

Rodrigo.

Re: asking for help compiling dns stats collector (dsc)

[Imre Oolberg]

Hi!

On 2016-02-25 12:52, Oliver Peter wrote:

On Thu, Feb 25, 2016 at 09:42:25AM +0200, Imre Oolberg wrote:

Hi!

On 2016-02-22 20:08, Stuart Henderson wrote:
>On 2016-02-21, Imre Oolberg  wrote:
>>Hi!
>>
>>I am in the middle of implementing 
https://www.dns-oarc.net/tools/dsc/
>>while on OpenBSD is running nameserver process i.e. there needs to 
be

>>also collector part of DSC and I am not succeeding compiling it.
>>Platform is OpenBSD v 5.8 amd64 and source is 
dsc-201502251630.tar.gz.

>>After unpacking i get
>>
>>imre-obsd-58-rec:~/dsc/l/dsc-201502251630/collector# make
>>...
>>cc -g -Wall -DUSE_IPV6=1 -g -O2  -g -Wall -DUSE_IPV6=1 -g -O2
-c

>>base64.c
>>cc -g -Wall -DUSE_IPV6=1 -g -O2  -g -Wall -DUSE_IPV6=1 -g -O2
-c

>>generic_counter.c
>>cc -g -Wall -DUSE_IPV6=1 -g -O2  -g -Wall -DUSE_IPV6=1 -g -O2
-c

>>pcap.c
>>cc -g -Wall -DUSE_IPV6=1 -g -O2  -g -Wall -DUSE_IPV6=1 -g -O2
-c

>>ncap.c
>>cc -g -Wall -DUSE_IPV6=1 -g -O2  -g -Wall -DUSE_IPV6=1 -g -O2
-c

>>dns_protocol.c
>>dns_protocol.c:9:33: error: arpa/nameser_compat.h: No such file or
>>directory
>>*** Error 1 in dsc (:87 'dns_protocol.o')
>>*** Error 1 in /root/dsc/l/dsc-201502251630/collector (Makefile:2
>>'all')
>>
>>So i found that probably i need libbind package and continuing in
>>collector/dsc directory like this
>>
>>imre-obsd-58-rec:~/dsc/l/dsc-201502251630/collector/dsc# 
./configure
>>CFLAGS="-I/usr/local/include/bind" 
LDFLAGS="-L/usr/local/lib/libbind"

>>
>>i get further (it think almost to the end on compilation)
>>
>>imre-obsd-58-rec:~/dsc/l/dsc-201502251630/collector/dsc# make
>>...
>>cc -g -Wall -DUSE_IPV6=1 -I/usr/local/include/bind   -g -Wall
>>-DUSE_IPV6=1 -I/usr/local/include/bind -c config_hooks.c
>>cc -g -Wall -DUSE_IPV6=1 -I/usr/local/include/bind   -g -Wall
>>-DUSE_IPV6=1 -I/usr/local/include/bind -c hashtbl.c
>>cc -g -Wall -DUSE_IPV6=1 -I/usr/local/include/bind   -g -Wall
>>-DUSE_IPV6=1 -I/usr/local/include/bind -c lookup3.c
>>cc -g -Wall -DUSE_IPV6=1 -I/usr/local/include/bind   -g -Wall
>>-DUSE_IPV6=1 -I/usr/local/include/bind -c xmalloc.c
>>cc -g -Wall -DUSE_IPV6=1 -I/usr/local/include/bind   -g -Wall
>>-DUSE_IPV6=1 -I/usr/local/include/bind -c inX_addr.c
>>c++ -o dsc base64.o  generic_counter.o  pcap.o  ncap.o  
dns_protocol.o

>>dns_message.o  ip_message.o  daemon.o  md_array.o  null_index.o
>>qtype_index.o  qclass_index.o  tld_index.o  country_index.o
>>rcode_index.o  qnamelen_index.o  qname_index.o  msglen_index.o
>>client_ipv4_addr_index.o  client_ipv4_net_index.o
>>md_array_xml_printer.o  ip_direction_index.o  ip_proto_index.o
>>ip_version_index.o  certain_qnames_index.o  
query_classification_index.o

>>idn_qname_index.o  edns_version_index.o  edns_bufsiz_index.o
>>do_bit_index.o  rd_bit_index.o  tc_bit_index.o  qr_aa_bits_index.o
>>opcode_index.o  transport_index.o  dns_ip_version_index.o
>>dns_source_port_index.o  ParseConfig.o  config_hooks.o  hashtbl.o
>>lookup3.o  xmalloc.o  inX_addr.o  -L/usr/local/lib/libbind
-lpcap

>> ../TmfBase/Hapy/src/.libs/libHapy.a
>>dns_protocol.o: In function `grok_question':
>>/root/dsc/l/dsc-201502251630/collector/dsc/dns_protocol.c:93: 
warning:

>>warning: strcpy() is almost always misused, please use strlcpy()
>>pcap.o: In function `handle_tcp':
>>/root/dsc/l/dsc-201502251630/collector/dsc/pcap.c:552: warning:
>>warning: sprintf() is often misused, please use snprintf()
>>query_classification_index.o: In function `a_for_a':
>>

>>/root/dsc/l/dsc-201502251630/collector/dsc/query_classification_index.c:71:
>>undefined reference to `__inet_aton'
>>inX_addr.o: In function `inXaddr_ntop':
>>/root/dsc/l/dsc-201502251630/collector/dsc/inX_addr.c:28: 
undefined

>>reference to `__inet_ntop'
>>/root/dsc/l/dsc-201502251630/collector/dsc/inX_addr.c:31: 
undefined

>>reference to `__inet_ntop'
>>inX_addr.o: In function `inXaddr_pton':
>>/root/dsc/l/dsc-201502251630/collector/dsc/inX_addr.c:41: 
undefined

>>reference to `__inet_pton'
>>/root/dsc/l/dsc-201502251630/collector/dsc/inX_addr.c:45: 
undefined

>>reference to `__inet_pton'
>>collect2: ld returned 1 exit status
>>*** Error 1 in /root/dsc/l/dsc-201502251630/collector/dsc 
(Makefile:65

>>'dsc')
>>
>>For example text around query_classification_index.c:71 reads like 
this

>>
>>static int
>>a_for_a(const dns_message * m)
>>{
>> struct in_addr a;
>> if (m->qtype != T_A)
>> return 0;
>> if (inet_aton(m->qname, ))
>> return CLASS_A_FOR_A;
>> return 0;
>>}
>>
>>I would be very thankful if you could point to me how to solve it 
and

>>progress from here to ./dsc binary.
>>
>>
>>Imre
>>
>>PS I searched ports collection for similarities and actually found 
file

>>
>>/usr/ports/pobj/dnstop-20140915/dnstop-20140915/inX_addr.c
>>
>>which is very similar to
>>
>>/root/dsc/l/dsc-201502251630/collector/dsc/inX_addr.c
>>
>>and has some inet_* funtsions in it. dnstop from ports compiles 
and

Supermicro AOC-SG-I2 (two port Intel 82575EB) hwfeatures

[Atanas Vladimirov]

Hi,
I'm running -current on Supermicro X9SCL-F with two on-board Gigabit 
Intel (82579LM and 82574L)

and one PCI-e 4x Supermicro AOC-SG-I2 [0] (two port Intel 82575EB).
The question is why 82575EB doesn't support hwfeatures 
(CSUM_TCPv4,CSUM_UDPv4 and VLAN_HWTAGGING) as 82579LM and 82574L.

Thanks.

[ns]~$ ifconfig em hwfeatures
em0: flags=18843 mtu 1500
hwfeatures=10 hardmtu 9216
lladdr 00:25:90:38:f4:a0
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX 
full-duplex,rxpause,txpause)

status: active
inet XX.87.YY.ZZ netmask 0xffe0 broadcast XX.87.YY.255
em1: 
flags=18b43 
mtu 1500

hwfeatures=10 hardmtu 9216
lladdr 00:25:90:38:f4:a1
priority: 0
media: Ethernet autoselect (1000baseT 
full-duplex,rxpause,txpause)

status: active
em2: 
flags=18b43 
mtu 1500
hwfeatures=36 
hardmtu 9216

lladdr 00:25:90:d2:ab:3f
priority: 0
media: Ethernet autoselect (1000baseT 
full-duplex,master,rxpause,txpause)

status: active
em3: flags=18802 mtu 1500
hwfeatures=36 
hardmtu 9216

lladdr 00:25:90:d2:ab:3e
priority: 0
media: Ethernet autoselect (none)
status: no carrier

[0] http://www.supermicro.com/products/accessories/addon/AOC-SG-I2.cfm


[ns]~$ dmesg
OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8544149504 (8148MB)
avail mem = 8281006080 (7897MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb5a0 (55 entries)
bios0: vendor American Megatrends Inc. version "2.2" date 02/20/2015
bios0: TAROX Parx T100s G4
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SPMI SSDT SSDT DMAR 
EINJ ERST HEST BERT
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4) 
USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7

(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(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) Xeon(R) CPU E31225 @ 3.10GHz, 3100.50 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,

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

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

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

SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,
NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, 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 5 (P0P1)
acpiprt2 at acpi0: bus 3 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus 4 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus 1 (PEG0)
acpiprt11 at acpi0: bus 2 

Re: sndiod fallback trouble

[Matej Nanut]

On 27 February 2016 at 10:15, Alexandre Ratchov  wrote:
> One option would to patch libsndio to try more devices (how many?).

I've also noticed this issue and have hacked libsndio to try snd/0 and
snd/1 first, which is basically the same as your suggestion.

> A nicer approach would be to handle this in sndiod [...]

That would be fantastic, but seems like quite a lot of work. I don't
know enough about the audio stack to really comment, but can't there
be problems with a device changing for the program mid stream? Or
would you add a special "trunk-like" pseudo device?

What do you think of adding a separator to AUDIODEVICE, to be able to
list more than one device (like : or ;)? Then libsndio just tries them
one after another, and you don't have to guess how many. It's a simple
backwards-compatible fix, but it doesn't address device migration.

I guess fixing it in sndiod is the right way, though.

Re: sndiod fallback trouble

[Alexandre Ratchov]

On Fri, Feb 26, 2016 at 07:18:06PM -0500, Michael Reed wrote:
> Hello,
> 
> I use OpenBSD on my laptop to listen to music, using an external DAC
> (USB) at home and built-in audio elsewhere.
> 
> In rc.conf.local I have
> 
>   # see http://thread.gmane.org/gmane.os.openbsd.misc/213373/focus=213377
>   sndiod_flags=-m play -f rsnd/1 -f rsnd/0
> 
> with the intention of using rsnd/1 (USB DAC) when it's available, and rsnd/0
> (built-in audio) when it's not.  However, this is what actually seems to
> happen when the USB DAC isn't plugged in (see DEFAULTS section in sndio(7)):
> 
>   - audio program tries to connect to snd/0, which fails because it doesn't
> exist (snd/0 is a sub-device of rsnd/1 (USB DAC), which isn't plugged in)
> 
>   - audio program then tries rsnd/0 (/dev/audio0), which works
> 
> The trouble is that, as shown by the second bullet, sndiod(8) is being
> completely bypassed if the USB DAC isn't plugged in:
> 
>   # fuser -u /dev/audio[0-2]# sndiod_flags=-m play -f rsnd/1 -f rsnd/0
>   /dev/audio2:
>   /dev/audio1:
>   /dev/audio0: 18636(_mpd)
> 
> If I set sndiod_flags to empty, then sndiod is no longer bypassed
> 
>   $ fuser -u /dev/audio[0-2] # sndiod_flags=
>   /dev/audio2:
>   /dev/audio1: 3291(_sndio)
>   /dev/audio0:
> 
> but, of course, the USB DAC won't be used at all.
>
> With that said, I'm wondering if it's even possible to set up sndiod so that
> (1) my USB audio device is always used when available and (2) sndiod isn't 
> bypassed
> if the DAC isn't available.
> 
> After reading various sndio/audio manual pages I'm still somewhat
> confused, so any help would be much appreciated.

Your understanding is right; this is a sndiod limitation.  We don't
have the code yet to do what you want.

One option would to patch libsndio to try more devices (how many?).

A nicer approach would be to handle this in sndiod by allowing
sub-devices (aka -s options) to change their device (aka -f
option).  The advantage of doing it in sndiod is that later this
could happen dynamically (ex.  unplug usb cable and programs
migrate to another device).