Support for ath10k QCA988x devices
Hello, I am curious if there is any info on support for the wireless chipset Qualcomm Atheros QCA988x in the ath10k drivers. These devices are sold by PCEngines. Prior discussions I found on this list: On 2014-04-17 Thom Lauret wrote > 802.11n is not yet supported in OpenBSD. On 2015-09-23 Stuart Henderson wrote > > http://www.pcengines.ch/wle600vx.htm > > This is a QCA9882 from the 802.11ac range, on Linux this uses the > Ath10k driver. Not yet supported on OpenBSD. On 2017-04-12 Stefan Sperling wrote > ath10k devices are not supported. They need a new driver because Atheros > has changed the driver<->hardware interface with this generation of devices. Is there any update? A brief look in the source code and manual did not show anything. What effort is required to implement a new driver, as Stefan mentions? Port something from another BSD? From Linux? Start from scratch? My motivation is to build a wireless router supporting 802.11ac (with OpenBSD if possible). Compex WLE600VX and WLE900VX support 867Mbps and 1300Mbps, respectively, according to their data sheets. I am not bound to this chipset, if there are alternatives which do work. -Alex
texlive_texmf-full package broken on cdn.openbsd.org
Hello Misc, Just to confirm that the package textlive_texmf-full is broken on cdn.openbsd and cloudfare.cdn.openbsd Error: doas pkg_add textlive_texmf-full quirks-3.182 signed on 2020-01-25T17:59Z https://cloudfare.cdn.openbsd.org/pub/OpenBSD/6.6/packages/amd64/textlive_texmf-full-2018.tgz: ftp: SSL write error: handshake failed: unexpected EOF signify: gzheader truncated Couldn't install texlive_texmf-full-2018 Using release 6.6 with all the patches thanks to syspatch. I actually could install it using https://mirror.esc7.net/pub/OpenBSD so maybe they are just broken there. I hope this information helps. Thank you. Manuel
Re: FreeBSD daemon(8)-like command for OpenBSD
But another use for daemon(8) is for its ability to detach the child process from the controlling terminal If it is about a rc.d script, you can add rc_bg=YES to it.
Re: experience with supermicro based Network Devices for 1Gb/s Ipsec throughput
On 01/10/2019 21:17, Lyndon Nerenberg wrote:
>> SYS-5018A-FTN4
>
> If you have any of these, replace them. They have known buggy CPUs
> and will randomly fail without warning. We replaced about a dozen
> of them after >50% failed within the first year of installation.
I have several of these boards that need RMA'ing. Fingers are crossed,
and holding thumbs, that this gets a positive result.
> Note this isn't an OpenBSD problem -- the 5018As are just bad hardware.
> (They also have APIC interrupt issues, most likely due to a buggy ACPI
> implementation.)
I know a lot about the above bricking issue ("Erratum AVR.54") but I
never heard anything about an ACPI problem. Do you have a link to
further information please?
I also have several servers that were produced *after* the SoC was fixed
(C0 stepping instead of B0). I don't know if any ACPI fixes were
implemented though. It would be good to get some kind of understanding
on this.
> We replaced all our SYS-5018A-FTN4s with SYS-5018D-FN8Ts.
Did the slightly more powerful cores (and potential for much more RAM,
plus other various improvements) in the replacement server compensate
sufficiently for the number of cores being halved?
Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: FreeBSD daemon(8)-like command for OpenBSD
hello, > PID=`pgrep gloob` > if [ -z "$PID" ] > then > /usr/local/bin/gloob -f poor_security_a_bad_idea_to_run.conf > fi is there a reason to not use the pgrep status ? pgrep -q gloob || /usr/local/bin/gloob regards, marc
Re: FreeBSD daemon(8)-like command for OpenBSD
You asked about the base image, so maybe there is some reason you can't use it, but Supervisor is in ports/packages. Allan Patrick Kristiansen writes: > Hi everyone, > > Is there something like the FreeBSD daemon(8) command for OpenBSD, which > can run a process in the background and restart it if it crashes? That > is, is there a command that comes with OpenBSD's base image with these > capabilities? Surprisingly, Google hasn't revealed anything useful to > me. > > Thanks, > Patrick Kristiansen >
Re: match two conditions in relayd(8)
On Mon, Jan 27, 2020 at 09:22:40PM +0100, Sebastian Benoit wrote:
> Joel Carnat(j...@carnat.net) on 2020.01.27 18:21:43 +0100:
> > Hi,
> >
> > I'm setting up an HTTP(S) Reverse Proxy with relayd(8).
> >
> > I have one listener with multiple FQDN allowed.
> > But I also have a common path that must be treated separately.
> >
> > As for now, I have:
> > http protocol "https" {
> > match request header "Host" value "one.domain.local" forward to
> > match request header "Host" value "two.domain.local" forward to
> > match request path "/common/*" forward to
> > }
> > relay "domain.local" {
> > listen on egress port 443 tls
> > protocol "https"
> > forward toport 80 check tcp
> > forward toport 80 check tcp
> > forward to port 80 check tcp
> > }
> >
> > With this configuration, both "/common/" are rendered by .
> > But I want
> > "one.domain.local/*" to be rendered by
> > "one.domain.local/common/" to be rendered by
> > "two.domain.local/*" to be rendered by
> > "two.domain.local/common/" to be rendered by
> >
> > Is there some way to achieve this?
>
> Try using "quick" or possibly "tag" and "tagged".
>
> /Benno
>
tag/tagged seem to do the trick.
Thanks a lot!
Re: FreeBSD daemon(8)-like command for OpenBSD
On 1/28/20 9:29 AM, Patrick Kristiansen wrote: > Hi Ingo > > Thank you for your reply. > > I can't say I disagree with your and the OpenBSD team's attitude about > bug-free daemons. But I am just a lowly application programmer, and > sometimes I introduce horrible bugs that make our systems crash. In many > cases it will be preferable to just start the process again (and, of > course, fix the bug) for the purposes of keeping our business running. Everyone has a testing environment, not everyone has a production environment... > > But another use for daemon(8) is for its ability to detach the child > process from the controlling terminal and furthermore redirect its > stdout/stderr to syslog. Is there some mechanism to do that from the > shell? Perhaps a combination of nohup and starting a background job? I once had to write a support script in shell that needed to run as daemon, basically some action needed to be taken if something was found in a log-file. To do this I did exactly what you said: nohup 2>&1 | logger & and put this inside an rc.d file or equivalent format of your OS of choice. now I'm not promoting this kind of hackery, but this worked for me quite reliably at the time. martijn@ > > Best regards, > Patrick > >> Hi Patrick, >> >> Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100: >> >>> Is there something like the FreeBSD daemon(8) command for OpenBSD, >>> which can run a process in the background and restart it if it >>> crashes? >> >> Absolutely not, we are strongly convinced this is an utterly stupid >> idea and a serious security risk. >> >> If a daemon crashes, it has a bug. Many bugs that cause crashes >> are also exploitable. So if a daemon crashes, you first have to >> understand why it crashed, fix or at least mitigate the bug, and >> can only restart it afterwards. >> >> Restarting it automatically is an irresponsible thing to do. >> >> If a daemon keeps crashing so frequently that you can only run it >> in production with automatic restarts, then running it at all is >> irresponsible in the first place. >> >> Yours, >> Ingo >
Re: FreeBSD daemon(8)-like command for OpenBSD
Hi Patrick,
On Tue, Jan 28, 2020 at 09:29:20AM +0100, Patrick Kristiansen wrote:
| Hi Ingo
|
| Thank you for your reply.
|
| I can't say I disagree with your and the OpenBSD team's attitude about
| bug-free daemons. But I am just a lowly application programmer, and
| sometimes I introduce horrible bugs that make our systems crash. In many
| cases it will be preferable to just start the process again (and, of
| course, fix the bug) for the purposes of keeping our business running.
|
| But another use for daemon(8) is for its ability to detach the child
| process from the controlling terminal and furthermore redirect its
| stdout/stderr to syslog. Is there some mechanism to do that from the
| shell? Perhaps a combination of nohup and starting a background job?
What I do to run a "normal" (non-daemon) program like a daemon, is to
start it in tmux. To have this start during system startup, I have an
@reboot cronjob:
--
[weerd@cube] $ cat ~/bin/conlog
#!/bin/sh
# conlog: start a tmux session with cu logging to a file
##
# Can be used with the following @reboot cron line to start at boot:
#
# @reboot /home/weerd/bin/conlog
PATH=/bin:/usr/bin
LOG="/home/weerd/data/conlog/log.`date +%s`"
mkdir -p `dirname ${LOG}`
tmux new -d "script -c 'cu -l cuaU0 -s 115200' ${LOG}"
--
At reboot, this will start a new (detached) tmux session that launches
cu (under script) to log the serial console output from another
OpenBSD machine. I can attach the tmux session and interact with the
console of that machine if necessary.
For the purpose of restarting crashing programs, you could do
something similar: run your program in a tmux session (convenient to
attach to when you want to look at its stdout/stderr output) and
script something to restart when it errors out. You could then also
send yourself e-mail to alert you to the restart.
Cheers,
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: FreeBSD daemon(8)-like command for OpenBSD
Hi Ingo Thank you for your reply. I can't say I disagree with your and the OpenBSD team's attitude about bug-free daemons. But I am just a lowly application programmer, and sometimes I introduce horrible bugs that make our systems crash. In many cases it will be preferable to just start the process again (and, of course, fix the bug) for the purposes of keeping our business running. But another use for daemon(8) is for its ability to detach the child process from the controlling terminal and furthermore redirect its stdout/stderr to syslog. Is there some mechanism to do that from the shell? Perhaps a combination of nohup and starting a background job? Best regards, Patrick > Hi Patrick, > > Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100: > >> Is there something like the FreeBSD daemon(8) command for OpenBSD, >> which can run a process in the background and restart it if it >> crashes? > > Absolutely not, we are strongly convinced this is an utterly stupid > idea and a serious security risk. > > If a daemon crashes, it has a bug. Many bugs that cause crashes > are also exploitable. So if a daemon crashes, you first have to > understand why it crashed, fix or at least mitigate the bug, and > can only restart it afterwards. > > Restarting it automatically is an irresponsible thing to do. > > If a daemon keeps crashing so frequently that you can only run it > in production with automatic restarts, then running it at all is > irresponsible in the first place. > > Yours, > Ingo
Re: interface modifiers :network and :0 picking different subnets for IPv6
Hi Richard,
On Tue, Jan 28, 2020 at 04:42:02PM +1300, richard.n.proc...@gmail.com wrote:
| Does the patch below help?
It does! Great, thank you!
(tested on my test vm as that has a source tree checked out)
[weerd@test1] $ echo 'block in on vio0 proto { tcp, udp } from vio0:network to
! vio0:0 port domain' | pfctl -nvf -
block drop in on vio0 inet proto tcp from 192.168.34.0/24 to ! 192.168.34.157
port = 53
block drop in on vio0 inet proto udp from 192.168.34.0/24 to ! 192.168.34.157
port = 53
block drop in on vio0 inet6 proto tcp from 2a02:898:28:200::/64 to !
fe80::fce1:bbff:fed1:c6d9 port = 53
block drop in on vio0 inet6 proto udp from 2a02:898:28:200::/64 to !
fe80::fce1:bbff:fed1:c6d9 port = 53
[weerd@test1] $ echo 'block in on vio0 proto { tcp, udp } from vio0:network to
! vio0:0 port domain' | obj/pfctl -nvf -
block drop in on vio0 inet proto tcp from 192.168.34.0/24 to ! 192.168.34.157
port = 53
block drop in on vio0 inet proto udp from 192.168.34.0/24 to ! 192.168.34.157
port = 53
block drop in on vio0 inet6 proto tcp from 2a02:898:28:200::/64 to !
2a02:898:28:200:4706:3e7a:afb9:5137 port = 53
block drop in on vio0 inet6 proto udp from 2a02:898:28:200::/64 to !
2a02:898:28:200:4706:3e7a:afb9:5137 port = 53
Looks great and would be perfect to have in I think. One rule to
concisely describe the behaviour I want :)
Thanks again!
Paul
| I think you have found an oversight in the original implementation of
| ':0', which defines a non-alias as the first defined address (of the given
| address family) [0]. The patch makes ':0' skip link-local addresses,
| matching the behaviour of ':network'.
|
| best,
| Richard.
|
| [0] sbin/pfctl/pfctl_parser.c 1.186 ifa_lookup()
|
| Index: sbin/pfctl/pfctl_parser.c
| ===
| RCS file: /cvs/src/sbin/pfctl/pfctl_parser.c,v
| retrieving revision 1.342
| diff -u -p -u -p -r1.342 pfctl_parser.c
| --- sbin/pfctl/pfctl_parser.c 17 Oct 2019 21:54:28 - 1.342
| +++ sbin/pfctl/pfctl_parser.c 28 Jan 2020 03:11:27 -
| @@ -1546,6 +1546,8 @@ ifa_lookup(const char *ifa_name, int fla
| continue;
| if ((flags & PFI_AFLAG_NETWORK) && p->ifindex > 0)
| continue;
| + if ((flags & PFI_AFLAG_NOALIAS) && p->ifindex > 0)
| + continue;
| if (last_if == NULL || strcmp(last_if, p->ifname))
| got4 = got6 = 0;
| last_if = p->ifname;
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
