On Mon, Apr 30, 2018 at 01:35:59PM +0100, Stuart Henderson wrote:
> On 2018/04/30 10:55, Stefan Sperling wrote:
> > The AP sends 5GHz beacons with a ridicously low RSSI while no client
> > is connected, and OpenBSD prefers the 2GHz band...
>
> Surely it has to be the receiver that is adding the RS
On Mon, Apr 30, 2018 at 08:57:23AM +0200, Peter Hessler wrote:
> On 2018 Apr 29 (Sun) at 11:51:26 +0200 (+0200), Stefan Sperling wrote:
> :This diff tries to avoid situations where background scans play
> :ping-pong between different APs with nearly equal RSSI, as
> :observed by phessler.
> :
> :No
On 2018/05/01 10:48, Stefan Sperling wrote:
> > On 2018/04/30 11:08, Stefan Sperling wrote:
> > > Derp. A dBm value of -10 would of course be better than -60.
> > >
> > > Whatever the numbers shown by tcpdump really mean, the probe response's
> > > one is better!!!
> >
> > Better as in "more accu
On Tue, May 01, 2018 at 10:22:22AM +0100, Stuart Henderson wrote:
> On 2018/05/01 10:48, Stefan Sperling wrote:
> > > On 2018/04/30 11:08, Stefan Sperling wrote:
> > > > Derp. A dBm value of -10 would of course be better than -60.
> > > >
> > > > Whatever the numbers shown by tcpdump really mean,
Florian Obser(flor...@openbsd.org) on 2018.04.30 18:27:52 +0200:
> The -d flag should be a no-op in monitor mode since it does not modify
> the routing table.
>
> However, if -d is provided route monitor lists all interfaces and
> their associated addresses and exits. This is confusing, unexpected
ok
Florian Obser(flor...@openbsd.org) on 2018.04.30 18:26:46 +0200:
> Sync p_rttables() to netstat(1) version. Pointed out by claudio and
> mpi.
>
> Remaining differences are pledge and priority handling which only
> route(8) has.
>
> While here switch flushroutes to get_sysctl() function.
>
>
So after adding a quick hack to mitigate Spectre variant 2 to ARM
Trusted Firmware (ATF), ARM actually designed a proper solution that
minimizes the performance loss and makes the presence of the
workaround detectable. This is all documented in an update of the SMC
Calling Convention (SMCCC) stand
Nick Owens(misch...@offblast.org) on 2018.04.30 18:40:34 -0700:
> hi tech@,
>
> i've written a program in go which gathers information from pf for
> exporting to prometheus. my go program invokes several ioctls on /dev/pf to
> do this. however, i recently looked at pledge'ing my program, but i've
On Tue, May 01, 2018 at 11:53:16AM +0200, Sebastian Benoit wrote:
> Florian Obser(flor...@openbsd.org) on 2018.04.30 18:27:52 +0200:
> > The -d flag should be a no-op in monitor mode since it does not modify
> > the routing table.
> >
> > However, if -d is provided route monitor lists all interfac
Hi,
A user has reported an issue with not having a proper promiscuous mode
on reddit a while back but as of now didn't manage to test the diff.
If somebody is running OpenBSD on Hyper-V, please test the diff below
and see if there are any regressions (like increased CPU load) without
running tcpd
On Sat, Apr 28, 2018 at 07:24:28PM +0200, Matthieu Herrb wrote:
> Hi,
>
> libXfontcache and libXxf86misc are implementing the client part of X
> extensions that have been disabled/removed for a while in the X
> server. So builing them or linking to them is useless.
>
> The patch below stops build
On Mon, Apr 30, 2018 at 07:49:20PM -0300, Gleydson Soares wrote:
> hi,
>
> following diff defines nitems locally and stop
> including
Has this been done elsewhere in the tree? Is this the new paradigm
we will be adopting? I don't have a strong opinion one way or the
other, just want to be consi
Mike Larkin wrote:
> On Mon, Apr 30, 2018 at 07:49:20PM -0300, Gleydson Soares wrote:
> > hi,
> >
> > following diff defines nitems locally and stop
> > including
>
> Has this been done elsewhere in the tree? Is this the new paradigm
> we will be adopting? I don't have a strong opinion one wa
On 2018 May 01 (Tue) at 11:20:54 +0200 (+0200), Stefan Sperling wrote:
:On Mon, Apr 30, 2018 at 08:57:23AM +0200, Peter Hessler wrote:
:> On 2018 Apr 29 (Sun) at 11:51:26 +0200 (+0200), Stefan Sperling wrote:
:> :This diff tries to avoid situations where background scans play
:> :ping-pong between
Here's a few X509_* functions with added const. This was part of a bulk
by sthen with no fallout. One minor difference: the diff I sent to
Stuart contained a mistake in X509_signature_print().
Most of these are straightforward. X509_ALGOR_get0() required a bit of
churn in *{pub,priv}_decode* func
> scrollback isn't part of wsdisplay_emulops but rather wsdisplay_accessops.
> It isn't clear how to properly get an attr in wsscrollback()
> GETCHAR/getchar is part of wsmoused and sc->sc_accessops->getchar
> may be NULL.
Ok, ignore that. There is a simpler solution.
Index: rasops.c
On Mon, Apr 30, 2018 at 02:55:21PM +0200, Martin Pieuchot wrote:
> On 30/04/18(Mon) 12:00, Theo Buehler wrote:
> > With mpi's encouragement and guidance, here's a diff that reduces the
> > scope of the NET_LOCK() a bit.
> >
> > in_control() is the only caller of mrt_ioctl() and the latter is a
> >
On Mon, Apr 30, 2018 at 09:39:18PM +0200, Theo Buehler wrote:
> Here is a straightforward diff that converts BIO_new(), BIO_set() and the
> BIO_{f,s}_*() functions to match OpenSSL wrt const. This was part of a
> larger diff that was run through a bulk by sthen and produced no fallout.
>
There we
Hi all.
So I finally got bored of ps not displaying command args when "-e" is
present. Yes, ps(1) is broken: compare end of lines in output of "ps
-ww" and "ps -eww". And IIRC it behaves this way long enough, but I
always thought that it's me not missing something in ps(1) manual. Bad
zhuk@.
This
Hi all.
The "p = realloc(p, size)" idiom is obviously wrong. Since both
places to be fixed were similar, I went further and unified the code
as well.
Note that "argv" is later initialized from kd->argv, so there is
no problem in reusing it here.
The amd64 is happy. Okay?
--
WBR,
Vadim Zhukov
ktrace makes the problem more clear:
25908 ps CALL
sysctl(1.55.75675.1,0xed0cc78,0x7f7cd3d8,0,0)
25908 ps RET sysctl -1 errno 14 Bad address
The various Rockchip SoCs seem to favour 150 for the serial
console speed. And since for some of those we still have to rely on
closed source firmware components, I think I'll have to bite the
bullit and properly support this. Here is a first diff that adds an
appropriate entry to gettytab(5)
2018-05-01 21:53 GMT+03:00 Theo de Raadt :
> ktrace makes the problem more clear:
>
> 25908 ps CALL
> sysctl(1.55.75675.1,0xed0cc78,0x7f7cd3d8,0,0)
> 25908 ps RET sysctl -1 errno 14 Bad address
And that's it, thanks!
Now little ps(1) is happy. But now there's a question
looks reasonable to me.
OK
On Tue, May 01, 2018 at 07:08:59PM +0200, Theo Buehler wrote:
> On Mon, Apr 30, 2018 at 02:55:21PM +0200, Martin Pieuchot wrote:
> > On 30/04/18(Mon) 12:00, Theo Buehler wrote:
> > > With mpi's encouragement and guidance, here's a diff that reduces the
> > > scope of the
Vadim Zhukov wrote:
> 2018-05-01 21:53 GMT+03:00 Theo de Raadt :
> > ktrace makes the problem more clear:
> >
> > 25908 ps CALL
> > sysctl(1.55.75675.1,0xed0cc78,0x7f7cd3d8,0,0)
> > 25908 ps RET sysctl -1 errno 14 Bad address
>
> And that's it, thanks!
>
> Now little
On 01/05/18(Tue) 19:08, Theo Buehler wrote:
> On Mon, Apr 30, 2018 at 02:55:21PM +0200, Martin Pieuchot wrote:
> > On 30/04/18(Mon) 12:00, Theo Buehler wrote:
> > > With mpi's encouragement and guidance, here's a diff that reduces the
> > > scope of the NET_LOCK() a bit.
> > >
> > > in_control() i
On Tue, May 01, 2018 at 07:08:59PM +0200, Theo Buehler wrote:
> I tested this as well as I could, but I don't usually use IPv6, so I
> dabbled a bit with it on my home network and I tried to use the netinet6
> regress tests, only with moderate success.
>
> A test from people who actually use IPv6
[this is long, and hppa-specific, feel free to ignore if you don't care
about OpenBSD/hppa. Noone does anyway nowadays]
At the beginning of the hppa port, no interrupts were shared - the
processor allows for 32 interrupt sources and the existing designs made
sure to allocate distinct interrupts t
Similarly to what we did for ifioctl() a few months back, we can factor
out the handling of reading ioctls into a new function, in_ioctl_get().
Treat these cases before grabbing the NET_LOCK() in in_ioctl().
I only moved and copied a few pieces of code around and did not try to
make any simplifica
On Wed, May 02, 2018 at 01:58:06AM +0200, Theo Buehler wrote:
> Similarly to what we did for ifioctl() a few months back, we can factor
> out the handling of reading ioctls into a new function, in_ioctl_get().
> Treat these cases before grabbing the NET_LOCK() in in_ioctl().
>
> I only moved and c
On Tue, May 01, 2018 at 05:03:26PM +, Miod Vallat wrote:
> > scrollback isn't part of wsdisplay_emulops but rather wsdisplay_accessops.
> > It isn't clear how to properly get an attr in wsscrollback()
> > GETCHAR/getchar is part of wsmoused and sc->sc_accessops->getchar
> > may be NULL.
>
> Ok
I believe you are correct to correlate RSSI & probe response.
My understanding is that 802.11 beacon is a management frame to synchronize
networks.
Essentially the beacon interval determines the multiple for the DTIM & may
include additional capability frames.
The beacon blinks at a configurable
> Thanks, looks good/ok. Shouldn't the eraserows call in
> rasops_doswitch() also use scr->rs_defattr for the attr argument?
Yes, indeed. Good catch!
33 matches
Mail list logo
