On Sun 03/10/2021 22:49, Stefan Sperling wrote:
> While working on 40MHz support for iwm(4) I noticed that throughput
> dropped from 200 Mbit/s to about 2 Mbit/s whenever the laptop roamed
> between APs. Sometimes traffic even stalled completely.
> The patch below fixes this problem for me.
$
On Tue 25/05/2021 15:48, Stefan Sperling wrote:
> This patch allows iwm(4) to use new firmware images which are part
> of the iwm-20210512 firmware package, available via fw_update (you
> need to run fw_update *before* booting with this patch).
>
> The new firmware images were published right
On Mon 27/01/2020 20:01, Björn Ketelaars wrote:
> cheloha@ recently replaced custom TAILQ concatenation loops in pool(9)
> with TAILQ_CONCAT(3) [0]. I was curious as how often these custom
> concatenations loops are used and grepped src. I found a couple of them.
> One being in
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git sbin/pfctl/parse.y sbin/pfctl/parse.y
index d524f9e92bc..67de79215e4 100644
--- sbin/pfctl/parse.y
+++ sbin/pfctl/parse.y
@@ -5637,16 +5637,11 @@ mv_rules(struct pf_ruleset *src, struct pf_ruleset *dst)
{
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git usr.sbin/snmpd/control.c usr.sbin/snmpd/control.c
index 54b58bbb7b6..dda18c1bad5 100644
--- usr.sbin/snmpd/control.c
+++ usr.sbin/snmpd/control.c
@@ -487,10 +487,7 @@ control_dispatch_agentx(int fd, short event,
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git usr.sbin/bgpd/config.c usr.sbin/bgpd/config.c
index cb43afb81fe..fc81a3efd3b 100644
--- usr.sbin/bgpd/config.c
+++ usr.sbin/bgpd/config.c
@@ -195,7 +195,6 @@ void
merge_config(struct bgpd_config *xconf, struct
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git usr.sbin/ldapd/search.c usr.sbin/ldapd/search.c
index 3033823eb18..887af5fb6a1 100644
--- usr.sbin/ldapd/search.c
+++ usr.sbin/ldapd/search.c
@@ -764,11 +764,8 @@ search_planner(struct namespace *ns, struct
Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).
Comments/OK?
diff --git sbin/unwind/frontend.c sbin/unwind/frontend.c
index b64036c4332..d2b69084db7 100644
--- sbin/unwind/frontend.c
+++ sbin/unwind/frontend.c
@@ -1011,10 +1011,7 @@ merge_tas(struct trust_anchor_head *newh, struct
cheloha@ recently replaced custom TAILQ concatenation loops in pool(9)
with TAILQ_CONCAT(3) [0]. I was curious as how often these custom
concatenations loops are used and grepped src. I found a couple of them.
One being in sys/ufs/ffs/ffs_softdep.c, and the others in userland.
I build a kernel
On Fri 29/11/2019 21:35, Otto Moerbeek wrote:
> On Fri, Nov 29, 2019 at 10:27:57AM +0100, Florian Obser wrote:
>
> > On Fri, Nov 29, 2019 at 07:28:20AM +0100, Otto Moerbeek wrote:
> > > On Fri, Nov 29, 2019 at 07:02:27AM +0100, Björn Ketelaars wrote:
> > > >
On Thu 28/11/2019 16:16, Otto Moerbeek wrote:
> On Thu, Nov 28, 2019 at 03:26:34PM +0100, Otto Moerbeek wrote:
>
> > Hi,
> >
> > In many offices, split horizon DNS is used. This means that if you are
> > in the office you are supposed to use a specific resolver that will
> > hand out different
On Mon 09/09/2019 16:37, Stefan Sperling wrote:
> On Mon, Sep 09, 2019 at 03:10:04PM +0200, Stefan Sperling wrote:
> > The wifi stack currently calls if_input once per packet instead of once
> > per interrupt. To make the wifi layer play nicely with the network stack
> > we can split
On Thu 06/06/2019 00:37, Christian Weisgerber wrote:
> Christian Weisgerber:
>
> > > To reproduce:
> > >
> > > mkdir -p /tmp/test /tmp/plop
> > > openrsync -rx /tmp/test/ /tmp/plop/
> > >
> > > Result:
> > >
> > > openrsync(3470) in free(): bogus pointer (double free?) 0x7f7dcdc8
> >
On Mon 01/04/2019 21:36, Björn Ketelaars wrote:
> Add --one-file-system, which prevents openrsync to cross filesystem
> boundaries. Option and behaviour is the same as GPL rsync.
Thanks for all the feedback!
New diff:
- Without the long option;
- Appropriate changes to usage and rsync.1;
Add --one-file-system, which prevents openrsync to cross filesystem
boundaries. Option and behaviour is the same as GPL rsync.
OK?
diff --git usr.bin/rsync/extern.h usr.bin/rsync/extern.h
index 12aceae566c..602cd24cede 100644
--- usr.bin/rsync/extern.h
+++ usr.bin/rsync/extern.h
@@ -117,6
Assuming that the other patches have been applied this patch enables
slaacctl(8) to print the set, advertised MTU.
diff --git usr.sbin/slaacctl/slaacctl.c usr.sbin/slaacctl/slaacctl.c
index 5b2a22f12e6..97b460aee08 100644
--- usr.sbin/slaacctl/slaacctl.c
+++ usr.sbin/slaacctl/slaacctl.c
@@
Diff below makes an advertised MTU available from slaacd(8) to
slaacctl(8).
diff --git sbin/slaacd/engine.c sbin/slaacd/engine.c
index 762fb3af7a3..88e8b6531aa 100644
--- sbin/slaacd/engine.c
+++ sbin/slaacd/engine.c
@@ -887,6 +887,7 @@ send_interface_info(struct slaacd_iface *iface, pid_t pid)
Assuming that the pledge bits are in, the diff below enables setting of
MTU on the interface by slaacd.
If a MTU is advertised it is checked that it is at least 1280 bytes. If
not MTU is set to 1280. If no MTU is advertised nothing is done.
diff --git sbin/slaacd/engine.c sbin/slaacd/engine.c
I recently sent a diff for enabling slaacctl(8) to show the advertised
MTU [0]. florian@ commented that it is confusing that slaacctl is
showing a different MTU than ifconfig, and noted that setting MTU is
"perfectly simple to do it in slaacd".
This is the first in a series of 4 patches, which
On Mon 23/07/2018 17:38, Florian Obser wrote:
> On Sun, Jul 22, 2018 at 10:32:31AM +0200, Björn Ketelaars wrote:
> > On Sun 22/07/2018 07:27, Björn Ketelaars wrote:
> > > Now that rad(8) is able to advertise a MTU I think it would be nice to
> > > have slaacctl
On Sun 22/07/2018 07:27, Björn Ketelaars wrote:
> Now that rad(8) is able to advertise a MTU I think it would be nice to
> have slaacctl(8) show this advertisement. The patch below touches both
> sbin/slaacd and usr.sbin/slaacctl. The addition to sbin/slaacd/engine.c
> makes sure
Now that rad(8) is able to advertise a MTU I think it would be nice to
have slaacctl(8) show this advertisement. The patch below touches both
sbin/slaacd and usr.sbin/slaacctl. The addition to sbin/slaacd/engine.c
makes sure that MTU RA messages are parsed, and that the result is made
available.
On Fri 20/07/2018 07:57, Florian Obser wrote:
> On Thu, Jul 19, 2018 at 09:47:06PM +0200, Björn Ketelaars wrote:
> > On Wed 18/07/2018 08:54, Florian Obser wrote:
> > > During g2k18 I commited rad(8).
> > >
> > > The latest amd64 and i386 snapshots should c
On Wed 18/07/2018 08:54, Florian Obser wrote:
> During g2k18 I commited rad(8).
>
> The latest amd64 and i386 snapshots should contain it with enough
> features to replace rtadvd(8). If you are using rtadvd(8) I'd
> appreciate if you could switch to rad(8) and report back if any
> features are
I received a Vodafone k3772 USB modem, which is not supported out of the
box in current. dmesg:
umass0 at uhub3 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 6
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets,
On Sun 20/08/2017 14:20, Björn Ketelaars wrote:
> I just upgraded my machine to a newer snapshot. Unfortunately the kernel
> relinking bit failed. Root cause is that strip has been replaced by ctfstrip,
> which is part of the comp set, which I have not installed.
>
> The exact same
then was that strip was thrown in base [0].
Does it make sense to move ctfstrip and ctfconv to base?
[0]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/sets/lists/base/mi?rev=1.847=text/x-cvsweb-markup
--
Björn Ketelaars
GPG key: 0x4F0E5F21
diff --git distrib/sets/lists/base/mi distrib/sets/lists
On Mon 26/06/2017 14:35, Theo de Raadt wrote:
> There is a diff in snapshots which does kernel relinking during
> install or upgrade.
>
> Really amazing...
Works as advertised, assuming that compXX is installed. The relinking bit uses
strip, which is part of the compiler collection.
Does it
for the noise...
For future references: is it possible to see if a kernel from snapshots contains
'non committed' code?
--
Björn Ketelaars
GPG key: 0x4F0E5F21
://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/hfsc.c.diff?r1=1.20r2=1.21f=h
--
Björn Ketelaars
GPG key: 0x4F0E5F21
specification for
dangerous files.
Included a small diff file.
--
Björn Ketelaars
GPG key: 0x4F0E5F21
Index: mtree/special
===
RCS file: /cvs/src/etc/mtree/special,v
retrieving revision 1.99
diff -u -p -r1.99 special
--- mtree/special
On 03/12/2013, Ian McWilliam wrote:
On 3/12/2013 7:12 PM, Björn Ketelaars wrote:
/etc/nsd.conf has been moved to /var/nsd/etc/nsd.conf. /etc/changelist has
been
changed accordingly, /etc/mtree/special has not. NSD's configuration file
resides in a root:_nsd owned directory with permission
On Thu, Apr 5, 2012 at 6:51 AM, Otto Moerbeek o...@drijf.net wrote:
That sounds like timing bases attacks to guess a username still will work.
-Otto
First thing I thought when reading your reply: absolute nonsense. With
that mindset I really wanted to disprove your suggestion. For this
2012/4/3 Theo de Raadt dera...@cvs.openbsd.org:
Hmm, I'd like to see that refactored somehow.
Also, '-' should not be legal at the start of a login name. There
are things that care. I think at the end it is OK, though.
Crazy eh. Isn't there something else in libc that checks this?
New
Why doesn't login_yubikey just use getpwnam() to check if the
user exists like the other login_* mechs?
Why make it simple if there are exciting pattern matching options like
regexp or multiple if-statements ;-)
Index: login_yubikey.c
2012/4/4 Todd C. Miller todd.mil...@courtesan.com:
Why do we care if the user exists? Ideally, you want the code to
behave more or less the same whether the user is real or not.
Otherwise, a remote attacker can guess valid usernames by timing a
login attempt.
For safety's sake, it makes
2012/4/1 Theo de Raadt dera...@cvs.openbsd.org:
You should really re-do that so that the login name cannot start or
end with a '.'
Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving
login_yubikey does not accept user names with a dot (e.g. user.name).
If one is offered login fails. As other authentication types (e.g.
login_passwd) do accept the use of a dot, it seems that this is a
'feature' related to login_yubikey.
A small patch:
ok?
Index: login_yubikey.c
2012/3/27 Gonzalo L. R. gonz...@x61.com.ar:
you need to send the patch inline only ports@ allow attach.
My mistake...again. This time inline:
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.399
diff -u -r1.399 rc
2012/3/14 Jakob Schlyter ja...@kirei.se (mailto:ja...@kirei.se):
Could you provide an update complete tarfil for review by other developers?
I think we should start considering importing this.
Latest iteration:
http://gateway.hydroxide.nl/OpenBSD/unbound-wip.9.tar.gz
Current status includes
The latest iteration includes:
- Removal of ldns-includes, -library and -manpages;
- Static link of ldns;
- No shared libraries.
There was a nasty config-error in Makefile.bsd-wrapper which has been fixed in:
http://gateway.hydroxide.nl/OpenBSD/unbound-wip.8.tar.gz
This iteration also
- Could you try to link ldns static and not install neither the ldns
library, include files nor the man-pages?
The latest iteration includes:
- Removal of ldns-includes, -library and -manpages;
- Static link of ldns;
- No shared libraries.
Tarball:
Latest iteration of trying to get unbound to fit in OpenBSD base can be
found here:
http://gateway.hydroxide.nl/OpenBSD/unbound-wip.5.tar.gz
Quite a few things have changed:
- better integration of ldns in unbound by writing a better
Makefile.bsd-wrapper (thanks to Ralf -at- ackstorm -dot- de);
I agree, however I cannot help with these arches as I do not have
access to them. Anyone does?
I tested another arch, alpha with -current from 2012-02-12. A couple
of build scripts needed executable bits to build successfully, like
install-sh and libtool (hppa had the same issue, of course,
2012/2/13 Stuart Henderson s...@spacehopper.org:
...
After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit
to
large to send to this list. if anyone feels like looking at the workbdo
not
hesitate to mail me.
Please do. It would be nice to put them on a public server.
WIP
On Tue, Feb 14, 2012 at 9:17 PM, roberth rob...@openbsd.pap.st wrote:
On Mon, 13 Feb 2012 22:35:15 +0100
Bjvrn Ketelaars bjorn.ketela...@hydroxide.nl wrote:
How and when do we automatically generate unbound-control keys? if
so, where should that be done?
Simply don't bother?
rndc keys
2.) Testing (read: does it compile and work) on AMD64.
amd64 is easy, better questions are things like does it build/work on vax
(gcc2, no shared libs), does it work on unusual arch like hppa, etc.
I agree, however I cannot help with these arches as I do not have
access to them. Anyone does?
Hello,
After some recent discussions [1, 2] on the topic of unbound in base, and
(more important) really liking the idea of an alternative for BIND in base, I
made a start with fitting the different pieces of the puzzle. What is
finished:
1.) Integration of ldns 1.6.12 and unbound 1.4.15 and
48 matches
Mail list logo
