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.
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
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.
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.
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
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.
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
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
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?
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
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
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...
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
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)
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, &a)) >> 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 >>runs fine. So i t
Re: sndiod fallback trouble
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.
Supermicro AOC-SG-I2 (two port Intel 82575EB) hwfeatures
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 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(350@104 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(350@104 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(350@104 mwait.1@0x20), C1(1000@1 mwait.1
Re: sndiod fallback trouble
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).