Re: routing q

2015-10-19 Thread Martin Pieuchot 
On 19/10/15(Mon) 13:37, Gregory Edigarov wrote:
> On 10/19/2015 01:24 PM, Stuart Henderson wrote:
> >On 2015-10-19, Gregory Edigarov  wrote:
> >>In order to conserve address space I am trying to confugure 'ip
> >>unnumbred' in cisco terminology, that is have an interface borrow the ip
> >>of a different interface, I am experimenting with vether0 and vlans the
> >>thing is to have one 'main' address on some 'real' interface and then
> >>just add routes pointing to the right interfaces.
> >>
> >># ifconfig vether0 192.168.100.1/24 up
> >># ifconfig vlan2 vlandev vether0 up
> >># ifconfig vlan3 vlandev vether0 up
> >># route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
> >>route: writing to routing socket: Network is unreachable
> >>add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable
> >>
> >>the same result I have if I am trying to configure this on a real
> >>interface connected  to my network:
> >>
> >># ifconfig vlan2 vlandev re0
> >># ifconfig vlan3 vlandev re0
> >># ifconfig re0 alias 192.168.100.1
> >># route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
> >>route: writing to routing socket: Network is unreachable
> >>add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable
> >>
> >># uname -a
> >>OpenBSD lbld12.duckdns.org 5.8 GENERIC.MP#1507 amd64
> >>
> >>I thoght OpenBSD supports such thing.
> >>
> >>am I missing something?
> >I don't *think* this is expected to work at the moment unless possibly
> >you specify a destination MAC address with -link.
> >
> >It does work with point-to-point interfaces, e.g. you can have
> >192.0.2.1/28 on em0 and 192.0.2.1/32 on pppoe0 and things will work
> >as expected, but in that case you don't have a problem of picking a
> >particular link-layer address, just "the pppoe0 interface" is enough
> >information for the system to know where to send the packet.
> >
> >The best I've done so far for address conservation on ethernet-like
> >interfaces is to use /31's (which works well).
> >
> Yes, I know /31 would work correctly, but I wanted further space
> conservation.

Does it?

> Is that a correct explanation that this does not work because  our routing
> table still wants a link layer address, errrmmm,  arp table is  included in
> routing table?

I believe it's simpler than that.  You cannot attach a route to an
interface without address, so I'm quite sure it will work if you add
an address to vlan2.

Re: routing q

2015-10-19 Thread Gregory Edigarov 

On 10/19/2015 02:14 PM, Martin Pieuchot wrote:

On 19/10/15(Mon) 13:37, Gregory Edigarov wrote:

On 10/19/2015 01:24 PM, Stuart Henderson wrote:

On 2015-10-19, Gregory Edigarov  wrote:

In order to conserve address space I am trying to confugure 'ip
unnumbred' in cisco terminology, that is have an interface borrow the ip
of a different interface, I am experimenting with vether0 and vlans the
thing is to have one 'main' address on some 'real' interface and then
just add routes pointing to the right interfaces.

# ifconfig vether0 192.168.100.1/24 up
# ifconfig vlan2 vlandev vether0 up
# ifconfig vlan3 vlandev vether0 up
# route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
route: writing to routing socket: Network is unreachable
add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable

the same result I have if I am trying to configure this on a real
interface connected  to my network:

# ifconfig vlan2 vlandev re0
# ifconfig vlan3 vlandev re0
# ifconfig re0 alias 192.168.100.1
# route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
route: writing to routing socket: Network is unreachable
add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable

# uname -a
OpenBSD lbld12.duckdns.org 5.8 GENERIC.MP#1507 amd64

I thoght OpenBSD supports such thing.

am I missing something?

I don't *think* this is expected to work at the moment unless possibly
you specify a destination MAC address with -link.

It does work with point-to-point interfaces, e.g. you can have
192.0.2.1/28 on em0 and 192.0.2.1/32 on pppoe0 and things will work
as expected, but in that case you don't have a problem of picking a
particular link-layer address, just "the pppoe0 interface" is enough
information for the system to know where to send the packet.

The best I've done so far for address conservation on ethernet-like
interfaces is to use /31's (which works well).


Yes, I know /31 would work correctly, but I wanted further space
conservation.

Does it?


Is that a correct explanation that this does not work because  our routing
table still wants a link layer address, errrmmm,  arp table is  included in
routing table?

I believe it's simpler than that.  You cannot attach a route to an
interface without address, so I'm quite sure it will work if you add
an address to vlan2.
yes, adding a route works now.  thanks, Martin. will test some further 
later.

Re: Linux crypt(3)

2015-10-19 Thread Adam Wysocki 
Thank you for all the replies!

On Sat, 17 Oct 2015, Devin Reade wrote:

> As you're looking into solutions, make sure you're looking at the right
> problem. Your text sounds like you're migrating system account passwords,

I'm not. These are passwords for the news server. Users are authenticated 
using ckpasswd, which uses crypt().

On Sat, 17 Oct 2015, Adam Wolk wrote:

> Don't know if it works out for you but you could generate ssh keys for
> existing accounts and allow users to access the new system using that
> provided ssh key & set the passwords themselves (or just keep using key
> auth and disabling passwords :)).

I don't want to force users to do anything, I want this change to be 
transparent to them...

-- 
"qui hic minxerit aut cacaverit, habeat deos superos et inferos iratos"

Re: Install on compact flash

2015-10-19 Thread Stuart Henderson 
On 2015-10-19, Paolo Aglialoro  wrote:
> On Mon, Oct 19, 2015 at 12:27 PM, Stuart Henderson  
> wrote:
>
>> Some devices get chown()ed during normal system operation, see fbtab(5).
>
> Does this mean that write access on files in /dev is limited just to
> permissions change and, therefore, just some bytes of change in the
> filesystem? This seems pretty much acceptable for me in terms of CF
> wear-off, if it does not happen with a high frequence.

Timestamps are updated as well. But I don't think wear-off is really
a problem for any kind of normal use. It's certainly less of a problem
than the need to handle a separate /dev partition and make sure that
things are kept in-sync through OS updates.

If you're worried about it you could get a larger card than you need
and leave some space unused to give a bigger pool for wear-levelling.

iked & nat-t problem (no keep alive)

2015-10-19 Thread igyht 
I am testing iked on OpenBSD phobos 5.7 GENERIC#738 i386, I think there is
keep-alive problem when use with NAT-T, 
detailed configurations are:

 

http://daemonforums.org/showthread.php?t=9446

 

I think, iked & nat-t need some kind of "keep alive", but I can't find it in
iked.conf configuration. Any idea?

 

igy

Re: Install on compact flash

2015-10-19 Thread Paolo Aglialoro 
Does this mean that write access on files in /dev is limited just to
permissions change and, therefore, just some bytes of change in the
filesystem? This seems pretty much acceptable for me in terms of CF
wear-off, if it does not happen with a high frequence.


On Mon, Oct 19, 2015 at 12:27 PM, Stuart Henderson 
wrote:

>
> Some devices get chown()ed during normal system operation, see fbtab(5).

Re: Remove removed utilities?

2015-10-19 Thread Nick Holland 
On 10/19/15 04:24, Raimo Niskanen wrote:
> Hello misc@
> 
> I just noticed from the detailed changelog 5.7->5.8:
> http://www.openbsd.org/plus58.html
> that e.g tcopy, tip and lmccontrol were removed, but after upgrading from
> 5.7 to 5.8 I still have /usr/bin/tip, /usr/bin/tcopy and /sbin/lmccontrol
> in the filesystem, with old dates.
> 
> The upgrade guide:
> http://www.openbsd.org/faq/upgrade58.html
> listed files to remove concerning the removed sudo, but nothing about
> the utilities above.
> 
> There are also more old files hanging around, e.g:
> /usr/bin/perl5.20.1
> /usr/bin/perlthanks
> and in /usr/lib there are old versions of libtls, libssl, libkvm, libedit,
> libcrypt, libc, etc...
> 
> I vaguely remember reading something about old libraries remaining after an
> upgrade, but can not find it now, at least not up front in the FAQ.
> 
> So my question is; should these old utilities be removed after upgrading to
> 5.8?  And what about old libraries?

We used to have a little disclaimer that upgrading was not equivalent to
wiping and reloading with the new version; yes, stuff will get left
behind.  It was decided the upgrade docs were too big and scary so that
was one of the things removed to shorten it up (see older versions, like
upgrade55.html, for example).

Things that are out-right replaced (i.e., sudo) should be actively
deleted.  Even if it still works after upgrade, some day it is going to
break, and you should be pushed to use the new application (or the
package of the old application).  Things like tip?  what's the point?
  case 1) It still works.  No harm done.
  case 2) It no longer works.  useless file on system...so what?
Either way...no harm.

Library files are far more "interesting"...depending on the upgrade,
they still may work with old packages still on the system.  Delete them,
you have broken the old packages before you got them upgraded, usually
no big deal, but sometimes, may really annoy you.

Again... who cares?  Yes, after ten upgrades, old libraries can start to
add up, but on a modern system, you will go through a lot of upgrades
before you can save a GB of data deleting old stuff.  Just not worth the
trouble.

Quoting upgrade55.html:
"However, the results are not intended to precisely match the results of
a wipe-and-reload installation. Old library files in particular are not
removed in the upgrade process, as they may be required by older
applications that may or may not be upgraded at this time. If you REALLY
wish to get rid of all these old files, you are probably better off
reinstalling from scratch."

If OCD is causing you to twitch at seeing the old files, reinstall...or
use this as a therapy.

Nick.

routing q

2015-10-19 Thread Gregory Edigarov 

Hello,

In order to conserve address space I am trying to confugure 'ip 
unnumbred' in cisco terminology, that is have an interface borrow the ip 
of a different interface, I am experimenting with vether0 and vlans the 
thing is to have one 'main' address on some 'real' interface and then 
just add routes pointing to the right interfaces.


# ifconfig vether0 192.168.100.1/24 up
# ifconfig vlan2 vlandev vether0 up
# ifconfig vlan3 vlandev vether0 up
# route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
route: writing to routing socket: Network is unreachable
add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable

the same result I have if I am trying to configure this on a real 
interface connected  to my network:


# ifconfig vlan2 vlandev re0
# ifconfig vlan3 vlandev re0
# ifconfig re0 alias 192.168.100.1
# route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
route: writing to routing socket: Network is unreachable
add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable

# uname -a
OpenBSD lbld12.duckdns.org 5.8 GENERIC.MP#1507 amd64

I thoght OpenBSD supports such thing.

am I missing something?

--
With best regards,
Gregory Edigarov

Re: routing q

2015-10-19 Thread Stuart Henderson 
On 2015-10-19, Gregory Edigarov  wrote:
> In order to conserve address space I am trying to confugure 'ip 
> unnumbred' in cisco terminology, that is have an interface borrow the ip 
> of a different interface, I am experimenting with vether0 and vlans the 
> thing is to have one 'main' address on some 'real' interface and then 
> just add routes pointing to the right interfaces.
>
> # ifconfig vether0 192.168.100.1/24 up
> # ifconfig vlan2 vlandev vether0 up
> # ifconfig vlan3 vlandev vether0 up
> # route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
> route: writing to routing socket: Network is unreachable
> add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable
>
> the same result I have if I am trying to configure this on a real 
> interface connected  to my network:
>
> # ifconfig vlan2 vlandev re0
> # ifconfig vlan3 vlandev re0
> # ifconfig re0 alias 192.168.100.1
> # route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
> route: writing to routing socket: Network is unreachable
> add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable
>
> # uname -a
> OpenBSD lbld12.duckdns.org 5.8 GENERIC.MP#1507 amd64
>
> I thoght OpenBSD supports such thing.
>
> am I missing something?

I don't *think* this is expected to work at the moment unless possibly
you specify a destination MAC address with -link.

It does work with point-to-point interfaces, e.g. you can have
192.0.2.1/28 on em0 and 192.0.2.1/32 on pppoe0 and things will work
as expected, but in that case you don't have a problem of picking a
particular link-layer address, just "the pppoe0 interface" is enough
information for the system to know where to send the packet.

The best I've done so far for address conservation on ethernet-like
interfaces is to use /31's (which works well).

Re: Install on compact flash

2015-10-19 Thread Stuart Henderson 
On 2015-10-19, Josh Grosse  wrote:
> On Mon, Oct 19, 2015 at 04:34:31AM +0200, Einfach Jemand wrote:
>>  No. As far as I understand it:
>> The type (char or block), the major and minor number of the device
>> special file and its name are means to activate the corresponding device
>> handler ("driver") in the kernel and the bytes are sent to the device
>> specified by the file. 
>
> Ok.  I can at least tell you that the last time I tested an r/o
> /dev was at OpenBSD 3.8 or so, and the filesystem was CD9660 rather
> than FFS.  
>
> It failed.  So from that point, until I stopped making live media
> images at 5.0, I never tested again. /dev was merely one of a half
> dozen r/w filesystems I used with MFS.

Some devices get chown()ed during normal system operation, see fbtab(5).

Re: routing q

2015-10-19 Thread Gregory Edigarov 

On 10/19/2015 01:24 PM, Stuart Henderson wrote:

On 2015-10-19, Gregory Edigarov  wrote:

In order to conserve address space I am trying to confugure 'ip
unnumbred' in cisco terminology, that is have an interface borrow the ip
of a different interface, I am experimenting with vether0 and vlans the
thing is to have one 'main' address on some 'real' interface and then
just add routes pointing to the right interfaces.

# ifconfig vether0 192.168.100.1/24 up
# ifconfig vlan2 vlandev vether0 up
# ifconfig vlan3 vlandev vether0 up
# route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
route: writing to routing socket: Network is unreachable
add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable

the same result I have if I am trying to configure this on a real
interface connected  to my network:

# ifconfig vlan2 vlandev re0
# ifconfig vlan3 vlandev re0
# ifconfig re0 alias 192.168.100.1
# route add 192.168.100.2/32 192.168.100.1 -cloning -ifp vlan2
route: writing to routing socket: Network is unreachable
add host 192.168.100.2/32: gateway 192.168.100.1: Network is unreachable

# uname -a
OpenBSD lbld12.duckdns.org 5.8 GENERIC.MP#1507 amd64

I thoght OpenBSD supports such thing.

am I missing something?

I don't *think* this is expected to work at the moment unless possibly
you specify a destination MAC address with -link.

It does work with point-to-point interfaces, e.g. you can have
192.0.2.1/28 on em0 and 192.0.2.1/32 on pppoe0 and things will work
as expected, but in that case you don't have a problem of picking a
particular link-layer address, just "the pppoe0 interface" is enough
information for the system to know where to send the packet.

The best I've done so far for address conservation on ethernet-like
interfaces is to use /31's (which works well).

Yes, I know /31 would work correctly, but I wanted further space 
conservation.
Is that a correct explanation that this does not work because  our 
routing table still wants a link layer address, errrmmm,  arp table is  
included in routing table?

Remove removed utilities?

2015-10-19 Thread Raimo Niskanen 
Hello misc@

I just noticed from the detailed changelog 5.7->5.8:
http://www.openbsd.org/plus58.html
that e.g tcopy, tip and lmccontrol were removed, but after upgrading from
5.7 to 5.8 I still have /usr/bin/tip, /usr/bin/tcopy and /sbin/lmccontrol
in the filesystem, with old dates.

The upgrade guide:
http://www.openbsd.org/faq/upgrade58.html
listed files to remove concerning the removed sudo, but nothing about
the utilities above.

There are also more old files hanging around, e.g:
/usr/bin/perl5.20.1
/usr/bin/perlthanks
and in /usr/lib there are old versions of libtls, libssl, libkvm, libedit,
libcrypt, libc, etc...

I vaguely remember reading something about old libraries remaining after an
upgrade, but can not find it now, at least not up front in the FAQ.

So my question is; should these old utilities be removed after upgrading to
5.8?  And what about old libraries?
-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Two typos in faq10.html

2015-10-19 Thread Reinhold Straub 

Hi, I found two typos in faq10.html

10.10 - How do I create a ftp-only account?
Should be: an ftp-only

A more sophisticated dosas.conf(5) file
Should be: doas.conf(5)

Re: Linux crypt(3)

2015-10-19 Thread Adam Van Ymeren 
Could you modify the existing linux system to also output a suitable
bcrypt hash for their password the next time they log in.

Leave that running for a while, and then migrate?  This way most
active users will have their password migrated for them.  The
remainder can probably afford to reset their password since they're
not using the system very often.

On Mon, Oct 19, 2015 at 7:38 AM, Adam Wysocki  wrote:
> Thank you for all the replies!
>
> On Sat, 17 Oct 2015, Devin Reade wrote:
>
>> As you're looking into solutions, make sure you're looking at the right
>> problem. Your text sounds like you're migrating system account passwords,
>
> I'm not. These are passwords for the news server. Users are authenticated
> using ckpasswd, which uses crypt().
>
> On Sat, 17 Oct 2015, Adam Wolk wrote:
>
>> Don't know if it works out for you but you could generate ssh keys for
>> existing accounts and allow users to access the new system using that
>> provided ssh key & set the passwords themselves (or just keep using key
>> auth and disabling passwords :)).
>
> I don't want to force users to do anything, I want this change to be
> transparent to them...
>
> --
> "qui hic minxerit aut cacaverit, habeat deos superos et inferos iratos"

Re: Remove removed utilities?

2015-10-19 Thread Raimo Niskanen 
On Mon, Oct 19, 2015 at 08:12:31AM -0400, Nick Holland wrote:
> On 10/19/15 04:24, Raimo Niskanen wrote:
> > Hello misc@
> > 
> > I just noticed from the detailed changelog 5.7->5.8:
> > http://www.openbsd.org/plus58.html
> > that e.g tcopy, tip and lmccontrol were removed, but after upgrading from
> > 5.7 to 5.8 I still have /usr/bin/tip, /usr/bin/tcopy and /sbin/lmccontrol
> > in the filesystem, with old dates.
> > 
> > The upgrade guide:
> > http://www.openbsd.org/faq/upgrade58.html
> > listed files to remove concerning the removed sudo, but nothing about
> > the utilities above.
> > 
> > There are also more old files hanging around, e.g:
> > /usr/bin/perl5.20.1
> > /usr/bin/perlthanks
> > and in /usr/lib there are old versions of libtls, libssl, libkvm, libedit,
> > libcrypt, libc, etc...
> > 
> > I vaguely remember reading something about old libraries remaining after an
> > upgrade, but can not find it now, at least not up front in the FAQ.
> > 
> > So my question is; should these old utilities be removed after upgrading to
> > 5.8?  And what about old libraries?
> 
> We used to have a little disclaimer that upgrading was not equivalent to
> wiping and reloading with the new version; yes, stuff will get left
> behind.  It was decided the upgrade docs were too big and scary so that
> was one of the things removed to shorten it up (see older versions, like
> upgrade55.html, for example).
> 
> Things that are out-right replaced (i.e., sudo) should be actively
> deleted.  Even if it still works after upgrade, some day it is going to
> break, and you should be pushed to use the new application (or the
> package of the old application).  Things like tip?  what's the point?
>   case 1) It still works.  No harm done.
>   case 2) It no longer works.  useless file on system...so what?
> Either way...no harm.

I understand the policy.  Sounds just fine to me.

> 
> Library files are far more "interesting"...depending on the upgrade,
> they still may work with old packages still on the system.  Delete them,
> you have broken the old packages before you got them upgraded, usually
> no big deal, but sometimes, may really annoy you.
> 
> Again... who cares?  Yes, after ten upgrades, old libraries can start to
> add up, but on a modern system, you will go through a lot of upgrades
> before you can save a GB of data deleting old stuff.  Just not worth the
> trouble.
> 
> Quoting upgrade55.html:
> "However, the results are not intended to precisely match the results of
> a wipe-and-reload installation. Old library files in particular are not
> removed in the upgrade process, as they may be required by older
> applications that may or may not be upgraded at this time. If you REALLY
> wish to get rid of all these old files, you are probably better off
> reinstalling from scratch."

Aaah...  There it was!

> 
> If OCD is causing you to twitch at seeing the old files, reinstall...or
> use this as a therapy.

Therapy is working...  I feel soothed.
Thank you for the explanation!

/ Raimo

> 
> Nick.

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: Linux crypt(3)

2015-10-19 Thread Adam Wysocki 
On Mon, 19 Oct 2015, Adam Van Ymeren wrote:

> Could you modify the existing linux system to also output a suitable
> bcrypt hash for their password the next time they log in.

Yes, that's the great idea. It didn't cross my mind before. Thank you!

-- 
"qui hic minxerit aut cacaverit, habeat deos superos et inferos iratos"

OpenIKED - send traffic selectors in own child sa

2015-10-19 Thread Kim Zeitler 

Hello

Running -current I have currently got a minor issue with iked.

Trying to connect a security gateway running OpenIKED to a Fortinet 
IPSEC fw. Connection is set up and seems to work (mostly) but following 
behaviour is a bit of an issue.


IKED sends one CHILD_SA request containing all Traffic Selectors. This 
is RFC 5996 conform. Sadly some of the proprietary VPN boxes have a 
*suboptimal* implementation and want *one* CHILD_SA per traffic selector.


Reading ikevd/ikev2.c I found comments about iked not being able to 
initiate multiple concurrent CREATE_CHILD_SA exchanges.


Coming round to my question - is it somehow possible to configure iked 
in such a way, that it sends one CHILD_SA per Traffic Selector or do I 
read the code correctly and it is simply NOT possible?


Cheers

Kim

Re: sensorsd, upd, and state changes

2015-10-19 Thread Maxim Khitrov 
On Mon, Dec 8, 2014 at 3:45 PM, David Higgs  wrote:
> On Mon, Dec 8, 2014 at 3:37 PM, trondd  wrote:
>> On Mon, Dec 8, 2014 at 3:23 PM, trondd  wrote:
>>> On Mon, Dec 8, 2014 at 11:47 AM, David Higgs  wrote:


 sysctl(8) will display Off if the value is zero, and On for nonzero.
 So, using the "closed interval" rule above, you should use "high=0"
 for indicators that you consider in "good" state when Off (i.e.
 ShutdownImminent), and "low=1" for indicators that you consider in
 "good" state when On (i.e. ACPresent).

>>>
>>> Isn't saying high=0 kind of the same thing as saying low=1?
>>
>>
>> Oh, I think I get this.  Since the sensor doesn't trigger if it is on the
>> limit, only outside the limit, you have to set up which is the OK state.
>>
>> Still a little confusing but I guess there is no way to automatically know
>> if an indicator is supposed to be Off or On when it's in it's good state?
>>
>
> Kind of.  The high/low difference is what values you consider "within"
> normal operating parameters (and the output of %l).  The upd(4) code
> hasn't yet been taught how to map specific indicator values to OK /
> WARN / CRITICAL status.  Currently any value successfully read is
> marked OK.
>
> I'm working with tech@ and slowly writing diffs to improve these things.
>
> --david

Resurrecting an old thread since I just ran into the same problem in
5.8. To summarize, upd(4) exposes some SENSOR_INDICATOR-type sensors
for attached UPSes, such as ACPresent = On/Off, and it's not clear how
to configure sensorsd(8) to execute a command when this value changes.
Also, upd always sets sensor status to "OK," so sensorsd never
triggers commands for status changes; we have to use low/high limits
until this is fixed. One proposed hack was to use "low=1:high=2" in
sensorsd.conf, but this doesn't seem to work for everybody.

Has anyone tried using "low=0:high=0"? I'm pretty sure that should
solve the problem in all cases.

The low/high range is inclusive at both ends. Off is 0, but On can be
any other int64 value, including negative. For my UPS, ACPresent = On
is actually a value of -1. I know this because when I set
"low=-1:high=-1" sensorsd reports "upd0.indicator2: within limits:
On". That being the case, "low=1:high=2" would not work because the
value changes from -1 (On) to 0 (Off), and is always below the lower
limit.

Using "low=0:high=0" should always work for On -> Off -> On
transitions, but it will show On as outside (below or above) the
limits. If you want On to be within limits, then just play with the
values until you figure out whether On is 1, -1, or something else
entirely. That may not be as reliable. I'm not actually sure whether
this value is UPS-specific or something that upd determines.

-Max

Exposing the rc(8) constructed pf ruleset, some patches

2015-10-19 Thread Karl O. Pinc 
Hello,

Attached are 3 patches to -current for your
consideration.  Apply with:

  cd /usr/src
  patch -p1 ...

The first, expose-default-pf-rules.patch, lets
the sysadm use the rc(8) constructed default pf
ruleset.  This ability was, in a sense,
compromised when 5.8 eliminated the pf_rules
variable from rc.conf(8).

The acceptance of this patch depends in part on
whether or not the default pf ruleset in rc(8)
is something you want to make readily accessible
or whether it's just there as a stopgap.

The supplied patch allows the rc.conf(8) pf
variable to be set to MINIMAL (in addition to
the current YES and NO).  A setting of MINIMAL
loads the rc(8) default pf ruleset and enables
pf.  MINIMAL means that rc(8) does not load
/etc/pf.conf.  Any loading of /etc/pf.conf
is left to the sysadm.

Why would anyone want such control?

Loading /etc/pf.conf after the daemons have
started allows pf.conf to contain (in many
cases) names instead of IP numbers, simplifying
administration.  The host is configured as a
slave DNS server (serving only on 127.0.0.1) for
locally administered zones.  So the host always
has more or less up to date copies of the zones
available locally without need of network
connection.  pf.conf can then make use of DNS
names in the local zones if loaded after the DNS
slave is started.

Circumstances depending, this can be easier to
administer and less error prone than other
methods of copying IP addresses from DNS into
pf.conf.


Other use-cases come to mind.  Enabling pf,
using the rc(8) fallback pf ruleset, and delaying
the load of /etc/pf.conf until after the
completion of boot could allow the sysadm to
perform final checks or give a final
authorization before the host is made fully
available on the network.  It could be useful
for failure testing, testing what happens when
the system is booted with broken /etc/pf.conf
content.  It provides a dirt simple ssh-only
mode.

In short the feature does not seem crazy and
seems useful.

Prior to 5.8 access to the rc(8) default rules
was "provided" by the rc.conf(8) pf_rules
variable.  In rc.conf.local the sysadm could set
pf_rules=/etc/pf.conf.boot, and have bad content
in pf.conf.boot so that pfctl retains the rc(8)
default rules.  Then, in /etc/rc.local or
otherwise, load /etc/pf.conf.


Given the present system I can't think of a
clean way to both enable pf early in the boot
sequence and avoid manually duplicating the
default pf ruleset in rc(8).

You could resort to keeping a set of minimal
boot-time rules in an anchor in /etc/pf.conf,
and then swap out the contents of the anchor
when ready.  A minor problem is that you have
the complication of messing with anchors and
having an extra file with your real "runtime" pf
rules instead of putting them in /etc/pf.conf.
The real problem is that you have to come up
with your own set of minimal rules that will let
the network configure and the system boot but no
more.

Alternately, you could put unloadable content in
/etc/pf.conf, and keep your real pf rules in,
say, /etc/pf.conf.runtime.  Because the load of
/etc/pf.conf would fail you'd retain the rc(8)
default pf rules until you loaded
/etc/pf.conf.runtime.  But this approach is
butt-ugly.


The 2nd patch, rc-RULES-doc.patch, documents
the default pf ruleset in the rc(8) man page.


The documentation in both patches was influenced
by the wording of the 2nd paragraph in the
DESCRIPTION section of the pfctl(8) man page.


The 3rd patch, rc-RULES-doc-fix.patch, eliminates
the mention of the RULES variable in rc(8) from
the man pages.  

Note: I did my best with the roff.  Where I
didn't know what I was doing I tried to find a
man page that did something similar and copied
that.  However I'm no roff expert and may have
made mistakes.  The generated output looks good
to me.

Please consider these patches and provide
feedback if you'd like something changed.

Thank you.




Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

[demime 1.01d removed an attachment of type text/x-patch]

[demime 1.01d removed an attachment of type text/x-patch]

[demime 1.01d removed an attachment of type text/x-patch]

Re: Upgrade from 5.7 to 5.8 : bsd.rd doesn't complete boot

2015-10-19 Thread Jean-Philippe Provost 
Here it is :

OpenBSD 5.7-stable (GENERIC.MP) #1: Fri Oct 16 18:59:45 EDT 2015
r...@puffy.soccer-beauport.qc.ca:/usr/src/sys/arch/amd64/compile/GENERIC.
MP
real mem = 6215434240 (5927MB)
avail mem = 6046064640 (5765MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfcb40 (45 entries)
bios0: vendor Dell Inc. version "A07" date 11/13/2010
bios0: Dell Inc. Inspiron 580s
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OSFR OEMB HPET ASF! GSCI SSDT
acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4)
BR1E(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4)
USB4(S4) USB5(S4) USB6(S4) BR20(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz, 3192.37 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF
,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz, 3191.99 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF
,PERF,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 2, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz, 3191.99 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF
,PERF,ITSC
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz, 3191.99 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF
,PERF,ITSC
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 6 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 6
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (BR1E)
acpiprt2 at acpi0: bus 1 (BR20)
acpiprt3 at acpi0: bus -1 (BR24)
acpiprt4 at acpi0: bus 2 (BR25)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
cpu0: Enhanced SpeedStep 3192 MHz: speeds: 3201, 3200, 3067, 2933,
2800, 2667, 2533, 2400, 2267, 2133, 2000, 1867, 1733, 1600, 1467,
1333, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x18
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x18
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1440x900
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 3400 MEI" rev 0x06 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x06: apic 6 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 3400 HD Audio" rev 0x06: msi
azalia0: codecs: Realtek/0x0887, Intel/0x2804, using Realtek/0x0887
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 3400 PCIE" rev 0x06: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 5 "Intel 3400 PCIE" rev 0x06
pci2 at ppb1 bus 2
bge0 at pci2 dev 0 function 0 "Broadcom BCM57788" rev 0x01, BCM57780
A1 (0x57780001): msi, address 84:2b:2b:ba:07:82
brgphy0 at bge0 phy 1: BCM57780 10/100/1000baseT PHY, rev. 1
ehci1 at pci0 dev 29 function 0 "Intel 3400 USB" rev 0x06: apic 6 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xa6
pci3 at ppb2 bus 3
pcib0 at pci0 dev 31 function 0 "Intel H57 LPC" rev 0x06
pciide0 at pci0 dev 31 function 2 "Intel 3400 SATA" rev 0x06: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide0: using apic 6 int 19 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector

Question about core dumps and swap space.

2015-10-19 Thread Christoph R. Murauer 
Hello !

I readed the FAQ 4.8 about partioning my drive but have a little problem
of understanding.

The machine has 32 GB physical RAM, the disc is a 256 GB SSD (yes, I know,
I should not use swap on a SSD) and, I installed the latest snapshot from
yesterday. So far so good.

Disklabel likes to create in auto layout b: swap with 23,2 GB and e: /var
with 30,2 GB.

If I follow the FAQ, then core dumps should not work. I could resize swap
and /var to have the same (or bigger size) as the physical RAM which is
also no problem. My question - or better the things I don't understand (I
found no informations and also had no panic message till now) are, which
size had a core dump and, will core dumps work, if swap (on /var is enough
place to copy the core dump file from swap to /var/crash after a reboot)
is smaller then the physical RAM ? My question is meaned, that swap is
only used for core dumps - nothing more.

Thanks for your answers.

Regards,


Christoph

Re: Upgrade from 5.7 to 5.8 : bsd.rd doesn't complete boot

2015-10-19 Thread Peter N. M. Hansteen 

On 10/19/15 22:04, Jean-Philippe Provost wrote:

Hi all,

I've downloaded the bsd.rd from the folder 5.8 on ftp.OpenBSD.org and put
it in /.

I reboot and type boot bsd.rd.

It loads, but at the "end", it sticks at *root on rd0a swap on rd0b dump on
rd0b*

​I did the same thing yesterday with my laptop and everything was fine.

Any ideas? The box is a Dell Inspiron ​


a dmesg always helps diagnose the problem, see eg 
http://www.openbsd.org/faq/faq4.html#getdmesg for how to collect one.


and of course, for a more general (and slightly more verbose) procedure 
for reporting bugs, see http://www.openbsd.org/report.html


Good luck!

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Upgrade from 5.7 to 5.8 : bsd.rd doesn't complete boot

2015-10-19 Thread Jean-Philippe Provost 
Hi all,

I've downloaded the bsd.rd from the folder 5.8 on ftp.OpenBSD.org and put
it in /.

I reboot and type boot bsd.rd.

It loads, but at the "end", it sticks at *root on rd0a swap on rd0b dump on
rd0b*

​I did the same thing yesterday with my laptop and everything was fine.

Any ideas? The box is a Dell Inspiron ​


--
*Jean-Philippe Provost*

Re: Upgrade from 5.7 to 5.8 : bsd.rd doesn't complete boot

2015-10-19 Thread patric conant 
On Mon, Oct 19, 2015 at 3:50 PM, Jean-Philippe Provost <
jphilippe.prov...@gmail.com> wrote:

> Hi,
>
> I don't have any CD. I just downloaded the bsd.rd for 5.8 and it wont boot
> and ask what I want to do.
>
> Since I have 5.7 installed on it, the dmesg I got is the one from 5.7 boot
> and not bsd.rd (5.8) boot.
>
> Am I clear?
>
> --
> *Jean-Philippe Provost*
>
>
> 2015-10-19 16:16 GMT-04:00 Peter N. M. Hansteen :
>
> > On 10/19/15 22:04, Jean-Philippe Provost wrote:
> >
> >> Hi all,
> >>
> >> I've downloaded the bsd.rd from the folder 5.8 on ftp.OpenBSD.org and
> put
> >> it in /.
> >>
> >> I reboot and type boot bsd.rd.
> >>
> >> It loads, but at the "end", it sticks at *root on rd0a swap on rd0b dump
> >> on
> >> rd0b*
> >>
> >> ​I did the same thing yesterday with my laptop and everything was
> fine.
> >>
> >> Any ideas? The box is a Dell Inspiron ​
> >>
> >
> > a dmesg always helps diagnose the problem, see eg
> > http://www.openbsd.org/faq/faq4.html#getdmesg for how to collect one.
> >
> > and of course, for a more general (and slightly more verbose) procedure
> > for reporting bugs, see http://www.openbsd.org/report.html
> >
> > Good luck!
> >
> > --
> > Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> > "Remember to set the evil bit on all malicious network traffic"
> > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
>
Please send the available dmesg.

Re: Upgrade from 5.7 to 5.8 : bsd.rd doesn't complete boot

2015-10-19 Thread Adam Van Ymeren 
On 19 Oct 2015 4:55 p.m., "Jean-Philippe Provost" <
jphilippe.prov...@gmail.com> wrote:
>
> Hi,
>
> I don't have any CD. I just downloaded the bsd.rd for 5.8 and it wont boot
> and ask what I want to do.
>
> Since I have 5.7 installed on it, the dmesg I got is the one from 5.7 boot
> and not bsd.rd (5.8) boot.
>
> Am I clear?
>
> --
> *Jean-Philippe Provost*
>
>
> 2015-10-19 16:16 GMT-04:00 Peter N. M. Hansteen :
>
> > On 10/19/15 22:04, Jean-Philippe Provost wrote:
> >
> >> Hi all,
> >>
> >> I've downloaded the bsd.rd from the folder 5.8 on ftp.OpenBSD.org and
put
> >> it in /.
> >>
> >> I reboot and type boot bsd.rd.
> >>
> >> It loads, but at the "end", it sticks at *root on rd0a swap on rd0b
dump
> >> on
> >> rd0b*
> >>
> >> ​I did the same thing yesterday with my laptop and everything was
> fine.
> >>
> >> Any ideas? The box is a Dell Inspiron ​
> >>
> >
> > a dmesg always helps diagnose the problem, see eg
> > http://www.openbsd.org/faq/faq4.html#getdmesg for how to collect one.
> >
> > and of course, for a more general (and slightly more verbose) procedure
> > for reporting bugs, see http://www.openbsd.org/report.html
> >
> > Good luck!
> >
> > --
> > Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> > "Remember to set the evil bit on all malicious network traffic"
> > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>

Do you have a serial port on the machine and another machine available?
You can capture the complete dmesg from the bsd.rd kernel on a second
machine.

Re: Upgrade from 5.7 to 5.8 : bsd.rd doesn't complete boot

2015-10-19 Thread Jean-Philippe Provost 
Hi,

I don't have any CD. I just downloaded the bsd.rd for 5.8 and it wont boot
and ask what I want to do.

Since I have 5.7 installed on it, the dmesg I got is the one from 5.7 boot
and not bsd.rd (5.8) boot.

Am I clear?

--
*Jean-Philippe Provost*


2015-10-19 16:16 GMT-04:00 Peter N. M. Hansteen :

> On 10/19/15 22:04, Jean-Philippe Provost wrote:
>
>> Hi all,
>>
>> I've downloaded the bsd.rd from the folder 5.8 on ftp.OpenBSD.org and put
>> it in /.
>>
>> I reboot and type boot bsd.rd.
>>
>> It loads, but at the "end", it sticks at *root on rd0a swap on rd0b dump
>> on
>> rd0b*
>>
>> ​I did the same thing yesterday with my laptop and everything was
fine.
>>
>> Any ideas? The box is a Dell Inspiron ​
>>
>
> a dmesg always helps diagnose the problem, see eg
> http://www.openbsd.org/faq/faq4.html#getdmesg for how to collect one.
>
> and of course, for a more general (and slightly more verbose) procedure
> for reporting bugs, see http://www.openbsd.org/report.html
>
> Good luck!
>
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: pledge(2) problems on 18/x/ octeon snapshot

2015-10-19 Thread Sebastien Marie 
On Mon, Oct 19, 2015 at 07:02:44PM +0200, Kim Zeitler wrote:
> I just tried updating an EdgeRouterLite to the latest octeon snapshot
> after replacing the kernel and unpacking base58.tgz
> Literally all commands lead to
> 
> : pledge: Function not implemented
> 

Do you try to run a bsd kernel from RELEASE 5.8 with a userland from
-current ?

RELEASE 5.8 returns ENOSYS ("Function not implemented") on tame(2) call
(which is the old name for pledge, so with the same syscall number).

Programs who call pledge(2), generally exit with error on errno.

I would be great if you can grab the kernel version echoed at boot time.
You could use `boot -c' in the boot loader, in order to enter in config
mode, and have the time to read the OpenBSD version.

-- 
Sebastien Marie

Re: It was twenty years ago you see...

2015-10-19 Thread luke350 
Just another thanks for the top quality work, making software not seem 
like an embarrassment to humanity.


Honesty and the golden rule go a really long way, IMO.   OpenBSD seems 
to play by those rules, to a degree that surprises people.


Thanks.

Re: cannot input _ (keyboard layout is jp)

2015-10-19 Thread Miod Vallat 
> chose 'keyboad layout' jp(japanese),
> then  i cannot input _(under bar) .

Are you using a PS/2 or USB keyboard? The underscore should be obtained
with shift-backslash (using the key left of the right shift key).

Re: Two typos in faq10.html

2015-10-19 Thread Ingo Schwarze 
Hi Reinhold,

Reinhold Straub wrote on Mon, Oct 19, 2015 at 02:56:49PM +0200:

> Hi, I found two typos in faq10.html
> 
> 10.10 - How do I create a ftp-only account?
> Should be: an ftp-only
> 
> A more sophisticated dosas.conf(5) file
> Should be: doas.conf(5)

Committed, thanks.
  Ingo

Re: Exposing the rc(8) constructed pf ruleset, some patches

2015-10-19 Thread Theo de Raadt 
> > The supplied patch allows the rc.conf(8) pf
> > variable to be set to MINIMAL (in addition to
> > the current YES and NO).  A setting of MINIMAL
> > loads the rc(8) default pf ruleset and enables
> > pf.  MINIMAL means that rc(8) does not load
> > /etc/pf.conf.  Any loading of /etc/pf.conf
> > is left to the sysadm.

I read your explanation, but I really don't see the point.
I think that configuration is silly.

Re: Install on compact flash

2015-10-19 Thread Bryan Irvine 
I ran native on compact flash as an experiment for 5+ years without ever
changing the CF card. I only migrated away from it because my old soekris
couldn't keep up with my internet speeds once I upgraded. It still boots
and works fine. Personally I found the hassle of maintaining a ramdisk
frankenstein was worse than just replacing the compact flash should it fail
(which it never did.) but of course YMMV.

On Thu, Oct 15, 2015 at 9:19 AM, Paolo Aglialoro  wrote:

> Hello,
>
> I would like to create an embedded amd64 installation, with system running
> on a 8GB 233x CF card attached to an Intel ITX mb.
>
> In order to minimise nand wear off, I would like to put on ramdisk (the
> machine would have 2GB ram, so I believe enough also for that, but I still
> can upgrade it to 4GB if needed) the parts of the file hierarchy with most
> intensive system write I/O, like, for instance, /tmp and I imagine some
> parts of /var.
>
> My questions are two:
> 1. What are the dirs I should take into account to go to ramdisk?
> 2. What is the correct filesystem type to put in fstab for all the entries
> of point 1. in order to store them in ramdisk?
>
> Thanks in advance for ur answers

Re: sensorsd, upd, and state changes

2015-10-19 Thread David Higgs 
On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov  wrote:

> On Mon, Dec 8, 2014 at 3:45 PM, David Higgs  wrote:
> > On Mon, Dec 8, 2014 at 3:37 PM, trondd  wrote:
> >> On Mon, Dec 8, 2014 at 3:23 PM, trondd  wrote:
> >>> On Mon, Dec 8, 2014 at 11:47 AM, David Higgs  wrote:
> 
> 
>  sysctl(8) will display Off if the value is zero, and On for nonzero.
>  So, using the "closed interval" rule above, you should use "high=0"
>  for indicators that you consider in "good" state when Off (i.e.
>  ShutdownImminent), and "low=1" for indicators that you consider in
>  "good" state when On (i.e. ACPresent).
> 
> >>>
> >>> Isn't saying high=0 kind of the same thing as saying low=1?
> >>
> >>
> >> Oh, I think I get this.  Since the sensor doesn't trigger if it is on
> the
> >> limit, only outside the limit, you have to set up which is the OK state.
> >>
> >> Still a little confusing but I guess there is no way to automatically
> know
> >> if an indicator is supposed to be Off or On when it's in it's good
> state?
> >>
> >
> > Kind of.  The high/low difference is what values you consider "within"
> > normal operating parameters (and the output of %l).  The upd(4) code
> > hasn't yet been taught how to map specific indicator values to OK /
> > WARN / CRITICAL status.  Currently any value successfully read is
> > marked OK.
> >
> > I'm working with tech@ and slowly writing diffs to improve these things.
> >
> > --david
>
> Resurrecting an old thread since I just ran into the same problem in
> 5.8. To summarize, upd(4) exposes some SENSOR_INDICATOR-type sensors
> for attached UPSes, such as ACPresent = On/Off, and it's not clear how
> to configure sensorsd(8) to execute a command when this value changes.
> Also, upd always sets sensor status to "OK," so sensorsd never
> triggers commands for status changes; we have to use low/high limits
> until this is fixed. One proposed hack was to use "low=1:high=2" in
> sensorsd.conf, but this doesn't seem to work for everybody.
>
> Has anyone tried using "low=0:high=0"? I'm pretty sure that should
> solve the problem in all cases.
>
> The low/high range is inclusive at both ends. Off is 0, but On can be
> any other int64 value, including negative. For my UPS, ACPresent = On
> is actually a value of -1. I know this because when I set
> "low=-1:high=-1" sensorsd reports "upd0.indicator2: within limits:
> On". That being the case, "low=1:high=2" would not work because the
> value changes from -1 (On) to 0 (Off), and is always below the lower
> limit.
>
> Using "low=0:high=0" should always work for On -> Off -> On
> transitions, but it will show On as outside (below or above) the
> limits. If you want On to be within limits, then just play with the
> values until you figure out whether On is 1, -1, or something else
> entirely. That may not be as reliable. I'm not actually sure whether
> this value is UPS-specific or something that upd determines.
>

Yes, the values reported are UPS-specific.  You may need to adjust the
ranges, but (as previously discussed) you can just use either high or low
(not both) to detect transition between good and bad indicator states.

This is still all just a hack; I ran out of free time to keep working on
upd(4).  I made the driver less terrible and added a few sensors, but
didn't get as far as changing sensor statuses which could make reporting
much easier.

--david

Re: It was twenty years ago you see...

2015-10-19 Thread Diana Eichert 

On Sun, 18 Oct 2015, Theo de Raadt wrote:


OpenBSD's source tree just turned 20 years old.

I recall the import taking about 3 hours on an EISA-bus 486 with two
ESDI drives.  There was an import attempt a few days earlier, but it
failed due to insufficient space.  It took some time to repartition
the machine.

It wasn't terribly long before David Miller, Chuck Cranor and Niklas
Hallqvist were commiting... then more people showed up.

The first developments were improvements to 32-bit sparc.

Chuck and I also worked on setting up the first 'anoncvs' to make sure
noone was ever cut out from 'the language of diffs' again.  I guess
that was the precursor for the github concept these days :-).  People
forget, but even FSF was a walled garden at the time -- throwing tar
files with vague logs over the wall every couple months.

I was lucky to have one of the few 64Kbit ISDN links in town,
otherwise this would not have happened.  My desktop was a Sparcstation
10; the third machine I had was a very slow 386.

The project is now at:

~322,000 commits
~44 commits/day average
~356 hackers through the years


I wish I still had my old mail server.

I remember sending an email to Theo when I was trying to bring up my
first OpenBSD system in early '96.  If I remember correctly installation 
was pretty sparse, I was used to FreeBSD 2.x hand holding.  Theo said

something to the effect of "if you can't figure out how to install
OpenBSD you should not be using it."  Well I went away and figured out
how to install OpenBSD and have been using it ever since.

thanks again for a great O/S

diana

Re: sensorsd, upd, and state changes

2015-10-19 Thread Maxim Khitrov 
On Mon, Oct 19, 2015 at 2:31 PM, David Higgs  wrote:
> On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov  wrote:
>>
>> On Mon, Dec 8, 2014 at 3:45 PM, David Higgs  wrote:
>> > On Mon, Dec 8, 2014 at 3:37 PM, trondd  wrote:
>> >> On Mon, Dec 8, 2014 at 3:23 PM, trondd  wrote:
>> >>> On Mon, Dec 8, 2014 at 11:47 AM, David Higgs  wrote:
>> 
>> 
>>  sysctl(8) will display Off if the value is zero, and On for nonzero.
>>  So, using the "closed interval" rule above, you should use "high=0"
>>  for indicators that you consider in "good" state when Off (i.e.
>>  ShutdownImminent), and "low=1" for indicators that you consider in
>>  "good" state when On (i.e. ACPresent).
>> 
>> >>>
>> >>> Isn't saying high=0 kind of the same thing as saying low=1?
>> >>
>> >>
>> >> Oh, I think I get this.  Since the sensor doesn't trigger if it is on
>> >> the
>> >> limit, only outside the limit, you have to set up which is the OK
>> >> state.
>> >>
>> >> Still a little confusing but I guess there is no way to automatically
>> >> know
>> >> if an indicator is supposed to be Off or On when it's in it's good
>> >> state?
>> >>
>> >
>> > Kind of.  The high/low difference is what values you consider "within"
>> > normal operating parameters (and the output of %l).  The upd(4) code
>> > hasn't yet been taught how to map specific indicator values to OK /
>> > WARN / CRITICAL status.  Currently any value successfully read is
>> > marked OK.
>> >
>> > I'm working with tech@ and slowly writing diffs to improve these things.
>> >
>> > --david
>>
>> Resurrecting an old thread since I just ran into the same problem in
>> 5.8. To summarize, upd(4) exposes some SENSOR_INDICATOR-type sensors
>> for attached UPSes, such as ACPresent = On/Off, and it's not clear how
>> to configure sensorsd(8) to execute a command when this value changes.
>> Also, upd always sets sensor status to "OK," so sensorsd never
>> triggers commands for status changes; we have to use low/high limits
>> until this is fixed. One proposed hack was to use "low=1:high=2" in
>> sensorsd.conf, but this doesn't seem to work for everybody.
>>
>> Has anyone tried using "low=0:high=0"? I'm pretty sure that should
>> solve the problem in all cases.
>>
>> The low/high range is inclusive at both ends. Off is 0, but On can be
>> any other int64 value, including negative. For my UPS, ACPresent = On
>> is actually a value of -1. I know this because when I set
>> "low=-1:high=-1" sensorsd reports "upd0.indicator2: within limits:
>> On". That being the case, "low=1:high=2" would not work because the
>> value changes from -1 (On) to 0 (Off), and is always below the lower
>> limit.
>>
>> Using "low=0:high=0" should always work for On -> Off -> On
>> transitions, but it will show On as outside (below or above) the
>> limits. If you want On to be within limits, then just play with the
>> values until you figure out whether On is 1, -1, or something else
>> entirely. That may not be as reliable. I'm not actually sure whether
>> this value is UPS-specific or something that upd determines.
>
>
> Yes, the values reported are UPS-specific.  You may need to adjust the
> ranges, but (as previously discussed) you can just use either high or low
> (not both) to detect transition between good and bad indicator states.

Why not both? The low limit is initialized to LLONG_MIN and high to
LLONG_MAX. For "indicator" sensors, the logic we are trying to express
is either value == 0 or value != 0. For the former (i.e. a sensor that
should be "Off" normally), "low=0:high=0" is exactly what you want.
For the latter, sensorsd.conf doesn't give you a way of negating the
range (possible feature request?), but if you know that ACPresent = On
is really -1 for your UPS, then "high=-1" is sufficient. This is, of
course, assuming that the On value will never be positive in the
future.

I just tested all of this, and it works perfectly. For UPSes that use
1 to indicate On, instead of "low=1:high=2" you can simplify that to
"low=1". Alternatively, use "low=0:high=0" everywhere, which will be
the most reliable method, and provide an extra parameter to your
script to indicate which value to consider "normal." The downside is
that sensorsd will complain when the value is On and stay silent when
it's Off.

-Max

Re: make release error on 5.8

2015-10-19 Thread Predrag Punosevac 
Joe S wrote:

> I 've just upgraded from 5.7 to 5.8 on amd64 and applied all of the errata
> found at .
> 
> I downloaded src.tar.gz and sys.tar.gz from
> ftp5.usa.openbsd.org/pub/OpenBSD/5.8 and then applied all of the errata
> (2015-10-18) from http://www.openbsd.org/errata58.html.
> 
> I want to make a release, to deploy on other systems. I followed the
> directions at http://www.openbsd.org/faq/faq5.html#Release.
> 
> During "make release", the process fails during libc:

I built the release yesterday only 30 minutes after Theo uploaded the
iso image on the new installation. I have used that image on over 20
servers today without any problems. I think you have done something
wrong, either during the upgrade from 5.7 or during the built process. 

Predrag

Re: sensorsd, upd, and state changes

2015-10-19 Thread Constantine Aleksandrovich Murenin 
On 19 October 2015 at 11:31, David Higgs  wrote:
> On Mon, Oct 19, 2015 at 11:11 AM, Maxim Khitrov  wrote:
>> Also, upd always sets sensor status to "OK," so sensorsd never
>> triggers commands for status changes; we have to use low/high limits
>> until this is fixed. One proposed hack was to use "low=1:high=2" in
>> sensorsd.conf, but this doesn't seem to work for everybody.
[...]
> This is still all just a hack; I ran out of free time to keep working on
> upd(4).  I made the driver less terrible and added a few sensors, but
> didn't get as far as changing sensor statuses which could make reporting
> much easier.

Yes, it looks like http://bxr.su/o/sys/dev/usb/upd.c follows the
NetBSD paradigm where ksensor.status is simply tied to SENSOR_FINVALID
from ksensor.flags, which is a redundant approach in the OpenBSD
ksensor API, and ksensor.status should instead not be set to anything
at all in such scenarios where it wouldn't alert one of a WARN or CRIT
condition as per http://bxr.su/o/sys/sys/sensors.h#sensor_status.

Cns:OpenBSD {8224} fgrep -n -e .status -e .flags sys/dev/usb/upd.c
254:sensor->ksensor.flags |= SENSOR_FINVALID;
255:sensor->ksensor.status = SENSOR_S_UNKNOWN;
398:sensor->ksensor.status = SENSOR_S_UNKNOWN;
399:sensor->ksensor.flags |= SENSOR_FINVALID;
432:sensor->ksensor.status = SENSOR_S_OK;
433:sensor->ksensor.flags &= ~SENSOR_FINVALID;
Cns:OpenBSD {8225}

All the three lines with `.status` should probably be removed to avoid
the extra confusion and not give the impression that ksensor.status is
actually supported by the driver.

Cheers,
Constantine.SU.

Typo in Upgrade FAQ

2015-10-19 Thread Halim Srama 
In http://www.openbsd.org/faq/upgrade58.html#upgrade

in the section "Upgrade using the install Kernel (RECOMMENDED)"

there is an extra dot in the last line:
"your configuration. info."

Re: Question about core dumps and swap space.

2015-10-19 Thread trondd 
On Mon, October 19, 2015 8:01 pm, Joel Rees wrote:
>
> I have lots of core dumps sitting around. I have not seen any the size
> of physical memory. Nothing close. Even firefox doesn't leave that
> much of a dump when it bombs.
>
> Hmm. Xombrero, from when I was playing with that, left a coredump of
> 512M. Firefox left one at 197M. Time to rm those.
>
> Why do you have 32G of RAM? What kind of working sets do you expect
> the applications you'll be running to have?
>

He's referring to savecore(8) dumps when the kernel crashes, not
application crashes.

Tim.

make release error on 5.8

2015-10-19 Thread Joe S 
I've just upgraded from 5.7 to 5.8 on amd64 and applied all of the errata
found at .

I downloaded src.tar.gz and sys.tar.gz from
ftp5.usa.openbsd.org/pub/OpenBSD/5.8 and then applied all of the errata
(2015-10-18) from http://www.openbsd.org/errata58.html.

I want to make a release, to deploy on other systems. I followed the
directions at http://www.openbsd.org/faq/faq5.html#Release.

During "make release", the process fails during libc:

===> lib/libc
install -c -o root -g bin -m 444 tags  /usr/dest/var/db/libc.tags
install -c -S -o root -g bin -m 600 libc.a  /usr/dest/usr/lib/libc.a
ranlib -t /usr/dest/usr/lib/libc.a
chmod 444 /usr/dest/usr/lib/libc.a
install -c -S -o root -g bin -m 600  libc_p.a /usr/dest/usr/lib
ranlib -t /usr/dest/usr/lib/libc_p.a
chmod 444 /usr/dest/usr/lib/libc_p.a
install -c -S -o root -g bin -m 444  libc.so.80.1 /usr/dest/usr/lib
install: libc.so.80.1: No such file or directory
*** Error 71 in /usr/src/lib/libc (:292 'realinstall')
*** Error 1 in /usr/src/lib (:48 'realinstall')
*** Error 1 in /usr/src (:48 'realinstall')
*** Error 1 in /usr/src/etc (Makefile:229 'distribution')

Did I miss something, or is this a known issue?


OpenBSD 5.8 (GENERIC.MP) #1: Sun Oct 18 14:02:37 PDT 2015
r...@firewall.home.lan:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4259938304 (4062MB)
avail mem = 4126941184 (3935MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb920 (27 entries)
bios0: vendor Intel Corp. version "CCCDT10N.86A.0034.2012.0612.1520" date
06/12/2012
bios0: Intel Corporation D2500CC
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC MCFG HPET
acpi0: wakeup devices SLT1(S4) PS2M(S4) PS2K(S4) UAR1(S3) UAR2(S3) UAR3(S4)
UAR4(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB7(S3) PXSX(S4) RP01(S4)
PXSX(S4) RP02(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D2500 @ 1.86GHz, 1867.05 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU D2500 @ 1.86GHz, 1866.74 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus 1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Atom D2000/N2000 Host" rev 0x03
vga1 at pci0 dev 2 function 0 "Intel Atom D2000/N2000 Video" rev 0x09
intagp at vga1 not configured
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: msi
pci1 at ppb0 bus 2
em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:22:4d:7b:81:bc
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: msi
pci2 at ppb1 bus 1
em1 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address
00:22:4d:7b:81:b8
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 8 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 8 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 8 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 8 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 8 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci3 at ppb2 bus 3
pcib0 at pci0 dev 31 function 0 "Intel NM10 LPC" rev 0x02
ahci0 at pci0 dev 31 function 2 "Intel 82801GR AHCI" rev 0x02: msi, AHCI 1.1
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
fixed naa.5001b449e1e22e7f
sd0: 61057MB, 512 bytes/sector, 125045424 sectors, thin
ichiic0 at

Re: Exposing the rc(8) constructed pf ruleset, some patches

2015-10-19 Thread Karl O. Pinc 
On Mon, 19 Oct 2015 12:47:46 -0600
Theo de Raadt  wrote:

> > > The supplied patch allows the rc.conf(8) pf
> > > variable to be set to MINIMAL (in addition to
> > > the current YES and NO).  A setting of MINIMAL
> > > loads the rc(8) default pf ruleset and enables
> > > pf.  MINIMAL means that rc(8) does not load
> > > /etc/pf.conf.  Any loading of /etc/pf.conf
> > > is left to the sysadm.
> 
> I read your explanation, but I really don't see the point.

Consider what happens when the IP number
of some server, say an SMTP server, is changed.

1) DNS must be updated.

2) On the firewall the pf rules or some pf table
content must be changed.  But keeping a single 
IP, like that of an SMTP server, in a table is 
inefficient and overly complicated.  So pf.conf 
must be edited.  (Most rules are kept in files
and are not programmatically generated.)

3) Then the rules must be reloaded.

But if you write DNS names into your pf.conf
file then step 2 can be eliminated.  All
that's required is to reload the rules.

Eliminating an extra editing step reduces
error.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Re: Upgrade from 5.7 to 5.8 : bsd.rd doesn't complete boot

2015-10-19 Thread Raf Czlonka 
On Mon, Oct 19, 2015 at 09:50:22PM BST, Jean-Philippe Provost wrote:

> Hi,

Hi,

> I don't have any CD. I just downloaded the bsd.rd for 5.8 and it wont
> boot and ask what I want to do.

What do you mean by that?

Does it give you the options to install, upgrade, etc.?

Does it look anything like described in the FAQ[0]?

> Since I have 5.7 installed on it, the dmesg I got is the one from 5.7
> boot and not bsd.rd (5.8) boot.
>
> Am I clear?

No, not really.

Raf

[0] http://www.openbsd.org/faq/faq4.html#InstStart

Re: Question about core dumps and swap space.

2015-10-19 Thread Joel Rees 
2015/10/20 6:29 "Christoph R. Murauer" :
>
> Hello !
>
> I readed the FAQ 4.8 about partioning my drive but have a little problem
> of understanding.
>
> The machine has 32 GB physical RAM,

Wow. Way cool.

> the disc is a 256 GB SSD

That's not shabby, either.

> (yes, I know,
> I should not use swap on a SSD)

Have you been reading this thread?

http://marc.info/?t=144492611700013=1=2

> and, I installed the latest snapshot from
> yesterday. So far so good.
>
> Disklabel likes to create in auto layout b: swap with 23,2 GB and e: /var
> with 30,2 GB.
>
> If I follow the FAQ, then core dumps should not work.

2G RAM, 4G swap on my netbook running openbsd.

I have lots of core dumps sitting around. I have not seen any the size
of physical memory. Nothing close. Even firefox doesn't leave that
much of a dump when it bombs.

Hmm. Xombrero, from when I was playing with that, left a coredump of
512M. Firefox left one at 197M. Time to rm those.

> I could resize swap
> and /var to have the same (or bigger size) as the physical RAM which is
> also no problem. My question - or better the things I don't understand (I
> found no informations and also had no panic message till now) are, which
> size had a core dump and, will core dumps work, if swap (on /var is enough
> place to copy the core dump file from swap to /var/crash after a reboot)
> is smaller then the physical RAM ? My question is meaned, that swap is
> only used for core dumps - nothing more.

So, you don't plan on using swap for deep sleep or powered-down system suspend?

Why do you have 32G of RAM? What kind of working sets do you expect
the applications you'll be running to have?

Do you expect chain-reaction core dumps, where one application hits an
uncaught exception and dumps core and then its parent or some other
application that is communicating with it bombs and dumps core, too?

In other words, do you expect to ever have all 32G filled with stuff
that all at once dies and dumps core?

> Thanks for your answers.
>
> Regards,
>
>
> Christoph

Re: Exposing the rc(8) constructed pf ruleset, some patches

2015-10-19 Thread Steve Shockley 

On 10/19/2015 8:26 PM, Karl O. Pinc wrote:

But if you write DNS names into your pf.conf
file then step 2 can be eliminated.  All
that's required is to reload the rules.


How often do you re-query DNS to update and reload the rules?  What do 
you do in the case of multiple A records, or a CDN?  If DNS or your 
registrar is compromised, how do you prevent an attacker from mapping 
your network (or worse)?

Re: Question about core dumps and swap space.

2015-10-19 Thread Nick Holland 
On 10/19/15 17:18, Christoph R. Murauer wrote:
> Hello !
...
> If I follow the FAQ, then core dumps should not work. I could resize swap
> and /var to have the same (or bigger size) as the physical RAM which is
> also no problem. My question - or better the things I don't understand (I
> found no informations and also had no panic message till now) are, which
> size had a core dump and, will core dumps work, if swap (on /var is enough
> place to copy the core dump file from swap to /var/crash after a reboot)
> is smaller then the physical RAM ? My question is meaned, that swap is
> only used for core dumps - nothing more.

The core dumps in question here are for when the OS panics.  Core dumps
can be used by developers to look at what went wrong, but in order to do
so, you may need everything that was in RAM at the time of the panic.

So...the kernel can dump to swap (whatever was in swap wasn't in RAM,
thus wasn't part of what caused the panic).  On next boot, savecore will
find the dump in swap, and save it to /var.

So that means swap has to be at least the size of RAM and you have to
have AT LEAST that much space FREE on your /var partition.  Your 256G
SSD just got ~70G smaller.  Ouch.

... or ...

you can look at the big picture and realize...
1) you probably aren't a developer.
2) you probably haven't seen a core dump.
3) you probably wouldn't know what to do with the core dump.
4) if you got a core dump and wanted to send it to a developer, a 32G
core dump would probably create a lot of problems for everyone.
5) that's a freaking big chunk of your SSD devoted to stuff you are
unlikely to ever do anything with!

and thus, I'll suggest you just don't worry about it.  IF you manage to
find a way to panic your machine, drop the memory wy down to 2G or
so, reproduce it and worry about a 2G core dump.

And -- even if you do have a system panic, very often developers can
make sense out of what went wrong from the output of the debugger's
trace and ps commands, rather than having to dig through an entire core
dump.  This is always what they ask for FIRST.

Nick.

PC Engine APU.1D4 installation stopper.

2015-10-19 Thread Daniel Ouellet 
Hi,

I am trying to load OpenBSD on this box and no matter what I try I end
up not being able too.

I did search and saw plenty that were successful and all. May be it's
the newer model.

APU.1D4?

Or is there any special truck?

I tried from usb flash drive, and even from a Sata drive inside a USB
hosing.

Could this may be use UEFI now?

I tried 5.7, 5.8 and still no go.

May be the only way to load it in there is via PXE- Boot?

And I saw the note as well about the bios for OpenBSD in case anyone
thought to say that. It is newer then April 2014 as recommended.

Here is where it block no matter what drives and version I tried.

Any clue stick would be greatly appreciated. I obviously must be
overlooking something stupid...

Daniel

=
USB Fash Drive
=
> PC Engines APU BIOS build date: Sep  8 2014
Total memory 4096 MB
AMD G-T40E Processor
CPU MHz=1000
USB MSC blksize=512 sectors=7897088
Press F10 key now for boot menu:
drive 0x000f2a60: PCHS=0/0/0 translation=lba LCHS=979/128/63 s=7897088
drive 0x000f2a90: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
s=31277232
Booting from Hard Disk...
Using drive 0, partition 3.
Loading.
probing: pc0 com0 com1 mem[639K 3568M 496M a20=on]
disk: hd0+ hd1+*
>> OpenBSD/amd64 BOOT 3.28
boot>
booting hd0a:/bsd: 6707920+2128368+250888+0+598016
[97+561408+373901]=0xa228f8
entry point at 0x1000160 [7205c766, 3404, 24448b12, 62e0a304]

=
SATA Drive via USB adaptor
=

> PC Engines APU BIOS build date: Sep  8 2014
Total memory 4096 MB
AMD G-T40E Processor
CPU MHz=1000
USB MSC blksize=512 sectors=125045424
Press F10 key now for boot menu:
drive 0x000f2a60: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=125045424
drive 0x000f2a90: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
s=31277232
Booting from Hard Disk...
Using drive 0, partition 3.
Loading.
probing: pc0 com0 com1 mem[639K 3568M 496M a20=on]
disk: hd0+ hd1+*
>> OpenBSD/amd64 BOOT 3.28
boot>
booting hd0a:/bsd:6741232+2129936+250888+0+598016
[97+563616+375372/]=0xa2c758
entry point at 0x1000160 [7205c766, 3404, 24448b12, f2e0a304]

Re: PC Engine APU.1D4 installation stopper.

2015-10-19 Thread Jonathan Gray 
For i386/amd64 you have to tell boot you want serial output
either at the boot prompt or via boot.conf.

stty com0 115200
set tty com0

On Mon, Oct 19, 2015 at 10:34:15PM -0400, Daniel Ouellet wrote:
> Hi,
> 
> I am trying to load OpenBSD on this box and no matter what I try I end
> up not being able too.
> 
> I did search and saw plenty that were successful and all. May be it's
> the newer model.
> 
> APU.1D4?
> 
> Or is there any special truck?
> 
> I tried from usb flash drive, and even from a Sata drive inside a USB
> hosing.
> 
> Could this may be use UEFI now?
> 
> I tried 5.7, 5.8 and still no go.
> 
> May be the only way to load it in there is via PXE- Boot?
> 
> And I saw the note as well about the bios for OpenBSD in case anyone
> thought to say that. It is newer then April 2014 as recommended.
> 
> Here is where it block no matter what drives and version I tried.
> 
> Any clue stick would be greatly appreciated. I obviously must be
> overlooking something stupid...
> 
> Daniel
> 
> =
> USB Fash Drive
> =
> > PC Engines APU BIOS build date: Sep  8 2014
> Total memory 4096 MB
> AMD G-T40E Processor
> CPU MHz=1000
> USB MSC blksize=512 sectors=7897088
> Press F10 key now for boot menu:
> drive 0x000f2a60: PCHS=0/0/0 translation=lba LCHS=979/128/63 s=7897088
> drive 0x000f2a90: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> s=31277232
> Booting from Hard Disk...
> Using drive 0, partition 3.
> Loading.
> probing: pc0 com0 com1 mem[639K 3568M 496M a20=on]
> disk: hd0+ hd1+*
> >> OpenBSD/amd64 BOOT 3.28
> boot>
> booting hd0a:/bsd: 6707920+2128368+250888+0+598016
> [97+561408+373901]=0xa228f8
> entry point at 0x1000160 [7205c766, 3404, 24448b12, 62e0a304]
> 
> =
> SATA Drive via USB adaptor
> =
> 
> > PC Engines APU BIOS build date: Sep  8 2014
> Total memory 4096 MB
> AMD G-T40E Processor
> CPU MHz=1000
> USB MSC blksize=512 sectors=125045424
> Press F10 key now for boot menu:
> drive 0x000f2a60: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=125045424
> drive 0x000f2a90: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> s=31277232
> Booting from Hard Disk...
> Using drive 0, partition 3.
> Loading.
> probing: pc0 com0 com1 mem[639K 3568M 496M a20=on]
> disk: hd0+ hd1+*
> >> OpenBSD/amd64 BOOT 3.28
> boot>
> booting hd0a:/bsd:6741232+2129936+250888+0+598016
> [97+563616+375372/]=0xa2c758
> entry point at 0x1000160 [7205c766, 3404, 24448b12, f2e0a304]

Re: Remove removed utilities?

2015-10-19 Thread Ted Unangst 
Nick Holland wrote:
> Things that are out-right replaced (i.e., sudo) should be actively
> deleted.  Even if it still works after upgrade, some day it is going to
> break, and you should be pushed to use the new application (or the
> package of the old application).  Things like tip?  what's the point?
>   case 1) It still works.  No harm done.
>   case 2) It no longer works.  useless file on system...so what?
> Either way...no harm.

while on the subject, removing /etc/sudoers may be bad advice for people who
intend the port. I'd break that out slightly with a note.

pledge(2) problems on 18/x/ octeon snapshot

2015-10-19 Thread Kim Zeitler 

I just tried updating an EdgeRouterLite to the latest octeon snapshot
after replacing the kernel and unpacking base58.tgz
Literally all commands lead to

: pledge: Function not implemented


I would offer a ktrace/kdump but sadly my kdump also returns with said 
error.


Cheers,
Kim

Re: Install on compact flash

2015-10-19 Thread Philip Guenther 
On Mon, Oct 19, 2015 at 5:02 AM, Stuart Henderson  wrote:
> On 2015-10-19, Paolo Aglialoro  wrote:
>> On Mon, Oct 19, 2015 at 12:27 PM, Stuart Henderson  
>> wrote:
>>
>>> Some devices get chown()ed during normal system operation, see fbtab(5).
>>
>> Does this mean that write access on files in /dev is limited just to
>> permissions change and, therefore, just some bytes of change in the
>> filesystem? This seems pretty much acceptable for me in terms of CF
>> wear-off, if it does not happen with a high frequence.
>
> Timestamps are updated as well. But I don't think wear-off is really
> a problem for any kind of normal use. It's certainly less of a problem
> than the need to handle a separate /dev partition and make sure that
> things are kept in-sync through OS updates.

Note that FFS, when not mounted with softdeps, will delay writing out
inode updates *for device files* when all that's being updated is the
timestamps.  They get flushed to disk when the vnode is reclaimed,
which is probably only when the filesystem is unmounted when shutting
down.  That was a nice little enhancement we merged from FreeBSD over
a year ago.


Philip Guenther

cannot input _ (keyboard layout is jp)

2015-10-19 Thread Tuyosi Takesima 
hi all .

i start openbsd-snapshots by ***kvm*** .

and

chose 'keyboad layout' jp(japanese),
then  i cannot input _(under bar) .

so
i am obliged to use 'keyboad layout' us .

this is a little incovinient .
how to cope with this ?

---
regards

Re: PC Engine APU.1D4 installation stopper.

2015-10-19 Thread Daniel Ouellet 
On 10/19/15 11:52 PM, Jonathan Gray wrote:
> For i386/amd64 you have to tell boot you want serial output
> either at the boot prompt or via boot.conf.
> 
> stty com0 115200
> set tty com0

Well,

I knew it was something stupid I overlook! I need an other beer. Just
was to excited when I got the box and the brain farted...

Many thanks for the clue stick!

Now I can do the full install and here is the dmesg as a results finally
for it.

Daniel

===
$ dmesg
OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error
ff
real mem = 4246003712 (4049MB)
avail mem = 4113428480 (3922MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
bios0: vendor coreboot version "4.0" date 09/08/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3)
UOH3(S3) UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.14 MHz
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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: 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 199MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40E Processor, 1000.00 MHz
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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu1: 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpiprt0 at acpi0: bus -1 (AGPB)
acpiprt1 at acpi0: bus -1 (HDMI)
acpiprt2 at acpi0: bus 1 (PBR4)
acpiprt3 at acpi0: bus 2 (PBR5)
acpiprt4 at acpi0: bus 3 (PBR6)
acpiprt5 at acpi0: bus -1 (PBR7)
acpiprt6 at acpi0: bus 5 (PE20)
acpiprt7 at acpi0: bus -1 (PE21)
acpiprt8 at acpi0: bus -1 (PE22)
acpiprt9 at acpi0: bus -1 (PE23)
acpiprt10 at acpi0: bus 0 (PCI0)
acpiprt11 at acpi0: bus 4 (PIBR)
acpicpu0 at acpi0: !C2(0@100 io@0x841), C1(@1 halt!), PSS
acpicpu1 at acpi0: !C2(0@100 io@0x841), C1(@1 halt!), PSS
acpibtn0 at acpi0: PWRB
cpu0: 1000 MHz: speeds: 1000 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E
(0x2c00), msi, address 00:0d:b9:3e:d5:5c
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E
(0x2c00), msi, address 00:0d:b9:3e:d5:5d
rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ppb2 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci3 at ppb2 bus 3
re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E
(0x2c00), msi, address 00:0d:b9:3e:d5:5e
rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int
19, AHCI 1.2
ahci0: port 0: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
t10.ATA_SATA_SSD_466F07541B9400349537
sd0: 15272MB, 512 bytes/sector, 31277232 sectors, thin
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18,
version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "ATI EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18,
version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "ATI EHCI root hub" rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0

Re: iked "failed to get dh secret"

2015-10-19 Thread Adam Van Ymeren 
On Mon, Oct 19, 2015 at 12:09 PM, Adam Van Ymeren  wrote:
> I've been trying to setup a VPN for my android device using strongSwan and 
> iked.
>
> When I try to initiate the connection from my device the SA never gets
> established.  I see this in the log:
> Here's the logs from iked -dvv

God damn gmail keyboard shotcuts, sent before I was finished.  The
relevant part of the log appears to be:

ikev2_sa_keys: failed to get dh secret group 24 len 256 secret 256 exchange 256
ikev2_resp_recv: failed to get IKE SA keys

Not sure how to debug this further.  Any thoughts what would trigger this error?

Re: Exposing the rc(8) constructed pf ruleset, some patches

2015-10-19 Thread Karl O. Pinc 
Well, since there's no attachments,
I am including the patches inline.

On Mon, 19 Oct 2015 10:27:16 -0500
"Karl O. Pinc"  wrote:

> Attached are 3 patches to -current for your
> consideration.  Apply with:
> 
>   cd /usr/src
>   patch -p1 ...
> 
> The first, expose-default-pf-rules.patch, lets
> the sysadm use the rc(8) constructed default pf
> ruleset.  This ability was, in a sense,
> compromised when 5.8 eliminated the pf_rules
> variable from rc.conf(8).

> The supplied patch allows the rc.conf(8) pf
> variable to be set to MINIMAL (in addition to
> the current YES and NO).  A setting of MINIMAL
> loads the rc(8) default pf ruleset and enables
> pf.  MINIMAL means that rc(8) does not load
> /etc/pf.conf.  Any loading of /etc/pf.conf
> is left to the sysadm.
> 


diff -ru old/etc/rc new/etc/rc
--- old/etc/rc  2015-10-18 18:48:00.563999219 -0500
+++ new/etc/rc  2015-10-18 23:32:20.084680681 -0500
@@ -329,7 +329,7 @@
 
 # Load pf rules and bring up pfsync interface.
 if [[ $pf != NO ]]; then
-   if [[ -f /etc/pf.conf ]]; then
+   if [[ $pf != MINIMAL && -f /etc/pf.conf ]]; then
pfctl -f /etc/pf.conf
fi
if [[ -f /etc/hostname.pfsync0 ]]; then
diff -ru old/usr/share/man8/rc.conf.8 new/usr/share/man8/rc.conf.8
--- old/usr/share/man8/rc.conf.82015-10-18 18:52:15.094082040 -0500
+++ new/usr/share/man8/rc.conf.82015-10-19 09:56:04.757154333 -0500
@@ -187,6 +187,19 @@
 .Xr spamd-setup 8 .
 .El
 .Pp
+.Cm pf
+may also be set to
+.Cm MINIMAL .
+This enables
+.Xr pf 4
+packet filtering and, instead of loading the
+.Pa /etc/pf.conf
+ruleset, retains the ruleset defined in
+.Xr rc 8
+by the
+.Va RULES
+variable.
+.Pp
 .Sy Auxiliary
 configuration variables mostly determine
 the locations of specific configuration files.


> The 2nd patch, rc-RULES-doc.patch, documents
> the default pf ruleset in the rc(8) man page.


diff -ru old/usr/share/man8/rc.8 new/usr/share/man8/rc.8
--- old/usr/share/man8/rc.8 2015-10-18 18:51:57.794484223 -0500
+++ new/usr/share/man8/rc.8 2015-10-19 09:49:33.190198395 -0500
@@ -156,6 +156,19 @@
 .Nm rc ,
 but this time without performing the file system preen.
 .Pp
+.Nm rc
+defines a set of minimal packet filter rules in it's
+.Va RULES
+variable, used when the
+.Xr pf 4
+packet filter is enabled but before
+.Pa /etc/pf.conf
+is loaded.  These rules deny all traffic except that
+necessary for inbound SSH connections, outbound ICMP ECHO_REQUEST
+datagrams and their returning ECHO_REPLY datagrams, DHCP and BOOTP
+client configuration, CARP synchronization and, if needed, NFS mounts
+of remote file systems.
+.Pp
 Before
 .Nm rc
 starts most system daemons,


> The 3rd patch, rc-RULES-doc-fix.patch, eliminates
> the mention of the RULES variable in rc(8) from
> the man pages.  


diff -ru new/sbin/pfctl/pfctl.8 newer/sbin/pfctl/pfctl.8
--- new/sbin/pfctl/pfctl.8  2015-10-18 20:27:07.621084480 -0500
+++ newer/sbin/pfctl/pfctl.82015-10-19 10:12:20.638745856 -0500
@@ -98,9 +98,7 @@
 be unable to load a ruleset,
 an error occurs and the original ruleset remains in place.
 If this happens at system startup,
-the ruleset defined by the
-.Va RULES
-variable in
+the minimal ruleset constructed by
 .Xr rc 8
 remains in place.
 .Pp
diff -ru new/usr/share/man8/rc.8 newer/usr/share/man8/rc.8
--- new/usr/share/man8/rc.8 2015-10-19 09:49:33.190198395 -0500
+++ newer/usr/share/man8/rc.8   2015-10-19 10:11:50.091443657 -0500
@@ -156,12 +156,11 @@
 .Nm rc ,
 but this time without performing the file system preen.
 .Pp
-.Nm rc
-defines a set of minimal packet filter rules in it's
-.Va RULES
-variable, used when the
+If the
 .Xr pf 4
-packet filter is enabled but before
+packet filter is enabled
+.Nm rc
+constructs a minimal set of rules for use until
 .Pa /etc/pf.conf
 is loaded.  These rules deny all traffic except that
 necessary for inbound SSH connections, outbound ICMP ECHO_REQUEST
diff -ru new/usr/share/man8/rc.conf.8 newer/usr/share/man8/rc.conf.8
--- new/usr/share/man8/rc.conf.82015-10-19 09:56:04.757154333 -0500
+++ newer/usr/share/man8/rc.conf.8  2015-10-19 10:12:03.667133799 -0500
@@ -192,13 +192,10 @@
 .Cm MINIMAL .
 This enables
 .Xr pf 4
-packet filtering and, instead of loading the
-.Pa /etc/pf.conf
-ruleset, retains the ruleset defined in
-.Xr rc 8
-by the
-.Va RULES
-variable.
+packet filtering and retains the ruleset constructed by
+.Xr rc 8 ,
+instead of loading
+.Pa /etc/pf.conf .
 .Pp
 .Sy Auxiliary
 configuration variables mostly determine





Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

iked "failed to get dh secret"

2015-10-19 Thread Adam Van Ymeren 
I've been trying to setup a VPN for my android device using strongSwan and iked.

When I try to initiate the connection from my device the SA never gets
established.  I see this in the log:
Here's the logs from iked -dvv

ikev2_recv: IKE_SA_INIT request from initiator :54158 to
65.19.130.43:500 policy 'policy1' id 0, 1012 bytes
ikev2_recv: ispi 0xedd37e5e75d328e5 rspi 0x
ikev2_policy2id: srcid IPV4/65.19.130.43 length 8
ikev2_pld_parse: header ispi 0xedd37e5e75d328e5 rspi
0x nextpayload SA version 0x20 exchange IKE_SA_INIT
flags 0x08 msgid 0 length 1012 response 0
ikev2_pld_payloads: payload SA nextpayload KE critical 0x00 length 604
ikev2_pld_sa: more than one proposal specified
ikev2_pld_sa: more 2 reserved 0 length 292 proposal #1 protoid IKE
spisize 0 xforms 34 spi 0
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 128 total 4
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 192 total 4
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type ENCR id 3DES
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_MD5_96
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_256_128
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_384_192
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA2_512_256
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id AES_XCBC_96
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_MD5
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA1
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_256
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_384
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id HMAC_SHA2_512
ikev2_pld_xform: more 3 reserved 0 length 8 type PRF id AES128_XCBC
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048_224
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_2048_256
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_1536
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_3072
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_4096
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_8192
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_1024
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id MODP_1024_160
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_256
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_384
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_521
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_224
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id ECP_192
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id BRAINPOOL_P224R1
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id BRAINPOOL_P256R1
ikev2_pld_xform: more 3 reserved 0 length 8 type DH id BRAINPOOL_P384R1
ikev2_pld_xform: more 0 reserved 0 length 8 type DH id BRAINPOOL_P512R1
ikev2_pld_payloads: payload KE nextpayload NONCE critical 0x00 length 264
ikev2_pld_ke: dh group MODP_2048 reserved 0
ikev2_pld_payloads: payload NONCE nextpayload NOTIFY critical 0x00 length 36
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_SOURCE_IP
ikev2_nat_detection: peer source 0xedd37e5e75d328e5 0x
184.151.36.170:54158
ikev2_pld_notify: NAT_DETECTION_SOURCE_IP detected NAT, enabling UDP
encapsulation
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 28
ikev2_pld_notify: protoid NONE spisize 0 type NAT_DETECTION_DESTINATION_IP
ikev2_nat_detection: peer destination 0xedd37e5e75d328e5
0x 65.19.130.43:500
ikev2_pld_payloads: payload NOTIFY nextpayload NOTIFY critical 0x00 length 8
ikev2_pld_notify: protoid NONE spisize 0 type 
ikev2_pld_payloads: payload NOTIFY nextpayload NONE critical 0x00 length 16
ikev2_pld_notify: protoid NONE spisize 0 type 
sa_state: INIT -> SA_INIT
ikev2_sa_negotiate: score 4
sa_stateok: SA_INIT flags 0x00, require 0x00
sa_stateflags: 0x00 -> 0x10 sa (required 0x00 )
ikev2_sa_keys: failed to get dh secret group 24 len 256 secret 256 exchange 256
ikev2_resp_recv: failed to get IKE SA keys
sa_state: SA_INIT -> CLOSED from any to any policy 'policy1'