Re: OpenBSD 5.9/amd64 (2-Jun-2016), httpd(40862): [syscall 5 "wpath"] error when attempting to start httpd with ssl

[Carlin Bingham]

On Thu, Jun 09, 2016 at 01:19:50PM -0500, Troy Frericks wrote:
> On the latest OpenBSD (5.9/amd64 at digitalocean.com), I'm able to start
> httpd without
> SSL using a simple httpd.conf file (below), but when I add SSL, I get error
> in the messages log.
> 
> I've focused on this error: [/bsd: httpd(40862): syscall 5 "wpath"]
> 

You need to remove the password from your TLS private key. httpd is
breaking its pledge when it tries to prompt for the password, but even
if it could prompt it doesn't support it anyway (it would give a
slightly more helpful error though).


--
Carlin


> I've spent hours googeling, and found only one mention that this may be a
> kernel bug.
> I've checked theOpenBSD 5.9 patch list, the OpenBSD 5.9 -current changes
> log.
> 
> I've struck out, seeking assistance... which is greatly appreciated!
> 
> I've also requested assistance here. Had some helpful suggestions, but it's
> still not working.
> https://stackoverflow.com/questions/37681532/httpd-with-ssl-will-not-start-on-openbsd-5-9-amd64
> 
> Here is my httpd.conf file for the non-ssl configuration. The ssl
> configuration is accomplished by
> uncommenting out all the current comments, and I did then comment out the
> 'root' for the port 80 section.
> 
> # cat /etc/httpd.conf
>   interface="egress"
>   domain="infmgr.com"
>   prefork 3
>   types { include "/usr/share/misc/mime.types" }
>   #server $domain {
>   #listen on $interface tls port 443
>   #tls {
>   #certificate "/etc/ssl/server.crt"
>   #key "/etc/ssl/private/server.key"
>   #}
>   #hsts
>   #root "/htdocs/infmgr.com" # chrooted at /var/www/
>   #}
>   server $domain {
>   listen on $interface port 80
>   root "/htdocs/infmgr.com" # chrooted at /var/www/
>   #block return 301 "https://$SERVER_NAME$REQUEST_URI;
>   }
> 
> Troy.
> #

Can read-only mmap() and fwrite() be combined.. via msync or something? In OpenBSD now. (repetition of Q sorry)

[Tinker]

Hi!

This question was answered as part of another conversation 1-2 years ago 
however I totally forgot and due to its relative complexity I simply 
wish to ask it again as to have it set in stone:



In OpenBSD's current absence of a Unified Buffer Cache, is there any 
trick that I can apply to use a read-only mmap() for quickly reading 
data, but fwrite() to do the writing, and this way get mmap's speed 
benefits for the reading but still not be under any risk of breaking my 
data by unintended writes?



I guess if it would be possible, then it would be done through that I 
would ensure that the reading (via memory access) and writing (fwrite()) 
activities would be *temporally separated*, and between each such block, 
I would need to put some kind of code that would do some kind of 
flush/reset as to force the mmap to get updated with the latest writes.


Possible, if so how?


Thanks!
Tinker

Re: no image on external monitor via HDMI output in X

[Nick Holland]

On 06/09/16 17:19, Xavier OB wrote:
> On Thu, Jun 09, 2016 at 08:57:00PM +0300, Mihai Popescu wrote:
> 
> Hi Mihai ,
> 
>> > More ideas ?
>>
>> dmesg output here >
>>
> 
> http://sprunge.us/gASi

guess what?
I don't click on random links.

If you want my help, you put the information IN THE message.  Otherwise,
I lose interest quickly.  I may not be the only one.

Nick.

Re: no image on external monitor via HDMI output in X

[frantisek holop]

try -current

http://marc.info/?l=openbsd-tech=146073262518343=2

-f
-- 
when you come to a fork in the road, take it!

Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)

[Stuart Henderson]

On 2016-06-09, Markus Wernig  wrote:
> On 06/09/2016 08:03 PM, Bryan Vyhmeister wrote:
>> On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote:
>>> Short question:
>>> How do I prevent pf from changing the source port of outgoing natted udp
>>> packets?
>>  
>> Did you look at static-port in pf.conf(5)?
>
> Argh! I had overlooked that. Shame. Works now.

Remember that static-port means you can't have two machines behind
the same NAT using the same source port and destination.

If it's OK to change the source port as long as it ends up within
a certain port range, you can do something like 'nat-to $address port
8000:9000'.

Re: no image on external monitor via HDMI output in X

[Xavier OB]

On Thu, Jun 09, 2016 at 08:57:00PM +0300, Mihai Popescu wrote:

Hi Mihai ,

> > More ideas ?
>
> dmesg output here >
>

http://sprunge.us/gASi

Thanks, see you.

bgpd l3 vpn issue

[Chris Cappuccio]

I found an annoying issue in the Jun 3 -current bgpd.

The interface address for em1 never gets propagated into
rt 686:3 via BGP if configured in this order:

# ifconfig em1 192.168.1.1/24 rdomain 1 
# ifconfig mpe1 172.20.254.1 mplslabel 111 rdomain 1
# /etc/rc.d/ldpd start
# /etc/rc.d/bgpd start

Now, if I simply execute this command again:

# ifconfig em1 192.168.1.1/24 rdomain 1

then the 192.168.1.0/24 network gets propagated via BGP
l3vpn target 686:3 and everything looks normal.

The issue seems to be bgpd reliably finding existing
connected routes in rdomains ?

bgpd.conf:

 AS 686
 router-id 172.20.254.1
 listen on 172.20.254.1
 rdomain 1 { 
descr "test-vrf"
rd 686:3
import-target rt 686:3
export-target rt 686:3
depend on mpe1
network inet connected
network inet static
 }
 group INTERNAL {
announce IPv4 unicast 
announce IPv4 vpn 
remote-as 686
local-address 172.20.254.1
neighbor 172.20.254.2
 }

Re: /usr/ and wxallowed

[Kevin Chadwick]

> > Anybody who had used automatic disk allocation, it would have taken
> > care of this:
> >
> > http://man.openbsd.org/disklabel#AUTOMATIC_DISK_ALLOCATION
> >
> > /usr/local 10% of disk.   2G – 10G
> >
> exactly

Yep, I have no idea why someone wouldn't. I like having nosuid
on less trusted /usr/local.

It pretty much removes the need to do the security technique of find
suid, like is recommended on Linux almost by "default"? I forget if it
is the default mount option for /usr/local or not (breaks sudo btw)?

Also, not that I care any more or many here I guess care but I remember
disapproval of the reasoning behind linux discontinuing support for a
seperate /usr to make booting life easier and also support corner cases
like ssh capable initramfs if I remember correctly. Precisely because
of my experience of OpenBSD so I certainly would never suggest that.

Everything is a package with Linux I guess is a big part of permitting
dropping seperate /usr "support".

--

KISSIS - Keep It Simple So It's Securable

Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)

[Markus Wernig]

On 06/09/2016 08:03 PM, Bryan Vyhmeister wrote:
> On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote:
>> Short question:
>> How do I prevent pf from changing the source port of outgoing natted udp
>> packets?
>  
> Did you look at static-port in pf.conf(5)?

Argh! I had overlooked that. Shame. Works now.

Thanks!

/m

neighbor router-id change on ospfd, ldpd

[Chris Cappuccio]

If I change the router id of a remote ospf peer, I see
weird behavior. I am using -current as of Jun 3rd.

ospfd shows FULL state for the new router ID, but doesn't
install routes into the local rtable while the old router-id
shows DOWN in the neighbor list. (I need to reproduce this
again to see the effects on the ospfd rib/fib.)

The catch is, this only happens when the router-id is a
higher IP address than the local router-id. When the remote
router-id is a lower IP address than the local, the routes
seem get installed in the local route table immediately.

'ospfctl reload' gets the routes installed in the local table
(in the case where the the routes did not get installed).
The old router-ids do not ever disappear from the ospfd
neighbor list unless ospfd is actually stopped and
restarted.

I see similar behavior with ldpd, although the router-id
being higher or lower makes no difference. With ldpd, after
changing the remote router-id, ldp takes quite a while to
re-establish. The adjacency list (ldpctl show discovery)
never shows the correct router-id.

Chris

OpenBSD 5.9/amd64 (2-Jun-2016), httpd(40862): [syscall 5 "wpath"] error when attempting to start httpd with ssl

[Troy Frericks]

On the latest OpenBSD (5.9/amd64 at digitalocean.com), I'm able to start
httpd without
SSL using a simple httpd.conf file (below), but when I add SSL, I get error
in the messages log.

I've focused on this error: [/bsd: httpd(40862): syscall 5 "wpath"]

I've spent hours googeling, and found only one mention that this may be a
kernel bug.
I've checked theOpenBSD 5.9 patch list, the OpenBSD 5.9 -current changes
log.

I've struck out, seeking assistance... which is greatly appreciated!

I've also requested assistance here. Had some helpful suggestions, but it's
still not working.
https://stackoverflow.com/questions/37681532/httpd-with-ssl-will-not-start-on-openbsd-5-9-amd64

Here is my httpd.conf file for the non-ssl configuration. The ssl
configuration is accomplished by
uncommenting out all the current comments, and I did then comment out the
'root' for the port 80 section.

# cat /etc/httpd.conf
  interface="egress"
  domain="infmgr.com"
  prefork 3
  types { include "/usr/share/misc/mime.types" }
  #server $domain {
  #listen on $interface tls port 443
  #tls {
  #certificate "/etc/ssl/server.crt"
  #key "/etc/ssl/private/server.key"
  #}
  #hsts
  #root "/htdocs/infmgr.com" # chrooted at /var/www/
  #}
  server $domain {
  listen on $interface port 80
  root "/htdocs/infmgr.com" # chrooted at /var/www/
  #block return 301 "https://$SERVER_NAME$REQUEST_URI;
  }

Troy.
#

Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)

[Bryan Vyhmeister]

On Thu, Jun 9, 2016, at 10:48 AM, Markus Wernig wrote:
> Short question:
> How do I prevent pf from changing the source port of outgoing
> natted udp
> packets?
 
Did you look at static-port in pf.conf(5)?
 
Bryan

Re: pf changes port on udp nat-to and rdr-to reply packets (RTP stream)

[Zé Loff]

> On 09/06/2016, at 18:48, Markus Wernig  wrote:
>
> Hi all
>
> I have a strange behaviour in pf on 5.9-stable:
>
> A system (asterisk) behind the gateway is receiving and replying to udp
> streams (RTP). The connection parameters (src/dst ip/port) are set up
> before (STUN and SIP), so both systems "know" where to send to.
>
> The gateway does NAT (rdr-to in, nat-to out) for the system. But while
> incoming packets are forwarded with source and destination port
> unchanged, the source port on the outgoing packets is changed (to
> something in the >5 range). This breaks the connection, as the
> external system (resp. the firewall it is behind) expects the packets to
> have the original dst port as src port.
>
> The same happens when the system starts a udp stream on its own - the
> source port gets rewritten. Also the UDP checksum appears to be wrong
> after the NAT.
>
>
> Short question:
> How do I prevent pf from changing the source port of outgoing natted udp
> packets?

Add "static-port" to the match rule

>
> Long question:
>
> tcpdump:
>
> $int_if:
> 18:40:21.392468 $int_server_ip.10442 > $external_system.5012: [udp sum
> ok] udp 32 (DF) (ttl 64, id 64912, len 60)
> 18:40:21.396091 $external_system.5012 > $int_server_ip.10442: [bad udp
> cksum a9e7! -> 316d] udp 32 (ttl 115, id 9052, len 60)
> 18:40:21.413332 $int_server_ip.10442 > $external_system.5012: [udp sum
> ok] udp 32 (DF) (ttl 64, id 64916, len 60)
> 18:40:21.415143 $external_system.5012 > $int_server_ip.10442: [bad udp
> cksum a9e7! -> 7036] udp 32 (ttl 115, id 9053, len 60)
> ...
>
> $ext_if:
> 18:40:21.392510 $sext_server_ip.51049 > $external_system.5012: [bad udp
> cksum 528b! -> e3da] udp 32 (ttl 63, id 16487, len 60)
> 18:40:21.395975 $external_system.5012 > $sext_server_ip.10442: [udp sum
> ok] udp 32 (ttl 116, id 9052, len 60) <--This is a "new" incoming stream
>
> 18:40:21.413377 $sext_server_ip.51049 > $external_system.5012: [bad udp
> cksum 528b! -> 53d8] udp 32 (ttl 63, id 30449, len 60)
> 18:40:21.415089 $external_system.5012 > $sext_server_ip.10442: [udp sum
> ok] udp 32 (ttl 116, id 9053, len 60)
> ...
>
> The problem seems to be that the internal system tells the external one
> about the source port (10442) it should connect to (via SIP), and as
> last step sends a packet from that port (plus in-protocol info, I
> assume). But pf changes that source port on that outgoing packet (to
> 51049), and keeps doing so for all following packets, while the external
> system sticks to the protocol and sends its traffic to 10442.
>
> So it looks like pf can't distinguish between what it sees as "follow
> up" packets to the first outgoing packet (18:40:21.392468) and the reply
> packets to the "incoming" stream.
>
> The connection breaks because the firewall the $external_system is
> behind expects replies to the packets send to 10442 to come back from
> that port.
>
> All of this wouldn't happen if the source port hadn't been changed to
51049.
>
> So: is there any way of preventing this behaviour? I didn't find
> anything in pf.conf(5) or elsewhere ...
>
> Thx for any insight, folks
>
> /markus
>
> PS:
> These are the rules in question:
>
> match in from any to $ext_server_ip rdr-to $int_server_ip
>
> match out from $int_server_ip to any nat-to $ext_server_ip
>
> pass  log  quick on { $ext_if, $int_if } inet proto udp  from any  to
> $int_server_ip port {  >< 11001 }  label "RTP IN -- ACCEPT "
>
> pass  log  quick on { $ext_if, $int_if } inet proto udp  from
> $int_server_ip  to any port { >= 1024 }  label "UDP HIGH OUT -- ACCEPT "

Re: no image on external monitor via HDMI output in X

[Mihai Popescu]

> More ideas ?

dmesg output here >

pf changes port on udp nat-to and rdr-to reply packets (RTP stream)

[Markus Wernig]

Hi all

I have a strange behaviour in pf on 5.9-stable:

A system (asterisk) behind the gateway is receiving and replying to udp
streams (RTP). The connection parameters (src/dst ip/port) are set up
before (STUN and SIP), so both systems "know" where to send to.

The gateway does NAT (rdr-to in, nat-to out) for the system. But while
incoming packets are forwarded with source and destination port
unchanged, the source port on the outgoing packets is changed (to
something in the >5 range). This breaks the connection, as the
external system (resp. the firewall it is behind) expects the packets to
have the original dst port as src port.

The same happens when the system starts a udp stream on its own - the
source port gets rewritten. Also the UDP checksum appears to be wrong
after the NAT.


Short question:
How do I prevent pf from changing the source port of outgoing natted udp
packets?


Long question:

tcpdump:

$int_if:
18:40:21.392468 $int_server_ip.10442 > $external_system.5012: [udp sum
ok] udp 32 (DF) (ttl 64, id 64912, len 60)
18:40:21.396091 $external_system.5012 > $int_server_ip.10442: [bad udp
cksum a9e7! -> 316d] udp 32 (ttl 115, id 9052, len 60)
18:40:21.413332 $int_server_ip.10442 > $external_system.5012: [udp sum
ok] udp 32 (DF) (ttl 64, id 64916, len 60)
18:40:21.415143 $external_system.5012 > $int_server_ip.10442: [bad udp
cksum a9e7! -> 7036] udp 32 (ttl 115, id 9053, len 60)
...

$ext_if:
18:40:21.392510 $sext_server_ip.51049 > $external_system.5012: [bad udp
cksum 528b! -> e3da] udp 32 (ttl 63, id 16487, len 60)
18:40:21.395975 $external_system.5012 > $sext_server_ip.10442: [udp sum
ok] udp 32 (ttl 116, id 9052, len 60) <--This is a "new" incoming stream

18:40:21.413377 $sext_server_ip.51049 > $external_system.5012: [bad udp
cksum 528b! -> 53d8] udp 32 (ttl 63, id 30449, len 60)
18:40:21.415089 $external_system.5012 > $sext_server_ip.10442: [udp sum
ok] udp 32 (ttl 116, id 9053, len 60)
...

The problem seems to be that the internal system tells the external one
about the source port (10442) it should connect to (via SIP), and as
last step sends a packet from that port (plus in-protocol info, I
assume). But pf changes that source port on that outgoing packet (to
51049), and keeps doing so for all following packets, while the external
system sticks to the protocol and sends its traffic to 10442.

So it looks like pf can't distinguish between what it sees as "follow
up" packets to the first outgoing packet (18:40:21.392468) and the reply
packets to the "incoming" stream.

The connection breaks because the firewall the $external_system is
behind expects replies to the packets send to 10442 to come back from
that port.

All of this wouldn't happen if the source port hadn't been changed to 51049.

So: is there any way of preventing this behaviour? I didn't find
anything in pf.conf(5) or elsewhere ...

Thx for any insight, folks

/markus

PS:
These are the rules in question:

match in from any to $ext_server_ip rdr-to $int_server_ip

match out from $int_server_ip to any nat-to $ext_server_ip

pass  log  quick on { $ext_if, $int_if } inet proto udp  from any  to
$int_server_ip port {  >< 11001 }  label "RTP IN -- ACCEPT "

pass  log  quick on { $ext_if, $int_if } inet proto udp  from
$int_server_ip  to any port { >= 1024 }  label "UDP HIGH OUT -- ACCEPT "

Re: no image on external monitor via HDMI output in X

[Xavier OB]

On Thu, Jun 09, 2016 at 04:59:39PM +0200, Francois Pussault wrote:

Hi Francois ,

> Hello
>
> Did you try to enable from xrandr command the hdmi port  ?
> at least xrandr --output HDMI1 --auto ?

Yes, with no results, any command output:

# xrandr --output HDMI1 --auto
# xrandr --output HDMI2 --auto
#

More ideas ?

Thanks, see you.

>
> I've had something more or less similar with an dvi port. mode auto solved
the
> issue.
>
> > 
> > From: Xavier OB 
> > Sent: Thu Jun 09 16:49:06 CEST 2016
> > To: 
> > Subject: no image on external monitor via HDMI output in X
> >
> >
> > Hi ,
> >
> >
> > I install a fresh new OpenBSD 5.9 on this machine http://sprunge.us/gRJU
.
> >
> > When X start, I get this log: http://sprunge.us/ZaUM
> >
> > I fix the "(WW) checkDevMem: failed" problem setting
> > machdep.allowaperture=1 in /etc/sysctl.conf with same problem, no
> > image on external monitor via HDMI output.
> >
> > The xrandr log is http://sprunge.us/VQGV .
> >
> > Hmmm, any idea ? Thanks.
> >
> >
> > See you.
> >
>
>
> Cordialement
> Francois Pussault
> 10 chemin de négo saoumos
> apt 202 - bat 2
> 31300 Toulouse
> +33 6 17 230 820   +33 5 34 365 269
> fpussa...@contactoffice.fr

Re: no image on external monitor via HDMI output in X

[Francois Pussault]

Hello

Did you try to enable from xrandr command the hdmi port  ?
at least xrandr --output HDMI1 --auto ?

I've had something more or less similar with an dvi port. mode auto solved the
issue.

> 
> From: Xavier OB 
> Sent: Thu Jun 09 16:49:06 CEST 2016
> To: 
> Subject: no image on external monitor via HDMI output in X
>
>
> Hi ,
>
>
> I install a fresh new OpenBSD 5.9 on this machine http://sprunge.us/gRJU .
>
> When X start, I get this log: http://sprunge.us/ZaUM
>
> I fix the "(WW) checkDevMem: failed" problem setting
> machdep.allowaperture=1 in /etc/sysctl.conf with same problem, no
> image on external monitor via HDMI output.
>
> The xrandr log is http://sprunge.us/VQGV .
>
> Hmmm, any idea ? Thanks.
>
>
> See you.
>


Cordialement
Francois Pussault
10 chemin de négo saoumos
apt 202 - bat 2
31300 Toulouse
+33 6 17 230 820   +33 5 34 365 269
fpussa...@contactoffice.fr

no image on external monitor via HDMI output in X

[Xavier OB]

Hi ,


I install a fresh new OpenBSD 5.9 on this machine http://sprunge.us/gRJU .

When X start, I get this log: http://sprunge.us/ZaUM

I fix the "(WW) checkDevMem: failed" problem setting
machdep.allowaperture=1 in /etc/sysctl.conf with same problem, no
image on external monitor via HDMI output.

The xrandr log is http://sprunge.us/VQGV .

Hmmm, any idea ? Thanks.


See you.

Re: /usr/ and wxallowed

[Kapetanakis Giannis]

On 09/06/16 16:07, Theodoros wrote:

Anybody who had used automatic disk allocation, it would have taken
care of this:

http://man.openbsd.org/disklabel#AUTOMATIC_DISK_ALLOCATION

/usr/local 10% of disk.   2G – 10G


exactly

Re: /usr/ and wxallowed

[Theodoros]

Anybody who had used automatic disk allocation, it would have taken
care of this:

http://man.openbsd.org/disklabel#AUTOMATIC_DISK_ALLOCATION

/usr/local 10% of disk.   2G – 10G


On 9 June 2016 at 15:53, Kapetanakis Giannis 
wrote:
> On 08/06/16 22:02, Mihai Popescu wrote:
>>>
>>> Sorry, no, I should have been clearer.
>>
>> Man, so much confusion in this thread. All are mixed in usage:
>> partition, mount point, filesystem, mount options, etc. Aren't they
>> different anymore? I was reading about wx_ stuff since I will install
>> a new snapshots, but this thread is too damn unclear.
>>
>> Sorry.
>>
>
> I think it's quite clear. If you want run programs that violate W^X
> protection, for instance some programs from ports might have problems with
> W^X,
> then you have to mount the filesystem under which the program exists with
> wxallowed.
>
> Since ports are installed in /usr/local you have options like:
>
> a) if you have a separate /usr/local then you mount /usr/local with
> wxallowed option
> b) if you have only /usr then you have to mount /usr with wxallowed option
> c) or create a new /usr/local filesystem, move old  /usr/local (from /usr
> filesystem) there and mount that with wxallowed
>
> If you install a new system, then recommended to create a separate
> /usr/local from start...
>
> G

Re: /usr/ and wxallowed

[Kapetanakis Giannis]

On 08/06/16 22:02, Mihai Popescu wrote:

Sorry, no, I should have been clearer.

Man, so much confusion in this thread. All are mixed in usage:
partition, mount point, filesystem, mount options, etc. Aren't they
different anymore? I was reading about wx_ stuff since I will install
a new snapshots, but this thread is too damn unclear.

Sorry.



I think it's quite clear. If you want run programs that violate W^X 
protection, for instance some programs from ports might have problems 
with W^X,
then you have to mount the filesystem under which the program exists 
with wxallowed.


Since ports are installed in /usr/local you have options like:

a) if you have a separate /usr/local then you mount /usr/local with 
wxallowed option

b) if you have only /usr then you have to mount /usr with wxallowed option
c) or create a new /usr/local filesystem, move old  /usr/local (from 
/usr filesystem) there and mount that with wxallowed


If you install a new system, then recommended to create a separate 
/usr/local from start...


G

Re: OpenBSD

[ludovic coues]

There was at least one thread on misc@ on the subject. Vendor was not reliable.

2016-06-09 8:07 GMT+02:00 T D :
> What happened to being able to purchase OpenBSD from the Canada outlet?
>
> Thanks
>
> Tom
>



-- 

Cordialement, Coues Ludovic
+336 148 743 42

OpenBSD

[T D]

What happened to being able to purchase OpenBSD from the Canada outlet?

Thanks

Tom