On Sat, Oct 08, 2022 at 11:14:34AM +, Mikolaj Kucharski wrote:
> On Sat, Oct 08, 2022 at 09:57:54AM +, Klemens Nanni wrote:
> > On Sat, Oct 08, 2022 at 07:33:38AM +0200, Florian Obser wrote:
> > > Being up2date doesn't feel like an error to me, what am I missing?
> >
> > I concur.
> >
>
For ease of running sysupgrade from within a script.
diff --git a/usr.sbin/sysupgrade/sysupgrade.sh
b/usr.sbin/sysupgrade/sysupgrade.sh
index d80ff127ffa..ce5800093c9 100644
--- a/usr.sbin/sysupgrade/sysupgrade.sh
+++ b/usr.sbin/sysupgrade/sysupgrade.sh
@@ -153,7 +153,7 @@ rm SHA256.sig
if
On Thu, Nov 11, 2021 at 02:42:39PM +0100, Stefan Sperling wrote:
> Testing on 4965 by jsg@ revealed an unrelated issue on those devices.
> A fix for this problem has just been committed.
> This new version of the 40MHz patch applies on top of that fix.
Working fine on my "Intel Centrino
On Mon, Nov 01, 2021 at 01:05:22PM +0100, Stefan Sperling wrote:
> On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> > To check whether your access point uses a 40MHz channel, run this command
> > while associated to the access point:
> > tcpdump -n -i iwm0 -v -y
On Tue, Apr 27, 2021 at 01:11:03PM +0200, Stefan Sperling wrote:
> Christian Ehrhardt reported an issue where changes in the ERP protection
> settings in beacons caused noticeable packet loss on iwm(4).
>
> I've found that there are a few parameters in beacons which can change at
> run-time but
On Tue, Apr 27, 2021 at 03:46:56PM +0200, Stefan Sperling wrote:
> Refactor softraid crypto code to allow use of a discipline-specific data
> structure for RAID1C volumes, as requested by jsing@ during review of my
> initial RAID1C patch.
>
> This patch should effectively be a cosmetic change.
>
On Tue, Apr 27, 2021 at 03:03:10PM +0200, Stefan Sperling wrote:
> This patch tweaks the heuristic RA is using to decide whether enough
> statistics have been gathered for a candidate Tx rate. The goal is to
> avoid Tx rate choices that might turn out to be too optimistic.
>
> In my testing RA
On Thu, Nov 22, 2018 at 06:33:57PM +0100, Reyk Floeter wrote:
> On Thu, Nov 22, 2018 at 11:50:52AM -0500, Josh Grosse wrote:
> > The page refers to vmx0 rather than vxlan0 in its pf.conf
> > guidance.
> >
>
> ... I committed a change to use em0 instead of vmx0.
>
&
The page refers to vmx0 rather than vxlan0 in its pf.conf
guidance.
Index: vxlan.4
===
RCS file: /systems/cvs/src/share/man/man4/vxlan.4,v
retrieving revision 1.7
diff -u -p -r1.7 vxlan.4
--- vxlan.4 22 Feb 2018 01:35:04 -
On Wed, Apr 12, 2017 at 01:44:48PM +0200, Reyk Floeter wrote:
> Hi,
>
> we want to make it easier to run NAT'ed and auto-configured VMs that
> don't need switches, L2, manual scripts, or any additional servers on
> the host. I wrote a new mode that just needs vmd, pf, and forwarding.
Tested on
On Fri, Apr 14, 2017 at 12:29:53PM -0400, Josh Grosse wrote:
> Tested on an amd64 host...
Following up on my own post to state this was tested both
with "local" in vm.conf as well as with vmctl -L.
alled may not refer
back to faq4.html when they later run into partition size issues after
following the untar guidance in faq15.
A link to #AddThoughts in this section of faq15.html might be appropriate.
> 2016-07-19 3:29 GMT+02:00 Josh Grosse <j...@jggimi.homeip.net>:
> > I had a
I had a conversation with a new OpenBSD user who thought that he
may have either misunderstood or been misled by the guidance to unpack
the ports tree tarball in /usr. He quickly discovered his 2G /usr
default allocation was too small when he began to build ports.
FAQ 15 doesn't warn users who
On Fri, Apr 01, 2016 at 04:19:46PM -0600, Todd C. Miller wrote:
> The problem is that fopen(tty, "w") uses O_CREAT. If we use open
> + fdopen we can avoid that.
>
> Can you try this diff?
Works well. Thank you!
When biff(1) is set to y, comsat opens the tty for write.
if ((tp = fopen(tty, "w")) == NULL) {
dsyslog(LOG_ERR, "%s: %s", tty, strerror(errno));
_exit(1);
}
This aborts:
(gdb) bt
#0 0x0890a441 in open () at :2
#1 0x0897e308 in *_libc_fopen
The following patch permits kern_xxx.c to build with SYSCALL_DEBUG.
Index: kern_xxx.c
===
RCS file: /systems/cvs/src/sys/kern/kern_xxx.c,v
retrieving revision 1.29
diff -u -p -u -r1.29 kern_xxx.c
--- kern_xxx.c 5 Dec 2015 10:11:53
The root cause for a recent problem reported on misc@ [0] was
determined to be setting kern.securelevel=2 in sysctl.conf. [1]
To perhaps prevent the provisioning error from happening to others,
I propose the following clarification to securelevel(7). I percieve the
setting as little more than
On Sat, Jan 10, 2015 at 06:09:21PM +, Stuart Henderson wrote:
On 2015/01/10 14:54, Florian Obser wrote:
I don't think this is entirely correct. eui64 enables IPv6 on an interface
by setting a link local address. For lo0 it also sets ::1.
I'm unsure what eui64 was supposed to do
when
Joel Sing joel at sing.id.au writes:
The following diff provides a softraid CONCAT discipline, which serially
concatenates data over the given chunks. This relies on the previous
metadata initialisation cleanup diff that I just sent out.
All testing appreciated.
This seems to work just
19 matches
Mail list logo
