Re: cd command, chdir syscall, shell behavour

[Janne Johansson]

Den lör 29 juni 2019 kl 22:42 skrev ropers :

> Anyway, in an ideal world, typing man  would always show the man
> page
> actually relevant to what the box would do if the user typed  at
> the
> prompt. I don't know how this could be solved though;


and how would
$ unset PATH ; man cc
behave? By showing nothing now that you can no longer find a c compiler?
or
$ PATH=$HOME/bin  man cc
should not show manpage for system compiler but dig out that local cc you
built in your home dir long time ago?
There is a rabbit hole to fall into if you want docs to change depending on
your definition of "relevant" in the sentence above.

-- 
May the most significant bit of your life be positive.

Re: Correct pexp variable for a shell script

[Jacob Adams]

On 6/29/19 8:46 AM, Antoine Jacoutot wrote:
> On Sat, Jun 22, 2019 at 02:14:12PM -0400, Jacob Adams wrote:
>> On 6/22/19 12:43 PM, Antoine Jacoutot wrote:
>>> On Sat, Jun 22, 2019 at 10:42:39AM -0400, Jacob Adams wrote:
 On 6/22/19 7:05 AM, Antoine Jacoutot wrote:
> On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote:
>> I've got a shell script I'd like to run as a system service. Due to the
>> 16 character limitation on pgrep and the -x flag that rc.subr passes to
>> check by default, I can't get check or stop to work correctly. The
>> problem is that the process name looks like "/bin/sh
>> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match
>> when -x is used.
>>
>> My rc.d script currently looks like this:
>>
> Hi.
>
> That should not be an issue, that's why pexp is used for.
> But without more context it's hard to know how to help you.
>
> I can match sh scripts without issue:
> $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session"
> 77289
>
> Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"?
> We don't run into the 16 chars  limitation when using -xf
 Here's what I was seeing that led me to that conclusion:

 rukey$ ps aux | grep authmail
 root 51889  0.0  0.1   724   568 p0- Ip    Fri12AM    0:00.01
 /bin/sh /usr/local/bin/authmail
 jacob    25510  0.0  0.2   272   892 p0  S+p   10:36AM    0:00.01 grep
 authmail
 rukey$ pgrep -f /bin/sh /usr/local/bin/authmail
 51889
 rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail


 However, I didn't think to quote it. that seems to fix it:

 rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail"
 51889

 It appears that rc.subr uses quotes, but:

 rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail"
 51889
 rukey# rcctl check authmail
 authmail(failed)
 rukey#

 Any idea what could be going wrong here?
>>> Dunno, run rcctl in debug mode.
>>
>> rukey# ps ux | grep authmail
>> root 93772  0.0  0.2   272   892 p0  S+p    2:10PM    0:00.01 grep
>> authmail
>> rukey# rcctl -d start authmail
>> doing _rc_parse_conf
>> doing _rc_quirks
>> authmail_flags empty, using default ><
>> doing _rc_parse_conf /var/run/rc.d/authmail
>> doing _rc_quirks
>> doing rc_check
>> authmail
>> doing rc_start
>> doing _rc_wait start
>> doing rc_check
>> doing rc_check
> Can you share you /var/run/rc.d/authmail file please.


That seems to be the problem


daemon_class=daemon
daemon_flags=
daemon_rtable=0
daemon_timeout=30
daemon_user=root
pexp=/usr/local/bin/authmail.sh


Deleting that file and restarting authmail fixed the issue, allowing me
to start authmail successfully


Thanks for your help!


Jacob

Re: cd command, chdir syscall, shell behavour

[Edgar Pettijohn]

On Jun 29, 2019 5:50 PM, Ingo Schwarze  wrote:
>
> Hi Ian,
>
> ropers wrote on Sat, Jun 29, 2019 at 10:40:30PM +0200:
>
> > This relates to a long-standing annoyance: When I do `man kill` for
> > example, the manpage shown is for code that won't be what runs when I
> > do `kill `.
> > I suppose the general case is that there can be discrepancies between
> >
> >>> $ which kill
> >>> /bin/kill
> >>> $ type kill
> >>> kill is a shell builtin
> >
> > and perhaps `man kill` too (kill is just an example; the issue
> > generalises).
> > As much as this looks like a problem that wants solving, it's such a
> > long-standing and fundamental issue that I'm not sure what can be
> > done. Is there any sense in adding some checks to man(1) to ensure the
> > "wrong" information is not displayed?
>
> It isn't the wrong information.  The command
>
>   $ man kill
>
> means:
>
>   Show me the manual page with the name "kill".
>
> Clearly, that will be kill(1) and not ksh(1).
>
> If what you mean is:
>
>   Show me the manual pages documenting "kill", no matter whether
>   as a stand-alone command or an internal command built-in to another
>   program.
>
> Then you need to say:
>
>   $ man -k Ic,Nm=kill
>
> or something similar.
>
> > An added complication: When users are looking at the respective
> > sections for builtins in `man sh` vs `man ksh`, it may not always be
> > clear which description and behaviour would actually apply.
> > It's also very cumbersome to jump to the correct section e.g. in `man
> > ksh`, even if the user already knows what kind of command and
> > documentation to look for (which is half the battle). One way I
> > sometimes do that is:
> > >> $ man ksh
> > >> G?The following describes/
> > This obviously isn't ideal, but I have not found any applicable
> > shortcuts. Would it be possible to add some way to make it easier to
> > accomplish the task "show me the documentation of builtin  in man
> > ksh"?
>
> What's wrong with:
>
>   $ man -O tag=kill ksh
>
> It's documented in
>
>   $ man -O tag=tag mandoc
>
> Alternatively, type this:
>
>   man ksh:tkill
>
> As documented here:
>
>   $ man -O tag=MANPAGER man
>
> > Anyway, in an ideal world, typing man  would always show the
> > man page actually relevant to what the box would do if the user typed
> >  at the prompt.
>
> No.  That's not how man(1) is defined.  It's
>
>   usage: man [-acfhklw] [-C file] [-M path] [-m path] [-S subsection]
>  [[-s] section] name ...
>
> not
>
>   usage: man ... command ...
>
> Besides, how man(1) searches for the "name" should absolutely not
> depend on the shell the user is currently running.
>
> What next?  When you run
>
>   $ perl -e 'system qw(man kill)'
>
> you want to see the same as with:
>
>   $ perldoc -f kill
>
> > I don't know how this could be solved though; I'm just noticing that
> > there's much inconsistency and considerable possibility for user
> > confusion in that area.
>
> No man(1) begaves quite consistently and predictably.  You are
> merely confused about what the man(1) "name" argument is and how
> to search for internal commands of arbitrary programs instead.
>
> > As another aside:
> > On Ubuntu (and probably Debian), when the user types a command name
> > that does not correspond to any program actually installed, but that
> > *does* correspond to an executable present in a .deb package present
> > in currently configured repositories, the system will recommend that
> > package (sometimes several packages) and helpfully print what the user
> > would have to type to install said package(s).
>
> How revolting.  That's very contrary to the spirit of Unix.
> We certainly don't want to copy that.  No program should attempt
> to implement its very own partial solution for every *other* task
> under the sun, but instead focus on doiing its own task well.
>
> If you want to search for a manual page, use man(1).
> If you want to search for packages, use pkglocate(1).
>

I don't think this would be needed on openbsd as the default install has 
everything you need for a basic system and it's easy to add additional 
packages. However, as I learned when I set up a Debian box for my son to play 
Minecraft it didn't. So it was kinda nice when I typed ifconfig it informed me 
what package to install and I eventually got everything working no thanks to 
the piss poor manual pages provided.

Edgar

> This is perfectly fine, exactly as it should be:
>
>   schwarze@isnote $ man bash   
>   man: No entry for bash in the manual.
>   schwarze@isnote $ pkglocate bin/bash | head -n1
>   bash-5.0.7p0:shells/bash:/usr/local/bin/bash
>
> > To end on a positive: Can I add how much I appreciate that OpenBSD
> > hard-links help(1) to man(1),
>
> Heh; deraadt@ did that on Sep 14, 1998 for OpenBSD 2.4 ...
>
> > and that man will default to `man help` when called as help?
>
> and aaron@ added the help(1) manual page on Oct 18, 1999
> for OpenBSD 2.6.
>
> > This elegant way of having OpenBSD respond to `hel

Re: cd command, chdir syscall, shell behavour

[Ingo Schwarze]

Hi Ian,

ropers wrote on Sat, Jun 29, 2019 at 10:40:30PM +0200:

> This relates to a long-standing annoyance: When I do `man kill` for
> example, the manpage shown is for code that won't be what runs when I
> do `kill `.
> I suppose the general case is that there can be discrepancies between
>
>>> $ which kill
>>> /bin/kill
>>> $ type kill
>>> kill is a shell builtin
>
> and perhaps `man kill` too (kill is just an example; the issue
> generalises).
> As much as this looks like a problem that wants solving, it's such a
> long-standing and fundamental issue that I'm not sure what can be
> done. Is there any sense in adding some checks to man(1) to ensure the
> "wrong" information is not displayed?

It isn't the wrong information.  The command

  $ man kill

means:

  Show me the manual page with the name "kill".

Clearly, that will be kill(1) and not ksh(1).

If what you mean is:

  Show me the manual pages documenting "kill", no matter whether
  as a stand-alone command or an internal command built-in to another
  program.

Then you need to say:

  $ man -k Ic,Nm=kill

or something similar.

> An added complication: When users are looking at the respective
> sections for builtins in `man sh` vs `man ksh`, it may not always be
> clear which description and behaviour would actually apply.
> It's also very cumbersome to jump to the correct section e.g. in `man
> ksh`, even if the user already knows what kind of command and
> documentation to look for (which is half the battle). One way I
> sometimes do that is:
> >> $ man ksh
> >> G?The following describes/
> This obviously isn't ideal, but I have not found any applicable
> shortcuts. Would it be possible to add some way to make it easier to
> accomplish the task "show me the documentation of builtin  in man
> ksh"?

What's wrong with:

  $ man -O tag=kill ksh

It's documented in

  $ man -O tag=tag mandoc

Alternatively, type this:

  man ksh:tkill

As documented here:

  $ man -O tag=MANPAGER man

> Anyway, in an ideal world, typing man  would always show the
> man page actually relevant to what the box would do if the user typed
>  at the prompt.

No.  That's not how man(1) is defined.  It's

  usage: man [-acfhklw] [-C file] [-M path] [-m path] [-S subsection]
 [[-s] section] name ...

not

  usage: man ... command ...

Besides, how man(1) searches for the "name" should absolutely not
depend on the shell the user is currently running.

What next?  When you run

  $ perl -e 'system qw(man kill)'

you want to see the same as with:

  $ perldoc -f kill

> I don't know how this could be solved though; I'm just noticing that
> there's much inconsistency and considerable possibility for user
> confusion in that area.

No man(1) begaves quite consistently and predictably.  You are
merely confused about what the man(1) "name" argument is and how
to search for internal commands of arbitrary programs instead.

> As another aside:
> On Ubuntu (and probably Debian), when the user types a command name
> that does not correspond to any program actually installed, but that
> *does* correspond to an executable present in a .deb package present
> in currently configured repositories, the system will recommend that
> package (sometimes several packages) and helpfully print what the user
> would have to type to install said package(s).

How revolting.  That's very contrary to the spirit of Unix.
We certainly don't want to copy that.  No program should attempt
to implement its very own partial solution for every *other* task
under the sun, but instead focus on doiing its own task well.

If you want to search for a manual page, use man(1).
If you want to search for packages, use pkglocate(1).

This is perfectly fine, exactly as it should be:

  schwarze@isnote $ man bash   
  man: No entry for bash in the manual.
  schwarze@isnote $ pkglocate bin/bash | head -n1
  bash-5.0.7p0:shells/bash:/usr/local/bin/bash

> To end on a positive: Can I add how much I appreciate that OpenBSD
> hard-links help(1) to man(1),

Heh; deraadt@ did that on Sep 14, 1998 for OpenBSD 2.4 ...

> and that man will default to `man help` when called as help?

and aaron@ added the help(1) manual page on Oct 18, 1999
for OpenBSD 2.6.

> This elegant way of having OpenBSD respond to `help` is really
> n00b-friendly.

And yet, even among those tiny innovations that are somehow neat,
not all get picked up elsewhere:

  https://man.openbsd.org/FreeBSD-12.0/help
  https://man.openbsd.org/NetBSD-8.0/help
  https://man.openbsd.org/Linux-5.01/help

Yours,
  Ingo

Re: Future of X.org?

[Leonid Bobrov]

On Sat, Jun 29, 2019 at 12:29:40PM -0700, Chris Cappuccio wrote:
> Leonid Bobrov [mazoc...@disroot.org] wrote:
> > On Fri, Jun 28, 2019 at 01:56:43PM -0400, Christopher Turkel wrote:
> > 
> > First, I'd like to blame Xenocara for this pain porting Wayland to
> > OpenBSD (because building Mesa from ports would be an opportunity),
> > right now to build Mesa with Wayland support we need to import
> > Wayland in Xenocara and all its dependencies (including libxml) in base.
> > 
> 
> Why not simply have a Wayland-appropriate Mesa option in the ports tree?
>

That's appropriate only if we build a module which then gets dlopen()'ed
by Mesa in Xenocara.

> > Fifth, almost nobody in OpenBSD cares about Wayland and personally I
> > don't see an opportunity in protocol which requires XML.
> > 
> 
> Sounds like something that belongs in the ports tree
>

Not really, we accepted worse crap than XML: DRM code from Linux,
especially AMDGPU; X.org; LLVM. So libxml in base won't be that harmful
to us, so maybe even radically removing X.org and having a sane Wayland
compositor in base will only benefit us in terms of security by default?
Still too bad there are no other alternatives, it's just XML is a bloat,
so basically we replace elephant X with horse Wayland.

> > The epoll() problem is solved at FreeBSD and NetBSD by using epoll-shim,
> > it's epoll() emulation via kqueue(), DragonFly BSD still prefers not
> > using epoll-shim and writting kqueue() code instead, but Peter Must
> > (the current maintainer of Wayland in DragonFly) is going to use
> > epoll-shim for libinput while still maintaining kqueue() code in
> > reference Wayland library.
> 
> So basically, the problems are already mostly solved. That makes for lots
> of options for someone who wants to port Wayland to OpenBSD.
> 

The Wayland library itself is already ported (check OpenBSD WIP repo, I
opened PR there but it updates to a previous Wayland release, I didn't
bother to port a new release yet because I am worried about input
handling in wscons which doesn't have documentation on that), but it's
useless without actual compositors. While wscons is not documented you
can't hope that someone will port Wayland compositors unless you are
going to import evdev just like FreeBSD and DragonFly BSD did it because
nobody is willing to work with undocumented syscons.

Surprisingly wscons suits Wayland even better than evdev because it's
possible to do keylogging with evdev while it's impossible to do
keylogging with wscons if you open /dev/wskbd* and /dev/wsmouse* with
O_NONBLOCK flag, that means only compositor will have direct access to
input no matter what user runs it.

Re: Evernote Alternative?

[Chris Humphries]

Final post.

After writing a script to port my 10 years of Evernote content to Zim
for a few hours, I ported all my content. Sadly, Zim crashes every time
now, maybe it wasn't meant to handle that workload. But hey, I got to
enjoy diving back into Perl programming again.

So, instead of investing more time into debugging the crashes, I've
moved on to Emacs org-mode which is working well. I've been using Emacs
for over decades years, so it OK.

For encryption and backup, I'm using jcs's veracrypt port to have a
container on a usb key and backing up remotely to a cloud data store.
Veracrypt is important to me because I want to flexibility to access my
data from whatever OS I'm at.

There just simply aren't good native personal wiki/notebook apps
available on OpenBSD (rich text, copy/paste content like web pages
[maintaining webpage rendering] and images, etc) at this time.

Thanks for everyone's help and suggestions! org-mode ended up being the
choice to pick, but mainly due to other options not being available and
it was the best from what remains.
https://www.privacytools.io/software/notebooks/


Anyone looking this thread up in the future (here is my setup):

1. Use org-mode: export your notebooks to enex files and use a utility
like https://github.com/aladine/EverOrg to convert them

2. Use jcs's port (at the time of this email) for veracrypt:
https://github.com/jcs/openbsd-ports/tree/master/security/veracrypt

3. Keep the encrypted container on a usb key and back it to a
cloud/remote data store regularly/as-needed.


On 6/28/19 11:48 PM, Chris Humphries wrote:
> On Sat, Jun 29, 2019 at 02:37:20AM +, Ipsen S Ripsbusker wrote:
>> I realized that you did mention what you liked in your first mail.
>>
>>> I keep a lot of my brain in Evernote, and having a replacement is a
>>> big productivity boost for me. I mainly want a way to categorize notes
>>> into categories/labels/notebooks, be able to view all notes in that
>>> category/label/notebook, and be able to search all notes.
>>>
>>> If I could also access that information from a mobile device, that
>>> would be great but not required.
>>
>> As others have pointed out, specialized text files  in a synchronized
>> directory do seem to accomplish this. I consequently think there is
>> more that you like about Evernote but have not articulated.
>>
> 
> You are right.
> 
> I surely left stuff out because I did not articulate all the reasons I
> use Evernote. I conveyed the main reasons I use Evernote and in a
> sense what features are that I care about on a day to day basis.
> 
> 
> I'm leaning towards Zim (which is in ports, has a nice GUI, has the
> features I wanted, and its data files are text files) with rclone for
> syncing to a cloud data store.
> 
> I start migrating all my Evernote data to it tomorrow. I will probably
> write up a blog post about it once I've completed the entire
> process. I'll need to write a script to handle the conversion.
> 
> 
> I appreciate your reply.
> Take care!
> 

-- 
Chris Humphries 
5223 9548 E1DE DE87 F509  1888 8141 8451 6338 DD29

Re: cd command, chdir syscall, shell behavour

[ropers]

On 28/06/2019, Ingo Schwarze <> wrote:
(...) while the fact that the cwd is a property
> of each process is actually fairly obvious in the first place.
> What else could it possibly be, in a multi-user system?

Fair enough; I suppose it's one of these things that once you know
them, they're obvious, and anything else seems unimaginable. ;)
But to imagine something else: Things could have been designed for the
shell to run in /bin (its *own* cwd) while *separately* keeping state
of a user- and program-cwd, which is what I meant when I talked about
nannying and chaperoning programs, etc.
However, there is a minimalist and very Unix-like elegance to the
actual choice of just using the working directory of the current shell
execution environment for that end. I do admire it, and it does make
permissions that much clearer. I had just never thought about it
before, though it seems so obvious in retrospect.

The only thing that now feels less intuitively clear is that there
apparently still is a need to have traverse permissions all the way
down, as mentioned here for example:

>> On the lower level, this particular permission in stat.h standard Unix 
>> library
>> is defined as
>>S_IXUSR
>>Execute/search permission, owner.
>> (...)
>> The reason behind that lies in the POSIX definition of EACCES:
>>[EACCES] Permission bits of the file mode do not permit the requested
>> access, or search permission is denied on a component of the path prefix
This would suggest path resolution back from the directory root with
every chdir() call, no? Now that I think about it, I'm not entirely
sure when traverse permissions (for "upper"/path prefix directories)
really come into play.
But this is really more of a "I need to learn this" issue and less of
a "can OpenBSD's man pages be improved here" issue.


Ingo Schwarze <> wrote:
> we don't write separate manual pages for shell builtins.
>
> It was discussed internally whether the chdir(2), getcwd(3),
> pwd(1), and ksh(1) manual pages can be improved to make it more
> explicit that the current working directory is a process property.
>
> But the conclusion was that introducing wording to that effect risks
> causing other ambiguities, (...)
>
> So the manual pages remain unchanged.

This relates to a long-standing annoyance: When I do `man kill` for
example, the manpage shown is for code that won't be what runs when I
do `kill `.
I suppose the general case is that there can be discrepancies between
>> $ which kill
>> /bin/kill
>> $ type kill
>> kill is a shell builtin
and perhaps `man kill` too (kill is just an example; the issue generalises).
As much as this looks like a problem that wants solving, it's such a
long-standing and fundamental issue that I'm not sure what can be
done. Is there any sense in adding some checks to man(1) to ensure the
"wrong" information is not displayed?
An added complication: When users are looking at the respective
sections for builtins in `man sh` vs `man ksh`, it may not always be
clear which description and behaviour would actually apply.
It's also very cumbersome to jump to the correct section e.g. in `man
ksh`, even if the user already knows what kind of command and
documentation to look for (which is half the battle). One way I
sometimes do that is:
>> $ man ksh
>> G?The following describes/
This obviously isn't ideal, but I have not found any applicable
shortcuts. Would it be possible to add some way to make it easier to
accomplish the task "show me the documentation of builtin  in man
ksh"?


|Side note:
|The util-linux whereis(1) will, as per `man -k whereis`,
|"locate the binary, source, and manual page files for a command",
|while OpenBSD's whereis(1) will "locate programs", noting that
|>> The whereis command first appeared in 2BSD, but the original version was
|>> legally tainted and was not included as part of the 4.4BSD release, such
|>> that most of the original functionality was lost.
|cf. 
|FreeBSD has a version that
|>> re-implements the historical functionality that was lost in 4.4BSD.
|cf. 
|They've apparently had those features back since FreeBSD 2.2.1 (April, 1997),
|which would have been not long after those features were removed. They seem
|to have rewritten their whereis(1) in 2002:
|
|How suitable any of this might be for OpenBSD I'm not in a position to say.


Anyway, in an ideal world, typing man  would always show the man page
actually relevant to what the box would do if the user typed  at the
prompt. I don't know how this could be solved though; I'm just noticing that
there's much inconsistency and considerable possibility for user confusion in
that area.


|As another aside:
|On Ubuntu (and probably Debian), when the user types a co

Re: Future of X.org?

[Chris Cappuccio]

Leonid Bobrov [mazoc...@disroot.org] wrote:
> On Fri, Jun 28, 2019 at 01:56:43PM -0400, Christopher Turkel wrote:
> 
> First, I'd like to blame Xenocara for this pain porting Wayland to
> OpenBSD (because building Mesa from ports would be an opportunity),
> right now to build Mesa with Wayland support we need to import
> Wayland in Xenocara and all its dependencies (including libxml) in base.
> 

Why not simply have a Wayland-appropriate Mesa option in the ports tree?

> Fifth, almost nobody in OpenBSD cares about Wayland and personally I
> don't see an opportunity in protocol which requires XML.
> 

Sounds like something that belongs in the ports tree

> The epoll() problem is solved at FreeBSD and NetBSD by using epoll-shim,
> it's epoll() emulation via kqueue(), DragonFly BSD still prefers not
> using epoll-shim and writting kqueue() code instead, but Peter Must
> (the current maintainer of Wayland in DragonFly) is going to use
> epoll-shim for libinput while still maintaining kqueue() code in
> reference Wayland library.

So basically, the problems are already mostly solved. That makes for lots
of options for someone who wants to port Wayland to OpenBSD.

Re: Future of X.org?

[Christopher Turkel]

If you want an idea when X11 will die, watch Debian Linux. When they drop
it, you know the end is coming. Right now, they do not even default to
Wayland.

On Sat, Jun 29, 2019 at 3:25 PM Juan Francisco Cantero Hurtado <
i...@juanfra.info> wrote:

> On Fri, Jun 28, 2019 at 05:06:49PM -0400, gwes wrote:
> >
> >
> > On 6/28/19 1:56 PM, Christopher Turkel wrote:
> > > Probably someday. X won’t be going away anytime soon.
> > >
> > > On Friday, June 28, 2019, Nathan Hartman 
> wrote:
> > >
> > > > Came across this:
> > > >
> > > > https://www.phoronix.com/scan.php?page=news_item&px=X.Org-
> > > > Maintenance-Mode-Quickly
> > > >
> > > > Long story short, Red Hat hopes to switch from X.Org to Wayland and
> > > > expects X.Org to go into "hard maintenance mode" after that.
> > > >
> > > > Relevant to OpenBSD?
> > > >
> > I regularly run programs on one machine connected to a display
> > on another machine. AFAIK, the current state of Wayland makes
> > that difficult. I confess to not following it closely.
> >
> > Implementing something as huge as Wayland in the kernel
> > mega-bloat. As a tightly coupled server process, maybe.
> > Sorta like X with a very different interface.
>
> We have the "mega-bloat" implemented in the kernel. It's the KMS/DRM thing.
> The compositor is a userland program.
>
> The missing parts are not so big but nobody is working on that.
>
> >
> > It also seems to assume a heavyweight desktop suite
> > to implement common X features Mega-bloat.
>
> https://swaywm.org/ <- an i3 inspired wayland compositor
>
> >
> > If I'm wrong, please point out sources.
> > Otherwise for my usage it's not nearly ready and
> > requires some complex porting/additional programs.
>
> I dont' know why people are so sad. X11 should have died long time ago.
> Xorg is just a big keylogger and will never be secure. KMS bought some
> of time for Xorg but it should be die for good.
>
>
> --
> Juan Francisco Cantero Hurtado http://juanfra.info
>
>

Re: may an edgerouter or pair / queue porblem

[Chris Cappuccio]

ms [m...@it-infrastrukturen.org] wrote:
> What hardware (CPU, memory type, network cards) do you use in your
> configuration?
> 
> Myself I have faced network related performance issues on OpenBSD (v. 6.4).
> 
> Network card drivers are known "not to be very fast" in OpenBSD..
> 

OpenBSD 6.5-current has improved networking performance from 6.5-release
for various use cases. 

For diagnosing this particular problem, it would be interesting to know,
WHAT queueing configuration is being applied in pf? and WHAT is the 
resulting performance when it is applied? I didn't see clear answers
to those questions in the first email.

Re: Future of X.org?

[Juan Francisco Cantero Hurtado]

On Fri, Jun 28, 2019 at 05:06:49PM -0400, gwes wrote:
> 
> 
> On 6/28/19 1:56 PM, Christopher Turkel wrote:
> > Probably someday. X won’t be going away anytime soon.
> > 
> > On Friday, June 28, 2019, Nathan Hartman  wrote:
> > 
> > > Came across this:
> > > 
> > > https://www.phoronix.com/scan.php?page=news_item&px=X.Org-
> > > Maintenance-Mode-Quickly
> > > 
> > > Long story short, Red Hat hopes to switch from X.Org to Wayland and
> > > expects X.Org to go into "hard maintenance mode" after that.
> > > 
> > > Relevant to OpenBSD?
> > > 
> I regularly run programs on one machine connected to a display
> on another machine. AFAIK, the current state of Wayland makes
> that difficult. I confess to not following it closely.
> 
> Implementing something as huge as Wayland in the kernel
> mega-bloat. As a tightly coupled server process, maybe.
> Sorta like X with a very different interface.

We have the "mega-bloat" implemented in the kernel. It's the KMS/DRM thing.
The compositor is a userland program.

The missing parts are not so big but nobody is working on that.

> 
> It also seems to assume a heavyweight desktop suite
> to implement common X features Mega-bloat.

https://swaywm.org/ <- an i3 inspired wayland compositor

> 
> If I'm wrong, please point out sources.
> Otherwise for my usage it's not nearly ready and
> requires some complex porting/additional programs.

I dont' know why people are so sad. X11 should have died long time ago.
Xorg is just a big keylogger and will never be secure. KMS bought some
of time for Xorg but it should be die for good.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: umsm0: this device is not using CDC notify message in intr pipe. HP Compaq dc5750

[Chris Cappuccio]

Kihaguru Gathura [pqscr...@gmail.com] wrote:
> Hello,
> 
> Huawei E303 modem now detaches in OpenBSD 6.5 This works fine on
> OpenBSD 6.2 same machine.
> 

There's a remote chance that this is fixed in 6.5-current. Some USB work
has been going on. But if that doesn't work, you'll have to try more kernels
to figure out when this stopped working. Try 6.5-current first, then 6.4,
and then 6.3 to see which are broken. 

Re: man bgpd.conf + question

[Claudio Jeker]

On Fri, Jun 28, 2019 at 10:52:01PM +, Mik J wrote:
> Hello,
> I have a syntax error with  announce none 
> group "spam-bgp" {
>     remote-as   $spamASN
>     multihop 64
>     announce none
> 
> I was told recently that everything is filtered by default from 6.4 and read 
> on Internet that announce none is deprecated
> However man bgpd.conf (Openbsd 6.5) still has this command in section 
> "NEIGHBORS AND GROUPS"announce (IPv4|IPv6) (none|unicast|vpn)
> 
> Do you know what is correct ?

There is a difference between:
announce none
and
announce IPv4 none
or
announce IPv6 none

The frist one no longer exists. The 2nd one still works and disables the
multiprotocol capability for the define AFI (IPv4 or IPv6).
By default the session enables the unicast AFI for the IP family that the
session uses. (e.g. announce IPv6 unicast for IPv6 sessions) and the other
AFI is disabled.

-- 
:wq Claudio

Re: bwfm bcm43569

[Janne Johansson]

Den fre 28 juni 2019 kl 06:45 skrev Joseph Mayer <
joseph.ma...@protonmail.com>:

> point today (due to not using block device multiqueueing and I get the
> impression that the disk/IO subsystem is mostly not parallellized, for
> some usecases also the 3GB buffer cap limit matters).
>

That last point is solved in current,
My box now says:

Memory: Real: 361M/15G act/tot Free: 899M Cache: 14G Swap: 0K/81M

and some go even further:
https://twitter.com/mlarkin2012/status/1136821764959350784

-- 
May the most significant bit of your life be positive.

Re: what about bootkit, infect the kernel and other security questions.

[Raul Miller]

You might want to put five minutes into researching each of these questions
on your own. This would help you form more meaningful questions and would
also increase the likelihood that you would be able to understand the
responses.

That said, here's something that you (or maybe someone else) might find
useful:

https://en.wikipedia.org/wiki/The_Coroner%27s_Toolkit


Thanks,

-- 
Raul

On Saturday, June 29, 2019, Cord  wrote:

> Hi, I have some questions about security and computer forensics on opensbd.
>
> - Is openbsd vulnerable to bootkit ? and firmware rootkit ?
> - Can an attacker (with root) infect the kernel and insert code to be
> relinked ?
> - Can an attacker substitute the entire kernel with an infected one ? If
> yes, how to check its integrity ?
> - Are there forensics tools for openbsd ?
> - Could be usefull memory forensics frameworks like rekall and volatility
> in openbsd ? Is planned to build something like that ?
>
>
> Thank you.
> Cord
>
>
>
>

umsm: sparc64

[Kihaguru Gathura]

Hello,

umsm is not being detected on this machine for Huawei E303 modem. Only
interface 0 and 1 which are both umass are detected. interface 2 is
umsm but not active please see boot message.

Any guidance here is highly appreciated.

Kihaguru.

Jun 29 13:14:37 GMT 2019 PowerOn SelfTest start
POST:Testing Flash/SRAM
POST:Testing SC
POST:Testing XSCF
POST:Banner
POST:FATAL check
POST:Testing Timer1
POST:Testing Tick
POST:Testing MMU
POST:Testing CPU Type
POST:Testing DTAG
POST:Memory Probe
POST:Testing Memory
POST:Testing Softint
POST:Testing U2P
POST:Testing Slave Device
POST:Testing Master Device
POST:System Configure
POST:OBP Start
screen not found.
keyboard not found.
Keyboard not present.  Using ttya for input and output.

Fujitsu Siemens PRIMEPOWER250 2x SPARC64 V, No Keyboard
OpenBoot 3.18.1-1, 16384 MB memory installed
Ethernet address 0:b:5d:f3:a7:5c, Host ID: 80f2a75c.
XSCF Version: 4.12.1



{0} ok boot
Boot device: /pci@83,4000/FJSV,ulsa@2,1/disk@0,0  File and args:
OpenBSD IEEE 1275 Bootblock 1.4
..>> OpenBSD BOOT 1.11
Can't read disk label.
Can't open disk label package
Trying bsd...
Booting /pci@83,4000/FJSV,ulsa@2,1/disk@0,0:a/bsd
9453456@0x100+112@0x1903f90+202800@0x1c0+3991504@0x1c31830
symbols @ 0xfe9e2400 165+610944+416267 start=0x100
[ using 1028408 bytes of bsd ELF symbol table ]
console is /pci@83,4000/isa@7/su@0,3f8
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.4 (GENERIC.MP) #6: Fri Oct 12 09:57:36 MDT 2018
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 17179869184 (16384MB)
avail mem = 16862707712 (16081MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: Fujitsu Siemens PRIMEPOWER250 2x SPARC64 V
cpu0 at mainbus0: FJSV,SPARC64-V (rev 5.1) @ 1979 MHz
cpu0: physical 128K instruction (64 b/l), 128K data (64 b/l), 3072K
external (64 b/l)
cpu1 at mainbus0: FJSV,SPARC64-V (rev 5.1) @ 1979 MHz
cpu1: physical 128K instruction (64 b/l), 128K data (64 b/l), 3072K
external (64 b/l)
psycho0 at mainbus0 addr 0xfffb2000: SUNW,psycho, impl 0, version 4, ign c0
psycho0: bus range 0-0, PCI bus 0
psycho0: dvma map fe00-, STC0 enabled
pci0 at psycho0
ebus0 at pci0 dev 1 function 0 "Sun PCIO EBus2" rev 0x01
"FJSV,scfc" at ebus0 addr 21-210085, 22-220031, 26-260001,
27-28 ivec 0x23 not configured
"FJSV,flashprom" at ebus0 addr 0-3f not configured
clock1 at ebus0 addr 25-251fff: mk48t59
"FJSV,panel" at ebus0 addr 210011-210011 ivec 0x25 not configured
ebus1 at pci0 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00
com0 at ebus1 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo
com0: console
com1 at ebus1 addr 2e8-2ef ivec 0x2b: ns16550a, 16 byte fifo
hme0 at pci0 dev 1 function 1 "Sun HME" rev 0x01: ivec 0xe1, address
00:0b:5d:f3:a7:5c
nsphyter0 at hme0 phy 1: DP83843 10/100 PHY, rev. 0
mpi0 at pci0 dev 2 function 1 "Symbios Logic 53c1030" rev 0x07: ivec 0xe0
mpi0: 0, firmware 1.0.12.0
scsibus1 at mpi0: 16 targets, initiator 7
sym0 at scsibus1 targ 0 lun 0:  SCSI2
0/direct fixed serial.FUJITSU_MAT3073N_SUN72G_000506B00RAR_AAN0P5200RAR
sd0 at scsibus0 targ 0 lun 0:  SCSI2
0/direct fixed serial.FUJITSU_MAT3073N_SUN72G_000506B00RAR_AAN0P5200RAR
sd0: 70007MB, 512 bytes/sector, 143374738 sectors
sym1 at scsibus1 targ 1 lun 0:  SCSI2
0/direct fixed serial.FUJITSU_MAT3073N_SUN72G_000506B00SSL_AAN0P5200SSL
sd1 at scsibus0 targ 1 lun 0:  SCSI2
0/direct fixed serial.FUJITSU_MAT3073N_SUN72G_000506B00SSL_AAN0P5200SSL
sd1: 70007MB, 512 bytes/sector, 143374738 sectors
mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1
mpi0: target 1 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1
pciide0 at pci0 dev 13 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc4:
DMA, channel 0 configured to native-PCI, channel 1 configured to
native-PCI
pciide0: using ivec 0xe4 for native-PCI interrupt
atapiscsi0 at pciide0 channel 0 drive 0
scsibus2 at atapiscsi0: 2 targets
cd0 at scsibus2 targ 0 lun 0:  ATAPI
5/cdrom removable
cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
ohci0 at pci0 dev 10 function 0 "Acer Labs M5237 USB" rev 0x03: ivec
0xe9, version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Acer Labs OHCI root hub"
rev 1.00/1.00 addr 1
psycho1 at mainbus0 addr 0xfff9e000: SUNW,psycho, impl 0, version 4, ign c0
psycho1: bus range 128-128, PCI bus 128
psycho1: dvma map fe00-, STC0 enabled, STC1 enabled
pci1 at psycho1
bge0 at pci1 dev 1 function 0 "Fujitsu PRIMEPOWER250/450 LAN" rev
0x02, BCM5702/5703 A2 (0x1002): ivec 0xc0, address 00:0b:5d:f4:27:5c
brgphy0 at bge0 phy 1: BCM5703 10/100/1000baseT PHY, rev. 2
"counter-timer" at mainbus0 addr 0xfff8bc00 not configured
umass0 at uhub0 port 2 configuration 1 interface 0 "HUAWEI HUAWEI
Mobile" rev 2.0

what about bootkit, infect the kernel and other security questions.

[Cord]

Hi, I have some questions about security and computer forensics on opensbd.

- Is openbsd vulnerable to bootkit ? and firmware rootkit ?
- Can an attacker (with root) infect the kernel and insert code to be relinked ?
- Can an attacker substitute the entire kernel with an infected one ? If yes, 
how to check its integrity ?
- Are there forensics tools for openbsd ?
- Could be usefull memory forensics frameworks like rekall and volatility in 
openbsd ? Is planned to build something like that ?


Thank you.
Cord

Re: Correct pexp variable for a shell script

[Antoine Jacoutot]

On Sat, Jun 22, 2019 at 02:14:12PM -0400, Jacob Adams wrote:
> 
> On 6/22/19 12:43 PM, Antoine Jacoutot wrote:
> > On Sat, Jun 22, 2019 at 10:42:39AM -0400, Jacob Adams wrote:
> >> On 6/22/19 7:05 AM, Antoine Jacoutot wrote:
> >>> On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote:
>  I've got a shell script I'd like to run as a system service. Due to the
>  16 character limitation on pgrep and the -x flag that rc.subr passes to
>  check by default, I can't get check or stop to work correctly. The
>  problem is that the process name looks like "/bin/sh
>  /usr/local/bin/script.sh" which, even if passed to pgrep, won't match
>  when -x is used.
> 
>  My rc.d script currently looks like this:
> 
> >>> Hi.
> >>>
> >>> That should not be an issue, that's why pexp is used for.
> >>> But without more context it's hard to know how to help you.
> >>>
> >>> I can match sh scripts without issue:
> >>> $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session"
> >>> 77289
> >>>
> >>> Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"?
> >>> We don't run into the 16 chars  limitation when using -xf
> >>
> >> Here's what I was seeing that led me to that conclusion:
> >>
> >> rukey$ ps aux | grep authmail
> >> root 51889  0.0  0.1   724   568 p0- Ip    Fri12AM    0:00.01
> >> /bin/sh /usr/local/bin/authmail
> >> jacob    25510  0.0  0.2   272   892 p0  S+p   10:36AM    0:00.01 grep
> >> authmail
> >> rukey$ pgrep -f /bin/sh /usr/local/bin/authmail
> >> 51889
> >> rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail
> >>
> >>
> >> However, I didn't think to quote it. that seems to fix it:
> >>
> >> rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail"
> >> 51889
> >>
> >> It appears that rc.subr uses quotes, but:
> >>
> >> rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail"
> >> 51889
> >> rukey# rcctl check authmail
> >> authmail(failed)
> >> rukey#
> >>
> >> Any idea what could be going wrong here?
> > Dunno, run rcctl in debug mode.
> 
> 
> rukey# ps ux | grep authmail
> root 93772  0.0  0.2   272   892 p0  S+p    2:10PM    0:00.01 grep
> authmail
> rukey# rcctl -d start authmail
> doing _rc_parse_conf
> doing _rc_quirks
> authmail_flags empty, using default ><
> doing _rc_parse_conf /var/run/rc.d/authmail
> doing _rc_quirks
> doing rc_check
> authmail
> doing rc_start
> doing _rc_wait start
> doing rc_check
> doing rc_check

Can you share you /var/run/rc.d/authmail file please.

-- 
Antoine

Re: may an edgerouter or pair / queue porblem

[ms]

What hardware (CPU, memory type, network cards) do you use in your 
configuration?


Myself I have faced network related performance issues on OpenBSD (v. 6.4).

Network card drivers are known "not to be very fast" in OpenBSD..


On 29.06.19 10:24, Holger Glaess wrote:

 hi


hi


my setup

edgerouter 6p with OpenBSD 6.5


an DSL line with up to 100Mbit

an Cable Line with 200/20 Mbit

the lines are separated my rdomain and connected to the main rdomain 0 
by pair interfaces


i dont use outbound loadbalancing but i delegate some traffic , 
example sip or IPv6 by PF.


the router are connected by a lacp trunk with 2 interfaces to the 
switch with a couple of vlans



all this work ,


my problem is that i dont get the full download speed at the cable line.


without queueing ig get just 150 Mbit , the is an buisness line that 
means the bandwidth is guarateed.



if i enable queueing ( inbound on my cable vlan outbound on the pair 
interface inside the cable rdom.



at netstat is see drops on some interfaces


Name    Mtu   Network Address  Ipkts Ifail Opkts Ofail 
Colls

lo0 32768   36 0 36 0 0
lo0 32768 ::1/128 ::1 36 0 36 0 0
lo0 32768 fe80::%lo0/ fe80::1%lo0 36 0 36 0 0
lo0 32768 127/8   127.0.0.1   36 0 36 0 0
cnmac0* 1500    fc:ec:da:40:fa:42    0 0    0 
0 0

cnmac1  1518    fc:ec:da:40:fa:43   283008 0 83585 0 0
cnmac2  1518    fc:ec:da:40:fa:43   116607 0 307880 
0 0

cnmac3  1500    fc:ec:da:40:fa:45  551 0 264 0 0
cnmac3  1500  192.168.1/2 192.168.1.250  551 0 264 0 0
cnmac4* 1500    fc:ec:da:40:fa:46    0 0    0 
0 0
cnmac5* 1500    fc:ec:da:40:fa:47    0 0    0 
0 0
enc0    0    0 0    0 
0 0

carp0   1500    00:00:5e:00:01:3c   119628 0 466 0 0
carp0   1500  192.168.131 192.168.131.250 119628 0 466 0 0
carp0   1500  fe80::%carp fe80::7c96:7198:9   119628 0 466 0 0
carp0   1500  fde0:911:91 fde0:911:911:2308   119628 0 466 0 0
carp1   1500    00:00:5e:00:01:3d  250 0 168 0 0
carp1   1500  10.0.0/24   10.0.0.1   250 0 168 0 0
carp2   1500    00:00:5e:00:01:3e 8059 0 182 0 0
carp2   1500  192.168.132 192.168.132.250   8059 0 182 0 0
carp2   1500  169.254/16  169.254.1.2   8059 0 182 0 0
carp3   1500    00:00:5e:00:01:3f    0 0 100 0 0
carp3   1500  192.168.134 192.168.134.250  0 0 100 0 0
carp6   1500    00:00:5e:00:01:42 1925 0 102 0 0
carp6   1500  192.168.135 192.168.135.250   1925 0 102 0 0
enc1    0    0 0    0 
0 0
lo1 32768    0 0    0 
0 0

lo1 32768 127/8   127.0.0.1    0 0 0 0 0
lo2 32768    0 0    0 
0 0

lo2 32768 127/8   127.0.0.1    0 0 0 0 0
lo3 32768    0 0    0 
0 0

lo3 32768 127/8   127.0.0.1    0 0 0 0 0
lo4 32768    0 0    0 
0 0

lo4 32768 127/8   127.0.0.1    0 0 0 0 0
lo5 32768    0 0    0 
0 0

lo5 32768 127/8   127.0.0.1    0 0 0 0 0
lo6 32768    0 0    0 
0 0

lo6 32768 127/8   127.0.0.1    0 0 0 0 0
pair0   1500    fe:e1:ba:d0:ee:1c   264709 0 113933 
0 0
pair0   1500  172.16.0.1/ 172.16.0.1  264709 0 113933 
0 0
pair1   1500    fe:e1:ba:d1:57:88   113932 0 264782    
72 0
pair1   1500  172.16.0.2/ 172.16.0.2  113932 0 264782    
72 0

pair2   1500    fe:e1:ba:d2:15:01    4 0 55 0 0
pair2   1500  172.16.0.9/ 172.16.0.9   4 0 55 0 0
pair2   1500  fe80::%pair fe80::d3d3:891:63    4 0 55 0 0
pair2   1500  fd00::/64   fd00::1  4 0 55 0 0
pair3   1500    fe:e1:ba:d3:d6:54   52 0    5 
0 0

pair3   1500  172.16.0.10 172.16.0.10 52 0 5 0 0
pair3   1500  fe80::%pair fe80::4741:df8e:7   52 0 5 0 0
pair3   1500  fd00::/64   fd00::2 52 0 5 0 0
pppoe0  1492   220 0 80 8 0
pppoe0  1492  fe80::%pppo fe80::c24c:1e46:1  220 0 80 8 0
pppoe0  1492  xxx   220 0   80 8 0
trunk0  1518    fc:ec:da:40:fa:43   399449 0 391325    
28 0
vlan100 1500    fc:ec:da:40:fa:43   122281 0 271578 
0 0
vlan100 1500  192.168.131 192.168.131.251

may an edgerouter or pair / queue porblem

[Holger Glaess]

 hi


hi


my setup

edgerouter 6p with OpenBSD 6.5


an DSL line with up to 100Mbit

an Cable Line with 200/20 Mbit

the lines are separated my rdomain and connected to the main rdomain 0 
by pair interfaces


i dont use outbound loadbalancing but i delegate some traffic , example 
sip or IPv6 by PF.


the router are connected by a lacp trunk with 2 interfaces to the switch 
with a couple of vlans



all this work ,


my problem is that i dont get the full download speed at the cable line.


without queueing ig get just 150 Mbit , the is an buisness line that 
means the bandwidth is guarateed.



if i enable queueing ( inbound on my cable vlan outbound on the pair 
interface inside the cable rdom.



at netstat is see drops on some interfaces


Name    Mtu   Network Address  Ipkts Ifail Opkts Ofail Colls
lo0 32768   36 0   36 0 0
lo0 32768 ::1/128 ::1 36 0 36 0 0
lo0 32768 fe80::%lo0/ fe80::1%lo0 36 0 36 0 0
lo0 32768 127/8   127.0.0.1   36 0 36 0 0
cnmac0* 1500    fc:ec:da:40:fa:42    0 0    0 0 0
cnmac1  1518    fc:ec:da:40:fa:43   283008 0    83585 0 0
cnmac2  1518    fc:ec:da:40:fa:43   116607 0 307880 
0 0

cnmac3  1500    fc:ec:da:40:fa:45  551 0  264 0 0
cnmac3  1500  192.168.1/2 192.168.1.250  551 0 264 0 0
cnmac4* 1500    fc:ec:da:40:fa:46    0 0    0 0 0
cnmac5* 1500    fc:ec:da:40:fa:47    0 0    0 0 0
enc0    0    0 0    0 0 0
carp0   1500    00:00:5e:00:01:3c   119628 0  466 0 0
carp0   1500  192.168.131 192.168.131.250 119628 0 466 0 0
carp0   1500  fe80::%carp fe80::7c96:7198:9   119628 0 466 0 0
carp0   1500  fde0:911:91 fde0:911:911:2308   119628 0 466 0 0
carp1   1500    00:00:5e:00:01:3d  250 0  168 0 0
carp1   1500  10.0.0/24   10.0.0.1   250 0 168 0 0
carp2   1500    00:00:5e:00:01:3e 8059 0  182 0 0
carp2   1500  192.168.132 192.168.132.250   8059 0 182 0 0
carp2   1500  169.254/16  169.254.1.2   8059 0 182 0 0
carp3   1500    00:00:5e:00:01:3f    0 0  100 0 0
carp3   1500  192.168.134 192.168.134.250  0 0 100 0 0
carp6   1500    00:00:5e:00:01:42 1925 0  102 0 0
carp6   1500  192.168.135 192.168.135.250   1925 0 102 0 0
enc1    0    0 0    0 0 0
lo1 32768    0 0    0 0 0
lo1 32768 127/8   127.0.0.1    0 0 0 0 0
lo2 32768    0 0    0 0 0
lo2 32768 127/8   127.0.0.1    0 0 0 0 0
lo3 32768    0 0    0 0 0
lo3 32768 127/8   127.0.0.1    0 0 0 0 0
lo4 32768    0 0    0 0 0
lo4 32768 127/8   127.0.0.1    0 0 0 0 0
lo5 32768    0 0    0 0 0
lo5 32768 127/8   127.0.0.1    0 0 0 0 0
lo6 32768    0 0    0 0 0
lo6 32768 127/8   127.0.0.1    0 0 0 0 0
pair0   1500    fe:e1:ba:d0:ee:1c   264709 0 113933 
0 0
pair0   1500  172.16.0.1/ 172.16.0.1  264709 0 113933 
0 0
pair1   1500    fe:e1:ba:d1:57:88   113932 0 264782    
72 0
pair1   1500  172.16.0.2/ 172.16.0.2  113932 0 264782    
72 0

pair2   1500    fe:e1:ba:d2:15:01    4 0   55 0 0
pair2   1500  172.16.0.9/ 172.16.0.9   4 0 55 0 0
pair2   1500  fe80::%pair fe80::d3d3:891:63    4 0 55 0 0
pair2   1500  fd00::/64   fd00::1  4 0 55 0 0
pair3   1500    fe:e1:ba:d3:d6:54   52 0    5 0 0
pair3   1500  172.16.0.10 172.16.0.10 52 0 5 0 0
pair3   1500  fe80::%pair fe80::4741:df8e:7   52 0 5 0 0
pair3   1500  fd00::/64   fd00::2 52 0 5 0 0
pppoe0  1492   220 0   80 8 0
pppoe0  1492  fe80::%pppo fe80::c24c:1e46:1  220 0 80 8 0
pppoe0  1492  xxx   220 0   80 8 0
trunk0  1518    fc:ec:da:40:fa:43   399449 0 391325    
28 0
vlan100 1500    fc:ec:da:40:fa:43   122281 0 271578 
0 0
vlan100 1500  192.168.131 192.168.131.251 122281 0 271578 
0 0
vlan100 1500  fe80::%vlan fe80::50fc:1e18:9   122281 0 271578 
0 0
vlan100 1500  fde0:911:91