Re: timestamps

[Stuart Henderson]

On 2016-01-21, Stuart Henderson  wrote:
> On 2016-01-21, Steve Shockley  wrote:
>> A while back [1], I posted a question asking about timeout issues using 
>> Openup (or any transfers really) to work through a Websense proxy. 
>> Later, I had problems with Smokeping on OpenBSD showing ~50% packet loss 
>> going through the proxy.  After far too long staring at debug logs and 
>> packet traces, it turned out that the proxy OS (CentOS) simply wasn't 
>> passing the traffic through to the proxy.
>>
>> I found a description of a similar problem on Server Fault [2].  It 
>> turned out OpenBSD was sending two SYN packets with timestamps (which 
>> were dropped by CentOS), then sending a SYN without a timestamp (which 
>> was successful).  Setting sysctl net.ipv4.tcp_timestamps=0 on the CentOS 
>> proxy worked around the problem.
>>
>> So, what went wrong here?  Was the OpenBSD timestamp "too random" for 
>> CentOS 6.7?  Or is there some other issue, and I'm just masking it by 
>> disabling timestamps?
>
> Removing timestamps will kill performance unless it's on a slow line.
> It gives a good clue though - try this (on the centos box) instead:
>
> http://stackoverflow.com/questions/8893888/dropping-of-connections-with-tcp-tw-recycle
>
>

Better reference.
http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

Re: Mismatch between config and documentation for dhcpd?

[Raf Czlonka]

On Thu, Jan 21, 2016 at 11:15:42AM GMT, Etienne wrote:
> On 2016-01-21 00:27, Stuart Henderson wrote:
> 
> >>man dhcp-options(5) shows the option classless-static-routes, however,
> >>when I use it, dhcpd fails to start and returns:
> >>
> >>dhcpd: /etc/dhcpd.conf line 49: unknown option
> >>dhcp.classless-static-routes
> >
> >It looks like it should just be "classless-static-routes" without a
> >dhcp. prefix.
> 
> I didn't add a prefix, it's been added in the log by the program itself. My
> config file looked like below:
> 
> option domain-name-servers 192.168.0.71, 192.168.0.149;
> option classless-static-routes 192.168.32/24 192.168.0.1;
 ^
Is this by any chance because the above is not valid CIDR and should
have been, 192.168.32.0/24?

Regards,

Raf

> deny unknown-clients;
> 
> For the moment, I'll go with the following config, which works:
> 
> option domain-name-servers 192.168.0.71, 192.168.0.149;
> option static-routes 192.168.32.7 192.168.0.1, 192.168.32.15
> 192.168.0.1;
> deny unknown-clients;
> 
> Cheers,
> 
> -- 
> Étienne

Re: iwm0: could not initiate 2 GHz scan

[Stefan Sperling]

On Thu, Jan 14, 2016 at 07:41:59PM -0700, Chris Wojo wrote:
> Here is a one liner from the beacons at home: 

It seems this AP does not support 802.11n and is using WEP.
Is this correct?

> Here are a few beacons from work: 

There's nothing unusual in these beacons as far as I can tell.

> This would be a selection of dmesg output for the work AP's:

It looks as if your connection failures at work could be related
to authentication failures. The OpenBSD client won't move from ASSOC
to RUN state. This usually means WPA authentication is failing.
Let's try to confirm this theory.

Which authentication mechanism is used on this network?
It's using some form of WPA but I'm not sure which exactly.
Can you show the lines 'ifconfig iwm0 scan' displays for these APs?
These lines should indicate the authentication method used.
If the lines contain '802.1x' you'll need to install wpa_supplicant
from packages and configure it before connecting.
See http://undeadly.org/cgi?action=article=20130128142215 for details.

Can you run 'ifconfig iwm0 debug' before trying to connect, and show
the WPA 'handshake' messages which should now end up in dmesg?
Upon success, 4 handshake messages are exchanged and the 'status:'
line displayed by 'ifconfig iwm0' becomes 'active'. Note that dhclient
cannot do anything before the link becomes active, so if you've only
been checking dhclient output that's not the right place to look.

Can you show what 'ifconfig iwm0' (as non-root user so passwords remain
hidden) looks like while you're trying to connect at work?
Perhaps you have a WEP key and a WPA set at the same time after moving
from home to the office while the laptop is suspended?
Switching from a WEP network to a WPA network requires clearing the
WEP key with 'ifconfig iwm0 -nwkey' in addition to the commands which
set up WPA. I've fallen into this trap myself many many times.

If none of the above help, did you ever manage to use any OpenBSD client
in this environment? Can you connect to this network with an OpenBSD
client using a wifi device supported by a driver other than iwm(4)?

Re: igmp option 148 (RA)

[Kapetanakis Giannis]

On 21/01/16 13:15, Stuart Henderson wrote:
See pf.conf(5) "allow-opts". 


thanx Stuart :)
that did the trick

G

Re: igmp option 148 (RA)

[Jonathan Gray]

On Thu, Jan 21, 2016 at 11:40:41AM +0100, Stefan Sperling wrote:
> On Thu, Jan 21, 2016 at 12:27:06PM +0200, Kapetanakis Giannis wrote:
> > Hi,
> > 
> > I'm constantly seeing this on my pf router.
> > rule 61/(ip-option) pass in on $ext_if: $ext_gw > 224.0.0.1: igmp query [tos
> > 0xc0] [ttl 1]
> > 
> > Rule 61 is:
> > @61 pass quick inet proto igmp from $ext_if:network to 224.0.0.1 keep state
> > (no-sync)
> > 
> > tcpdump on $ext_if shows:
> > $ext_gw > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 59056, len 32,
> > optlen=4 IPOPT-148{4})
> > 
> > I guess pf has a problem with ip-option 148 which is router alert (rfc2113)
> > Is this normal? Why does it think it's bad?
> > 
> > Ext gateway is cisco (no under my control) which apparently is sending this
> > option.
> > 
> > G
> 
> Multicast traffic is black-holed by default.
> You may want to set multicast_host=Yes in /etc/rc.conf.local.
> See the MULTICAST ROUTING section in the netstart(8) man page.
> 

Note that it is just "multicast" with snapshots and >= 5.9
http://www.openbsd.org/faq/current.html#20151205

Re: igmp option 148 (RA)

[Kapetanakis Giannis]

On 21/01/16 12:40, Stefan Sperling wrote:

On Thu, Jan 21, 2016 at 12:27:06PM +0200, Kapetanakis Giannis wrote:

Hi,

I'm constantly seeing this on my pf router.
rule 61/(ip-option) pass in on $ext_if: $ext_gw > 224.0.0.1: igmp query [tos
0xc0] [ttl 1]

Rule 61 is:
@61 pass quick inet proto igmp from $ext_if:network to 224.0.0.1 keep state
(no-sync)

tcpdump on $ext_if shows:
$ext_gw > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 59056, len 32,
optlen=4 IPOPT-148{4})

I guess pf has a problem with ip-option 148 which is router alert (rfc2113)
Is this normal? Why does it think it's bad?

Ext gateway is cisco (no under my control) which apparently is sending this
option.

G

Multicast traffic is black-holed by default.
You may want to set multicast_host=Yes in /etc/rc.conf.local.
See the MULTICAST ROUTING section in the netstart(8) man page.



I 've tried multicast=YES and manually removing the -reject rule
as in /etc/netstart (route -qn delete 224.0.0.0/4)

but nothing changed

multicast_host seems deprecated. I can't find any entry for this in 
/etc/rc /etc/rc.conf or /etc/netstart
Anyway I don't think this is the problem since the reject route probably 
has nothing to do with pf deciding it's a bad ip option.


thanx for reply

G

Re: igmp option 148 (RA)

[Stuart Henderson]

On 2016-01-21, Kapetanakis Giannis  wrote:
> Hi,
>
> I'm constantly seeing this on my pf router.
> rule 61/(ip-option) pass in on $ext_if: $ext_gw > 224.0.0.1: igmp query 
> [tos 0xc0] [ttl 1]
>
> Rule 61 is:
> @61 pass quick inet proto igmp from $ext_if:network to 224.0.0.1 keep 
> state (no-sync)
>
> tcpdump on $ext_if shows:
> $ext_gw > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 59056, len 32, 
> optlen=4 IPOPT-148{4})
>
> I guess pf has a problem with ip-option 148 which is router alert (rfc2113)
> Is this normal? Why does it think it's bad?
>
> Ext gateway is cisco (no under my control) which apparently is sending 
> this option.
>
> G
>
>

See pf.conf(5) "allow-opts".

Re: Mismatch between config and documentation for dhcpd?

[Etienne]

On 2016-01-21 00:27, Stuart Henderson wrote:


man dhcp-options(5) shows the option classless-static-routes, however,
when I use it, dhcpd fails to start and returns:

dhcpd: /etc/dhcpd.conf line 49: unknown option
dhcp.classless-static-routes


It looks like it should just be "classless-static-routes" without a
dhcp. prefix.


I didn't add a prefix, it's been added in the log by the program itself. 
My config file looked like below:


option domain-name-servers 192.168.0.71, 192.168.0.149;
option classless-static-routes 192.168.32/24 192.168.0.1;
deny unknown-clients;

For the moment, I'll go with the following config, which works:

option domain-name-servers 192.168.0.71, 192.168.0.149;
option static-routes 192.168.32.7 192.168.0.1, 192.168.32.15 
192.168.0.1;

deny unknown-clients;

Cheers,

--
Étienne

Re: Building AMI for AWS EC2

[Reyk Floeter]

On Thu, Jan 21, 2016 at 07:36:01AM +0100, Antoine Jacoutot wrote:
> > There are a couple public AMIs available, but I'm curious as to how they are
> > built. It'd be pretty cool to be able to build a given snapshot into an AMI,
> > rather than be dependent on whomever is creating the public ones.
> > 
> > If the builder of the public AMIs is reading this, I'd love to hear what
> > your process is.
> 

I started putting out some experimental AMIs on EC2, I usually copy
them to the following zones: eu-central-1, eu-west-1, us-west-2 and
ap-northeast-1.  So the public images are probably from me - they
aren't official and I didn't publish the ami IDs, so there is no way
to verify it yet.

These images are not meant to replace your own images - but they can
help to test, play and to get started.

> You can play with this if you're brave:
> https://github.com/ajacoutot/aws-openbsd
> 
> It's kind of ugly but should do the job. Once vmm is in GENERIC, I'll script 
> something around it instead.
> 

I'm using Antoine's aws-openbsd/create-ami.sh script to upload my
images with -i.  But I manually create them in vmm because I prefer
images that have been created with the standard installer (see below).

That's my process of creating the images:

- I boot bsd.rd with install59.fs in vmm and install the latest
OpenBSD/amd64 snapshot in a 1G disk image.

- For the images, I use all the default installer options, auto-layout
etc.  These images are for experimenting with OpenBSD on EC2, so there
is no need for any manual "cloud tweaks" (and, after all, I wouldn't
expect custom changes in an image that calls itself openbsd).

- I install a custom -current kernel that has xen/xnf enabled and
sometimes extra things that helps mikeb@'s development (debug
messages, upcoming fixes etc.).  Now that it is enabled by default, I
could just switch to snapshot kernel as well, but we're still trying
to figure out why it doesn't work on the biggest machines (such as
m4.10xlarge with 40CPU and 160GB RAM - xnf cannot transmit there).

- I mount the image, add ec2-init.sh and configure /etc/hostname.xnf0.

- I upload the new image with create-ami.sh -i openbsd-amd64-mmDDHHMM

- I mark it as public and copy it to a few regions (with aws ec2 copy-image).

Amazon gave me a generous amount of EC2 credits for development and/or
evaluation (thanks!) and I hope that they will last a while as
constantly uploading new images already exceeded my free tier limits.
But my company is also willing to support this and to continue
providing irregular snapshot images.

Reyk

Re: 5.9-beta upgrade stalled at base59.tgz 98% fetched, 51072 KB on first try, retry succeeds

[Janne Johansson]

2016-01-18 18:39 GMT+01:00 Peter N. M. Hansteen :

> For about the last week, I've been seeing this oddity with the amd64
> installer when doing snap to snap upgrades on my laptop.
>
> My routine for quite a while has been to fetch snapshots off the local
> mirror whenever I notice there's a new one, recently about once a day,
> then installing by booting the new bsd.rd and pointing at the local
> directory for sets. This is a procedure that has just worked(TM) for years.
>
> But as I mentioned earlier, for about the last week the installer has
> consistently stalled at base59.tgz 98%, 51072 KB fetched, and stayed
> that way for long enough that I'd Ctrl-C out to the bsd.rd shell and
> restart by typing 'upgrade' at the prompt. The upgrade then proceeds
> with no issues on the second attempt. That is, on the previous attempts
> over the last few days I've usually opted for the http (most local
> mirror) as the source for sets.
>

I've seen it also, but in a VirtualBox amd64 vm which I more or less blamed
VB for.

But very alike your situation, stalls at base(58).tgz and restarts of the
upgrade script allows it to run through.

In my case, always got the sets from ftp.eu.openbsd.org..

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

Re: Building AMI for AWS EC2

[Reyk Floeter]

On Wed, Jan 20, 2016 at 08:56:25PM -0800, Jonathon Sisson wrote:
> On Wed, Jan 20, 2016 at 02:51:21PM -0800, Simon McFarlane wrote:
> > Hi all,
> > 
> > Now that the Xen guest stuff is getting some love, I think it would be fun
> > to toy around with OpenBSD on EC2 (particularly because of EBS -- other VPS
> > providers like the old standby ARP Networks don't allow you to attach
> > copious amounts of storage to a low-spec system).
> > 
> > There are a couple public AMIs available, but I'm curious as to how they are
> > built. It'd be pretty cool to be able to build a given snapshot into an AMI,
> > rather than be dependent on whomever is creating the public ones.
> > 
> > If the builder of the public AMIs is reading this, I'd love to hear what
> > your process is.
> > 
> > Thanks,
> > Simon
> > 
> I have a relatively simple process involving the use of vmimport.
> 
> Basically, build out the VM how you want (I used VirtualBox, but YMMV),
> then ran something like ec2-import-volume to bring the VHD into AWS.
> Once that was complete, I booted up an Amazon Linux instance, stopped it,
> detached the root volume, attached the OpenBSD volume as /dev/xvda, then
> booted up into OpenBSD.  Afterwards, create an AMI of your work.
> 
> Also note that OpenBSD won't recognize EBS volumes attached as anything
> other than xvd*.  I haven't bothered looking into why.
> 

We don't have a Xen driver for the blkfront disks yet, and we only
support the emulated IDE controller.  Nobody has started working on it
yet.  The Xen HVPVM layer and the netfront (xnf) driver were necessary
to bootstrap OpenBSD in EC2, the blkfront driver is optional but
needed to mount additional volumes.

Reyk

Re: igmp option 148 (RA)

[Stefan Sperling]

On Thu, Jan 21, 2016 at 12:27:06PM +0200, Kapetanakis Giannis wrote:
> Hi,
> 
> I'm constantly seeing this on my pf router.
> rule 61/(ip-option) pass in on $ext_if: $ext_gw > 224.0.0.1: igmp query [tos
> 0xc0] [ttl 1]
> 
> Rule 61 is:
> @61 pass quick inet proto igmp from $ext_if:network to 224.0.0.1 keep state
> (no-sync)
> 
> tcpdump on $ext_if shows:
> $ext_gw > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 59056, len 32,
> optlen=4 IPOPT-148{4})
> 
> I guess pf has a problem with ip-option 148 which is router alert (rfc2113)
> Is this normal? Why does it think it's bad?
> 
> Ext gateway is cisco (no under my control) which apparently is sending this
> option.
> 
> G

Multicast traffic is black-holed by default.
You may want to set multicast_host=Yes in /etc/rc.conf.local.
See the MULTICAST ROUTING section in the netstart(8) man page.

Re: timestamps

[Stuart Henderson]

On 2016-01-21, Steve Shockley  wrote:
> A while back [1], I posted a question asking about timeout issues using 
> Openup (or any transfers really) to work through a Websense proxy. 
> Later, I had problems with Smokeping on OpenBSD showing ~50% packet loss 
> going through the proxy.  After far too long staring at debug logs and 
> packet traces, it turned out that the proxy OS (CentOS) simply wasn't 
> passing the traffic through to the proxy.
>
> I found a description of a similar problem on Server Fault [2].  It 
> turned out OpenBSD was sending two SYN packets with timestamps (which 
> were dropped by CentOS), then sending a SYN without a timestamp (which 
> was successful).  Setting sysctl net.ipv4.tcp_timestamps=0 on the CentOS 
> proxy worked around the problem.
>
> So, what went wrong here?  Was the OpenBSD timestamp "too random" for 
> CentOS 6.7?  Or is there some other issue, and I'm just masking it by 
> disabling timestamps?

Removing timestamps will kill performance unless it's on a slow line.
It gives a good clue though - try this (on the centos box) instead:

http://stackoverflow.com/questions/8893888/dropping-of-connections-with-tcp-tw-recycle

igmp option 148 (RA)

[Kapetanakis Giannis]

Hi,

I'm constantly seeing this on my pf router.
rule 61/(ip-option) pass in on $ext_if: $ext_gw > 224.0.0.1: igmp query 
[tos 0xc0] [ttl 1]


Rule 61 is:
@61 pass quick inet proto igmp from $ext_if:network to 224.0.0.1 keep 
state (no-sync)


tcpdump on $ext_if shows:
$ext_gw > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 59056, len 32, 
optlen=4 IPOPT-148{4})


I guess pf has a problem with ip-option 148 which is router alert (rfc2113)
Is this normal? Why does it think it's bad?

Ext gateway is cisco (no under my control) which apparently is sending 
this option.


G

Re: vmm(4) status?

[Peter N. M. Hansteen]

On Wed, Jan 20, 2016 at 06:20:48PM +0100, Reyk Floeter wrote:
 
> It is not enabled in GENERIC, so obviously not ready yet :)
> 
> The CPU usage, time and networking issues are know and should go away
> after mlarkin@ finished implementing proper interrupt handling. 
> 
> On the userland side, the networking configuration will be changed to
> a slightly different approach, but I kind of suspended this until the
> previous issue is solved.

for the terminally curious among us, do you have a ballpark figure for when
it comes back in GENERIC? (as in, pre- or post-5.9?)

- P
-- 
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: ??????a problem with pf's NAT...

[Marko Cupać]

On Thu, 21 Jan 2016 09:19:32 +0100
"Peter N. M. Hansteen"  wrote:


> I've already told you the basic steps, but as to the PF part, I'd
> start with a block, then open the stuff I need, as in

Or even better, start with 'block log', and inspect blocked traffic in
real time with:
# tcpdump -n -e -q -ttt -i pflog0

Or see what has been blocked in the past with:
# tcpdump -n -e -q -ttt -r /var/log/pflog
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: openbgpd puts wrong nexthop in FIB

[Stuart Henderson]

On 2016-01-20, Tony Sarendal  wrote:
> network inet connected is broken in 5.6, 5.8 and -current.
> Restarting bgpd is required when making interface changes.

Ah, so it was fixed in 5.7 and broken again? Now the previous mail
(http://permalink.gmane.org/gmane.os.openbsd.misc/227597) makes more
sense.

Re: Building AMI for AWS EC2

[Jonathon Sisson]

On Thu, Jan 21, 2016 at 09:30:57AM +0100, Reyk Floeter wrote:
> On Wed, Jan 20, 2016 at 08:56:25PM -0800, Jonathon Sisson wrote:
> > On Wed, Jan 20, 2016 at 02:51:21PM -0800, Simon McFarlane wrote:
> > > Hi all,
> > > 
> > > Now that the Xen guest stuff is getting some love, I think it would be fun
> > > to toy around with OpenBSD on EC2 (particularly because of EBS -- other 
> > > VPS
> > > providers like the old standby ARP Networks don't allow you to attach
> > > copious amounts of storage to a low-spec system).
> > > 
> > > There are a couple public AMIs available, but I'm curious as to how they 
> > > are
> > > built. It'd be pretty cool to be able to build a given snapshot into an 
> > > AMI,
> > > rather than be dependent on whomever is creating the public ones.
> > > 
> > > If the builder of the public AMIs is reading this, I'd love to hear what
> > > your process is.
> > > 
> > > Thanks,
> > > Simon
> > > 
> > I have a relatively simple process involving the use of vmimport.
> > 
> > Basically, build out the VM how you want (I used VirtualBox, but YMMV),
> > then ran something like ec2-import-volume to bring the VHD into AWS.
> > Once that was complete, I booted up an Amazon Linux instance, stopped it,
> > detached the root volume, attached the OpenBSD volume as /dev/xvda, then
> > booted up into OpenBSD.  Afterwards, create an AMI of your work.
> > 
> > Also note that OpenBSD won't recognize EBS volumes attached as anything
> > other than xvd*.  I haven't bothered looking into why.
> > 
> 
> We don't have a Xen driver for the blkfront disks yet, and we only
> support the emulated IDE controller.  Nobody has started working on it
> yet.  The Xen HVPVM layer and the netfront (xnf) driver were necessary
> to bootstrap OpenBSD in EC2, the blkfront driver is optional but
> needed to mount additional volumes.
> 
> Reyk
> 
Ahh, understood.  It wasn't necessarily an issue, as I've been able to
mount any EBS volume I want as xvd* devices, so certainly not a concern,
it was just behavior I noticed =)

Thanks for the explanation!

Re: ??????a problem with pf's NAT...

[Peter N. M. Hansteen]

On Thu, Jan 21, 2016 at 12:25:16AM +0800, zje.net.cn wrote:
> sorry, i had tried many times with inspecting all settings, but can't make 
> the NAT well done yet.In this environment, my haproxy is working well, so i 
> think the base network settings are good 

As long as you're not providing any further information, we're left to
speculate as to the real reason.

I've already told you the basic steps, but as to the PF part, I'd start with a 
block, then open the stuff I need, as in

int_if = "de1"#10.0.11.200
ext_if = "de2"   #61.xxx.xx.xx
int_net = "10.0.11.0/24"

block
match out on egress inet nat-to $ext_if
pass inet from $int_net 

(hint: careful where you block and where you pass)

-- 
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: ??????a problem with pf's NAT...

[Peter N. M. Hansteen]

On Thu, Jan 21, 2016 at 10:14:25AM +0100, Marko Cupa?? wrote:
> Or even better, start with 'block log', and inspect blocked traffic in
> real time with:
> # tcpdump -n -e -q -ttt -i pflog0

Very true. Or even add log (all) to all rule if you want all packets. The main 
point remains,
logging is essential to debugging, which is what the original poster needs to 
do.

-- 
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: openbgpd puts wrong nexthop in FIB

[Denis Fondras]

> network inet connected is broken in 5.6, 5.8 and -current.
> Restarting bgpd is required when making interface changes.
> 

Thank you very much Tony.

nat-t quirks with iked on openbsd 5.8

[Sascha Biberhofer]

Hi misc@,

I'm using iked to establish ipsec tunnels on a multi-homed OpenBSD
system (classical failover setup). iked is used to initialize key
exchanges between various servers (which run strongswan/charon for IKE
via ikev2).

The iked.conf basically consists of entries like

ikev2 active esp from $localsubnet to $remotesubnet peer $peerip

The thing that I've noticed is that whenever iked initiates the IKE, the
following line is logged:

ikev2_msg_send: IKE_SA_INIT request from 0.0.0.0:500 to $peerip:500...

The strongswan server on the peer then detects that a NAT is in place,
while the iked detects no such thing. This leads to the OpenBSD system
expecting/sending ESP packets while the peer expects and sends
udp-encapsulated ESP packets on port 4500. This leads to a non-working
ipsec configuration (even though it probably shouldn't matter).


If, on the other hand, the very same configuration is used, but the IKE
is initialized by the peer, then iked logs:

ikev2_msg_send: IKE_SA_INIT request from $interfaceip:500 to $peerip:500
...

In this case, no NAT is detected and everything works as expected.


I'm neither an expert on ipsec and its related protocols, and neither
are my C skills sufficient to understand the code behind iked, but it
seems that iked doesn't include the proper NAT detection IP if
multiple routes/interfaces are present.

Clearly, this can be avoided if one adds the "local $interfaceip"
statement to the entries in iked.conf, but this would require two
configurations, one for each interface and a restart of iked when
failover occurs (at least as far as I can tell).

In fact, looking iked's debug output, one gets

ikev2_nat_detection: local source 0x17284e621a47c05d 0x
0.0.0.0:500

w/o the "local" statement and

ikev2_nat_detection: local source 0x5b69fb18d2980778 0x
10.10.0.151:500

w/ the "local" statement in place.

Is this behaviour intentional i.e. is there no way around specifying a fixed
local IP? The primary interface has a dynamic IP, which would require me to
recreate the iked.conf whenever an IP-change or failover has been
detected (which is how I've worked around the problem right now, but this
feels like a hackish solution).

Also, shouldn't iked accept udp-encapsulated ESP regardless of whether a
NAT was detected? RFC 5996 at least mentions in section 2.23 that
"implementations MUST process received UDP-encapsulated ESP packets even
when no NAT was detected.", but as far as I can tell iked discards the
UDP-encapsulated ESP packets.

Cheers,
Sascha

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: 5.9-beta upgrade stalled at base59.tgz 98% fetched, 51072 KB on first try, retry succeeds

[mark9]

Folks,

I also see this, on an i386 system.  It's been happening since 2015-12-19,
but I hadn't used snapshots since 2015-09-25, where it did not occur.  I
download snapshots from mirror.ox.ac.uk.

Installing base59.tgz stalls at 98%, 48128KB.

Dmesg can be found at http://www.hydrus.org.uk/ref/chrome.txt

-mark
> -Original Message-
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On
> Behalf Of Janne Johansson
> Sent: 21 January 2016 08:11
> To: Peter N. M. Hansteen ; Misc 
> Subject: Re: 5.9-beta upgrade stalled at base59.tgz 98% fetched,
> 51072 KB on first try, retry succeeds
> 
> 2016-01-18 18:39 GMT+01:00 Peter N. M. Hansteen :
> 
> > For about the last week, I've been seeing this oddity with the
> amd64
> > installer when doing snap to snap upgrades on my laptop.
> >
> > My routine for quite a while has been to fetch snapshots off the
> local
> > mirror whenever I notice there's a new one, recently about once a
> day,
> > then installing by booting the new bsd.rd and pointing at the local
> > directory for sets. This is a procedure that has just worked(TM)
> for years.
> >
> > But as I mentioned earlier, for about the last week the installer
> has
> > consistently stalled at base59.tgz 98%, 51072 KB fetched, and
> stayed
> > that way for long enough that I'd Ctrl-C out to the bsd.rd shell
> and
> > restart by typing 'upgrade' at the prompt. The upgrade then
> proceeds
> > with no issues on the second attempt. That is, on the previous
> attempts
> > over the last few days I've usually opted for the http (most local
> > mirror) as the source for sets.
> >
> 
> I've seen it also, but in a VirtualBox amd64 vm which I more or less
> blamed
> VB for.
> 
> But very alike your situation, stalls at base(58).tgz and restarts of
> the
> upgrade script allows it to run through.
> 
> In my case, always got the sets from ftp.eu.openbsd.org..
> 
> --
> May the most significant bit of your life be positive.

Missing "boot> machine regs" on amd64

[edward wandasiewicz]

The man page on boot(8) for amd64 says we should be able to print the
contents of the processor registers if compiled with DEBUG.

If we can do so on amd64, it seems we are missing a few debug.* files
in the amd64 source tree to do so.

% find /usr/src/sys/ -type f | xargs grep -l "DUMP_REGS"
/usr/src/sys/arch/amd64/stand/libsa/cmd_i386.c
/usr/src/sys/arch/i386/stand/libsa/cmd_i386.c
/usr/src/sys/arch/i386/stand/libsa/debug_md.h

% find /usr/src/sys/ -type f | xargs grep -l "debug_md.h"
/usr/src/sys/arch/i386/stand/libsa/CVS/Entries
/usr/src/sys/arch/i386/stand/libsa/debug.h
/usr/src/sys/arch/i386/stand/libsa/debug_i386.S
/usr/src/sys/arch/i386/stand/libsa/debug_md.h
/usr/src/sys/arch/i386/stand/libsa/gidt.S

Are we missing this feature on amd64?

Or should the man page for boot(8) amd64 be changed if this feature is
not available on amd64?

Edward.

Re: Mismatch between config and documentation for dhcpd?

[Etienne]

On 2016-01-21 12:28, Raf Czlonka wrote:

I didn't add a prefix, it's been added in the log by the program 
itself. My

config file looked like below:

option domain-name-servers 192.168.0.71, 192.168.0.149;
option classless-static-routes 192.168.32/24 192.168.0.1;

 ^
Is this by any chance because the above is not valid CIDR and should
have been, 192.168.32.0/24?


I just tried, I'm afraid it doesn't make any change.

--
Étienne

Re: Mismatch between config and documentation for dhcpd?

[Etienne]

On 2016-01-21 12:28, Raf Czlonka wrote:

   I didn't add a prefix, it's been added in the log by the 
program itself. My

   config file looked like below:

   option domain-name-servers 192.168.0.71, 192.168.0.149;
   option classless-static-routes 192.168.32/24 
192.168.0.1;



^
   Is this by any chance because the above is not valid CIDR and should
   have been, 192.168.32.0/24?


I just tried, I'm afraid it doesn't make any change.

--
Étienne

BUILDINFO file included in system snapshot dirs...

[Adam Jeanguenat]

I hadn't seen anything posted to misc@ or tech@ about this yet, but
wanted to thank the person responsible for the relatively recent
addition (looks like late Oct or early Nov 2015) of the BUILDINFO
file included with the kernel/base snapshots. I only noticed it last
week and it was a rather nice surprise.

There's a tool I've cleverly dubbed 'trackcur' created and massaged
over the years to help automate the process of following -current
using the install kernel and binary packages. The original intent was
to avoid some of the potential pitfalls I encountered while following
the process manually (like updating to a flag-day snapshot which
doesn't yet have package snapshots built or updating packages from a
mirror still syncing from the master site), and it's grown to include
other useful things to help stay up-to-date like syncing a repo via
cvsync and checking out a local copy of src+ports from it.

The biggest challenge was trying to devise a way to reliably and
consistently track file timestamps on an arbitrary mirror via
arbitrary transport without several hacky transport-specific methods
-- e.g., HTML scraping and/or checking Last-Modified for HTTP
transport.

I'm not privy to how the snapshot package builds make it up to the
master site, but would it be possible to generate a similar file that
would live in the root of a given arch's package snaps? It would
satisfy my selfish needs, but I think others may also see the value
in a similar file for package builds. This would provide definitive
information on the build, independent of file timestamps that may be
lost or unavailable depending on the method of transfer.

Is the generation of this file something that can be done relatively
easy?

Thanks,

--avj

Problem with CARP interfaces not responding until VHID is changed.

[rizz2pro .]

Hello,

This is my first time posting here so be gentle.


It seems that random CARP interfaces on our systems will just die, stop
replying to any requests OR only 1 request out of ~50 will make it through,
slowly.

tcpdump also shows no traffic reach the interface. Only when that 1 request
makes it through, we will see traffic arrive to the system.

We've tried everything we could think of to bring the carp interface back
to life such as reboot, run sh /etc/netstart and even going as far as
rebuilding the system server from scratch with maven and dropping the
site55.tgz file in there but none of these things fix the issue.

When we change the VHID to anything else and restart the interface, it
fixes everything and the interface is smoking fast again. When we change
the VHID back to what it originally was, we're dead in the water. Again,
change it back to any random VHID and the issue goes away. So I have
narrowed it down to VHID. Whenever we run into this problem I just tell
people to change it to anything else.

I know the CARP interface's MAC address is generated by the VHID so I am
sort of leaning towards it be an ARP issue and possibly not an issue with
the OBSD system. But I am hoping for some hints or ideas from you guys.

Thanks in advance for any help!

RZ

Re: timestamps

[Steve Shockley]

On 1/21/2016 5:53 AM, Stuart Henderson wrote:

Removing timestamps will kill performance unless it's on a slow line.
It gives a good clue though - try this (on the centos box) instead:

http://stackoverflow.com/questions/8893888/dropping-of-connections-with-tcp-tw-recycle


Better reference.
http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html


Thanks!  I'll give it a shot.

Re: openbgpd puts wrong nexthop in FIB

[Tony Sarendal]

2016-01-21 11:16 GMT+01:00 Stuart Henderson :

> On 2016-01-20, Tony Sarendal  wrote:
> > network inet connected is broken in 5.6, 5.8 and -current.
> > Restarting bgpd is required when making interface changes.
>
> Ah, so it was fixed in 5.7 and broken again? Now the previous mail
> (http://permalink.gmane.org/gmane.os.openbsd.misc/227597) makes more
> sense.
>
>
That sums is up well. Serious a bug in a piece of routing software.

/T

Re: Problem with CARP interfaces not responding until VHID is changed.

[Alexander Salmin]

Hey,

Welcome to the OpenBSD community mailing list. I'm also using CARP for 
lots of HA-setups and yes, I will be gentle. I have never had issues 
like yours but my setup seems very different. The virtual host id (vhid) 
and its ip adress becomes a carp-group, so changing the vhid back and 
forth is not something I understand why you are doing.


 - Try to isolate this to 2 simple test machines with as simple setup 
as possible. Be simple.
 - Make those machines either run the release version or current. State 
which.

 - Then continue;
  - Post your interfaces configurations.
  - Post your dmesg
  - Post your pf.conf
  - Post your tcpdump (where you observed this, make it as small as 
possible)
  - Also some information about why you are changing vhid would be 
interesting.
  - vhid needs to be the same on all hosts participating in the same 
carp interface.
  - if you change vhid, the other host(s) on the other side also needs 
to change.
  - Are you using a carp on top of any other non-hardware interface? 
Like a vlan, with carpdev?
  - Also, many people forget this, but if you type "man 4 carp" you 
will find a lot of good stuff to be read about carp, vhids, carpdev and 
such.


Best of luck,
Alexander





On 01/21/2016 11:02 PM, rizz2pro . wrote:

Hello,

This is my first time posting here so be gentle.


It seems that random CARP interfaces on our systems will just die, stop
replying to any requests OR only 1 request out of ~50 will make it through,
slowly.

tcpdump also shows no traffic reach the interface. Only when that 1 request
makes it through, we will see traffic arrive to the system.

We've tried everything we could think of to bring the carp interface back
to life such as reboot, run sh /etc/netstart and even going as far as
rebuilding the system server from scratch with maven and dropping the
site55.tgz file in there but none of these things fix the issue.

When we change the VHID to anything else and restart the interface, it
fixes everything and the interface is smoking fast again. When we change
the VHID back to what it originally was, we're dead in the water. Again,
change it back to any random VHID and the issue goes away. So I have
narrowed it down to VHID. Whenever we run into this problem I just tell
people to change it to anything else.

I know the CARP interface's MAC address is generated by the VHID so I am
sort of leaning towards it be an ARP issue and possibly not an issue with
the OBSD system. But I am hoping for some hints or ideas from you guys.

Thanks in advance for any help!

RZ