Wouldn't it be cool...!

2018-04-06 Thread Luke Small
What if you could set up a pf rule to:

overload an ip address into a table if they tried to access the wrong port
on an address and overload flush global immediately into a blocklist

(

max-src-states
0)!

or with max-src-conn-rate 2/60 when sshd behaves in such a manner as to
confirm that a successful connection has taken place, that max-src-conn-rate
gets reset for that connection so that you could log in and log out faster
than twice in a minute without getting put on a blocklist!


Re: Cannot access internet with virtual switch

2018-04-06 Thread Ayaka Koshibe
On Fri, Apr 6, 2018 at 4:40 PM, Aham Brahmasmi  wrote:
> Hello misc,
>
> Problem
> A physical server with a switch (add em0 up) cannot access the internet.
> However, the same host with a bridge (add em0 up) can access the
> internet.
>
> Steps
> $ ifconfig
> em0: flags=8843 mtu 1500
> lladdr 22:22:22:22:22:22
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (1000baseT full-duplex,master)
> status: active
> inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255
> ...
> $ doas route -n show
> Routing tables
>
> Internet:
> Destination GatewayFlags   Refs  Use   Mtu  Prio Iface
> default 20.20.20.1 UGS0 1XXX - 8 em0
> 224/4   127.0.0.1  URS00 32768 8 lo0
> 127/8   127.0.0.1  UGRS   00 32768 8 lo0
> 127.0.0.1   127.0.0.1  UHhl   1X 32768 1 lo0
> 20.20.20/24 20.20.20.20UCn1  9XX - 4 em0
> 20.20.20.1  33:33:33:33:33:33  UHLch  1 1XXX - 3 em0
> 20.20.20.20 44:44:44:44:44:44  UHLl   0X - 1 em0
> 20.20.20.25520.20.20.20UHb00 - 1 em0
> $ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms
> ...
> $ doas ifconfig switch0 create
> $ doas ifconfig switch0 add em0
> $ doas ifconfig switch0 up
> $ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> ^C
> --- 8.8.8.8 ping statistics ---
> 31 packets transmitted, 0 packets received, 100.0% packet loss

Hi,

Seems you haven't started switchd(8), or connected your switch to it
-- it shouldn't forward traffic until you do so.

> $ ifconfig
> em0: flags=8b43 mtu 
> 1500
> lladdr 22:22:22:22:22:22
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (1000baseT full-duplex,master)
> status: active
> inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255
> switch0: flags=41
> index 6 llprio 3
> groups: switch
> datapath xx maxflow 1 maxgroup 1000
> em0 flags=0<>
> port 1 ifpriority 0 ifcost 0
> ...
> $ doas route -n show
> Routing tables
>
> Internet:
> Destination GatewayFlags   Refs  Use   Mtu  Prio Iface
> default 20.20.20.1 UGS0 1XXX - 8 em0
> 224/4   127.0.0.1  URS00 32768 8 lo0
> 127/8   127.0.0.1  UGRS   00 32768 8 lo0
> 127.0.0.1   127.0.0.1  UHhl   1X 32768 1 lo0
> 20.20.20/24 20.20.20.20UCn1  9XX - 4 em0
> 20.20.20.1  33:33:33:33:33:33  UHLch  1 1XXX - 3 em0
> 20.20.20.20 44:44:44:44:44:44  UHLl   0X - 1 em0
> 20.20.20.25520.20.20.20UHb00 - 1 em0
> $ doas ifconfig switch0 destroy
> $ ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms
>
> Repeating the above steps with bridge0 does let the ping pass through
> after the bridge is brought up. The only delta between the switch and
> bridge output is in the ifconfig.
> $ ifconfig
> bridge0: flags=41
> index 8 llprio 3
> groups: bridge
> priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rtsp
> em0 flags=3
> port 1 ifpriority 0 ifcost 0
> ...
>
> I have run "doas route -n monitor" in a separate session while doing
> this. However, I cannot comprehend the output. pf is not involved -
> running tcpdump -nettti pflog0 with the catchall "block log" produces
> the normal output of blocked packets with the bridge. However, it stops
> producing the normal output of blocked packets with the switch. Once the
> switch is destroyed, it is back to normal blocked packets output.
>
> What am I doing wrong/missing? The only thing that stands out to me is
> the em0 flags=0<> line in the ifconfig for the switch. And I do not know
> what to make of it.
>
> Regards,
> ab
> -|-|-|-|-|-|-|--
>



[Arduino Library] Does WifiDriverInit() is missing in some package ?

2018-04-06 Thread Olivier Burelli
Hello all,

I would like to share my issue with the compilation of the sketch
provided by arduino.cc concerning the Wifi Whield.

After few try and some unrefferenced reference (IPAddress, WiFiDrv)...
as expected i edited the MAkefile:

LIBRARIES=SPI WiFi IPAddress WiFiDrv


Question:

as i still have an error message:

/usr/local/bin/avr-g++ -c -mmcu=atmega328p -I. -gstabs -DF_CPU=1600
-DARDUINO=100 -I/usr/local/share/arduino//cores/arduino
-I/usr/local/share/arduino//libraries/SPI
-I/usr/local/share/arduino//libraries/WiFi
-I/usr/local/share/arduino//libraries/IPAddress
-I/usr/local/share/arduino//libraries/WiFiDrv
-I/usr/local/share/arduino//libraries/SD
-I/usr/local/share/arduino//libraries/File
-I/usr/local/share/arduino//libraries/utility/SdFile
-I/usr/local/share/arduino//libraries/utility/SdVolume
-I/usr/local/share/arduino//libraries/utility/Sd2Card
-I/usr/local/share/arduino//libraries/SPI/utility/
-I/usr/local/share/arduino//libraries/WiFi/utility/
-I/usr/local/share/arduino//libraries/IPAddress/utility/
-I/usr/local/share/arduino//libraries/WiFiDrv/utility/
-I/usr/local/share/arduino//libraries/SD/utility/
-I/usr/local/share/arduino//libraries/File/utility/
-I/usr/local/share/arduino//libraries/utility/SdFile/utility/
-I/usr/local/share/arduino//libraries/utility/SdVolume/utility/
-I/usr/local/share/arduino//libraries/utility/Sd2Card/utility/
-I/usr/local/share/arduino//variants/standard -Os
-ffunction-sections
-fdata-sections /usr/local/share/arduino//cores/arduino/IPAddress.cpp
-o IPAddress.o 
make: don't know how to make WiFiDrv.o (prerequisite of:
applet/core.a) Stop in /home/olivier/Code/Arduino/Project/wifi


Did i miss something, something to do ?

Here, i am not sure to understand well, what happens, with avrdude or
avr-libc. 

Thanks in advance.



Cannot access internet with virtual switch

2018-04-06 Thread Aham Brahmasmi
Hello misc,

Problem
A physical server with a switch (add em0 up) cannot access the internet.
However, the same host with a bridge (add em0 up) can access the
internet.

Steps
$ ifconfig
em0: flags=8843 mtu 1500
lladdr 22:22:22:22:22:22
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255
...
$ doas route -n show
Routing tables

Internet:
Destination GatewayFlags   Refs  Use   Mtu  Prio Iface
default 20.20.20.1 UGS0 1XXX - 8 em0
224/4   127.0.0.1  URS00 32768 8 lo0
127/8   127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1   127.0.0.1  UHhl   1X 32768 1 lo0
20.20.20/24 20.20.20.20UCn1  9XX - 4 em0
20.20.20.1  33:33:33:33:33:33  UHLch  1 1XXX - 3 em0
20.20.20.20 44:44:44:44:44:44  UHLl   0X - 1 em0
20.20.20.25520.20.20.20UHb00 - 1 em0
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms
...
$ doas ifconfig switch0 create
$ doas ifconfig switch0 add em0
$ doas ifconfig switch0 up
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
31 packets transmitted, 0 packets received, 100.0% packet loss
$ ifconfig
em0: flags=8b43 mtu 
1500
lladdr 22:22:22:22:22:22
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 20.20.20.20 netmask 0xff00 broadcast 20.20.20.255
switch0: flags=41
index 6 llprio 3
groups: switch
datapath xx maxflow 1 maxgroup 1000
em0 flags=0<>
port 1 ifpriority 0 ifcost 0
...
$ doas route -n show
Routing tables

Internet:
Destination GatewayFlags   Refs  Use   Mtu  Prio Iface
default 20.20.20.1 UGS0 1XXX - 8 em0
224/4   127.0.0.1  URS00 32768 8 lo0
127/8   127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1   127.0.0.1  UHhl   1X 32768 1 lo0
20.20.20/24 20.20.20.20UCn1  9XX - 4 em0
20.20.20.1  33:33:33:33:33:33  UHLch  1 1XXX - 3 em0
20.20.20.20 44:44:44:44:44:44  UHLl   0X - 1 em0
20.20.20.25520.20.20.20UHb00 - 1 em0
$ doas ifconfig switch0 destroy
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=x.xxx ms

Repeating the above steps with bridge0 does let the ping pass through
after the bridge is brought up. The only delta between the switch and
bridge output is in the ifconfig.
$ ifconfig
bridge0: flags=41
index 8 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rtsp
em0 flags=3
port 1 ifpriority 0 ifcost 0
...

I have run "doas route -n monitor" in a separate session while doing
this. However, I cannot comprehend the output. pf is not involved -
running tcpdump -nettti pflog0 with the catchall "block log" produces
the normal output of blocked packets with the bridge. However, it stops
producing the normal output of blocked packets with the switch. Once the
switch is destroyed, it is back to normal blocked packets output.

What am I doing wrong/missing? The only thing that stands out to me is
the em0 flags=0<> line in the ifconfig for the switch. And I do not know
what to make of it.

Regards,
ab
-|-|-|-|-|-|-|--



OpenBSD-based network switch with >16 GigE ports.

2018-04-06 Thread Karel Gardas


Hello,

I'm looking to buy a new switch for house network. Ideally I'd like to setup 
everything here on OpenBSD, but I'm not lucky
to find any OpenBSD-based switch. I need just GigE ports, at least 18-20. 
Preferably fanless. 1-2U shallow depth into small rack.
I know all those Marvells, Broadcoms etc. holding majority in switch business 
with strict NDAs are not OpenBSD friendly, but
still hope something may have slipped from my sight.

Any advice appreciated.

Thanks!
Karel



Re: Documenting library promises.

2018-04-06 Thread Theo de Raadt
Ingo Schwarze  wrote:

> Hi Kristaps,
> 
> Kristaps Dzonsons BSD.LV wrote on Sat, Apr 07, 2018 at 01:37:32AM +0700:
> 
> > The only reason I suggest a standalone section is that it's easier
> > to standardise across manpages.
> 
> For that goal, using ".Ss Pledge promises"
> at the end of the DESCRIPTION might work.
> 
> For now, such consistency would be local to the ksql package (and
> maybe some related packages like kcgi?), and i don't anticipate a
> large number of other non-base libraries that want to integrate
> with pledge(2) in the near future.  But even if some other libraries
> pick it up from there, that wouldn't seem undesirable to me.

BTW, there is another approach:

Describe what your function does properly.

For instance, use terminology that a libc-level programmer will
recognize as implying use of particular libc interfaces, which they can
mentally maps back pledge concepts.

(This reminds me of the warts in libc we got rid of -- to allow the
creation of pledge.  syslog() doesn't use sockets.  DNS is a special
socket, and regular sockets can't do DNS.  isatty() is used extensively
in libc, so it abstracted out to ensure ioctl is taken away.  Various
things like this were taken away inside libc, so that programmers don't
need to be shocked "That operation seems so simple, why does it do
something so complicated which I never expected?"



Re: OpenBSD VMM VMs Crash

2018-04-06 Thread Carlos Cardenas
On Fri, Apr 06, 2018 at 06:55:05PM +0200, Aaron Marcher wrote:
> Ohai,
> 
> for me OpenBSD VMM VMs crash after some (undefined) time while logging the
> following on the host:
> vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument
> Apart from that VMM works es expected.
> 
> Regards,
> Aaron
> 
> -- 
> Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/
> Gopher: gopher://drkhsh.at or gopher://drkhsh5rv6pnahas.onion
> GPG: 0x7A65E38D55BE96FE
> Fingerprint: 4688 907C 8720 3318 0D9F AFDE 7A65 E38D 55BE 96FE
> 

Aaron,

This is not a very good bug report.

Please provide the following information:
* dmesg of host
* vm.conf
* Guest information (dmesg if OpenBSD)
* What is the guest doing when it dies?
* What is the host doing when the guest dies?

+--+
Carlos



Re: OpenBSD VMM VMs Crash

2018-04-06 Thread Mike Larkin
On Fri, Apr 06, 2018 at 06:55:05PM +0200, Aaron Marcher wrote:
> Ohai,
> 
> for me OpenBSD VMM VMs crash after some (undefined) time while logging the
> following on the host:
> vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument
> Apart from that VMM works es expected.
> 
> Regards,
> Aaron
> 
> -- 
> Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/
> Gopher: gopher://drkhsh.at or gopher://drkhsh5rv6pnahas.onion
> GPG: 0x7A65E38D55BE96FE
> Fingerprint: 4688 907C 8720 3318 0D9F AFDE 7A65 E38D 55BE 96FE
> 

could be anything. enable VMM_DEBUG and send me what you see in dmesg
after the crash.




Re: Documenting library promises.

2018-04-06 Thread Ingo Schwarze
Hi Kristaps,

Kristaps Dzonsons BSD.LV wrote on Sat, Apr 07, 2018 at 01:37:32AM +0700:

> The only reason I suggest a standalone section is that it's easier
> to standardise across manpages.

For that goal, using ".Ss Pledge promises"
at the end of the DESCRIPTION might work.

For now, such consistency would be local to the ksql package (and
maybe some related packages like kcgi?), and i don't anticipate a
large number of other non-base libraries that want to integrate
with pledge(2) in the near future.  But even if some other libraries
pick it up from there, that wouldn't seem undesirable to me.

> How about .Sh RESOURCES?

I don't like that because the term "resources" is so broad that it
is hard for users to guess what they might find there.  Maybe
something related to X11, or to setrlimit(2), or books and mailing
lists on the subject?  Also, trying to standardize a section requires
that the section is widely needed and that the subject matter is
very mature.  Premature attempts to standardize new top-level
sections, mostly in other operating systems, already left us with
various half-dead sections that are not being used consistently and
of doubtful utility (LIBRARY, IMPLEMENTATION NOTES, SECURITY
CONSIDERATIONS, ..., not even talking about what OpenSolaris /
illumos did).

> This would also fit other systems like Capsicum.
> Though in practice, I think we'll find only pledge documented there.

Then i'd suggest to not try to plan ahead for theoretical ideas
that are not likely to get done at all.  Besides, as Theo said,
Capsicum is so different from pledge(2) that what is possible with
pledge(2) likely cannot be done with Capsicum - regarding documentation
just like regarding consistent application to the complete codebase
of a whole operating system.

Yours,
  Ingo



OpenBSD VMM VMs Crash

2018-04-06 Thread Aaron Marcher

Ohai,

for me OpenBSD VMM VMs crash after some (undefined) time while logging 
the following on the host:

vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Invalid argument
Apart from that VMM works es expected.

Regards,
Aaron

--
Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/
Gopher: gopher://drkhsh.at or gopher://drkhsh5rv6pnahas.onion
GPG: 0x7A65E38D55BE96FE
Fingerprint: 4688 907C 8720 3318 0D9F AFDE 7A65 E38D 55BE 96FE



Re: Documenting library promises.

2018-04-06 Thread Theo de Raadt
Kristaps Dzonsons  wrote:

> The only reason I suggest a standalone section is that it's easier to
> standardise across manpages.

I do not see a way to do this in libc.  So standardise isn't really
required.  You are talking about doing this in a port library, not a
base library.

I don't know how we would do this in a base library, without being
overly specific and screwing ourselves in the future somehow.  It feels
too early to give pledge a formal specification.


> How about .Sh RESOURCES?  This would also fit other systems like
> Capsicum.  Though in practice, I think we'll find only pledge documented
> there.

You really think you'll find common ground??  I'm extremely sceptical.
The underlying concepts couldn't be different.  pledge disables "grouped
actions" taken against objects, whereas capsicum reduces ability to gain
new objects but generally leaves all style of actions intact.  A pledge
context can be described in 2-3 words, but capsicum is a heavy
environment one cannot describe so easily.

Also, don't want capsicum or any other non-OpenBSD described in OpenBSD
manual pages.  What you do in your own pages is your own concern, but
then premature standardization doesn't matter.



Re: Documenting library promises.

2018-04-06 Thread Kristaps Dzonsons
>> .Sh SANDBOXING
>> On
>> .Ox ,
>> the
>> .Fn khttp_parse
>> function requires the
>> .Qq stdio proc
>> promises to
>> .Xr pledge 2 .
> 
> As long as it is only a single sentence, that could easily go right
> after the description of the individual function in the DESCRIPTION,
> or alternatively at the end of the DESCRIPTION section.  Custom
> sections are not very nice, in particular when they are so short
> that they hardly justify opening a new section in the first place.
> 
> If you really want to describe multiple different sandboxing
> systems, then i guess ".Sh SANDBOXING" after the DESCRIPTION
> might make sense.  I'm not all that sure that describing any other
> system will be possible without going overboard; they are typically
> much too complicated to be summarized without excessive verbosity.
> But you shall no doubt see whether or not it works...

Ingo,

The only reason I suggest a standalone section is that it's easier to
standardise across manpages.  Saying "it should go after the function"
is too open to interpretation.  Moreover, some functions may have
varying promises depending upon function parameters, which will rapidly
eat into space better left to the functions themselves.

How about .Sh RESOURCES?  This would also fit other systems like
Capsicum.  Though in practice, I think we'll find only pledge documented
there.

Best,

Kristaps



Re: Documenting library promises.

2018-04-06 Thread Theo de Raadt
> .Sh SANDBOXING

And please stop using that word.  It has been misused so many
times, by now it is misleads.

pledge is not a sandbox (whatever the hell a sandbox is)



Re: Documenting library promises.

2018-04-06 Thread Ingo Schwarze
Hi Kristaps,

Kristaps Dzonsons BSD.LV wrote on Fri, Apr 06, 2018 at 09:57:09PM +0700:

> Short: what do you recommend for documenting an external library's
> pledge(2) requirements?

That is an interesting question indeed.  I never considered it
before, so i will think about it in some detail.

For a bit of context, let me first explain how documentation of
pledge(2) requirements inside the OpenBSD C library itself works,
and why the documentation was designed that way.

On first sight, it might seem most user-friendly if each and every
section 3 manual page for the C library would state the pledge(2)
requirements for each individual library function.

But that would have three important downsides:

 (1) It would be hard to do.  There are very many manual pages,
 so it would require much work for initial setup.

 (2) It would be unmaintainable, in particular while pledge(2)
 is still in very active development.  Pledge evolved through
 incremental tweaking.  Usage patterns were studied and modeled,
 the resulting pledge promises applied across the whole three,
 and the resulting experience allowed to refine the analysis
 and improve the way pledge(2) itself worked, based on real-world
 usage.  Rinse and repeat, literally dozens of times, over years
 of careful work.  Keeping many hundred manual pages in sync
 with that gradual evolution would have been flat-out impossible.

 (3) It would have put the focus in the wrong place.
 One among the chief ideas of pledge(2) is to avoid the splintered
 character of traditional syscall filters, where you are forced
 to filter each syscall, or even worse each of the arguments
 of each syscall, individually, and consequently completely lose
 the overview of what you are really doing before you even get
 started.  Instead, pleadge promises enable high-level logical
 feature groups.  The essential job of pledge(2) documentation
 is not to say that the FOO promise enables the BAR argument
 of the BAZ syscall, but that pledging FOO is required when you
 want to do operations of the BAR kind, no matter with which
 calls or arguments.

 Of course, once pledge(2) is completely stable, there would
 be nothing wrong with *also* documenting the effect in individual
 library functions manuals for user convenience, even though
 that would imply some redundancy.  But given that pledge(2)
 is still quite actively worked on, i doubt it will happen soon,
 if ever at all.

That said, for external libraries, putting your stuff directly into
the pledge(2) manual is obviously not an option.  Also, i agree
that documenting pledge(2) requirements for external libraries
is very useful, because these requirements are often quite
non-obvious and hard to guess by just looking at the pledge(2)
manual page itself, because many library manuals intentionally,
and sensibly, do not document how exactly the library operates
internally.

Note that for external libraries, the above arguments do not
apply:

 (1) Well-designed external libraries have small numbers of
 functions, so problem (1) is not a concern.

 (2) The logical functionality of functions in external libraries
 is hopefully mostly stable, and the required promises will
 rarely be affected by changes in pledge(2) itself.  Also,
 pledge(2) has already stabilized considerably, so problem (2)
 is no longer a major concern - though a bit of maintenace
 may be required now and then if you put such information
 into your manual pages.

 (3) The pledge(2) manual explains the high-level logic, your
 manuals add the specifics for your library, without
 duplication of information.  That is a clean division
 of tasks, so problem (3) is not a concern.

> Longer: https://bsd.network/@florian/99802355448571943
> 
> The question raised in this... um... toot?... is which promises are
> required by an external library call, in this case khttp_parse(3) in
> kcgi.  Sure, we can always just run the program, look in
> /var/log/messages for failure, and edit our promises.  But just... no.
> 
> In this particular case, I've documented this function's requirements
> unofficially here and there---tutorials and such.  But it's not
> canonical.  What I'd like is to put these directly into the manpages.

Absolutely agreed.  "Complete functional description in one
canonical place, do not scatter reference-manual-type information
across multiple sources" is among the most important requirements
for good documentation.

> .Sh SANDBOXING
> On
> .Ox ,
> the
> .Fn khttp_parse
> function requires the
> .Qq stdio proc
> promises to
> .Xr pledge 2 .

As long as it is only a single sentence, that could easily go right
after the description of the individual function in the DESCRIPTION,
or alternatively at the end of the DESCRIPTION section.  Custom
sections are not very nice, in particular when they are so short
that they hardly 

Documenting library promises.

2018-04-06 Thread Kristaps Dzonsons
Hi folks,

Short: what do you recommend for documenting an external library's
pledge(2) requirements?

Longer: https://bsd.network/@florian/99802355448571943

The question raised in this... um... toot?... is which promises are
required by an external library call, in this case khttp_parse(3) in
kcgi.  Sure, we can always just run the program, look in
/var/log/messages for failure, and edit our promises.  But just... no.

In this particular case, I've documented this function's requirements
unofficially here and there---tutorials and such.  But it's not
canonical.  What I'd like is to put these directly into the manpages.

Something like:

.Sh SANDBOXING
On
.Ox ,
the
.Fn khttp_parse
function requires the
.Qq stdio proc
promises to
.Xr pledge 2 .

This encourages developers to use the tightest possible promises.  And
as mdoc(7) is meant not to be system-specific, this might also include
information on, say, .Fx's Capsicum, or maybe whatever Linux uses this
week.  It already has "SECURITY CONSIDERATIONS", but that just doesn't
seem quite right.

Thoughts?

Kristaps



is gif(4) not backward compatible between 6.3 and 6.2?

2018-04-06 Thread Peter J. Philipp
Hi,

I am in need of setting up an IPV4 tunnel over IPv6 in gif between a
6.3-current and a 6.2 router.  Only I'm not able to establish the
tunnel.  In revision 1.109 of /sys/net/if_gif.c there went a change that
changed the next header (protocol) to IPPROTO_GRE (protocol 47?) and
that's what I'm observing on the 6.2 box is that it doesn't recognize
the GRE becuase it might be expecting IPENCAP (protocol 4?).

Am I forced to bring the 6.2 box to 6.3?  Or is this a bug that crept
in?  Inline is a tcpdump:

16:19:27.803168 (authentic,confidential): SPI 0xf24bfe38:
fd43:5602:29bd:16:0:de
ad:beef:1 > fd43:5602:29bd:16:0:dead:beef:16:
fd43:5602:29bd:16:0:dead:beef:1 >
fd43:5602:29bd:16:0:dead:beef:16: [R] 5400 sum 0x4e38 off 0x0
(rtaf=0xff01) (rta
f=0x2526)[|gre] (len 84, hlim 64) (len 124, hlim 64)
  : 6000  007c 2940 fd43 5602 29bd 0016 
`|)@.CV.)... 
  0010:  dead beef 0001 fd43 5602 29bd 0016  .CV.)...
  0020:  dead beef 0016 6000  0054 2f40  `T/@
  0030: fd43 5602 29bd 0016  dead beef 0001  .CV.)...
  0040: fd43 5602 29bd 0016  dead beef 0016  .CV.)...
  0050: 4500 0054 4e38  ff01 f535 ac10 100a  E..TN8.5
  0060: ac10 1010 0800 8cc6 a056  fec7 b8c0  .V..
  0070: 72b7 f575 4327 4fda 71dd 45a5 ff30 7ec4  r..uC'O.q.E..0~.
  0080: 1315 5d1b 1819 1a1b 1c1d 1e1f 2021 2223  ..]. !"#
  0090: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
  00a0: 3435 3637    4567

16:19:27.803207 (authentic,confidential): SPI 0x0f8c22de:
fd43:5602:29bd:16:0:de
ad:beef:16 > fd43:5602:29bd:16:0:dead:beef:1:
fd43:5602:29bd:16:0:dead:beef:16 >
 fd43:5602:29bd:16:0:dead:beef:1: icmp6: parameter problem next header -
octet 6
 [icmp6 cksum ok] (len 132, hlim 64) (len 172, hlim 64)
  : 6000  00ac 2940 fd43 5602 29bd 0016  `.)@.CV.)...
  0010:  dead beef 0016 fd43 5602 29bd 0016  .CV.)...
  0020:  dead beef 0001 6000  0084 3a40  `.:@
  0030: fd43 5602 29bd 0016  dead beef 0016  .CV.)...
  0040: fd43 5602 29bd 0016  dead beef 0001  .CV.)...
  0050: 0401 009c  0006 6000  0054 2f40  `T/@
  0060: fd43 5602 29bd 0016  dead beef 0001  .CV.)...
  0070: fd43 5602 29bd 0016  dead beef 0016  .CV.)...
  0080: 4500 0054 4e38  ff01 f535 ac10 100a  E..TN8.5
  0090: ac10 1010 0800 8cc6 a056  fec7 b8c0  .V..
  00a0: 72b7 f575 4327 4fda 71dd 45a5 ff30 7ec4  r..uC'O.q.E..0~.
  00b0: 1315 5d1b 1819 1a1b 1c1d 1e1f 2021 2223  ..]. !"#
  00c0: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
  00d0: 3435 3637    4567



Regards,

-peter



Issues with relayd

2018-04-06 Thread Matt Schwartz

Hi misc@

I am running relayd as a reverse TLS proxy on OpenBSD 6.3 release with 
the GENERIC kernel. I have noticed two issues that happen: (1) netstat 
reports that the Recv-q for the ip protocol steadily climbs and never 
goes back to 0 unless I restart relayd and (2) I am getting a lot of 
spurious TLS handshake errors that I can't pin down. I am running relayd 
with relayd -vv logging. Below is output from my relayd.log and dmesg.


Thanks,

Matt

/var/log/relayd:

Apr  5 23:45:43 panther relayd[94018]: startup
Apr  5 23:46:08 panther relayd[43579]: relay_tls_transaction: session 1: 
scheduling on EV_READ
Apr  5 23:46:08 panther relayd[43579]: relay ghost, tls session 1 
established (1 active)
Apr  5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 2: 
scheduling on EV_READ
Apr  5 23:46:15 panther relayd[43579]: relay ghost, tls session 2 
established (1 active)
Apr  5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 3: 
scheduling on EV_READ
Apr  5 23:46:15 panther relayd[43579]: relay ghost, tls session 3 
established (1 active)
Apr  5 23:46:15 panther relayd[43579]: relay_tls_transaction: session 4: 
scheduling on EV_READ
Apr  5 23:46:15 panther relayd[11143]: relay_tls_transaction: session 1: 
scheduling on EV_READ
Apr  5 23:46:15 panther relayd[43579]: relay ghost, tls session 4 
established (2 active)
Apr  5 23:46:15 panther relayd[11143]: relay ghost, tls session 1 
established (1 active)
Apr  5 23:46:21 panther relayd[11143]: relay_tls_transaction: session 2: 
scheduling on EV_READ
Apr  5 23:46:22 panther relayd[11143]: relay ghost, tls session 2 
established (1 active)
Apr  5 23:47:04 panther relayd[11143]: relay_tls_transaction: session 3: 
scheduling on EV_READ
Apr  5 23:47:04 panther relayd[11143]: relay ghost, tls session 3 
established (1 active)
Apr  5 23:47:09 panther relayd[11143]: relay_tls_transaction: session 4: 
scheduling on EV_READ
Apr  5 23:47:09 panther relayd[11143]: relay ghost, tls session 4 
established (2 active)
Apr  5 23:47:09 panther relayd[73657]: relay_tls_transaction: session 1: 
scheduling on EV_READ
Apr  5 23:47:09 panther relayd[11143]: relay_tls_transaction: session 5: 
scheduling on EV_READ
Apr  5 23:47:09 panther relayd[73657]: relay ghost, tls session 1 
established (1 active)
Apr  5 23:47:09 panther relayd[11143]: relay ghost, tls session 5 
established (1 active)
Apr  5 23:48:23 panther relayd[73657]: relay_tls_transaction: session 2: 
scheduling on EV_READ
Apr  5 23:48:23 panther relayd[73657]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402610B:SSL 
routines:ACCEPT_SR_CLNT_HELLO:wrong version number
Apr  5 23:48:23 panther relayd[73657]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:23 panther relayd[73657]: relay_tls_transaction: session 3: 
scheduling on EV_READ
Apr  5 23:48:23 panther relayd[73657]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402710B:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number
Apr  5 23:48:23 panther relayd[73657]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:24 panther relayd[73657]: relay_tls_transaction: session 4: 
scheduling on EV_READ
Apr  5 23:48:24 panther relayd[73657]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402710B:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number
Apr  5 23:48:24 panther relayd[73657]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:24 panther relayd[43579]: relay_tls_transaction: session 5: 
scheduling on EV_READ
Apr  5 23:48:24 panther relayd[43579]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402710B:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number
Apr  5 23:48:24 panther relayd[43579]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:24 panther relayd[73657]: relay_tls_transaction: session 5: 
scheduling on EV_READ
Apr  5 23:48:24 panther relayd[73657]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:1402710B:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:wrong version number
Apr  5 23:48:24 panther relayd[73657]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:24 panther relayd[43579]: relay_tls_transaction: session 6: 
scheduling on EV_READ
Apr  5 23:48:24 panther relayd[43579]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: unexpected EOF
Apr  5 23:48:24 panther relayd[43579]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:25 panther relayd[43579]: relay_tls_transaction: session 7: 
scheduling on EV_READ
Apr  5 23:48:25 panther relayd[43579]: TLS handshake failed: ghost: 
relay_tls_handshake: handshake failed: error:140270C1:SSL 
routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher
Apr  5 23:48:25 panther relayd[43579]: relay_close: sessions inflight 
decremented, now 0
Apr  5 23:48:25 panther relayd[11143]: relay_tls_transaction: session 6: 
scheduling on EV_READ
Apr  5 

Re: Compilations errors with plan9port on 2018/04/05 snapshot

2018-04-06 Thread Patrick Marchand
On 04/05, Philip Guenther wrote:
> On Thu, Apr 5, 2018 at 9:50 PM, Philip Guenther  wrote:
> 
> > On Thu, Apr 5, 2018 at 7:53 PM, Patrick Marchand  > > wrote:
> >
> >> Output of compiling plan9port on amd64 with the april 5 snaphot
> >>
> > ...
> >
> >> ===>  Patching for plan9port-20180117
> >> Segmentation fault (core dumped)
> >> *** Warning in /usr/ports/plan9/plan9port: "uname -m" returned non-zero
> >>
> >
> > dmesg from this box, please.
> >
> 
> Also, does this segfault happen consistently at that same exact spot, or is
> it inconsistent?

It appears to be inconsistent, I've joined a file containing a few
failed runs and another with the dmesg.
OpenBSD 6.3-current (GENERIC.MP) #135: Thu Apr  5 12:31:23 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8261529600 (7878MB)
avail mem = 8004067328 (7633MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries)
bios0: vendor LENOVO version "N14ET42W (1.20 )" date 09/13/2017
bios0: LENOVO 20BTS0Y500
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.59 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
acpihpet0: recalibrated TSC frequency 2593996580 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.22 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.22 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.22 MHz
cpu3: 
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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 3 (EXP1)
acpiprt3 at acpi0: bus 4 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 10 (EXP6)
acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1
acpipwrres1 at acpi0: NVP3, resource for PEG_
acpipwrres2 at acpi0: NVP2, 

Re: iwi(4) fatal firmware error

2018-04-06 Thread Ax0n
On Thu, Apr 5, 2018 at 3:37 AM, Stefan Sperling  wrote:
>
> Is this a purely cosmetic issue or does it actually prevent your
> wifi connection from working?
>
> These looks like potentially harmless errors which happen during
> association.
> Does the driver recover from these errors automatically? It should be able
> to.
>
> As to why the firmware reports such errors: We have no idea. It's a black
> box.
>

As far as I can tell, it recovers. Lately, it's been doing it at odd hours
when I'm
not actually using it, but I've never come back to it being disconnected or
anything like that. I had it next to me streaming music with Pianobar for a
few hours yesterday without any hiccups. I'll just ignore these. Thanks,
stsp!


The modesetting driver uses acceleration or not?

2018-04-06 Thread Zsolt Kantor
Hello,

In the modesetting video driver man page states that it is a non-accelerated 
driver, but you have a option to set the acceleration method. If it is 
non-accelerated driver why can you set the acceleration?

Thanks.