Re: opensmtpd / ldap unreliable

[justina colmena]

On Tue, 22 May 2018 18:13:23 -0700
"Paul B. Henson"  wrote:

> If the ldap server isn't available when opensmtpd is started, it says
> it started:
> 
> # /etc/rc.d/smtpd start

Then apparently you should have done

# /etc/rc.d/ldapd start

or preferably

# rcctl start ldapd

first.

Are you enabling them both at boot time?

# rcctl enable ldapd
# rcctl enable smtpd

Are they being started in the wrong order at boot time?

Otherwise, there may well be arguably a certain reliability or error
reporting issue in the code for it, but there is a certain bottom line
here in that if you configure ASDF to _require_ JKL for authentication,
then you really do need to have JKL "available" if you expect ASDF to
work the way you configured it.

What you ask is a very general question: If A depends on B, and B is
missing, how do expect A to behave?

Anyways, smtpd is a daemon. It was forked off, and it was still running
when it was checked immediately after you issued the command
"/etc/rc.d/smtpd start". Its parent process had no doubt already
terminated and control had reverted to the shell before the fatal error
occurred. You would have to issue the command

# rcctl check smtpd

to check that smtpd is still running at some later time.

opensmtpd / ldap unreliable

[Paul B. Henson]

So I recently converted my opensmtpd server to use ldap as the backend
for user authentication. It seems it's a bit untolerant to ldap issues?

If the ldap server isn't available when opensmtpd is started, it says it
started:

# /etc/rc.d/smtpd start
smtpd(ok)

But it isn't there:

# ps -aux | grep smtpd
root 89090  0.0  0.0   304  1208 p6  S+p5:52PM0:00.00 grep smtpd

And it's not really obvious why:

May 22 17:52:51 bart smtpd[46044]: info: OpenSMTPD 6.0.4 starting
May 22 17:52:51 bart smtpd[23325]: warn: table-proc: pipe closed
May 22 17:52:51 bart smtpd[23325]: lookup: table-proc: exiting
May 22 17:52:51 bart smtpd[73239]: smtpd: process lka socket closed

Starting in debug mode:

# smtpd -d
info: OpenSMTPD 6.0.4 starting
users[43283]: debug: reading key "url" -> "ldap://localhost:3389;
users[43283]: debug: reading key "basedn" ->
users[43283]: debug: reading key "username" ->
users[43283]: debug: reading key "password" ->
users[43283]: debug: reading key "credentials_filter" -> 
"(&(objectClass=uidObject)(uid=%s))"
users[43283]: debug: parsing attribute "credentials_attributes" (2) -> 
"uid,description"
users[43283]: debug: done reading config
users[43283]: warn: aldap_parse
users[43283]: fatal: failed to connect
warn: table-proc: pipe closed
lookup: table-proc: exiting
smtpd: process lka socket closed

You can see it looks like it fails to connect to the ldap server at
startup and just dies.

Further, if the ldap server is up at startup, but ever restarts or has
the connection broken, authentication just fails:

May 21 13:22:10 bart smtpd[42132]: warn: user credentials lookup fail for 
users:henson

The opensmtpd process needs to be restarted before authentication works
again.

In debug mode, it shows:

users[7295]: debug: table_ldap: ldap_query:
filter=(&(objectClass=uidObject)(uid=henson)), ret=0
5e46e2fabbf8d72e smtp event=authentication user=henson
address=134.71.249.41 host=134.71.249.41 result=permfail

Is it expected that the ldap support is currently not production ready?
I see in a presentation from back in 2013 that ldap was classified
experimental at the time, but it's not clear if that's still the case.

I see in the repo at

https://github.com/OpenSMTPD/OpenSMTPD-extras/blob/master/extras/tables/table-ldap/table_ldap.c

there's a change to add ldap reconnection support:

https://github.com/OpenSMTPD/OpenSMTPD-extras/commit/04e4c521b34d1987af915ff97dcb0d87daf122b0#diff-369c0fcbfbc85bf2cdad7dba1131b872

but it's dated 7/27/2017, and the last github release seems to be
201601072302 (although the openbsd port appears to be 201703132115, I
guess it's not downloading it from github?).

It looks like the code in head still fails to start if the ldap server
isn't available when opensmtpd is started though.

Is anybody using opensmtpd with ldap in production? If so, how are you
working around this issue?

Thanks...

Re: Intranet routing with dynamic IPs

[giant]

Regardless of which routing protocol I use, I run into the same problem. 
I can't find a way to configure this on OpenBSD. Is this such an exotic 
set-up?


On 2018-05-21 22:23, Raul Miller wrote:

I would try OpenOSPFD for this situation, instead of OpenBGPD.

vlan without IP address not working (parent not in promisc mode)

[Sigi Rudzio]

Hi misc@,

I'm trying to bridge a VLAN between two routers with a vxlan(4) interface.

Setup:
router 1 (6.3):
physical interface (em) - vlan (with IP address) - bridge - vxlan

The two routers are connected directly, the traffic is encrypted with IPSec
and encapsulated in etherip(4), routed traffic is working perfectly.

router 2 (6.3-current):
vxlan - bridge - vlan (no IP address) - parent interface (sk0) -
switch - devices

With this configuration, the parent interface on router 2 (sk0) isn't in
promiscous mode and no traffic can pass into the vlan interface on router 2
(the devices attached to the switch receive echo requests and answer, but the
answer is not received on the vlan interface, only on the parent interface (sk0)
in encapsulated form).
Outgoing traffic can be seen on the vlan interface.

If I assign an IP address to the vlan device on router 2, the parent
interface (sk0)
flags change from:
sk0: flags=8843 mtu 1500
to:
sk0: flags=8b43
mtu 1500

and traffic can flow over the vlan interface, it keeps working even
after deleting the
IP address (sk0 stays in promisc. mode).
Even when I delete the vlan interface after deleting the IP address
and add the vlan
interface again it keeps working until I reboot.

running tcpdump on sk0 or adding it to a bridge with no other members also makes
traffic flow and puts sk0 in promisc mode, but exiting
tcpdump/destroying the bridge
removes the PROMISC flag again.

Easiest way to reproduce this is creating a vlan interface on top of a
ethernet interface
with and without an IP address for the vlan interface. (also tried it
with an rl interface,
got the same behaviour).

disabling pf doesn't change anything.

Am I doing something wrong/is this behaviour intended or indeed a bug?

If you need any more information/want me to reproduce this with a simpler setup,
I'll be happy to help.

dmesg of router 2 is attached.

Thanks for any help!

Regards,

Sigi Rudzio

dmesg router 2:
OpenBSD 6.3-current (GENERIC) #41: Sat May 19 22:35:35 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 989462528 (943MB)
avail mem = 951570432 (907MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (51 entries)
bios0: vendor American Megatrends Inc. version "080014" date 09/12/2008
bios0: ECS GeForce7050M-M
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET NVHD SSDT
acpi0: wakeup devices NSMB(S4) USB0(S4) USB2(S3) US15(S4) US12(S3)
NMAC(S5) P0P1(S4) HDAC(S4) BR10(S4) BR11(S4) BR12(S4) BR13(S4)
BR14(S4) BR15(S4) BR16(S4) PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Sempron(tm) Processor LE-1150, 1995.48 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,EAPICSP,AMCR8,3DNOWP
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 256KB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2500 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus 2 (BR10)
acpiprt3 at acpi0: bus 3 (BR11)
acpiprt4 at acpi0: bus 4 (BR12)
acpiprt5 at acpi0: bus 5 (BR13)
acpiprt6 at acpi0: bus 6 (BR14)
acpiprt7 at acpi0: bus 7 (BR15)
acpiprt8 at acpi0: bus 8 (BR16)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 110 degC
acpicmos0 at acpi0
"*pnp0c14" at acpi0 not configured
acpibtn0 at acpi0: PWRB
cpu0: PowerNow! K8 1995 MHz: speeds: 2000 1800 1000 MHz
pci0 at mainbus0 bus 0
"NVIDIA MCP67 Memory" rev 0xa2 at pci0 dev 0 function 0 not configured
pcib0 at pci0 dev 1 function 0 "NVIDIA MCP67 ISA" rev 0xa2
nviic0 at pci0 dev 1 function 1 "NVIDIA MCP67 SMBus" rev 0xa2
iic0 at nviic0
spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-6400CL6
iic1 at nviic0
ohci0 at pci0 dev 2 function 0 "NVIDIA MCP67 USB" rev 0xa2: apic 1 int
10, version 1.0, legacy support
ehci0 at pci0 dev 2 function 1 "NVIDIA MCP67 USB" rev 0xa2: apic 1 int 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "NVIDIA EHCI root hub" rev
2.00/1.00 addr 1
ohci1 at pci0 dev 4 function 0 "NVIDIA MCP67 USB" rev 0xa2: apic 1 int
10, version 1.0, legacy support
ehci1 at pci0 dev 4 function 1 "NVIDIA MCP67 USB" rev 0xa2: apic 1 int 10
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "NVIDIA EHCI root hub" rev
2.00/1.00 addr 1

Re: socket permissions inside /var/www chroot

[justina colmena]

On Tue, 22 May 2018 06:04:57 +0300
IL Ka  wrote:
> I am definitely not an expert in this field, but here are some
> thoughts:
Exactly. There is always more than one way to skin a cat. I'm not
looking for a perfectly spelled out "solution" I must follow to the
letter.

> So, you can create "_fastcgi" group, add www to this group, and
> configure php-fpm
> to create socket with this group (it must be main group of user used
> by php-fpm).
I was thinking more the other way around: creating a "_fastcgi"
*user* and inviting that user into the "www" group. 

> See listen.group and listen.mode options.
These are a little odd because OpenBSD's httpd apparently refuses to
connect to the php fastcgi socket unless these are both set to "www"
in /etc/php-fpm.conf

> In PHP world maybe, but for Python/Django Postgres is default
> database.
Sure. There are plenty of good reasons to consider languages other than
PHP for the web.

> Again, you can add _postgres to some group, and give it permissions to
> create socket in this folder.
Very good observation.

> > although the chrooted user must specify the username together with a
> > dummy password (which is not used) to connect to the socket inside
> > the chroot, apparently because there is no access to /etc/passwd
> > or /etc/group inside the chroot.
> >  
> /etc/passwd must be accessed by postgres (which is not chrooted,
> right?) but not by client.
> Client (php) just opens socket file, and postgres uses openbsd API to
> get its user id.

The client (inside the chroot) has its numeric userid, but cannot
even look up its own username (in /etc/passwd) from inside the chroot to
supply to PostgreSQL for the connection. That's why it must be specified
manually from within the chroot.

Re: N7260 wifi card bug (hardware or driver?)

[Daniel Camoles]

Well, this problem just magically went away, and all I did was complain 
about it here and run syspatch and fw_update regularly. Are there 
any chances that someone fixed it? Or should I attribute this problem
and its solution to something else other than OpenBSD? I looked at
the changelog from 6.3 to -current but didn't see anything that could
justify this.

bit shifter, is it also fixed on your machine?


On Tue, May 01, 2018 at 01:45:53PM -0600, bit shifter wrote:
> On Tue, May 1, 2018 at 6:16 AM, Daniel Camol??s  wrote:
> > Does anyone in here happens to be running openbsd 6.3 in some machine
> > which has a N7260 wifi card? I have problems with mine (thinkpad
> > x240), and since it only happens on openbsd as far as I can tell, I
> > was wondering if it is some kind of driver problem. I tested ubuntu
> > 16.04, which uses version 17 of the intel firmware, and the problem
> > doesn't happen. Openbsd is using version 16 of intel firmware.
> >
> > The problem is that whenever I am downloading or uploading any file
> > bigger than a couple of megabytes, performance will degrade during the
> > transmission and speed will drop to a halt, often timing out. Doing
> > some research on the web, I was able to find users of other OS'es
> > complaining about a similar problem with N7260, but the reports I
> > found were a couple of years old, which made me think that it was
> > possibly a bug in the intel firmware which they probably fixed since
> > then.
> >
> > It does not seem to be related to my wifi router nor service provider,
> > since the same happens with another router and provider. It also
> > happens not only in http transfers, but also in ssh.
> >
> > I didn't try to run -current because I didn't saw any change in iwm.
> >
> > Thanks in advance for any help. Below is my dmesg output:
> 
> 
> I have the same machine, same wifi card, and definitely similar
> issues.  I'm kind of relieved to know I'm not the only one.  I've
> tried multiple access points, forced 11g mode, 5GHz band, but the
> issue persists.  I get poor speeds and stalls -- some web pages never
> finish loading.  I've also tested with iperf on my LAN and have poor
> results there as well.  In a live Antergos Linux environment, I
> achieve the full potential speed.
> 
> This issue has been ongoing for me since I installed OpenBSD 6.1 on
> this machine, and I'm now running a snapshot from April 22.  Until
> pretty recently, I've only used this machine casually, so aside from a
> little frustration, it hasn't affected me much.  I would love to be
> able to get this resolved though.
> 
> My dmesg is below.  Please let me know what other information I can
> provide or troubleshooting steps I can take.
> 
> 
> dmesg:
> 
> OpenBSD 6.3-current (GENERIC.MP) #10: Sun Apr 22 10:09:36 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8447578112 (8056MB)
> avail mem = 8184410112 (7805MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (60 entries)
> bios0: vendor LENOVO version "GIET88WW (2.38 )" date 02/09/2017
> bios0: LENOVO 20AMS0HH00
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT
> SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI POAT ASF! BATB FPDT UEFI DMAR
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 1796.09 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,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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 99MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 1795.85 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,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application 

Re: ikev2 All incoming/outgoing traffic over IPsec?

[Johan Hattne]

Not sure I quite understand this setup.  Why redirect over port 9222 on the 
client—can’t you just do “pass in … rdr-to 192.168.6.1 port ssh” on the server? 
 That said, I do believe you’ll need NAT on the server, because it’s now 
masquerading its own 192.168.5.0/24 network as well as the 192.168.6.0/24 
network of the client.

// Johan

> On May 21, 2018, at 05:11, Denis  wrote:
> 
> I can successful ping both sides of IPsec tunnel:
> 
> server$ ping -I 192.168.5.1 192.168.6.1
> 64 bytes from 192.168.6.1 icpm_seq...
> 
> client$ ping -I 192.158.6.1 192.168.5.1
> 64 bytes from 192.168.6.1 icpm_seq...\
> 
> tcpdump -en -i pflog0
> shows nothing about blocked traffic while connecting by "external machine"
> 
> I tried to do external connection to server's public IP (a.b.c.d) and
> redirect this connection by PF trough IPsec tunnel to client's IPsec IP:
> 192.168.6.1. Then client's PF rules redirect connection from server's
> IPsec IP: 192.168.5.1 to a client's 127.0.0.1 and must reply to external
> machine from a.b.c.d
> 
> My test conditions:
> 
>   external machine
>   #ssh -p 9922 to a.b.c.d
>   |
>   |
>   server's public IP is a.b.c.d
>   PF rule:
> pass in quick on a.b.c.d inet proto tcp from any to (a.b.c.d) \
> port 9922 rdr-to 192.168.6.1 queue (ssh_bulk, ssh_login)
>   ||
>   ||
>   IPsec tunnel (working):
>   srv IP: 192.168.5.1
>   clnt IP: 192.168.6.1
>   ||
>   ||
>   client's PF rule:
> pass in quick on enc0 inet proto tcp from any to any port 9922 rdr-to
> lo0 port 22 modulate state
> 
> Incoming packets from "external machine" with SSH client seems to be
> redirected to client's 127.0.0.1 port 22, but client not replied to a
> "externa machine".
> 
> It seems I have to implement NAT rule for IPsec or what?
> 
> Please advise.
> 
> Denis
> 
> 
> On 5/15/2018 5:12 AM, Johan Hattne wrote:
>> I don’t know that outgoing traffic from lo is expected to go through the 
>> tunnel.  If you’re doing these tests with ping, does e.g.
>> 
>>  server$ ping -I 192.168.6.1 192.168.5.1
>> 
>> yield the expected results?  I’d expect ping responses, and tcpdump on the 
>> enc interfaces on both sides to show both the request and the response.
>> 
>> // Johan 
>> 
>>> On May 14, 2018, at 07:34, Denis  wrote:
>>> 
>>> I have added to /etc/pf.conf:
>>> 
>>> $ipsec_if = "axen0"
>>> $ipsec_remote_lan = "192.168.5.0/24"
>>> 
>>> pass out quick on $ipsec_if proto tcp from lo0 to $ipsec_remote_lan
>>> 
>>> but outgoing traffic from client's lo0 is blocked anyway:
>>> 
>>> rule 14/(match) block out on axen0: 127.0.0.1:port > 192.168.5.1:port: S
 776927979:776927979(0) ack 896868769 win 16384 >> 
>>> Denis
>>> 
>>> On 5/14/2018 2:17 PM, Denis wrote:
 Incoming connections to client's IP (192.168.6.1) is established and
 seems redirected to lo0:port, but outgoing connection from client's lo0
 to a server's IP (192.168.5.1) is blocked according to
 
 # tcpdump -en -i pflog0 output:
 
 ...
 rule 14/(match) block out on axen0: 127.0.0.1:port > 192.168.5.1:port: S
 776927979:776927979(0) ack 896868769 win 16384 >>> ...
 
 Do I need to add a NAT rule to have reply passed to server's source IP
 (192.168.5.1) or what?
 
 Thanks.
 
 Denis
 
 
 On 5/13/2018 7:12 PM, Johan Hattne wrote:
> Nah, sorry, I misread your rules—on second look, I don’t see what’s gone 
> wrong.  What about logging blocked packets
> 
> block log (all, to pflog0)
> 
> in pf.conf and dumping it
> 
> # tcpdump -en -i pflog0
> 
> while doing what you expect should work?
> 
> // Johan
> 
>> On May 13, 2018, at 02:15, Denis  wrote:
>> 
>> Johan,
>> 
>> Do I have to remove these two rules or modify them by removing ipencap?
>> 
>> pass in quick on $ipsec_enc_if proto ipencap from any to ($ipsec_if) \
>> keep state (if-bound)
>> pass out quick on $ipsec_enc_if proto ipencap from ($ipsec_if) to any \
>> keep state (if-bound)
>> 
>> On 5/12/2018 10:11 AM, Johan Hattne wrote:
>>> 
 On May 11, 2018, at 06:21, Denis  wrote:
 
 Hello,
 
 I have working ikev2 tunnel between two virtual aliased subnets. But no
 traffic over IPsec tunnel from $ext_if on server machine to $ext_if on
 client machine and vice-versa. Both machines are using in production 
 and
 firewalled by PF.
 
 
 # cat /etc/hostname.em1
 ### server $ext_if
 dhcp
 alias 192.168.5.1
 255.255.255.0
 
  |
  | IPsec
 

Re: sndio multiple interfaces

[Ken M]

On Tue, May 22, 2018 at 07:56:31AM +0200, Alexandre Ratchov wrote:
> On Sun, May 20, 2018 at 06:49:25PM -0400, Ken M wrote:
> > Been looking around and can't find the answer to this question. If I missed 
> > it
> > in some obvious place please excuse me.
> > 
> > Anyway I am curious if sndio can support multiple simultaneous cards, either
> > identical or different, particularly multiple standards compliant USB audio
> > interfaces. Basically I am asking if it supports similar features to what 
> > one
> > might use zita with jack on a linux system.
> 
> This doesn't work with sndio. It's difficult to make work because each
> audio interface would use its own clock source, and clocks would drift
> sooner or later. Drift may be corrected, but this would cost
> additional latency, complexity and (probably) quality problems.
> 
> That's why certain devices have a "word clock", to allow audio devices
> to by synchronized; OpenBSD doesn't support any of them, but
> supporting them looks much easier than combining multiple devices.
> 
> Nowadays many-channel devices are common, so supporting multiple cards
> as one isn't that important, is it?

OK, noted. The question was about a feature parity against a library in linux.
Zita is a tool to help overcome the clock drift. Truth is in practice it is less
than reliable so a single interface is better in practice. 

Thank you.
Ken

Re: ping blocked for 12 minutes

[Stuart Henderson]

On 2018-05-20, Patrick Dohman  wrote:
> It appears there is an errata effecting Avoton and Rangeley products.
>
> AVR54:
>
> “System May Experience Inability to Boot or May Cease Operation Problem: 
> The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Low Pin Count bus clock 
> outputs) may stop functioning.
> Implication: If the LPC clock(s) stop functioning the system will no longer 
> be able to boot.
> Workaround: A platform level change has been identified and may be 
> implemented as a workaround for this erratum."

That's unrelated to this issue - the hardware fault on c2xxx atom
you're describing here results in the system not booting, not some
very odd blocking of ping for 12 minutes overnight.

Re: Building OpenBSD and ports VS installing from packages

[Stuart Henderson]

On 2018-05-21, Peter Hessler  wrote:
> i386 and amd64 are different platforms, so of course you get different 
> packages.
>
> Within the same platform, all binaries that are built should run on all
> possible members of that platform.
>
> So, code will be compiled WITHOUT AVX support, unless it can be detected
> at runtime (e.g. mplayer/ffmpeg).  I believe that firefox does not to
> runtime detection, so firefox should not directly call AVX.

Firefox isn't a great example, the rust code targets p4 with sse2.

> On 2018 May 21 (Mon) at 18:37:43 -0300 (-0300), Elias M. Mariani wrote:
>:Hi,
>:I understand that about the builds and packages.
>:I will re write my question in another form:
>:If I build, say, firefox on a i386 machine I get a package, and
>:another if I build firefox on amd64, they differ.
>:If I build firefox on an amd64 machine WITHOUT AVX support I get a
>:package, if now I build firefox in an amd64 machine WITH AVX support,
>:do I still get the same package ?
>:(firefox is a random pick)

You may be able to build some things with different compiler flags
to use different cpu-specific instructions (-march, -mtune). If you
have some very specific computation-heavy software that needs to be
high performance then *maybe* it's worth looking into this. But in the
general case you're going to waste far more time than you save just in
compiling, let alone if you have to spend any extra time debugging.

Re: 6.3 just died (not for the first time)

[Harald Dunkel]

Hi Peter,

please check the threads on the b...@openbsd.org mailing list. The patch
posted by Martin Pieuchot seemst to help. Its running on my hosts for
5 days without any hiccup.


Hope this helps
Harri

Re: HPPA 720/60 and PS/2 Keyboard

[Markus Hennecke]

On Mon, 21 May 2018, Otto Moerbeek wrote:

> On Mon, May 21, 2018 at 12:29:13PM +0200, Markus Hennecke wrote:
> 
> > I tried updating my HPPA box from 6.2 to 6.3, but when booting the release 
> > or -current bsd.rd kernel the keyboard repeats the last key pressed. The 
> > 6.2 release did not show this behaviour. Is there anyone out there running 
> > 6.3 or -current on hppa?
> > 
> > Markus
> 
> There was a diff from miod floating around to fix this:
> 
> https://marc.info/?l=openbsd-tech=152536826316030=2

Thanks a lot.
After installing via serial console and building a kernel over night I can 
confirm the patch fixed the problem.

Markus

Re: Viewport for man.openbsd.org -- readability on phones

[Marc Espie]

On Tue, May 22, 2018 at 06:35:17AM +0300, li...@wrant.com wrote:
> For younger UNIX users, the real reason is technical limits of hardware then.
> 
> https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_format_and_character_codes
> https://en.wikipedia.org/wiki/Characters_per_line#History
> 
> People tend to forget quickly historic evolution is the only reason there is.

The actual "readability limit" is around 60 signs for variable-width
fonts, that's what you use in typography, conventionally, to decide whether
you want two columns text or one column.

Longer than that, it becomes for your eyes to reset to the correct start
of line.

I suspect that somewhat larger text on screen with fixed width fonts has
a somewhat bigger threshold, nobody knows exactly which, the cursor 
probably helps a bit.   80 looks like a good compromise.