Re: softraid/bioctl cant find device /dev/bio

[sven falempin]

On Mon, Aug 3, 2020 at 11:38 AM Brian Brombacher 
wrote:

>
>
> > On Aug 3, 2020, at 9:54 AM, sven falempin 
> wrote:
> >
> > Hello
> >
> > I saw a similar issue in the mailing list around decembre 2019,
> > following an electrical problem softraid doesn't bring devices ups
> >
> >
> > # ls /dev/sd??
> > /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e
> > /dev/sd2k
> > /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f
> > /dev/sd2l
> > /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g
> > /dev/sd2m
> > /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h
> > /dev/sd2n
> > /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i
> > /dev/sd2o
> > /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j
> > /dev/sd2p
> > # dmesg | grep 6.7
> > OpenBSD 6.7 (RAMDISK_CD) #177: Thu May  7 11:19:02 MDT 2020
> > # dmesg | grep sd
> >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
> > sd0 at scsibus1 targ 0 lun 0: 
> > t10.ATA_QEMU_HARDDISK_Q
> > M5_
> > sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin
> > sd1 at scsibus1 targ 1 lun 0: 
> > t10.ATA_QEMU_HARDDISK_Q
> > M7_
> > sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin
> > wskbd0 at pckbd0: console keyboard, using wsdisplay1
> > softraid0: trying to bring up sd2 degraded
> > softraid0: sd2 was not shutdown properly
> > softraid0: sd2 is offline, will not be brought online
> > # bioctl -d sd2
> > bioctl: Can't locate sd2 device via /dev/bio
> > #
> >
> > I suspect a missing devices in /dev ( but it seems i have the required
> one )
> > and MAKEDEV all of course did a `uid 0 on /: out of inodes`
> >
> > I have backups but i ' d like to fix the issue !
>
> Hi Sven,
>
> The device sd2 wasn’t attached by softraid, your /dev/bio is fine.  This
> can happen if softraid fails to find all component disks or the metadata on
> one or more components does not match expectations (newer metadata seen on
> other disks).  Make sure all of the component disks are working.  If that
> is not the issue, you may need to re-run the command that you used to
> create the array and include -C force.  Be very careful doing this, I
> suggest running the command once without -C force to ensure it found all
> the components and fails to bring the array up due to the same error
> message you got (attempt to bring up degraded).
>
> If you’re not careful, you can blow out the whole array.
>
> -Brian
>
>
> The disk looks fine, the disklabel is ok, the array is just sd0 and sda1
both got the disklabel RAID part,
shall i do further checks ?

# bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0
softraid0: trying to bring up sd2 degraded
softraid0: sd2 was not shutdown properly
softraid0: sd2 is offline, will not be brought online
softraid0: trying to bring up sd2 degraded
softraid0: sd2 was not shutdown properly
softraid0: sd2 is offline, will not be brought online

I wouldnt like to blow the whole array ! sd0a should be in perfect
condition but unsure about sd1a, i probably need to bioctl -R sd1

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

softraid/bioctl cant find device /dev/bio

[sven falempin]

Hello

I saw a similar issue in the mailing list around decembre 2019,
following an electrical problem softraid doesn't bring devices ups


# ls /dev/sd??
/dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e
/dev/sd2k
/dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f
/dev/sd2l
/dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g
/dev/sd2m
/dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h
/dev/sd2n
/dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i
/dev/sd2o
/dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j
/dev/sd2p
# dmesg | grep 6.7
OpenBSD 6.7 (RAMDISK_CD) #177: Thu May  7 11:19:02 MDT 2020
# dmesg | grep sd
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
sd0 at scsibus1 targ 0 lun 0: 
t10.ATA_QEMU_HARDDISK_Q
M5_
sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin
sd1 at scsibus1 targ 1 lun 0: 
t10.ATA_QEMU_HARDDISK_Q
M7_
sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin
wskbd0 at pckbd0: console keyboard, using wsdisplay1
softraid0: trying to bring up sd2 degraded
softraid0: sd2 was not shutdown properly
softraid0: sd2 is offline, will not be brought online
# bioctl -d sd2
bioctl: Can't locate sd2 device via /dev/bio
#

I suspect a missing devices in /dev ( but it seems i have the required one )
and MAKEDEV all of course did a `uid 0 on /: out of inodes`

I have backups but i ' d like to fix the issue !

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: NET_LOCK and trunk detach

[sven falempin]

On Tue, Jul 28, 2020 at 4:42 PM Vitaliy Makkoveev  wrote:
>
> On Tue, Jul 28, 2020 at 04:10:01PM -0400, sven falempin wrote:
> > Hello,
> >
> > I am running some trunk interfaces in a multi core environment,
> > it's a slightly modified version, i have a few NET_ASSERT_LOCKED();
> > suspecting some multi core shenanigans, which i guess was confirmed:
> > (unsure the have X meaning, but i ' m pretty sure 256 is very wrong)
> > the if_trunk.c locking is completely unmodified
> > The code is 6.7-stable
> >
> > splassert: lacp_detach: want 2 have 0
> > splassert: lacp_detach: want 2 have 0
> > splassert: lacp_detach: want 2 have 256
> >
> > I noticed : trunk_clone_destroy ,call
> >
> > if (tr->tr_proto != TRUNK_PROTO_NONE)
> > tr->tr_detach(tr);
> >
> > outside the lock, and that trunk_ioctl call it
> >
> > if (tr->tr_proto != TRUNK_PROTO_NONE)
> > error = tr->tr_detach(tr);
> >
> > but ioctl is as far as i understand locked.
> > I'm unsure if the difficult and amazing unlocking work
> > did an oopsies or if ioctl is already assumed unlocked.
> >
> > Kindly inform me.
> > Best regards, thank you for reading.
> >
>
> lacp_detach() touches nothing which requires NET_LOCK(). What is the
> reason you placed assertion to lacp_detach()?

<>

the lacp_detach is not yours, i put them here because i have a NULL pointer
popping in other 'driver' callback.

I'm tracking this and trying to understand  how this memory is 'nullified'
mid function.

I do not think putting NET_ASSERT_LOCKED can be harmful in any way.
If so please tell me.

I am just tracking  a bug  and noticed these detach locking strangeness.

NET_LOCK and trunk detach

[sven falempin]

Hello,

I am running some trunk interfaces in a multi core environment,
it's a slightly modified version, i have a few NET_ASSERT_LOCKED();
suspecting some multi core shenanigans, which i guess was confirmed:
(unsure the have X meaning, but i ' m pretty sure 256 is very wrong)
the if_trunk.c locking is completely unmodified
The code is 6.7-stable

splassert: lacp_detach: want 2 have 0
splassert: lacp_detach: want 2 have 0
splassert: lacp_detach: want 2 have 256

I noticed : trunk_clone_destroy ,call

if (tr->tr_proto != TRUNK_PROTO_NONE)
tr->tr_detach(tr);

outside the lock, and that trunk_ioctl call it

if (tr->tr_proto != TRUNK_PROTO_NONE)
error = tr->tr_detach(tr);

but ioctl is as far as i understand locked.
I'm unsure if the difficult and amazing unlocking work
did an oopsies or if ioctl is already assumed unlocked.

Kindly inform me.
Best regards, thank you for reading.

Re: acme-client config grammar improvements

[sven falempin]

On Fri, Jul 24, 2020 at 10:47 AM Florian Obser  wrote:

> On Thu, Jul 16, 2020 at 07:40:35AM +0200, Daniel Eisele wrote:
> > Also it would be nice to have a feature to update all domains of the
> > config file. I currently do that in a shell script by parsing the output
> > of acme-client -nv with sed and then calling acme-client multiple times.
> >
> > Maybe an easy solution would be an option that prints the list of all
> > domains, so I can avoid the sed parsing, as this is prone to breaking.
>
> I'm not opposed to that. You will probably need to output some form of
> csv.
>
> Consider this:
>
> domain handle1-example.com {
> domain name example.com
> alternative names { www.example.com secure.example.com }
> domain key "/etc/ssl..." rsa
> }
> domain handle2-example.com {
> domain name example.com
> alternative names { mail.example.com }
> domain key "/etc/ssl..." ecdsa
> }
>
> Should it be output like this?
>
> handle1-example.com; example.com; www.example.com, secure.example.com
> handle2-example.com; example.com; mail.example.com
>
> Or this?
>
> handle1-example.com; example.com; www.example.com
> handle1-example.com; example.com; secure.example.com
> handle2-example.com; example.com; mail.example.com
>
>
> >
> > Another solution is obviously to just add an "update all" command line
> > option (or maybe even in the config?), but that is probably more
> > complicated to implement.
>
> I'm more worried that you will very soon end up with some form of exec
> plugin mechanism. Typically you need to do something when a cert is
> renewed (restart daemon).
>
> My acme-client.conf is generate by a config management system which
> also creates individual cronjobs for each renew job and knows how to
> handle a cert renew.
>
> >
> > What do you think about that?
> >
>

A management system may auto reload services when the configuration files
changes , an update all would be convenient.

Moreover

Acme-client update && rcctl reload nginx

Once a week is easy , as acme-client will not return 0 if nothing is
changed .




> --
> I'm not entirely sure you are real.
>
> --
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

UPgrading pkg to 6.7 missed a package

[sven falempin]

Readers,

pkg_add -u
failed to upgrade

p5-DBD-MariaDB-1.2
to
p5-DBD-MariaDB-1.21p0

p5-DBD-MariaDB-1.2 is previous released so maybe it is too old and my fault
, but it is
odd that pkg_add -u p5-DBD-MariaDB does nothing when p5-DBD-MariaDB-1.2 is
in the package list

and p5-DBD-MariaDB-1.21p0.tgz available in the package depot.

Best.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: download site or stuff from sources with weak password

[sven falempin]

On Mon, Jul 13, 2020 at 2:38 PM Theo de Raadt  wrote:

> I am sceptical of any need to support what you propose, especially
> when it isn't documented, and secondly when it is shitty, and
> outside the scope of the project.
>


FTP(1) General Commands ManualFTP(1)

NAME
 ftp - Internet file transfer program

SYNOPSIS
 ftp [-46AadEegiMmnptVv] [-D title] [-k seconds] [-P port] [-r seconds]
 [-s srcaddr] [host [port]]
 ftp [-C] [-o output] [-s srcaddr]
 ftp://[user:password@]host[:port]/file[/]

documented here


-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

download site or stuff from sources with weak password

[sven falempin]

?(+([!@])@)

is not very smart for something:something@
but i guess it is enough ?

( tabulation should be present below )

Index: ./distrib/miniroot/install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1154
diff -u -p -r1.1154 install.sub
--- ./distrib/miniroot/install.sub  26 May 2020 16:21:00 -
1.1154
+++ ./distrib/miniroot/install.sub  13 Jul 2020 18:26:42 -
@@ -1775,7 +1775,7 @@ install_http() {
HTTP_SERVER=${1%%/*}
# Repeat loop to get user to confirm server address.
;;
-   ?(http?(s)://)+([A-Za-z0-9:.\[\]_-]))
+   ?(http?(s)://)?(+([!@])@)+([A-Za-z0-9:.\[\]_-]))
case $resp in
https://*)  _tls=force _http_proto=https;;
http://*)   _tls=no_http_proto=http;;

--

Re: bridge(4) shouldn't try to create new interfaces when i make a typo

[sven falempin]

On Thu, Jul 9, 2020 at 3:31 AM Klemens Nanni  wrote:
>
> On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote:
> > if i accidentally `ifconfig bridge add gre0` instead of egre0, having
> > bridge create gre0 and then not like it is not what i expect to happen.
> > especially when it leaves me with an extra gre0 interface lying around
> > afterwards.
> >
> > i can appreciate that this was trying to be helpful when you wanted
> > to add virtual interfaces to a bridge on boot, but that was before
> > netstart(8) created all the interfaces with config files up front, before
> > it then goes through and runs the config for them.
> I agree.
>
> OK kn
>

this will force the use of create beforehand ?
or ifconfig bridge0 up will still work ?

because script in the wild may not do the create first.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: Stuck in Needbuf state, trying to understand (6.7)

[sven falempin]

On Mon, Jun 29, 2020 at 12:58 PM sven falempin 
wrote:

>
>
> On Mon, Jun 29, 2020 at 12:12 PM Bob Beck  wrote:
>
>>
>> > Awesome, thanks!
>> >
>> > I will test that, ASAP,
>> > do not hesitate to slay dragon,
>> > i heard the bathing in the blood pool is good for the skin
>> >
>> > Little concern, I did the test without the MFS and ran into issues ,
>> > anyway i get back to you (or list ?) when i have test report with
>> patched
>> > kernel
>>
>> Yes, howver, you didn't tell my what options you had on the filesystem
>> mounted
>> when you did the test without MFS, because it matters. If you had your
>> filesystem
>> mounted ASYNC it would have exhibited the same behavoir.  the issue is
>> due to the
>> async mount, which MFS does by default, not strictly to do with MFS.
>>
>>
> tmpfs was just not mounted so it was the option of the underlying /home
>
> /dev/sd0d on /home type ffs (local, nodev, nosuid)
>
> So far the above patch improve the situation drastically
>
> I will now perform a test in the original device.
>
>
>
It works in the original problematic setup.

Will it go to base ?

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: Stuck in Needbuf state, trying to understand (6.7)

[sven falempin]

On Mon, Jun 29, 2020 at 12:12 PM Bob Beck  wrote:

>
> > Awesome, thanks!
> >
> > I will test that, ASAP,
> > do not hesitate to slay dragon,
> > i heard the bathing in the blood pool is good for the skin
> >
> > Little concern, I did the test without the MFS and ran into issues ,
> > anyway i get back to you (or list ?) when i have test report with patched
> > kernel
>
> Yes, howver, you didn't tell my what options you had on the filesystem
> mounted
> when you did the test without MFS, because it matters. If you had your
> filesystem
> mounted ASYNC it would have exhibited the same behavoir.  the issue is due
> to the
> async mount, which MFS does by default, not strictly to do with MFS.
>
>
tmpfs was just not mounted so it was the option of the underlying /home

/dev/sd0d on /home type ffs (local, nodev, nosuid)

So far the above patch improve the situation drastically

I will now perform a test in the original device.

Re: Stuck in Needbuf state, trying to understand (6.7)

[sven falempin]

On Mon, Jun 29, 2020 at 11:44 AM Bob Beck  wrote:

> On Sun, Jun 28, 2020 at 12:18:06PM -0400, sven falempin wrote:
> > On Sun, Jun 28, 2020 at 2:40 AM Bryan Linton  wrote:
> >
> > > On 2020-06-27 19:29:31, Bob Beck  wrote:
> > > >
> > > > No.
> > > >
> > > > I know *exactly* what needbuf is but to attempt to diagnose what your
> > > > problem is we need exact details. especially:
> > > >
> > > > 1) The configuration of your system including all the details of the
> > > filesystems
> > > > you have mounted, all options used, etc.
> > > >
> > > > 2) The script you are using to generate the problem (Not a
> paraphrasing
> > > of what
> > > > you think the script does) What filesystems it is using.
> > > >
> > >
> > > Not the OP, but this problem sounds almost exactly like the bug I
> > > reported last year.
> > >
> > > There is a detailed list of steps I used to reproduce the bug in
> > > the following bug report.
> > >
> > > https://marc.info/?l=openbsd-bugs=156412299418191
> > >
> > > I was even able to bisect and identify the commit which first
> > > caused the breakage for me.
> > >
> > >
> > > ---8<---
> > >
> > > CVSROOT:/cvs
> > > Module name:src
> > > Changes by: b...@cvs.openbsd.org2019/05/08 06:40:57
> > >
> > > Modified files:
> > > sys/kern   : vfs_bio.c vfs_biomem.c
> > >
> > > Log message:
> > > Modify the buffer cache to always flip recovered DMA buffers high.
> > >
> > > This also modifies the backoff logic to only back off what is requested
> > > and not a "mimimum" amount. Tested by me, benno@, tedu@ anda ports
> build
> > > by naddy@.
> > >
> > > ok tedu@
> > >
> > > ---8<---
> > >
> > > However, I have since migrated away from using vnd(4)s since I was
> > > able to find other solutions that worked for my use cases.  So I
> > > may not be able to provide much additional information other than
> > > what is contained in the above bug report.
> > >
> > > --
> > > Bryan
> > >
> > > >
> > > >
> > >
> > >
> > Reproduction of BUG.
> >
> >
> > # optional
> > mkdir /tmpfs
> > mount_mfs -o rw -s 2500M swap /tmpfs # i mounted through fstab so this
> line
> > is not tested
> > #the bug
> > /bin/dd if=/dev/zero of=/tmpfs/img.dd count=0 bs=1 seek=25
> > vnconfig vnd3 /tmpfs/img.dd
> > printf "a a\n\n\n\nw\nq\n" | disklabel -E vnd3
> > newfs vnd3a
> > mount /dev/vnd3a /mnt
> > cd /tmp && ftp https://cdn.openbsd.org/pub/OpenBSD/6.7/amd64/base67.tgz
> > cd /mnt
> > #will occur here (the mkdir was ub beedbuf state for a while ...
> > for v in 1 2 3 4 5 6 7 8 9; do mkdir /tmp/$v; tar xzvf /tmp/base67.tgz -C
> > /mnt/$v; done
> >
> > Ready to test patches.
> >
> >
>
> So, your problem is that you have your vnd created in an mfs
> filesystem, when I run your test with the vnd backed by a regular
> filesystem (withe softdep even) it works fine.
>
> The trouble happens when your VND has buffers cached in it's
> "filesystem" but then is not flushing them out to the underlyin file
> (vnode) that you have your vnd backed by.  On normal filesystems this
> works fine, since vnd tells the lower layer to not cache the writes
> and to do them syncrhonously, to avoid an explosion of delayed writes
> and dependencies of buffers.
>
> The problem happens when we convert syncryonous bwrites to
> asynchronous bdwrites if the fileystem is mounted ASYNC, which,
> curiously, MFS always is (I don't know why, it doesn't really make any
> sense, and I might even look at changing that) All the writes you do
> end up being delayed anc chewing up more buffer space. And they are
> all tied to one vnode (your image).  once you exhaust the buffer
> space, the cleaner runs, but as you have noticed can't clean out your
> vnode until the syncer runs (every 60 seconds).  This is why your
> thing "takes a long time", and things stall in need buffer. softdep
> has deep dark voodoo in it to avoid this problem and therefore when I
> use a softdep filesystem instead of an ASYNC filesystem it works.
>
> Anyway, what's below fixes your issue on my machine. I'm not sure I'm
> happy that it's the final fix but it does fix it. there are many 

Re: Stuck in Needbuf state, trying to understand (6.7)

[sven falempin]

On Sun, Jun 28, 2020 at 2:40 AM Bryan Linton  wrote:

> On 2020-06-27 19:29:31, Bob Beck  wrote:
> >
> > No.
> >
> > I know *exactly* what needbuf is but to attempt to diagnose what your
> > problem is we need exact details. especially:
> >
> > 1) The configuration of your system including all the details of the
> filesystems
> > you have mounted, all options used, etc.
> >
> > 2) The script you are using to generate the problem (Not a paraphrasing
> of what
> > you think the script does) What filesystems it is using.
> >
>
> Not the OP, but this problem sounds almost exactly like the bug I
> reported last year.
>
> There is a detailed list of steps I used to reproduce the bug in
> the following bug report.
>
> https://marc.info/?l=openbsd-bugs=156412299418191
>
> I was even able to bisect and identify the commit which first
> caused the breakage for me.
>
>
> ---8<---
>
> CVSROOT:/cvs
> Module name:src
> Changes by: b...@cvs.openbsd.org2019/05/08 06:40:57
>
> Modified files:
> sys/kern   : vfs_bio.c vfs_biomem.c
>
> Log message:
> Modify the buffer cache to always flip recovered DMA buffers high.
>
> This also modifies the backoff logic to only back off what is requested
> and not a "mimimum" amount. Tested by me, benno@, tedu@ anda ports build
> by naddy@.
>
> ok tedu@
>
> ---8<---
>
> However, I have since migrated away from using vnd(4)s since I was
> able to find other solutions that worked for my use cases.  So I
> may not be able to provide much additional information other than
> what is contained in the above bug report.
>
> --
> Bryan
>
> >
> >
>
>
Reproduction of BUG.


# optional
mkdir /tmpfs
mount_mfs -o rw -s 2500M swap /tmpfs # i mounted through fstab so this line
is not tested
#the bug
/bin/dd if=/dev/zero of=/tmpfs/img.dd count=0 bs=1 seek=25
vnconfig vnd3 /tmpfs/img.dd
printf "a a\n\n\n\nw\nq\n" | disklabel -E vnd3
newfs vnd3a
mount /dev/vnd3a /mnt
cd /tmp && ftp https://cdn.openbsd.org/pub/OpenBSD/6.7/amd64/base67.tgz
cd /mnt
#will occur here (the mkdir was ub beedbuf state for a while ...
for v in 1 2 3 4 5 6 7 8 9; do mkdir /tmp/$v; tar xzvf /tmp/base67.tgz -C
/mnt/$v; done

Ready to test patches.



-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: Stuck in Needbuf state, trying to understand (6.7)

[sven falempin]

On Fri, Jun 26, 2020 at 7:35 PM sven falempin 
wrote:

>
>
> On Fri, Jun 26, 2020 at 5:22 PM Stuart Henderson 
> wrote:
>
>> On 2020/06/26 15:30, sven falempin wrote:
>> > behavior confirmed on current.
>> >
>> > Once the process stalls,  ( could be anything writing to the vnconfig
>> disk,
>> > cp , umount )
>> > a few other calls like df , or ps, etc may hang, never the same
>> > sp or mp kernel, reproduced on today's snapshots.
>>
>> vnconfig is used as part of "make release", many builds are done every
>> week using this so it's not a general problem with vnconfig.
>>
>> Can you show some commands or a script to trigger the behaviour?
>>
>
> the perl script use the system to call :
>
> vnconfig.
> mount.
> umount. <- saw hanged
> cp.<- saw hanged
> tar.<- saw hanged
> svn up.<- saw hanged
> and dd.
> newfs.
>
> really nothing fancy, only stuff writing to disk got stuck.
>
> At one point it does a chroot but it never hangs near that , most of the
> time it hangs before.
>
> The script has been used like 1000 times on 6.0 and maybe twice more on
> 6.4.
>
> I have absolutely no idea what the 'needbuf' of top is .
>
> the script hangs at random position , always writing into vnconfig.
>
> I have no idea how to reproduce outside the perl script , so maybe it is
> related
> to some devious perl stdin/stdout buffer .
>
> Nevertheless there's like a 5% chance that's the script will work( slowly )
>
> Most of the system call are inside a routine to log
>
> sub debug_system {
>   $logger->debug('running: '.join(' ', @_));
>   return system(@_);
> }
>
> so i can easily put things inside to try to understand the issue.
>
> It is really a strange behavior, and the device must be shut down
> electrically.
> Something really odd, i run syslogd on a buffer, and syslogc buffer is
> stuck too
> when the device stuck (but it supposed to be mostly already allocated
> memory ).
>
> It's really like the vm does not want to give anymore bucket (<- i
> don't know what i m talking about here,
> but i looks like that anything that doesn't malloc is ok , computer reply
> to ping , can do a few things for a while , and then complete
> hang )
>
> I ran the 6.7 release on a VM somewhere and another device with many perl
> script and they work.
>
> Only this fails 95% of the time and is VERY VERY slow when ok.
> compared to what i saw in /usr/src the vnconfig is big ,  ( forgot to copy
> df -h  ),
> like 2GB
>


i put ktrace in front of the perl system call

An di was able to recover a 800MB trace

$ kdump -f ./trace.out | tail -20
kdump: realloc: Cannot allocate memory
 25955 UNKNOWN(1634890859)
 72466 ▒▒▒ CALL  syscall()


could that be of some use ?


-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: Stuck in Needbuf state, trying to understand (6.7)

[sven falempin]

On Fri, Jun 26, 2020 at 5:22 PM Stuart Henderson 
wrote:

> On 2020/06/26 15:30, sven falempin wrote:
> > behavior confirmed on current.
> >
> > Once the process stalls,  ( could be anything writing to the vnconfig
> disk,
> > cp , umount )
> > a few other calls like df , or ps, etc may hang, never the same
> > sp or mp kernel, reproduced on today's snapshots.
>
> vnconfig is used as part of "make release", many builds are done every
> week using this so it's not a general problem with vnconfig.
>
> Can you show some commands or a script to trigger the behaviour?
>

the perl script use the system to call :

vnconfig.
mount.
umount. <- saw hanged
cp.<- saw hanged
tar.<- saw hanged
svn up.<- saw hanged
and dd.
newfs.

really nothing fancy, only stuff writing to disk got stuck.

At one point it does a chroot but it never hangs near that , most of the
time it hangs before.

The script has been used like 1000 times on 6.0 and maybe twice more on 6.4.

I have absolutely no idea what the 'needbuf' of top is .

the script hangs at random position , always writing into vnconfig.

I have no idea how to reproduce outside the perl script , so maybe it is
related
to some devious perl stdin/stdout buffer .

Nevertheless there's like a 5% chance that's the script will work( slowly )

Most of the system call are inside a routine to log

sub debug_system {
  $logger->debug('running: '.join(' ', @_));
  return system(@_);
}

so i can easily put things inside to try to understand the issue.

It is really a strange behavior, and the device must be shut down
electrically.
Something really odd, i run syslogd on a buffer, and syslogc buffer is
stuck too
when the device stuck (but it supposed to be mostly already allocated
memory ).

It's really like the vm does not want to give anymore bucket (<- i
don't know what i m talking about here,
but i looks like that anything that doesn't malloc is ok , computer reply
to ping , can do a few things for a while , and then complete
hang )

I ran the 6.7 release on a VM somewhere and another device with many perl
script and they work.

Only this fails 95% of the time and is VERY VERY slow when ok.
compared to what i saw in /usr/src the vnconfig is big ,  ( forgot to copy
df -h  ),
like 2GB

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

pkg_add.1

[sven falempin]

Dear readers,

It may not be very obvious that 'dry run' mode of pkg_add
actually downloads packages.
It is a good feature and maybe the pkg_add man could use an EXAMPLES
section.

Index: pkg_add.1
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
retrieving revision 1.163
diff -u -p -r1.163 pkg_add.1
--- pkg_add.1   24 Jan 2020 21:10:46 -  1.163
+++ pkg_add.1   23 Jun 2020 23:25:12 -
@@ -836,6 +836,18 @@ information about individual packages
 database of installed
 .Xr packages 7
 .El
+.Sh EXAMPLES
+It is possible to download packages before installing them to separate
download and installation process.
+.Pp
+.Dl PKG_CACHE=/tmp/pkgs pkg_add -I -u -n
+.Pp
+will download the package(s) to be updated into .Dq /tmp/pkgs
+directory
+and they can be installed later
+.Pp
+pkg_add -I /tmp/pkgs/*
+.Pp
+.El
 .Sh SEE ALSO
 .Xr ftp 1 ,
 .Xr pkg_create 1 ,

Best,

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

On Mon, Jun 8, 2020 at 1:48 PM Stefan Sperling  wrote:
>
> On Fri, May 22, 2020 at 01:48:28PM -0400, sven falempin wrote:
> >  After a few days ... (free size too small  288 < 1024 /2 )
> >
> > Maybe this can help make the driver better.
> >
> > printf '%x\n' $((0x350+0xf7)) ; grep -A2 'if_iwx.c:515'  /tmp/iwx.dis
> > 447
> > /usr/src/sys/dev/pci/if_iwx.c:515
> >  447:   41 c7 86 28 2f 05 00movl   $0x0,0x52f28(%r14)
> >  44e:   00 00 00 00
> >
> > [0]-[current]-[~]
> > # cat -n /usr/src/sys/dev/pci/if_iwx.c | grep -C5 -E '  515'
> >510  /* free paging*/
> >511  for (i = 0; i < dram->paging_cnt; i++)
> >512  iwx_dma_contig_free(dram->paging);
> >513
> >514  free(dram->paging, M_DEVBUF, dram->paging_cnt *
> > sizeof(*dram->paging));
> >515  dram->paging_cnt = 0;
> >516  dram->paging = NULL;
> >517  }
> >518
> >519  int
> >520  iwx_get_num_sections(const struct iwx_fw_sects *fws, int start
>
> This should fix free with a wrong size in the error case, and avoids
> re-allocating a chunk of DMA memory (sc->ctxt_info_dma) every time the
> firmware gets loaded. Instead, this chunk is now allocated once at
> attach time. This seems to be the allocation that failed in your case.
>
> diff 66ecf2e2f524653126dce17a447a43b26ee90abb /usr/src
> blob - c3ca08c7a726326e37cda8645596a176051b6cf4
> file + sys/dev/pci/if_iwx.c
> --- sys/dev/pci/if_iwx.c
> +++ sys/dev/pci/if_iwx.c
> @@ -230,7 +230,7 @@ int iwx_alloc_fw_monitor_block(struct iwx_softc *, uin
>  intiwx_alloc_fw_monitor(struct iwx_softc *, uint8_t);
>  intiwx_apply_debug_destination(struct iwx_softc *);
>  intiwx_ctxt_info_init(struct iwx_softc *, const struct iwx_fw_sects *);
> -void   iwx_ctxt_info_free(struct iwx_softc *);
> +void   iwx_ctxt_info_free_fw_img(struct iwx_softc *);
>  void   iwx_ctxt_info_free_paging(struct iwx_softc *);
>  intiwx_init_fw_sec(struct iwx_softc *, const struct iwx_fw_sects *,
> struct iwx_context_info_dram *);
> @@ -535,52 +535,60 @@ iwx_init_fw_sec(struct iwx_softc *sc, const struct iwx
>  struct iwx_context_info_dram *ctxt_dram)
>  {
> struct iwx_self_init_dram *dram = >init_dram;
> -   int i, ret, lmac_cnt, umac_cnt, paging_cnt;
> +   int i, ret, fw_cnt = 0;
>
> KASSERT(dram->paging == NULL);
>
> -   lmac_cnt = iwx_get_num_sections(fws, 0);
> +   dram->lmac_cnt = iwx_get_num_sections(fws, 0);
> /* add 1 due to separator */
> -   umac_cnt = iwx_get_num_sections(fws, lmac_cnt + 1);
> +   dram->umac_cnt = iwx_get_num_sections(fws, dram->lmac_cnt + 1);
> /* add 2 due to separators */
> -   paging_cnt = iwx_get_num_sections(fws, lmac_cnt + umac_cnt + 2);
> +   dram->paging_cnt = iwx_get_num_sections(fws,
> +   dram->lmac_cnt + dram->umac_cnt + 2);
>
> -   dram->fw = mallocarray(umac_cnt + lmac_cnt, sizeof(*dram->fw),
> -   M_DEVBUF,  M_ZERO | M_NOWAIT);
> -   if (!dram->fw)
> +   dram->fw = mallocarray(dram->umac_cnt + dram->lmac_cnt,
> +   sizeof(*dram->fw), M_DEVBUF,  M_ZERO | M_NOWAIT);
> +   if (!dram->fw) {
> +   printf("%s: could not allocate memory for firmware 
> sections\n",
> +   DEVNAME(sc));
> return ENOMEM;
> -   dram->paging = mallocarray(paging_cnt, sizeof(*dram->paging),
> +   }
> +
> +   dram->paging = mallocarray(dram->paging_cnt, sizeof(*dram->paging),
> M_DEVBUF, M_ZERO | M_NOWAIT);
> -   if (!dram->paging)
> +   if (!dram->paging) {
> +   printf("%s: could not allocate memory for firmware paging\n",
> +   DEVNAME(sc));
> return ENOMEM;
> +   }
>
> /* initialize lmac sections */
> -   for (i = 0; i < lmac_cnt; i++) {
> +   for (i = 0; i < dram->lmac_cnt; i++) {
> ret = iwx_ctxt_info_alloc_dma(sc, >fw_sect[i],
> -  >fw[dram->fw_cnt]);
> +  >fw[fw_cnt]);
> if (ret)
> return ret;
> ctxt_dram->lmac_img[i] =
> -   htole64(dram->fw[dram->fw_cnt].paddr);
> +   htole64(dram->fw[fw_cnt].paddr);
> DPRINTF(("%s: firmware LMAC section %d at 0x%llx size 
> %lld\n", __func__, i,
> - 

dhclient new commit are good but....

[sven falempin]

Dear readers,

  since 5.8 i ve been carrying around patches to manage :
* crazy server sending hostname like "crazy ISP name with space" ( in
one case the ignore or supersede failed to workaround the problem ),
it  is a bit hard to test, and it looks like some improvement was made
to crash fatal on all invalid network information,
* and a bridging case, which is more realistic :

Assuming the EGRESS is Bridged to a vether, a pair or something to
serve the same LAN to a VM or something else, the first dhclient will eat
the paquet in the BPF filter because MAC are ignored.

MAC are ignored for some obscure historic case where the dhcp server responded
with broadcast or something.

To see the problem , assuming em0 is egress like :

# ifconfig  em0
em0: 
flags=808b43
mtu 1500
lladdr 00:ff:18:0b:4a:ee
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 172.16.1.4 netmask 0xff00 broadcast 172.16.1.255

Bridge it to something

ifconfig  vether0 create
ifconfig  vether0 rdomain 1
ifconfig  bridge0 create
ifconfig  bridge0 add em0
ifconfig  bridge0 add vether0
#safety net
echo <<< EOF >> /etc/dhclient
interface "vether1" {
send host-name "bridged-sub-host-1";
send dhcp-lease-time 3600;
ignore domain-name-servers,routers;
require subnet-mask,domain-name-servers;
}
#testing
ifconfig  bridge0 up
route -T 1 exec dhclient vether0

No lease ! because dhclient on em0 is actually filtering them at bpf level
A year ago the hw_addr was kept inside the daemon so i am not sure how
to apply my bpf filter.

To not break something the path add a -m option to dhclient that
enable mac bpf filter awareness,

In configure_bpf_sock, I added a  ` uint8_t *  ether_addr_octet` param
that is not null
and setup in case -m is passed to fill in a slightly different filter.

/* Set up the bpf filter program structure. */
p.bf_len = dhcp_bpf_mac_filter_len;
p.bf_insns = dhcp_bpf_mac_filter;
dhcp_bpf_mac_filter[8].k = LOCAL_PORT;
memcpy(, ether_addr_octet, sizeof(bits16));
dhcp_bpf_mac_filter[10].k = ntohs(bits16);
memcpy(, ether_addr_octet + 2, sizeof(bits));
dhcp_bpf_mac_filter[12].k = ntohl(bits);

with the filter :

struct bpf_insn dhcp_bpf_mac_filter[] = {
/* Make sure this is an IP packet. */
BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 12),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_IP, 0, 8),

/* Make sure it's a UDP packet. */
BPF_STMT(BPF_LD + BPF_B + BPF_ABS, 23),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 6),

/* Make sure this isn't a fragment. */
BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20),
BPF_JUMP(BPF_JMP + BPF_JSET + BPF_K, 0x1fff, 8, 0),

/* Get the IP header length. */
BPF_STMT(BPF_LDX + BPF_B + BPF_MSH, 14),

/* Make sure it's to the right port. */
BPF_STMT(BPF_LD + BPF_H + BPF_IND, 16),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 67, 0, 1),  /* patch */

/* check bootp.hw.addr 2 bytes */
BPF_STMT(BPF_LD + BPF_H + BPF_IND, 50),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0x, 0, 3),  /* patch */
/* check bootp.hw.addr 4 bytes */
BPF_STMT(BPF_LD + BPF_W + BPF_IND, 52),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0x, 0, 1),  /* patch */

/* If we passed all the tests, ask for the whole packet. */
BPF_STMT(BPF_RET+BPF_K, (unsigned int)-1),

/* Otherwise, drop it. */
BPF_STMT(BPF_RET+BPF_K, 0),
};

int dhcp_bpf_filter_len = sizeof(dhcp_bpf_filter) / sizeof(struct bpf_insn);
int dhcp_bpf_mac_filter_len = sizeof(dhcp_bpf_mac_filter) /
sizeof(struct bpf_insn);

I would gladly test an officially made diff because this is becoming
hard to maintain,
and there should be use cases out there.

The only workaround I know is to put egress in a vether behind the bridges,
certainly something that could break anyway.

Thanks for reading up to there !

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: Correcty reloading unresolved host in syslogd @Conf lines

[sven falempin]

On Mon, May 18, 2020 at 5:31 AM Alexander Bluhm 
wrote:

> On Sat, May 16, 2020 at 07:23:37PM -0400, sven falempin wrote:
> > This was looked at before.
> > Did not get through.
>
> The posted diff was not my final solution.  But yes, the issue was
> forgotten.  So I would suggest this.
>
> When DNS lookup of an UDP loghost failed, syslogd(8) did close the
> UDP sockets for sending messages.  Keep the sockets open in this
> case.  Then they can be used if DNS is working during the next
> SIGHUP.
>
> ok?
>
> bluhm
>
> Index: usr.sbin/syslogd/syslogd.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
> retrieving revision 1.262
> diff -u -p -r1.262 syslogd.c
> --- usr.sbin/syslogd/syslogd.c  5 Jul 2019 13:23:27 -   1.262
> +++ usr.sbin/syslogd/syslogd.c  9 Feb 2020 20:25:20 -
> @@ -853,20 +853,6 @@ main(int argc, char *argv[])
> event_add(ev_udp, NULL);
> if (fd_udp6 != -1)
> event_add(ev_udp6, NULL);
> -   } else {
> -   /*
> -* If generic UDP file descriptors are used neither
> -* for receiving nor for sending, close them.  Then
> -* there is no useless *.514 in netstat.
> -*/
> -   if (fd_udp != -1 && !send_udp) {
> -   close(fd_udp);
> -   fd_udp = -1;
> -   }
> -   if (fd_udp6 != -1 && !send_udp6) {
> -   close(fd_udp6);
> -   fd_udp6 = -1;
> -   }
> }
> for (i = 0; i < nbind; i++)
> if (fd_bind[i] != -1)
> @@ -2416,6 +2402,7 @@ init(void)
> s = 0;
> strlcpy(progblock, "*", sizeof(progblock));
> strlcpy(hostblock, "*", sizeof(hostblock));
> +   send_udp = send_udp6 = 0;
> while (getline(, , cf) != -1) {
> /*
>  * check for end-of-section, comments, strip off trailing
> @@ -2508,6 +2495,22 @@ init(void)
> Initialized = 1;
> dropped_warn(_dropped, "during initialization");
>
> +   if (SecureMode) {
> +   /*
> +* If generic UDP file descriptors are used neither
> +* for receiving nor for sending, close them.  Then
> +* there is no useless *.514 in netstat.
> +*/
> +   if (fd_udp != -1 && !send_udp) {
> +   close(fd_udp);
> +   fd_udp = -1;
> +   }
> +   if (fd_udp6 != -1 && !send_udp6) {
> +   close(fd_udp6);
> +   fd_udp6 = -1;
> +   }
> +   }
> +
> if (Debug) {
> SIMPLEQ_FOREACH(f, , f_next) {
> for (i = 0; i <= LOG_NFACILITIES; i++)
> @@ -2755,6 +2758,13 @@ cfline(char *line, char *progblock, char
> sizeof(f->f_un.f_forw.f_addr)) != 0) {
> log_warnx("bad hostname \"%s\"",
> f->f_un.f_forw.f_loghost);
> +   /* DNS lookup may work after SIGHUP, keep sockets
> */
> +   if (strcmp(proto, "udp") == 0)
> +   send_udp = send_udp6 = 1;
> +   else if (strcmp(proto, "udp4") == 0)
> +   send_udp = 1;
> +   else if (strcmp(proto, "udp6") == 0)
> +   send_udp6 = 1;
> break;
> }
> f->f_file = -1;
>

@OK


? Will it goes into base this time ?

tl;dr

_Patch_

--
|Index: usr.sbin/syslogd/syslogd.c
|===
|RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
|retrieving revision 1.262
|diff -u -p -r1.262 syslogd.c
|--- usr.sbin/syslogd/syslogd.c  5 Jul 2019 13:23:27 -   1.262
|+++ usr.sbin/syslogd/syslogd.c  9 Feb 2020 20:25:20 -
--
Patching file usr.sbin/syslogd/syslogd.c using Plan A...
Hunk #1 succeeded at 853.
Hunk #2 succeeded at 2402.
Hunk #3 succeeded at 2495.
Hunk #4 succeeded at 2758.

_Install run debug with @totalcrappy _

logline: pri 053, flags 0x4, from current, msg syslogd[33975]: bad hostname
"@totalcrappy"
[..]
Loggi

Correcty reloading unresolved host in syslogd @Conf lines

[sven falempin]

This was looked at before.
Did not get through.

--- /usr/src/usr.sbin/syslogd/syslogd.c Wed May 13 19:17:17 2020
+++ ./syslogd.c Mon Feb 10 16:05:59 2020
@@ -2416,6 +2416,7 @@
s = 0;
strlcpy(progblock, "*", sizeof(progblock));
strlcpy(hostblock, "*", sizeof(hostblock));
+   send_udp = send_udp6 = 0;
while (getline(, , cf) != -1) {
/*
 * check for end-of-section, comments, strip off trailing
@@ -2755,6 +2756,9 @@
sizeof(f->f_un.f_forw.f_addr)) != 0) {
log_warnx("bad hostname \"%s\"",
f->f_un.f_forw.f_loghost);
+   /* DNS lookup may work after SIGHUP, keep sockets */
+   if (strncmp(proto, "udp", 3) == 0)
+   send_udp = send_udp6 = 1;
break;
}
f->f_file = -1;

It helps with @ domain in conf.

As explain a Failed DNS request at boot can work later.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

On Fri, May 15, 2020 at 11:17 AM Stefan Sperling  wrote:

> On Fri, May 15, 2020 at 11:11:44AM -0400, sven falempin wrote:
> > Index: if_iwx.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
> > retrieving revision 1.11
> > diff -u -p -r1.11 if_iwx.c
> > --- if_iwx.c29 Apr 2020 13:13:30 -  1.11
> > +++ if_iwx.c15 May 2020 15:08:45 -
> > @@ -3222,6 +3222,9 @@ iwx_run_init_mvm_ucode(struct iwx_softc
> >  * Send init config command to mark that we are sending NVM
> >  * access commands
> >  */
> > +   printf("%s: DELAYING\n", DEVNAME(sc));
> > +   DELAY(5000);
> > +
> > err = iwx_send_cmd_pdu(sc, IWX_WIDE_ID(IWX_SYSTEM_GROUP,
> > IWX_INIT_EXTENDED_CFG_CMD), 0, sizeof(init_cfg), _cfg);
> > if (err)
> >
> > Gave
> >
> > iwx0: DELAYING
> > iwx0: dumping device error log
> > iwx0: Start Error Log Dump:
> > iwx0: Status: 0x1, count: 6
> > iwx0: 0x0071 | NMI_INTERRUPT_UMAC_FATAL
> > iwx0: 0020A2F0 | trm_hw_status0
> > iwx0:  | trm_hw_status1
> > iwx0: 004FC308 | branchlink2
> > iwx0: 00016E5A | interruptlink1
> > iwx0: 00016E5A | interruptlink2
> > iwx0: 004F9F62 | data1
> > iwx0: 1000 | data2
> > iwx0: F008 | data3
> > iwx0:  | beacon time
> > iwx0: 000115E1 | tsf low
> > iwx0:  | tsf hi
> > iwx0:  | time gp1
> > iwx0: 000115E2 | time gp2
> > iwx0: 0001 | uCode revision type
> > iwx0: 002E | uCode version major
> > iwx0: 177B3E46 | uCode version minor
> > iwx0: 0340 | hw version
> > iwx0: 18889000 | board version
> > iwx0: 800AFD0C | hcmd
> > iwx0: 2002 | isr0
> > iwx0:  | isr1
> > iwx0: 18F2 | isr2
> > iwx0: 00CC | isr3
> > iwx0:  | isr4
> > iwx0:  | last cmd Id
> > iwx0: 004F9F62 | wait_event
> > iwx0:  | l2p_control
> > iwx0: 0020 | l2p_duration
> > iwx0:  | l2p_mhvalid
> > iwx0:  | l2p_addr_match
> > iwx0: 0009 | lmpm_pmg_sel
> > iwx0: 19071335 | timestamp
> > iwx0: 0828 | flow_handler
> > iwx0: Start UMAC Error Log Dump:
> > iwx0: Status: 0x1, count: 7
> > iwx0: 0x201010A3 | ADVANCED_SYSASSERT
> > iwx0: 0x | umac branchlink1
> > iwx0: 0xC008B1C0 | umac branchlink2
> > iwx0: 0xC0084E04 | umac interruptlink1
> > iwx0: 0x | umac interruptlink2
> > iwx0: 0x0002 | umac data1
> > iwx0: 0x0001 | umac data2
> > iwx0: 0xDEADBEEF | umac data3
> > iwx0: 0x002E | umac major
> > iwx0: 0x177B3E46 | umac minor
> > iwx0: 0x000115D2 | frame pointer
> > iwx0: 0xC0886C6C | stack pointer
> > iwx0: 0x00050C00 | last host cmd
> > iwx0: 0x | isr status reg
> > driver status:
> >   tx ring  0: qid=0  cur=6   queued=0
> >   tx ring  1: qid=1  cur=0   queued=0
> >   tx ring  2: qid=2  cur=0   queued=0
> >   tx ring  3: qid=3  cur=0   queued=0
> >   tx ring  4: qid=4  cur=0   queued=0
> >   tx ring  5: qid=5  cur=0   queued=0
> >   tx ring  6: qid=6  cur=0   queued=0
> >   tx ring  7: qid=7  cur=0   queued=0
> >   tx ring  8: qid=8  cur=0   queued=0
> >   tx ring  9: qid=9  cur=0   queued=0
> >   tx ring 10: qid=10 cur=0   queued=0
> >   tx ring 11: qid=11 cur=0   queued=0
> >   tx ring 12: qid=12 cur=0   queued=0
> >   tx ring 13: qid=13 cur=0   queued=0
> >   tx ring 14: qid=14 cur=0   queued=0
> >   tx ring 15: qid=15 cur=0   queued=0
> >   tx ring 16: qid=16 cur=0   queued=0
> >   tx ring 17: qid=17 cur=0   queued=0
> >   tx ring 18: qid=18 cur=0   queued=0
> >   tx ring 19: qid=19 cur=0   queued=0
> >   tx ring 20: qid=20 cur=0   queued=0
> >   tx ring 21: qid=21 cur=0   queued=0
> >   tx ring 22: qid=22 cur=0   queued=0
> >   tx ring 23: qid=23 cur=0   queued=0
> >   tx ring 24: qid=24 cur=0   queued=0
> >   tx ring 25: qid=25 cur=0   queued=0
> >   tx ring 26: qid=26 cur=0   queued=0
> >   tx ring 27: qid=27 cur=0   queued=0
> >   tx ring 28: qid=28 cur=0   queued=0
> >   tx ring 29: qid=29 cur=0   queued=0
> >   tx ring 30: qid=30 cur=0   queued=0
> >   rx ring: cur=265
> >   802.11 state INIT
> > iwx0: fatal firmware error
> >
> > I think the delay must be somewhere after.
>
> Ouch. Yes, looks like that's a bad spot.
>
> Though it is an interesting observation that waiting there for a long time
> causes another problem.
>
> > I 

Re: iwx: fix phy context command

[sven falempin]

>
> # patch -p0 -l < ./patch.diff
>>
> --
> |-- sys/dev/pci/if_iwx.c
> |+++ sys/dev/pci/if_iwx.c
> --
> Patching file sys/dev/pci/if_iwx.c using Plan A...
> Hunk #1 succeeded at 343.
> Hunk #2 succeeded at 3771.
> Hunk #3 succeeded at 3810.
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> --
> |blob - bf3209c2d3bb508f36dff179ab3e7cf5f45725dc
> |blob + 210e2e89a61c004c04afe87cc829ecc2d37cfcd3
> |--- sys/dev/pci/if_iwxreg.h
> |+++ sys/dev/pci/if_iwxreg.h
> --
> Patching file sys/dev/pci/if_iwxreg.h using Plan A...
> Hunk #1 succeeded at 2794.
> Hunk #2 succeeded at 2815.
> done
>
> It worked here
>
> iwx0: hw rev 0x340, fw ver 46.393952838.0, address f8:e4:e3:23:3c:46
>
> without the Debug IWX_DEBUG, will reboot a few time more to be sure
>
> --
> --
>

Because time is relative or something

# cat /etc/rc.local
D=$(date)

if ifconfig iwx0 | grep -q 'lladdr 00:00:00:00:00:00'
then
echo FAILED $D >> /var/db/iwTest
dmesg | grep 'iwx0:' > /var/db/iwFail/$D
else
echo OK $D >> /var/db/iwTest
ifconfig iwx0 scan >> /var/db/iwScans/$D
fi

test `wc -l < /var/db/iwTest` -lt 50 && reboot

# cat /var/db/iwTest
OK Fri May 15 13:37:31 EDT 2020
OK Fri May 15 13:38:10 EDT 2020
OK Fri May 15 13:38:49 EDT 2020
OK Fri May 15 13:39:28 EDT 2020
OK Fri May 15 13:40:07 EDT 2020
FAILED Fri May 15 13:40:50 EDT 2020
OK Fri May 15 13:41:29 EDT 2020
FAILED Fri May 15 13:42:12 EDT 2020
OK Fri May 15 13:42:51 EDT 2020
OK Fri May 15 13:43:30 EDT 2020
OK Fri May 15 13:44:09 EDT 2020
OK Fri May 15 13:44:50 EDT 2020
OK Fri May 15 13:45:29 EDT 2020
OK Fri May 15 13:46:08 EDT 2020
OK Fri May 15 13:46:47 EDT 2020
FAILED Fri May 15 13:47:30 EDT 2020
OK Fri May 15 13:48:09 EDT 2020
OK Fri May 15 13:48:48 EDT 2020
OK Fri May 15 13:49:27 EDT 2020
FAILED Fri May 15 13:50:11 EDT 2020
FAILED Fri May 15 13:50:55 EDT 2020
FAILED Fri May 15 13:51:38 EDT 2020
OK Fri May 15 13:52:17 EDT 2020
FAILED Fri May 15 13:53:02 EDT 2020
OK Fri May 15 13:53:42 EDT 2020
FAILED Fri May 15 13:54:24 EDT 2020
FAILED Fri May 15 13:55:07 EDT 2020
OK Fri May 15 13:55:46 EDT 2020
OK Fri May 15 13:56:25 EDT 2020
FAILED Fri May 15 13:57:08 EDT 2020
OK Fri May 15 13:57:50 EDT 2020
OK Fri May 15 13:58:30 EDT 2020
OK Fri May 15 13:59:09 EDT 2020
OK Fri May 15 13:59:48 EDT 2020
FAILED Fri May 15 14:00:31 EDT 2020
OK Fri May 15 14:01:10 EDT 2020
OK Fri May 15 14:02:05 EDT 2020
OK Fri May 15 14:02:45 EDT 2020
FAILED Fri May 15 14:03:28 EDT 2020
OK Fri May 15 14:04:09 EDT 2020
OK Fri May 15 14:04:48 EDT 2020
OK Fri May 15 14:05:27 EDT 2020
OK Fri May 15 14:06:06 EDT 2020
OK Fri May 15 14:06:45 EDT 2020
FAILED Fri May 15 14:07:28 EDT 2020
OK Fri May 15 14:08:08 EDT 2020
OK Fri May 15 14:08:47 EDT 2020
OK Fri May 15 14:09:26 EDT 2020
FAILED Fri May 15 14:10:09 EDT 2020

The greped dmesg are in the attached tar

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do


iwDmesg.tar.gz
Description: GNU Zip compressed data

Re: iwx: fix phy context command

[sven falempin]

On Fri, May 15, 2020 at 9:29 AM Stefan Sperling  wrote:

> iwx(4) firmware understands two different variants of the "PHY_CONTEXT"
> command. Both variants are documented with the same command API version
> number, but they use different sizes for an embedded struct that contains
> information about channels.
>
> Which variant to use depends on whether the firmware advertises support for
> the "ULTRA_HB_CHANNELS" feature (we don't use this feature; it's about 6
> GHz
> channels; but if the command we send has the wrong size the firmware will
> reject the command).
>
> The code I wrote to handle both of these cases has a bug in case this
> feature is *not* supported. Our current iwx(4) firmware supports the
> feature, so there is no actual problem for now.
>
> I have considered removing the command variant which is currently not
> needed.
> However, additional devices may be added to this driver at some point.
> And some of those are kind of hybrids between the 9k and the ax200 device
> generations. I do not know which variant those devices will need. So this
> diff fixes the bug in the non-UHB code path, in case it will be needed.
> We can always remove this later.
>
> ok?
>
>  M  sys/dev/pci/if_iwx.c
>  M  sys/dev/pci/if_iwxreg.h
>
> diff f896dbcaba91a37b23dc6cbeb42839fba3e329be
> 24bd56723f1f029278b7c9cc71d56349db3c5950
> blob - 64c3641a2d0d07a9d899c0b7ccdbe46d46e17b96
> blob + d01db87880cc583922d1610de8319e491e7f148c
> --- sys/dev/pci/if_iwx.c
> +++ sys/dev/pci/if_iwx.c
> @@ -343,10 +343,8 @@ void   iwx_rx_tx_cmd(struct iwx_softc *, struct
> iwx_rx_p
>  void   iwx_rx_bmiss(struct iwx_softc *, struct iwx_rx_packet *,
> struct iwx_rx_data *);
>  intiwx_binding_cmd(struct iwx_softc *, struct iwx_node *, uint32_t);
> -void   iwx_phy_ctxt_cmd_hdr(struct iwx_softc *, struct iwx_phy_ctxt *,
> -   struct iwx_phy_context_cmd *, uint32_t, uint32_t);
> -void   iwx_phy_ctxt_cmd_data(struct iwx_softc *, struct
> iwx_phy_context_cmd *,
> -   struct ieee80211_channel *, uint8_t, uint8_t);
> +intiwx_phy_ctxt_cmd_uhb(struct iwx_softc *, struct iwx_phy_ctxt *,
> uint8_t,
> +   uint8_t, uint32_t, uint32_t);
>  intiwx_phy_ctxt_cmd(struct iwx_softc *, struct iwx_phy_ctxt *,
> uint8_t,
> uint8_t, uint32_t, uint32_t);
>  intiwx_send_cmd(struct iwx_softc *, struct iwx_host_cmd *);
> @@ -3773,52 +3771,38 @@ iwx_binding_cmd(struct iwx_softc *sc, struct
> iwx_node
> return err;
>  }
>
> -void
> -iwx_phy_ctxt_cmd_hdr(struct iwx_softc *sc, struct iwx_phy_ctxt *ctxt,
> -struct iwx_phy_context_cmd *cmd, uint32_t action, uint32_t apply_time)
> +int
> +iwx_phy_ctxt_cmd_uhb(struct iwx_softc *sc, struct iwx_phy_ctxt *ctxt,
> +uint8_t chains_static, uint8_t chains_dynamic, uint32_t action,
> +uint32_t apply_time)
>  {
> -   memset(cmd, 0, sizeof(struct iwx_phy_context_cmd));
> +   struct ieee80211com *ic = >sc_ic;
> +   struct iwx_phy_context_cmd_uhb cmd;
> +   uint8_t active_cnt, idle_cnt;
> +   struct ieee80211_channel *chan = ctxt->channel;
>
> -   cmd->id_and_color = htole32(IWX_FW_CMD_ID_AND_COLOR(ctxt->id,
> +   memset(, 0, sizeof(cmd));
> +   cmd.id_and_color = htole32(IWX_FW_CMD_ID_AND_COLOR(ctxt->id,
> ctxt->color));
> -   cmd->action = htole32(action);
> -   cmd->apply_time = htole32(apply_time);
> -}
> +   cmd.action = htole32(action);
> +   cmd.apply_time = htole32(apply_time);
>
> -void
> -iwx_phy_ctxt_cmd_data(struct iwx_softc *sc, struct iwx_phy_context_cmd
> *cmd,
> -struct ieee80211_channel *chan, uint8_t chains_static,
> -uint8_t chains_dynamic)
> -{
> -   struct ieee80211com *ic = >sc_ic;
> -   uint8_t active_cnt, idle_cnt;
> +   cmd.ci.band = IEEE80211_IS_CHAN_2GHZ(chan) ?
> +   IWX_PHY_BAND_24 : IWX_PHY_BAND_5;
> +   cmd.ci.channel = htole32(ieee80211_chan2ieee(ic, chan));
> +   cmd.ci.width = IWX_PHY_VHT_CHANNEL_MODE20;
> +   cmd.ci.ctrl_pos = IWX_PHY_VHT_CTRL_POS_1_BELOW;
>
> -   if (isset(sc->sc_enabled_capa,
> IWX_UCODE_TLV_CAPA_ULTRA_HB_CHANNELS)) {
> -   cmd->ci.band = IEEE80211_IS_CHAN_2GHZ(chan) ?
> -   IWX_PHY_BAND_24 : IWX_PHY_BAND_5;
> -   cmd->ci.channel = htole32(ieee80211_chan2ieee(ic, chan));
> -   cmd->ci.width = IWX_PHY_VHT_CHANNEL_MODE20;
> -   cmd->ci.ctrl_pos = IWX_PHY_VHT_CTRL_POS_1_BELOW;
> -   } else {
> -   struct iwx_fw_channel_info_v1 *ci_v1;
> -   ci_v1 = (struct iwx_fw_channel_info_v1 *)>ci;
> -   ci_v1->band = IEEE80211_IS_CHAN_2GHZ(chan) ?
> -   IWX_PHY_BAND_24 : IWX_PHY_BAND_5;
> -   ci_v1->channel = ieee80211_chan2ieee(ic, chan);
> -   ci_v1->width = IWX_PHY_VHT_CHANNEL_MODE20;
> -   ci_v1->ctrl_pos = IWX_PHY_VHT_CTRL_POS_1_BELOW;
> -   }
> -   /* Set rx the chains */
> idle_cnt = chains_static;
> active_cnt = 

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

On Thu, May 14, 2020 at 5:55 AM Stefan Sperling  wrote:

> On Wed, May 13, 2020 at 07:55:02PM -0400, sven falempin wrote:
> > 'good news'
> >
> > I build a custom kernel with the DEBUG flag for the driver
>
> > I 'works' ,
>
> This means that the driver is doing something too fast on your hardware,
> and some miscommunication happens with the card as a result.
>
> One way to work around this is to add DELAY calls. It is not the ideal
> solution but would be a good first step to get the card working.
>
> Can you disable debugging again and try the patch below instead?
> If the problem re-appears, try to increase the amount of delay (up to 5000
> seems reasonable). If increasing the DELAY value does not help, try to move
> the DELAY call further down until it works.
>
> The DELAY may even need to be moved into the while loop inside
> iwx_nvm_init().
> But please try using the DELAY outside of a loop first.
>
> Finding the right spot might take some time. Welcome to driver development
> :)
>
> If you cannot find a spot for the DELAY that makes this work, then we will
> have to wait for someone else who is seeing the same problem and tries
> harder.
>
> diff 4a0fa473f5ea308b63ffd39645f73b2195291973 /usr/src
> blob - 64c3641a2d0d07a9d899c0b7ccdbe46d46e17b96
> file + sys/dev/pci/if_iwx.c
> --- sys/dev/pci/if_iwx.c
> +++ sys/dev/pci/if_iwx.c
> @@ -3222,6 +3222,7 @@ iwx_run_init_mvm_ucode(struct iwx_softc *sc, int
> readn
>  * Send init config command to mark that we are sending NVM
>  * access commands
>  */
> +   DELAY(1000);
> err = iwx_send_cmd_pdu(sc, IWX_WIDE_ID(IWX_SYSTEM_GROUP,
> IWX_INIT_EXTENDED_CFG_CMD), 0, sizeof(init_cfg), _cfg);
> if (err)
>


Index: if_iwx.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwx.c,v
retrieving revision 1.11
diff -u -p -r1.11 if_iwx.c
--- if_iwx.c29 Apr 2020 13:13:30 -  1.11
+++ if_iwx.c15 May 2020 15:08:45 -
@@ -3222,6 +3222,9 @@ iwx_run_init_mvm_ucode(struct iwx_softc
 * Send init config command to mark that we are sending NVM
 * access commands
 */
+   printf("%s: DELAYING\n", DEVNAME(sc));
+   DELAY(5000);
+
err = iwx_send_cmd_pdu(sc, IWX_WIDE_ID(IWX_SYSTEM_GROUP,
IWX_INIT_EXTENDED_CFG_CMD), 0, sizeof(init_cfg), _cfg);
if (err)

Gave

iwx0: DELAYING
iwx0: dumping device error log
iwx0: Start Error Log Dump:
iwx0: Status: 0x1, count: 6
iwx0: 0x0071 | NMI_INTERRUPT_UMAC_FATAL
iwx0: 0020A2F0 | trm_hw_status0
iwx0:  | trm_hw_status1
iwx0: 004FC308 | branchlink2
iwx0: 00016E5A | interruptlink1
iwx0: 00016E5A | interruptlink2
iwx0: 004F9F62 | data1
iwx0: 1000 | data2
iwx0: F008 | data3
iwx0:  | beacon time
iwx0: 000115E1 | tsf low
iwx0:  | tsf hi
iwx0:  | time gp1
iwx0: 000115E2 | time gp2
iwx0: 0001 | uCode revision type
iwx0: 002E | uCode version major
iwx0: 177B3E46 | uCode version minor
iwx0: 0340 | hw version
iwx0: 18889000 | board version
iwx0: 800AFD0C | hcmd
iwx0: 2002 | isr0
iwx0:  | isr1
iwx0: 18F2 | isr2
iwx0: 00CC | isr3
iwx0:  | isr4
iwx0:  | last cmd Id
iwx0: 004F9F62 | wait_event
iwx0:  | l2p_control
iwx0: 0020 | l2p_duration
iwx0:  | l2p_mhvalid
iwx0:  | l2p_addr_match
iwx0: 0009 | lmpm_pmg_sel
iwx0: 19071335 | timestamp
iwx0: 0828 | flow_handler
iwx0: Start UMAC Error Log Dump:
iwx0: Status: 0x1, count: 7
iwx0: 0x201010A3 | ADVANCED_SYSASSERT
iwx0: 0x | umac branchlink1
iwx0: 0xC008B1C0 | umac branchlink2
iwx0: 0xC0084E04 | umac interruptlink1
iwx0: 0x | umac interruptlink2
iwx0: 0x0002 | umac data1
iwx0: 0x0001 | umac data2
iwx0: 0xDEADBEEF | umac data3
iwx0: 0x002E | umac major
iwx0: 0x177B3E46 | umac minor
iwx0: 0x000115D2 | frame pointer
iwx0: 0xC0886C6C | stack pointer
iwx0: 0x00050C00 | last host cmd
iwx0: 0x | isr status reg
driver status:
  tx ring  0: qid=0  cur=6   queued=0
  tx ring  1: qid=1  cur=0   queued=0
  tx ring  2: qid=2  cur=0   queued=0
  tx ring  3: qid=3  cur=0   queued=0
  tx ring  4: qid=4  cur=0   queued=0
  tx ring  5: qid=5  cur=0   queued=0
  tx ring  6: qid=6  cur=0   queued=0
  tx ring  7: qid=7  cur=0   queued=0
  tx ring  8: qid=8  cur=0   queued=0
  tx ring  9: qid=9  cur=0   queued=0
  tx ring 10: qid=10 cur=0   queued=0
  tx ring 11: qid=11 cur=0   queued=0
  tx ring 12: qid=12 cur=0   queued=0
  tx ring 13: qid=13 cur=0   queued=0
  tx ring 14: qid=14 cur=0   queued=0
  tx ring 15: qid=15 cur=0   queued=0
  tx ring 16: qid=16 cur=0   queued=0
  tx ring 17: qid=17 cur=0   queued=0
  tx ring 18: qid=18 cur=0   queued=0
  tx ring 19: qid=19 cur=0   queued=0
  tx ring 20: qid=20 cur=0   queued=0
  tx ring 21: qid=21 cur

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

'good news'

I build a custom kernel with the DEBUG flag for the driver

ugen0 at uhub3 port 3 "Intel product 0x0029" rev 2.01/0.01 addr 2
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x203 done
iwx0: unexpected firmware response to command 0x203
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_cmd_done: command 0x88 done
iwx_send_cmd: sending command 0x88
iwx_cmd_done: command 0x88 done
iwx_send_cmd: sending command 0x88
iwx_cmd_done: command 0x88 done
iwx_send_cmd: sending command 0x88
iwx_cmd_done: command 0x88 done
iwx_send_cmd: sending command 0x88
iwx_cmd_done: command 0x88 done
iwx_send_cmd: sending command 0x88
iwx_cmd_done: command 0x88 done
iwx_send_cmd: sending command 0x88
iwx_cmd_done: command 0x88 done
iwx_send_cmd: sending command 0x88
iwx_cmd_done: command 0x88 done
iwx_send_cmd: sending command 0xc00
iwx_cmd_done: command 0xc00 done
iwx0: hw rev 0x340, fw ver 46.393952838.0, address f8:e4:e3:23:3c:46

I 'works' ,

shall i log more around like the reponse  here ?

iwx_cmd_done: command 0x203 done
iwx0: unexpected firmware response to command 0x203

Scanning worked !

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

On Wed, May 13, 2020 at 2:24 PM Stuart Henderson  wrote:
>
> On 2020/05/13 13:46, sven falempin wrote:
> > *Please*
> > advise how to squeeze more information to thwart that problem.
>
> If I had a card using a newly developed driver that was doing that,
> I would remove the card, offer to send it to somebody working on the
> driver if they want it, and replace it with an alternative..
>

It is possible to send the m2 wifi card out there to a Dev.
I can also recompile custom kernel with broad guidance
to dumping `things` .

As it is always good to have some test outside the dev bench.
I will check some #if DEBUG in the driver see if I can squeeze out
more information.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

>
> OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 7975399424 (7605MB)
> avail mem = 7721070592 (7363MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebee0 (48 entries)
> bios0: vendor American Megatrends Inc. version "F2" date 06/20/2014
> bios0: Gigabyte Technology Co., Ltd. AM1M-S2H
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT
> acpi0: wakeup devices BR11(S4) GPP0(S4) GPP1(S4) GBE_(S4) GPP2(S4) GPP3(S4) 
> SBAZ(S4) PS2K(S3) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) 
> XHC0(S4) PWRB(S3)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.43 MHz, 16-00-01
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.16 MHz, 16-00-01
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.16 MHz, 16-00-01
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.16 MHz, 16-00-01
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
> 16-way L2 cache
> cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 5 pa 0xfec0, version 21, 24 pins
> ioapic1 at mainbus0: apid 6 pa 0xfec01000, version 21, 32 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318180 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (BR11)
> acpiprt2 at acpi0: bus 1 (GPP0)
> acpiprt3 at acpi0: bus 2 (GPP1)
> acpiprt4 at acpi0: bus -1 (GPP2)
> acpiprt5 at acpi0: bus -1 (GPP3)
> acpicpu0 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS
> acpicpu1 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS
> acpicpu2 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS
> acpicpu3 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS
> acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
> acpicmos0 at acpi0
> acpibtn0 at acpi0: PWRB
> cpu0: 2046 MHz: speeds: 2050 1850 1650 1400 1200 1000 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD 16h Host" rev 0x00
> radeondrm0 at pci0 dev 1 function 0 "ATI Kabini" rev 0x00
> drm0 at radeondrm0
> radeondrm0: msi
> azalia0 at pci0 dev 1 

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

On Mon, May 11, 2020 at 5:52 AM Stefan Sperling  wrote:

> On Sun, May 10, 2020 at 04:17:46PM -0400, sven falempin wrote:
> > On Sun, May 10, 2020 at 4:51 AM Stefan Sperling  wrote:
> >
> > > On Sat, May 09, 2020 at 04:23:08PM -0400, sven falempin wrote:
> > > > "no config, interface is down", Did not do anything special,
> > > > upgrade => Plug card => boot => crash
> > >
> > > > I tested with the intel firmware it does the same.
> > >
> > > I'm sorry, but there is really not enough information in your messages
> > > that would allow me to do anything other than just trying to somehow
> > > reproduce this problem by chance.
> > >
> >
> > I understand.
> >
> > there is nothing I did that is outside what I tell,
> > the problem is constant,
> > unavoidable
> > and requires 0 config
> > nor any command to enter.
>
> Yes, I believe what you are saying.
>
> The problem is that this error is not happening to me, and to diagnose it
> I need to see this same error happen on a machine I have in front of me.
> Once we reach that point, I can silently work on it until I find a fix.
> But before then, I cannot do anything. In order to try to replicate your
> setup as closely as possible, I need to know what your setup looks like.
>
> So, for example, knowing what hardware you have in front of you would be
> a good first step. But your report lacks a dmesg.
>
> Please follow the guidance given on https://www.openbsd.org/report.html
> Any bit of information that is requested there, if you can tell us about
> it,
> then please include it in your report. It will save us time in the long
> term.
>

I changed the PCI slot used , verify the USB power,
removed the other PCI card ( cleaner dmesg ).

I also have two m2 modules , both of them do the same :-(

Dmesg

OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7975399424 (7605MB)
avail mem = 7721070592 (7363MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebee0 (48 entries)
bios0: vendor American Megatrends Inc. version "F2" date 06/20/2014
bios0: Gigabyte Technology Co., Ltd. AM1M-S2H
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT
acpi0: wakeup devices BR11(S4) GPP0(S4) GPP1(S4) GBE_(S4) GPP2(S4) GPP3(S4)
SBAZ(S4) PS2K(S3) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4)
XHC0(S4) PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.43 MHz, 16-00-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.16 MHz, 16-00-01
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.16 MHz, 16-00-01
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries f

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

On Sun, May 10, 2020 at 4:51 AM Stefan Sperling  wrote:

> On Sat, May 09, 2020 at 04:23:08PM -0400, sven falempin wrote:
> > "no config, interface is down", Did not do anything special,
> > upgrade => Plug card => boot => crash
>
> > I tested with the intel firmware it does the same.
>
> I'm sorry, but there is really not enough information in your messages
> that would allow me to do anything other than just trying to somehow
> reproduce this problem by chance.
>

I understand.

there is nothing I did that is outside what I tell,
the problem is constant,
unavoidable
and requires 0 config
nor any command to enter.


-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: 6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

On Sat, May 9, 2020 at 4:14 AM Stefan Sperling  wrote:

> On Fri, May 08, 2020 at 11:51:50AM -0400, sven falempin wrote:
> > I upgraded to 6.7 - beta a tftp server i use
> >
> > Not much to report as the device is basic but i wanted to test some wifi
> on
> > it.
> >
> > iwx0 at pci8 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix
> >
> > The firmware crashes at start,
>
> It looks like a failure of the NVM_ACCESS command:
>
> > iwx0: 0x00050088 | last host cmd
>
> #define IWX_NVM_ACCESS_CMD  0x88
>
> > no config down:
>
> What does "no config down" mean?
>
> If you could provide an exact sequence of steps anyone without prior
> knowledge
> could perform in order to repeat this problem, then I would take a look.
> Please don't assume that I already knew. I have never seen this error.
>

"no config, interface is down", Did not do anything special,
upgrade => Plug card => boot => crash

I tested with the intel firmware it does the same.

Full Dmesg :

OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7975399424 (7605MB)
avail mem = 7721066496 (7363MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xebee0 (48 entries)
bios0: vendor American Megatrends Inc. version "F2" date 06/20/2014
bios0: Gigabyte Technology Co., Ltd. AM1M-S2H
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT
acpi0: wakeup devices BR11(S4) GPP0(S4) GPP1(S4) GBE_(S4) GPP2(S4) GPP3(S4)
SBAZ(S4) PS2K(S3) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4)
XHC0(S4) PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.44 MHz, 16-00-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.17 MHz, 16-00-01
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.17 MHz, 16-00-01
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Athlon(tm) 5350 APU with Radeon(tm) R3, 2046.17 MHz, 16-00-01
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 5 pa 0xfec0, v

6.7 snaps upgrade went fine - Intel ax200ngw not so much

[sven falempin]

I upgraded to 6.7 - beta a tftp server i use

Not much to report as the device is basic but i wanted to test some wifi on
it.

iwx0 at pci8 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix

The firmware crashes at start, no config down:

iwx0: dumping device error log
iwx0: Start Error Log Dump:
iwx0: Status: 0x1, count: 6
iwx0: 0x0071 | NMI_INTERRUPT_UMAC_FATAL
iwx0: 002022F0 | trm_hw_status0
iwx0:  | trm_hw_status1
iwx0: 004FC308 | branchlink2
iwx0: 00016E5A | interruptlink1
iwx0: 00016E5A | interruptlink2
iwx0: 004F9F62 | data1
iwx0: 1000 | data2
iwx0: F008 | data3
iwx0:  | beacon time
iwx0: 00011B6F | tsf low
iwx0:  | tsf hi
iwx0:  | time gp1
iwx0: 00011B6F | time gp2
iwx0: 0001 | uCode revision type
iwx0: 002E | uCode version major
iwx0: 177B3E46 | uCode version minor
iwx0: 0340 | hw version
iwx0: 00889000 | board version
iwx0: 800AFD0C | hcmd
iwx0: 0002 | isr0
iwx0:  | isr1
iwx0: 18F2 | isr2
iwx0: 04CC | isr3
iwx0:  | isr4
iwx0:  | last cmd Id
iwx0: 004F9F62 | wait_event
iwx0:  | l2p_control
iwx0: 0020 | l2p_duration
iwx0:  | l2p_mhvalid
iwx0:  | l2p_addr_match
iwx0: 0009 | lmpm_pmg_sel
iwx0: 19071335 | timestamp
iwx0: 0024 | flow_handler
iwx0: Start UMAC Error Log Dump:
iwx0: Status: 0x1, count: 7
iwx0: 0x201010A3 | ADVANCED_SYSASSERT
iwx0: 0x | umac branchlink1
iwx0: 0xC008B1C0 | umac branchlink2
iwx0: 0xC0084E04 | umac interruptlink1
iwx0: 0x | umac interruptlink2
iwx0: 0x0002 | umac data1
iwx0: 0x0001 | umac data2
iwx0: 0xDEADBEEF | umac data3
iwx0: 0x002E | umac major
iwx0: 0x177B3E46 | umac minor
iwx0: 0x00011B60 | frame pointer
iwx0: 0xC0886C6C | stack pointer
iwx0: 0x00050088 | last host cmd
iwx0: 0x | isr status reg
driver status:
  tx ring  0: qid=0  cur=5   queued=0
  tx ring  1: qid=1  cur=0   queued=0
  tx ring  2: qid=2  cur=0   queued=0
  tx ring  3: qid=3  cur=0   queued=0
  tx ring  4: qid=4  cur=0   queued=0
  tx ring  5: qid=5  cur=0   queued=0
  tx ring  6: qid=6  cur=0   queued=0
  tx ring  7: qid=7  cur=0   queued=0
  tx ring  8: qid=8  cur=0   queued=0
  tx ring  9: qid=9  cur=0   queued=0
  tx ring 10: qid=10 cur=0   queued=0
  tx ring 11: qid=11 cur=0   queued=0
  tx ring 12: qid=12 cur=0   queued=0
  tx ring 13: qid=13 cur=0   queued=0
  tx ring 14: qid=14 cur=0   queued=0
  tx ring 15: qid=15 cur=0   queued=0
  tx ring 16: qid=16 cur=0   queued=0
  tx ring 17: qid=17 cur=0   queued=0
  tx ring 18: qid=18 cur=0   queued=0
  tx ring 19: qid=19 cur=0   queued=0
  tx ring 20: qid=20 cur=0   queued=0
  tx ring 21: qid=21 cur=0   queued=0
  tx ring 22: qid=22 cur=0   queued=0
  tx ring 23: qid=23 cur=0   queued=0
  tx ring 24: qid=24 cur=0   queued=0
  tx ring 25: qid=25 cur=0   queued=0
  tx ring 26: qid=26 cur=0   queued=0
  tx ring 27: qid=27 cur=0   queued=0
  tx ring 28: qid=28 cur=0   queued=0
  tx ring 29: qid=29 cur=0   queued=0
  tx ring 30: qid=30 cur=0   queued=0
  rx ring: cur=263
  802.11 state INIT
iwx0: fatal firmware error

ifconfig  iwx0 up creates the crashes.

Could it be the beta did not load the right firmware ? or is there come MAC
address restriction ?

# strings /etc/firmware/iwx-cc-a0-46  | grep rel
release/core43_pv::177b3e46
# md5 /etc/firmware/iwx-cc-a0-46
MD5 (/etc/firmware/iwx-cc-a0-46) = babe453e0bc18ec93768ec6f002d8229

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: syslogd closing all udp is a tiny bit aggressiv

[sven falempin]

On Sun, Feb 9, 2020 at 4:12 PM Alexander Bluhm 
wrote:

> On Thu, Feb 06, 2020 at 05:57:15PM -0500, sven falempin wrote:
> > > Your DNS lookup fails at startup, sockets are closed.
> > > Later at SIGHUP you DNS works again.  Now the sockets are needed.
> > > So do not close them if DNS for udp fails.
>
> I thought again about this problem.  The fix can be more specific.
> - if user requested udp4 or udp6, close the other af socket.
> - after SIGHUP, when DNS works, close the unneeded af socket.
>
> ok?
>
> Index: usr.sbin/syslogd/syslogd.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
> retrieving revision 1.262
> diff -u -p -r1.262 syslogd.c
> --- usr.sbin/syslogd/syslogd.c  5 Jul 2019 13:23:27 -   1.262
> +++ usr.sbin/syslogd/syslogd.c  9 Feb 2020 20:25:20 -
> @@ -853,20 +853,6 @@ main(int argc, char *argv[])
> event_add(ev_udp, NULL);
> if (fd_udp6 != -1)
> event_add(ev_udp6, NULL);
> -   } else {
> -   /*
> -* If generic UDP file descriptors are used neither
> -* for receiving nor for sending, close them.  Then
> -* there is no useless *.514 in netstat.
> -*/
> -   if (fd_udp != -1 && !send_udp) {
> -   close(fd_udp);
> -   fd_udp = -1;
> -   }
> -   if (fd_udp6 != -1 && !send_udp6) {
> -   close(fd_udp6);
> -   fd_udp6 = -1;
> -   }
> }
> for (i = 0; i < nbind; i++)
> if (fd_bind[i] != -1)
> @@ -2416,6 +2402,7 @@ init(void)
> s = 0;
> strlcpy(progblock, "*", sizeof(progblock));
> strlcpy(hostblock, "*", sizeof(hostblock));
> +   send_udp = send_udp6 = 0;
> while (getline(, , cf) != -1) {
> /*
>  * check for end-of-section, comments, strip off trailing
> @@ -2508,6 +2495,22 @@ init(void)
> Initialized = 1;
> dropped_warn(_dropped, "during initialization");
>
> +   if (SecureMode) {
> +   /*
> +* If generic UDP file descriptors are used neither
> +* for receiving nor for sending, close them.  Then
> +* there is no useless *.514 in netstat.
> +*/
> +   if (fd_udp != -1 && !send_udp) {
> +   close(fd_udp);
> +   fd_udp = -1;
> +   }
> +   if (fd_udp6 != -1 && !send_udp6) {
> +   close(fd_udp6);
> +   fd_udp6 = -1;
> +   }
> +   }
> +
> if (Debug) {
> SIMPLEQ_FOREACH(f, , f_next) {
> for (i = 0; i <= LOG_NFACILITIES; i++)
> @@ -2755,6 +2758,13 @@ cfline(char *line, char *progblock, char
> sizeof(f->f_un.f_forw.f_addr)) != 0) {
> log_warnx("bad hostname \"%s\"",
> f->f_un.f_forw.f_loghost);
> +   /* DNS lookup may work after SIGHUP, keep sockets
> */
> +   if (strcmp(proto, "udp") == 0)
> +   send_udp = send_udp6 = 1;
> +   else if (strcmp(proto, "udp4") == 0)
> +   send_udp = 1;
> +   else if (strcmp(proto, "udp6") == 0)
> +   send_udp6 = 1;
> break;
> }
> f->f_file = -1;
>


@ok here

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: syslogd closing all udp is a tiny bit aggressiv

[sven falempin]

On Thu, Feb 6, 2020 at 5:32 PM Alexander Bluhm  wrote:
>
> On Thu, Feb 06, 2020 at 11:46:25AM -0500, sven falempin wrote:
> > If for exemple there s a wrong endpoint in the config file, like
> > local1.warn @badhost
> > and no other the daemon will close  fd_udp.
>
> Your DNS lookup fails at startup, sockets are closed.
>
> > // reload with a badhost in /etc/hosts for the sake of testing
>
> Later at SIGHUP you DNS works again.  Now the sockets are needed.
>
> So do not close them if DNS for udp fails.
> Does this diff fix your setup?
>
> bluhm
>
> Index: usr.sbin/syslogd/syslogd.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
> retrieving revision 1.262
> diff -u -p -r1.262 syslogd.c
> --- usr.sbin/syslogd/syslogd.c  5 Jul 2019 13:23:27 -   1.262
> +++ usr.sbin/syslogd/syslogd.c  6 Feb 2020 21:51:30 -
> @@ -2416,6 +2416,7 @@ init(void)
> s = 0;
> strlcpy(progblock, "*", sizeof(progblock));
> strlcpy(hostblock, "*", sizeof(hostblock));
> +   send_udp = send_udp6 = 0;
> while (getline(, , cf) != -1) {
> /*
>  * check for end-of-section, comments, strip off trailing
> @@ -2755,6 +2756,9 @@ cfline(char *line, char *progblock, char
> sizeof(f->f_un.f_forw.f_addr)) != 0) {
> log_warnx("bad hostname \"%s\"",
> f->f_un.f_forw.f_loghost);
> +   /* DNS lookup may work after SIGHUP, keep sockets */
> +   if (strncmp(proto, "udp", 3) == 0)
> +   send_udp = send_udp6 = 1;
> break;
> }
> f->f_file = -1;

It make sense and it totally works.
@ok

Thank you.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

syslogd closing all udp is a tiny bit aggressiv

[sven falempin]

Hello,

Syslogd is supposed to reload the configuration on HUP, and does it well
but for one case.

If the demon does not have any endpoint it will close the FD opened *at start*

line 587
/*
* If generic UDP file descriptors are used neither
* for receiving nor for sending, close them.  Then
* there is no useless *.514 in netstat.
*/
if (fd_udp != -1 && !send_udp) {
close(fd_udp);
fd_udp = -1;
}

If for exemple there s a wrong endpoint in the config file, like
local1.warn @badhost
and no other the daemon will close  fd_udp.


when reloading the conf, if badhost suddenly resolved.
===
RCS file: /cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.262
diff -u -p -r1.262 syslogd.c
--- syslogd.c   5 Jul 2019 13:23:27 -   1.262
+++ syslogd.c   6 Feb 2020 16:28:34 -
@@ -2762,6 +2762,7 @@ cfline(char *line, char *progblock, char
switch (f->f_un.f_forw.f_addr.ss_family) {
case AF_INET:
send_udp = 1;
+   if ( fd_udp == -1 ) log_warnx("bad
oops cannot reload because new feature");
f->f_file = fd_udp;
break;
case AF_INET6:


send_udp is back to 1 but fd_udp is dead, RIP fd_udp !

logline: pri 053, flags 0x4, from current, msg syslogd[62371]: bad
hostname "@badhost "
// reload with a badhost in /etc/hosts for the sake of testing
logline: pri 053, flags 0x4, from current, msg syslogd[20219]: bad
oops cannot reload because new feature
Logging to FORWUDP @badhost
logline: pri 053, flags 0x4, from current, msg syslogd[62371]: sendto
"@totalcrap": Bad file descriptor


One easy fix would be to not close the FD ... or change the man

if (socket_bind("udp", NULL, "syslog", SecureMode,
_udp, _udp6) == -1)
log_warnx("socket bind * failed");

could be called in init when send_udp is set to 1, but it will crush
the udp6 one

I often have the wrong idea about the right fix, so please tell me !

For example i wonder if the udp socket could be put in the enpoint
struct,and open/close
when the enpoint state is valid/invalid.

Best, and thanks for all the work.

* this is tested on 6.6, with current version of syslogd * using cvs
-q up -Pd -CA as learned *

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: ifconfig: fix maximum SSID length with WPA

[sven falempin]

+1 on max Len , keep \0, use length - 1 for sum.

IMHO.

Happy holidays all.

On Fri, Dec 27, 2019 at 7:39 AM Claudio Jeker 
wrote:

> On Fri, Dec 27, 2019 at 01:12:42PM +0100, Stefan Sperling wrote:
> > If an SSID uses the maximum allowed length, ifconfig overwrites
> > the last byte with \0 when hashing the WPA key.
> > This leads to a wrong WPA key being installed in the kernel:
> >
> > iwm0: SCAN -> AUTH
> > iwm0: sending auth to xx:xx:xx:xx:xx:xx on channel 1 mode 11g
> > iwm0: AUTH -> ASSOC
> > iwm0: sending assoc_req to xx:xx:xx:xx:xx:xx on channel 1 mode 11g
> > iwm0: ASSOC -> RUN
> > iwm0: associated with xx:xx:xx:xx:xx:xx ssid "FRITZ!Box7430
> Internetmanufaktur" channel 1 start MCS 0 short preamble short slot time
> protection enabled HT enabled
> > iwm0: missed beacon threshold set to 30 beacons, beacon interval is 100
> TU
> > iwm0: received msg 1/4 of the 4-way handshake from xx:xx:xx:xx:xx:xx
> > iwm0: sending msg 2/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx
> > iwm0: received msg 1/4 of the 4-way handshake from xx:xx:xx:xx:xx:xx
> > iwm0: sending msg 2/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx
> > iwm0: received msg 1/4 of the 4-way handshake from xx:xx:xx:xx:xx:xx
> > iwm0: sending msg 2/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx
> > iwm0: received msg 1/4 of the 4-way handshake from xx:xx:xx:xx:xx:xx
> > iwm0: sending msg 2/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx
> >
> >
> > The diff below fixes this. Using strlcpy is incorrect for SSIDs.
> > We need to manually track the length instead and treat the SSID
> > as an opaque byte string which might not be NUL-terminated.
> >
> > iwm0: SCAN -> AUTH
> > iwm0: sending auth to xx:xx:xx:xx:xx:xx on channel 1 mode 11g
> > iwm0: AUTH -> ASSOC
> > iwm0: sending assoc_req to xx:xx:xx:xx:xx:xx on channel 1 mode 11g
> > iwm0: ASSOC -> RUN
> > iwm0: associated with xx:xx:xx:xx:xx:xx ssid "FRITZ!Box7430
> Internetmanufaktur" channel 1 start MCS 0 short preamble short slot time
> protection enabled HT enabled
> > iwm0: missed beacon threshold set to 30 beacons, beacon interval is 100
> TU
> > iwm0: received msg 1/4 of the 4-way handshake from xx:xx:xx:xx:xx:xx
> > iwm0: sending msg 2/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx
> > iwm0: received msg 3/4 of the 4-way handshake from xx:xx:xx:xx:xx:xx
> > iwm0: sending msg 4/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx
> >
> > ok?
>
> OK claudio@
>
> > diff 5181eb992cbbf64c135f177197957b0e0b427e21 /usr/src
> > blob - 0ee441181c9f85d12056accc352833cf31c41895
> > file + sbin/ifconfig/ifconfig.c
> > --- sbin/ifconfig/ifconfig.c
> > +++ sbin/ifconfig/ifconfig.c
> > @@ -714,7 +714,9 @@ const struct afswtch {
> >  const struct afswtch *afp;   /*the address family being set or asked
> about*/
> >
> >  char joinname[IEEE80211_NWID_LEN];
> > +size_t joinlen;
> >  char nwidname[IEEE80211_NWID_LEN];
> > +size_t nwidlen;
> >
> >  int ifaliases = 0;
> >  int aflag = 0;
> > @@ -1735,11 +1737,11 @@ setifnwid(const char *val, int d)
> >   struct ieee80211_nwid nwid;
> >   int len;
> >
> > - if (strlen(joinname) != 0) {
> > + if (joinlen != 0) {
> >   errx(1, "nwid and join may not be used at the same time");
> >   }
> >
> > - if (strlen(nwidname) != 0) {
> > + if (nwidlen != 0) {
> >   errx(1, "nwid may not be specified twice");
> >   }
> >
> > @@ -1752,9 +1754,9 @@ setifnwid(const char *val, int d)
> >   if (get_string(val, NULL, nwid.i_nwid, ) == NULL)
> >   return;
> >   }
> > - nwid.i_len = len;
> > + nwidlen = nwid.i_len = len;
> >   (void)strlcpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name));
> > - (void)strlcpy(nwidname, nwid.i_nwid, sizeof(nwidname));
> > + memcpy(nwidname, nwid.i_nwid, len);
> >   ifr.ifr_data = (caddr_t)
> >   if (ioctl(sock, SIOCS80211NWID, (caddr_t)) == -1)
> >   warn("SIOCS80211NWID");
> > @@ -1777,11 +1779,11 @@ setifjoin(const char *val, int d)
> >  {
> >   int len;
> >
> > - if (strlen(nwidname) != 0) {
> > + if (nwidlen != 0) {
> >   errx(1, "nwid and join may not be used at the same time");
> >   }
> >
> > - if (strlen(joinname) != 0) {
> > + if (joinlen != 0) {
> >   errx(1, "join may not be specified twice");
> >   }
> >
> > @@ -1796,9 +1798,9 @@ setifjoin(const char *val, int d)
> >   if (len == 0)
> >   join.i_flags |= IEEE80211_JOIN_ANY;
> >   }
> > - join.i_len = len;
> > + joinlen = join.i_len = len;
> >   (void)strlcpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name));
> > - (void)strlcpy(joinname, join.i_nwid, sizeof(joinname));
> > + memcpy(joinname, join.i_nwid, len);
> >
> >   actions |= A_JOIN;
> >  }
> > @@ -2181,12 +2183,12 @@ setifwpakey(const char *val, int d)
> >   strlcpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name));
> >
> >   /* Use the value specified in 'join' or 'nwid' */
> > - if 

Re: ix(4) need support for X553

[sven falempin]

On Thu, Oct 31, 2019 at 9:49 AM sven falempin 
wrote:

>
>
> On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson 
> wrote:
>
>> On 2019/10/31 08:25, sven falempin wrote:
>> > Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly
>> removed from this
>>
>> The pcidevs update is no longer needed since pcidevs r1.1889.
>>
>> > I may have time to test it against 6.6, see if it is still working
>> since 6.4 (where it was
>> > tested, also a cross test revealed
>> > that plugin'/unplugging SFP maybe non functionnal)
>>
>> I can test an already-wprking fibre ix for new problems at some point,
>> but I don't
>> think I'll have a fibre X553.
>>
>>
> ppb7 at pci0 dev 22 function 0 "Intel C3000 PCIE" rev 0x11
> "Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 0 not configured
> "Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 1 not configured
> ppb8 at pci0 dev 23 function 0 "Intel C3000 PCIE" rev 0x11
> "Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 0 not configured
> "Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 1 not configured
>
> When I look at them , some more involved people was talking about 10gb in
> OpenBSD .
>
> Isn't there some limitations currently or can we expect the X553  to
> perform at 10Gb ?
>
>
>
Hey looks like my diff still works

OpenBSD 6.6-stable (GENERIC.MP) #21: Thu Oct 31 10:53:41 EDT 2019
ix0 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:81
ix1 at pci8 dev 0 function 1 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:82
ix2 at pci9 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:83
ix3 at pci9 dev 0 function 1 "Intel X553 SFP+" rev 0x11: msi, address
00:30:18:0b:4a:84

# ifconfig ix
ix0: flags=8802 mtu 1500
lladdr 00:30:18:0b:4a:81
index 3 priority 0 llprio 3
media: Ethernet autoselect
status: no carrier
ix1: flags=8802 mtu 1500
lladdr 00:30:18:0b:4a:82
index 4 priority 0 llprio 3
media: Ethernet autoselect (10GbaseSR full-duplex)
status: active
ix2: flags=8802 mtu 1500
lladdr 00:30:18:0b:4a:83
index 5 priority 0 llprio 3
media: Ethernet autoselect
status: no carrier
ix3: flags=8802 mtu 1500
lladdr 00:30:18:0b:4a:84
index 6 priority 0 llprio 3
media: Ethernet autoselect (10GbaseSR full-duplex)
status: active

# ifconfig ix1 rdomain 1 10.0.0.1
# ifconfig ix3 rdomain 3 10.0.0.3
# ping -V 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.573 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.246 ms

# route -T 1 exec iperf -c 10.0.0.3

Client connecting to 10.0.0.3, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 10.0.0.1 port 29912 connected with 10.0.0.3 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec   871 MBytes   731 Mbits/sec

If anyone want to help run it faster, you re welcome.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: ix(4) need support for X553

[sven falempin]

On Thu, Oct 31, 2019 at 9:17 AM Stuart Henderson 
wrote:

> On 2019/10/31 08:25, sven falempin wrote:
> > Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly
> removed from this
>
> The pcidevs update is no longer needed since pcidevs r1.1889.
>
> > I may have time to test it against 6.6, see if it is still working since
> 6.4 (where it was
> > tested, also a cross test revealed
> > that plugin'/unplugging SFP maybe non functionnal)
>
> I can test an already-wprking fibre ix for new problems at some point, but
> I don't
> think I'll have a fibre X553.
>
>
ppb7 at pci0 dev 22 function 0 "Intel C3000 PCIE" rev 0x11
"Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 0 not configured
"Intel X553 SFP+" rev 0x11 at pci8 dev 0 function 1 not configured
ppb8 at pci0 dev 23 function 0 "Intel C3000 PCIE" rev 0x11
"Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 0 not configured
"Intel X553 SFP+" rev 0x11 at pci9 dev 0 function 1 not configured

When I look at them , some more involved people was talking about 10gb in
OpenBSD .

Isn't there some limitations currently or can we expect the X553  to
perform at 10Gb ?


-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: ix(4) need support for X553

[sven falempin]

On Wed, Oct 30, 2019 at 5:43 PM Stuart Henderson 
wrote:

> On 2019/10/30 07:34, sven falempin wrote:
> > https://github.com/dohnuts/wip/blob/master/ixgbe.diff
> >
> > Needs lots of cleaning
> >
> > On Wed, Oct 30, 2019 at 6:59 AM Joerg Goltermann  wrote:
> >
> > > Hello,
> > >
> > > I have a new Lanner NCA-1510A (with a Intel C3558) which has some
> > > X553 SGMII ethernet ports. Unfortunately there is no support in ix(4)
> > > for this type.
> > >
> > > Is anyone working on an update for the ix(4) to support the new
> > > hardware?
> > >
> > > I took a look at the actual ix(4) and it's a bit confusing. I'm
> > > not sure about the "version" of this driver compared to FreeBSD/
> > > Intel version.
> > >
> > > Wouldn't it be nice to have a more "stock" version of the driver. This
> > > would make it much easier to port updates from FreeBSD/Intel to
> OpenBSD.
> > >
> > > Any feedback is appreciated.
> > >
> > >   - Joerg
> > >
>
> Oh I've got a machine coming soon and I have a nasty feeling it's going to
> have one of those ..
>
> That diff is stale, I've merged conflicts at
> https://junkpile.org/ixgbe.diff2,
> and it builds but totally untested.
>
>
Thank you, the ./dev/pci/pcidevs_data.h,  pcidevs.h are completly removed
from this

I may have time to test it against 6.6, see if it is still working since
6.4 (where it was tested, also a cross test revealed
that plugin'/unplugging SFP maybe non functionnal)



-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: ix(4) need support for X553

[sven falempin]

https://github.com/dohnuts/wip/blob/master/ixgbe.diff

Needs lots of cleaning

On Wed, Oct 30, 2019 at 6:59 AM Joerg Goltermann  wrote:

> Hello,
>
> I have a new Lanner NCA-1510A (with a Intel C3558) which has some
> X553 SGMII ethernet ports. Unfortunately there is no support in ix(4)
> for this type.
>
> Is anyone working on an update for the ix(4) to support the new
> hardware?
>
> I took a look at the actual ix(4) and it's a bit confusing. I'm
> not sure about the "version" of this driver compared to FreeBSD/
> Intel version.
>
> Wouldn't it be nice to have a more "stock" version of the driver. This
> would make it much easier to port updates from FreeBSD/Intel to OpenBSD.
>
> Any feedback is appreciated.
>
>   - Joerg
>
> --
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: acme-client no longer usable on -stable?

[sven falempin]

On Thu, Oct 10, 2019 at 2:57 AM Stuart Henderson 
wrote:

> On 2019/10/09 08:50, sven falempin wrote:
> > "2019-10-16T12:35:23Z", "challenges": [ { "type": "http-01", "status":
> > "invalid", "error": { "type": "urn:ietf:params:acme:error:connection",
> > "detail": "Fetching
> >
> http://siot.XX.com/.well-known/acme-challenge/Iu3ZGDaCNUZOXnHqCra6sHAsJL4qdqwRKXgMszZJCJA
> :
> > Connection refused", "status": 400 }, "url": "
> > https://acme-v02.api.letsencrypt.org/acme/chall-v3/701076860/ZeqP3g;,
>
> This is letsencrypt saying that it can't connect to the http port on
> your server. Doesn't work for me either:
>
> $ curl http://siot.citypassenger.com/
> curl: (7) Failed to connect to siot.citypassenger.com port 80: Connection

refused


Thank you, it works 

>
> --
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: acme-client no longer usable on -stable?

[sven falempin]

On Thu, Sep 12, 2019 at 9:00 AM Florian Obser  wrote:

> On Thu, Sep 12, 2019 at 12:42:58PM +0200, Henry Jensen wrote:
> > Greetings,
> >
> > A tweet[0]from @romanzolotarev confused some people, including me.
> >
> > Basically he says, that if you wish co continue to use acme-client you
> > have to upgrade to -current, because of the switch to ACME v02 API and
> > the deprecation of v01.
>
> [citation needed]
> I guess they ran out of space in their twitters.
>
> https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430
>
> >
> > That would mean, that acme-client on -stable can no longer be used.
> >
> > Is that true, and if so, it is planned to publish a patch for stable?
>
> mostly not true and it is not planned to publish a patch for stable.
>
> No new accounts starting November 2019 and no new domains starting
> June 2020. So existing domains can be renewed while 6.5 still receives
> patches.
>
> Changing the api endpoint from 01 to 02 in 6.5 will not work.
>
> >
> >
> > [0] https://twitter.com/romanzolotarev/status/1172009006078074886
> >
>
> --
> I'm not entirely sure you are real.
>
>

I upgraded to snapshot a device and was eager to use acme-client instead of
certbot and the
zillion of python dependencies,I removed the strip 2 and tested with ftp if
the challenge
path was accessible , because the server is nginx ( i PUT file and I also
use some auto retry in proxy mode )

This device was previously using certbot and i created a new domain name to
avoid overlapping.
So far my attempts at creating the certificate failed :-(

- CONF -
#
# $OpenBSD: acme-client.conf,v 1.7 2018/04/13 08:24:38 ajacoutot Exp $
#
authority letsencrypt {
api url "https://acme-v02.api.letsencrypt.org/directory;
account key "/etc/acme/letsencrypt-privkey.pem"
}authority letsencrypt-staging {
api url "https://acme-staging-v02.api.letsencrypt.org/directory;
account key "/etc/acme/letsencrypt-staging-privkey.pem"
}domain siot.XX.com {
domain key "/etc/ssl/private/siot.XX.com.key"
domain certificate "/etc/ssl/siot.XX.com.crt"
domain full chain certificate
"/etc/ssl/siot.XX.com.fullchain.pem"
challengedir "/var/www/acme/.well-known/acme-challenge"
sign with letsencrypt
}
- NGINX serving -
   server
   {
listen 80;
server_name siot.XX.com;
root /var/www/acme;
location ~ /.well-known/acme-challenge/(.*) {
try_files $uri =404;
}
}
and access :
current# curl --fail
http://siot.XX.com/.well-known/acme-challenge/foobar
lol
current# cat /var/www/acme/.well-known/acme-challenge/foobar
lol
- acme OUPUT  -
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: transfer buffer: [{ "identifier": { "type": "dns", "value": "
siot.XX.com" }, "status": "pending", "expires":
"2019-10-16T12:35:23Z", "challenges": [ { "type": "http-01", "status":
"pending", "url": "
https://acme-v02.api.letsencrypt.org/acme/chall-v3/701076860/ZeqP3g;,
"token": "Iu3ZGDaCNUZOXnHqCra6sHAsJL4qdqwRKXgMszZJCJA" }, { "type":
"dns-01", "status": "pending", "url": "
https://acme-v02.api.letsencrypt.org/acme/chall-v3/701076860/K4SYKQ;,
"token": "Iu3ZGDaCNUZOXnHqCra6sHAsJL4qdqwRKXgMszZJCJA" }, { "type":
"tls-alpn-01", "status": "pending", "url": "
https://acme-v02.api.letsencrypt.org/acme/chall-v3/701076860/iqKsWA;,
"token": "Iu3ZGDaCNUZOXnHqCra6sHAsJL4qdqwRKXgMszZJCJA" } ] }] (797 bytes)
acme-client: challenge, token: Iu3ZGDaCNUZOXnHqCra6sHAsJL4qdqwRKXgMszZJCJA,
uri: https://acme-v02.api.letsencrypt.org/acme/chall-v3/701076860/ZeqP3g,
status: 0
acme-client:
/var/www/acme/.well-known/acme-challenge/Iu3ZGDaCNUZOXnHqCra6sHAsJL4qdqwRKXgMszZJCJA:
created
acme-client:
https://acme-v02.api.letsencrypt.org/acme/chall-v3/701076860/ZeqP3g:
challenge
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: transfer buffer: [{ "type": "http-01", "status": "pending",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/701076860/ZeqP3g;,
"token": "Iu3ZGDaCNUZOXnHqCra6sHAsJL4qdqwRKXgMszZJCJA" }] (184 bytes)
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: 172.65.32.248: tls_close: EOF without close notify
acme-client: transfer buffer: [{ "status": "pending", "expires":
"2019-10-16T12:35:23Z", "identifiers": [ { "type": "dns", "value": "
siot.XX.com" } ], "authorizations": [ "
https://acme-v02.api.letsencrypt.org/acme/authz-v3/701076860; ],
"finalize": "
https://acme-v02.api.letsencrypt.org/acme/finalize/68764372/1250153505; }]
(341 bytes)
acme-client: order.status 0
acme-client: dochngreq:
https://acme-v02.api.letsencrypt.org/acme/authz-v3/701076860
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: acme-v02.api.letsencrypt.org: cached
acme-client: 172.65.32.248: 

Re: Minor vi MAN helper/precisions

[sven falempin]

On Fri, Oct 4, 2019 at 4:29 AM Stuart Henderson  wrote:

> On 2019/10/03 11:56, sven falempin wrote:
> > BTW, on modern system RAM is plentiful while SSD are not always '/tmp'
> > friendly.
>
> Some of the slower media (CF/SD cards etc) might have issues eventually but
> I would expect anything worthy of the name 'SSD' should be fine.
>
> > Using tmpfs for /tmp,  vi unless you create a proto with
> vi.recover
> > subdir or create it on rc.local.
> > maybe a mkdir /tmp/vi.recover.uid would make sense, or just a mktemp .
>
> eh?
>
> - vi.recover is created by /usr/libexec/vi.recover which is run from
> /etc/rc already
>
> - tmpfs is disabled in the kernel config for a reason
>

I will investigate why I lose the directory so often . Meant MFS , no
custom kernel.
Last time it’s just a no reboot situation *

Are you ok with the man changes ?
-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: Minor vi MAN helper/precisions

[sven falempin]

On Thu, Oct 3, 2019 at 12:15 PM Jason McIntyre  wrote:
>
> On Thu, Oct 03, 2019 at 11:56:26AM -0400, sven falempin wrote:
> > Dear reader,
> >
> > If you look an option, the options section does not tell you how to set it
> > ( nor where )
> > at least this creates a searchable ref between the set ( which you cannot
> > find looking for set
> > because of the [t] ).
> >
>
> hi.
>
> it's probably not explicit since it's fairly straightforward, and
> there's an example near page top.
>
> still, your point is a fair one. but there's no "OPTIONS" section - just
> "SET OPTIONS", and that doesn;t fit into the text. i wonder if it
> wouldn;t make sense to rearrange the text at the start of SET OPTIONS.
>
> SET OPTIONS
> There are a large number of options that may be set (or unset)
> to change the editor's behaviour.
>
> we could change that to sth like:
>
> SET OPTIONS
> There are a large number of options that can change the editor's
> behaviour, using the set command.
>
> would that address your issue?
> jmc
>

Ok, SET OPTIONS is written as `.Sh SET OPTIONS` ,
and yes
I did not understand that SET was the command,
not why the sections was named like that .
At first I just enter option=value in the .exrc file '-_-

Nevertheless this is still less easy as you cannot search '/set' in
the man because of the se[t]
and the fact that set is very common word.
Looking for OPTIONS ( not options ) should reveal the link between the two IMHO.

-Display or set editor options.
+ Display or
+ .Sx SET OPTIONS
+ of the editor.

And your text change really does not hurt .

Best.

Minor vi MAN helper/precisions

[sven falempin]

Dear reader,

If you look an option, the options section does not tell you how to set it
( nor where )
at least this creates a searchable ref between the set ( which you cannot
find looking for set
because of the [t] ).

Index: docs/USD.doc/vi.man/vi.1
===
RCS file: /cvs/src/usr.bin/vi/docs/USD.doc/vi.man/vi.1,v
retrieving revision 1.76
diff -u -p -r1.76 vi.1
--- docs/USD.doc/vi.man/vi.121 May 2019 09:24:58 -  1.76
+++ docs/USD.doc/vi.man/vi.13 Oct 2019 15:52:42 -
@@ -2089,7 +2089,9 @@ in a line, not just the first.
 .Op option? ...
 .Op Ar all
 .Xc
-Display or set editor options.
+Display or set editor
+.Sx OPTIONS
+.
 .Pp
 .It Cm sh Ns Op Cm ell
 Run a shell program.

- - -
BTW, on modern system RAM is plentiful while SSD are not always '/tmp'
friendly.
Using tmpfs for /tmp,  vi unless you create a proto with vi.recover
subdir or create it on rc.local.
maybe a mkdir /tmp/vi.recover.uid would make sense, or just a mktemp .
Your call of course.

Best.

Re: arm64: softraid boot

[sven falempin]

On Fri, Aug 2, 2019 at 3:26 PM Patrick Wildt  wrote:
>
> On Fri, Aug 02, 2019 at 03:16:55PM -0400, sven falempin wrote:
> > Dear ARM gurus,
> >
> > I m trying to tftp boot last snaphots on pine64+.
> > Not sure if it s possible.
> > So far I tried loading minitroot like an idiot and then, a boolader,
> > now I cant get the efi bootloader to do some tftp ( which I guess is normal 
> >  )
> > But maybe I am just missing a small pieces.
>

Just a though, low value but maybe of some use,
assuming the bsd.rd is at the end of the EFI loader
cat BOOTAA64.EFI bsd.rd > EZ.EFI
Then in our boot , the code could check if there is a bsd.rd down there
or we could have a 'bootm' command (which would be default for this )

And `voila` we can boot bsd.rd through network for testing and more ?

Is this possible ?

Best


-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: arm64: softraid boot

[sven falempin]

Dear ARM gurus,

I m trying to tftp boot last snaphots on pine64+.
Not sure if it s possible.
So far I tried loading minitroot like an idiot and then, a boolader,
now I cant get the efi bootloader to do some tftp ( which I guess is normal  )
But maybe I am just missing a small pieces.

I also created etc/boot.conf in the tftp directory.. just in case.

getting some bsd code to boot :

=> dhcp
BOOTP broadcast 1
DHCP client bound to address 172.16.65.55 (1445 ms)
Using ethernet@01c3 device
TFTP from server 172.16.65.1; our IP address is 172.16.65.55
Filename 'BOOTAA64.EFI'.
Load address: 0x4200
Loading: ###
 5.1 MiB/s
done
=> bootefi 0x4200
## Starting EFI application at 4200 ...
Scanning disks on usb...
Disk usb0 not ready
Disk usb1 not ready
Disk usb2 not ready
Disk usb3 not ready
Scanning disks on mmc...
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 3 disks
WARNING: Invalid device tree, expect boot to fail
disks: sd0
>> OpenBSD/arm64 BOOTAA64 0.16
open(tftp0a:/etc/boot.conf): Operation not permitted
boot>
booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
 failed(1). will try /bsd
boot>
booting tftp0a:/bsd: open tftp0a:/bsd: Operation not permitted
 failed(1). will try /bsd
Turning timeout off.
boot> l
stat(tftp0a:/.): Operation not permitted
boot> l
stat(tftp0a:/.): Operation not permitted
boot> l
stat(tftp0a:/.): Operation not permitted
boot> boot tftp:bsd.rd
cannot open tftp:/etc/random.seed: bad drive number
booting tftp:bsd.rd: open tftp:bsd.rd: bad drive number
 failed(98). will try /bsd
boot> boot 172.16.65.1:/bsd.rd
boot> boot tftp:/bsd.rd
cannot open tftp:/etc/random.seed: bad drive number
booting tftp:/bsd.rd: open tftp:/bsd.rd: bad drive number
 failed(98). will try /bsd
boot> boot tftp0a:/bsd.rd
booting tftp0a:/bsd.rd: open tftp0a:/bsd.rd: Operation not permitted
 failed(1). will try /bsd

is there some kind of trick to boot this ?


On Thu, Jan 31, 2019 at 7:54 AM Mark Kettenis  wrote:
>
> > Date: Wed, 30 Jan 2019 22:31:31 +0100
> > From: Patrick Wildt 
> >
> > Hi,
> >
> > to boot a pinebook with softraid crypto there are three parts that need
> > to be implemented, which this diff hopefully does well enough.
> >
> > First, our EFI bootloader so far only supports one disk, so we need to
> > extend this so we can see all connected block devices.  The second part
> > is adding the softraid code, which probes for softraid partitions on the
> > block devices and "spawns" its own block device.  At last, we need to
> > push the softraid uuid and key up to the kernel.
> >
> > Pushing the informaton to the kernel is the easiest part.  We can add
> > another openbsd-specific property in the device tree which we read out
> > early on, so that we can zero the space in the device tree so it can not
> > be read by anyone else.
> >
> > For the other part there's a bit more to do.  Very early on efiboot
> > looks for the boot device.  While doing that, we create a list of block
> > devices.  While there, already try to read the disklabel because after
> > this the softraid probing needs to know the partition table.
> >
> > We then call srprobe() which will go over the disklist to look for a
> > disk that contains RAID volumes, but calling the disk's diskio and
> > strategy function to read from the device.  This creates the sr_volumes
> > list of softraid volumes.  The MI boot code will then look for the boot
> > device name by calling devboot().  If we don't have the device path for
> > the boot device, it's a PXE boot.  Otherwise we will find it in either
> > the disklist or sr_volumes list.
> >
> > The next part is the MI code opening the device, looking for a file-
> > system.  The boot device name now is e.g. sr0a, which will then be
> > looked up in the devsw[] array.  From there it's straight forward.
> > Softraid maps the unit number to a volume, the volume already has a
> > pointer to the diskinfo structure from the actual device and then
> > calls the IO functions of that device.
> >
> > softraid_arm64.[ch] is copied from amd64 and adjusted a little bit
> > for arm64, including adding the small devsw[] abstraction.
> >
> > With this I can successfully boot from softraid crypto on bluhm@'s
> > Pinebook.
> >
> > Feedback?
>
> Apart from the property names, this looks good to me.  So feel free to
> go ahead once you changed those properties.
>
> > diff --git sys/arch/arm64/arm64/machdep.c sys/arch/arm64/arm64/machdep.c
> > index 45f6451066a..03bc8464f3a 100644
> > --- sys/arch/arm64/arm64/machdep.c
> > +++ sys/arch/arm64/arm64/machdep.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >  #include 
> > @@ -49,6 +50,11 @@
> >
> >  #include 
> >
> > +#include "softraid.h"
> > +#if NSOFTRAID > 0
> > +#include 
> > +#endif
> > +
> >  char *boot_args = NULL;
> >  char *boot_file = "";
> >
> > @@ -826,6 +832,22 @@ initarm(struct arm64_bootparams *abp)
> >   

pushing option to dhclient from netstart

[sven falempin]

Dear reader,

/etc/netstart pushed option from 'dhcp #options#' beside ifconfig and before up.
It's easy to have this behavior like this

#options#
dhcp

OTA dhclient could be feed with argument like -l or -L , but those are
not easily configured.
it seams like a minor typo was introduce, or there is another/better
way that eluded me.

current# diff -bu /etc/netstart.base /etc/netstart
--- /etc/netstart.base  Wed Jul  3 22:23:35 2019
+++ /etc/netstart   Wed Jul  3 22:24:22 2019
@@ -65,7 +65,7 @@
_cmds[$_prev]="${_c[@]}"
;;
dhcp)   _c[0]=
-   _cmds[${#_cmds[*]}]="ifconfig $_if ${_c[@]} up;dhclient $_if"
+   _cmds[${#_cmds[*]}]="ifconfig $_if up;dhclient $_if ${_c[@]}"
V4_DHCPCONF=true
;;
'!'*)   _cmd=$(print -- "${_c[@]}" | sed 's/\$if/'$_if'/g')
current# cat /etc/hostname.vether0
dhcp -l /tmp/lol
current# sh /etc/netstart -n vether0
ifconfig vether0 up;dhclient vether0  -l /tmp/lol

Can we fix this ?
Moreover is it still require to up the interface before ?

( the diff above contains space, tr them or -b )

Thank you for reading all that.
Best.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: ntpd auto time setting

[sven falempin]

On Thu, Jun 20, 2019 at 6:46 AM Otto Moerbeek  wrote:

> Hi,
>
> I have been working on a nice feature that improves startup behaviour of
> ntpd.
>
> Summary: make sure you have at least one constraint source configured
> and use no options. ntpd will set the clock if needed, even if you
> machines has no battery backed up clock and is running a DNSSEC
> validating resolver.
>
> Previoulsy, using constraints or a DNSSEC validating resolver would
> break initial time setting, since doing https certificate and DNSSEC
> validation requires a proper clock. An we do not have that in above
> circumstances.
>
> In addition to previous work from jsing@ regarding https certificate
> validation my commits enable time bootstrapping in these adverse
> conditions.
>
> You want to stop using -s if you did, since the new method is more
> robust and more secure. (-s trusts any ntp reply, while the new
> automatic mode only does so if several ntp replies were validated).
>
> The last commit was a few hours ago, upcoming snaps should have all
> the nice things.
>
> -Otto
>
>
>
It works here (complied from source).
Device go back to right time after Destroying date at boot and only
accepting DNSSEC .

snaps# date
Thu Jun 20 15:52:57 CEST 2019
snaps# uptime
 3:52PM  up 2 mins, 1 user, load averages: 0.07, 0.04, 0.01
snaps# head /etc/rc
#   $OpenBSD: rc,v 1.537 2019/05/10 13:29:21 guenther Exp $
# System startup script run by init on autoboot or after single-user.
# Output and error are redirected to console by init, and the console is the
# controlling terminal.
date 201806041030.00
# Turn off Strict Bourne shell.

Best.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: trunk(4) shouldn't need to play with a port's if_type

[sven falempin]

Some interfaces are marked as busy ( promiscuitous ?) so they can’t be
added in two bridges for example, this could be extended and make things
more consistent?

Just my two cents

On Tue, Jun 11, 2019 at 8:27 PM David Gwynne  wrote:

> I get that trunk ports should not be able to be added to bridges or have
> carp interfaces hanging off them, but I think the value of making the
> if_type immutable outweighs this usability feature. Especially when you
> consider that you can have an interface that is already a member of a
> bridge (or have the other things on it) and then add it to trunk, and the
> system thinks that it is fine.
>
> It gets more confusing when you think about whether things like vlan or
> bpe are "service delimiting" or not, and how they're supposed to interact
> with trunk. If trunk is enabled on a physical interface, should vlan be
> allowed to coexist with it? If the trunk is doing LACP, you could argue no,
> but if it's doing failover or broadcast then maybe you want that to operate
> independently for different vlans and the "native" vlan on the one physical
> interface.
>
> If we ever want to support "independent" LACP trunk port operation like a
> variety of switches do now, then it makes sense to maintain IFT_ETHER too.
>
> dlg
>
> >
> > On 11 Jun 2019, at 17:32, Reyk Floeter  wrote:
> >
> > Hi,
> >
> > the initial intention was to differentiate a trunk port from a regular
> Ethernet interface.
> >
> > As long as an interface is a member of a trunk, it is not a fully
> featured Ethernet interface. The changed type prevented from using it
> elsewhere.
> >
> > I‘m not so familiar with the current network stack anymore, so maybe
> there are other ways to do it these days, but you should test that a trunk
> port cannot be attached to a bridge or carp or anything like this.
> >
> > You also forgot a comment that mentions the type as well.
> >
> > Reyk
> >
> >> Am 11.06.2019 um 08:33 schrieb David Gwynne :
> >>
> >> i think trunk(4) is the only thing left in the kernel that modifies an
> >> interfaces if_type at runtime. this diff removes that fiddling, so
> >> hopefully we can say that if_type is immutable after this.
> >>
> >> however, while this diff reads well to me, i don't actually know if it
> >> works. could someone kick the tyres for me?
> >>
> >> cheers,
> >> dlg
> >>
> >> Index: if_trunk.c
> >> ===
> >> RCS file: /cvs/src/sys/net/if_trunk.c,v
> >> retrieving revision 1.140
> >> diff -u -p -r1.140 if_trunk.c
> >> --- if_trunk.c11 May 2019 18:10:45 -1.140
> >> +++ if_trunk.c11 Jun 2019 06:31:29 -
> >> @@ -330,10 +330,7 @@ trunk_port_create(struct trunk_softc *tr
> >>   }
> >>   }
> >>
> >> -/* Change the interface type */
> >> -tp->tp_iftype = ifp->if_type;
> >> -ifp->if_type = IFT_IEEE8023ADLAG;
> >> -
> >> +/* Change the interface methods */
> >>   tp->tp_ioctl = ifp->if_ioctl;
> >>   ifp->if_ioctl = trunk_port_ioctl;
> >>
> >> @@ -422,9 +419,7 @@ trunk_port_destroy(struct trunk_port *tp
> >>   if (tr->tr_port_destroy != NULL)
> >>   (*tr->tr_port_destroy)(tp);
> >>
> >> -/* Restore interface type. */
> >> -ifp->if_type = tp->tp_iftype;
> >> -
> >> +/* Restore interface methods. */
> >>   ifp->if_ioctl = tp->tp_ioctl;
> >>   ifp->if_output = tp->tp_output;
> >>
> >> @@ -474,8 +469,7 @@ trunk_port_ioctl(struct ifnet *ifp, u_lo
> >>   int error = 0;
> >>
> >>   /* Should be checked by the caller */
> >> -if (ifp->if_type != IFT_IEEE8023ADLAG ||
> >> -(tp = trunk_port_get(NULL, ifp)) == NULL ||
> >> +if ((tp = trunk_port_get(NULL, ifp)) == NULL ||
> >>   (tr = (struct trunk_softc *)tp->tp_trunk) == NULL) {
> >>   error = EINVAL;
> >>   goto fallback;
> >> @@ -521,8 +515,7 @@ trunk_port_output(struct ifnet *ifp, str
> >>struct rtentry *rt)
> >> {
> >>   /* restrict transmission on trunk members to bpf only */
> >> -if (ifp->if_type == IFT_IEEE8023ADLAG &&
> >> -(m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
> >> +if ((m_tag_find(m, PACKET_TAG_DLT, NULL) == NULL)) {
> >>   m_freem(m);
> >>   return (EBUSY);
> >>   }
> >> @@ -1123,10 +1116,6 @@ trunk_input(struct ifnet *ifp, struct mb
> >>   eh = mtod(m, struct ether_header *);
> >>   if (ETHER_IS_MULTICAST(eh->ether_dhost))
> >>   ifp->if_imcasts++;
> >> -
> >> -/* Should be checked by the caller */
> >> -if (ifp->if_type != IFT_IEEE8023ADLAG)
> >> -goto bad;
> >>
> >>   tp = (struct trunk_port *)cookie;
> >>   if ((tr = (struct trunk_softc *)tp->tp_trunk) == NULL)
> >>
> >
>
> --
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: Talking about time (ntpd -s)

[sven falempin]

On Wed, Apr 24, 2019 at 2:39 PM Theo de Raadt  wrote:

> sven falempin  wrote:
>
> > Dear Tech reader,
> >
> > NTPD -S is useful, when a device is in storage for a while the clock is
> in
> > disarray.
> > But this assume the network exists, the fixed 15 seconds timeout makes
> > sense,
> > nevertheless it could be too long or too short.
> >
> > https://pastebin.com/gmNGpXLq
> >
> > Also NTPD just log out the failure after 15 seconds, not informing a
> script
> > that time is probably wrong.
> >
> > https://pastebin.com/z0eVrvgG
> >
> > Alast why not just wait for something to respond and then set time ??
> > This (bit ugly) diff reveals some dead code in ntpd
> >
> > https://pastebin.com/9PwqBDHz
> >
> > Is there another way to bootstrap time correctly ?
>
> No. It is a crappy workaround.
>
> I have schemed about a better method, but it is quite complicated
> and hasn't been written.
>

[ or even a script that takes on
a more complicated set of actions before allowing the system to move
forward]


The only way is to check the log files for the messages, which is not so
easy to do correctly
in a bunch of script file.

Currently I wait 'internet' to be ready before starting ntpd, but then my
system MAY wonder why some
services started in a another space/time ( well another time only ).

So I am open to any suggestion to have a better way.

currently the patch https://pastebin.com/z0eVrvgG that change the exit code
in case timeout is reach
is the less ugly IMHO, maybe just let the daemon(1,0) call and print
something on STDERR or even STDOUT
so a script file knows it s wrong without looking for log ( which are time
based ! )

Best.

PS: ( can we remove the == -1 that does not exist, or is it a return error
in the called function  https://pastebin.com/9PwqBDHz )

Talking about time (ntpd -s)

[sven falempin]

Dear Tech reader,

NTPD -S is useful, when a device is in storage for a while the clock is in
disarray.
But this assume the network exists, the fixed 15 seconds timeout makes
sense,
nevertheless it could be too long or too short.

https://pastebin.com/gmNGpXLq

Also NTPD just log out the failure after 15 seconds, not informing a script
that time is probably wrong.

https://pastebin.com/z0eVrvgG

Alast why not just wait for something to respond and then set time ??
This (bit ugly) diff reveals some dead code in ntpd

https://pastebin.com/9PwqBDHz

Is there another way to bootstrap time correctly ?

Best

Regression on dhclient and automatisation

[sven falempin]

Dear courageous Reader,

The 6.0 to 6.4 diff show the go_daemon ( why not
https://man.openbsd.org/daemon ??? )
function changed a lot, before it was working through automation software
now it creates zombie, that NEVER dies.

do_daemon Diff Below.

One way to produce this would be :

perl
unless ( fork ) {
close STDIN; close STDOUT; close STDERR;
open STDIN, '/dev/null';
open STDOUT, '>/dev/null';
open STDERR, '>/dev/null';
exec('dhclient', 'if0'); #choose your if
}
^D

The code of dhclient regarding the privsep is quite complex
and apparently the isatty is quite late.


Going to daemon super early 'fix' the problem
( I have another diff in this stable tree so don't mind the line number )

@@ -554,6 +558,11 @@ main(int argc, char *argv[])
if ((cmd_opts & OPT_NOACTION) != 0)
return 0;
+   if (isatty(STDERR_FILENO) != 0
+   && (cmd_opts & OPT_FOREGROUND) == 0 ) {
+// cmd_opts |= OPT_VERBOSE;
+   go_daemon();
+   }
/*
 * Set default client identifier, if needed, *before* reading
 * the leases file! Changes to the lladdr will trigger a restart

go_daemon maybe over kill , so far I don't understand which FD stay open
I guess only reading ktrace would help.

o: Thank you for reading :o

 - - - - - - - - -

 void
 go_daemon(void)
 {
- static int state = 0;
+ static int daemonized = 0;

- if (no_daemon || state)
+ if ((cmd_opts & OPT_FOREGROUND) != 0 || daemonized != 0)
  return;

- state = 1;
+ daemonized = 1;

+ if (rdaemon(nullfd) == -1)
+ fatal("daemonize");
+
  /* Stop logging to stderr. */
- log_perror = 0;
+ log_init(0, LOG_DAEMON);
+ if ((cmd_opts & OPT_VERBOSE) != 0)
+ log_setverbose(1); /* Show log_debug() messages. */
+ log_procinit(log_procname);

- if (daemon(1, 0) == -1)
- error("daemon");
-
- /* we are chrooted, daemon(3) fails to open /dev/null */
- if (nullfd != -1) {
- dup2(nullfd, STDIN_FILENO);
- dup2(nullfd, STDOUT_FILENO);
- dup2(nullfd, STDERR_FILENO);
- close(nullfd);
- nullfd = -1;
- }
-
- /* Catch stuff that might be trying to terminate the program. */
+ setproctitle("%s", log_procname);
  signal(SIGHUP, sighdlr);
- signal(SIGINT, sighdlr);
- signal(SIGTERM, sighdlr);
- signal(SIGUSR1, sighdlr);
- signal(SIGUSR2, sighdlr);
-
  signal(SIGPIPE, SIG_IGN);
 }



--
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Better call poll - pkg_add / ftp can never timeout

[sven falempin]

Dear Reader

I already send email about my issue with pkg_add staying up for a long time.
I cannot change the sysctl because other connections need large inactivity.

I finally got a 'decent' diff working, still not very good imho,
tls_read shall provide something smart as poll reply the data amount ready
to be fetch but because of the crypto layer, it cannot be used.
Also the FD is inside the tls context.
Also kept it out of 

I do hope this, or a better this, can somewhat end up in base.
I suspect some kind of relay or transparent proxy to be bugged,
or a routing to get wrong during the transfer. This creating a socket
that does not ever close but does not send data. Or worse.
Anyway I'd like my pkg_add to quit after a while, and -w is only
doing the connection part.
I guess the variable should be rename too in another diff maybe or the same
don't know.

maybe SIGALARM could be used to effectively timeout in the read
payload part.

Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.167
diff -u -p -r1.167 fetch.c
--- fetch.c 10 Feb 2018 06:25:16 -  1.167
+++ fetch.c 13 Oct 2018 03:51:53 -
@@ -63,6 +63,9 @@
 #else /* !NOSSL */
 struct tls;
 #endif /* !NOSSL */
+#ifndef SMALL
+#include 
+#endif /* SMALL */
 #include "ftp_var.h"
 #include "cmds.h"
@@ -173,6 +176,33 @@ tooslow(int signo)
_exit(2);
 }
+#ifndef SMALL
+int
+ftp_poll(struct pollfd pfd[]) {
+   int nready;
+   struct timespec timeout;
+   sigset_t blocked, omask;
+   sigemptyset();
+   sigaddset(, SIGALRM); //PROGRESS METER -_-
+   sigprocmask(SIG_BLOCK, , );
+
+   timeout.tv_sec = connect_timeout;
+   timeout.tv_nsec = 0;
+
+   nready = ppoll(pfd, 1, , );
+   if (nready == -1) {
+   errx(1, "poll");
+   }
+   if (nready == 0) {
+   warn("Timeout\n");
+   return 1;
+   }
+   if ((pfd[0].revents & (POLLERR|POLLNVAL)))
+   errx(1, "bad fd");
+   return 0;
+}
+#endif
+
 /*
  * Retrieve URL, via the proxy in $proxyvar if necessary.
  * Modifies the string argument given.
@@ -210,6 +240,10 @@ url_get(const char *origline, const char
int status;
int save_errno;
const size_t buflen = 128 * 1024;
+#ifndef SMALL
+   struct pollfd pfd[1];
+   pfd[0].fd = -1;
+#endif
direction = "received";
@@ -609,6 +643,12 @@ noslash:
goto cleanup_url_get;
}
+#ifndef SMALL
+   if (connect_timeout) {
+   pfd[0].fd = fd;
+   pfd[0].events = POLLIN;
+   }
+#endif /* !SMALL */
 #ifndef NOSSL
if (ishttpsurl) {
if (proxyenv && sslpath) {
@@ -659,6 +699,11 @@ noslash:
signal(SIGALRM, SIG_DFL);
alarmtimer(0);
}
+#ifndef SMALL
+   if (connect_timeout) {
+   fcntl(pfd[0].fd , F_SETFL, O_NONBLOCK);
+   }
+#endif /* !SMALL */
/*
 * Construct and send the request. Proxy requests don't want
leading /.
@@ -763,6 +808,11 @@ noslash:
warn("Writing HTTP request");
goto cleanup_url_get;
}
+#ifndef SMALL
+   if (pfd[0].fd != -1)
+   if (ftp_poll(pfd))
+   goto cleanup_url_get;
+#endif
if ((buf = ftp_readline(fin, tls, )) == NULL) {
warn("Receiving HTTP reply");
goto cleanup_url_get;
@@ -833,6 +883,11 @@ noslash:
filesize = -1;
for (;;) {
+#ifndef SMALL
+   if (pfd[0].fd != -1)
+   if (ftp_poll(pfd))
+   goto cleanup_url_get;
+#endif
if ((buf = ftp_readline(fin, tls, )) == NULL) {
warn("Receiving HTTP reply");
goto cleanup_url_get;
@@ -978,6 +1033,11 @@ noslash:
len = 1;
oldinti = signal(SIGINFO, psummary);
while (len > 0) {
+#ifndef SMALL
+   if (pfd[0].fd != -1)
+   if (ftp_poll(pfd))
+   goto cleanup_url_get;
+#endif
len = ftp_read(fin, tls, buf, buflen);
bytes += len;
for (cp = buf, wlen = len; wlen > 0; wlen -= i, cp += i) {

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: ftp -w is not dying

[sven falempin]

On Thu, Sep 27, 2018 at 11:59 AM sven falempin 
wrote:

>
>
> On Thu, Sep 27, 2018 at 10:47 AM sven falempin 
> wrote:
>
>> I m not sure how this is possible but here s the data :
>>
>> i used the ENV to push -w 5 in my pkg_add process :
>> # date
>> Thu Sep 27 10:40:28 EDT 2018
>> # ps auxww | grep pkgfet
>> _pkgfetc 60348 0.0 0.1 1728 5456 ?? INp Wed05PM 0:00.09 /usr/bin/ftp -w 5
>> -S session -o - https://
>> myportal.com/tar/6.3/packages/amd64/p5-LWP-MediaTypes-6.02.tgz
>> # fstat -p  60348
>> _pkgfetc ftp 60348 5* internet stream tcp 0x806e8548
>> 172.16.1.35:5512 --> 92.222.70.241:443
>>
>> I can see the PF state on the natting device:
>>
>> tcp 206.180.254.190:52251 (172.16.1.35:5512) -> 92.222.70.241:443
>> ESTABLISHED:ESTABLISHED
>> age: 16:55:28 expires: 07:07:25 id: 5b7ce30b0094854a
>> rule: pass out quick on em5 all flags S/SA label "READY_TO_NAT" tagged
>> READY_TO_NAT
>>
>> this is stock 6.3 ftp which is still the same now (
>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/ )
>>
>> # ktrace -p 60348
>> generate an empty 64 bit file.
>>
>> Any other test i could do to understand ?
>>
>>
>
Reading NC it seems that the 'poll' syscall is indeed required to
timeout correctly.

I m trying to find a way to recreate the problem and i am running a
modified version in a loop

My understanding of the tls_read(SSL_read then ssl_read) .. is that the
retry is for SSL protocol error
and retry which would only occur on non TCP layer. That's  irrelevant in
fetch.c
I m just guessing the  ( at the top of ssl_read )
call will write and fix an POLLIN when write is done.
This explaining trying to read again when a write is requested >.<

Nevertheless each read/write code ( and even close ) shall be precede
by a poll call.

Bellow is the patch i m testing at the moment , i do not quite like it,
it s not solving the problem, and show how the factorization of read is
making the code hard to read/modify
IMHO url_get should be just calling

url_get_https
url_get_http
url_get_ftp

and each of this function do only that. The _fin_ FILE* may be NULL
fd may be -1 randomly in the function, it s kinda messy.
And this make it difficult to nicely call poll before reading
to avoid being blocked in a read indefinitely

RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.167
diff -u -p -r1.167 fetch.c
--- fetch.c 10 Feb 2018 06:25:16 -  1.167
+++ fetch.c 27 Sep 2018 20:10:52 -
@@ -59,6 +59,7 @@
 #include 

 #ifndef NOSSL
+#include 
 #include 
 #else /* !NOSSL */
 struct tls;
@@ -73,12 +74,12 @@ voidabortfile(int);
 char   hextochar(const char *);
 char   *urldecode(const char *);
 char   *recode_credentials(const char *_userinfo);
-intftp_printf(FILE *, struct tls *, const char *, ...)
__attribute__((format(printf, 3, 4)));
+intftp_printf(FILE *, int fd, struct tls *, const char *, ...)
__attribute__((format(printf, 4, 5)));
 char   *ftp_readline(FILE *, struct tls *, size_t *);
 size_t ftp_read(FILE *, struct tls *, char *, size_t);
 #ifndef NOSSL
 intproxy_connect(int, char *, char *);
-intSSL_vprintf(struct tls *, const char *, va_list);
+intSSL_vprintf(int fd, struct tls *, const char *, va_list);
 char   *SSL_readline(struct tls *, size_t *);
 #endif /* !NOSSL */

@@ -98,6 +99,90 @@ jmp_buf  httpabort;

 static int redirect_loop;

+#ifndef NOSSL
+/*from netcat.c correct way to timeout a tls_call*/
+int
+timeout_tls(int s, struct tls *tls_ctx, int (*func)(struct tls *))
+{
+   int timeout = connect_timeout; // glu
+   struct pollfd pfd;
+   int ret;
+
+   while ((ret = (*func)(tls_ctx)) != 0) {
+   if (ret == TLS_WANT_POLLIN)
+   pfd.events = POLLIN;
+   else if (ret == TLS_WANT_POLLOUT)
+   pfd.events = POLLOUT;
+   else
+   break;
+   pfd.fd = s;
+   if ((ret = poll(, 1, timeout)) == 1)
+   continue;
+   else if (ret == 0) {
+   errno = ETIMEDOUT;
+   ret = -1;
+   break;
+   } else
+   err(1, "poll failed");
+   }
+
+   return ret;
+}
+
+/*must realloc / offset*/
+int
+timeout_tls_write(int s, struct tls *tls_ctx,
+   const void *buf, size_t buflen)
+{
+   int timeout = connect_timeout; // glu
+   struct pollfd pfd;
+   int ret;
+
+   // should check ready first => do poll write then write
+   while ((ret = tls_write(tls_ctx,buf,buflen)) != 0) {
+   if (ret == TLS_WANT_POLLIN)
+  

Re: ftp -w is not dying

[sven falempin]

On Thu, Sep 27, 2018 at 10:47 AM sven falempin 
wrote:

> I m not sure how this is possible but here s the data :
>
> i used the ENV to push -w 5 in my pkg_add process :
> # date
> Thu Sep 27 10:40:28 EDT 2018
> # ps auxww | grep pkgfet
> _pkgfetc 60348 0.0 0.1 1728 5456 ?? INp Wed05PM 0:00.09 /usr/bin/ftp -w 5
> -S session -o - https://
> myportal.com/tar/6.3/packages/amd64/p5-LWP-MediaTypes-6.02.tgz
> # fstat -p  60348
> _pkgfetc ftp 60348 5* internet stream tcp 0x806e8548
> 172.16.1.35:5512 --> 92.222.70.241:443
>
> I can see the PF state on the natting device:
>
> tcp 206.180.254.190:52251 (172.16.1.35:5512) -> 92.222.70.241:443
> ESTABLISHED:ESTABLISHED
> age: 16:55:28 expires: 07:07:25 id: 5b7ce30b0094854a
> rule: pass out quick on em5 all flags S/SA label "READY_TO_NAT" tagged
> READY_TO_NAT
>
> this is stock 6.3 ftp which is still the same now (
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/ )
>
> # ktrace -p 60348
> generate an empty 64 bit file.
>
> Any other test i could do to understand ?
>
>

My understanding of the code is that the -w cannot work .
I have been using a lot of socket and c code, and
always ended using non blocking fd because : life

the code is not using non blocking fd , and rely on the POLLIN of tls in a
strange way

The syscall in fetch.c are ( geee the get_url is crazy long and full o
ifdef :s )

error = getaddrinfo(host, port, , );
fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol);

(void)signal(SIGALRM, tooslow);
alarmtimer(connect_timeout);

connect ( and tls_init and stuff

and then

directly tls_read like that :

do {
  tret = tls_read(tls, buf, len);
} while (tret == TLS_WANT_POLLIN || tret == TLS_WANT_POLLOUT);

i did not code much with tls_read
but calling tls_read on TLS_WANT_POLLOUT

seems
far FETCH

Cheers.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

ftp -w is not dying

[sven falempin]

I m not sure how this is possible but here s the data :

i used the ENV to push -w 5 in my pkg_add process :
# date
Thu Sep 27 10:40:28 EDT 2018
# ps auxww | grep pkgfet
_pkgfetc 60348 0.0 0.1 1728 5456 ?? INp Wed05PM 0:00.09 /usr/bin/ftp -w 5
-S session -o - https://
myportal.com/tar/6.3/packages/amd64/p5-LWP-MediaTypes-6.02.tgz
# fstat -p  60348
_pkgfetc ftp 60348 5* internet stream tcp 0x806e8548
172.16.1.35:5512 --> 92.222.70.241:443

I can see the PF state on the natting device:

tcp 206.180.254.190:52251 (172.16.1.35:5512) -> 92.222.70.241:443
ESTABLISHED:ESTABLISHED
age: 16:55:28 expires: 07:07:25 id: 5b7ce30b0094854a
rule: pass out quick on em5 all flags S/SA label "READY_TO_NAT" tagged
READY_TO_NAT

this is stock 6.3 ftp which is still the same now (
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/ )

# ktrace -p 60348
generate an empty 64 bit file.

Any other test i could do to understand ?

--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: ix0/1/2/3 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:xxxxxxx

[sven falempin]

On Tue, Sep 18, 2018 at 4:39 AM Hrvoje Popovski  wrote:

> On 17.9.2018. 22:32, sven falempin wrote:
> > Dear Tech reader,
> >
> > I am recently working on  Intel(R) Atom(TM) CPU C3758  intel devices.
> > SFP Intel card are not working in 6.3/current openBSD base
> >
> > I did patch intel driver reading netbsd, freebsd and intel code of ixgbe
> > driver.
> >
> > I am now transferring data between two openBSD at ~1.50 Gb/s
> > for more than 48 hours ( been looping all week end )
> >
> > First, i d like to find other user with ix card to check for regression !
> > Secondly, can i get some feedback on how to test 10Gb /s transfer
> >  - i usually download ramfs file through nginx or use iperf .
> > Third, how can i get a patch accepted into base : ie, how do i clean this
> > work ?
>
> Hi,
>
> user here. Thank you for doing this. I think that your primary concern
> at this point should be stability of this driver.
> While transferring data over ix interfaces you could try shutting down
> interfaces and bring them up. maybe something like this in loop:
>
> ifconfig ix0 down && ifconfig ix0 up && ifconfig ifconfig ix1 down &&
> ifconfig ix1 up && ifconfig ix0 down && ifconfig ix1 down && sh netstart
>
>
that is working okay, and unplugging too


>
> if you have some sx or lx sfp+ modules insert/remove them in ix
> interfaces and stuff link that.
>

I only have one type of sfp+ with me


>
> regarding performance testing if you have other box with 10G interfaces
> you could directly connect these boxes and generate lots of traffic over
> your driver and doing all that crazy stuff..
>
>
i only have openbsd denverton hardware and it s kinda hard to sustain 10Gb
of traffic


I had a request to extract the github patch file directly inside the email,
i m thinking the 17 K lines would not make sense inside the mail.

Is there someone with ixgbe hardware ( especially with a fan ? )

Best.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

ix0/1/2/3 at pci8 dev 0 function 0 "Intel X553 SFP+" rev 0x11: msi, address 00:30:18:xxxxxxx

[sven falempin]

Dear Tech reader,

I am recently working on  Intel(R) Atom(TM) CPU C3758  intel devices.
SFP Intel card are not working in 6.3/current openBSD base

I did patch intel driver reading netbsd, freebsd and intel code of ixgbe
driver.

I am now transferring data between two openBSD at ~1.50 Gb/s
for more than 48 hours ( been looping all week end )

First, i d like to find other user with ix card to check for regression !
Secondly, can i get some feedback on how to test 10Gb /s transfer
 - i usually download ramfs file through nginx or use iperf .
Third, how can i get a patch accepted into base : ie, how do i clean this
work ?

- - - - -

Patch :

17 K lines OOPS
Find the patch here : https://github.com/dohnuts/wip/blob/master/ixgbe.diff

- - - -

dmesg:

OpenBSD 6.3-stable (ACPI.MP) #10: Fri Sep 14 14:54:51 EDT 2018
root@futur:/usr/src/sys/arch/amd64/compile/ACPI.MP
real mem = 17130721280 (16337MB)
avail mem = 16604413952 (15835MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f1fc000 (18 entries)
bios0: vendor American Megatrends Inc. version "0ACHIA01" date 06/14/2018
bios0: NF699 NF699
acpi0 at bios0: rev 2
#please dont mind this
acpi0: sleep states S0 S4 S5acpi_enable: 000C, 00A0, 0010,
0001, 00B2, 15 (15), acpi_writepm: smi = 00b2: a0
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010
 check acpi_enable, PM1, , 0001, 0010, can't enable ACPI
#please dont mind this
acpi0: tables DSDT FACP FPDT FIDT MCFG WDAT APIC BDAT HPET UEFI SSDT DMAR
HEST BERT ERST EINJ WSMT
acpi0: wakeup devices PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4)
PEX6(S4) PEX7(S4) XHC1(S4) LAN0(S4) LAN1(S4) LAN2(S4) LAN3(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.41 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 2MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 2MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 8 (application processor)
cpu2: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.00 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 2MB 64b/line 16-way L2 cache
cpu2: smt 0, core 4, package 0
cpu3 at mainbus0: apid 12 (application processor)
cpu3: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.00 MHz
cpu3:

Re: Very strange condition

[sven falempin]

On Thu, Aug 9, 2018 at 10:40 AM Mark Kettenis  wrote:
>
> > From: sven falempin 
> > Date: Thu, 9 Aug 2018 10:10:14 -0400
> >
> > In ACPI.c
> >
> >
> >   if ((pm1 & ACPI_PM1_SCI_EN) == 0 && sc->sc_fadt->smi_cmd &&
> >   (!sc->sc_fadt->acpi_enable && !sc->sc_fadt->acpi_disable)) {
> >   printf(", ACPI control unavailable\n");
> >   acpi_unmap_pmregs(sc);
> >   return;
> >   }
> >
> >
> > the condition test that the sc_fadt is NOT ENABLE AND NOT DISABLE
> >
> > wut ?
>
> No.  It tests whether the magic that's needed to enable and disable is
> provided.  If both are absent it decides that the ACPI implementation
> is probably borked and bails out.
>


Me heads hurt. Yes the system is screaming at me ;-)

I m gonna see if there is multple fadt table , as rev 6 ( my hardware
is rev 6 hdr )
say they could have a 64 and 32 bits and that you must prefer the bigger one ...


Wörse diff ever enables device to reboot properly when asked

Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.341
diff -u -p -r1.341 acpi.c
--- dev/acpi/acpi.c 27 Mar 2018 21:11:16 -  1.341
+++ dev/acpi/acpi.c 9 Aug 2018 15:26:59 -
@@ -980,11 +980,18 @@ acpi_attach(struct device *parent, struc
/*
 * Find the FADT
 */
+   size_t fadt_s = sizeof(FADT_SIG) - 1;
SIMPLEQ_FOREACH(entry, >sc_tables, q_next) {
-   if (memcmp(entry->q_table, FADT_SIG,
-   sizeof(FADT_SIG) - 1) == 0) {
-   sc->sc_fadt = entry->q_table;
-   break;
+   if (memcmp(entry->q_table, FADT_SIG,fadt_s) == 0) {
+   if (sc->sc_fadt == NULL) {
+   sc->sc_fadt = entry->q_table;
+   } else {
+   struct acpi_fadt*p = entry->q_table;
+   printf(", more than one FADT old s:
%d,new s: %d\n",sc->sc_fadt->hdr_length, p->hdr_length);
+   if (sc->sc_fadt->hdr_length < p->hdr_length) {
+   sc->sc_fadt = entry->q_table;
+   }
+   }
}
}
if (sc->sc_fadt == NULL) {
@@ -999,6 +1006,8 @@ acpi_attach(struct device *parent, struc
if (sc->sc_fadt->hdr_revision >= 5 &&
sc->sc_fadt->flags & FADT_HW_REDUCED_ACPI)
sc->sc_hw_reduced = 1;
+printf(", hdr_revision %d", sc->sc_fadt->hdr_revision);
+   printf(", ACPI FATD %08X\n", sc->sc_fadt->flags);

/* Map Power Management registers */
acpi_map_pmregs(sc);
@@ -1093,7 +1102,7 @@ acpi_attach(struct device *parent, struc
if ((pm1 & ACPI_PM1_SCI_EN) == 0 && sc->sc_fadt->smi_cmd) {
if (acpi_enable(sc)) {
printf(", can't enable ACPI\n");
-   return;
+   // return;
}
}

dmesg:

OpenBSD 6.3-current (M.MP) #12: Thu Aug  9 11:11:50 EDT 2018
r...@imeee.com:/usr/src/sys/arch/amd64/compile/M .MP
real mem = 17130721280 (16337MB)
avail mem = 16604438528 (15835MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f1fc000 (18 entries)
bios0: vendor American Megatrends Inc. version "0ACHIA01" date 06/14/2018
bios0: NF699 NF699
acpi0 at bios0: rev 2, hdr_revision 6, ACPI FATD 0002C4A5

acpi0: sleep states S0 S4 S5, can't enable ACPI

acpi0: tables DSDT FACP FPDT FIDT MCFG WDAT APIC BDAT HPET UEFI SSDT
DMAR HEST BERT ERST EINJ WSMT
acpi0: wakeup devices PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4)
PEX5(S4) PEX6(S4) PEX7(S4) XHC1(S4) LAN0(S4) LAN1(S4) LAN2(S4)
LAN3(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz, 2200.43 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SENSOR,ARAT
cpu0: 2MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 25MHz
cpu0: mwait

Very strange condition

[sven falempin]

In ACPI.c


if ((pm1 & ACPI_PM1_SCI_EN) == 0 && sc->sc_fadt->smi_cmd &&
(!sc->sc_fadt->acpi_enable && !sc->sc_fadt->acpi_disable)) {
printf(", ACPI control unavailable\n");
acpi_unmap_pmregs(sc);
return;
}


the condition test that the sc_fadt is NOT ENABLE AND NOT DISABLE

wut ?

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: tables in anchor

[sven falempin]

On Thu, Jul 12, 2018 at 12:15 PM sven falempin 
wrote:

> You can add them with pftcl -a foo/bar -t new -T add something
> The table cannot be created empty ( no -T create )
> It s not possible to write in a configuration file
>
> anchor "whenitshot" {
>   table  const { 192.168/16, 10/8, 172.16/12, 169.254/16,
> 10.1.0.254/16 }
> }
>
> Was possible in 6.0 it s no more possible since 6.1.
>
> Is it a bug or an advice ?
>
>
>
PS:  Okay it was working when used inside pfctl parser like,
i assumed it was wokring in file as -f for pfctl was very similar ( in my
head )

# echo 'table  const { 192.168.0.0/16, 172.16.0.0/12, 169.254.0.0/16
}\n' | pfctl -a  "stuff/lol" -f -
[0]

not directly into a file

now :

# echo 'table  const { 192.168.0.0/16, 172.16.0.0/12, 169.254.0.0/16
}\n' | pfctl -a  "stuff/lol" -f -
stdin:1: cannot define table locals: Device busy
pfctl: Syntax error in config file: pf rules not loaded



-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

tables in anchor

[sven falempin]

You can add them with pftcl -a foo/bar -t new -T add something
The table cannot be created empty ( no -T create )
It s not possible to write in a configuration file

anchor "whenitshot" {
  table  const { 192.168/16, 10/8, 172.16/12, 169.254/16,
10.1.0.254/16 }
}

Was possible in 6.0 it s no more possible since 6.1.

Is it a bug or an advice ?

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: Timeouting the pkg_add

[sven falempin]

Thank you all, looks like it was just noise, the unused http code got me worry.

--

Short: DOH !!
Code :
/usr/libdata/perl5/OpenBSD/Paths.pm:sub ftp() { $ENV{'FETCH_CMD'} ||
'/usr/bin/ftp' }
Man :
FETCH_CMDOverride use of ftp(1).  Must point to a command that
   understands ${FETCH_CMD} -o - url.


On Thu, Jun 14, 2018 at 5:52 PM Marc Espie  wrote:
>
> On Thu, Jun 14, 2018 at 01:40:28PM -0400, sven falempin wrote:
> > Dear Tech Readers,
> >
> > In ftp command -w is available, very useful for crappy networks.
> > pkg_add does not have any of this.
> >
> > The HTTP layer is not configuring Timeout.
> > ( in /usr/libdata/perl5/OpenBSD/./PackageRepository/HTTP.pm )
> > my $o = IO::Socket::INET->new(
> > PeerHost => $host,
> > PeerPort => $port);
> > ( plenty of option here like MultiHomed or Timeout, ReuseAddr, blocking )
>
> That stuff is unused, disregard completly.
>
> > Maybe a patch can add a '-w' to pkg_add and push it there :
>
> Nope, use FETCH_CMD if necessary, and push whatever -w you need there.
>
> Note that this is documente



-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Timeouting the pkg_add

[sven falempin]

Dear Tech Readers,

In ftp command -w is available, very useful for crappy networks.
pkg_add does not have any of this.

The HTTP layer is not configuring Timeout.
( in /usr/libdata/perl5/OpenBSD/./PackageRepository/HTTP.pm )
my $o = IO::Socket::INET->new(
PeerHost => $host,
PeerPort => $port);
( plenty of option here like MultiHomed or Timeout, ReuseAddr, blocking )

Nor using an nonblocking Read later

sub get_header
{
my $o = shift;
my $l = $o->getline;
if ($l !~ m,^HTTP/1\.1\s+(\d\d\d),) {

Most usage may be used in FTP so none notice so far.

SCP and FTP are done with the actual binary, ftp handle http well and
is ready to get an option for crappy network.

Maybe a patch can add a '-w' to pkg_add and push it there :

sub ftp_cmd
{
my $self = shift;
return $self->SUPER::ftp_cmd." -S session=/dev/fd/".fileno($self->{fh});
}

And use this for all transfer ?

Or is the user supposed to manage this out of the pkg_add tool.

I can propose a patch if not *

Best.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

dhclient hw_addr savvy

[sven falempin]

With no TABS because i m an idiot

so use :%s/   /^->/g
îs CTRL+V right, and -> is TAB

Index: bpf.c
===
RCS file: /cvs/src/sbin/dhclient/bpf.c,v
retrieving revision 1.69
diff -u -p -r1.69 bpf.c
--- bpf.c   20 Sep 2017 18:28:14 -  1.69
+++ bpf.c   21 Mar 2018 17:39:09 -
@@ -115,18 +115,27 @@ struct bpf_insn dhcp_bpf_filter[] = {

/* Make sure it's a UDP packet. */
BPF_STMT(BPF_LD + BPF_B + BPF_ABS, 23),
-   BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 6),
+   BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 10),

/* Make sure this isn't a fragment. */
BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20),
-   BPF_JUMP(BPF_JMP + BPF_JSET + BPF_K, 0x1fff, 4, 0),
+   BPF_JUMP(BPF_JMP + BPF_JSET + BPF_K, 0x1fff, 8, 0),

/* Get the IP header length. */
BPF_STMT(BPF_LDX + BPF_B + BPF_MSH, 14),

/* Make sure it's to the right port. */
BPF_STMT(BPF_LD + BPF_H + BPF_IND, 16),
-   BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 67, 0, 1),  /* patch */
+   BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 67, 0, 5),  /* patch */
+
+   /* MAC zero will be replaced into Patch the server port etc*/
+   /* check bootp.hw.addr 2 bytes */
+   BPF_STMT(BPF_LD + BPF_H + BPF_IND, 50),
+BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0x, 0, 3),
+
+/* check bootp.hw.addr 4 bytes */
+BPF_STMT(BPF_LD + BPF_W + BPF_IND, 52),
+BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, 0x, 0, 1),

/* If we passed all the tests, ask for the whole packet. */
BPF_STMT(BPF_RET+BPF_K, (unsigned int)-1),
@@ -142,13 +151,6 @@ int dhcp_bpf_filter_len = sizeof(dhcp_bp
  * 'ip and udp and src port bootps and dst port (bootps or bootpc)'
  */
 struct bpf_insn dhcp_bpf_wfilter[] = {
-   BPF_STMT(BPF_LD + BPF_B + BPF_IND, 14),
-   BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, (IPVERSION << 4) + 5, 0, 12),
-
-   /* Make sure this is an IP packet. */
-   BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 12),
-   BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_IP, 0, 10),
-
/* Make sure it's a UDP packet. */
BPF_STMT(BPF_LD + BPF_B + BPF_ABS, 23),
BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 8),
@@ -178,11 +180,13 @@ struct bpf_insn dhcp_bpf_wfilter[] = {
 int dhcp_bpf_wfilter_len = sizeof(dhcp_bpf_wfilter) / sizeof(struct bpf_insn);

 int
-configure_bpf_sock(int bfdesc)
+configure_bpf_sock(int bfdesc, uint8_t * hw_address)
 {
struct bpf_version   v;
struct bpf_program   p;
int  flag = 1, sz;
+   uint32_t bits;
+   uint16_t bits16;

/* Make sure the BPF version is in range. */
if (ioctl(bfdesc, BIOCVERSION, ) == -1)
@@ -213,11 +217,16 @@ configure_bpf_sock(int bfdesc)
p.bf_insns = dhcp_bpf_filter;

/* Patch the server port into the BPF program.
+* also patch MAC
 *
 * N.B.: changes to filter program may require changes to the
 * insn number(s) used below!
 */
dhcp_bpf_filter[8].k = LOCAL_PORT;
+   memcpy(, hw_address, sizeof(bits16));
+   dhcp_bpf_filter[10].k = ntohs(bits16);
+   memcpy(, hw_address + 2, sizeof(bits));
+   dhcp_bpf_filter[12].k = ntohl(bits);

if (ioctl(bfdesc, BIOCSETF, ) == -1)
fatal("BIOCSETF");
Index: dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.565
diff -u -p -r1.565 dhclient.c
--- dhclient.c  28 Feb 2018 22:16:56 -  1.565
+++ dhclient.c  21 Mar 2018 17:39:10 -
@@ -636,7 +636,7 @@ main(int argc, char *argv[])
/* Register the interface. */
ifi->ufdesc = get_udp_sock(ifi->rdomain);
ifi->bfdesc = get_bpf_sock(ifi->name);
-   ifi->rbuf_max = configure_bpf_sock(ifi->bfdesc);
+   ifi->rbuf_max = configure_bpf_sock(ifi->bfdesc,(uint8_t
*)&(ifi->hw_address));
ifi->rbuf = malloc(ifi->rbuf_max);
if (ifi->rbuf == NULL)
fatal("bpf input buffer");
Index: dhcpd.h
===
RCS file: /cvs/src/sbin/dhclient/dhcpd.h,v
retrieving revision 1.254
diff -u -p -r1.254 dhcpd.h
--- dhcpd.h 28 Feb 2018 22:16:56 -  1.254
+++ dhcpd.h 21 Mar 2018 17:39:10 -
@@ -190,7 +190,7 @@ void parse_warn(char *);
 /* bpf.c */
 int get_bpf_sock(char *);
 int get_udp_sock(int);
-int configure_bpf_sock(int);
+int configure_bpf_sock(int, uint8_t *);
 ssize_t send_packet(struct interface_info *, struct in_addr,
 struct in_addr, const char *);
 ssize_t receive_packet(struct interface_info *,
struct sockaddr_in *,
[1]-[iBase63]-[/usr/src/sbin/dhclient]

Tested ( i just go a lease inside a rdomain 

Re: possibility to disable relink in conf

[sven falempin]

On Thu, Sep 14, 2017 at 10:26 AM, sven falempin <sven.falem...@gmail.com> wrote:
>
>
> On Wed, Sep 13, 2017 at 9:07 PM, Theo de Raadt <dera...@openbsd.org> wrote:
>>
>> > +[[ $reorder != NO ]] && /usr/libexec/reorder_kernel &
>>
>> No.  Kernels get relinked.
>>
>> if you don't like it, make your own personal changes and suffer
>> the consequences.
>>
>> We are not going to add buttons for 1 person.
>>
>> Stop suggesting changes which reduce safety.  You provided no
>> justifaction.  "Here have a diff" is a stupid process.  Ever wonder
>> why you don't have an account?  Hint: You don't discuss, you
>> don't read commit messages, you don't read our justifications,
>> you don't act in the same directions.  D.
>>
>
>
> I completly missed the
>
> library_aslr
>
> and/but  for kernel
>
> # Skip if /usr/share is on a nfs mounted filesystem.
>
> So yes, Kernels  _often_ get relinked,
> instead of being smart and guessing the NFS
> is the only problem, being to explicitly in local conf
is the only problem, being ABLE to explicitly WRITE in local conf
> droping the cool re-link would be more visible
THAT  the cool re-link  is being DROPPED ...
>
> and my diff is garbage.
>
> --
> --
> -
> The 1 %on



-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: possibility to disable relink in conf

[sven falempin]

On Wed, Sep 13, 2017 at 9:07 PM, Theo de Raadt  wrote:

> > +[[ $reorder != NO ]] && /usr/libexec/reorder_kernel &
>
> No.  Kernels get relinked.
>
> if you don't like it, make your own personal changes and suffer
> the consequences.
>
> We are not going to add buttons for 1 person.
>
> Stop suggesting changes which reduce safety.  You provided no
> justifaction.  "Here have a diff" is a stupid process.  Ever wonder
> why you don't have an account?  Hint: You don't discuss, you
> don't read commit messages, you don't read our justifications,
> you don't act in the same directions.  D.
>
>

I completly missed the

library_aslr

and/but  for kernel

# Skip if /usr/share is on a nfs mounted filesystem.

So yes, Kernels  _often_ get relinked,
instead of being smart and guessing the NFS
is the only problem, being to explicitly in local conf
droping the cool re-link would be more visible

and my diff is garbage.

-- 
--
-
The 1 %on

Re: possibility to disable relink in conf

[sven falempin]

On Wed, Sep 13, 2017 at 11:58 AM, Theo de Raadt  wrote:
> Not going to do that.
>
>> Because sometimes you run not so good device,
>> and you boot often.
>>
>> or you do not want to write on boot.
>>
>> ( attached file got the tabulation to apply )
>>
>> Index: ./etc/rc.conf
>> ===
>> RCS file: /cvs/src/etc/rc.conf,v
>> retrieving revision 1.213
>> diff -u -p -r1.213 rc.conf
>> --- ./etc/rc.conf 26 Feb 2017 16:51:18 - 1.213
>> +++ ./etc/rc.conf 13 Sep 2017 14:35:21 -
>> @@ -51,6 +51,7 @@ rarpd_flags=NO
>>  rbootd_flags=NO
>>  relayd_flags=NO
>>  rebound_flags=NO
>> +reorder= # NO to disable relink on boot
>>  ripd_flags=NO
>>  route6d_flags=NO # be sure to set net.inet6.ip6.forwarding=1
>>  rtadvd_flags=NO # for normal use: list of interfaces
>> Index: ./etc/rc
>> ===
>> RCS file: /cvs/src/etc/rc,v
>> retrieving revision 1.493
>> diff -u -p -r1.493 rc
>> --- ./etc/rc 26 Feb 2017 16:51:18 - 1.493
>> +++ ./etc/rc 13 Sep 2017 14:35:21 -
>> @@ -411,7 +411,7 @@ mount -s /var >/dev/null 2>&1
>>
>>  random_seed
>>
>> -reorder_libs
>> +[[ $reorder != NO ]] && reorder_libs $reorder
>>
>>  # Clean up left-over files.
>>  rm -f /etc/nologin /var/spool/lock/LCK.*
>>
>> --
>> --
>> 
-
>> Knowing is not enough; we must apply. Willing is not enough; we must do
>>
>> --001a113fee683ba8120559132126
>> Content-Type: application/octet-stream; name=diff
>> Content-Disposition: attachment; filename=diff
>> Content-Transfer-Encoding: base64
>> X-Attachment-Id: f_j7j4r11g0
>>
>> SW5kZXg6IC4vZXRjL3JjLmNvbmYNCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09
>> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAv
Y3ZzL3NyYy9ldGMv
>> cmMuY29uZix2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjEzDQpkaWZmIC11
IC1wIC1yMS4yMTMg
>> cmMuY29uZg0KLS0tIC4vZXRjL3JjLmNvbmYJMjYgRmViIDIwMTcgMTY6NTE6
MTggLTAwMDAJMS4y
>> MTMNCisrKyAuL2V0Yy9yYy5jb25mCTEzIFNlcCAyMDE3IDE0OjM1OjIxIC0w
MDAwDQpAQCAtNTEs
>> NiArNTEsNyBAQCByYXJwZF9mbGFncz1OTw0KIHJib290ZF9mbGFncz1OTw0K
IHJlbGF5ZF9mbGFn
>> cz1OTw0KIHJlYm91bmRfZmxhZ3M9Tk8NCityZW9yZGVyX2ZsYWdzPQkJIyBO
TyB0byBkaXNhYmxl
>> IHJlbGluayBvbiBib290DQogcmlwZF9mbGFncz1OTw0KIHJvdXRlNmRfZmxh
Z3M9Tk8JIyBiZSBz
>> dXJlIHRvIHNldCBuZXQuaW5ldDYuaXA2LmZvcndhcmRpbmc9MQ0KIHJ0YWR2
ZF9mbGFncz1OTwkJ
>> IyBmb3Igbm9ybWFsIHVzZTogbGlzdCBvZiBpbnRlcmZhY2VzDQpJbmRleDog
Li9ldGMvcmMNCj09
>> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09
>> PT09PT09PT0NClJDUyBmaWxlOiAvY3ZzL3NyYy9ldGMvcmMsdg0KcmV0cmll
dmluZyByZXZpc2lv
>> biAxLjQ5Mw0KZGlmZiAtdSAtcCAtcjEuNDkzIHJjDQotLS0gLi9ldGMvcmMJ
MjYgRmViIDIwMTcg
>> MTY6NTE6MTggLTAwMDAJMS40OTMNCisrKyAuL2V0Yy9yYwkxMyBTZXAgMjAx
NyAxNDozNToyMSAt
>> MDAwMA0KQEAgLTQxMSw3ICs0MTEsNyBAQCBtb3VudCAtcyAvdmFyID4vZGV2
L251bGwgMj4mMQ0K
>> IA0KIHJhbmRvbV9zZWVkDQogDQotcmVvcmRlcl9saWJzDQorW1sgJHJlb3Jk
ZXJfZmxhZ3MgIT0g
>> Tk8gXV0gJiYgcmVvcmRlcl9saWJzICRyZW9yZGVyX2ZsYWdzDQogDQogIyBD
bGVhbiB1cCBsZWZ0
>> LW92ZXIgZmlsZXMuDQogcm0gLWYgL2V0Yy9ub2xvZ2luIC92YXIvc3Bvb2wv
bG9jay9MQ0suKg0K
>> --001a113fee683ba8120559132126
>> Content-Type: application/octet-stream; name="diff.noflag"
>> Content-Disposition: attachment; filename="diff.noflag"
>> Content-Transfer-Encoding: base64
>> X-Attachment-Id: f_j7j4r1211
>>
>> SW5kZXg6IC4vZXRjL3JjLmNvbmYNCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09
>> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAv
Y3ZzL3NyYy9ldGMv
>> cmMuY29uZix2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjEzDQpkaWZmIC11
IC1wIC1yMS4yMTMg
>> cmMuY29uZg0KLS0tIC4vZXRjL3JjLmNvbmYJMjYgRmViIDIwMTcgMTY6NTE6
MTggLTAwMDAJMS4y
>> MTMNCisrKyAuL2V0Yy9yYy5jb25mCTEzIFNlcCAyMDE3IDE0OjM1OjIxIC0w
MDAwDQpAQCAtNTEs
>> NiArNTEsNyBAQCByYXJwZF9mbGFncz1OTw0KIHJib290ZF9mbGFncz1OTw0K
IHJlbGF5ZF9mbGFn
>> cz1OTw0KIHJlYm91bmRfZmxhZ3M9Tk8NCityZW9yZGVyPQkJIyBOTyB0byBk
aXNhYmxlIHJlbGlu
>> ayBvbiBib290DQogcmlwZF9mbGFncz1OTw0KIHJvdXRlNmRfZmxhZ3M9Tk8J
IyBiZSBzdXJlIHRv
>> IHNldCBuZXQuaW5ldDYuaXA2LmZvcndhcmRpbmc9MQ0KIHJ0YWR2ZF9mbGFn
cz1OTwkJIyBmb3Ig
>> bm9ybWFsIHVzZTogbGlzdCBvZiBpbnRlcmZhY2VzDQpJbmRleDogLi9ldGMv
cmMNCj09PT09PT09
>> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09
>> PT0NClJDUyBmaWxlOiAvY3ZzL3NyYy9ldGMvcmMsdg0KcmV0cmlldmluZyBy
ZXZpc2lvbiAxLjQ5
>> Mw0KZGlmZiAtdSAtcCAtcjEuNDkzIHJjDQotLS0gLi9ldGMvcmMJMjYgRmVi
IDIwMTcgMTY6NTE6
>> MTggLTAwMDAJMS40OTMNCisrKyAuL2V0Yy9yYwkxMyBTZXAgMjAxNyAxNDoz
NToyMSAtMDAwMA0K
>> QEAgLTQxMSw3ICs0MTEsNyBAQCBtb3VudCAtcyAvdmFyID4vZGV2L251bGwg
Mj4mMQ0KIA0KIHJh
>> bmRvbV9zZWVkDQogDQotcmVvcmRlcl9saWJzDQorW1sgJHJlb3JkZXIgIT0g
Tk8gXV0gJiYgcmVv
>> cmRlcl9saWJzICRyZW9yZGVyDQogDQogIyBDbGVhbiB1cCBsZWZ0LW92ZXIg
ZmlsZXMuDQogcm0g
>> LWYgL2V0Yy9ub2xvZ2luIC92YXIvc3Bvb2wvbG9jay9MQ0suKg0K
>> --001a113fee683ba8120559132126--
>>
>

Sorry, i did not know the stuff was sending text file like that.
The diff, from 

possibility to disable relink in conf

[sven falempin]

Because sometimes you run not so good device,
and you boot often.

or you do not want to write on boot.

( attached file got the tabulation to apply )

Index: ./etc/rc.conf
===
RCS file: /cvs/src/etc/rc.conf,v
retrieving revision 1.213
diff -u -p -r1.213 rc.conf
--- ./etc/rc.conf 26 Feb 2017 16:51:18 - 1.213
+++ ./etc/rc.conf 13 Sep 2017 14:35:21 -
@@ -51,6 +51,7 @@ rarpd_flags=NO
 rbootd_flags=NO
 relayd_flags=NO
 rebound_flags=NO
+reorder= # NO to disable relink on boot
 ripd_flags=NO
 route6d_flags=NO # be sure to set net.inet6.ip6.forwarding=1
 rtadvd_flags=NO # for normal use: list of interfaces
Index: ./etc/rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.493
diff -u -p -r1.493 rc
--- ./etc/rc 26 Feb 2017 16:51:18 - 1.493
+++ ./etc/rc 13 Sep 2017 14:35:21 -
@@ -411,7 +411,7 @@ mount -s /var >/dev/null 2>&1

 random_seed

-reorder_libs
+[[ $reorder != NO ]] && reorder_libs $reorder

 # Clean up left-over files.
 rm -f /etc/nologin /var/spool/lock/LCK.*

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do


diff
Description: Binary data


diff.noflag
Description: Binary data

trunk (roundrobin) interface unexpected behavior

[sven falempin]

Removing interface speed up the trunk .
Snapshot + pkg_add iperf
# cat /etc/rc.conf.local
pflogd_flags=NO # add more flags, e.g. "-s 256"
smtpd_flags=NO
sndiod_flags=NO

Nothing else

The network : configuration of device

one# uname -a
OpenBSD beta.test 6.2 GENERIC.MP#89 amd64
one#for v in `ls /etc/hostname.*`; do echo file:$v; cat $v; done
file:/etc/hostname.bridge0
add em0
add em5
up
file:/etc/hostname.bridge1
add trunk0
add vether1
up
file:/etc/hostname.em0
down
file:/etc/hostname.em5
dhcp
file:/etc/hostname.em7
up
file:/etc/hostname.em8
up
file:/etc/hostname.trunk0
up
trunkport em7
trunkport em8
file:/etc/hostname.vether1
rdomain 1
inet 10.0.0.2 255.0.0.0

device two is exactly the same with
file:/etc/hostname.vether1
rdomain 1
inet 10.0.0.1 255.0.0.0


two# ping -V 1 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=1.039 ms

two#route -T1 exec iperf -s

one# route -T1 exec iperf -c 10.0.0.1

Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 10.0.0.2 port 23507 connected with 10.0.0.1 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.1 sec  70.4 MBytes  58.6 Mbits/sec

Wow super slow :o

two# (iperf output server )
[  4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 17665
[ ID] Interval   Transfer Bandwidth
[  4]  0.0-10.0 sec  97.0 MBytes  81.1 Mbits/sec
[  5] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 36997
[  5]  0.0-10.0 sec   781 MBytes   655 Mbits/sec

one#ifconfig trunk0 -trunkport em7
one#route -T1 exec iperf -c 10.0.0.1

Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 10.0.0.2 port 9762 connected with 10.0.0.1 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0- 9.9 sec   770 MBytes   650 Mbits/sec

With more time the speed reach almost the expected 1 gb /s


Afaik the rdomain/vether/bridge shenenigans is just my test glu,
sorry about that.

With more interface in the trunk ( i put 5 interfaces in it  )
 the speed goes to 200Mb/s

With this two it s terrible.


Because i expect some reader to ask more,

pci0 at mainbus0 bus 0
ppb7 at pci0 dev 28 function 2 "Intel Bay Trail PCIE" rev 0x0e: msi
pci8 at ppb7 bus 8
ppb8 at pci8 dev 0 function 0 "Pericom PI7C9X2G608GP PCIE" rev 0x00
pci9 at ppb8 bus 9
ppb11 at pci9 dev 3 function 0 "Pericom PI7C9X2G608GP PCIE" rev 0x00: msi
ppb12 at pci9 dev 4 function 0 "Pericom PI7C9X2G608GP PCIE" rev 0x00: msi
pci13 at ppb12 bus 13
pci12 at ppb11 bus 12
em7 at pci12 dev 0 function 0 "Intel I210 Fiber" rev 0x03: msi,
address 00:30:18:13:41:b2
em8 at pci13 dev 0 function 0 "Intel I210 Fiber" rev 0x03: msi,
address 00:30:18:13:41:b3

and get 'amused' by all the [pci bridging]

same behavior with em1 + em8

pci0 at mainbus0 bus 0
ppb0 at pci0 dev 28 function 0 "Intel Bay Trail PCIE" rev 0x0e: msi
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Pericom PI7C9X2G608GP PCIE" rev 0x00
pci2 at ppb1 bus 2
ppb3 at pci2 dev 2 function 0 "Pericom PI7C9X2G608GP PCIE" rev 0x00: msi
pci4 at ppb3 bus 4
em1 at pci4 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:30:18:03:b8:c8

or em4

pci0 at mainbus0 bus 0
ppb6 at pci0 dev 28 function 1 "Intel Bay Trail PCIE" rev 0x0e: msi
pci7 at ppb6 bus 7
em4 at pci7 dev 0 function 0 "Intel I211" rev 0x03: msi, address
00:30:18:04:3f:b3


which perform a tiny bit better

# route -T1 exec iperf -c 10.0.0.1

Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 10.0.0.2 port 6334 connected with 10.0.0.1 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.1 sec  97.4 MBytes  81.0 Mbits/sec


I hope this help . you can ask more ( i hope i ll be able to compile
from this snap )

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: 6.2 beta snapshot , dhclient and bridge

[sven falempin]

On Tue, Sep 12, 2017 at 5:11 PM, sven falempin <sven.falem...@gmail.com>
wrote:

> Following beta snaps
>
> same setup ( one machine is a bridge for the next ) still cannot recover
> DHCP OFFER back through the bridge
>
> ( updated the bridge device)
>
> # uname -a
> OpenBSD bridgeandstuff.my.domain 6.2 GENERIC.MP#63 amd64
>
> # dhclient em5
> DHCPDISCOVER on em5 - interval 1
> DHCPDISCOVER on em5 - interval 1
> DHCPDISCOVER on em5 - interval 2
> DHCPDISCOVER on em5 - interval 4
> DHCPDISCOVER on em5 - interval 10
> DHCPDISCOVER on em5 - interval 10
> ^C
> # ifconfig em5
> em5: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:30:18:13:41:b0
> index 6 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (1000baseSX full-duplex)
> status: active
> inet 172.16.1.51 netmask 0x broadcast 172.16.255.255
> # ping 172.16.1.1
> PING 172.16.1.1 (172.16.1.1): 56 data bytes
> 64 bytes from 172.16.1.1: icmp_seq=0 ttl=255 time=0.504 ms
>
> Now updating client
> ( for trunk test on last version , currently the more the interface the
> less the speed :s )
>
>

Confirmed last snap both device

(Device one) em0 <--->  em5 ( Device Two  <--> bridge <--> ) em0 <--->

the interface em0 on the device 'two' must be down the up
for the  device 'one' to receive the OFFER


one#reboot
two#reboot
one#dhclient em5
FAILED
two#ifconfig em0 down
two#ifconfig em0 up
one#dhclient em5
SUCCESS


--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: 6.2 beta snapshot , dhclient and bridge

[sven falempin]

Following beta snaps

same setup ( one machine is a bridge for the next ) still cannot recover
DHCP OFFER back through the bridge

( updated the bridge device)

# uname -a
OpenBSD bridgeandstuff.my.domain 6.2 GENERIC.MP#63 amd64

# dhclient em5
DHCPDISCOVER on em5 - interval 1
DHCPDISCOVER on em5 - interval 1
DHCPDISCOVER on em5 - interval 2
DHCPDISCOVER on em5 - interval 4
DHCPDISCOVER on em5 - interval 10
DHCPDISCOVER on em5 - interval 10
^C
# ifconfig em5
em5: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:30:18:13:41:b0
index 6 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseSX full-duplex)
status: active
inet 172.16.1.51 netmask 0x broadcast 172.16.255.255
# ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=255 time=0.504 ms

Now updating client
( for trunk test on last version , currently the more the interface the
less the speed :s )


On Fri, Sep 1, 2017 at 2:42 PM, sven falempin <sven.falem...@gmail.com>
wrote:

> Unexpected behavior :
>
> GENERIC.MP#63 6.2 AMD64
>
> (Device one) em0 <--->  em5 ( Device Two  <--> bridge <--> ) em0 <--->
> DHCP SERVER
>
> two#: dhclient em0
> two#: ifconfig bridge0 create
> two#: ifconfig bridge0 add em5
> two#: ifconfig bridge0 add em0
> two#: ifconfig bridge0 up
>
> one#: dhclient em0
> FAILED (paquet does not come back thourgh bridge )
>
> two#: ifconfig em0 down
> two#: ifconfig vether0 create
> two#: dhclient vether0
> FAILED
>
> two#: ifconfig em0 up
> two#: dhclient vether0
> FAILED
>
> two#: ifconfig em0 down
> two#: ifconfig em0 down
> two#: dhclient vether0
> success
>
> BUT IP on em0 and vether1
>
> one# dhclient em0
> SUCCESS
>
> --
> --
> 
> -
> Knowing is not enough; we must apply. Willing is not enough; we must do
>



-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

6.2 beta snapshot , dhclient and bridge

[sven falempin]

Unexpected behavior :

GENERIC.MP#63 6.2 AMD64

(Device one) em0 <--->  em5 ( Device Two  <--> bridge <--> ) em0 <--->
DHCP SERVER

two#: dhclient em0
two#: ifconfig bridge0 create
two#: ifconfig bridge0 add em5
two#: ifconfig bridge0 add em0
two#: ifconfig bridge0 up

one#: dhclient em0
FAILED (paquet does not come back thourgh bridge )

two#: ifconfig em0 down
two#: ifconfig vether0 create
two#: dhclient vether0
FAILED

two#: ifconfig em0 up
two#: dhclient vether0
FAILED

two#: ifconfig em0 down
two#: ifconfig em0 down
two#: dhclient vether0
success

BUT IP on em0 and vether1

one# dhclient em0
SUCCESS

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

qemu vmm 6.0 / 6.1

[sven falempin]

6.1 got a firmware (ewww) for seabios

i mean this : /usr/ports/sysutils/firmware/vmm

If i compile this ports on 6.0 do i have any chance it does something right
or i am just digging my grave deeper ?

Best,


-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: caesar(6) documents incorrect frequencies

[sven falempin]

On Tue, Aug 1, 2017 at 9:49 AM, Theo de Raadt  wrote:
>> > Is it possible you've got the fix backwards?  I think ETAONRISHetc is
>> > from some well-known research, but ETSAOR* is brand new and even google
>> > cannot find a reference to that ordering.  It seems there is a bug here,
>> > but is it perhaps the other frequency table?
>>
>> I certainly don't claim to know which frequencies are more accurate.
>> Does anyone have a preferred source for which percentages to use?
>
> I suggest a google search for ETAONRISH, which leads to a handful of
> references from 1960, 1963, etc.  Of course it is only an estimate, and
> will vary between regions and countries EH?
>
> I think that frequency order is still the most accepted.
>

No ones agree,

Wikipedia : compares to < eotha sinrd luymw fgcbp kvjqxz of modern
English > ( https://en.wikipedia.org/wiki/Letter_frequency )

from: 
http://www.math.ucsd.edu/~crypto/Projects/MarshaMoreno/TimeComparisonFrequency.pdf

Note the paper from wikipedia reference talk  english and use
the bible ???

The tables can be sorted and gave : ETAOINSHR DLC ...



Meh

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: efiboot: disallow com(4) speed changes

[sven falempin]

On Wed, Mar 1, 2017 at 5:41 PM, sven falempin <sven.falem...@gmail.com>
wrote:

>
>
> On Wed, Mar 1, 2017 at 4:31 AM, Patrick Wildt <patr...@blueri.se> wrote:
>
>> Hi,
>>
>> there is no com(4) direct access support in EFI, so setting the speed
>> will fail and crash the EFI Application.  Happens when you run stty
>> com0 115200.
>>
>> ok?
>>
>> Patrick
>>
>>
>> diff --git a/sys/arch/amd64/stand/libsa/dev_i386.c
>> b/sys/arch/amd64/stand/libsa/dev_i386.c
>> index e40856cbf05..245ced84a8e 100644
>> --- a/sys/arch/amd64/stand/libsa/dev_i386.c
>> +++ b/sys/arch/amd64/stand/libsa/dev_i386.c
>> @@ -182,8 +182,10 @@ ttydev(char *name)
>>  int
>>  cnspeed(dev_t dev, int sp)
>>  {
>> +#ifndef EFIBOOT
>> if (major(dev) == 8)/* comN */
>> return comspeed(dev, sp);
>> +#endif
>>
>> /* pc0 and anything else */
>> return 9600;
>>
>>
>
> in stand boot
> stty could be disable
>
> ( diff probably got space instead of tabs , please use -b )
> Index: ./stand/boot/cmd.c
> ===
> RCS file: /cvs/src/sys/stand/boot/cmd.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 cmd.c
> --- ./stand/boot/cmd.c  20 Jul 2014 19:33:54 -  1.63
> +++ ./stand/boot/cmd.c  1 Mar 2017 22:36:11 -
> @@ -68,7 +68,9 @@ const struct cmd_table cmd_table[] = {
>  #endif
> {"reboot", CMDT_CMD, Xreboot},
> {"set",CMDT_SET, Xset},
> +#ifndef EFIBOOT
> {"stty",   CMDT_CMD, Xstty},
> +#endif
> {"time",   CMDT_CMD, Xtime},
> {NULL, 0},
>  };
>
>
> Alternatively the function could document the problem ( but it make the
> boot loader bigger
>
>
> Index: ./stand/boot/cmd.c
> ===
> RCS file: /cvs/src/sys/stand/boot/cmd.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 cmd.c
> --- ./stand/boot/cmd.c  20 Jul 2014 19:33:54 -  1.63
> +++ ./stand/boot/cmd.c  1 Mar 2017 22:39:23 -
> @@ -375,6 +375,11 @@ Xstty(void)
> char *cp;
> dev_t dev;
>
> +#ifndef EFIBOOT
> +   printf("no com(4) direct access support in EFI");
> +   return 0;
> +#endif
> +
> if (cmd.argc == 1) {
> printf("%s speed is %d\n", ttyname(0), cnspeed(0, -1));
> return 0;
>
> Maybe a better way ?
>
>
return 0 in the function if we are in EFI mode, of course

Index: ./stand/boot/cmd.c
===
RCS file: /cvs/src/sys/stand/boot/cmd.c,v
retrieving revision 1.63
diff -u -p -r1.63 cmd.c
--- ./stand/boot/cmd.c  20 Jul 2014 19:33:54 -  1.63
+++ ./stand/boot/cmd.c  1 Mar 2017 22:39:23 -
@@ -375,6 +375,11 @@ Xstty(void)
char *cp;
dev_t dev;

+#ifdef EFIBOOT
+   printf("no com(4) direct access support in EFI");
+   return 0;
+#endif
+
if (cmd.argc == 1) {
printf("%s speed is %d\n", ttyname(0), cnspeed(0, -1));
return 0;

-- 

-
() ascii ribbon campaign - against html e-mail
/\

Re: efiboot: disallow com(4) speed changes

[sven falempin]

On Wed, Mar 1, 2017 at 4:31 AM, Patrick Wildt  wrote:

> Hi,
>
> there is no com(4) direct access support in EFI, so setting the speed
> will fail and crash the EFI Application.  Happens when you run stty
> com0 115200.
>
> ok?
>
> Patrick
>
>
> diff --git a/sys/arch/amd64/stand/libsa/dev_i386.c
> b/sys/arch/amd64/stand/libsa/dev_i386.c
> index e40856cbf05..245ced84a8e 100644
> --- a/sys/arch/amd64/stand/libsa/dev_i386.c
> +++ b/sys/arch/amd64/stand/libsa/dev_i386.c
> @@ -182,8 +182,10 @@ ttydev(char *name)
>  int
>  cnspeed(dev_t dev, int sp)
>  {
> +#ifndef EFIBOOT
> if (major(dev) == 8)/* comN */
> return comspeed(dev, sp);
> +#endif
>
> /* pc0 and anything else */
> return 9600;
>
>

in stand boot
stty could be disable

( diff probably got space instead of tabs , please use -b )
Index: ./stand/boot/cmd.c
===
RCS file: /cvs/src/sys/stand/boot/cmd.c,v
retrieving revision 1.63
diff -u -p -r1.63 cmd.c
--- ./stand/boot/cmd.c  20 Jul 2014 19:33:54 -  1.63
+++ ./stand/boot/cmd.c  1 Mar 2017 22:36:11 -
@@ -68,7 +68,9 @@ const struct cmd_table cmd_table[] = {
 #endif
{"reboot", CMDT_CMD, Xreboot},
{"set",CMDT_SET, Xset},
+#ifndef EFIBOOT
{"stty",   CMDT_CMD, Xstty},
+#endif
{"time",   CMDT_CMD, Xtime},
{NULL, 0},
 };


Alternatively the function could document the problem ( but it make the
boot loader bigger


Index: ./stand/boot/cmd.c
===
RCS file: /cvs/src/sys/stand/boot/cmd.c,v
retrieving revision 1.63
diff -u -p -r1.63 cmd.c
--- ./stand/boot/cmd.c  20 Jul 2014 19:33:54 -  1.63
+++ ./stand/boot/cmd.c  1 Mar 2017 22:39:23 -
@@ -375,6 +375,11 @@ Xstty(void)
char *cp;
dev_t dev;

+#ifndef EFIBOOT
+   printf("no com(4) direct access support in EFI");
+   return 0;
+#endif
+
if (cmd.argc == 1) {
printf("%s speed is %d\n", ttyname(0), cnspeed(0, -1));
return 0;

Maybe a better way ?

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: sleep.1: "while true;" -> "while :;"

[sven falempin]

On Tue, Dec 20, 2016 at 5:49 PM, Jason McIntyre  wrote:

> On Tue, Dec 20, 2016 at 10:58:40PM +0100, Michal Mazurek wrote:
> > While there is nothing wrong with "while true", "while :" is better
> > and used a lot more often in the source tree.
> >
> > OK?
> >
>
> i'm not sure why "while :" is better in this example, but "while true"
> is clearer, i think. allowing for differences in preference, is their a
> good reason to change what's there?
>
> jmc
>
> > Index: bin/sleep/sleep.1
> > ===
> > RCS file: /cvs/src/bin/sleep/sleep.1,v
> > retrieving revision 1.22
> > diff -u -p -r1.22 sleep.1
> > --- bin/sleep/sleep.1 16 Aug 2016 18:51:25 -  1.22
> > +++ bin/sleep/sleep.1 20 Dec 2016 21:46:07 -
> > @@ -94,7 +94,7 @@ job.
> >  .Pp
> >  To monitor the growth of a file without consuming too many resources:
> >  .Bd -literal -offset indent
> > -while true; do
> > +while :; do
> >   ls -l file
> >   sleep 5
> >  done
> >
> > --
> > Michal Mazurek
> >
>
>
Thanks,

i did not know a ksh nop was a thing.

I tend to agree with jmc,

void* p = NULL;
if (p) is neat but not clear like , if ( p != NULL )

as jw013 said:

I agree. true for a condition, : for a NOP. – jw013 *

*
http://unix.stackexchange.com/questions/37473/what-is-the-utility-of-the-command-in-shell-scripting-given-that-it-explicitl


-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: mounting tmpfs ???

[sven falempin]

On Wed, Dec 14, 2016 at 7:02 PM, Martin Schröder <mar...@oneiros.de> wrote:

> 2016-12-14 17:07 GMT+01:00 sven falempin <sven.falem...@gmail.com>:
> > i am using this daily, what can i do !?
>
> maintain tmpfs
>
> Best
>Martin
>
>
So  fixing the BUG section of the man page ?

-- 

-
() ascii ribbon campaign - against html e-mail
/\

Re: mounting tmpfs ???

[sven falempin]

On Wed, Dec 14, 2016 at 10:51 AM, Stuart Henderson <s...@spacehopper.org>
wrote:

> On 2016/12/14 10:44, sven falempin wrote:
> > [130]-[~]
> > # ktrace mount_tmpfs -s20M tmpfs /foo
> > mount_tmpfs: tmpfs on /foo: Operation not supported
> > [1]-[~]
> > # ls -ld /foo
> > drwxr-xr-x  2 root  wheel  512 Dec 14 16:26 /foo
>
> 
> revision 1.229
> date: 2016/07/25 19:52:56;  author: deraadt;  state: Exp;  lines: +2 -2;
> commit
> id: SKJd8VyGOLxZLj1g;
> disable tmpfs because it receives zero maintainance.
> 
>
>
Okay,

i am using this daily, what can i do !?
besides compiling my own 'unsuported' kernel . . .

Cheers

-- 
-
() ascii ribbon campaign - against html e-mail
/\

mounting tmpfs ???

[sven falempin]

[130]-[~]
# ktrace mount_tmpfs -s20M tmpfs /foo
mount_tmpfs: tmpfs on /foo: Operation not supported
[1]-[~]
# ls -ld /foo
drwxr-xr-x  2 root  wheel  512 Dec 14 16:26 /foo


trace:

  6289 mount_tmpfs CALL  lstat(0x7f7d9810,0x7f7d89f0)
  6289 mount_tmpfs NAMI  "/foo"
  6289 mount_tmpfs STRU  struct stat { dev=1024, ino=1974784,
mode=drwxr-xr-x , nlink=2, uid=0<"root">, gid=0<"wheel">, rdev=7880112,
atime=1481729169<"Dec 14 16:26:09 2016">.100496580, mtime=1481729169<"Dec
14 16:26:09 2016">.100496580, ctime=1481729169<"Dec 14 16:26:09
2016">.100496580, size=512, blocks=4, blksize=16384, flags=0x0,
gen=0xd76f1232 }
  6289 mount_tmpfs RET   lstat 0
  6289 mount_tmpfs CALL  stat(0x7f7d9810,0x7f7d9700)
  6289 mount_tmpfs NAMI  "/foo"
  6289 mount_tmpfs STRU  struct stat { dev=1024, ino=1974784,
mode=drwxr-xr-x , nlink=2, uid=0<"root">, gid=0<"wheel">, rdev=7880112,
atime=1481729169<"Dec 14 16:26:09 2016">.100496580, mtime=1481729169<"Dec
14 16:26:09 2016">.100496580, ctime=1481729169<"Dec 14 16:26:09
2016">.100496580, size=512, blocks=4, blksize=16384, flags=0x0,
gen=0xd76f1232 }
  6289 mount_tmpfs RET   stat 0
  6289 mount_tmpfs CALL
 mount(0x1c632902c204,0x7f7d9810,0<>0,0x7f7d97e0)
  6289 mount_tmpfs NAMI  "/foo"
  6289 mount_tmpfs RET   mount -1 errno 45 Operation not supported

dmesg :

OpenBSD 6.0 (GENERIC.MP) #2: Mon Oct 17 10:22:47 CEST 2016
r...@stable-60-amd64.mtier.org:
/binpatchng/work-binpatch60-amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8371699712 (7983MB)
avail mem = 8113508352 (7737MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6250 (11 entries)
bios0: vendor SeaBIOS version "Ubuntu-1.8.2-1ubuntu1~cloud0+ovh1" date
04/01/2014
bios0: OpenStack Foundation OpenStack Nova
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel Core Processor (Haswell, no TSX), 2394.79 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel Core Processor (Haswell, no TSX), 2394.52 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: smt 0, core 0, package 1
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
"ACPI0006" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel
0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int
9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address fa:16:3e:32:60:4e
virtio0: msix shared
virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 40960MB, 512 bytes/sector, 83886080 sectors

Re: reloading pf through ansible easy hook

[sven falempin]

On Mon, Nov 21, 2016 at 5:48 PM, Antoine Jacoutot <ajacou...@bsdfrog.org> wrote:
>
> On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote:
> > Ansible is already managing pkg and service of openBSD , cool
> >
> > If one want to manage pf with it, and push or modify a few files,
> > on must run - command: /sbin/pfctl -f {{ dank.config }}
> >
> > Yet - service could be use, if this glue was in the rc.d directory :
>
> You can easily create an ansible role|module to do that natively.
> The rc.d framework is only meant to handle real daemons.
> We don't want it to manage pf, quota, network, mounts...
>
> --
> Antoine

I see your point and agree, OTH
and not for the sake of arguing,

PF is inside rc.conf , so rcctl manages it, so rc.d
could have a relation.

So YES there is only daemon in rc.d NOW
but not in rc.conf.

Cheers

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: Enabling rasops24

[sven falempin]

Tested here and it works ! @OK

The terminal is white on red for first part of boot then goes back to white
on
blue.
Also some kind of flicker/bufering during the start,
aftfer the kernel loading no update for like half a second.

But it s booting completly :

i got some
dmesg: sysctl: KERN_MSGBUF: Cannot allocate memmory.
probably related to my  tree i used to compile the kernel with the
option
rasops24

( QEMU emulator version 2.6.0, with OVMF Bios, OpenBSD directly on phyical
hard drive )



On Tue, Aug 30, 2016 at 12:49 PM, YASUOKA Masahiko 
wrote:

> Enabling rasops24 in files.amd64 makes QEMU with UEFI start working.
>
> But.. the background color of the kernel message is sometimes red or
> green where it should be blue.
>
> ok for files.amd64?
> comments for the color problem?
>
> Index: sys/arch/amd64/conf/files.amd64
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/files.amd64,v
> retrieving revision 1.85
> diff -u -p -r1.85 files.amd64
> --- sys/arch/amd64/conf/files.amd64 8 Jan 2016 15:54:13 -
>  1.85
> +++ sys/arch/amd64/conf/files.amd64 30 Aug 2016 16:38:19 -
> @@ -109,7 +109,7 @@ filearch/amd64/amd64/ioapic.c
>  ioapic n
>  #
>  # EFI Framebuffer
>  #
> -device efifb: wsemuldisplaydev, rasops32, rasops16, rasops8, rasops4
> +device efifb: wsemuldisplaydev, rasops32, rasops24, rasops16, rasops8,
> rasops4
>  attach efifb at mainbus
>  file arch/amd64/amd64/efifb.c  efifb needs-flag
>
>
>


-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: ksh tab completion: ^_: unexpected `^'

[sven falempin]

This does not include UTF8 basic character,

so if someone do  

And it want to do it again for that file ... sviňák , does not work.

This problem should be address in isalnum, i guess, i think some c++
lib did it already,
and i have a headache everytime i want to use \w in a regexp.

current $ ./a.out élol
NOP
_
~
current $ ./a.out elol
elol_
~
current $ cat /tmp/foo.c
#include 

int main(int argc, char** argv) {
  if (isalnum(argv[1][0] )) printf("%s", argv[1]); else printf ("NOP\n");
}

On Thu, Sep 8, 2016 at 6:08 AM, Stuart Henderson  wrote:
> On 2016/09/08 10:45, Nicholas Marriott wrote:
>> Yeah we probably shouldn't bother to look for commands that aren't 
>> [A-Za-z0-9_-]:
>
> I don't think - is necessary, it's not a valid character for an array
> name so it can't be used here anyway. Otherwise OK.
>
>> Index: edit.c
>> ===
>> RCS file: /cvs/src/bin/ksh/edit.c,v
>> retrieving revision 1.56
>> diff -u -p -r1.56 edit.c
>> --- edit.c7 Sep 2016 04:42:31 -   1.56
>> +++ edit.c8 Sep 2016 09:45:21 -
>> @@ -584,9 +584,8 @@ x_try_array(const char *buf, int buflen,
>>  int *nwords, char ***words)
>>  {
>>   const char *cmd, *cp;
>> - int cmdlen, n;
>> + int cmdlen, n, i, slen;
>>   char *name, *s;
>> - size_t slen;
>>   struct tbl *v, *vp;
>>
>>   *nwords = 0;
>> @@ -604,6 +603,10 @@ x_try_array(const char *buf, int buflen,
>>   cmdlen = 0;
>>   while (cmd + cmdlen < want && !isspace((u_char)cmd[cmdlen]))
>>   cmdlen++;
>> + for (i = 0; i < cmdlen; i++) {
>> + if (!isalnum((u_char)cmd[i]) && cmd[i] != '_' && cmd[i] != '-')
>> + return 0;
>> + }
>>
>>   /* Take a stab at argument count from here. */
>>   n = 1;
>>
>>
>> On Thu, Sep 08, 2016 at 09:43:53AM +0100, Stuart Henderson wrote:
>> > I just ran into this which was introduced with custom completions
>> > (I haven't setup any complete_* arrays).
>> >
>> > $ ag "(foo)[^_]" /u
>> >
>> > results in
>



-- 
-
() ascii ribbon campaign - against html e-mail
/\

Perl HTTP Tiny non configurable Timeout

[sven falempin]

Base perl got a deprecated HTTP Tiny code (0.29),
one can use a package but base may enjoy the correction
around or a better one.

# Annoyingly IO::Socket's connect() is where the timeout logic is

Index: IP.pm
===
RCS file: /cvs/src/gnu/usr.bin/perl/cpan/IO-Socket-IP/lib/IO/Socket/IP.pm,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 IP.pm
--- IP.pm 17 Nov 2014 20:52:48 - 1.1.1.1
+++ IP.pm 5 Aug 2016 20:53:17 -
@@ -1,13 +1,13 @@
 #  You may distribute under the terms of either the GNU General Public
License
 #  or the Artistic License (the same terms as Perl itself)
 #
-#  (C) Paul Evans, 2010-2014 -- leon...@leonerd.org.uk
+#  (C) Paul Evans, 2010-2015 -- leon...@leonerd.org.uk

 package IO::Socket::IP;
 # $VERSION needs to be set before  use base 'IO::Socket'
 #  - https://rt.cpan.org/Ticket/Display.html?id=92107
 BEGIN {
-   $VERSION = '0.29';
+   $VERSION = '0.38';
 }

 use strict;
@@ -31,7 +31,7 @@ use Socket 1.97 qw(
 my $AF_INET6 = eval { Socket::AF_INET6() }; # may not be defined
 my $AI_ADDRCONFIG = eval { Socket::AI_ADDRCONFIG() } || 0;
 use POSIX qw( dup2 );
-use Errno qw( EINVAL EINPROGRESS EISCONN );
+use Errno qw( EINVAL EINPROGRESS EISCONN ENOTCONN ETIMEDOUT EWOULDBLOCK );

 use constant HAVE_MSWIN32 => ( $^O eq "MSWin32" );

@@ -265,6 +265,22 @@ If true, set the C sockopt

 If true, set the C sockopt

+=item Sockopts => ARRAY
+
+An optional array of other socket options to apply after the three listed
+above. The value is an ARRAY containing 2- or 3-element ARRAYrefs. Each
inner
+array relates to a single option, giving the level and option name, and an
+optional value. If the value element is missing, it will be given the
value of
+a platform-sized integer 1 constant (i.e. suitable to enable most of the
+common boolean options).
+
+For example, both options given below are equivalent to setting
C.
+
+ Sockopts => [
+[ SOL_SOCKET, SO_REUSEADDR ],
+[ SOL_SOCKET, SO_REUSEADDR, pack( "i", 1 ) ],
+ ]
+
 =item V6Only => BOOL

 If defined, set the C sockopt when creating C
sockets
@@ -304,6 +320,22 @@ If defined but false, the socket will be
 it will default to blocking mode. See the NON-BLOCKING section below for
more
 detail.

+=item Timeout => NUM
+
+If defined, gives a maximum time in seconds to block per C call
+when in blocking mode. If missing, no timeout is applied other than that
+provided by the underlying operating system. When in non-blocking mode this
+parameter is ignored.
+
+Note that if the hostname resolves to multiple address candidates, the same
+timeout will apply to each connection attempt individually, rather than to
the
+operation as a whole. Further note that the timeout does not apply to the
+initial hostname resolve operation, if connecting by hostname.
+
+This behviour is copied inspired by C; for more fine
grained
+control over connection timeouts, consider performing a nonblocking connect
+directly.
+
 =back

 If neither C nor C hints are provided, a default of
@@ -380,6 +412,12 @@ sub _io_socket_ip__configure
my @localinfos;
my @peerinfos;

+   my $listenqueue = $arg->{Listen};
+   if( defined $listenqueue and
+   ( defined $arg->{PeerHost} || defined $arg->{PeerService} ||
defined $arg->{PeerAddrInfo} ) ) {
+  croak "Cannot Listen with a peer address";
+   }
+
if( defined $arg->{GetAddrInfoFlags} ) {
   $hints{flags} = $arg->{GetAddrInfoFlags};
}
@@ -425,11 +463,17 @@ sub _io_socket_ip__configure
   ref $info eq "ARRAY" or croak "Expected 'LocalAddrInfo' to be an
ARRAY ref";
   @localinfos = @$info;
}
-   elsif( defined $arg->{LocalHost} or defined $arg->{LocalService} ) {
+   elsif( defined $arg->{LocalHost} or
+  defined $arg->{LocalService} or
+  HAVE_MSWIN32 and $arg->{Listen} ) {
   # Either may be undef
   my $host = $arg->{LocalHost};
   my $service = $arg->{LocalService};

+  unless ( defined $host or defined $service ) {
+ $service = 0;
+  }
+
   local $1; # Placate a taint-related bug; [perl #67962]
   defined $service and $service =~ s/\((\d+)\)$// and
  my $fallback_port = $1;
@@ -476,14 +520,27 @@ sub _io_socket_ip__configure
   }
}

+   my $INT_1 = pack "i", 1;
+
my @sockopts_enabled;
-   push @sockopts_enabled, SO_REUSEADDR if $arg->{ReuseAddr};
-   push @sockopts_enabled, SO_REUSEPORT if $arg->{ReusePort};
-   push @sockopts_enabled, SO_BROADCAST if $arg->{Broadcast};
+   push @sockopts_enabled, [ SOL_SOCKET, SO_REUSEADDR, $INT_1 ] if
$arg->{ReuseAddr};
+   push @sockopts_enabled, [ SOL_SOCKET, SO_REUSEPORT, $INT_1 ] if
$arg->{ReusePort};
+   push @sockopts_enabled, [ SOL_SOCKET, SO_BROADCAST, $INT_1 ] if
$arg->{Broadcast};
+
+   if( my $sockopts = $arg->{Sockopts} ) {
+  ref $sockopts eq "ARRAY" or croak "Expected 'Sockopts' to be an
ARRAY ref";
+  foreach ( @$sockopts ) {
+ ref $_ eq "ARRAY" or croak "Bad Sockopts item - 

Re: pf.conf macro with space

[sven falempin]

On Tue, Jun 21, 2016 at 8:30 AM, Stefan Sperling  wrote:

> On Tue, Jun 21, 2016 at 01:11:16PM +0200, Henning Brauer wrote:
> > however, the ruleset in this case does NOT load.
> >   $ echo '"a macro with spaces"="foo"\npass from $a\
> macro\ with\ spaces"' | pfctl -nvf -
> > a macro with spaces = "foo"
> > stdin:2: macro 'a' not defined
> > stdin:2: syntax error
>
> Ah, good. I tested with just a macro definition, but not use.
>
>
I have explain the use of spaced macro,
a config file that is self explanatory.

I've been around a while, and i saw a lot of effort
making configuration file clean and meaningful.
A recent example is the doas.conf file.

A parsing tool is not like hacking into an advanced kernel
feature with unexpected side effect, so the feature of fully
handling macro is
 * not an hassle
 * a plus, as you can define element in a more clear way
 * not a risk


BTW,
There s better way to change the parse.y to kill the space,
not using STRING.
It s in the samples of the lexer, for c code.

I hope someone will help the case for spaces in macro.

Cheers.

-- 
-
() ascii ribbon campaign - against html e-mail
/\

pf.conf macro with space

[sven falempin]

Dear Tech Readers,

in a pf.conf file one can do
"silly things" = egress

as defined in parse.y like

varset  : STRING '=' varstring  {
if (pf->opts & PF_OPT_VERBOSE)
printf("%s = \"%s\"\n", $1, $3);
if (symset($1, $3, 0) == -1)
err(1, "cannot store variable %s", $1);
free($1);
free($3);
}

and because it s better to triple check
$ cat /tmp/pf.lol.conf
karate = egress
"kar ra tei" = egress
pass on $kar\ ra\ tei
$ pfctl -nf /tmp/pf.lol.conf
/tmp/pf.lol.conf:3: macro 'kar' not defined
/tmp/pf.lol.conf:3: syntax error

i also tried the bash ${hope} or makefile $(madness) and even $"sillyness"

I also remember that being able to read a config file with ease can save a
lot of time

"Third Floor Network Switch" = em8
pass quick on $"Third Floor Network Switch" from www.openbsd.org to
($"Third Floor Network Switch":network) set prio (7,7)

I was wondering why it refused such and read the code,
fount out a lgetc function is used to read string, and first argument is
explicit and is a switch to manage quoted string,
so why not using it after the $macro ?

--- ./parse.y   Tue Apr 21 12:34:59 2015
+++ /tmp/1  Mon Jun 20 17:04:08 2016
@@ -5179,7 +5179,7 @@
; /* nothing */
if (c == '$' && parsebuf == NULL) {
while (1) {
-   if ((c = lgetc(0)) == EOF)
+   if ((c = lgetc(1)) == EOF)
return (0);

if (p + 1 >= buf + sizeof(buf) - 1) {

of course it s not that simple as the code below show, this one works,
the previous does not.
 :

Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.648
diff -u -r1.648 parse.y
--- parse.y 21 Apr 2015 16:34:59 -  1.648
+++ parse.y 20 Jun 2016 21:36:29 -
@@ -5178,22 +5178,55 @@
while ((c = lgetc(0)) != '\n' && c != EOF)
; /* nothing */
if (c == '$' && parsebuf == NULL) {
-   while (1) {
-   if ((c = lgetc(0)) == EOF)
-   return (0);
-
-   if (p + 1 >= buf + sizeof(buf) - 1) {
-   yyerror("string too long");
-   return (findeol());
-   }
-   if (isalnum(c) || c == '_') {
+   if ((c = lgetc(0)) == '"') {
+   quotec = c;
+   while (1) {
+   if ((c = lgetc(quotec)) == EOF)
+   return (0);
+   if (c == '\n') {
+   file->lineno++;
+   continue;
+   } else if (c == '\\') {
+   if ((next = lgetc(quotec)) == EOF)
+   return (0);
+   if (next == quotec || c == ' ' || c
== '\t')
+   c = next;
+   else if (next == '\n') {
+   file->lineno++;
+   continue;
+   } else
+   lungetc(next);
+   } else if (c == quotec) {
+   *p = '\0';
+   break;
+   } else if (c == '\0') {
+   yyerror("syntax error");
+   return (findeol());
+   }
+   if (p + 1 >= buf + sizeof(buf) - 1) {
+   yyerror("string too long");
+   return (findeol());
+   }
*p++ = c;
-   continue;
}
-   *p = '\0';
-   lungetc(c);
-   break;
-   }
+   } else
+   while (1) {
+   if ((c = lgetc(0)) == EOF)
+   return (0);
+
+   if (p + 1 >= buf + sizeof(buf) - 1) {
+   yyerror("string too long");
+   return (findeol());
+   }
+
+   if (isalnum(c) || c == '_') {
+   *p++ = c;
+   

Re: current trunk is not accepting tun / link0

[sven falempin]

On Fri, May 6, 2016 at 3:27 PM, Stuart Henderson <s...@spacehopper.org>
wrote:

> On 2016/05/06 15:19, sven falempin wrote:
> > Claudio Jeker : 10 years ago
> > ...
> > trunk(4) works only over ethernet devices (more precisely IEEE802 based
> > interfaces). This includes wireless devices but neither of gif, gre or
> > pppoe. tun(4) in layer 2 mode works while a "normal" tun(4) will not.
> >
> > Looks like it s broken on layer 2 tun.
>
> Layer 2 tun has been replaced. See the release notes and upgrade guide.
>

Does that mean link0 is completly useless now ? (because i can ifconfig
tapX link0)

Also looks like openvpn does not UP the tap interface.

Anyone checked ?

-- 
-
() ascii ribbon campaign - against html e-mail
/\

current trunk is not accepting tun / link0

[sven falempin]

Claudio Jeker : 10 years ago
...
trunk(4) works only over ethernet devices (more precisely IEEE802 based
interfaces). This includes wireless devices but neither of gif, gre or
pppoe. tun(4) in layer 2 mode works while a "normal" tun(4) will not.

Looks like it s broken on layer 2 tun.

# uname -a
OpenBSD current 5.9 GENERIC.MP#2004 amd64
[0]-[current]-[~]
# ifconfig tun1
tun1: flags=9051 mtu 1500
index 81 priority 0
groups: tun
status: active
[0]-[current]-[~]
# ifconfig trunk0 trunkport em7
ifconfig: SIOCSTRUNKPORT: Invalid argument
[1]-[current]-[~]
# ifconfig trunk0 trunkport tun1
ifconfig: SIOCSTRUNKPORT: Protocol not supported
[1]-[current]-[~]
# ifconfig em1 up
[0]-[current]-[~]
# ifconfig trunk0 trunkport em1
[0]-[current]-[~]
#



--
-
() ascii ribbon campaign - against html e-mail
/\

Re: Print ifindex in ifconfig(8)

[sven falempin]

On Tue, Apr 12, 2016 at 8:18 AM, Claudio Jeker 
wrote:

> On Tue, Apr 12, 2016 at 01:47:53PM +0200, Stefan Sperling wrote:
> > On Tue, Apr 12, 2016 at 12:27:10PM +0100, Stuart Henderson wrote:
> > > On 2016/04/12 13:00, Martin Pieuchot wrote:
> > > > Relying on the "scopeid" field is not a viable long-term solution.
> I'm
> > > > spending too much time these days trying to figure out which
> interface
> > > > correspond to which index.
> > > >
> > > > Here's a difference in output, then the diff itself.  ok?
> > > >
> > > > @@ -1,31 +1,29 @@
> > > >  lo0: flags=8049 mtu 32768
> > > > + index 4
> > > >   priority: 0
> > > >   groups: lo
> > > >   inet6 ::1 prefixlen 128
> > > >   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
> > > >   inet 127.0.0.1 netmask 0xff00
> > > >  em0:
> flags=18b43
> mtu 1500
> > > > - lladdr f0:de:f9:1d:88:53
> > > > + index 1 lladdr f0:de:f9:1d:88:53
> > >
> > > This will break scripts, e.g. "awk '/lladdr/ {print $2}'"
> > >
> > > I would expect putting it after lladdr would be better for the sort
> > > of scripts a user is likely to write, but bsd.rd would need a change
> > > if that was done, it uses sed 's/.*lladdr \(.*\)/\1/p;d'
> > >
> > > On a new line would be safer.
> >
> > How about appending to the flags line, like this?
> >
> > lo0: flags=8049 mtu 32768 index 4
> >
>
> Or on the line with priority? The risk of breaking scripts that way is
> probably smaller.
>
> --
> :wq Claudio
>
>
my 2 cents:

new line please, or only with an option like -vv
so you can alias it and no one see it, but you.

still advocating for a structured output of system commands like ifconfig
-json,
new scripts  would be able to manage those changes better.

-- 
-
() ascii ribbon campaign - against html e-mail
/\

corner network case revealing unexpected behavior

[sven falempin]

Using 5.9 + openup , amd64 base config

Assuming two interface s
em1 and em5
and a configuration interconnecting interfaces like this
vether10 10.1.2.10 rdomain 10 <--> bridge10 <--> vlan1010 vlan 10<-> em1
<--cable
cable-> em5 <--> vlan1020 vlan 10 <--> bridge50 <--> vether50 10.1.2.50
rdomain 50

Only by tcpdumping em1 the ping will go trhough:
(notice the kill pid of tcpdump in the middle, when icmp_seq=3  second ping)

# route -T10 exec ping -I 10.1.2.10 10.1.2.50
PING 10.1.2.50 (10.1.2.50): 56 data bytes
64 bytes from 10.1.2.50: icmp_seq=0 ttl=255 time=0.716 ms
64 bytes from 10.1.2.50: icmp_seq=1 ttl=255 time=0.457 ms
64 bytes from 10.1.2.50: icmp_seq=2 ttl=255 time=0.558 ms
64 bytes from 10.1.2.50: icmp_seq=3 ttl=255 time=0.977 ms
64 bytes from 10.1.2.50: icmp_seq=4 ttl=255 time=0.958 ms
--- 10.1.2.50 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.457/0.733/0.977/0.208 ms
# ps axww | grep em1
29673 p0- Sp  0:00.16 tcpdump -tteni em1
 5502 p1  R+  0:00.00 grep em1
# route -T10 exec ping -I 10.1.2.10 10.1.2.50&
[1] 32168
# PING 10.1.2.50 (10.1.2.50): 56 data bytes
64 bytes from 10.1.2.50: icmp_seq=0 ttl=255 time=0.344 ms
64 bytes from 10.1.2.50: icmp_seq=1 ttl=255 time=0.922 ms
64 bytes from 10.1.2.50: icmp_seq=2 ttl=255 time=1.024 ms
k64 bytes from 10.1.2.50: icmp_seq=3 ttl=255 time=0.489 ms
ill64 bytes from 10.1.2.50: icmp_seq=4 ttl=255 time=0.981 ms
 64 bytes from 10.1.2.50: icmp_seq=5 ttl=255 time=0.463 ms
64 bytes from 10.1.2.50: icmp_seq=6 ttl=255 time=0.988 ms
264 bytes from 10.1.2.50: icmp_seq=7 ttl=255 time=0.949 ms
964 bytes from 10.1.2.50: icmp_seq=8 ttl=255 time=0.473 ms
673
# fg
route -T10 exec ping -I 10.1.2.10 10.1.2.50
--- 10.1.2.50 ping statistics ---
22 packets transmitted, 9 packets received, 59.1% packet loss
round-trip min/avg/max/std-dev = 0.344/0.737/1.024/0.268 ms
#

--

function madconfig {
ifconfig vether10 10.1.2.10 rdomain 10
ifconfig vether50 10.1.2.50 rdomain 50
ifconfig bridge10 create
ifconfig bridge50 create
ifconfig vlan1010 vlan 10 vlandev $1
ifconfig vlan1050 vlan 10 vlandev $2
ifconfig bridge10 add vlan1010 add vether10
ifconfig bridge50 add vlan1050 add vether50
for v in vether10 vether50  vlan1010  vlan1050  bridge10  bridge50 $1 $2
do
  ifconfig $v up
done
}

function madtest {
  route -T10 exec ping -I 10.1.2.10 10.1.2.50 &
  sleep 3
  tcpdump -tteni $1
}

madconfig em1 em5
madtest  em1

--
using this you could with a bit of play around see ,
ping may not work unless you remove add vlan interface from bridge (having
them up before insertion may be the source of that)

# tcpdump -tteni em1
tcpdump: listening on em1, link-type EN10MB
^C
0 packets received by filter
0 packets dropped by kernel
# ifconfig bridge10 add vlan1010
# tcpdump -tteni em1
tcpdump: listening on em1, link-type EN10MB
1459545383.791862 fe:e1:ba:d0:f8:45 fe:e1:ba:d1:89:9d 8100 102: 802.1Q vid
10 pri 3 10.1.2.10 > 10.1.2.50: icmp: echo request
1459545384.786795 fe:e1:ba:d0:f8:45 fe:e1:ba:d1:89:9d 8100 102: 802.1Q vid
10 pri 3 10.1.2.10 > 10.1.2.50: icmp: echo request
1459545385.791786 fe:e1:ba:d0:f8:45 fe:e1:ba:d1:89:9d 8100 102: 802.1Q vid
10 pri 3 10.1.2.10 > 10.1.2.50: icmp: echo request
^C
3 packets received by filter
0 packets dropped by kernel
# tcpdump -tteni em5
tcpdump: listening on em5, link-type EN10MB
64 bytes from 10.1.2.50: icmp_seq=201 ttl=255 time=0.574 ms
1459545388.786778 fe:e1:ba:d0:f8:45 fe:e1:ba:d1:89:9d 8100 102: 802.1Q vid
10 pri 3 10.1.2.10 > 10.1.2.50: icmp: echo request
1459545388.786872 fe:e1:ba:d1:89:9d fe:e1:ba:d0:f8:45 8100 102: 802.1Q vid
10 pri 3 10.1.2.50 > 10.1.2.10: icmp: echo reply
64 bytes from 10.1.2.50: icmp_seq=202 ttl=255 time=0.472 ms
1459545389.792210 fe:e1:ba:d0:f8:45 fe:e1:ba:d1:89:9d 8100 102: 802.1Q vid
10 pri 3 10.1.2.10 > 10.1.2.50: icmp: echo request
1459545389.792310 fe:e1:ba:d1:89:9d fe:e1:ba:d0:f8:45 8100 102: 802.1Q vid
10 pri 3 10.1.2.50 > 10.1.2.10: icmp: echo reply

But if i adapt to

function madconfig {
ifconfig vether10 10.1.2.10 rdomain 10
ifconfig vether50 10.1.2.50 rdomain 50
ifconfig bridge10 create
ifconfig bridge50 create
ifconfig vlan1010 vlan 10 vlandev $1
ifconfig vlan1050 vlan 10 vlandev $2
for v in vether10 vether50  vlan1010  vlan1050  bridge10  bridge50 $1 $2
do
  ifconfig $v up
done
ifconfig bridge10 add vlan1010 add vether10
ifconfig bridge50 add vlan1050 add vether50
}

I have more chance to have something working.

I do not know if it specified somewhere that to put an interface in
promiscuous mode it must be up or something.
But maybe the ifconfig / bridge / add could say it.

This may also be the surface of a bigger problem.

(You can ask more test)

-- 
-
() ascii ribbon campaign - against html e-mail
/\

5.9 installation report - watchdog bark on em0

[sven falempin]

Base install + openup

64 bytes from 8.8.8.8: icmp_seq=1 ttl=49 time=32.923 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.008/32.466/32.923/0.457 ms
#
#
# em0: watchdog: head 78 tail 77 TDH 78 TDT 78
em0: watchdog: head 15 tail 14 TDH 15 TDT 15
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host
ping: wrote 8.8.8.8 64 chars, ret=-1
64 bytes from 8.8.8.8: icmp_seq=1 ttl=49 time=34.567 ms


DMESG:

#
#
# dmesg
OpenBSD 5.8-stable (RAMDISK_SSH) #0: Fri Feb 26 01:20:13 GMT 2016
r...@flash.citypassenger.com:/usr/src/sys/arch/amd64/compile/RAMDISK_SSH
real mem = 4169109504 (3975MB)
avail mem = 4041039872 (3853MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe9570 (14 entries)
bios0: vendor American Megatrends Inc. version "BAR3NA01" date 08/11/2015
bios0: NF533 NF533
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC FPDT MCFG LPIT HPET SSDT SSDT SSDT UEFI
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.45 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 7 (RP02)
acpiprt3 at acpi0: bus 8 (RP03)
acpiprt4 at acpi0: bus 9 (RP04)
acpiec0 at acpi0: not present
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Bay Trail Host" rev 0x0e
vga1 at pci0 dev 2 function 0 "Intel Bay Trail Video" rev 0x0e
vga1: aperture needed
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
xhci0 at pci0 dev 20 function 0 "Intel Bay Trail xHCI" rev 0x0e: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel Bay Trail TXE" rev 0x0e at pci0 dev 26 function 0 not configured
ppb0 at pci0 dev 28 function 0 "Intel Bay Trail I2C" rev 0x0e: msi
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 vendor "Pericom", unknown product 0x2608 rev
0x00
pci2 at ppb1 bus 2
ppb2 at pci2 dev 1 function 0 vendor "Pericom", unknown product 0x2608 rev
0x00: msi
pci3 at ppb2 bus 3
em0 at pci3 dev 0 function 0 "Intel I350" rev 0x01: msi, address
00:30:18:c0:cc:40
em1 at pci3 dev 0 function 1 "Intel I350" rev 0x01: msi, address
00:30:18:c0:cc:41
ppb3 at pci2 dev 2 function 0 vendor "Pericom", unknown product 0x2608 rev
0x00: msi
pci4 at ppb3 bus 4
em2 at pci4 dev 0 function 0 "Intel I211" rev 0x03: msi, address
00:30:18:c9:39:76
ppb4 at pci2 dev 3 function 0 vendor "Pericom", unknown product 0x2608 rev
0x00: msi
pci5 at ppb4 bus 5
ppb5 at pci2 dev 4 function 0 vendor "Pericom", unknown product 0x2608 rev
0x00: msi
pci6 at ppb5 bus 6
em3 at pci6 dev 0 function 0 "Intel I350" rev 0x01: msi, address
00:30:18:c0:cb:fa
em4 at pci6 dev 0 function 1 "Intel I350" rev 0x01: msi, address
00:30:18:c0:cb:fb
ppb6 at pci0 dev 28 function 1 "Intel Bay Trail PCIE" rev 0x0e: msi
pci7 at ppb6 bus 7
em5 at pci7 dev 0 function 0 "Intel I211" rev 0x03: msi, address
00:30:18:c9:39:73
ppb7 at pci0 dev 28 function 2 "Intel Bay Trail PCIE" rev 0x0e: msi
pci8 at ppb7 bus 8
em6 at pci8 dev 0 function 0 "Intel I211" rev 0x03: msi, address
00:30:18:c9:39:74
ppb8 at pci0 dev 28 function 3 "Intel Bay Trail PCIE" rev 0x0e: msi
pci9 at ppb8 bus 9
em7 at pci9 dev 0 function 0 "Intel I211" rev 0x03: msi, address
00:30:18:c9:39:75
pcib0 at pci0 dev 31 function 0 "Intel Bay Trail LPC" rev 0x0e
"Intel Bay Trail SMBus" rev 0x0e at pci0 dev 31 function 3 not configured
isa at pcib0 not configured
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
umass0 at uhub0 port 2 configuration 1 interface 0 "FLASH DISK" rev
2.00/11.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI0 0/direct removable
serial.090c1171
sd0: 967MB, 512 bytes/sector, 1981440 sectors
uhub1 at uhub0 port 4 "vendor 0x05e3 USB2.0 Hub" rev 2.00/85.37 addr 3
umass1 at uhub1 port 3 configuration 1 interface 0 "Innodisk USB Drive 3ME"
rev 2.10/8.05 addr 4
umass1: using SCSI over Bulk-Only
scsibus1 at umass1: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0:  SCSI4
0/direct removable serial.196d0201A67921335050

Re: OpenBSD ASLR and the stack

[sven falempin]

http://www.openbsd.org/papers/asiabsdcon2015-pie-slides.pdf
page6 ?


On Tue, Mar 22, 2016 at 8:36 PM, Shawn Webb 
wrote:

> Random newbie-sounding question:
>
> Does OpenBSD's ASLR implementation also randomize the top stack address?
> Or is it simply a random gap (top of the stack still at the same
> address, but application starts utilizing the stack at a random, but
> properly aligned, offset)?
>
> If it's just a random gap, would OpenBSD appreciate a patch that
> implements true stack randomization + stack gap?
>
> Thanks,
>
> --
> Shawn Webb
> HardenedBSD
>
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>



-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: Why are you so mean dhclient ?

[sven falempin]

On Fri, Feb 5, 2016 at 5:11 PM, sven falempin <sven.falem...@gmail.com>
wrote:
>
>
> tl;dr
> Digging a bit,
>
> carp is not handle like other interface there is no if_carp.c file or
> carp_X function.
> In if.c,  the case is handle with if type = IFT_CARP statement.
> carp_carpdev_state is where the up/inactive reported status may be change,
> in ./sys/netinet/ip_carp.c
>
> for the ethernet address, a similar hax is made in the ioctl so set/get it:
> case IFT_ETHER:
> case IFT_CARP:
> case IFT_XETHER:
> case IFT_ISO88025:
>
> So dhclient should align to this somehow:
> -   if (sdl->sdl_type != IFT_ETHER ||
> +  int is_ether = sdl->sdl_type == IFT_ETHER || sdl->sdl_type
> == IFT_CARP || sdl->sdl_type == IFT_XETHER || sdl->sdl_type ==
> IFT_ISO88025;
> +   if ( !( is_ether  ) ||
>
> getifsaddr calls sysctl_iflist, data from interface are dumped for the
> client, thus finding the IFT_CARP
> line 1291 of  sys/net/rtsock.c:  ifm->ifm_data = ifp->if_data;
> in the carp AF_LINK entry.
> tl;dr
>
>

To send/receive the DHCP protocol, carp must accept ethernet data in INIT
MODE,
The IFF_RUNNING flag can be avoided or not.
With this, and the IFT_CARP in dhclient , carp can be initialized by dhcp.

/!\ invalid diff wont apply, and just work in progress

Index: ip_carp.c
===
RCS file: /cvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.264
diff -u -p -r1.264 ip_carp.c
--- ip_carp.c   2 Jul 2015 09:40:03 -   1.264
+++ ip_carp.c   7 Feb 2016 03:26:14 -
@@ -1394,9 +1396,19 @@ carp_ourether(void *v, u_int8_t *ena)

TAILQ_FOREACH(vh, >vhif_vrs, sc_list) {
struct carp_vhost_entry *vhe;
+LIST_FOREACH(vhe, >carp_vhosts, vhost_entries) {
+   if ( vhe->vhid == 0 ) {
+   printf("squeeeze\n");
+   continue; //no ethernet if no vhid (no in
ipv6 mode maybe :p
+   }
+   if (vhe->state == INIT && !memcmp(ena,
vhe->vhe_enaddr,ETHER_ADDR_LEN)) { //IFF_UP|IFF_RUNNING must be checked too
+   return (>sc_if);
+   }
+   }
if ((vh->sc_if.if_flags & (IFF_UP|IFF_RUNNING)) !=
-   (IFF_UP|IFF_RUNNING))
+   (IFF_UP|IFF_RUNNING)) {
continue;
+}
if (vh->sc_balancing == CARP_BAL_ARP) {
LIST_FOREACH(vhe, >carp_vhosts, vhost_entries)
if (vhe->state == MASTER &&
@@ -1426,9 +1438,15 @@ carp_input(struct ifnet *ifp0, struct mb
eh = mtod(m, struct ether_header *);
cif = (struct carp_if *)ifp0->if_carp;
ifp = carp_ourether(cif, eh->ether_dhost);
-   if (ifp == NULL && !ETHER_IS_MULTICAST(eh->ether_dhost))
+   if (ifp == NULL && !ETHER_IS_MULTICAST(eh->ether_dhost)) {
return (0);
+   }

if (ifp == NULL) {
struct carp_softc *vh;
@@ -1567,15 +1586,22 @@ carp_setrun(struct carp_vhost_entry *vhe
sc->sc_realmac = 0;

if (sc->sc_if.if_flags & IFF_UP && vhe->vhid > 0 &&
-   (sc->sc_naddrs || sc->sc_naddrs6) && !sc->sc_suppress) {
+   /*(sc->sc_naddrs || sc->sc_naddrs6) &&*/ !sc->sc_suppress) {
+   printf( "%s: SET IFF_RUNNING 2\n", sc->sc_if.if_xname);
sc->sc_if.if_flags |= IFF_RUNNING;
} else {
sc->sc_if.if_flags &= ~IFF_RUNNING;
return;
}
+   if ( !sc->sc_naddrs && !sc->sc_naddrs6 ) {
+   return;
+   }

switch (vhe->state) {
case INIT:
carp_set_state(vhe, BACKUP);
carp_setrun(vhe, 0);
break;
@@ -2314,6 +2341,14 @@ carp_output(struct ifnet *ifp, struct mb

vhe = sc->cur_vhe ? sc->cur_vhe : LIST_FIRST(>carp_vhosts);

+
+   if ((vhe->state == INIT)
+   && !sc->sc_naddrs && !sc->sc_naddrs6 //just PARANOIA
+   && vhe->vhid > 0 && sc->sc_carpdev) { //actually an INVALID
STATE would be nice { INVALID =-1, INIT, BACKUP, MASTER}
+   return (ether_output(ifp, m, sa, rt));
+   }
+
if ((sc->sc_carpdev == NULL) ||
(!sc->sc_balancing && vhe->state != MASTER)) {
m_freem(m);
@@ -2329,6 +2364,12 @@ carp_set_state_all(struct carp_softc *sc
struct carp_vhost_entry *vhe;

Re: GIF interface and Routing Serious Unexpected behavior

[sven falempin]

On Fri, Jan 15, 2016 at 9:23 AM, sven falempin <sven.falem...@gmail.com>
wrote:

>
> Ok this morning the routing of gif was not done , after deleting the
> default route and readding it,
> tada, it s routed again.
>
> I will test with 5.8 , is it enough or do you absolutely require current ?
> i think for this case only the kernel could be updated.
>
> Please take a look Test Log :
>
> #validate the routing is broken
>
> [1]-[villemarie]-[/root]
> # tcpdump -tteni gif0 icmp
> tcpdump: listening on gif0, link-type LOOP
> 1452867126.675719 172.16.0.1 > 8.8.8.8: icmp: echo request
> 1452867126.675899 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
> 1452867126.785273 172.16.0.1 > 8.8.8.8: icmp: echo request
> 1452867126.785371 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
> 1452867126.895401 172.16.0.1 > 8.8.8.8: icmp: echo request
> 1452867126.895552 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
> 1452867127.005380 172.16.0.1 > 8.8.8.8: icmp: echo request
> 1452867127.005474 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
>
> ^C
> 8 packets received by filter
> 0 packets dropped by kernel
>
> #But route is here, why replying unreachable ? (label is here because we
> manage multiple default route )
>
> [0]-[villemarie]-[/root]
> # netstat -rnv | grep defa
> default192.168.10.1   UGS  115   684491 - 8
> re0   DHCLIENT MINE
>
> # ok lets try to confirm the yesterday strange behavior
>
> [1]-[villemarie]-[/root]
> # route delete default
> delete net default
> [0]-[villemarie]-[/root]
> # route add default 192.168.10.1 -mpath -label "DHCLIENT GIF"
> add net default: gateway 192.168.10.1
> [0]-[villemarie]-[/root]
> # tcpdump -tteni gif0 icmp
> tcpdump: listening on gif0, link-type LOOP
> 1452867248.839222 8.8.8.8 > 172.16.0.1: icmp: echo reply
> 1452867249.834122 172.16.0.1 > 8.8.8.8: icmp: echo request
>
> # wow that s strange !
>
>
>


It s all 5.8 stable now.
gif is unstable.

[0]-[58-gif]-[~]
# ping 172.16.0.1
ping: wrote 172.16.0.1 64 chars, ret=-1
--- 172.16.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
[1]-[58-gif]-[~]
# ifconfig gif0 down
[0]-[58-gif]-[~]
# ifconfig gif0 up
[0]-[58-gif]-[~]
# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: icmp_seq=0 ttl=255 time=1.122 ms

i now activate ifconfig gif0 debug

Something nasty in there.


-- 
-
() ascii ribbon campaign - against html e-mail
/\

GIF interface and Routing Serious Unexpected behavior

[sven falempin]

On Thu, Jan 14, 2016 at 8:56 PM, sven falempin <sven.falem...@gmail.com>
wrote:

>
>
> On Thu, Jan 14, 2016 at 3:14 PM, sven falempin <sven.falem...@gmail.com>
> wrote:
>
>>
>> On Thu, Jan 14, 2016 at 1:08 PM, sven falempin <sven.falem...@gmail.com>
>> wrote:
>>
>>> Dear Tech Reader,
>>> Maybe this would be misc but i am trying to avoid some useless answer.
>>> This is openbsd 5.8 patched ( -r OPENBSD_5_8 )
>>>
>>> All my block rule log.
>>> Nothing appear in tcpdump -teni pflog0
>>>
>>> But pf drop packet (set skip or pfctl -d) solve problem.
>>>
>>> [0]-[blue]-[/cloudgate]
>>> # ping -c2 -w2 172.16.0.1
>>> PING 172.16.0.1 (172.16.0.1): 56 data bytes
>>> 64 bytes from 172.16.0.1: icmp_seq=0 ttl=255 time=0.894 ms
>>> 64 bytes from 172.16.0.1: icmp_seq=1 ttl=255 time=0.966 ms
>>> --- 172.16.0.1 ping statistics ---
>>> 2 packets transmitted, 2 packets received, 0.0% packet loss
>>> round-trip min/avg/max/std-dev = 0.894/0.930/0.966/0.036 ms
>>> [0]-[blue]-[/cloudgate]
>>> # tcpdump -tteni pflog0 &
>>> [1] 31913
>>> [0]-[blue]-[/cloudgate]
>>> # tcpdump: WARNING: snaplen raised from 116 to 160
>>> tcpdump: listening on pflog0, link-type PFLOG
>>> pfctl -e
>>> pf enabled
>>> [0]-[blue]-[/cloudgate]
>>> # ping -c2 -w2 172.16.0.1
>>> PING 172.16.0.1 (172.16.0.1): 56 data bytes
>>> ping: sendto: No route to host
>>> ping: wrote 172.16.0.1 64 chars, ret=-1
>>> ping: sendto: No route to host
>>> ping: wrote 172.16.0.1 64 chars, ret=-1
>>> --- 172.16.0.1 ping statistics ---
>>> 2 packets transmitted, 0 packets received, 100.0% packet loss
>>> [1]-[blue-viking]-[/cloudgate]
>>> # ifconfig gre
>>> gre0: flags=9011<UP,POINTOPOINT,LINK0,MULTICAST> mtu 1476
>>> description: citywan
>>> priority: 0
>>> keepalive: timeout 10 count 6
>>> groups: gre
>>> status: keepalive down
>>> tunnel: inet 10.19.71.31 -> 10.54.213.241
>>> inet 172.16.0.2 --> 172.16.0.1 netmask 0x
>>>
>>>
>>> But i would like to match out on gre0 from (x:network) to !(self) nat-to
>>> (gre0:0)
>>>
>>> Not possible ?
>>>
>>>
>>>
>> Following up on the gre interface, the routing is odd, once gre is up i
>> got data form a side ,
>> yet no forwarding is done.
>>
>> [0]-[villemarie]-[/root]
>> # tcpdump -tteni gre0 icmp
>> tcpdump: listening on gre0, link-type LOOP
>> 1452800353.714927 172.16.0.2 > 8.8.8.8: icmp: echo request
>> 1452800353.715047 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
>> 1452800354.725152 172.16.0.2 > 8.8.8.8: icmp: echo request
>> 1452800354.725240 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
>> 1452800355.735124 172.16.0.2 > 8.8.8.8: icmp: echo request
>> 1452800355.735213 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
>> ^C
>> 8 packets received by filter
>> 0 packets dropped by kernel
>> [0]-[villemarie]-[/root]
>> # netstat -rnv -f inet | grep default
>> default192.168.10.1   UGS6  1510585 - 8
>> re0   DHCLIENT MANUAL
>> [0]-[villemarie]-[/root]
>> # tcpdump -tteni re0 icmp
>> tcpdump: listening on re0, link-type EN10MB
>> ^C
>> 46 packets received by filter
>> 0 packets dropped by kernel
>> [0]-[villemarie]-[/root]
>> # sysctl -a | grep forwarding
>> net.inet.ip.forwarding=1
>>
>> nothing is blocked in pf once againt aso the timing ot the reply is very
>> short.
>>
>> I was expecting the data to be routed .
>>
>>
>>
>>
> and it does, it feels like adding the route after the interface creation
> got an effect.. but unsure.
>
> First problem still unsolved.
>
>
Ok this morning the routing of gif was not done , after deleting the
default route and readding it,
tada, it s routed again.

I will test with 5.8 , is it enough or do you absolutely require current ?
i think for this case only the kernel could be updated.

Please take a look Test Log :

#validate the routing is broken

[1]-[villemarie]-[/root]
# tcpdump -tteni gif0 icmp
tcpdump: listening on gif0, link-type LOOP
1452867126.675719 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.675899 172.16.0.2 > 172.16.0.1: icmp: host 8.8.8.8 unreachable
1452867126.785273 172.16.0.1 > 8.8.8.8: icmp: echo request
1452867126.785371 172.16.0.2 > 172.1

gre, pf and overworking

[sven falempin]

Dear Tech Reader,
Maybe this would be misc but i am trying to avoid some useless answer.
This is openbsd 5.8 patched ( -r OPENBSD_5_8 )

All my block rule log.
Nothing appear in tcpdump -teni pflog0

But pf drop packet (set skip or pfctl -d) solve problem.

[0]-[blue]-[/cloudgate]
# ping -c2 -w2 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: icmp_seq=0 ttl=255 time=0.894 ms
64 bytes from 172.16.0.1: icmp_seq=1 ttl=255 time=0.966 ms
--- 172.16.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.894/0.930/0.966/0.036 ms
[0]-[blue]-[/cloudgate]
# tcpdump -tteni pflog0 &
[1] 31913
[0]-[blue]-[/cloudgate]
# tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
pfctl -e
pf enabled
[0]-[blue]-[/cloudgate]
# ping -c2 -w2 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
ping: sendto: No route to host
ping: wrote 172.16.0.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 172.16.0.1 64 chars, ret=-1
--- 172.16.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
[1]-[blue-viking]-[/cloudgate]
# ifconfig gre
gre0: flags=9011 mtu 1476
description: citywan
priority: 0
keepalive: timeout 10 count 6
groups: gre
status: keepalive down
tunnel: inet 10.19.71.31 -> 10.54.213.241
inet 172.16.0.2 --> 172.16.0.1 netmask 0x


But i would like to match out on gre0 from (x:network) to !(self) nat-to
(gre0:0)

Not possible ?

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: gre, pf and overworking

[sven falempin]

On Thu, Jan 14, 2016 at 3:14 PM, sven falempin <sven.falem...@gmail.com>
wrote:

>
> On Thu, Jan 14, 2016 at 1:08 PM, sven falempin <sven.falem...@gmail.com>
> wrote:
>
>> Dear Tech Reader,
>> Maybe this would be misc but i am trying to avoid some useless answer.
>> This is openbsd 5.8 patched ( -r OPENBSD_5_8 )
>>
>> All my block rule log.
>> Nothing appear in tcpdump -teni pflog0
>>
>> But pf drop packet (set skip or pfctl -d) solve problem.
>>
>> [0]-[blue]-[/cloudgate]
>> # ping -c2 -w2 172.16.0.1
>> PING 172.16.0.1 (172.16.0.1): 56 data bytes
>> 64 bytes from 172.16.0.1: icmp_seq=0 ttl=255 time=0.894 ms
>> 64 bytes from 172.16.0.1: icmp_seq=1 ttl=255 time=0.966 ms
>> --- 172.16.0.1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 0.894/0.930/0.966/0.036 ms
>> [0]-[blue]-[/cloudgate]
>> # tcpdump -tteni pflog0 &
>> [1] 31913
>> [0]-[blue]-[/cloudgate]
>> # tcpdump: WARNING: snaplen raised from 116 to 160
>> tcpdump: listening on pflog0, link-type PFLOG
>> pfctl -e
>> pf enabled
>> [0]-[blue]-[/cloudgate]
>> # ping -c2 -w2 172.16.0.1
>> PING 172.16.0.1 (172.16.0.1): 56 data bytes
>> ping: sendto: No route to host
>> ping: wrote 172.16.0.1 64 chars, ret=-1
>> ping: sendto: No route to host
>> ping: wrote 172.16.0.1 64 chars, ret=-1
>> --- 172.16.0.1 ping statistics ---
>> 2 packets transmitted, 0 packets received, 100.0% packet loss
>> [1]-[blue-viking]-[/cloudgate]
>> # ifconfig gre
>> gre0: flags=9011<UP,POINTOPOINT,LINK0,MULTICAST> mtu 1476
>> description: citywan
>> priority: 0
>> keepalive: timeout 10 count 6
>> groups: gre
>> status: keepalive down
>> tunnel: inet 10.19.71.31 -> 10.54.213.241
>> inet 172.16.0.2 --> 172.16.0.1 netmask 0x
>>
>>
>> But i would like to match out on gre0 from (x:network) to !(self) nat-to
>> (gre0:0)
>>
>> Not possible ?
>>
>>
>>
> Following up on the gre interface, the routing is odd, once gre is up i
> got data form a side ,
> yet no forwarding is done.
>
> [0]-[villemarie]-[/root]
> # tcpdump -tteni gre0 icmp
> tcpdump: listening on gre0, link-type LOOP
> 1452800353.714927 172.16.0.2 > 8.8.8.8: icmp: echo request
> 1452800353.715047 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
> 1452800354.725152 172.16.0.2 > 8.8.8.8: icmp: echo request
> 1452800354.725240 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
> 1452800355.735124 172.16.0.2 > 8.8.8.8: icmp: echo request
> 1452800355.735213 172.16.0.1 > 172.16.0.2: icmp: host 8.8.8.8 unreachable
> ^C
> 8 packets received by filter
> 0 packets dropped by kernel
> [0]-[villemarie]-[/root]
> # netstat -rnv -f inet | grep default
> default192.168.10.1   UGS6  1510585 - 8
> re0   DHCLIENT MANUAL
> [0]-[villemarie]-[/root]
> # tcpdump -tteni re0 icmp
> tcpdump: listening on re0, link-type EN10MB
> ^C
> 46 packets received by filter
> 0 packets dropped by kernel
> [0]-[villemarie]-[/root]
> # sysctl -a | grep forwarding
> net.inet.ip.forwarding=1
>
> nothing is blocked in pf once againt aso the timing ot the reply is very
> short.
>
> I was expecting the data to be routed .
>
>
>
>
and it does, it feels like adding the route after the interface creation
got an effect.. but unsure.

First problem still unsolved.

-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: trunk vs busy ports

[sven falempin]

On Fri, Nov 20, 2015 at 9:00 AM, Reyk Floeter  wrote:

> On Fri, Nov 20, 2015 at 11:27:05PM +1000, David Gwynne wrote:
> >
> > > On 20 Nov 2015, at 11:23 PM, Reyk Floeter  wrote:
> > >
> > > On Fri, Nov 20, 2015 at 03:36:40PM +1000, David Gwynne wrote:
> > >> IFF_OACTIVE means the hardware ring is full, not if it is busy.
> > >>
> > >> perhaps a better check is to see whether there are pending packets
> > >> on the send queue?
> > >>
> > >> i could also argue we dont need the check at all, but this is less
> > >> of a semantic change.
> > >>
> > >> ok?
> > >>
> > >
> > > OK
> > >
> > > I added this check in the initial commit of trunk(4) more than 10
> > > years ago.  I don't remember a particular reason - there wasn't even a
> > > production use yet.  I initially wrote trunk to use it for failover on
> > > some firewalls, but it was not going into production before it was
> > > committed to OpenBSD.
> > >
> > > So the reason for the flag might just be a historical one: back in the
> > > days, I heard that 10 years is a long time in IT, there was not much
> > > reference about implementing such a "cloner" correctly.  I must have
> > > looked at vlan(4) or bridge(4) and decided that it was the way to do.
> > > I mean, before mpi@, working in the network stack was tough and very
> > > different: you didn't ask, never refered to any documentation, just
> > > relied on the traditions and repeated what was done by the BSD heroes
> > > in the past.
> >
> > thats exactly right. please dont take this as an accusation of
> negligence, this is just mopping up some of that inherited code.
> >
> > im upset about my own use of IFQ_POLL() in a bunch of my own drivers,
> but really i am only guilty of what you described above too. ie, we're not
> guilty, we were just following best practices at the time.
> >
>
> Hehe, i'm not feeling accused.  I think it is a lot of fun to see all
> the progress and cleanup happening.  I just wanted to tell a story ...
> and to point out that some of the obvious mistakes of the past weren't
> so obvious to us back then.
>
> > how would you feel if i simply removed the check?
> >
>
> fine!
>
> Reyk
>
> > >> Index: if_trunk.c
> > >> ===
> > >> RCS file: /cvs/src/sys/net/if_trunk.c,v
> > >> retrieving revision 1.124
> > >> diff -u -p -r1.124 if_trunk.c
> > >> --- if_trunk.c 20 Nov 2015 05:33:54 -  1.124
> > >> +++ if_trunk.c 20 Nov 2015 05:35:07 -
> > >> @@ -296,7 +296,7 @@ trunk_port_create(struct trunk_softc *tr
> > >>return (ENOSPC);
> > >>
> > >>/* New trunk port has to be in an idle state */
> > >> -  if (ifp->if_flags & IFF_OACTIVE)
> > >> +  if (!ifq_empty(>if_snd))
> > >>return (EBUSY);
> > >>
> > >>/* Check if port has already been associated to a trunk */
> > >
> > > --
> >
>
> --
>
>
I have a trunk usage currently, and when the trunk is created, the first
data to go through
suffer a very high latency.

After less than 5 seconds, everything runs smoothly (same latency as each
link)

Could it be related ?


-- 
-
() ascii ribbon campaign - against html e-mail
/\

Re: kill NLS (native language support) libc errno message

[sven falempin]

On Sat, Oct 24, 2015 at 10:44 AM, Stefan Sperling  wrote:

> On Sat, Oct 24, 2015 at 04:07:59PM +0200, Alexander Bluhm wrote:
> > Hi,
> >
> > The only thing that is translated into multiple languages in OpenBSD
> > are the errno messages and signal names.  Everything else is in
> > English.  We are not planning to translate more text.  Running a
> > mixed system with less than 1% of the text in native language makes
> > no sense.  So I suggest to remove the NLS support from libc messages.
> > The catopen(3) functions stay as they are.
> >
> > I already saw performance issues with NLS as generating error
> > messages currently requires disk access.
> >
> > I will take care of mtree and bsd.nls.mk if we agree on this
> > direction.
> >
> > There are some NLS leftovers in pledge(2).  I will remove them later
> > after people have updated libc.
> >
> > ok for the libc part?
>
> I am very happy to see this go away. There's no point in translating
> just strerror() strings, and there are no plans to translate the
> base system.
>
> Many ports will still use their own translations with gettext. The
> errno strings will be in English regardless of language settings,
> but everything else about gettext in ports will still work.
>
> OK by me.
>
>
English is not my native language and i like this nice diff.