On Fri, Apr 30, 2021 at 12:03:00PM +0100, Raf Czlonka wrote:
> Hi Mark,
>
> You and me both ;^)
>
> Until recently, I thought that getopt(1) was POSIX, whereas it is
> in fact getopts(1), and it is not a shell built-in there, but a
> utility[0].
Nope, it is a shell built-in... the "wording" of
> Date: Fri, 30 Apr 2021 14:18:46 +0200
> From: Stefan Sperling
[ Dropping Florian from the CC ]
> On Fri, Apr 30, 2021 at 12:36:57PM +0200, Mark Kettenis wrote:
> > Since booting into a kernel with this diff, I've started seeing the
> > following messages on my OpenBSD AP that uses athn(4):
>
On Fri, Apr 30, 2021 at 02:31:22PM +0200, Mark Kettenis wrote:
> media autoselect mediaopt hostap
> nwid openbsd chan 60 wpakey password
> inet 192.168.32.1
>
> and this is what ifconfig athn0 shows:
>
> athn0: flags=8843 mtu 1500
> lladdr 6c:71:d9:33:44:55
> index 3 priority 4
On Fri, Apr 30, 2021 at 12:14:26PM BST, Marc Espie wrote:
> On Fri, Apr 30, 2021 at 12:03:00PM +0100, Raf Czlonka wrote:
> > Hi Mark,
> >
> > You and me both ;^)
> >
> > Until recently, I thought that getopt(1) was POSIX, whereas it is
> > in fact getopts(1), and it is not a shell built-in
On Fri, Apr 30, 2021 at 12:36:57PM +0200, Mark Kettenis wrote:
> Since booting into a kernel with this diff, I've started seeing the
> following messages on my OpenBSD AP that uses athn(4):
>
> Apr 30 02:13:54 smetana /bsd: athn0: Michael MIC failure
> Apr 30 02:14:40 smetana /bsd: athn0: Michael
The conclusion of my previous fixes to vmd(8) [1] changes the event
handling in vmctl(8) to support receiving IMSG_VMDOP_TERMINATE_VM_EVENTs
from the control process. (This removes a XXX comment from vmd.)
For clarity, the messaging logic was changed previously:
- ...TERMINATE_VM_RESPONSE
Until a patch from naddy, I wasn't even aware of getopts in sh(1)
Unless I made some mistakes, this translates the example in getopt(1)
manpage.
It's likely some stronger wording might be adequate, I suspect some
of the BUGS section in getopt(1) does not apply to the sh(1) built-in.
Index:
> Date: Fri, 30 Apr 2021 11:56:49 +0200
> From: Florian Obser
>
> This still works fine on
>
> iwm0 at pci2 dev 0 function 0 "Intel AC 7260" rev 0x83, msi
> iwm0: hw rev 0x140, fw ver 17.3216344376.0
Since booting into a kernel with this diff, I've started seeing the
following messages on my
We have released OpenBGPD 6.9p0, which will be arriving in the
OpenBGPD directory of your local OpenBSD mirror soon.
This is the first stable release for the 6.9 version. It includes
the following changes:
* Introduced bgpd(8) 'rde evaluate all' to reduce path hiding in
IXP
Hi Mark,
You and me both ;^)
Until recently, I thought that getopt(1) was POSIX, whereas it is
in fact getopts(1), and it is not a shell built-in there, but a
utility[0].
[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/getopts.html
Cheers,
Raf
On Fri, Apr 30, 2021 at
This still works fine on
iwm0 at pci2 dev 0 function 0 "Intel AC 7260" rev 0x83, msi
iwm0: hw rev 0x140, fw ver 17.3216344376.0
Thanks,
Florian
--
I'm not entirely sure you are real.
On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> Until a patch from naddy, I wasn't even aware of getopts in sh(1)
>
> Unless I made some mistakes, this translates the example in getopt(1)
> manpage.
>
> It's likely some stronger wording might be adequate, I suspect some
> of the
On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> my argument boils down to: sh(1) is small and has no examples. adding
> them changes the (deliberate) nature of the page. ksh(1) is what you
> read when you can;t get to sleep.
>
> why is it wrong to add your example to ksh(1)? why
On Fri, Apr 30, 2021 at 04:07:55PM +0200, Marc Espie wrote:
> On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> > On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
> > >
> > > Unless I made some
On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> On Fri, Apr 30, 2021 at 04:07:55PM +0200, Marc Espie wrote:
> > On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> > > On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > > > Until a patch from naddy, I
On Fri, Apr 30, 2021 at 02:44:01PM +0100, Jason McIntyre wrote:
> On Fri, Apr 30, 2021 at 11:54:16AM +0200, Marc Espie wrote:
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
> >
> > Unless I made some mistakes, this translates the example in getopt(1)
> > manpage.
> >
> >
Marc Espie:
> Until a patch from naddy, I wasn't even aware of getopts in sh(1)
Let's start the discussion with this instead.
This puts the deprecation notice in getopt.1 in a prominent place,
and uses the same snippet in sh.1 and ksh.1.
Index: bin/ksh/ksh.1
Hello tech@,
currently the man-page for strlcpy(3) and strlcat(3) calls
the third argument for those functions "dstsize" whereas the
C source code calls it "dsize". This patch addresses this issue
by renaming it to "dsize" to keep coherency between the man-page
and the source code.
diff --git
On 4/30/21 12:18 PM, Stefan Sperling wrote:
> Our default group cipher is CCMP which should not involve any TKIP MIC
> checks on the AP. Such checks occuring would be a bug in this case.
TKIP has been so easily crackable for over a decade that I wonder if it has a
place in OpenBSD, atleast
Kevin Chadwick wrote:
> On 4/30/21 12:18 PM, Stefan Sperling wrote:
> > Our default group cipher is CCMP which should not involve any TKIP MIC
> > checks on the AP. Such checks occuring would be a bug in this case.
>
> TKIP has been so easily crackable for over a decade that I wonder if it has
I disagree.
"dstsize" is conceptually easier for readers to understand.
Secondly, there is nothing which says the library code has to match the
manual page. Implementation does not need to match documentation.
Emil Engler wrote:
> Hello tech@,
> currently the man-page for strlcpy(3) and
On Fri, Apr 30, 2021 at 12:03:41AM +0200, Stefan Sperling wrote:
> This is another patch for Tx aggregation support in iwm(4).
> I have tested 7265, 8265, and 9560, and they seem to work.
>
> Causes of various fatal firmware errors from my earlier attempts at
> getting this to work have been
On Fri, Apr 30, 2021 at 04:54:57PM +0200, Christian Weisgerber wrote:
> Marc Espie:
>
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
>
> Let's start the discussion with this instead.
>
> This puts the deprecation notice in getopt.1 in a prominent place,
> and uses the
Hi Stefan,
* Stefan Sperling wrote:
> This is another patch for Tx aggregation support in iwm(4).
> I have tested 7265, 8265, and 9560, and they seem to work.
>
> Causes of various fatal firmware errors from my earlier attempts at
> getting this to work have been identified and fixed in this
On Fri, 30 Apr 2021 11:15:21 -0600, "Theo de Raadt" wrote:
> I disagree.
>
> "dstsize" is conceptually easier for readers to understand.
>
> Secondly, there is nothing which says the library code has to match the
> manual page. Implementation does not need to match documentation.
My feelings
On Fri, Apr 30, 2021 at 06:00:00PM +, Kevin Chadwick wrote:
> On 4/30/21 12:18 PM, Stefan Sperling wrote:
> > Our default group cipher is CCMP which should not involve any TKIP MIC
> > checks on the AP. Such checks occuring would be a bug in this case.
>
> TKIP has been so easily crackable
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.28 10:45:20 +0200:
> There are various time fields in the JSON output.
> last_read, last_write, last_updown on sessions, last_update for rib
> entries and last_change for sets. Currently the value is the fmt_timeframe
> string (which looks
On Fri, Apr 30, 2021 at 04:54:57PM +0200, Christian Weisgerber wrote:
> Marc Espie:
>
> > Until a patch from naddy, I wasn't even aware of getopts in sh(1)
>
> Let's start the discussion with this instead.
>
> This puts the deprecation notice in getopt.1 in a prominent place,
> and uses the
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.28 12:40:46 +0200:
> At the moment bgpd will fall back to IPv4 unicast if there was no match in
> the multiprotocol capabilities between local and remote peer.
> This is not correct, if the router expects a certain AFI/SAFI for the
> session then
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.29 15:34:15 +0200:
> Like for rsync repos files in the RRDP repos should be delayed until after
> the validation finished. As with anything RPKI related there is little
> trust in the repositories and their abilities to not botch an update.
>
>
Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.04.29 15:34:15 +0200:
> > Like for rsync repos files in the RRDP repos should be delayed until after
> > the validation finished. As with anything RPKI related there is little
> > trust in the repositories and their
Vitaliy Makkoveev writes:
> On Thu, Apr 29, 2021 at 09:31:57AM -0700, Greg Steuck wrote:
>> Alexander Bluhm writes:
>> >> I like this too. I somehow got the impression that macros are severely
>> >> frowned upon and didn't offer this kind of interface before.
>> >>
>> >> If you get this
On Fri, Apr 30, 2021 at 04:42:12PM +0200, Marc Espie wrote:
> On Fri, Apr 30, 2021 at 03:28:42PM +0100, Jason McIntyre wrote:
> > my argument boils down to: sh(1) is small and has no examples. adding
> > them changes the (deliberate) nature of the page. ksh(1) is what you
> > read when you can;t
On 2021/04/05 09:34, Scott Cheloha wrote:
> > On Apr 5, 2021, at 09:07, Stuart Henderson wrote:
> >
> > I've attached r620-E5_2630v2-2p6c2t.tgz, from Dell PE R620 with E5-2630v2.
> > This is a machine which has "disabling user TSC (skew=XXX)" reported for
> > some cores:
> >
> > Nov 5
> On Apr 30, 2021, at 15:53, Stuart Henderson wrote:
>
> On 2021/04/05 09:34, Scott Cheloha wrote:
On Apr 5, 2021, at 09:07, Stuart Henderson wrote:
>>> I've attached r620-E5_2630v2-2p6c2t.tgz, from Dell PE R620 with E5-2630v2.
>>> This is a machine which has "disabling user TSC
In this auxiliary script, replace the deprecated getopt with getopts.
There is no pressing reason to do so, but let's stop perpetuating
an obsolete idiom.
ok?
Index: usr.sbin/switchd/genmap.sh
===
RCS file:
> On Apr 28, 2021, at 03:47, Claudio Jeker wrote:
>
> There are various time fields in the JSON output.
> last_read, last_write, last_updown on sessions, last_update for rib
> entries and last_change for sets. Currently the value is the fmt_timeframe
> string (which looks something like
/etc/netstart contains the following getopts handler:
while getopts ":n" opt; do
That colon is just totally bogus, isn't it?
tilo
Index: netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.211
diff -u -p
On 22.4.2021. 13:08, Hrvoje Popovski wrote:
> On 22.4.2021. 12:38, Alexander Bluhm wrote:
>> It is not clear why the lock helps. Is it a bug in routing or ARP?
>> Or is it just different timing introduced by the additional kernel
>> lock? The parallel network task stress the subsystems of the
39 matches
Mail list logo
