On Mon, Jul 05, 2021 at 06:36:00PM -0700, Greg Steuck wrote:
> Stefan Sperling writes:
>
> > On Tue, Jul 06, 2021 at 12:31:20AM +0200, Stefan Sperling wrote:
> >> On Mon, Jul 05, 2021 at 02:11:36PM -0700, Greg Steuck wrote:
> >> > Do I need to figure out the state machines behind iwx and iee80211
On Mon, Jul 05, 2021 at 08:11:12PM -0900, Philip Guenther wrote:
> Based on the fts_open(3) manpage and other base source usage, shouldn't
> this use fts_accpath instead of fts_name?
Yes this should use fts_accpath. I knew there was something different
than fts_name. I just missed it when I read
Based on the fts_open(3) manpage and other base source usage, shouldn't
this use fts_accpath instead of fts_name?
The use of fts_statp in this code seems a bit loose vs ftp_info: instead of
using S_ISLNK() on fts_statp I would expect this code to check for fts_info
== FTS_SL: according the manpage
Stefan Sperling writes:
> On Tue, Jul 06, 2021 at 12:31:20AM +0200, Stefan Sperling wrote:
>> On Mon, Jul 05, 2021 at 02:11:36PM -0700, Greg Steuck wrote:
>> > Do I need to figure out the state machines behind iwx and iee80211 now? :)
>>
>> This AP seems to use TKIP for the groupcipher and the i
Stefan Sperling writes:
> This AP seems to use TKIP for the groupcipher and the iwx
> setkey task doesn't handle this case properly.
>
> Can you try this?
This works great, yielding these diagnostics:
iwx0: associated with 38:ff:36:23:09:ac ssid "MarlinGuest" channel 52 start MCS
0 long preamb
On Tue, Jul 06, 2021 at 12:31:20AM +0200, Stefan Sperling wrote:
> On Mon, Jul 05, 2021 at 02:11:36PM -0700, Greg Steuck wrote:
> > Do I need to figure out the state machines behind iwx and iee80211 now? :)
>
> This AP seems to use TKIP for the groupcipher and the iwx
> setkey task doesn't handle
On Mon, Jul 05, 2021 at 02:11:36PM -0700, Greg Steuck wrote:
> Do I need to figure out the state machines behind iwx and iee80211 now? :)
This AP seems to use TKIP for the groupcipher and the iwx
setkey task doesn't handle this case properly.
Can you try this?
diff 7faf78381a333a9545f245f931e6a5
Greg Steuck writes:
> Stefan Sperling writes:
>
>>> iwx0: received msg 3/4 of the 4-way handshake from 38:ff:36:23:09:ac
>>> iwx0: sending msg 4/4 of the 4-way handshake to 38:ff:36:23:09:ac
>>>
>>> I never see "iwx0: sending action to" after this.
>>
>> And you still see status: "no network" i
> Date: Mon, 5 Jul 2021 07:54:10 -0600
> From: "Todd C. Miller"
> That would result in an error like:
>
> ksh: syntax error: `done' unexpected
>
> instead of:
>
> ksh: syntax error: `do' unexpected
>
> But perhaps this is not important. It is also possible to call
> yyerror() direct
> Date: Mon, 5 Jul 2021 19:30:28 +0200
> From: Patrick Wildt
>
> Am Mon, Jul 05, 2021 at 07:07:24PM +0200 schrieb Mark Kettenis:
> > > Date: Mon, 5 Jul 2021 19:02:32 +0200
> > > From: Patrick Wildt
> > >
> > > Am Mon, Jul 05, 2021 at 06:34:31PM +0200 schrieb Mark Kettenis:
> > > > > Date: Mon,
Am Mon, Jul 05, 2021 at 07:07:24PM +0200 schrieb Mark Kettenis:
> > Date: Mon, 5 Jul 2021 19:02:32 +0200
> > From: Patrick Wildt
> >
> > Am Mon, Jul 05, 2021 at 06:34:31PM +0200 schrieb Mark Kettenis:
> > > > Date: Mon, 5 Jul 2021 00:04:24 +0200
> > > > From: Patrick Wildt
> > > >
> > > > Hi,
>
On Mon, Jul 05, 2021 at 10:20:09AM -0700, Greg Steuck wrote:
> Stefan Sperling writes:
>
> > On Mon, Jul 05, 2021 at 09:35:20AM +0200, Stefan Sperling wrote:
> >> On Sun, Jul 04, 2021 at 07:58:47PM -0700, Greg Steuck wrote:
> >> > I never see "iwx0: sending action to" after this.
> >>
> >> And y
Stefan Sperling writes:
>> iwx0: received msg 3/4 of the 4-way handshake from 38:ff:36:23:09:ac
>> iwx0: sending msg 4/4 of the 4-way handshake to 38:ff:36:23:09:ac
>>
>> I never see "iwx0: sending action to" after this.
>
> And you still see status: "no network" in ifconfig at this point?
> Thi
Stefan Sperling writes:
> On Mon, Jul 05, 2021 at 09:35:20AM +0200, Stefan Sperling wrote:
>> On Sun, Jul 04, 2021 at 07:58:47PM -0700, Greg Steuck wrote:
>> > I never see "iwx0: sending action to" after this.
>>
>> And you still see status: "no network" in ifconfig at this point?
>> This could
> Date: Mon, 5 Jul 2021 19:02:32 +0200
> From: Patrick Wildt
>
> Am Mon, Jul 05, 2021 at 06:34:31PM +0200 schrieb Mark Kettenis:
> > > Date: Mon, 5 Jul 2021 00:04:24 +0200
> > > From: Patrick Wildt
> > >
> > > Hi,
> > >
> > > I had trouble interfacing with a machine's IPMI through dwiic(4). W
Am Mon, Jul 05, 2021 at 06:34:31PM +0200 schrieb Mark Kettenis:
> > Date: Mon, 5 Jul 2021 00:04:24 +0200
> > From: Patrick Wildt
> >
> > Hi,
> >
> > I had trouble interfacing with a machine's IPMI through dwiic(4). What
> > I saw was that when sending 'bigger' commands, it would never receive
>
> Date: Mon, 5 Jul 2021 00:04:24 +0200
> From: Patrick Wildt
>
> Hi,
>
> I had trouble interfacing with a machine's IPMI through dwiic(4). What
> I saw was that when sending 'bigger' commands, it would never receive
> the STOP bit interrupt.
>
> The trouble is, as can be seen in the log, that
Alexander Bluhm wrote:
> pledge(2) and so_state SS_DNS are special. There is no real risk
> of a race and the flag is set only at socket creation.
Yes, this looks safe to me. ps_flags PS_PLEDGE and ps_pledge are only
set inside locked pledge(), which makes the pledge_socket() SS_DNS check
non-
On Sun, Jul 04, 2021 at 03:59:53PM +0200, Martin Pieuchot wrote:
> On 02/07/21(Fri) 15:01, Alexander Bluhm wrote:
> > On Fri, Jul 02, 2021 at 01:05:39PM +0200, Martin Pieuchot wrote:
> > > Looks good to me. Grabbing solock() after calling pledge_socket() in
> > > sys_connect(), like it is already
Here, we define mode_t so we can use it as the argument type in string.h
diff --git a/include/string.h b/include/string.h
index 9141c34..482fa275d53 100644
--- a/include/string.h
+++ b/include/string.h
@@ -119,6 +119,12 @@ size_t strxfrm_l(char *__restrict, const char
*__restrict, si
On Mon, Jul 05, 2021 at 09:35:20AM +0200, Stefan Sperling wrote:
> On Sun, Jul 04, 2021 at 07:58:47PM -0700, Greg Steuck wrote:
> > I never see "iwx0: sending action to" after this.
>
> And you still see status: "no network" in ifconfig at this point?
> This could mean we're failing to set the lin
On Mon, 05 Jul 2021 16:30:49 +0959, Reuben ua =?UTF-8?Q?Br=C3=AD=C4=A1?= wrote:
> if i might suggest a slight variation, how about only requiring that
> at least one of the lists is non-empty, in the case of while, and
> leaving for, until, etc. as they are?
>
> this way nothing is broken.
>
> you
On Mon, 05 Jul 2021 15:08:27 +0200, Jeremie Courreges-Anglas wrote:
> LGTM as a first step, ok jca@
Committed.
> I'd prefer to fix the odd uses we have in tree and end up with your
> initial diff in a third step.
>
> Here are the three cases pointed out by halex@, mechanical diff.
>
> ok? / Todd
> Date: Mon, 5 Jul 2021 14:41:46 +0200
> From: Alexander Hall
> I don't really see what you win either.
the point of todds diff is to fix the issue i raised:
Subject: while do done
Date: Mon, 28 Jun 2021 22:20:15 +1000
From: Reuben ua Bríġ
To: m...@openbsd.org
On Mon, 05 Jul 2021 14:47:08 +0200, Alexander Hall wrote:
> Please note that I'm not really opposing the initial suggestion per se. I'm n
> ot sure "do done" is even valid in ksh93.
It is not.
> Nowadays I try to avoid "do done", and my personal scripts breaking I can han
> dle. I was just point
> Date: Sun, 4 Jul 2021 16:25:39 -0600
> From: Todd C. Miller
> let's just require a non-empty expression but still allow an empty
> loop body.
if i might suggest a slight variation, how about only requiring that
at least one of the lists is non-empty, in the case of while, and
leaving for, unt
On July 5, 2021 3:12:07 PM GMT+02:00, "Reuben ua Bríġ"
wrote:
>> Date: Mon, 5 Jul 2021 14:41:46 +0200
>> From: Alexander Hall
>
>> I don't really see what you win either.
>
>the point of todds diff is to fix the issue i raised:
>
> Subject: while do done
> Date: Mon, 28 Jun 2021
On July 5, 2021 3:08:27 PM GMT+02:00, Jeremie Courreges-Anglas
wrote:
>On Sun, Jul 04 2021, Todd C. Miller wrote:
>> On Sun, 04 Jul 2021 23:25:25 +0200, Alexander Hall wrote:
>>
>>> The "... do done" variant has been frequently used by me, and seems to
>>> appear
>>> at least three times in
On Sun, Jul 04 2021, Todd C. Miller wrote:
> On Sun, 04 Jul 2021 23:25:25 +0200, Alexander Hall wrote:
>
>> The "... do done" variant has been frequently used by me, and seems to appear
>> at least three times in install.sub, so if this goes in, please scan the scr
>> ipts in our tree first, at l
On July 5, 2021 12:25:39 AM GMT+02:00, "Todd C. Miller"
wrote:
>On Sun, 04 Jul 2021 23:25:25 +0200, Alexander Hall wrote:
>
>> The "... do done" variant has been frequently used by me, and seems to appear
>> at least three times in install.sub, so if this goes in, please scan the scr
>> ipts
On July 5, 2021 8:31:49 AM GMT+02:00, "Reuben ua Bríġ"
wrote:
>> Date: Sun, 4 Jul 2021 16:25:39 -0600
>> From: Todd C. Miller
>
>> let's just require a non-empty expression but still allow an empty
>> loop body.
>
>if i might suggest a slight variation, how about only requiring that
>at leas
> 5. jul. 2021 kl. 04:58 skrev Greg Steuck :
>
> I stumbled upon a weird hotel WiFi which never gets to a fully running
> link with iwx0. I see ifconfig is stuck with:
>
> iwx0: flags=808847
> mtu 1500
>lladdr xx
>index 1 priority 4 llprio 3
>groups: wlan egress
>
On Sun, Jul 04, 2021 at 07:58:47PM -0700, Greg Steuck wrote:
> I stumbled upon a weird hotel WiFi which never gets to a fully running
> link with iwx0. I see ifconfig is stuck with:
>
> iwx0: flags=808847
> mtu 1500
> lladdr xx
> index 1 priority 4 llprio 3
> groups: wlan
Hi Dave,
> On 3 Jul 2021, at 19:08, Matthias Schmidt wrote:
>
> Hi Dave,
>
> * Dave Voutila wrote:
>> Looking for some broader testing of the following diff. It cleans up
>> some complicated logic predominantly left over from the early days of
>> vmd prior to its having a dedicated device threa
34 matches
Mail list logo