Re: relayd: "listen on egress" only listens to IPv4 and not IPv6

[Sebastian Benoit]

Thanks for the feedback.
I guess now i have to try and remember what this was about ;-)

/Benno


Stefan R. Filipek(srfili...@gmail.com) on 2024.02.03 09:47:45 -0500:
> Hi all,
> 
> Reviving a really old thread, but this problem still exists in 7.4 and
> is impacting my use case as well.
> 
> However, I can confirm that this patch does fix the issue. An
> additional "struct keyname  *name;" was required in the function, but
> otherwise it works as-is.
> 
> Best,
> Stefan
> 
> 
> 
> On Tue, Sep 17, 2019 at 2:03???PM Muhammad Kaisar Arkhan  
> wrote:
> >
> > Hi,
> >
> > No, not yet. I've been busy with life atm (Uni just started and other 
> > stuff). I'm hoping to test it this weekend.
> >
> > Thanks.
> >
> >
> > Le September 17, 2019 ?? 1:51 PM Sebastian Benoit 
> > <http://benoit-li...@fb12.de > a ??crit:
> >
> > > Hi,
> > >
> > > did you manage to test the diff?
> > >
> > > /Benno
> > >
> > > Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 17:05:34 +0200:
> > >
> > > > > Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 16:44:37 
> > > +0200:
> > > >
> > > > > > > Muhammad Kaisar Arkhan(h...@yukiisbo.red) on 
> > > > 2019.08.29 14:55:03 +0200:
> > > > >
> > > > > > > > > Hi Tom,
> > > > > >
> > > > > >
> > > > > > > > > > > listen on 
> > > > > > 2a03:6000:9106::50f7:f07a:d1cc port 443 tls
> > > > > > >
> > > > > > > > > > > I've tried this before, 
> > > > > > > it just results in this:
> > > > > >
> > > > > > /etc/relayd.conf:33: cannot load certificates for 
> > > > > > relay https2:443
> > > > > >
> > > > > > > > > Your error says "for relay https2", 
> > > > > > but the relayd.conf file you quote does
> > > > > not have a relay "https2".
> > > > >
> > > > > Please show the output of "relayd -nvv" and *exactly* the 
> > > > > /etc/relayd.conf
> > > > > file at the time when you ran the command.
> > > > >
> > > > > > > sorry, my mistake: the https2 there is fine, it 
> > > > > comes from the second
> > > > "listen ..." directive.
> > > >
> > > > I think i found the issue: relays with multiple listen 
> > > > statements do not
> > > > work with keypair currently.
> > > >
> > > > Can you test this diff with a config that has a listen on the 
> > > > v4 adress and
> > > > a listen on the v6 adress, not the "egress" method.
> > > >
> > > > If it does not work, please show again your config and "relayd 
> > > > -nvv".
> > > >
> > > > /Benno
> > > >
> > > > diff --git usr.sbin/relayd/parse.y usr.sbin/relayd/parse.y
> > > > index c6e2bcacdfb..8338d5c9e6d 100644
> > > > --- usr.sbin/relayd/parse.y
> > > > +++ usr.sbin/relayd/parse.y
> > > > @@ -3323,11 +3312,19 @@ relay_inherit(struct relay *ra, struct 
> > > > relay *rb)
> > > > goto err;
> > > > }
> > > >
> > > > - if (relay_load_certfiles(conf, rb, NULL) == -1) {
> > > > + if (TAILQ_EMPTY(&rb->rl_proto->tlscerts) &&
> > > > + relay_load_certfiles(conf, rb, NULL) == -1) {
> > > > yyerror("cannot load certificates for relay %s",
> > > > rb->rl_conf.name);
> > > > goto err;
> > > > }
> > > > + TAILQ_FOREACH(name, &rlay->rl_proto->tlscerts, entry) {
> > > > + if (relay_load_certfiles(conf, rb, name->name) == -1) {
> > > > + yyerror("cannot load keypair %s for relay %s",
> > > > + name->name, rb->rl_conf.name);
> > > > + goto err;
> > > > + }
> > > > + }
> > > >
> > > > TAILQ_FOREACH(rta, &ra->rl_tables, rlt_entry) {
> > > > if ((rtb = calloc(1, sizeof(*rtb))) == NULL) {
> > > >
> > > > > --
> > >
> 

-- 

Re: htop install fails on -current

[Sebastian Benoit]

Louis Brauer(lo...@emacs.ch) on 2024.01.28 20:54:17 +:
> I've just installed 7.4-current on an ARM64 machine and tried to pkg_add the 
> "htop" package. It fails and this is the output of pkg_add:
> 
> # pkg_add htop
> quirks-7.0:updatedb-0p0: ok
> quirks-7.0 signed on 2024-01-21T11:57:22Z
> quirks-7.0: ok
> htop-3.2.2:bzip2-1.0.8p0: ok
> htop-3.2.2:pcre2-10.37p1: ok
> htop-3.2.2:libiconv-1.17: ok
> Can't install gettext-runtime-0.22.4 because of libraries
> |library c++.9.0 not found
> | /usr/lib/libc++.so.10.0 (system): bad major
> |library c++abi.6.0 not found
> | /usr/lib/libc++abi.so.7.0 (system): bad major
> Direct dependencies for gettext-runtime-0.22.4 resolve to libiconv-1.17
> Full dependency tree is libiconv-1.17
> htop-3.2.2:libffi-3.4.4p0: ok
> htop-3.2.2:sqlite3-3.44.2: ok
> htop-3.2.2:xz-5.4.5: ok
> Can't install python-3.10.13p0: can't resolve gettext-runtime-0.22.4
> Can't install glib2-2.78.3: can't resolve 
> python-3.10.13p0,gettext-runtime-0.22.4
> Can't install desktop-file-utils-0.27: can't resolve glib2-2.78.3
> Can't install htop-3.2.2: can't resolve desktop-file-utils-0.27
> Couldn't install desktop-file-utils-0.27 gettext-runtime-0.22.4 glib2-2.78.3 
> htop-3.2.2 python-3.10.13p0
> 
> It works fine on -stable. Since I do not have much experience with
> -current or the package system, I'm not sure if that is a bug in the
> -current tree or if there is anything I missed?

libc++ and libc++abi were updated on the 26th. The changes were incompatible
with the previous version so they got newer version numbers.

This can happen on -current. On OpenBSD, there is no guarantee for binary
backward compatibility of libaries, so when the version changes, binaries
need to be recompiled.

Now, packages are build independent from the base. This means that there is
a time lag between such a library bump and the packages catching up.
Wait a few hours or a day and try pkg_add again.

The same can happen when you upgrade to a newer -current.
If you run current, you have to live with this.

/B.

> 
> Any advice would be much appreciated.
> 
> - Louis
> 

-- 

Re: 7.4 and hostname.pfsync7

[Sebastian Benoit]

Harald Dunkel(ha...@afaics.de) on 2023.10.15 06:51:08 +0200:
> Hi folks,
> 
> I learned that pfsync has been rewritten for 7.4 and that
> 
>   up
>   syncdev em7
> 
> doesn't work anymore. What about
> 
>   up syncdev em7
> 
> (one line), as suggested in the current pfsync(4)?

Did you try it?

Re: dhcpleased losing route

[Sebastian Benoit]

David Diggles(da...@elven.com.au) on 2023.05.11 08:09:54 +1000:
> Thanks Florian, here's a tcpdump from the Apple (NetBSD) router.
> This implementatin isn't losing the default route.
> 
> tcpdump -n -i mgi1 -s1500 -vv port 67 or 68
> tcpdump: listening on mgi1, link-type EN10MB (Ethernet), capture size 1500 
> bytes
> 07:15:36.010329 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: 
> 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300
> 07:15:40.326961 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: 
> 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300
> 07:15:47.010316 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: 
> 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300
> 07:15:47.065803 IP (tos 0xc0, ttl 128, id 47543, offset 0, flags [none], 
> length: 328) 202.63.66.1.67 > 255.255.255.255.68: [udp sum ok] UDP, length: 
> 300
> 07:15:47.066581 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], length: 
> 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] UDP, length: 300
> 07:15:47.281209 IP (tos 0xc0, ttl 128, id 59063, offset 0, flags [none], 
> length: 328) 202.63.66.1.67 > 255.255.255.255.68: [udp sum ok] UDP, length: 
> 300
> 07:20:42.239765 IP (tos 0x0, ttl  64, id 31050, offset 0, flags [none], 
> length: 328, bad cksum 0 (->e6b6)!) 202.63.67.36.68 > 202.63.66.1.67: [bad 
> udp cksum 8b57!] UDP, length: 300
> 07:20:42.288197 IP (tos 0xc0, ttl 128, id 45441, offset 0, flags [none], 
> length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300
> 07:25:07.019747 IP (tos 0x0, ttl  64, id 18503, offset 0, flags [none], 
> length: 328, bad cksum 0 (->17ba)!) 202.63.67.36.68 > 202.63.66.1.67: [bad 
> udp cksum 8b57!] UDP, length: 300
> 07:25:07.085454 IP (tos 0xc0, ttl 128, id 28472, offset 0, flags [none], 
> length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300
> 07:30:08.019746 IP (tos 0x0, ttl  64, id 46516, offset 0, flags [none], 
> length: 328, bad cksum 0 (->aa4c)!) 202.63.67.36.68 > 202.63.66.1.67: [bad 
> udp cksum 8b57!] UDP, length: 300
> 07:30:08.068323 IP (tos 0xc0, ttl 128, id 21000, offset 0, flags [none], 
> length: 328) 202.63.66.1.67 > 202.63.67.36.68: [udp sum ok] UDP, length: 300

Hi,

i think that putput does not help mmuch because it does not show the DHCP
packet contents.

You could write the capture to a file with "-w filename" and then copy the
file to the OpenBSD box for printing with "-r filename". Or send the raw
pcap file.

/B.
 
> On Wed, May 10, 2023 at 04:38:25PM +0200, Florian Obser wrote:
> > ( this is a good dhcp state diagram to follow along at home: 
> > https://commons.wikimedia.org/wiki/File:DHCP_Client_State_Diagram_-_en.png )
> > 
> > On 2023-05-10 23:07 +10, David Diggles  wrote:
> > > I probably should have done numeric tcpdump output. Here's both again.
> > >
> > > tcpdump: WARNING: snaplen raised from 116 to 1500
> > > 22:36:40.276682 0.0.0.0.68 > 255.255.255.255.67: xid:0x74253f08 
> > > vend-rfc1048 DHCP:REQUEST HN:"sarah" CID:1.220.159.219.40.20.191 
> > > PR:SM+DG+NS+HN+DN+BR+119+121 RQ:202.63.67.36 [tos 0x10]
> > 
> > dhcpleased starts up and we have a lease file in /var/db/dhcpleased/, we
> > are in INIT-REBOOT and ask the dhcp server via broadcast if we can use
> > our previous IP address 202.63.67.36. We go to state REBOOTING.
> > 
> > > 22:36:40.327371 202.63.66.1.67 > 255.255.255.255.68: xid:0x74253f08 
> > > flags:0x8000 Y:202.63.67.36 S:172.21.116.42 ether dc:9f:db:28:14:bf 
> > > vend-rfc1048 DHCP:ACK SM:255.255.254.0 DG:202.63.66.1 
> > > NS:119.40.106.35,119.40.106.36 NTP:125.253.59.254 LT:600 SID:202.63.66.1 
> > > CID:1.220.159.219.40.20.191 [tos 0xc0]
> > 
> > dhcp server: yeah, that's fine (DHCP:ACK). Lifetime is 600 seconds. We
> > configure the interface and go into state BOUND.
> > 
> > some time passes
> > 
> > > 22:41:40.422661 202.63.67.36.56480 > 202.63.66.1.67: (request) 
> > > xid:0xa180ce6b C:202.63.67.36 vend-rfc1048 DHCP:REQUEST HN:"sarah" 
> > > CID:1.220.159.219.40.20.191 PR:SM+DG+NS+HN+DN+BR+119+121
> > 
> > Time T1 expires, we send a unicast DHCPREQUEST to the dhcpserver: is it
> > OK to hold on to our IP address? We go into state RENEWING.
> > 
> > > 22:41:40.434534 202.63.66.1.67 > 202.63.67.36.68:  xid:0xa180ce6b 
> > > C:202.63.67.36 S:172.21.116.42 vend-rfc1048 DHCP:NACK SID:202.63.66.1 
> > > CID:1.220.159.219.40.20.191 [tos 0xc0]
> > 
> > dhcp server: Absolutely not! DHCP:NACK.
> > 
> > RFC 2131 has this:
> > 
> >   If the client receives a DHCPNAK message, it cannot reuse its
> >   remembered network address.  It must instead request a new
> >   address by restarting the configuration process, this time
> >   using the (non-abbreviated) procedure described in section
> >   3.1.  This action also corresponds to the client moving to
> >   the INIT state in the DHCP state diagram.
> > 
> > There is not a lot of wiggle room, we MUST remove our address. We go to
> > s

Re: Gmux Driver Macbook Pro for backlight control.

[Sebastian Benoit]

Leonardo Moreno(leomor...@hey.com) on 2022.09.18 16:01:18 -0500:
> Hi everyone.
> 
> Last week I sent a diff to @tech that controls the hardware??
> display backlight in a MacBook Pro mid-2015 since I got??
> tired of looking at a partially illuminated screen.

Sounds reasonable :)

> 
> https://marc.info/?l=openbsd-tech&m=166274342026233&w=2
> 
> I had to refer for some guidance to the Linux apple-gmux code in order??
> to get it working so there might be an issue with the license.
> 
> Does anyone know if it has any chance of being commited?

Well, you are asking on the wrong list.
Ask again on tech@, for example reply to your previous mail.

Sometimes you have to be a bit patient and then ask again. Maybe the person
who knows what your diff is about is busy with other things, or on holiday.
 
> Is this kind of driver development relevant to the purpose of OpenBSD???
> Is the hardware too niche to justify adding it to the system?
> 
> Thanks,
> 
> Leonardo
> 

-- 

Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1

[Sebastian Benoit]

Stuart Henderson(s...@spacehopper.org) on 2021.11.13 00:11:08 +:
> I have a pair of -current routers running bgpd (let's call them rtr-a
> and rtr-b) on a subnet which also has some vpn gateways and firewalls.
> 
> These routers provide a carp address which the vpn gateways are using
> as default route. There are some networks behind the vpn gateways (a
> /32 to accept incoming vpn connections and some other prefixes that vpn
> clients are numbered from).
> 
> rtr-a and rtr-b have static routes to those networks, and they have
> network statements in bgpd.conf to announce them to their ibgp peers
> ("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are reachable
> from the rest of the network. (This is replacing an existing setup using
> ospf, trying to remove routing protocols from machines that don't really
> need them).
> 
> It is working but something seems a little odd - the paths are announced
> from both routers briefly and show up on the rest of the network from
> both rtr-a and rtr-b. But after a few seconds, rtr-b receives these
> paths from rtr-a, and then rtr-b stops announcing them itself. (they
> stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh nex" does
> correctly identify the associated nexthops as connected/UP).
> 
> Is this expected/correct behaviour?

It is expected: once rtr-b receives the route from rtr-a, it will run the
route decision process on it. IF both routers are configured identically
except for the router-id, one of the routes will be prefered at either the
"oldest path" or the "lowest bgp id" criteria.

As only one route is a best route, that one will be annouced to the
neighbors. However this is IBGP. In a set of IBGP connected routers, a
router will not announce a route to other IBGP peers that it received from
on a IBGP session. Thus, rtr-b will stop announcing that route.

When rtr-a goes down, the session is shut down or the prefix is filtered,
bgpd wont see the "better" route anymore and announce its own instead.

> I'd prefer to have them announced from both rtr-a and rtr-b, so there's
> no blackhole period if rtr-a is restarted while rtr-b figures out that
> it should start announcing them, etc. (No need for tracking carp state
> in this case, I'm not using stateful pf rules on the traffic involved).

This is a place where ospf might give you faster failover, especiall y with
the redistribute ... depend on ... syntax.
 
> If rtr-b stops seeing the prefixes from rtr-a (either by taking down
> the ibgp session, or by filtering) I see the announcements from both
> rtr-a and rtr-b again. So the obvious workaround is to filter, but
> I thought I'd ask first in case it's something that is better handled
> by code changes rather than config.

Re: dhcpleased: interface "stalls" during Renewing

[Sebastian Benoit]

Peter Gorsuch(gorsu...@cfw.com) on 2021.11.13 08:25:00 -0500:
> Hi All,
> 
> As [Renewing] begins and during the renewing cycle (as I view 
> configuration with dhcpleasectl -l fxp0) about halfway through the 
> ISP'one hour dhcp lease, the external interface seems to become "stalled".
> 
> "Stalled" is a term that describes the experience of using a host on the 
> lan, as one's video is fine, then stops, then starts up again after some 
> period of time.
> 
> This on a dual homed i386 GENERIC installation planned to be a router 
> and run unbound and dhcp for the lan.
> Subject to my understanding, I'm informed by 
> https://www.mail-archive.com/misc@openbsd.org/msg180064.html and I 
> imagine there is some interplay with the dhcp rebinding/renewing 
> timer(s) and name resolution.

Have you tried the fix suggested by florian@ in that thread?

If not you can upgrade to the latest snapshot, that change was commited
yesterday.

Re: dhcpleased(8) not renewing leases

[Sebastian Benoit]

Eike Lantzsch ZP6CGE(zp6...@gmx.net) on 2021.11.04 18:07:57 -0300:
> On Mittwoch, 3. November 2021 14:41:08 -03 Zack Newman wrote:
> > dhcpleased(8) is unable to renew DHCP leases from my ISP,
> > Xfinity/Comcast. This in turn is causing leases to expire leading to
> > IPv4 drops that last between 15 and 20 seconds until a new lease can
> > be binded. Note that lease binding does succeed.
> Hi Zack,
> Similarily here. Did you specify a lladdr in your hostname.if after
> "dhcp"?
> I get a lease with my hardware MAC address without specifying lladdr,
> but it is not the right one of course. If I force the fake MAC address
> and then I ask for a new lease I get nothing.
> I'm going to write about it later together with all the pertinent
> infomation. Just now I am too busy with other disasters.

please include tcpdump of both the non-working attempts and the working
attempts (if it is indeed successful with dhclient), with a command like
this:

  tcpdump -enlp -i iwm0 port 67 and port 68

Also include your hostname.if file and dhclient.conf and dhcpleased.conf if
any.

> Cheers
> Eike
> >
> > For about a month before the release of OpenBSD 7.0, I had been using
> > dhcpleased(8) instead of dhclient(8) on OpenBSD 6.9 as I wanted to be
> > "ahead of the curve" before the eventual release of OpenBSD 7.0.
> > During that time, there were no problems with lease renewals. I have
> > not made any hardware or software changes other than the upgrade to
> > 7.0.
> >
> > I've factory reset my bridge modem about a dozen times, I've changed
> > the MAC address of the interface connected to the modem, I've
> > experimented using different NICs altogether, and nothing has worked.
> > At the time, I "knew" it was Xfinity; so I demanded that a tech come
> > over and inspect the cable lines and modem. They said it was fine;
> > although based on Internet reviews, that doesn't say much as they are
> > often wrong. It wasn't until I had a slice of humble pie and actually
> > considered that the problem was indeed my router that I was able to
> > fix the problem by switching to dhcpcd which I have been already
> > using for DHCPv6. Sure enough, I have had no issues with IPv4
> > renewals since then.
> >
> > I do know that Xfinity, at least where I am, does NOT respond to
> > unicast renewals for both DHCP and DHCPv6, but I am unsure if that is
> > relevant. Before I successfully switched to dhcpcd, I made sure to
> > log dhcpleased(8) over night. Here are the results:
> [snip]
> 
> 
> 

-- 

Re: pf and tap interfaces

[Sebastian Benoit]

tech-lists(tech-li...@zyxst.net) on 2021.10.31 15:10:57 +:
> Hello misc@
> 
> Generically, can OpenBSD [7.0] apply rules to *just* the ethernet
> interface, ignoring the bridge and tap interfaces? Can it do this
> natively or is a VLAN required as well? Or something else?
> 
> I'm asking this here because I'm trying to do this with FreeBSD 
> but their pf has diverged a lot from OpenBSD's, and what I thought 
> would work does not. skip on $tap_ifs has unexpected results in that
> traffic still gets blocked on the guest.
> 
> If OpenBSD's pf does work for my use case, then a way to solving my
> issue may be to have an OpenBSD guest in the FreeBSD host managing the
> pf for the host as bhyve has pci passthru. The other way would be to put
> a firewall box in front of the freebsd host.

Maybe you could describe a bit more what you are trying to do.

Re: Dhcp client configuration in 7.0

[Sebastian Benoit]

Arnoud Otten(arn...@beekberg.nl) on 2021.10.30 22:18:09 +0200:
> Hi,
> 
> Maybe i am wrong and do not understand this right, but wat should  the 
> ???ignore dns??? option do when used in the dhcpleased .conf config file?
> Here @xs4all our IPTV network on a separate vlan also gets an ip address and 
> the dhcp offer also sends a dns server which should be ignored. 
> I also thought that with the ???ignore dns??? option, this dns server was 
> blocked, but that is not what the option does? 
> 
> Regards,
> 
> Arnoud

The "ignore dns" config option causes dhcpleased to send a RTM_PROPOSAL
message to resolvd with an empty DNS proposal for that interface. This
causes resolvd to remove any nameserver entry for that interface from
/etc/resolv.conf.

Note that resolvd adds comments to the lines it touches in resolv.conf, for
example:
nameserver 192.168.1.1 # resolvd: iwm0

Anyone who thinks the "ignore dns" option does not work could help to debug
this with the following:

* run "route -n monitor"
* empty the dhcpleased.conf: mv /etc/dhcpleased.conf /etc/X.dhcpleased.conf
* cat /etc/resolv.conf, copy the output into an email.
* restart dhcpleased: doas /etc/rc.d/dhcpleased restart 
* copy the output of "route -n monitor" into the email
* cat /etc/resolv.conf, copy the output into the email.

then run dhcpleased with the configuration file:

* run "route -n monitor"
* mv /etc/X.dhcpleased.conf /etc/dhcpleased.conf
* cat /etc/dhcpleased.conf and copy the output into the email
* cat /etc/resolv.conf, copy the output into the email.
* restart dhcpleased: doas /etc/rc.d/dhcpleased restart
* copy the output of "route -n monitor" into the email
* cat /etc/resolv.conf, copy the output into the email.

send that email as a reply to this thread.

Thanks,
Benno

> > On 30 Oct 2021, at 21:00, Sebastian Benoit  wrote:
> > 
> > ???Z?? Loff(zel...@zeloff.org) on 2021.10.29 18:30:29 +0100:
> >>> On Fri, Oct 29, 2021 at 03:37:56PM +0300, Samarul Meu wrote:
> >>> Hello to you all!
> >>> 
> >>> Prior to 7.0 I was using this line in /etc/dhclient.conf
> >>> supersede domain-name-servers 127.0.0.1;
> >>> so that I do not get the DNS from the ISP provider.
> >>> 
> >>> I am using unbound to resolve my queries. With the new changes I can not
> >>> get the same functionality.
> >>> 
> >>> I tried to add this in /etc/dhcpleased.conf
> >>> interface urtwn0 ignore dns
> >>> where urtwn0 is my interface or disable resolvd.
> >>> 
> >>> If resolvd is on I get my ISP DNS server, if not when unbound starts
> >>> resolvd  adds the ISP DNS server to resolv.conf.
> >>> 
> >>> Can you please tell me what am I doing wrong and how can I have only
> >>> 127.0.0.1 on the resolv.conf file?
> >>> 
> >>> Thank you!
> >> 
> >> This works for me:
> >> 
> >> 
> >> /etc/hostname.em0:
> >> 
> >>inet autoconf
> >> 
> >> 
> >> /etc/resolv.conf:
> >> 
> >>nameserver 127.0.0.1
> >> 
> >> 
> >> /etc/dhcpleased.conf:
> >> 
> >>interface em0 {
> >>ignore dns
> >>}
> > 
> > 
> > If you never intend to use other nameservers on this system, you can also
> > deactivate resolvd:
> > 
> >  rcctl stop resolvd
> >  rcctl disable resolvd
> > 
> > and remove dhcpleased.conf again.
> > 
> > 
> 

-- 

Re: Dhcp client configuration in 7.0

[Sebastian Benoit]

Z?? Loff(zel...@zeloff.org) on 2021.10.29 18:30:29 +0100:
> On Fri, Oct 29, 2021 at 03:37:56PM +0300, Samarul Meu wrote:
> > Hello to you all!
> > 
> > Prior to 7.0 I was using this line in /etc/dhclient.conf
> > supersede domain-name-servers 127.0.0.1;
> > so that I do not get the DNS from the ISP provider.
> > 
> > I am using unbound to resolve my queries. With the new changes I can not
> > get the same functionality.
> > 
> > I tried to add this in /etc/dhcpleased.conf
> > interface urtwn0 ignore dns
> > where urtwn0 is my interface or disable resolvd.
> > 
> > If resolvd is on I get my ISP DNS server, if not when unbound starts
> > resolvd  adds the ISP DNS server to resolv.conf.
> > 
> > Can you please tell me what am I doing wrong and how can I have only
> > 127.0.0.1 on the resolv.conf file?
> > 
> > Thank you!
> 
> This works for me:
> 
> 
> /etc/hostname.em0:
> 
> inet autoconf
> 
> 
> /etc/resolv.conf:
> 
> nameserver 127.0.0.1
> 
> 
> /etc/dhcpleased.conf:
> 
> interface em0 {
> ignore dns
> }


If you never intend to use other nameservers on this system, you can also
deactivate resolvd:

  rcctl stop resolvd
  rcctl disable resolvd

and remove dhcpleased.conf again.
 

Re: httpd(8) - Internal Server error (500) on invalid request

[Sebastian Benoit]

Matthias Pressfreund(m...@fn.de) on 2021.10.23 17:16:18 +0200:
> On 2021-10-21 16:38, Sebastian Benoit wrote:
> > 
> > This diff makes httpd return "505 HTTP Version Not Supported"
> > for < 0.9 and > 1.9 http versions. Anything from 1.1 to 1.9 is
> > interpreted as 1.1. This is what nginx does too.
> 
> 
> I don't understand why an invalid HTTP version sent by the client
> should result in a server error while the problem actually is on
> the other side, isn't it? Wouldn't a "400 Bad Request" response
> instead of a "505 HTTP Version Not Supported" be more appropriate?

because 

 505 HTTP Version Not Supported

means

 The server does not support the HTTP protocol version used in the request.

I think its appropiate, nginx responds the same.

> Second, the latest version correctly detects "HTTP/4.0" (for
> example) as an unsupported version while "HTTP/123" wrongly is
> accepted as "HTTP/1.1".

i might add that indeed, thx.

> 
> The suggestion below changes both of the above.
> 
> Index: usr.sbin/httpd/server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.145
> diff -u -p -r1.145 server_http.c
> --- usr.sbin/httpd/server_http.c  22 Oct 2021 08:51:50 -  1.145
> +++ usr.sbin/httpd/server_http.c  23 Oct 2021 14:39:50 -
> @@ -206,8 +206,12 @@ http_version_num(char *version)
>   return (9);
>   if (strcmp(version, "HTTP/1.0") == 0)
>   return (10);
> + /* version strings other than 8 chars long are invalid */
> + if (strlen(version) != 8)
> + return (0);
>   /* any other version 1.x gets downgraded to 1.1 */
> - if (strncmp(version, "HTTP/1", 6) == 0)
> + if (strncmp(version, "HTTP/1.", 7) == 0 &&
> + version[7] >= '1' && version[7] <= '9')
>   return (11);
>  
>   return (0);
> @@ -350,13 +354,13 @@ server_read_http(struct bufferevent *bev
>* be changed independently by the filters later.
>* Allow HTTP version 0.9 to 1.1.
>* Downgrade http version > 1.1 <= 1.9 to version 1.1.
> -  * Return HTTP Version Not Supported for anything else.
> +  * Anything else is a client error (malformed version).
>*/
>  
>   version = http_version_num(http_version);
>  
>   if (version == 0) {
> - server_abort_http(clt, 505, "bad http version");
> + server_abort_http(clt, 400, "malformed");
>   goto abort;
>   } else if (version == 11) {
>   if ((desc->http_version =
> 
> 
> 
> > 
> > ok?
> > 
> > diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
> > index 6a74f3e45c5..52aaf3711c2 100644
> > --- usr.sbin/httpd/server_http.c
> > +++ usr.sbin/httpd/server_http.c
> > @@ -51,6 +51,7 @@ intserver_http_authenticate(struct 
> > server_config *,
> > struct client *);
> >  char   *server_expand_http(struct client *, const char *,
> > char *, size_t);
> > +int http_version_num(char *);
> >  
> >  static struct http_method   http_methods[] = HTTP_METHODS;
> >  static struct http_errorhttp_errors[] = HTTP_ERRORS;
> > @@ -198,6 +199,19 @@ done:
> > return (ret);
> >  }
> >  
> > +int http_version_num(char *version)
> > +{
> > +   if (strcmp(version, "HTTP/0.9") == 0)
> > +   return (9);
> > +   if (strcmp(version, "HTTP/1.0") == 0)
> > +   return (10);
> > +   /* any other version 1.x gets downgraded to 1.1 */
> > +   if (strncmp(version, "HTTP/1", 6) == 0)
> > +   return (11);
> > +
> > +   return (0);
> > +}
> > +
> >  void
> >  server_read_http(struct bufferevent *bev, void *arg)
> >  {
> > @@ -207,6 +221,7 @@ server_read_http(struct bufferevent *bev, void *arg)
> > char*line = NULL, *key, *value;
> > const char  *errstr;
> > size_t   size, linelen;
> > +   int  version;
> > struct kv   *hdr = NULL;
> >  
> > getmonotime(&clt->clt_tv_last);
> > @

Re: httpd(8) - Internal Server error (500) on invalid request

[Sebastian Benoit]

Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.10.21 17:19:02 +0200:
> > +   version = http_version_num(desc->http_version);
> 
> I woud prefer if this code would store the version not in
> desc->http_version until after the strdup(). The way these strdup work is
> just wonky. Especil in the failure cases this may result in calling free
> on the wrong thing.

Yes, this was actually the reason for the convoluted if (version.. ) bits,
because server_abort_http() calls into server_close() to free desc->http_version
and that is a crash when not pointing to the strduped string.

Fixed.
 
> > +   if (version == 11) {
> > +   if ((desc->http_version =
> > +   strdup("HTTP/1.1")) == NULL)
> > +   goto fail;
> > +   } else {
> > +   if ((desc->http_version =
> > +   strdup(desc->http_version)) == NULL)
> > +   goto fail;
> > +   }
> > +
> > +   if (version == 0) {
> > +   server_abort_http(clt, 505, "bad http version");
> > +   goto abort;
> > +   }
> 
> I would prefer to have this as:
>   if (version == 0) {
>   } else if if (version == 11) {
>   } else {
>   }

Fixed.

ok?

diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
index 6a74f3e45c5..e65a667c556 100644
--- usr.sbin/httpd/server_http.c
+++ usr.sbin/httpd/server_http.c
@@ -51,6 +51,7 @@ intserver_http_authenticate(struct server_config 
*,
struct client *);
 char   *server_expand_http(struct client *, const char *,
char *, size_t);
+int http_version_num(char *);
 
 static struct http_method   http_methods[] = HTTP_METHODS;
 static struct http_errorhttp_errors[] = HTTP_ERRORS;
@@ -111,7 +112,7 @@ server_httpdesc_free(struct http_descriptor *desc)
desc->http_query = NULL;
free(desc->http_query_alias);
desc->http_query_alias = NULL;
-   free(desc->http_version);
+   free(desc->http_version); //XX
desc->http_version = NULL;
free(desc->http_host);
desc->http_host = NULL;
@@ -198,6 +199,20 @@ done:
return (ret);
 }
 
+int
+http_version_num(char *version)
+{
+   if (strcmp(version, "HTTP/0.9") == 0)
+   return (9);
+   if (strcmp(version, "HTTP/1.0") == 0)
+   return (10);
+   /* any other version 1.x gets downgraded to 1.1 */
+   if (strncmp(version, "HTTP/1", 6) == 0)
+   return (11);
+
+   return (0);
+}
+
 void
 server_read_http(struct bufferevent *bev, void *arg)
 {
@@ -206,7 +221,9 @@ server_read_http(struct bufferevent *bev, void *arg)
struct evbuffer *src = EVBUFFER_INPUT(bev);
char*line = NULL, *key, *value;
const char  *errstr;
+   char*http_version;
size_t   size, linelen;
+   int  version;
struct kv   *hdr = NULL;
 
getmonotime(&clt->clt_tv_last);
@@ -317,24 +334,39 @@ server_read_http(struct bufferevent *bev, void *arg)
if (desc->http_path == NULL)
goto fail;
 
-   desc->http_version = strchr(desc->http_path, ' ');
-   if (desc->http_version == NULL) {
+   http_version = strchr(desc->http_path, ' ');
+   if (http_version == NULL) {
server_abort_http(clt, 400, "malformed");
goto abort;
}
 
-   *desc->http_version++ = '\0';
+   *http_version++ = '\0';
desc->http_query = strchr(desc->http_path, '?');
if (desc->http_query != NULL)
*desc->http_query++ = '\0';
 
/*
-* Have to allocate the strings because they could
+* We have to allocate the strings because they could
 * be changed independently by the filters later.
+* Allow HTTP version 0.9 to 1.1.
+* Downgrade http version > 1.1 <= 1.9 to version 1.1.
+* Return HTTP Version Not Supported for anything else.
 */
-   if ((desc->http_version =
-   strdup(desc->http_version)) == NULL)
-   goto fail;
+
+   version = http_version_num(http_version);
+
+   if (version == 0) {
+ 

Re: httpd(8) - Internal Server error (500) on invalid request

[Sebastian Benoit]

J. K.(openbsd.l...@krottmayer.com) on 2021.10.21 14:10:16 +0200:
> Another question, to httpd(8). Tried the following query.
> Used an invalid HTTP Version number (typo).
> 
> $ telnet 10.42.42.183 80
> [Shortened]
> GET / HTTP/1.2
> [content]
> 
> httpd provide here the site. Without checking the not existent version
> (1.2) number and the Host. Okay, that's maybe stupid from me to
> start a request with an invalid version number. But should not also
> the server answer with 400 (bad request)?
> 
> According to the source only HTTP/1.1 is checked. All other request
> will be accepted. Okay, I'm not a RFC specialist. Still a newbie.

This diff makes httpd return "505 HTTP Version Not Supported"
for < 0.9 and > 1.9 http versions. Anything from 1.1 to 1.9 is
interpreted as 1.1. This is what nginx does too.

ok?

diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
index 6a74f3e45c5..52aaf3711c2 100644
--- usr.sbin/httpd/server_http.c
+++ usr.sbin/httpd/server_http.c
@@ -51,6 +51,7 @@ intserver_http_authenticate(struct server_config 
*,
struct client *);
 char   *server_expand_http(struct client *, const char *,
char *, size_t);
+int http_version_num(char *);
 
 static struct http_method   http_methods[] = HTTP_METHODS;
 static struct http_errorhttp_errors[] = HTTP_ERRORS;
@@ -198,6 +199,19 @@ done:
return (ret);
 }
 
+int http_version_num(char *version)
+{
+   if (strcmp(version, "HTTP/0.9") == 0)
+   return (9);
+   if (strcmp(version, "HTTP/1.0") == 0)
+   return (10);
+   /* any other version 1.x gets downgraded to 1.1 */
+   if (strncmp(version, "HTTP/1", 6) == 0)
+   return (11);
+
+   return (0);
+}
+
 void
 server_read_http(struct bufferevent *bev, void *arg)
 {
@@ -207,6 +221,7 @@ server_read_http(struct bufferevent *bev, void *arg)
char*line = NULL, *key, *value;
const char  *errstr;
size_t   size, linelen;
+   int  version;
struct kv   *hdr = NULL;
 
getmonotime(&clt->clt_tv_last);
@@ -329,12 +344,29 @@ server_read_http(struct bufferevent *bev, void *arg)
*desc->http_query++ = '\0';
 
/*
-* Have to allocate the strings because they could
+* We have to allocate the strings because they could
 * be changed independently by the filters later.
+* Allow HTTP version 0.9 to 1.1.
+* Downgrade http version > 1.1 <= 1.9 to version 1.1.
+* Return HTTP Version Not Supported for anything else.
 */
-   if ((desc->http_version =
-   strdup(desc->http_version)) == NULL)
-   goto fail;
+
+   version = http_version_num(desc->http_version);
+   if (version == 11) {
+   if ((desc->http_version =
+   strdup("HTTP/1.1")) == NULL)
+   goto fail;
+   } else {
+   if ((desc->http_version =
+   strdup(desc->http_version)) == NULL)
+   goto fail;
+   }
+
+   if (version == 0) {
+   server_abort_http(clt, 505, "bad http version");
+   goto abort;
+   }
+
 
if (desc->http_query != NULL &&
(desc->http_query =

Re: httpd(8) - Internal Server error (500) on invalid request

[Sebastian Benoit]

J. K.(openbsd.l...@krottmayer.com) on 2021.10.21 11:55:47 +0200:
> Hi,
> 
> I don't know if this is a real issue from OpenBSD's httpd(8).
> Tried some requests to httpd(8) for the purpose of education.
> 
> Simple tried the following request:
> 
> $ telnet 10.42.42.183 80
> Trying 10.42.42.183...
> Connected to 10.42.42.183.
> Escape character is '^]'.
> GET / HTTP/1.1
> fasfsdfsfd
> 
> Here without the colon httpd(8) return an internal server
> error.
> 
> Can somebody verify this behavior?
> 
> Noticed with OpenBSD 7.0. Is this a correct behavior (RFC
> conform)?
> 
> Thanks in advance!
> 
> Kind regrads,
> 
> J. K.

Hi,

yes. The server should probably answer with a "Bad Request" instead.

Fix below. ok?

diff --git usr.sbin/httpd/server_http.c usr.sbin/httpd/server_http.c
index 732add41283..fce3c21af72 100644
--- usr.sbin/httpd/server_http.c
+++ usr.sbin/httpd/server_http.c
@@ -268,8 +268,14 @@ server_read_http(struct bufferevent *bev, void *arg)
else if (*key == ' ' || *key == '\t')
/* Multiline headers wrap with a space or tab */
value = NULL;
-   else
+   else {
+   /* Not a multiline header, should have a : */
value = strchr(key, ':');
+   if (value == NULL) {
+   server_abort_http(clt, 400, "malformed");
+   goto abort;
+   }
+   }
if (value == NULL) {
if (clt->clt_line == 1) {
server_abort_http(clt, 400, "malformed");

Re: Base httpd authentication against RADIUS server?

[Sebastian Benoit]

Federico Giannici(giann...@neomedia.it) on 2021.10.20 08:09:54 +0200:
> From the man page It seems that httpd in base can authenticate only 
> against a standard passwd file. Is there no way (apart from modifying 
> source and recompiling) to authenticate with something else, like a 
> RADIUS server?

No. But modifying source is always an underappreciated option.

/B.

OpenBSD Errata: September 30, 2021 (libressl)

[Sebastian Benoit]

An errata patch for LibreSSL has been released for OpenBSD 6.8 and
OpenBSD 6.9.

Compensate for the expiry of the DST Root X3 certificate.  The use of an
unnecessary expired certificate in certificate chains can cause validation
errors.

Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility.  Source code patches can be found on the
respective errata page:

  https://www.openbsd.org/errata68.html
  https://www.openbsd.org/errata69.html

Re: Server certs expired higher up the chain, imaps and https

[Sebastian Benoit]

Chris Bennett(cpb_m...@bennettconstruction.us) on 2021.09.30 10:02:17 -0700:
> Hi,
> 
> I'm getting that the certs are expired, but https works fine in Firefox,
> including when looking at the full chain.
> 
> 
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect 
> mail.strengthcouragewisdom.rocks:imaps
> 
> openssl s_client -servername mail.strengthcouragewisdom.rocks -connect 
> mail.strengthcouragewisdom.rocks:https
> 
> However are not happy. I force updated my ssl certs, syspatch, pkg_add
> -u and rebooted.
> 
> I didn't rebuild dh.pem for dovecot.
> 
> Is this just a DNS propagation issue?
> Or should I do something further myself?

This is an issue with an expired root/intermediate certificate (DST Root X3)
in use by Let's Encrypt.

Stuart Henderson (sthen@) summarized it like this:

  LibreSSL in OpenBSD 6.9/earlier is having problems with the expiry of a
  CA certificate used to cross-sign Let's Encrypt certs.

  LE decided not to switch to using their own root fully, rather they
  are continuing to use the expired cross-signer to increase compatibility
  with old Android devices, which is tickling this problem.
  https://letsencrypt.org/2020/12/21/extending-android-compatibility.html

An errata has just been published, you can install it using syspatch.

Best,
Benno

Re: relayd, rsae_send_imsg: privenc poll timeout

[Sebastian Benoit]

Allan Streib(astr...@fastmail.fm) on 2021.09.28 17:40:58 -0400:
> On Thu, Sep 16, 2021, at 6:43 PM, Allan Streib wrote:
> > On Tue, Sep 14, 2021, at 5:09 PM, Allan Streib wrote:
> > > Seen a few of these in my logs (OpenBSD 6.9 release amd64)
> > > 
> > > Sep 14 02:12:05  relayd[78491]: rsae_send_imsg: privenc poll 
> > > timeout, keyop #946
> > > Sep 14 02:12:06  relayd[78491]: relay_dispatch_ca: privenc result 
> > > after timeout
> > > 
> > > The number after "keyop" varies.
> > 
> > Seeing a few more of these, the system is lightly loaded but it's a hosted 
> > KVM "slice"
> > so perhaps the host system is oversubscribed?
> 
> Just to close loop, hosting provider found that host machine was overheating.
> 
> Moved VM to another host machine and have not seen any repeat of this problem.

Thanks for the feedback!

Re: Experience using httpd in production on busy machines?

[Sebastian Benoit]

Crystal Kolipe(kolip...@exoticsilicon.com) on 2021.08.27 01:40:15 -0300:
> On Thu, Aug 26, 2021 at 11:46:15AM +0200, Stefan Sperling wrote:
> > On Thu, Aug 26, 2021 at 06:20:08AM -0300, Crystal Kolipe wrote:
> > > On Thu, Aug 26, 2021 at 02:47:40AM +, iio7 wrote:
> > > > Any caveats to look out for?
> > > 
> > > There is an issue with httpd and large file uploads, ( > ~ 600 Mb), which 
> > > was introduced sometime after OpenBSD 6.1.
> > > 
> > > We had a system handling such large file uploads via http, (which is 
> > > probably not a typical use case), and it worked fine whilst it was 
> > > running OpenBSD 6.1.  When OpenBSD 6.6 was released we did a fresh 
> > > installation and found that uploads over about 600 Mb would randomly 
> > > abort.  Since by this time the system had fallen into disuse anyway, as 
> > > far as I know nobody here bothered to investigate further, but testing 
> > > now on an OpenBSD 6.9 installation, I can see that the bug still exists.
> > > 
> > 
> > If your test on 6.9 involves a handoff to fcgi (e.g. nextcloud) then
> > please try again with a server running -current. There was a related
> > bug fixed in May after 6.9 was branched.
> 
> A quick test on -current with a very simple CGI handler invoked via
> slowcgi showed different behaviour.  It now results in a repeatable
> kernel panic after uploading about 1098-1119 Mb.  Smaller uploads work
> fine.
> 
> As we know that it worked at one point, albeit several years ago, I'll
> try to find the commit that broke it.  That might take a while, though.

Even if you cannot find the commit or time range, please send a crash report
with the panic (and -current dmesg) to bugs@.

Thanks,
Benno

Re: Remove outdated /etc/examples/unwind.conf?

[Sebastian Benoit]

David Higgs(hig...@gmail.com) on 2021.07.24 14:05:04 -0400:
> I wonder if there would be any benefit to a sysclean-like tool as part of a
> standard upgrade/sysmerge that automatically deletes everything older than
> the (supported) current and prior release?  It would remove the need to
> curate removal lists in upgrade.html.  Just an idle thought... pay me no
> mind.

At this time we believe it is enough to provide the list in upgrade.html.
If the removal of a file is needed because leaving it around can cause
problems (for example include files), it will be mentioned in current.html.

Sometimes less is more, for example more time for developers to do important
things.

Also note that any automatically generated list should be reviewed, you may
have valid reasons to keep a file around.

Re: Performance tuning PF.

[Sebastian Benoit]

Christopher Sean Hilton(ch...@vindaloo.com) on 2021.07.21 14:20:58 -0400:
> I have a packet filtering bridge running on PF and OpenBSD 6.8. My
> hardware is  a SuperMicro Atom D525 service with dual Intel Gigabit
> Nics. I've added a second dual Intel card in a PCIe slot.

I have used this hardware in the past (5-6 years ago). As far as i can
remember you cannot get it much faster. If i remember correctly, routing
was even less.
 
> When I run iPerf across this bridge, I max out at about 550Mbit/s. I'm
> running systat on the bridge. At peak load, I'm seeing 1500 ~ 1700
> interrupts per second for each interface in the bridge via systat.
> 
> I'm noticing similar limitations from another OpenBSD 6.8 firewall
> that I run. This is an Atom C2758 machine. And in this case, I'm
> getting about 650 ~ 700 Mbit/s from the slightly faster hardware.
> 
> My questions are:
> 
> * Where should I be looking for the bottleneck on this problem?

The IO paths of those Atoms are slow. Disk IO is also lacking.
 
> * Is it possible with tuning to forward packets over this hardware
>   at full gigabit speeds, ~950 Mbit/s?

Not as far as i can remember.

If you can get the later generation Xeon-D machines with similar form
factor. Much better hardware.

> Thanks for any help you can give,
> 
> -- Chris
> 
> -- 
> Chris
> 
>   __o  "All I was trying to do was get home from work."
> _`\<,_   -Rosa Parks
> ___(*)/_(*).___o..___..o...ooO..._
> Christopher Sean Hilton[chris/at/vindaloo/dot/com]
> 

-- 

Re: DHCP non-issues

[Sebastian Benoit]

Paul de Weerd(we...@weirdnet.nl) on 2021.07.19 20:04:35 +0200:
> On Mon, Jul 19, 2021 at 01:59:18PM +0200, Paul de Weerd wrote:
> | So far, I've found NFS and syslogd to need configuration changes or
> | /etc/hosts entries to ensure they start properly.
> 
> As I was asked about this off-list, I went back and re-read my
> message.  Apologies for not being more clear:

Thanks for the details. The details are important here. They can be worked
around by doing what dhclient did - wait. But they can also be fixed in the
programs that have the actual problem, i.e. in syslogd and the NFS setup.
Which is, i hope what we will do.

Re: carp backup and disconnecting ssh session

[Sebastian Benoit]

MJ J(mikedotjack...@gmail.com) on 2021.05.23 17:58:47 +0300:
> Hi,
> 
> I have a carp master and backup on a pair of one-armed Rapsberry Pi 4B
> devices (router1 and router2) and when I ssh to the backup using the
> carp IP as my gateway, it repeatedly throws me out after a few seconds
> with the message:
> 
> My laptop's network config:
> ---
> IP: 192.168.4.109
> Subnet mask: 255.255.255.0
> Gateway: 192.168.4.1
> 
> Both RPI4s are connected to switchports with packets tagged for VLANs
> 2,3,4,6 and the network devices don't have IP configuration -
> everything is configured on VLAN interfaces with the single parent
> interface bse0. CARP failover actually works as expected, but as
> mentioned I am unable to maintain an ssh session with the backup
> "router2" while using the carp IPs as my network gateway.
> 
> Network switch is a Zyxel GS1200-8 with firmware V2.00(ABME.0)C0. Loop
> prevention is enabled and I have also tested with it disabled to no
> avail.
> 
> What happens:
> ---
> $ ssh 10.0.1.101
> Last login: Sun May 23 17:44:21 2021 from 10.0.1.100
> OpenBSD 6.9 (GENERIC.MP) #1134: Sun Apr 18 01:53:35 MDT 2021
> router2#
> router2# client_loop: send disconnect: Broken pipe

you ssh from 192.168.4.109 to 10.0.1.101?

My best guess is that you have asymetric routing and your carp master
router1 only sees one direction of the traffic: 

laptop -> router1 -> router2
and
router2 -> laptop

because router2 has your laptop network locally on vlan6.

Solution: ssh to 192.168.4.3.

> 
> 
> Router 1 network config:
> ---
> router1# cat hostname.bse0
> up
> 
> router1# cat hostname.vlan2
> 172.16.1.6/24 172.16.1.255 parent bse0 vnetid 2 group PFSYNC
> description "private segment with router2"
> 
> router1# cat hostname.vlan3
> 10.0.1.100/24 10.0.1.255 parent bse0 vnetid 3 group INTERNAL
> description "router1 internal interface"
> 
> router1# cat hostname.vlan4
> 192.168.1.252/24 192.168.1.255 parent bse0 vnetid 4 group OLDSHIT
> description "unmigrated shit"
> 
> router1# cat hostname.vlan6
> 192.168.4.2/24 192.168.4.255 parent bse0 vnetid 6 group TCWIFI
> description "Time-Capsule Wifi"
> 
> router1# cat hostname.carp4
> 192.168.1.1/24 carpdev vlan4 pass fukdissh1t vhid 41 advskew 1
> description "TC-WIFI gateway"
> 
> router1# cat hostname.carp6
> 192.168.4.1/24 carpdev vlan6 pass fukdissh1t vhid 61 advskew 1
> description "TC-WIFI gateway"
> 
> 
> Router2 network config:
> ---
> router2# cat hostname.bse0
> up
> 
> router2# cat hostname.vlan2
> 172.16.1.7/24 172.16.1.255 parent bse0 vnetid 2 group PFSYNC
> description "private segment with router1"
> 
> router2# cat hostname.vlan3
> 10.0.1.101/24 10.0.1.255 parent bse0 vnetid 3 group INTERNAL
> description "router2 internal interface"
> 
> router2# cat hostname.vlan4
> 192.168.1.253/24 192.168.1.255 parent bse0 vnetid 4 group OLDSHIT
> description "unmigrated shit"
> 
> router2# cat hostname.vlan6
> 192.168.4.3/24 192.168.4.255 parent bse0 vnetid 6 group TCWIFI
> description "Time-Capsule Wifi"
> 
> router2# cat hostname.carp4
> 192.168.1.1/24 carpdev vlan4 pass fukdissh1t vhid 41 advskew 128
> description "TC-WIFI gateway"
> 
> router2# cat hostname.carp6
> 192.168.4.1/24 carpdev vlan6 pass fukdissh1t vhid 61 advskew 128
> description "TC-WIFI gateway"
> 
> 
> Any tips much appreciated.
> 
> -mike
> 

-- 

Re: sndiod on by default (does it need to be ? )

[Sebastian Benoit]

Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +:
> Hello,
> 
> I was wondering should sndiod (default) startup be determined based on
> whether or not
> it the install is a typical headless install (off) or  an install for
> a user machine with  running X
> 
> is there a reason why one would need to run this daemon by default?

Because users want to listen to audio.

> my thinking is by having the service off by default would reduce the
> default attack surface of the OS ?

How big is that attack surface? And especially compared to X?
 
> perhaps the installer could use the answer to the question do you
> intend to run X   to determine whether or not to enable the sndiod
> daemon ?

The difference is that a running sndiod is not noticable to you. Running X
is - you dont have a console anymore on your screen.

Whereas a not running sndiod is noticable - no sound.

Next to security, we try to make it easy for people to use OpenBSD. Not
asking questions when not needed is just that.

/Benno

Re: phonetics on OpenBSD: IPA transcription

[Sebastian Benoit]

Mihai Popescu(mih...@gmail.com) on 2021.01.08 23:00:44 +0200:
> > I mostly use macOS for that now [...]
> 
> I think it's better to stay on that system only, and avoid spamming misc
> with your cross-breeding experiments. Seriously now.

He asked a perfectly valid question. If you don't know the answer, don't
answer.

Re: Redistribution between ospfd and ripd

[Sebastian Benoit]

Hi,

Jason Tubnor(ja...@tubnor.net) on 2020.11.25 15:52:19 +1100:
> Hi,
> 
> We are planning for migration from ripd to ospf, however both protocols
> will need to work together as the migration rolls through.
> 
> I was looking at the 'redistribute rtlabel' option, even after digging into
> the code, it is unclear how this would work to bring other dynamic routes
> on the same host to be redistributed by a different routing protocol.

'redistribute rtlabel' can be used to redistribute routes (from the kernel
routing table aka fib) that have a label attached.

Thus, to have a routing daemon announce these routes they have to be in the
fib already. One way to create the routes in the fib is with the route(8)
command:

  route add -label FOOBAR 172.16.1.0/24 172.16.2.5
  route show -label FOOBAR

I am only aware of these mechanisms to set labels on routes added by  routing 
daemons:

bgpd (rtlabel  keyword in filter "set")
ospfd/ospf6d (rtlabel label external-tag number) 

Neither would help in your situation.

Can you explain a bit more what you are planing to do?

/Benno


> 
> A valid, but not very clean solution would be to add:
> 
> redistribute 10.0.0/8
> redistribute 172.16.0/12
> redistribute 192.168.0/16
> 
> To both ospfd.conf and ripd.conf
> 
> What am I missing here or is there a far more elegant way to achieve this?
> 
> Thanks,
> 
> Jason.
> 

-- 

Re: Relayd Help Needed

[Sebastian Benoit]

Lari Huttunen(open...@huttu.net) on 2020.11.07 15:01:04 +:
> On Sat, Nov 07, 2020 at 08:29:12AM +, Lari Huttunen wrote:
> > Cheers!
> 
> > In practice, what I'm struggling with is the: 
> > 
> >  * ability to control the requests or responses by HTTP method, i.e.
> >only allowing GET by default and access controlling POST and PUT
> 
> It turned out that filtering the requests per method was possible
> at least as follows:
> 
> match request method "GET" tag "REQ_OK"
> block request
> pass tagged "REQ_OK"
> 
> $ curl -i -X GET https://www.huttu.net
> HTTP/1.1 200 OK
> 
> $ curl -i -X POST https://www.huttu.net
> HTTP/1.0 403 Forbidden
> Date: Sat, 07 Nov 2020 14:53:20 GMT
> Server: OpenBSD relayd
> Connection: close
> Content-Type: text/html
> Content-Length: 427
> 
> The only downside is that for unknown request types I still get a
> 500 from relayd. For example:
> 
> $ curl -i -X WHATNOT https://www.huttu.net
> HTTP/1.0 500 Internal Server Error
> Date: Sat, 07 Nov 2020 14:55:32 GMT
> Server: OpenBSD relayd
> Connection: close
> Content-Type: text/html
> Content-Length: 442
> 
> Is that the intended behavior?

Yes,

see relay_read_http() in relay_http.c.

Unknown http methods reult in a 500 error.

> 
> >  * ability to control the behavior of relayd based on the response
> >code from the backend IPFS web server, e.g. upon a 404, redirecting to 
> >generic 404 page on the httpd.
> 
> So what remains missing is the ability to control the responses
> back to the client in a controlled manner.
> 
> Does anyone have a recipe for this, please?

You should be able to set a Location header on a response:

match response header set "Location" value "https://something"; tagged "FOO"


> Best regards,
> 
> Lari Huttunen
> -- 
> "See the unseen."
> 

-- 

Re: possible relayd.conf(5) documentation mistake regarding session tickets

[Sebastian Benoit]

Sebastian Benoit(benoit-li...@fb12.de) on 2020.10.21 21:26:00 +0200:
> Ashlen(euryd...@riseup.net) on 2020.10.20 16:02:49 -0600:
> > In relayd.conf(5), the tls section under PROTOCOLS states the following:
> > 
> > no session tickets
> >  Disable TLS session tickets.  relayd(8) supports stateless TLS
> >  session tickets (RFC 5077) to implement TLS session resumption.
> >  The default is to enable session tickets.
> > 
> > However, an SSL Labs test[1] without `tls { session tickets }` specified
> > shows no session tickets.
> 
> There are two things i believe happening:
> 
> * i'm not sure we wanted session resumption to be enabled by default because
> of the security implications regarding perferct forward secrecy. Indeed the
> option is off by default at the moment.

It's disabled by default on purpose.
Manpage is updated.

> 
> * With TLS 1.3, session resumption is called pre-shared key) resumption.
> I have to check what the issue here is, that is if qualys does not show this
> right or if relayd has to do something different.

Indeed, our TLS 1.3 does not yet support session resumption.:

> For now, with the following options you should see session resumption:
> 
> tls { session tickets, tlsv1.2, no tlsv1.3 }

Of course if you just do

  tls { session tickets }

clients that support 1.3 wont get it, but ones that do not support 1.3 will.

Best,
Benno

Re: possible relayd.conf(5) documentation mistake regarding session tickets

[Sebastian Benoit]

Ashlen(euryd...@riseup.net) on 2020.10.20 16:02:49 -0600:
> In relayd.conf(5), the tls section under PROTOCOLS states the following:
> 
> no session tickets
>  Disable TLS session tickets.  relayd(8) supports stateless TLS
>  session tickets (RFC 5077) to implement TLS session resumption.
>  The default is to enable session tickets.
> 
> However, an SSL Labs test[1] without `tls { session tickets }` specified
> shows no session tickets.

There are two things i believe happening:

* i'm not sure we wanted session resumption to be enabled by default because
of the security implications regarding perferct forward secrecy. Indeed the
option is off by default at the moment.

* With TLS 1.3, session resumption is called pre-shared key) resumption.
I have to check what the issue here is, that is if qualys does not show this
right or if relayd has to do something different.

For now, with the following options you should see session resumption:

tls { session tickets, tlsv1.2, no tlsv1.3 }


I will figure out what to do about the default, the documentation and TLS
1.3.

/Benno
> 
> $ uname -a
> OpenBSD lain.lan 6.8 GENERIC.MP#98 amd64
> 
> [1]: https://www.ssllabs.com/ssltest/
> 
> --
> https://amissing.link
> 

-- 

Re: OpenBSD 6.8 Relase Time

[Sebastian Benoit]

Valdrin Muja(valdrinm...@protonmail.com) on 2020.10.16 13:52:14 +:
> Hi Misc,
> 
> I'm looking forward to OpenBSD 6.8 release.
> 
> On OpenBSD 6.8 page, `Released Oct XXX` is writing..
> 
> https://www.openbsd.org/68.html
> 
> When will it be released?

today.

Re: bgpd path selection seems broken at now

[Sebastian Benoit]

Hi,

I think it would help if you could send your configuration file, or at least
the bgpctl commands that show the problem.
Also please send a dmesg so we know what version you are running.

Thanks,
Benno


Bars Bars(tutbara...@gmail.com) on 2020.10.12 15:10:11 +0300:
> To be more clear i mean this one commit on rde_rib.c, but again im not sure.
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde_rib.c?rev=1.189&content-type=text/x-cvsweb-markup
> 
> 
> , 12 ??. 2020 ??. ?? 13:52, Bars Bars :
> 
> > Hi,
> >
> > Firstly, i have to say, that its really hard to understand prefix
> > comparison procedure
> > calls for me, because of there are so much ways where
> > different comparisons done inside, like
> > prefix_cmp()/prefix_compare()/pt_prefix_cmp()/path_compare()/etc. So, I
> > guess, I may be totally wrong here in decisions...
> >
> > But anyway, it seems currently (at 6.6-stable and 6.7-stable, at least)
> > that
> > path selection is not performing at least for VPNv4 (not tried other AIDs
> > yet) if we have the same
> > prefixes with different RD while importing them to FIB. Normally, at this
> > stage there should be path selection accomplished (or ECMP multipath
> > used, if supported). But instead, both prefixes are present in rdomain's
> > rib,
> > and the only newest one is used as active even if others have better
> > attributes (route-age evaluation is not enabled by default).
> > I tried to research is that caused by different rd, or by some broken
> > comparison itself, but i guess that things get broken somewhere with
> > commit
> > evision 1.189 (tagged as "bgpd adj-rib-out rewrite") or so around,
> > because of since that we have static prefix_cmp() in rde_rib translation
> > unit,
> > and so functions like prefix_add()/prefix_move()/prefix_update() are
> > missing
> > prefix_cmp() defined in rde_decide translation unit, which is actually do
> > bgp path selection.
> >
> > The peer setup is
> > ebgp-peer advertises multiple VPNv4 prefixes with different RD to the
> > bgpd-peer, say,
> > rd1:x.x.x.x/y
> > rd2:x.x.x.x/y
> > rd3:x.x.x.x/y
> > where x.x.x.x/y are equal but have different as-path length, or changed
> > lpref in bgpd config
> > with set attributes filter. Prefix which advertised last becomes active
> > prefix for the FIB.
> >
> > Again, may be I dont understand something, but it does not work.
> >
> >
> 

-- 

Re: rtables and kernel routes

[Sebastian Benoit]

Claudio Jeker(cje...@diehard.n-r-g.com) on 2020.08.21 09:04:09 +0200:
> On Fri, Aug 21, 2020 at 08:45:36AM +0200, open...@kene.nu wrote:
> > Hello,
> > 
> > I am seeing rather strange, or maybe expected, behaviour. I utilise
> > rtables to send internal traffic towards the internet via a default
> > route in rtable 2. The traffic is punted to rtable 2 with pf. The
> > strangeness I am seeing is that unless there is a matching dummy route
> > in rtable 0 the traffic gets dropped on ingress hence the pf ruleset
> > that moves it into rtable 2 is never evalutated.
> > 
> > Is this expected? The man pages for rdomain seems to suggest so but it
> > is not explicitly stated.
> 
> I guess with internal traffic you mean traffic on the local LAN that is
> forwarded by the router. Not traffic local to the machine.
> 
> pf(4) runs twice in your box. Once on packet reception (in rules) and once
> before sending out a packet (out rules). In between these two checkpoints
> packet forwarding happens (if forwarding is enabled and traffic is
> not for the local system). During forwarding a route lookup is made and
> based on that lookup the packet is sent out on the right interface.
> If this lookup fails the packet can't be forwarded and is dropped. Now
> the pf hook for out rules happens after this point and so a valid route is
> required to get there.
> 
> In your case you either need a (default) route in rtable 0 so that traffic
> makes it to the out rule that then changes the rtable to 2 and sends out
> the packet towards the internet or you need to change the rtable on input
> (match in ... rtable 2) so that the forwarding lookup is done on rtable 2
> (where there is a valid route to the destination).
> 
> It seems most people prefer to write pf rulesets like yours with out rules
> and so a dummy default route in rtable 0 is needed but from a technical
> perspective it is better to do the rtable change on input. By doing so you
> actually save an extra route lookup (the one on rtable 0 hitting the dummy
> route).

Even if you use the "match in ... rtable 2" solution (which you should), you
may want to add a default route to rdomain 0, because this problem can
happen in other cases as well.

To make sure your route points packets to nowhere, but make pf work you can
do this (in one of your hostname.* files):

!/sbin/route add -inet 0.0.0.0/0 127.0.0.1 -blackhole

Re: Adding more syspatch platform.

[Sebastian Benoit]

Jordan Geoghegan(jor...@geoghegan.ca) on 2020.08.12 10:32:21 -0700:
> 
> 
> On 2020-08-12 02:08, Stuart Henderson wrote:
> >The only proxy we have for "what is really used" is dmesg submissions.
> >Since 6.7 release:
> >
> >amd6462
> >i386 5
> >arm643
> >macppc   2
> >octeon   1
> >
> >Based on this there isn't a great case for adding any more.
> >
> 
> I didn't realize you guys used dmesg@ as a popularity gauge, I thought 

s/popularity/usage/

> it was just for sending dmesgs for interesting/new hardware. I figured 
> with something like Edgerouters with their standardized hardware that 
> repeat dmesgs would just serve to irritate the devs. I personally 
> administer more OpenBSD 6.x machines than are on that list you sent. I 
> can start hammering dmesg@, but then I'm gonna skew your stats and 

In a way, you also skew the stats if you dont send dmesgs. And "you" means
everyone. Do it once every 6 months (for every release) i'd say.

> you're gonna think that your userbase consists of a bunch of autists 
> that unironically run macppc, sparc64 and octeon in production 
> everywhere. In the small Canadian town I live in, I've got a big chunk 
> of it running on OpenBSD. I've got a bunch of old 90's / 2000's i386 
> stuff too, so I can send dmesgs in for that too, the reason I didn't is 
> I figured the hardware was already 'been there, done that'.

If the dmesgs dont show that certain hardware is still used, the drivers for
it will get deleted eventually. Another reason to show what you use.

> As I mentioned earlier in the thread, I can afford to donate 2 octeon 
> machines to any devs that are interested (including shipping world wide; 
> any devs reading: please contact me if you're interested), and am also 
> happy to help out with octeon stuff in any way I can. Obviously you guys 
> aren't going to trust me to do anything syspatch related as I'm not a 
> dev, but I'd at least like it to be known that there are people who care 
> about the octeon port and who are willing make an effort for it.
> 
> Regards,
> 
> Jordan
> 

-- 

Re: dhclient on carp

[Sebastian Benoit]

Guy Godfroy(guy.godf...@gugod.fr) on 2020.07.22 14:59:53 +0200:
> Hello,
> 
> So I read in 6.7 release note that it's finally possible to use dhclient 
> on CARP interface. That's great news.
> 
> However, I'm not sure how to use it on a hostname.if file. I tried to 
> replace inet instruction directly with dhcp:
> 
> dhcp vhid 11 carpdev em1 pass  description "test"
> 
> 
> But that didn't do the trick: at boot time, none of my nodes carp were 
> in master state so dhclient didn't manage to get any lease.
> 
> So I have first to give a static IP to my carp in order to activate it, 
> and only then trigger dhcp:
> 
> inet [...] vhid 11 carpdev em1 pass  description "test"
> 
> dhcp
> 
> It doesn't feel right. Is there a better way to do this?

Maybe someone will correct me on this, but I don't think so.
carp(4) needs an ip address to come up, thats how the protocol works.

Just pick one, there are many (from rfc1918 private use of course).

Re: Issue with relayd and redirections

[Sebastian Benoit]

Gabri Tofano(ga...@tofanos.com) on 2020.07.07 15:38:17 -0400:
> When using redirections, no listening ports are open (I guess due to
> relayd using pf nat rules)

correct

> and I'm unable to reach both backend servers.

show the output of "relayctl sh sum".

Re: relayd multiple listen on same redirect

[Sebastian Benoit]

Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2020.07.03 10:31:18 +0300:
> Hi,
> 
> My setup in relayd is like this:
> 
> redirect radius {
>listen on $radius_addr udp port radius interface $ext_if
>pftag RELAYD_radius
>sticky-address
>forward to  mode least-states check icmp demote carp
> }
> 
> redirect radacct {
>listen on $radius_addr udp port radacct interface $ext_if
>pftag RELAYD_radius
>sticky-address
>forward to  mode least-states check icmp demote carp
> }
> 
> I want to combine it in one redirect but the redirect forwards it to the 
> first port defined in listen for both radius and radacct ports.
> 
> redirect radius {
>listen on $radius_addr udp port radius interface $ext_if
>listen on $radius_addr udp port radacct interface $ext_if
>pftag RELAYD_radius
>sticky-address
>forward to  mode least-states check icmp demote carp
> }
> 
> Is there another way to do this

No

> or do I have to stick with two redirects?

Yes.

/Benno

Re: pfsync and rule specific state timeouts

[Sebastian Benoit]

Paul B. Henson(hen...@acm.org) on 2020.06.07 15:23:16 -0700:
> On 6/5/2020 11:15 PM, obs...@loopw.com wrote:
> 
> >1)  ???egress??? can be used to reference the external nic in a rule,
> >instead of having a specific IP.  Egress is defined as the nic with
> >the default route. pass in quick log on egress inet proto tcp to
> >(egress) port 22
> 
> Ah, I think I seen that in the past but did not remember it offhand. 
> Thanks; although these boxes run OSPF and the default route changes 
> depend on the network state, so I'm not sure that this would work.

Depending on what you are doing, you can also use interface groups to refer
to interfaces, and if you put only one interface into a unique group, you
can thereby refer in pf to a single interface by its group.

That way different interfaces that server the same function on your two
systems can still be used with an identical ruleset.

> 
> >2)  Both of the firewall IP addresses can be in a rule if egress is
> >not suitable for your topology, something like this will sync over
> >cleanly with pfsync: pass in quick log on $ext_if inet proto tcp to {
> >$fw1_ext $fw2_ext } port 22
> 
> I thought about doing that, but I ended up just making a table with a 
> single IP address in it, each router having the appropriate IP address 
> in the table, and the rule referencing the table being exactly the same 
> on both. Everything is working properly now.

Or use groups again.
 
> I do still wonder if this requirement is documented anywhere? I've been 
> looking, and could not find it. It was very confusing trying to sort out 
> why my states were mysteriously disappearing, I ended up having to add 
> some extra debugging code in the kernel to figure out what was happening.

This is indeed not very well documented, if at all.
Maybe you can create a diff for the pfsync(4) manpage?

/Benno

Re: Could somebody please put unveil() in ftp(1)?

[Sebastian Benoit]

Luke Small(lukensm...@gmail.com) on 2020.05.29 08:30:05 -0500:
> You mention a lot of files that need to be read, but a program like pkg_add
> can make it the _pkgfetch (57) user which has no directory and I???m guessing
> not in interactive mode. At the very least, in noninteractive mode you
> could unveil(???/???, ???rx???); and change the specified output file 
> discover the
> name of the file that is to be downloaded and unveil it as ???cw??? !

Yes, indeed.
You could.

Re: DNS and rdomains

[Sebastian Benoit]

Hi,

James(ja...@jmp-e.com) on 2020.05.28 11:12:29 +0100:
> Thanks. Your solution works but is not ideal for my situation. The
> reason it's not ideal is that one of the rdomains gets its nameserver
> from DHCP and I don't think unbound can read this information.
> 
> For example, In the case of a captive portal or floating between APs I 
> would like DNS to work on different LANs where outbound DNS queries are
> blocked. 
> 
> I'm trying to build an isolated network environment in which all traffic
> is routed over an interface with a custom DNS server and no network leaks.
> 
> My solution so far is as follows:
>  ___  ___
> |   ||   |
> | rdomain0  ||  rdomain1 |
> |   pair0   ||pair1  |
> |tun0   ||wlan0  |
> |___||___|
> 
>   with pf tagging and NAT'ing tun0 traffic behind wlan0.
>   rdomain0 DNS queries should be routed to a fixed address and
>   rdomain1 DNS queries should be sent to the nameserver as per
>   /etc/resolv.conf generated from dhclient.
> 
> Linux's implementation of network namespaces allows for custom
> resolv.conf files per network namespace [1]. The problem I 
> currently face is that only 1 rdomain can perform DNS queries at a 
> time by modifying /etc/resolv.conf.

This should work in OpenBSD 6.7:

run unwind in rdomain 0 (this is optional, kind of, but a good idea to
see how it works):

  rcctl enable unwind
  rcctl start unwind

then set your resolver to 127.0.0.1:

  echo "supersede domain-name-servers 127.0.0.1;" > /etc/dhclient.conf
  dhclient 

That assumes that your rdomain 0 uses dhcp, if it does not, just set the
nameserver in /etc/resolv.conf to 127.0.0.1.

Now check that DNS works in rdomain 0.

If it does, run unwind in your rdomain1, same method as Tom described for
nsd:

  ln -s /etc/rc.d/unwind /etc/rc.d/unwind1
  rcctl enable unwind1
  rcctl set unwind1 rtable=1
  rcctl start unwind1

Now put the supersede option into the dhclient.conf for rdomain 1,
and run dhclient there.

Dns in rdomain 1 should work, and 

  route -T 1 exec unwindctl sta

should show that its using the dhcp supplied nameserver:

$ unwindctl sta
1. recursorvalidating,  50ms   3. stub resolving,  90ms
2. dhcpvalidating, 150ms   4. oDoT-dhcp dead,   N/A

--> see ...^^ here

> 
> Thanks,
> 
> 
> 
> [1] https://www.man7.org/linux/man-pages/man8/ip-netns.8.html
> 
> On Wed, May 27, 2020 at 11:35:11PM +0100, Tom Smyth wrote:
> >howdy,
> >
> >you can use symbolic links for /etc/rc.d/nsd   to /etc/rc.d/nsd1
> >and to/etc/rc.d/nsd2  to  /etc/rc.d/nsdn  where 1,2 n are your  r
> >domains for your
> >dns servers (authoritive) or you can use unbound instead of nsd
> >if it is just a forwarding  dns server
> >
> >then use  for a dns server for rdomain1
> >rcctl enable nsd1
> >rcctl set nsd1 rtable=1
> >
> >repeat the procedure for each domain configured
> >rcctl enable nsd2
> >rcctl set nsd2 rtable=2
> >
> >then go back to rdomain0
> >route -T0 exec ksh
> >and then run the following to start each of your daemons
> >
> >rcctl start nsd1
> >rcctl start nsd2
> >
> >and so on and so fourth...
> >
> >I used to have issues starting and stopping daemons if I was not in
> >the correct domain when running the rcctl command,
> >I saw a diff by  ajacoutot   a few months / (years ago that might have
> >fixed the rcctl starting domains from a shell in a different
> >Rdomain...
> >I just got into the habit...  of going to the correct rdomain of the
> >daemon or rdomain0 before running the rcctl command to start / stop or
> >restart the daemon
> >
> >Hope this helps,
> >
> >Tom Smyth
> >
> >
> >On Wed, 27 May 2020 at 23:24, James  wrote:
> >>
> >>Hi all,
> >>
> >>How can I allow different rdomains to use separate DNS nameservers?
> >>
> >>Thanks
> >>
> >
> >
> >-- 
> >Kindest regards,
> >Tom Smyth.
> >
> 

-- 

Re: FAQ/Multimedia: Burning CDs and DVDs

[Sebastian Benoit]

Stefan Wollny(stefan.wol...@web.de) on 2020.05.24 22:59:57 +0200:
> Hi there!
> 
> 
> I just noticed that the sections on burning CDs and DVDs are no longer
> present in OpenBSD's FAQ related to multimedia.
> 
> Is this intentional?

probably yes

> I didn't see anything on this on tech@ or misc@...

Not everything needs a long discussion...

The real question here is: What question do you have (that was answered by
that webpage)? And is it asked frequently?

/Benno

PS:
https://web.archive.org/web/20150716003030/http://www.openbsd.org/faq/faq13.html#burnCD

Re: Why isn't src included with OpenBSD? (documentation)

[Sebastian Benoit]

Andras Farkas(deepbluemist...@gmail.com) on 2020.05.18 13:07:36 -0400:
> Not sure whether to post this on misc@ or tech@, so trying misc@ first:
> 
> Why isn't src included on OpenBSD, perhaps as an install fileset?
> Lots of documentation is unavailable outside of the /usr/src tree.
[...]
> This is a situation I occasionally run into, where useful
> documentation isn't included with OpenBSD, nor is available on
> OpenBSD's website (FAQ, etc).  It's occasional, but it's frustrating
> every time.

There you are:

  https://ftp.openbsd.org/pub/OpenBSD/6.7/src.tar.gz

ready to be unpacked at a place of your convenience.

Re: pf table for all publicly routable ipv4 addresses

[Sebastian Benoit]

Marko Cupa??(marko.cu...@mimar.rs) on 2020.05.04 22:42:50 +0200:
> I thought I could do such table like this:
> 
> table  {0.0.0.0/0 \
>  !0.0.0.0/8 \
>  ...
>!224.0.0.0/3 }
> 
> ...but https://www.openbsd.org/faq/pf/tables.html#addr states that "One 
> limitation when specifying addresses is that 0.0.0.0/0 and 0/0 will not 
> work in tables".


 table  {1.0.0.0/8 \
   2.0.0.0/8 \
   3.0.0.0/8 \
   4.0.0.0/6 \
   8.0.0.0/5 \
   16.0.0.0/4 \
   32.0.0.0/3 \
   64.0.0.0/2 \
128.0.0.0/3 \
160.0.0.0/3 \
192.0.0.0/3 \
!192.168.0.0/24 \
...
 }

> 
> I know I can solve this by reordering rules, and using block instead of 
> pass, but I'd really like to have a table of all publicly routable ip 
> addresses in pf.
> 
> Regards,
> -- 
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
> 
> Marko Cupa??
> https://www.mimar.rs/
> 

-- 

Re: VLAN syntax in hostname.vlanxxx

[Sebastian Benoit]

Lars Bonnesen(lars.bonne...@gmail.com) on 2020.04.29 21:58:27 +0200:
> In earlier obsd versions I have been having success with this in
> hostname.vlan703
> inet 172.18.11.9 255.255.255.252 NONE vlandev em5 description VLAN703
> 
> On an obsd 6.6, I use the vmx device, but the syntax:
> inet 172.18.11.9 255.255.255.252 NONE vlandev vmx2 description VLAN703 does
> not work as expected. If I do a tcpdump, I can find the packages reaching
> vmx2, but they are never passed on to vlan703
> 
> How to to if I have configured a trunk on a switch, I want to configure say
> VLAN id 703 on a vmx device?

Between OpenBSD 6.1 and 6.2 the syntax for configuring VLAN interfaces was
changed.

You now have to use the 'vnetid' and 'parent' options, as well as 'up'.

see ifconfig(8) and https://www.openbsd.org/faq/upgrade62.html:

The vlan(4) and svlan(4) specific configuration options in ifconfig(8) and
hostname.if(5) have been deprecated in favour of the generic parent and
vnetid handling.

The vlan, vlandev, and -vlandev options are now deprecated in favour of
vnetid, -vnetid, parent, and -parent when using ifconfig(8) or in
hostname.if(5) configuration files. Use of the vlan option must be replaced
with vnetid. Because VLAN tag 0 is invalid according to the relevant VLAN
specifications, the vnetid option does not accept 0 as a valid network
identifier. To use VLAN tag 0 on the wire the vnetid can be unconfigured
with -vnetid. Use of vlandev and -vlandev must be replaced with parent and
-parent respectively.

Unlike vlan and vlandev, vnetid and parent do not implicitly bring the vlan
interface up. Similarly, the vlan option is no longer implied by the
interface's minor when it is not explicitly set.

ifconfig(8) no longer outputs a vlan specific status line, or separate
vnetid and parent lines. The vnetid and parent lines have been merged into a
single encap line containing the VLAN tag and parent information.

An example of the changes to a vlan(4) configuration file and the
ifconfig(8) output is below. Before the changes:

  # cat /etc/hostname.vlan7
  vlandev em0 # vlan 7 and up are implied
  lladdr random
  # ifconfig vlan7
  vlan7: flags=8843 mtu 1500
  lladdr 70:a7:3a:75:da:2d
  index 7 priority 0 llprio 3
  vlan: 7 parent interface: em0
  vnetid: 7
  parent: em0
  status: active 

After the changes:

  # cat /etc/hostname.vlan7
  vnetid 7 parent em0
  up
  lladdr random
  # ifconfig vlan7
  vlan7: flags=8843 mtu 1500
  lladdr 60:e8:d7:0d:10:6d
  index 7 priority 0 llprio 3
  encap: vnetid 7 parent: em0
  groups: vlan
  status: active 
 
> And while we are at it, what if the switch is an access port?
> 
> Regards, Lars.
> 

-- 

Re: Ospfd default route query

[Sebastian Benoit]

Richard Chivers(r.chiv...@zengenti.com) on 2020.04.27 19:26:08 +0100:
> Hi,
> 
> That makes a lot of sense thanks, and appears to have solved the problem,
> we had a route added through our loopback interface in production"
> "!/sbin/route add -reject default 127.0.0.1"
> 
> Is that the best/general practise in general?

Yes. -blackhole is even better because you wont respond with icmp if you
loose routes (for example when routes flap) or when someone sends you
traffic you cannot route for other reasons.

> 
> Cheers
> 
> Richard
> 
> On Mon, Apr 27, 2020 at 8:25 AM Claudio Jeker 
> wrote:
> 
> > On Sun, Apr 26, 2020 at 08:44:42PM +0100, Richard Chivers wrote:
> > > Not sure how I missed the clear information in the man page...
> > >
> > > "If set to default, a default route pointing to this router will be
> > > announced over OSPF"
> > >
> > > It seems I am just having an issue and it should work as I expected.
> > >
> > > I will do some more diagnosis in the morning...
> > >
> >
> > I think the man page is not optimal here. ospfd(8) and ospf6d(8) will only
> > redistribute networks that are in the FIB. So in case of redistribute
> > default the router needs to have a default route 0/0 or ::/0 in the
> > routing table. Also that route's priority needs to be less than 32
> > to be picked up.
> >
> > This is different from bgpd where the network statements and export
> > default-route statement work even if there is no matching route in the
> > FIB.
> >
> > > On Sun, 26 Apr 2020, 17:09 Richard Chivers, 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > Hope someone can help, I am having a strange issue and can't seem to
> > > > isolate the problem.
> > > >
> > > > We have "redistribute default" set globally on our bgp/ibgp speakers
> > > > in the ospfd.conf. The bsd boxes are all 6.6.
> > > >
> > > > These routers are connected via ibgp to some other routers and have
> > > > external bgp sessions taking at present a couple of basic network
> > > > announcements from their egbp peers. e.g. 2.2.2.0/24 ( we have faked
> > our
> > > > transit provider)
> > > >
> > > > Connected to these routers we have a pair of firewalls, which
> > previously
> > > > received a default route from the bgp/ibgp speakers.
> > > >
> > > > I am trying to understand exactly what the redistribute default in the
> > > > ospfd.conf does. I assume it is saying if i have a static default
> > route or
> > > > another default route from an upstream then tell other routers about
> > it? Or
> > > > is it saying tell others to use me as a default route. I can't seem to
> > find
> > > > anything specific in the docs to clarify this, and would like to
> > understand
> > > > it clearly if pos.
> > > >
> > > > In our case our previous configuration on 5.8 and this configuration
> > has a
> > > > static route on the bgp speakers of 0.0.0.0/24 -> 127.0.0.1.
> > > >
> > > > If I do a ospfctl sh rib or ospfctl sh data on the firewalls i just
> > don't
> > > > see any default route being provided by the bgp speakers.
> > > >
> > > > Hope this makes sense. I am sure I am missing something obvious...
> > > >
> > > > Effectively I want the bgp speakers to announce themselves as the
> > default
> > > > route for their neighbor firewalls over ospf.
> > > >
> > > > Thanks
> > > >
> >
> > --
> > :wq Claudio
> >
> 

-- 

Re: Full disk encryption including /boot, excluding bootloader?

[Sebastian Benoit]

no@s...@mgedv.net(nos...@mgedv.net) on 2020.02.13 13:31:43 +0100:
> > > On Linux you can do the following:
> > > { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive
> entirely encrypted] }
> ... which i would consider to be as insecure, as unencrypted root at all.

... which totaly depends on what you are trying to protect your laptop/data
from.

The lost/stolen laptop szenario is covered nicely by what OpenBSD offers.

Re: using first alias as masquerading ip on pf.conf

[Sebastian Benoit]

Paul de Weerd(we...@weirdnet.nl) on 2020.02.12 12:46:02 +0100:
> On Wed, Feb 12, 2020 at 12:09:12PM +0100, Federico Donati wrote:
> | Hi all,
> | 
> | I have a couple of firewalls with carp configured and I need them to
> | reach the Internet even when they are in BACKUP state.
> | I'm managing pf via Ansible/GIT, so I'd like to keep the
> | configuration of pf.conf standard and simple as much as possible.
> | 
> | Usually, I use the notation "nat-to ($interface)" to let pf use the
> | correct ip, but in this case I've BGP configured and the provider
> | forces me to use a complex configuration with an alias on the
> | external interface, like this:
> | 
> | # ifconfig vlan835
> | vlan835: flags=8943 mtu 1500
> | lladdr b0:26:28:1e:e6:6e
> | index 13 priority 0 llprio 3
> | encap: vnetid 835 parent trunk0 txprio packet rxprio outer
> | groups: vlan egress
> | media: Ethernet autoselect
> | status: active
> | inet 1.1.1.1 netmask 0xfff0 broadcast 1.1.1.255
> | inet 2.2.2.2 netmask 0xfff0 broadcast 2.2.2.255
> 
> Surely the provider doesn't force 1.1.1.1 to be the "primary" and
> 2.2.2.2 to the be alias?  How could they tell the difference?
> 
> | So, 1.1.1.1 is the "transit ip" for the BGP, the one we must use to
> | talk with the provider's router and that I can't use as masquerading
> | ip.
> | 
> | The ip 2.2.2.2 is the one that I should use to mask my traffic to
> | the Internet, and is different on each firewall.
> | 
> | Is there a way to tell pf to use the first alias of interface to
> | mask the traffic? Something like "nat-to (vlan835:1)"...
> 
> Could you make 1.1.1.1 the alias and 2.2.2.2 the primary address?
> Then your NAT rule could simply use (vlan835:0).
> 
> Alternatively, you could refer to a hostname that you then specify in
> /etc/hosts (with a different address on each host).

If you dont want to go that route, you could have a file with a local
definition:

$ cat /etc/pf/local
natip="2.2.2.2"

$ cat /etc/pf.conf
include "/etc/pf/local"
[...]
pass in on em0 to any nat-to $natip

Then you have pf.conf identical on both machines and /etc/pf/local per
machine (and possibly generated by ansible differently on each box).

> As far as I know, there's no way to refer to the 'first alias'.  What
> is the 'first alias' anyway?  The first one you configured?  Or the
> last one?  Since you're using the '(interface)' specification (with
> the parentheses), you're using dynamically changing addresses .. what
> does that mean in the context of 'first alias'?

I would stay away from the :0 syntax as much as possible. It does not do
what you think it does in IPv6, and in fact there were discussions lately to
remove it completly. Even tough the ifconfig manpage and command line syntax
suggests, there is no difference between primary address and aliases on an
interface, it's all the same to the kernel.

/Benno

> | I would like to keep things simple and avoid to use the include
> | directive, if possible.

I think its simpler than fiddeling with /etc/hosts ;)
 
> I tend to dislike the whole IP address "aliases" thing more and more
> recently... :)
> 
> Cheers,
> 
> Paul 'WEiRD' de Weerd
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 

-- 

Re: openbsd.org - certain https URLs downgraded to http in redirection

[Sebastian Benoit]

Aham Brahmasmi(aham.brahma...@gmx.com) on 2020.02.12 10:34:55 +0100:
> Namaste misc,
> 
> Overview:
> Certain https URLs on openbsd.org get downgraded to http in redirection.
> 
> Steps:
> When navigating to https://www.openbsd.org/cgi-bin/man.cgi [1] from a
> browser, one ends up on http://man.openbsd.org/cgi-bin/man.cgi.
> 
> Same with https://www.openbsd.org/cgi-bin/cvsweb [1], which ends up on
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/.
> 
> Probable Solution:
> Would we benefit from changing our httpd.conf to
> ...
> listen on * port https
> ...
> location "/cgi-bin/man.cgi*" {
> block return 301 "https://man...
> ...
> 
> ...
> 
> This is similar to the recommended httpd.conf for OpenBSD mirrors [2].
> 
> Dhanyavaad,
> ab
> [1] - These URLs are among the top search results for the search terms
> "openbsd man", "openbsd cvsweb" et al, as returned by a privacy-friendly
> non-evil web search engine.
> [2] - 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/www/httpd.conf?rev=1.5&content-type=text/x-cvsweb-markup

Thanks for noticing this.

These two services are run by volunteers, and it's up to them how to provide
the service.

If you want to keep it secret what manpage you are looking at or what src
file you are reading, OpenBSD comes with fine command line tools that dont
need network access after initial installation.

Best regards,
B.

Re: match two conditions in relayd(8)

[Sebastian Benoit]

Joel Carnat(j...@carnat.net) on 2020.01.27 18:21:43 +0100:
> Hi,
> 
> I'm setting up an HTTP(S) Reverse Proxy with relayd(8).
> 
> I have one listener with multiple FQDN allowed.
> But I also have a common path that must be treated separately.
> 
> As for now, I have:
> http protocol "https" {
>   match request header "Host" value "one.domain.local" forward to 
>   match request header "Host" value "two.domain.local" forward to 
>   match request path "/common/*"   forward to 
> }
> relay "domain.local" {
>   listen on egress port 443 tls
>   protocol "https"
>   forward toport 80 check tcp
>   forward toport 80 check tcp
>   forward to  port 80 check tcp
> }
> 
> With this configuration, both "/common/" are rendered by .
> But I want
>   "one.domain.local/*"   to be rendered by 
>   "one.domain.local/common/" to be rendered by 
>   "two.domain.local/*"   to be rendered by 
>   "two.domain.local/common/" to be rendered by 
> 
> Is there some way to achieve this?

Try using "quick" or possibly "tag" and "tagged".

/Benno

Re: pflog flooded with igmp queries

[Sebastian Benoit]

Sonic(sonicsm...@gmail.com) on 2020.01.01 12:33:30 -0500:
> The pflogs on my firewall and on a new system I'm installing (-current
> with pretty much a default pf.conf) are flooded with igmp query
> entries. Neither system has a log rule for such action.
> 
> Ex:
> ===
> rule 1/(match) pass in on em1: 192.168.1.20 > 224.0.0.1: igmp query [ttl 1]
> ===
> 
> pf.conf:
> ===
> #   $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
> #
> # See pf.conf(5) and /etc/examples/pf.conf
> 
> set skip on lo
> 
> block return# block stateless traffic
> pass# establish keep-state
> ===
> 
> Reason? Solution?

show the output of

  pfctl -si
  pfctl -sr
  dmesg

Re: thank you for 6.6 and bsd.rd

[Sebastian Benoit]

Roderick(hru...@gmail.com) on 2019.12.21 19:50:03 +:
> 
> On Thu, 19 Dec 2019, Theo de Raadt wrote:
> 
> > for 6.5 onwards, all you had to was type
> > 
> > sysmerge
> > sysupgrade
> 
> I read somewhere that something like this was coming for 6.6, but 
> I remember that I followed the instructions for upgrading from 6.5 
> to 6.6, and this was to be done manually, I had to delete acording 
> to the instructions some files.
> 
> Since upgrading twice a year is something like a must for OpenBSD,
> this new feature is more than welcome, although manual upgrading
> was never something difficult. Thanks.

You should still read the upgrade guide and indeed you will have to remove
some things yourself, in addition to telling you about config and command
option changes. For 65 -> 66 there were instructions to remove some old
(perl) manpages and old X drivers as well some include files.

Nothing really problematic, the worst thing that can happen is that you read
an outdated manpage or some 3rd party software will have problems because of
an outdated .h file.

Re: acme-client issue with domain w/ alternative name [Solved]

[Sebastian Benoit]

Daniel Winters(daniel.wint...@tydirium.org) on 2019.10.24 10:53:22 +0100:
> For the archives:
> 
> With the help of Florian and Ian we managed to find the error in the
> setup: One of the alternative names in acme-client.conf had no A record
> in DNS anymore (it was removed a few days prior).
> 
> acme-client will fail in such a case and return "status": "invalid" in
> the output of acme-client -vv.
> 
> After removing the entry from acme-client.conf everything works as
> expected (with the "EOF without close" warning which is unrelated).
> 
> Thanks to everybody who helped!

Thanks for figuring it out. I wont be searching for a bug then.

Re: WLAN disconnects after a while

[Sebastian Benoit]

Roderick(hru...@gmail.com) on 2019.09.23 19:45:06 +:
> 
> I still have this problem:
> 
> https://marc.info/?t=15148946743&r=1&w=2
> 
> Now tested with other AP (FritzBox).
> 
> I am the only one?

As stsp@ said, its hard to debug like this.

Today a fix was okayed for a problem that sounds like it might be yours:

https://marc.info/?l=openbsd-tech&m=156925557704956&w=2

If you run current, you could try that diff and see if it fixes your problem.
Or wait until it is commited and then update to a snapshot after that.

You could also send the output of

ifconfig  scan

when your internet is working, and again when it stops working.

Possibly that shows if you encounter the same problem as the one addressed
by that diff.

/B.

Re: relayd: "listen on egress" only listens to IPv4 and not IPv6

[Sebastian Benoit]

Hi,

did you manage to test the diff?

/Benno

Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 17:05:34 +0200:
> Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 16:44:37 +0200:
> > Muhammad Kaisar Arkhan(h...@yukiisbo.red) on 2019.08.29 14:55:03 +0200:
> > > Hi Tom,
> > > 
> > > > listen  on 2a03:6000:9106::50f7:f07a:d1cc port 443 tls
> > > 
> > > I've tried this before, it just results in this:
> > > 
> > > /etc/relayd.conf:33: cannot load certificates for relay https2:443
> > 
> > Your error says "for relay https2", but the relayd.conf file you quote does
> > not have a relay "https2".
> >  
> > Please show the output of "relayd -nvv" and *exactly* the /etc/relayd.conf
> > file at the time when you ran the command.
> 
> sorry, my mistake: the https2 there is fine, it comes from the second
> "listen ..." directive.
> 
> I think i found the issue: relays with multiple listen statements do not
> work with keypair currently.
> 
> Can you test this diff with a config that has a listen on the v4 adress and
> a listen on the v6 adress, not the "egress" method.
> 
> If it does not work, please show again your config and "relayd -nvv".
> 
> /Benno
> 
> diff --git usr.sbin/relayd/parse.y usr.sbin/relayd/parse.y
> index c6e2bcacdfb..8338d5c9e6d 100644
> --- usr.sbin/relayd/parse.y
> +++ usr.sbin/relayd/parse.y
> @@ -3323,11 +3312,19 @@ relay_inherit(struct relay *ra, struct relay *rb)
>   goto err;
>   }
>  
> - if (relay_load_certfiles(conf, rb, NULL) == -1) {
> + if (TAILQ_EMPTY(&rb->rl_proto->tlscerts) &&
> + relay_load_certfiles(conf, rb, NULL) == -1) {
>   yyerror("cannot load certificates for relay %s",
>   rb->rl_conf.name);
>   goto err;
>   }
> + TAILQ_FOREACH(name, &rlay->rl_proto->tlscerts, entry) {
> + if (relay_load_certfiles(conf, rb, name->name) == -1) {
> + yyerror("cannot load keypair %s for relay %s",
> + name->name, rb->rl_conf.name);
> + goto err;
> + }
> + }
>  
>   TAILQ_FOREACH(rta, &ra->rl_tables, rlt_entry) {
>   if ((rtb = calloc(1, sizeof(*rtb))) == NULL) {
> 

-- 

Re: Iked and PKCS7

[Sebastian Benoit]

Tristan Pilat(cont...@tristanpilat.com) on 2019.09.09 10:02:32 +0200:
> Hello all,
> 
> It's the first time I'm trying to set up a site-to-site IKEv2 VPN with a
> non OpenBSD device at the other side. I've been asked to provide a CSR,
> then they sent me a PKCS7 certificate in return.
> 
> Is there any way to install this kind of certificate with iked? If so, how
> do I proceed?
> 
> Thank you for your help.

PKCS7 is just another format (actually one that can contain multiple certs
in one container).

Something like 

  openssl pkcs7 -print_certs -in file.p7b -out file.pem

can be used to convert it.

/B

Re: KARL sometimes renderring computer unbootable

[Sebastian Benoit]

cho...@jtan.com(cho...@jtan.com) on 2019.09.07 06:49:34 +0100:
> Occasionally after a power loss some computers, especially virtual
> machines for obvious reasons, are no longer able to boot. The bootloader
> reads the kernel, one of the two spins for a bit and then the computer
> returns to the bootloader prompt. In the case of VMs, vmd eventually gives
> up and turns it off. After getting into an affected OS, /bsd doesn't match
> the sha in /var.
> 
> The repair is easy thanks to the simple design - load bsd.booted into
> single user mode and replace /bsd (and the sha in /var) with it then boot
> as normal, taking care to let KARL finish this time. Obviously "don't keep
> losing power" is another solution, as is "get rid of the cats who keep
> knocking over the router", but neither is really workable and only hide
> the error anyway.
> 
> The problem stems from here I think:
> 
> newinstall:
> umask 077 && cp bsd /nbsd && mv /nbsd /bsd && \
> sha256 -h /var/db/kernel.SHA256 /bsd
> 
> I guess, and it is only a guess, that what's happening is that the
> filesystem doesn't finish writing /nbsd's data even after it's been moved
> to /bsd, so on my computers here I've put 'sync' between the cp and the mv
> to see if it resolves it (it will go away of course when 6.6 is installed)
> and I'll try to find the time to reproduce the problem reliably and
> hopefully produce a fix that's not essentially shotgun-debugging.
> 
> In the meantime does that sound like a likely source of the problem, and
> if so is there a better way to fix it?

You dont say, but you are probably using 6.5?

In current and thus in 6.6 the relevant line reads

newinstall:
install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd

which flushes the data to disk when writing /bsd.

Upgrade to a snapshot or wait for 6.6.

Re: handling snapshot installation in production environment

[Sebastian Benoit]

Stuart Henderson(s...@spacehopper.org) on 2019.09.02 17:58:55 -:
> On 2019-09-02, Marcus MERIGHI  wrote:
> > Hello Joerg, 
> >
> > just passing on my user experience...:
> >
> > streckf...@dfn-cert.de (Joerg Streckfuss), 2019.09.02 (Mon) 10:15 (CEST):
> >> Furthermore I'm not sure which snapshot should I run. Almost every day
> >> there will be a fresh one. 
> >
> > you seem to be watching closely, therefore you will notice a time when
> > there are no new daily snapshots for a couple of days. this is usually
> > when the next release is tagged/built. additionally you can monitor
> > ports@ to see when the ports tree gets locked for the next release. 
> 
> Ports lock is no indication of the state of base. The locks are independent.
> 
> >> Perhaps is there a moment/date where a
> >> freeze of the code base will be done which reflects the 6.6 release?

While a bit dated, this presentation explains what we do:

https://www.openbsd.org/papers/asiabsdcon2009-release_engineering/
 
> Use sysupgrade -n and monitor the OS version number ("what
> /home/_sysupgrade/bsd"). If you see 6.6-current it is post-release and
> you should not install it ("rm /bsd.upgrade"), you can then wait until
> actual release day and update to be sure you're running on the proper
> release binaries.

Re: relayd: "listen on egress" only listens to IPv4 and not IPv6

[Sebastian Benoit]

Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 16:44:37 +0200:
> Muhammad Kaisar Arkhan(h...@yukiisbo.red) on 2019.08.29 14:55:03 +0200:
> > Hi Tom,
> > 
> > > listen  on 2a03:6000:9106::50f7:f07a:d1cc port 443 tls
> > 
> > I've tried this before, it just results in this:
> > 
> > /etc/relayd.conf:33: cannot load certificates for relay https2:443
> 
> Your error says "for relay https2", but the relayd.conf file you quote does
> not have a relay "https2".
>  
> Please show the output of "relayd -nvv" and *exactly* the /etc/relayd.conf
> file at the time when you ran the command.

sorry, my mistake: the https2 there is fine, it comes from the second
"listen ..." directive.

I think i found the issue: relays with multiple listen statements do not
work with keypair currently.

Can you test this diff with a config that has a listen on the v4 adress and
a listen on the v6 adress, not the "egress" method.

If it does not work, please show again your config and "relayd -nvv".

/Benno

diff --git usr.sbin/relayd/parse.y usr.sbin/relayd/parse.y
index c6e2bcacdfb..8338d5c9e6d 100644
--- usr.sbin/relayd/parse.y
+++ usr.sbin/relayd/parse.y
@@ -3323,11 +3312,19 @@ relay_inherit(struct relay *ra, struct relay *rb)
goto err;
}
 
-   if (relay_load_certfiles(conf, rb, NULL) == -1) {
+   if (TAILQ_EMPTY(&rb->rl_proto->tlscerts) &&
+   relay_load_certfiles(conf, rb, NULL) == -1) {
yyerror("cannot load certificates for relay %s",
rb->rl_conf.name);
goto err;
}
+   TAILQ_FOREACH(name, &rlay->rl_proto->tlscerts, entry) {
+   if (relay_load_certfiles(conf, rb, name->name) == -1) {
+   yyerror("cannot load keypair %s for relay %s",
+   name->name, rb->rl_conf.name);
+   goto err;
+   }
+   }
 
TAILQ_FOREACH(rta, &ra->rl_tables, rlt_entry) {
if ((rtb = calloc(1, sizeof(*rtb))) == NULL) {

Re: relayd: "listen on egress" only listens to IPv4 and not IPv6

[Sebastian Benoit]

Muhammad Kaisar Arkhan(h...@yukiisbo.red) on 2019.08.29 14:55:03 +0200:
> Hi Tom,
> 
> > listen  on 2a03:6000:9106::50f7:f07a:d1cc port 443 tls
> 
> I've tried this before, it just results in this:
> 
> /etc/relayd.conf:33: cannot load certificates for relay https2:443

Your error says "for relay https2", but the relayd.conf file you quote does
not have a relay "https2".
 
Please show the output of "relayd -nvv" and *exactly* the /etc/relayd.conf
file at the time when you ran the command.

Also i don't think relayd has support for "listen on egress",
it should alsways display

   /etc/relayd.conf:##: invalid listen ip: egress

when you use

   listen on egress port https tls

in your config.

> I'm not sure why it does this despite the fact I have clearly 
> indicated which TLS certificates to use in relayd.conf with the
> new "tls keypair" feature.
> 
> % cat /etc/relayd.conf
> 
> log connection
> 
> table  { 127.0.0.1 }
> table  { 127.0.0.1 }
> table  { 127.0.0.1 }
> 
> http protocol "reverse_proxy" {
> return error
> 
> match header set "X-Forwarded-For" value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
> 
> match request header "Host" value "znc.yukiisbo.red" \
> forward to 
> 
> tls keypair "yukiisbo.red"
> tls keypair "arkhan.io"
> tls keypair "znc.yukiisbo.red"
> }
> 
> relay "https" {
> listen on vio0 port 443 tls
> listen on 2a03:6000:9106::50f7:f07a:d1cc port 443 tls
> 
> protocol "reverse_proxy"
> 
> forward to  port 80
> forward to  port 
> }
> 
> protocol "znc" {
> tls keypair "znc.yukiisbo.red"
> }
> 
> relay "irc" {
> listen on vio0 port 6697 tls
> listen on 2a03:6000:9106::50f7:f07a:d1cc port 6697 tls
> 
> protocol "znc"
> forward to  port 
> }
> 

-- 

Re: Re :dhcrelay

[Sebastian Benoit]

shadrock uhuru(niyal...@gmail.com) on 2019.08.25 17:14:48 +0100:
> > To:
> > shadrock uhuru 
> > CC:
> > misc@openbsd.org
> >
> >
> > shadrock uhuru(niyal...@gmail.com) on 2019.08.23 18:46:32 +0100:
> >> hi eveyone
> >> if i have a dhcp server in subnet A connected to interface em0 (lan) and
> >> subnet B connected to interface iwn0 (wireless zone) on the router
> >> with dhcrelay -i em0 running on the router should the wireless subnet be
> >> able?? to get its dhcp address from the dhcp server on the lan ?
> > No, you would need to run 
> >
> >    dhcrelay -i iwn0 
> >
> > to do that.
> >
> > Subject:
> > Re: dhcrelay
> > From:
> > Sebastian Benoit 
> > Date:
> > 8/23/19, 10:12 PM
> >
> thank Sebastian
> i have two samba?? active domain controllers with dhcp installed on each,
> is it possible to do this
> 
> dhcrelay -i iwn0  

Yes.

But why did you not just read the manpage and try it out?

Re: unexpected behavior with static route inserted

[Sebastian Benoit]

Benjamin Girard(benjamin.gir...@kambi.com) on 2019.08.22 12:35:08 +:
> Hi,
> 
> 
> I have the following machine with two interfaces like this:
> 
> root@fw:~ # cat /etc/hostname.vlan10
> vlan 10 vlandev vio0

shoudl be 'vnetid 10 parent vio0'

> inet 10.0.0.1 255.255.255.0 NONE
> up
> 
> root@fw:~ # cat /etc/hostname.vlan23
> vlan 23 vlandev vio0

should be 'vnetid 23 parent vio0'

> inet 172.30.133.83 255.255.255.240 NONE
> !route add 10.0.0.10/32 172.30.133.84
> up
> 
> now the problem is that if i start pinging 10.0.0.10 before my vlan23 is up 
> and has inserted the static route, the openbsd machine will insert another 
> route like this:
> 
> root@fw:~ $ route -n show | grep 10.0.0.10
> 10.0.0.10link#12UHLc   0   78 - 3 vlan10
> 
> then if I netstart vlan23 the static route will be inserted but with a lower 
> priority:
> 
> kmbops@fw:~ $ route -n show | grep 209.43.38.6
> 10.0.0.10link#12UHLc   0   78 - 3 vlan10
> 10.0.0.10172.30.133.84  UGHS   00 - 8 vlan23
> 
> Eventually this first route inserted will disappear if i stop pinging the
> ip, or will not at all exist in the first place if i don't try to reach
> that ip before inserting the static route, but my question is: Is it the
> expected behavior?

Yes.

> Why does this route get inserted while there is already a route for the
> full 10.0.0.0/24 subnet existing anyway?

Simplified, this is how the network stack stores the information that it is
trying to find the link-local address of 10.0.0.10 on that link (by sending
arp requests).

If you run OpenBSD 6.5 or newer, you can try to solve your problem by
renaming the vlan23 hostname.if file:

 mv /etc/hostname.vlan23 /etc/hostname.vlan1

Then it will be created before vlan10, and things should just work.

Re: dhcrelay

[Sebastian Benoit]

shadrock uhuru(niyal...@gmail.com) on 2019.08.23 18:46:32 +0100:
> hi eveyone
> if i have a dhcp server in subnet A connected to interface em0 (lan) and
> subnet B connected to interface iwn0 (wireless zone) on the router
> with dhcrelay -i em0 running on the router should the wireless subnet be
> able?? to get its dhcp address from the dhcp server on the lan ?

No, you would need to run 

   dhcrelay -i iwn0 

to do that.

Re: openrsync out of memory

[Sebastian Benoit]

Olivier Antoine(olivier.anto...@gmail.com) on 2019.08.19 11:34:06 +0200:
> Hi,
> On i386: before patch:
> $ dd if=/dev/urandom  of=in bs=1M count=2k
> $ openrsync --rsync-path=/usr/bin/openrsync  -av in localhost:out
> Transfer starting: 1 files
> sender.c:551: error: in: mmap: Cannot allocate memory
> client.c:85: error: rsync_sender
> receiver.c:345: error: poll: hangup
> server.c:145: error: rsync_receiver
> 
> With your patch:
> $ patch -p0 < /tmp/1
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |diff --git usr.bin/rsync/uploader.c usr.bin/rsync/uploader.c
> |index fd07b22caeb..cce8b47a4c9 100644
> |--- usr.bin/rsync/uploader.c
> |+++ usr.bin/rsync/uploader.c
> --
> Patching file usr.bin/rsync/uploader.c using Plan A...
> Hunk #1 succeeded at 158.
> Hunk #2 succeeded at 741.
> Hunk #3 succeeded at 910.
> Hmm...  Ignoring the trailing garbage.
> done
> 
> $ cd usr.bin/rsync/ && make -j3 && doas make install
> ???
> 
> $ openrsync --rsync-path=/usr/bin/openrsync  -av in localhost:out
> Transfer starting: 1 files
> sender.c:551: error: in: mmap: Cannot allocate memory
> client.c:85: error: rsync_sender
> receiver.c:345: error: poll: hangup
> server.c:145: error: rsync_receiver
> 
> From what I see, the mmap problem is on sender.c

Thanks,

i'll work on that one too.

/Benno

Re: openrsync out of memory

[Sebastian Benoit]

Joe Davis(m...@jo.ie) on 2019.08.16 12:26:36 +0100:
> By the looks of it, openrsync does attempt to map the entire file, from
> usr.bin/rsync/uploader.c:
> 
> mapsz = st.st_size;
> map = mmap(NULL, mapsz, PROT_READ, MAP_SHARED, *fileinfd, 0);
> 
> The likely reason for your out of memory error is the default datasize
> in login.conf. IIRC on some arches it's set to 768MB by default, which
> would allow your 300MB file to transfer, but would cause mmap to fail
> upon attempting to map the 1.6GB one.
> 
> Increasing the default limits in /etc/login.conf should fix the problem.
> 
> Note that rsync (not openrsync), doesn't use mmap for other reasons,
> from rsync-3.1.3/fileio.c:
> 
> /* This provides functionality somewhat similar to mmap() but using read().
>  * It gives sliding window access to a file.  mmap() is not used because of
>  * the possibility of another program (such as a mailer) truncating the
>  * file thus giving us a SIGBUS. */
> 
> Cheers,
> Joe

Hi,

this replaces the mmap() with pread(), please try it out.

I dont much like the error handling here, but its a start.

ok?


diff --git usr.bin/rsync/uploader.c usr.bin/rsync/uploader.c
index fd07b22caeb..cce8b47a4c9 100644
--- usr.bin/rsync/uploader.c
+++ usr.bin/rsync/uploader.c
@@ -158,8 +158,8 @@ init_blk(struct blk *p, const struct blkset *set, off_t 
offs,
p->len = idx < set->blksz - 1 ? set->len : set->rem;
p->offs = offs;
 
-   p->chksum_short = hash_fast(map + offs, p->len);
-   hash_slow(map + offs, p->len, p->chksum_long, sess);
+   p->chksum_short = hash_fast(map, p->len);
+   hash_slow(map, p->len, p->chksum_long, sess);
 }
 
 /*
@@ -741,8 +741,9 @@ rsync_uploader(struct upload *u, int *fileinfd,
 {
struct blkset   blk;
struct stat st;
-   void   *map, *bufp;
-   size_t  i, mapsz, pos, sz;
+   void   *mbuf, *bufp;
+   ssize_t msz;
+   size_t  i, pos, sz;
off_t   offs;
int c;
const struct flist *f;
@@ -909,35 +910,46 @@ rsync_uploader(struct upload *u, int *fileinfd,
blk.csum = u->csumlen;
 
if (*fileinfd != -1 && st.st_size > 0) {
-   mapsz = st.st_size;
-   map = mmap(NULL, mapsz, PROT_READ, MAP_SHARED, *fileinfd, 0);
-   if (map == MAP_FAILED) {
-   ERR("%s: mmap", u->fl[u->idx].path);
-   close(*fileinfd);
-   *fileinfd = -1;
-   return -1;
-   }
-
init_blkset(&blk, st.st_size);
assert(blk.blksz);
 
blk.blks = calloc(blk.blksz, sizeof(struct blk));
if (blk.blks == NULL) {
ERR("calloc");
-   munmap(map, mapsz);
+   close(*fileinfd);
+   *fileinfd = -1;
+   return -1;
+   }
+
+   if ((mbuf = calloc(1, blk.len)) == NULL) {
+   ERR("calloc");
close(*fileinfd);
*fileinfd = -1;
return -1;
}
 
offs = 0;
-   for (i = 0; i < blk.blksz; i++) {
-   init_blk(&blk.blks[i],
-   &blk, offs, i, map, sess);
+   i = 0;
+   do {
+   msz = pread(*fileinfd, mbuf, blk.len, offs);
+   if (msz < 0) {
+   ERR("pread");
+   close(*fileinfd);
+   *fileinfd = -1;
+   return -1;
+   }
+   if ((size_t)msz != blk.len && (size_t)msz != blk.rem) {
+   /* short read, try again */
+   continue;
+   }
+   init_blk(&blk.blks[i], &blk, offs, i, mbuf, sess);
offs += blk.len;
-   }
+   LOG3(
+   "i=%ld, offs=%lld, msz=%ld, blk.len=%lu, 
blk.rem=%lu",
+   i, offs, msz, blk.len, blk.rem);
+   i++;
+   } while (i < blk.blksz);
 
-   munmap(map, mapsz);
close(*fileinfd);
*fileinfd = -1;
LOG3("%s: mapped %jd B with %zu blocks",

Re: How do I publish default router preferences using rad?

[Sebastian Benoit]

Caleb(enlightened.des...@gmail.com) on 2019.08.06 08:05:48 -0700:
> How do I publish default router preferences as defined in RFC 4191
> (https://tools.ietf.org/html/rfc4191) using rad in OpenBSD 6.5?
> I've read the friendly rad.conf man page
> (https://man.openbsd.org/rad.conf.5) and scanned the source
> (https://github.com/openbsd/src/tree/master/usr.sbin/rad) with no
> success.

You can't, because it was not implemented.

That is, until now.

I wrote a patch, which you can test if you like. It's completly untested
though.


diff --git usr.sbin/rad/frontend.c usr.sbin/rad/frontend.c
index 8178b058629..75723797fcf 100644
--- usr.sbin/rad/frontend.c
+++ usr.sbin/rad/frontend.c
@@ -1016,6 +1016,8 @@ build_packet(struct ra_iface *ra_iface)
ra->nd_ra_flags_reserved |= ND_RA_FLAG_MANAGED;
if (ra_options_conf->o_flag)
ra->nd_ra_flags_reserved |= ND_RA_FLAG_OTHER;
+   ra->nd_ra_flags_reserved |=
+   ra_options_conf->preference;
if (ra_iface->removed)
/* tell clients that we are no longer a default router */
ra->nd_ra_router_lifetime = 0;
@@ -1048,6 +1050,8 @@ build_packet(struct ra_iface *ra_iface)
if (ra_prefix_conf->aflag)
ndopt_pi->nd_opt_pi_flags_reserved |=
ND_OPT_PI_FLAG_AUTO;
+   ndopt_pi->nd_opt_pi_flags_reserved |=
+   ra_prefix_conf->preference;
ndopt_pi->nd_opt_pi_valid_time = htonl(ra_prefix_conf->vltime);
ndopt_pi->nd_opt_pi_preferred_time =
htonl(ra_prefix_conf->pltime);
diff --git usr.sbin/rad/parse.y usr.sbin/rad/parse.y
index 004e5e22f92..b004ab37356 100644
--- usr.sbin/rad/parse.y
+++ usr.sbin/rad/parse.y
@@ -106,6 +106,7 @@ typedef struct {
union {
int64_t  number;
char*string;
+   shortpref;
} v;
int lineno;
 } YYSTYPE;
@@ -117,11 +118,13 @@ typedef struct {
 %token CONFIGURATION OTHER LIFETIME REACHABLE TIME RETRANS TIMER
 %token AUTO PREFIX VALID PREFERRED LIFETIME ONLINK AUTONOMOUS
 %token ADDRESS_CONFIGURATION DNS NAMESERVER SEARCH MTU
+%token PREFERENCE LOW MEDIUM HIGH
 
 %token   STRING
 %token   NUMBER
 %typeyesno
 %typestring
+%type  preftype
 
 %%
 
@@ -213,6 +216,9 @@ ra_opt_block: DEFAULT ROUTER yesno {
| MTU NUMBER {
ra_options->mtu = $2;
}
+   | PREFERENCE preftype {
+   ra_options->preference = $2;
+   }
| DNS dns_block
;
 
@@ -298,6 +304,19 @@ ra_prefixoptsl : VALID LIFETIME NUMBER {
| AUTONOMOUS ADDRESS_CONFIGURATION yesno {
ra_prefix_conf->aflag = $3;
}
+   | PREFERENCE preftype {
+   ra_prefix_conf->preference = $2;
+   }
+   ;
+preftype   : LOW {
+   $$ = RA_PREFIXOPT_PREF_LOW;
+   }
+   | MEDIUM {
+   $$ = RA_PREFIXOPT_PREF_MEDIUM;
+   }
+   | HIGH {
+   $$ = RA_PREFIXOPT_PREF_HIGH;
+   }
;
 dns_block  : '{' optnl dnsopts_l '}'
| '{' optnl '}'
@@ -425,17 +444,21 @@ lookup(char *s)
{"configuration",   CONFIGURATION},
{"default", DEFAULT},
{"dns", DNS},
+   {"high",HIGH},
{"hop", HOP},
{"include", INCLUDE},
{"interface",   RA_IFACE},
{"lifetime",LIFETIME},
{"limit",   LIMIT},
+   {"low", LOW},
{"managed", MANAGED},
+   {"medium",  MEDIUM},
{"mtu", MTU},
{"nameserver",  NAMESERVER},
{"no",  NO},
{"on-link", ONLINK},
{"other",   OTHER},
+   {"preference",  PREFERENCE},
{"preferred",   PREFERRED},
{"prefix",  PREFIX},
{"reachable",   REACHABLE},
diff --git usr.sbin/rad/printconf.c usr.sbin/rad/printconf.c
index d42890da518..e063daaa19f 100644
--- usr.sbin/rad/printconf.c
+++ usr.sbin/rad/printconf.c
@@ -34,6 +34,7 @@
 #include "rad.h"
 
 const char*yesno(int);
+const char*preference(short);
 void   print_ra_options(const char*, const struct ra_options_conf*);
 void   print_prefix_options(const char*, const struct ra_prefix_conf*);
 
@@ -43,6 +44,21 @@ yesno(int flag)
return flag ? "yes" : "no";
 }
 
+const c

Re: Sysmerge

[Sebastian Benoit]

Jay Hart(jh...@kevla.org) on 2019.07.06 08:57:49 -0400:
> > On Sat, Jul 06, 2019 at 11:56:32AM BST, Jay Hart wrote:
> >> Good Morning,
> >>
> >> What is the simple way to have sysmerge "keep" all custom changes to the 
> >> config files, during a
> >> system update from one stable release to the next? I seem to struggle with 
> >> this every release...
> >>
> >> Thanks for your time.
> >>
> >> Jay
> >>
> >
> > Hi Jay,
> >
> > $ man 8 sysmerge
> > [...]
> > FILES
> >  /etc/sysmerge.ignoreFiles and directories to ignore from 
> > comparison.
> > [...]
> >
> > Is this what you have in mind?
> >
> > Regards,
> >
> > Raf
> >
> >
> 
> I think its more like when diff asks to keep current config vs new config. I 
> want to keep my
> current config files (or at least those custom portions).

But your current config may be incompatible with the new code.

However, sysmerge offers you an option that gets you there halfway: the
sdiff(1) merge feature.

It it a bit awkward to use if you have the original and your own changes
mixed, so here is a trick to help you with the merge:

Put as many of your local changes at the bottom of the file, or at least in
one large chunk, and leave as much of the original file untouched.

For example with sshd_config, all options are commented out.
So put your local changes at the bottom of the file.
The next time sshd_config changes, your merge will be a lot easier.

/B

Re: Route through different gateways depending on process

[Sebastian Benoit]

slackwaree(slackwa...@protonmail.com) on 2019.06.26 13:11:19 +:
> Hello,
> 
> Well this is not so simple as it looks but I have made success with 
> traceroute.
> 
> route -T1 exec '/usr/sbin/traceroute' -n
> route -T2 exec '/usr/sbin/traceroute' -n
> route -T3 exec '/usr/sbin/traceroute' -n
> 
> Goes out on proper gateways so it works.
> 
> For Squid things gets a little bit more complicated.
> 
> For example I use squidguard which is spawned by squid so I don't know if the 
> alternative routing table applied to this as well.
> 
>  |-+= 03951 root /usr/local/sbin/squid
>  | \--- 06369 _squid (squid-1) --kid squid-1 (squid)
> 
> When I start squid I get:
> 
> 
>  route -T3 exec '/usr/local/sbin/squid'
> 2019/06/26 14:50:35| WARNING: (B) '127.0.0.1' is a subnetwork of (A) 
> '127.0.0.1'
> 2019/06/26 14:50:35| WARNING: because of this '127.0.0.1' is ignored to keep 
> splay tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.1' from the 
> ACL named 'localhost'
> 2019/06/26 14:50:35| WARNING: (B) '127.0.0.1' is a subnetwork of (A) 
> '127.0.0.1'
> 2019/06/26 14:50:35| WARNING: because of this '127.0.0.1' is ignored to keep 
> splay tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.1' from the 
> ACL named 'localhost'
> 2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
> 2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay 
> tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL 
> named 'localhost'
> 2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
> 2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay 
> tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL 
> named 'localhost'
> 2019/06/26 14:50:35| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) 
> '127.0.0.0/8'
> 2019/06/26 14:50:35| WARNING: because of this '127.0.0.0/8' is ignored to 
> keep splay tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.0/8' from 
> the ACL named 'to_localhost'
> 2019/06/26 14:50:35| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0'
> 2019/06/26 14:50:35| WARNING: because of this '0.0.0.0' is ignored to keep 
> splay tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '0.0.0.0' from the 
> ACL named 'to_localhost'
> 2019/06/26 14:50:35| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0'
> 2019/06/26 14:50:35| WARNING: because of this '0.0.0.0' is ignored to keep 
> splay tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '0.0.0.0' from the 
> ACL named 'to_localhost'
> 2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
> 2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay 
> tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL 
> named 'to_localhost'
> 2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
> 2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay 
> tree searching predictable
> 2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL 
> named 'to_localhost'
> 2019/06/26 14:50:35| ERROR: Directive 'url_rewrite_concurrency' is obsolete.
> 2019/06/26 14:50:35| WARNING: url_rewrite_concurrency upgrade overriding 
> url_rewrite_children settings.
> 
> I see that this might be an issue of the loopback not being present on that 
> table so I have added:
> 
> 
> route -T3 add -net 127.0.0.0/8 127.0.0.1
> route -T3 add -host localhost localhost

just run

   ifconfig lo3 inet 127.0.0.1/8 rdomain 3
   route -T3 add 127/8 127.0.0.1 

and you will get

 # route -T3 -n show 
 Routing tables

 Internet:
 DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
 127/8  127.0.0.1  UGS00 32768 8 lo3  
 127.0.0.1  127.0.0.1  UHhl   12 32768 1 lo3  

 Internet6:
 DestinationGatewayFlags Refs   
   Use   Mtu  Prio Iface
 ::1::1UHl   0  
  0 32768 1 lo3  
 fe80::1%lo3fe80::1%lo3UHl   0  
  0 32768 1 lo3  
 ff01::%lo3/32  fe80::1%lo3Um0  
  1 32768 4 lo3  
 ff02::%lo3/32  fe80::1%lo3Um0  
  1 32768 4 lo3  

 

> route -T3 show
> Routing tables
> 
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
> default192.168.10.252 UGS05 - 8 vio0
> 127/8  localhost  UGS01 32768 8 lo0
> localhost  lo

Re: relayd shows ssh sessions as idle

[Sebastian Benoit]

Joel Carnat(j...@carnat.net) on 2019.06.12 16:10:25 +0200:
> Hi,
> 
> I have configured relayd(8) on my vmd(8) host so that I can connect to
> the running VMs using SSH.
> 
> Using relayctl(8), I can see that those sessions have the same value for
> age and idle ; even when something happens in the SSH sessions.
> 
> Is this expected or an error in my relayd.conf ?
> 
> Thanks.
> 
> 
> # config snippet
> 
> protocol sshtcp {
>   tcp { nodelay, socket buffer 65536 }

this uses the implicit "splice" option.

If you add "no splice" to the tcp options, the idle time will be reset.

The reason is this: After connection setup, relayd "splices" the socket
connecting to the ssh client to the socket connecting to the ssh server.
After that, the kernel takes care of transfering data between the client
connection and the forward connection. relayd does not see the traffic
anymore.

It will only touch the connection again, when a maximum number of bytes are
transfered, or a timeout triggers.

For tcp connections, the max number of bytes is unlimited, and the timeout
is set toyour session timeout.

(For http connections, the max number of bytes is smaller, because relayd
wants to look at the headers of the next http request).

So relayd cannot know if the connection has been idle. It will only know
when it reaches "session timeout". If you dont like this, use "no splice".
However, that makes the connection slower and consume more cpu.

/Benno

> }
> relay ssh_vm1 {
>   listen on $public_ip port 8022
>   protocol sshtcp
>   transparent forward to $vm1 port 8022
>   session timeout 28800
> }
> #
> 
> 

-- 

Re: Criteria for errata

[Sebastian Benoit]

Jeremy O'Brien(neut...@fastmail.com) on 2019.05.10 10:30:42 -0400:
> On Fri, May 10, 2019, at 09:58, Jonathan Gray wrote:
> > On Fri, May 10, 2019 at 09:14:00AM -0400, Ted Unangst wrote:
> > > Jeremy O'Brien wrote:
> > > > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above 
> > > > fix, and installed it on my system which has made X rock-stable for me. 
> > > > This is totally fine for me personally, but I was curious if other 
> > > > people have run into this issue on their 6.5 installs, and if so, is 
> > > > this something worth pushing a reliability errata out for? I'm 
> > > > unfamiliar with how the process traditionally works so please excuse me 
> > > > if the question is outlandish.
> > > 
> > > security issues and major reliability issues. but we try not to spend all 
> > > our
> > > time making errata. that fix may be a contender. depends on how widely
> > > reported it is.
> > > 
> > 
> > vga arbiter is only used with multiple cards which isn't the common case
> >
> 
> That's how I understood the bug too, but when I enabled a debug build of 
> xenocara and examined the core dump after a crash, I had the same 
> "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug report.

I dont know much about xenocara, but i think that including dmesg and
maybe /var/log/Xorg.0.log output in your mail can't hurt.

Re: post-6.5-upgrade bgpd(8) problem

[Sebastian Benoit]

Hi,

Adam Thompson(athom...@athompso.net) on 2019.05.09 10:58:54 -0500:
> I've upgraded my looking glass from 6.4 to 6.5, and an experiencing an 
> unexpected problem - routes learned from one (iBGP) peer are not being 
> automatically exported to other (eBGP) peers.
> 
> I did not change /etc/bgpd.conf, but behaviour seems to have changed 
> nonetheless.  The upgrade from 6.4 to 6.5 appeared smooth otherwise, 
> nothing to suggest subtle breakage under the hood.
> 
> As you can see below, this bgpd.conf is almost so simple it *can't* have 
> problems.  Apparently "almost" being the operative word.
> 
> Under 6.4, this behaved as though "export none" only applied to the 
> first group.  Under 6.5, it behaves as though "export none" is a global 
> setting.
> 
> Under 6.5, bgpctl show produces:
> root@bgpmirror:~# bgpctl sh
> Neighbor   ASMsgRcvdMsgSent  OutQ 
> Up/Down  State/PrfRcvd
> Hermes IPv4 16796 128773 85 0 
> 00:41:40 753748
> Hermes IPv6 16796  29727 85 0 
> 00:41:40  68228
> MBNOG IPv4  65204 97 85 0 
> 00:41:40  0
> MBNOG IPv6  65204 97 85 0 
> 00:41:40  0
> BGPMon.io IPv4   6447  0 21 0 Never  
>   Active
> isolario.it IPv465517 86 85 0 
> 00:41:39  0
> isolario.it IPv665517 86 85 0 
> 00:41:39  0
> and the operator of the MBNOG route collector confirms that I stopped 
> sending him a full routing table at the same time I did the OS upgrade.
> 
> Any ideas?  What other information would help diagnose this problem?
> 
> Thanks,
> -Adam
> 
> 
> 
> Dmesg & bgpd.conf:  
> https://gist.github.com/athompso/e334d8621ce458925e25bb44b8068341
> 
> 
> bgpd.conf, duplicated here for convenience:
> 
>   ===BOF===
>   route-collector yes
>   socket "/var/www/run/bgpd.rsock" restricted # for bgplg
> 
>   # settings
>   nexthop qualify via default
>   fib-update no
>   dump table-v2 "/var/www/htdocs/bgplg/mrt/rib-dump.mrt" 3600
>   dump updates in "/var/www/htdocs/bgplg/mrt/updates-in-%H%M" 300
>   dump all in "/var/www/htdocs/bgplg/mrt/all-in-%H%M" 300
> 
>   # myself
>   AS X
>   router-id X.X.X.X
> 
>   # neighbors
> 
>   group hermes {
>   enforce local-as no
>   enforce neighbor-as no
>   export none
> 
>   neighbor X.X.X.X {
>   remote-as X
>   descr "Hermes IPv4"
>   }
>   neighbor X:X:X:X::X {
>   remote-as X
>   descr "Hermes IPv6"
>   }
>   }
> 
>   group bgpresearch {
>   multihop 32
>   enforce local-as no
>   enforce neighbor-as no
> 
>   neighbor 192.160.102.196 {
>   remote-as 65204
>   descr "MBNOG IPv4"
>   }
>   neighbor 2620:132:3003:300::196 {
>   remote-as 65204
>   descr "MBNOG IPv6"
>   }
>   neighbor 129.82.138.6 {
>   remote-as 6447
>   descr "BGPMon.io IPv4"
>   }
>   neighbor 146.48.78.12 {
>   remote-as 65517
>   descr "isolario.it IPv4"
>   }
>   neighbor 2a00:1620:c0:4e:146:48:78:12 {
>   remote-as 65517
>   descr "isolario.it IPv6"
>   }
>   }
> 
>   # policies
>   allow quick from group hermes
>   allow quick to group bgpresearch
>   ===EOF===

Please check

bgpctl sh rib neigh  out

for all neighbors.

Also look at 

bgpctl sh rib best

if any routes are actually selected - maybe the "nexthop qualify via
default" isnt working.

/Benno

Re: May 7 snap broken, ld.so: ld: can't load library 'libc++.so.2.2'

[Sebastian Benoit]

Greg Steuck(g...@nest.cx) on 2019.05.07 19:23:03 -0700:
> This is presumably already fixed by "Sync after libc++ bump", but in case
> somebody else hits it...
> 
> The amd64 snapshot with this signature:
> RWSZaRmt1LEQT+LPpgKcdukqjs3m1yYLE+J4zXB8YQ/iylbA3a/1IW31M6W9qKI+yIOxrbWghPno0HTSgbBfDyBZGwHWggiJBw4=
> 
> ... produces these errors upon reboot into the newly installed system:
> reordering libraries:ld.so: ld: can't load library 'libc++.so.2.2'
> Killed
> Abort trap
> install: ld.so.test: No such file or directory
>  failed.

already fixed, wait for the next snapshot.

> Thanks
> Greg
> 
> P.S.How useful would it be to automatically install amd64/i386 snapshots in
> a vmm before declaring them worthy of publishing?

Well, that offloads finding of problems from many pair of eyes to one. So
no, probably not going to happen. If you use snapshots things like this may
happen fromtime to time.

Re: Upgrading a CARP firewall cluster

[Sebastian Benoit]

mabi(m...@protonmail.ch) on 2019.04.30 08:21:43 +:
> Hello,
> 
> I have an OpenBSD 6.3 firewall cluster made out of two nodes (one master, one 
> backup) using CARP and pfsync. This cluster also makes use of trunk and vlan 
> interfaces.
> 
> Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was 
> wondering if it is possible to operate that cluster for a short amount of 
> time having one node running 6.3 and the other node with 6.4 and then the 
> same for going to 6.4 to 6.5.
> 
> Is this safe? or could there be any incompatibilities in carp/pfsync which 
> would prevent me to do that upgrade in two steps while keeping everything 
> online?
> 
> Cheers,
> Mabi

This is only a problem when we change the protocols involved, and that would
be mentioned in the upgrade guide.

Since there were no protocol changes to carp(4) or pfsync(4) between 6.3 and
6.5, you should not have a problem with this upgrade. In fact, you could go
63 -> 64 -> 65 on one firewall while the other stays on 63.

/Benno

Re: bgpd between two 6.4 boxes. IPv6 flapping, IPv4 rock solid

[Sebastian Benoit]

Stuart Henderson(s...@spacehopper.org) on 2019.04.03 16:22:26 -:
> On 2019-04-02, Rachel Roch  wrote:
> >
> >
> >
> > Mar 30, 2019, 11:10 AM by s...@spacehopper.org:
> >
> >> On 2019-03-29, Rachel Roch <> rr...@tutanota.de 
> >> > > wrote:
> >>
> >>> Hi,
> >>>
> >>> Has anyone encountered this before ?
> >>>
> >>> Neighbor?? AS?? MsgRcvd?? MsgSent?? OutQ 
> >>> Up/Down?? State/PrfRcvd
> >>> EXT-V6-R2 65515 50 
> >>> 40 0 00:02:55 Active
> >>> EXT-V4-R2 65515 38 
> >>> 37 0 00:27:42?? 1
> >>> After approx just over 2 minutes, the V6 flaps, bu the V4 remains rock 
> >>> solid.
> >>>
> >>> The boxes are sitting right next to each other, connected over an OpenBSD 
> >>> LACP trunk.
> >>>
> >>> I have made the pf rules as simple as possible:
> >>>
> >>> table  counters {self}
> >>> table  counters {192.0.2.1,2001:DB8::1}
> >>> pass in quick proto {tcp,udp,icmp} from  to 
> >>>  modulate state
> >>> pass out quick proto {tcp,udp,icmp} from  to 
> >>>  modulate state
> >>>
> >>
> >> A few tips:
> >>
> >> Start with an explicit "block any" rule so you don't have any traffic
> >> caught by the implicit "pass flags any no state" default. (If you want
> >> some "stateless" traffic as may often be the case on a BGP router, make
> >> it explicit in the ruleset). Otherwise you risk state being created 
> >> on something other than a SYN, so PF doesn't know the TCP window scaling
> >> value (which is *only* sent on SYN packets), which can result in the
> >> connection being killed after some traffic passes (state tracking gets
> >> out of sync).
> >>
> >> You don't have a rule for icmp6. IPv6's equivalent to ARP runs over icmp6
> >> and you do need a rule for that. It will currently be passed by the 
> >> implicit
> >> default rule but that will stop when you add "block any"..
> >>
> >> "modulate state" really isn't as simple as possible ;)
> >>
> >
> > A belated thanks for this !
> >
> > Re: icmp6:
> > pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol
> > pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv
> > pass quick inet6 proto ipv6-icmp all icmp6-type echoreq
> > pass quick inet6 proto ipv6-icmp all icmp6-type echorep
> >
> > Re: "modulate state" I thought that was meant to be a good option these 
> > days instead of one of the more traditional state techniques ?
> >
> >
> 
> "modulate state" can be useful for protecting machines with poor
> sequence number generation, but OpenBSD already has good randomness
> for this. At best (assuming no bugs in 'modulate state'), this
> adds complexity and burns cpu cycles for no benefit,

If it were better, it would be the default. It is useful, but can also cause
problems. Dont use it if you are not sure you need it _and_ know you will
get reports if there are problems.

My advise:

Regarding your config: As sthen said, start your policy with block any.

Then add rules to pass traffic for the networks you route. With "no state",
because if you have asymetric routing, stateful does not work.

Then add rules to pass traffic of the router itself, i.e. from/to ip
addresses on the router. Those can be stateful.

As for inet6, start with "pass inet6 proto icmp6 no state".
Then when everything is working, restrict it to what is actually needed.

Re: openbgpd; strip private ASNs from bgp updates

[Sebastian Benoit]

open...@kene.nu(open...@kene.nu) on 2019.03.29 08:36:26 +0100:
> I forgot to add to my previous email. One thing that could be useful
> in this case is to mimic the Cisco option "neighbor x.x.x.x
> remove-private-as" which removes any private ASes from the path on any
> updates to a peer.  Just throwing it out there, cant be a very
> difficult option to implement I guess?

If as-override does what you need, i'm not to keen on adding more knobs.

That said, i'm happy to look at your diff ;)

Re: flowd or similiar in base

[Sebastian Benoit]

Hi,

Heinz Kampmann(h.kampm...@web.de) on 2019.03.27 10:19:26 +0100:
> 
> Hello misc,
> 
> is there a chance that flowd or similar program
> will be included in base in the foreseeable future?

No.

A note on mailing list questions like this: I usually would not comment a
question like this - i dont know what anyone else is working on at any time
- but you write 'foreseeable', so if someone commits The Perfect Flow
Collector tomorrow, i would still be correct in saying No, because it was
past my foreseeable future. Better ask: whats a good flow collector with
features x and y.

Re: openbgpd; strip private ASNs from bgp updates

[Sebastian Benoit]

open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100:
> Hello,
> 
> That would unforunately affect all the prefixes announced to the edge
> router from the internal router. I need it to be only prefixes
> announced to my peering partners.
> 
> /Oscar
> 
> On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras  wrote:
> >
> > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote:
> > > Hello,
> > >
> > > Is there a way to make openbgpd strip private ASNs from updates it
> > > sends to certain neighbors?
> > > I am using openbgpd on my edge routers and distribute routes generated
> > > internally to the rest of the world. However, the internal routers use
> > > private ASNs and this is obviously frowned upon by my peering
> > > partners.
> > >
> > > I can of course have network statements on my edge routers but that
> > > assumes the prefixes will always be reachable via said edge router,
> > > something I can never be certain of. I would rather the updates rely
> > > on the prefix actually being announced from the source.
> > >
> >
> > Perhaps with transparent-as ?

In current (snapshots) there is "as-override":

 as-override (yes|no)
 If set to yes, all occurrences of the neighbor AS in the AS
 path will be replaced with the local AS before running the
 filters.  The Adj-RIB-In still holds the unmodified AS path. 
 The default value is no.

this is a neighbor option and used on the session to a peer that uses a
private AS.

You dont say much about your network structure, but if your edge router has
a normal As number, and your internal ebgp peers have private As numbers,
this option will help.

/Benno

Re: httpd acme-client renew multiple domains

[Sebastian Benoit]

Geir Svalland(thorshamm...@outlook.com) on 2019.03.23 15:39:13 +:
> Hello
> mtp$ uname -a
> OpenBSD smtp.thorshammare.org 6.4 GENERIC.MP#8 amd64
> 
> I'm hosting and serving multiple domains, 5 of them, using httpd.
> The domains are declared in /etc/acme-client.conf, and in my initial
> setup I used the command "acme-client -vAD example.com" on every domain 
> to create
> the certs. All of this is working great, but my question is regarding 
> updating.
> 
> I intend to use a cron job for this, "acme-client example.com && rcctl 
> reload httpd"
> but I'm not able to get this working for all of the domains in one 
> single command.
> 
> Is that possible to do ?
> Or do I have to use 5 differen lines with one domain name on each?

Currently acme-client does not do that.

Use mishas script.

Or modify acme-client to itterate over all domains in the config file.
If you do that, i suggest to only do it for the renew case.

Re: man httpd.conf option does not mention option blocks

[Sebastian Benoit]

Alfred Morgan(alf...@54.org) on 2019.03.12 01:24:40 -0500:
> httpd uses the configuration processor that relayd uses so I was curious to
> see how this block of sub options were explained in relayd.conf(5) and

Good idea.

But dont draw general conclusions from this please. The parsers are similar
because they were (in part) written by the same author. no wonder they share
syntactic feature.

Every time we write one of these parsers, its a mix of "how do we apply our
general syntax to this new domain?", "what do i re-use to make it easier for
people?", "how lazy am i?" and "%^$#@#$ yacc is crazy!!!".

/B.

> interestingly enough this is not explained there either but there are
> examples of the multiple option block being used. One thing I learned from
> relayd.conf examples was that the sub options can also be separated by a
> coma allowing multiple sub options to be written on one line inside the
> brackets. I confirmed this works the same in httpd.conf. This gives us
> these possibilities to write sub options:
> A)
> connection max requests 10
> connection timeout 600
> 
> B)
> connection {
> max requests 10
> timeout 600
> }
> 
> C)
> connection { max requests 10, timeout 60 }
> 
> While reading the man page for relayd.conf I found this easy to read and
> simple explanation that we may draw inspiration from -- although this still
> does not explain the sub option block:
> """
> It is possible to specify multiple listen directives with different IP
>  protocols in a single redirection configuration:
>redirect "dns" {
>listen on dns.example.com tcp port 53
>listen on dns.example.com udp port 53
> 
>forward to  port 53 check tcp
>}
> """
> I think we are struggling on how to be clear because option and sub-option
> are named the same and the need to distinguish between other
> "non-sub-options", if that makes any sense.
> We could go the relayd.conf(5) method and don't mention anything about
> sub-option blocks and just give examples such as A, B, and C above.
> 
> On Mon, Mar 11, 2019 at 5:21 PM Evan Silberman  wrote:
> 
> > Jason McIntyre  wrote:
> > > On Mon, Mar 11, 2019 at 12:29:41PM -0700, Evan Silberman wrote:
> > > > Jason McIntyre  wrote:
> > > > >
> > > > > Index: httpd.conf.5
> > > > > ===
> > > > > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> > > > > retrieving revision 1.103
> > > > > diff -u -r1.103 httpd.conf.5
> > > > > --- httpd.conf.5  19 Feb 2019 11:37:26 -  1.103
> > > > > +++ httpd.conf.5  11 Mar 2019 19:05:57 -
> > > > > @@ -155,7 +155,10 @@
> > > > >  .Xr patterns 7 .
> > > > >  .El
> > > > >  .Pp
> > > > > -Followed by a block of options that is enclosed in curly brackets:
> > > > > +It is followed by a block of directives and values, enclosed in
> > curly brackets.
> > > > > +Directives which take multiple
> > > > > +.Ar option
> > > > > +values may also group these options in curly brackets.
> > > >
> > > > This is better than mine but I don't think the "also" has a referent
> > here. Maybe:
> > > > "Directives which take multiple option values may be repeated or may
> > group the
> > > > options in curly brackets." This excludes the possible interpretation
> > that e.g.
> > > > 'log access "acces_log" error "error_log"' is valid syntax.
> > > >
> > >
> > > "also" because we just said that directives and values are enclosed in
> > > curly brackets. so "also" meaning "in the same way as we just showed
> > > you".
> >
> > You're right, reading the context more carefully this makes perfect sense.
> > >
> > > "repeated" is confusing i think (like you would specify the same option
> > > value twice).
> >
> > Fair enough. I have no further quibbles.
> >
> > Evan Silberman
> >
> -- 
> -alfred
> 

-- 

Re: pppoe(4) and vlan(4)

[Sebastian Benoit]

Thomas Huber(miracu...@gmail.com) on 2019.02.26 14:22:33 +0100:
> with chap the tcpdump looks like this:
> 
> #tcpdump -nevvs1500 -i vlan0
> tcpdump: listening on vlan0, link-type EN10MB
> 13:54:44.118903 00:0d:b9:43:43:b4 88:a2:5e:1e:52:88 8864 36: PPPoE-Session
> code Session, version 1, type 1, id 0x00a9, length 16
> LCP Configure-Request Id=0x24: Magic-Number=98519
> Max-Rx-Unit=1492
> 13:54:49.120414 00:0d:b9:43:43:b4 88:a2:5e:1e:52:88 8864 36: PPPoE-Session
> code Session, version 1, type 1, id 0x00a9, length 16
> LCP Configure-Request Id=0x25: Magic-Number=98519
> Max-Rx-Unit=1492
> 13:54:55.122239 00:0d:b9:43:43:b4 88:a2:5e:1e:52:88 8864 36: PPPoE-Session
> code Session, version 1, type 1, id 0x00a9, length 16
> LCP Configure-Request Id=0x26: Magic-Number=98519
> Max-Rx-Unit=1492
> 13:55:02.124396 00:0d:b9:43:43:b4 88:a2:5e:1e:52:88 8864 36: PPPoE-Session
> code Session, version 1, type 1, id 0x00a9, length 16
> LCP Configure-Request Id=0x27: Magic-Number=98519
> Max-Rx-Unit=1492
> 
> 
> but no connection esblished.
> 
> On Tue, 26 Feb 2019 at 13:02, Stuart Henderson  wrote:
> 
> > On 2019/02/26 12:36, Thomas Huber wrote:
> > > Hi Stuart,
> > >
> > > and thanks for your help.
> > > I tried yout suggestion but didn??t solve the problem.
> > > here is the tcpdump output (i just stripped the account credentials) but
> > I can not read it.
> > > Maybe you can spot something here:
> > >
> > > # tcpdump -nevvs1500 -i em0
> > > tcpdump: listening on em0, link-type EN10MB
> >
> > Reformatted a bit:
> >
> > OPENBSD -> JUNIPER: LCP Configure-Request Id=0xf6: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Request Id=0xab: Max-Rx-Unit=1492
> > Auth-Prot=PAP Magic-Number=526788746
> > JUNIPER -> OPENBSD: LCP Configure-Ack Id=0xf6: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > OPENBSD -> JUNIPER: LCP Configure-Ack Id=0xab: Max-Rx-Unit=1492
> > Auth-Prot=PAP Magic-Number=526788746
> > OPENBSD -> JUNIPER: PAP Authenticate-Request Id=0xf7: Peer-Id=
> > Passwd=
> > OPENBSD -> JUNIPER: PAP Authenticate-Request Id=0xf8: Peer-Id=
> > Passwd=
> > JUNIPER -> OPENBSD: LCP Configure-Request Id=0x02: Max-Rx-Unit=1492
> > Auth-Prot=CHAP/MD5 Magic-Number=3828540274
> > OPENBSD -> JUNIPER: LCP Configure-Nak Id=0x02: Auth-Prot=PAP
> > OPENBSD -> JUNIPER: LCP Configure-Request Id=0xf9: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Ack Id=0xf9: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > OPENBSD -> JUNIPER: LCP Configure-Request Id=0xfa: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Ack Id=0xfa: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > OPENBSD -> JUNIPER: LCP Configure-Request Id=0xfb: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Ack Id=0xfb: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > OPENBSD -> JUNIPER: LCP Configure-Request Id=0xfc: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Ack Id=0xfc: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > OPENBSD -> JUNIPER: LCP Configure-Request Id=0xfd: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Ack Id=0xfd: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Request Id=0x03: Max-Rx-Unit=1492
> > Auth-Prot=CHAP/MD5 Magic-Number=3430741983
> > OPENBSD -> JUNIPER: LCP Configure-Nak Id=0x03: Auth-Prot=PAP
> > OPENBSD -> JUNIPER: LCP Configure-Request Id=0xfe: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Ack Id=0xfe: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > OPENBSD -> JUNIPER: LCP Configure-Request Id=0xff: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> > JUNIPER -> OPENBSD: LCP Configure-Ack Id=0xff: Magic-Number=1818005467
> > Max-Rx-Unit=1492
> >
> > It looks like this could be as simple as the other side needing CHAP
> > instead of PAP.  Please try that next.
> >

Two possibilities not mentioned yet: some providers want specific values in
the priority field of the vlan packets, maybe try playing with the txprio
option could help.

The other thing is: if your provider (Vodafone) uses CHAP cauthentication,
you run into a problem, because you connect through Deutsche Telekom. The
way this works is, that you authenticate with DTAG, who wants PAP. They
notice your @vodafone handle and they hand your authentication off to that
providers radius service. Unfortunatly if they have different authentication
protocols, this does not work, because the openbsd pppoe wont switch from
PAP to CHAP.

/Benno

Re: emmc support on Ubiquiti Networks UniFi Security Gateway PRO-4

[Sebastian Benoit]

Diana Eichert(deich...@wrench.com) on 2019.02.24 13:42:34 -0700:
> thanks everyone for their feedback.
> 
> I ended up backing up internal emmc drive and disklabel
> dd if=/dev/rsd1c of=emmc_4G_backup/factory_linux.img bs=8225280 count=481
> 
> next step is install on internal drive.
> 
> New question, is there a way to mount Squashfs filesystem on OpenBSD?
> 
> file /mnt/squashfs.img
> /mnt/squashfs.img: Squashfs filesystem, little endian, version 4.0,
> 18463067392 bytes, 31682 inodes, blocksize: 4 bytes, created: Sat Dec
> 5 04:28:48 2015

I just sent a port of https://github.com/vasi/squashfuse/blob/master/README
to ports@ (Subject: NEW: squash-fuse).

Maybe you can test it ;)

Re: Getting traffic from rdomain X to talk to a daemon in default rdomain 0

[Sebastian Benoit]

Zach Nedwich(z...@znedw.com) on 2019.02.03 07:54:23 +1000:
> Apologies for hijacking but how can I redirect other hosts to a pair in
> PF? I've tried adding a route manually to the hosts via the gateway and
> adding a rdr-to in PF but I can't reach any hosts in the second rdomain,
> only the gateway.

well, i guess you might be missing a route.

But you are not giving any details, just a vague description of your
problem. If i want to read about puzzles, i prefer reading Ready Player One,
not openbsd-misc.

/B


> 
> Cheers,
> Zach
> 
> On February 3, 2019 7:20:28 AM GMT+10:00, Jiri B  wrote:
> >Thank you, that works fine.
> >
> >
> >Jiri
> >
> >
> >On Thu, Jan 31, 2019 at 11:26 PM Sebastian Benoit
> > wrote:
> >>
> >> Jiri B(jiri...@gmail.com) on 2019.01.31 22:23:34 +0100:
> >> > Hello,
> >> >
> >> > I'm trying to isolate an app running on OpenBSD on network level
> >and thus I
> >> > have started
> >> > the app in a specific rdomain.
> >> >
> >> > I can successfully make traffic from the rdomain to reach Internet:
> >> >
> >> > pass out quick on rdomain 1 to any nat-to (egress) rtable 0
> >>
> >> that rule is only evaluated when the packes pass through a network
> >> interface.
> >>
> >> > But I cannot figure out how to make the app in this rdomain 1 to
> >communicate
> >> > which daemons in default rdomain (0).
> >> >
> >> > With above rule I would see something like this on lo0 (rdomain0):
> >> >
> >> > Jan 31 16:04:22.285915 199.195.x.x.60666 > 199.195.x.x.53: 14874+
> >NS? .(17)
> >> >
> >> > Tested with route -T 1 exec dig @199.195.x.x  www.openbsd.org.
> >> > It seems it does not know how to send back replies ?
> >>
> >> yes, because rdomain 0 does not have a route to what network you have
> >in
> >> rdomain 1.
> >>
> >> Btw. its hard to talk about this without you giving the actual
> >networks and
> >> IPs used.
> >>
> >> > Without 'nat-to (egress)' the replies would be just send via
> >default gw in
> >> > rdomain 0:
> >> >
> >> > mx1# tcpdump -i vio0 -n -e -ttt icmp
> >> > tcpdump: listening on vio0, link-type EN10MB
> >> > Jan 31 16:08:27.053592 00:16:a1:5d:50:b6 00:12:f2:f2:1a:00 0800 98:
> >> > 199.195.x.x > 172.16.1.2: icmp: echo reply
> >> >
> >> > (172.16.1.2 was the IP in rdomain 1)
> >> >
> >> > Any idea what would be PF rule to make this working - ie. make an
> >app in
> >> > rdomain X talk to daemons in rdomain 0.
> >> >
> >> > I also tried to use pair interfaces but I failed too.
> >>
> >> Try this:
> >>
> >> # set up two connected pair interfaces:
> >> ifconfig pair8 inet 192.168.2.8/24 rdomain 8
> >> ifconfig pair1 inet 192.168.2.1/24 rdomain 0
> >> ifconfig pair1 patch pair8
> >>
> >> # they now can ping each other:
> >> ping 192.168.2.8
> >> route -T 8 exec ping 192.168.2.1
> >>
> >> # my em0 interface in rdomain 0 has the IP 192.168.1.52:
> >> em0:
> >flags=208847
> >mtu 1500
> >> lladdr 44:c6:86:5a:c2:f7
> >> index 1 priority 0 llprio 3
> >> groups: egress
> >> media: Ethernet autoselect
> >> status: active
> >> inet 192.168.1.52 netmask 0xff00 broadcast 192.168.1.255
> >>
> >> # add a route to 192.168.1.52 to rdomain 8:
> >> route -T 8 add 192.168.1.52 192.168.2.1
> >> route -T 8 exec ping 192.168.1.52
> >>
> >> # the traffic back from rdomain 0 to rdomain 8 works now, because
> >packets
> >> # are send with source ip 192.168.2.8, and rdomain 0 has a route to
> >that IP
> >> # through pair1.
> >>
> >> Now run your service on 192.168.1.52.
> >>
> >> /Benno
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 

-- 

Re: is pfsync loosing data on reboot?

[Sebastian Benoit]

Janne Johansson(icepic...@gmail.com) on 2019.02.01 12:49:53 +0100:
> Den fre 1 feb. 2019 kl 07:17 skrev Harald Dunkel :
> 
> > Hi folks,
> > I have a question about pfsync protocol in a master-backup firewall
> > configuration (OpenBSD 6.3 and 6.4):
> > If I reboot (let's say) the backup host, will it receive the whole
> > set of state information again, when it gets back online?
> > Hopefully I am not too blind to see, but pfsync(4) doesn't tell.
> >
> >
> > Yes, it will get a full dump since it has zero pre-existing knowledge of
> the current situation regarding states.
> 
> I think carp will delay itself until the sync is done, so it will not try
> to take over even if it has lower advskew than the other, until the sync is
> complete.

depending on the setting of sysctl net.inet.carp.log,
carp(4) will log what it (and pfsync) does.

Re: Getting traffic from rdomain X to talk to a daemon in default rdomain 0

[Sebastian Benoit]

Jiri B(jiri...@gmail.com) on 2019.01.31 22:23:34 +0100:
> Hello,
> 
> I'm trying to isolate an app running on OpenBSD on network level and thus I
> have started
> the app in a specific rdomain.
> 
> I can successfully make traffic from the rdomain to reach Internet:
> 
> pass out quick on rdomain 1 to any nat-to (egress) rtable 0

that rule is only evaluated when the packes pass through a network
interface.

> But I cannot figure out how to make the app in this rdomain 1 to communicate
> which daemons in default rdomain (0).
> 
> With above rule I would see something like this on lo0 (rdomain0):
> 
> Jan 31 16:04:22.285915 199.195.x.x.60666 > 199.195.x.x.53: 14874+ NS? .(17)
> 
> Tested with route -T 1 exec dig @199.195.x.x  www.openbsd.org.
> It seems it does not know how to send back replies ?

yes, because rdomain 0 does not have a route to what network you have in
rdomain 1.

Btw. its hard to talk about this without you giving the actual networks and
IPs used.
 
> Without 'nat-to (egress)' the replies would be just send via default gw in
> rdomain 0:
> 
> mx1# tcpdump -i vio0 -n -e -ttt icmp
> tcpdump: listening on vio0, link-type EN10MB
> Jan 31 16:08:27.053592 00:16:a1:5d:50:b6 00:12:f2:f2:1a:00 0800 98:
> 199.195.x.x > 172.16.1.2: icmp: echo reply
> 
> (172.16.1.2 was the IP in rdomain 1)
> 
> Any idea what would be PF rule to make this working - ie. make an app in
> rdomain X talk to daemons in rdomain 0.
> 
> I also tried to use pair interfaces but I failed too.

Try this:

# set up two connected pair interfaces:
ifconfig pair8 inet 192.168.2.8/24 rdomain 8
ifconfig pair1 inet 192.168.2.1/24 rdomain 0
ifconfig pair1 patch pair8

# they now can ping each other:
ping 192.168.2.8
route -T 8 exec ping 192.168.2.1

# my em0 interface in rdomain 0 has the IP 192.168.1.52:
em0: flags=208847 mtu 
1500
lladdr 44:c6:86:5a:c2:f7
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet 192.168.1.52 netmask 0xff00 broadcast 192.168.1.255

# add a route to 192.168.1.52 to rdomain 8:
route -T 8 add 192.168.1.52 192.168.2.1
route -T 8 exec ping 192.168.1.52

# the traffic back from rdomain 0 to rdomain 8 works now, because packets
# are send with source ip 192.168.2.8, and rdomain 0 has a route to that IP
# through pair1.

Now run your service on 192.168.1.52.

/Benno

Re: Questions about Carp / PF / PFSync

[Sebastian Benoit]

Charles Amstutz(charl...@binary.net) on 2019.01.30 23:16:17 +:
> Hello
> 
> We are running into an issue with a lot of dropped packets where states are 
> failing to be created. We have noticed that it coincides with a fair amount 
> of congestion, around 10-15/s according to 'pfctl -si'.
> 
> We finally tried disabling our Carp Interfaces (we are using carp for 
> failover) and the problem seems to completely go away. We have 53 carp 
> interfaces on these two boxes and are just looking for some input on what 
> might be causing an issue like this, where having carp interfaces enabled is 
> causing such high congestion.
> 
> We are running OpenBSD 6.4.
> 
> Thanks,

Set sysctl net.inet.carp.log=7 (and activate carp again).
What does it show (in /var/log/messages)?

Also, whats the output of

sysctl net.inet.ip.ifq.drops
sysctl net.inet6.ip6.ifq.drops
netstat -m
pfctl -vsi

?

Re: Cannot ping local IPv6 traffic on seperate lo1 interface

[Sebastian Benoit]

Mark(m...@zm.is) on 2019.01.28 20:24:36 +:
> Hello everyone,
> 
> I've set up another interface for local services, as I would like to
> have internal firewall rules. Using lo0 is problematic as it's what
> everything else uses.
> 
> I can't, however, ping the IPv6 addresses I added:
> # ping6 ::2
> PING ::2 (::2): 56 data bytes
> 

::2/128 is not a valid ipv6 address. In IPv6 there is only one address for
localhost, ::1.

If you need other local addresses on lo1, either use the automatically
added link-local address (fe80::1%lo1) or set a unique local address
(https://en.wikipedia.org/wiki/Unique_local_address).

$ doas ifconfig lo1 inet6 alias fd00::2/64
$ ping6 fd00::2
PING fd00::2 (fd00::2): 56 data bytes
64 bytes from fd00::2: icmp_seq=0 hlim=64 time=0.153 ms
^C

/Benno

> ^ this hangs
> So does this: # ping6 ::2
> 
> ::1 works fine:
> # ping6 ::1
> PING ::1 (::1): 56 data bytes
> 64 bytes from ::1: icmp_seq=0 hlim=64 time=0.369 ms
> 64 bytes from ::1: icmp_seq=4 hlim=64 time=0.340 ms
> ^C
> --- ::1 ping statistics ---
> 2 packets transmitted, 2 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 0.180/0.362/0.481/0.104 ms
> 
> Here is /etc/hostname.lo1:
> #inet 127.0.0.1 255.0.0.0
> inet 127.0.0.2 255.0.0.0
> inet alias 127.0.0.3 255.0.0.0
> 
> #inet6 ::1 128
> inet6 ::2 128
> inet6 alias ::3 128
> 
> pf.conf has nothing concerning lo1. Issue persists if pf is disabled.
> 
> Here's ifconfig:
> lo0: flags=8049 mtu 32768
> index 3 priority 0 llprio 3
> groups: lo
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> inet 127.0.0.1 netmask 0xff00
> vio0: flags=8843 mtu 1500
> lladdr fa:16:3e:35:ba:80
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect
> status: active
> inet 51.38.80.182 netmask 0xff00 broadcast 51.38.80.255
> inet6 fe80::c4d0:8bc6:3c06:9c91%vio0 prefixlen 64 scopeid 0x1
> inet6 2001:41d0:801:2000::cbb prefixlen 64
> enc0: flags=0<>
> index 2 priority 0 llprio 3
> groups: enc
> status: active
> lo1: flags=8049 mtu 32768
> index 4 priority 0 llprio 3
> groups: lo
> inet 127.0.0.2 netmask 0xff00
> inet6 fe80::1%lo1 prefixlen 64 scopeid 0x4
> inet6 ::2 prefixlen 128
> inet6 ::3 prefixlen 128
> pflog0: flags=141 mtu 33136
> index 5 priority 0 llprio 3
> groups: pflog
> 
> Here's route -n show:
> Routing tables
> 
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio
> Iface
> default51.38.80.1 UGS   18 1416 - 8
> vio0
> 224/4  127.0.0.1  URS00 32768 8
> lo0
> 51.38.80/2451.38.80.182   UCn10 - 4
> vio0
> 51.38.80.1 32:7a:6c:96:dc:ff  UHLch  2   73 - 3
> vio0
> 51.38.80.182   fa:16:3e:35:ba:80  UHLl   0 4100 - 1
> vio0
> 51.38.80.255   51.38.80.182   UHb00 - 1
> vio0
> 127/8  127.0.0.1  UGRS   00 32768 8
> lo0
> 127.0.0.1  127.0.0.1  UHhl  47 6876 32768 1
> lo0
> 127.0.0.2  127.0.0.2  UHl4  388 32768 1
> lo1
> 127.0.0.3  127.0.0.3  UHl00 32768 1
> lo1
> 185.16.85.134  51.38.80.1 UGHD   1 1382 - L   8
> vio0
> 
> Internet6:
> DestinationGatewayFlags
>  Refs  Use   Mtu  Prio Iface
> default2001:41d0:801:2000::1  UGS
> 2  466 - 8 vio0
> ::/96  ::1UGRS
> 02 32768 8 lo0
> ::1::1UHhl
>10   30 32768 1 lo0
> ::2::2UHl
> 04 32768 1 lo1
> ::3::3UHl
> 06 32768 1 lo1
> :::0.0.0.0/96  ::1UGRS
> 00 32768 8 lo0
> 2001:41d0:801:2000::/642001:41d0:801:2000::cbbUCn
> 10 - 4 vio0
> 2001:41d0:801:2000::1  32:7a:6c:96:dc:ff  UHLch
> 1   52 - 3 vio0
> 2001:41d0:801:2000::cbbfa:16:3e:35:ba:80  UHLl
> 0  474 - 1 vio0
> 2002::/24  ::1UGRS
> 00 32768 8 lo0
> 2002:7f00::/24 ::1UGRS
> 00 32768 8 lo0
> 2002:e000::/20 ::1UGRS
> 00 32768 8 lo0
> 2002:ff00::/24 ::1UGRS
> 0   

Re: BGP Redistribution question

[Sebastian Benoit]

8.1.1UCn10
> - 4 em0
> 192.168.1.100:e0:67:09:71:3c  UHLl   0   51 - 1 em0
> 192.168.1.2link#1 UHLch  2   47 - 3 em0
> 192.168.1.3192.168.1.1UHb00 - 1 em0
> 192.168.5.1192.168.5.1UHl0  371 32768
> 1 lo100192.168.5.2/32 192.168.1.2UG 00
> -32 em0  192.168.5.3/32 192.168.1.2UG 0
> 13 -32 em0
> 
> 
> But, I cannot see the link network between B and C (192.168.2.0/30).
> 
> 
> B#cat /etc/bgpd.conf (Comments removed for brevity)
> 
> # cat /etc/bgpd.conf | grep -v "^#"
> 
> ASN="65001"
> 
> AS $ASN
> router-id 192.168.5.2
> 
> prefix-set mynetworks { \
> 192.168.5.2/32  \
> 192.168.2.0/30  \
> }
> 
> prefix-set bogons {
> 0.0.0.0/8   # 'this' network [RFC1122]
> 10.0.0.0/8  # private space [RFC1918]
> 100.64.0.0/10   # CGN Shared [RFC6598]
> 127.0.0.0/8 # localhost [RFC1122]
> 169.254.0.0/16  # link local [RFC3927]
> 172.16.0.0/12   # private space [RFC1918]
> 192.0.2.0/24# TEST-NET-1 [RFC5737]
> 192.88.99.0/24  # 6to4 anycast relay [RFC7526]
> #192.168.0.0/16 # private space [RFC1918]
> 198.18.0.0/15   # benchmarking [RFC2544]
> 198.51.100.0/24 # TEST-NET-2 [RFC5737]
> 203.0.113.0/24  # TEST-NET-3 [RFC5737]
> 224.0.0.0/4 # multicast
> 240.0.0.0/4 # reserved for future use
> ::/8# RFC 4291 IPv4-compatible, loopback, et al
> 0100::/64   # Discard-Only [RFC]
> 2001:2::/48 # BMWG [RFC5180]
> 2001:10::/28# ORCHID [RFC4843]
> 2001:db8::/32   # docu range [RFC3849]
> 2002::/16   # 6to4 anycast relay [RFC7526]
> 3ffe::/16   # old 6bone
> fc00::/7# unique local unicast
> fe80::/10   # link local unicast
> fec0::/10   # old site local unicast
> ff00::/8# multicast
> }
> 
> network prefix-set mynetworks set large-community $ASN:1:1
> network inet priority 32
> 
> group "ibgp mesh v4" {
> remote-as $ASN
> # use loopback for IBGP sessions, assume its distributed in OSPF
> local-address 192.168.2.1
> neighbor 192.168.2.2# 4nic2
> }
> 
> allow to ebgp prefix-set mynetworks large-community $ASN:1:1
> 
> deny quick from ebgp prefix-set mynetworks or-longer
> 
> allow from ibgp
> allow to ibgp
> 
> match from 192.168.2.2 set rtlabel zyx
> 
> match from ebgp set { community delete $ASN:* }
> match from ebgp set { large-community delete $ASN:*:* }
> 
> allow from any inet prefixlen 8 - 24
> allow from any inet6 prefixlen 16 - 48
> 
> match from any community GRACEFUL_SHUTDOWN set { localpref 0 }
> 
> deny quick from any prefix-set bogons or-longer
> 
> deny quick from any AS 23456
> deny quick from any AS 64496 - 131071
> deny quick from any AS 42 - 4294967295
> 
> deny from any max-as-len 100
> 
> 
> network inet priority 32 is used to redistribute ospf into bgp.

Between A and B you run OSPF.

So B has to send A the information about how 192.168.2.2 is reachable
through OSPF.

add to ospfd.conf on B:

either "redistribute connected"

or

area 0.0.0.0 {
...
interface em0:192.168.2.1 { passive }
...
}


where em0 is the interface where you have 192.168.2.1 configured on.

The second method allows for finer control over what networks get
redistributed.
 
> 
> Hope it makes more sense now.
> 
> Simply, how can I get router B to advertise (or label) the directly
> connected network (192.168.2.0/30) so that I can re-advertise into
> OSPF.
> 
> Is there a way to add a label to a directly connected network? Can I
> get router C to advertise this, and then use router B to label? etc
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 
> On Mon, 14 Jan 2019 at 22:06, Sebastian Benoit  wrote:
> 
> > Hi,
> >
> > Simen Stavdal(sstav...@gmail.com) on 2019.01.14 21:29:43 +0100:
> > > Hello,
> > >
> > > I have three routers connected in a  chain.
> > > A<->B<->C
> > >
> > > All routers have a host address as loopback 100 (192.168.5.x/32, A=1,
> > B=2,
> > > C=3).
> > > The segm

Re: BGP Redistribution question

[Sebastian Benoit]

Hi,

Simen Stavdal(sstav...@gmail.com) on 2019.01.14 21:29:43 +0100:
> Hello,
> 
> I have three routers connected in a  chain.
> A<->B<->C
> 
> All routers have a host address as loopback 100 (192.168.5.x/32, A=1, B=2,
> C=3).
> The segments between the routers are 192.168.1.0/30 (AB) and 192.168.2.0/30
> (BC).
> 
> A to B runs OSPF
> B to C runs IBGP
> 
> I redistribute the BGP routes into OSPF using the label I append on router
> B.
> router B : match from  set rtlabel zyx
> And this works just fine. I see the tag being applied (but only on the
> advertised lo100 host address).
> Reverse redistribution is based on route priority (32) for OSPF into bgp.
> All good.
> 
> The link network however between B and C is not being advertised, as it is
> locally connected for both router B and C. They are added in the network
> statement on both sides.
> So, on B, I can see the route label on the C loopback interface marked zyx.
> 192.168.2.0/30 however does not have any route label, and hence will not be
> redistributed into OSPF.
> 
> So, I can ping router C from router B.
> When I ping loopback on router C from router A using the loopback interface
> as source, all is good.
> When I ping with no source interface, the source address is the link
> network not being advertised, and hence the far router does not know where
> to send the traffic.
> 
> I will continue to play around with this, just wondering if anybody has a
> "good practice" way of dynamically advertising the network.

Your mail is missing

- what version of openbsd you are running, i.e. dmesg

- your bgpd.conf and ospfd.conf files would be helpful.

- you describe what you have currently configured, but not what your actual
intent is. It may be better if you say what you want your network devices to
do.

That said, if i understand what you are doing right, maybe
"network inet connected" on router B bgpd.conf will help.
(you may also need filters to allow the prefix to be sent to C).

/Benno

Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"

[Sebastian Benoit]

Remi Locherer(remi.loche...@relo.ch) on 2019.01.10 21:18:58 +0100:
> On Fri, Jan 11, 2019 at 12:06:09AM +0700, Igor Podlesny wrote:
> > On Thu, 10 Jan 2019 at 21:11, Remi Locherer  wrote:
> > [...]
> > > I can reproduce it. Interestingly it only sends out the wrong type when
> > > the "depend on" interfac (carp1 in your example) is down or in backup
> > > state and the configured type is 2.
> > 
> > That's an irony for real! -- Type 1 is "heavier" than Type 2; so it means 
> > then
> > when it shouldn't be announcing "heavy" default due it's BACKUP it
> > actually is announcing
> > it as "heavy" (preferred) one.
> > 
> > > I don't have much time right now so please don't expect a fast fix.
> > 
> > Understood.
> > 
> > > > I see, thank you. BTW, if-when it's fixed would such a fix be brought
> > > > within standard syspatch update process or
> > > > what would it be otherwise?
> > >
> > > I don't think this is worth a syspatch. It is not a vulnerability or
> > > stability issue.
> > 
> > The second part of my question was exactly about how this fix would be
> > supplied then if
> > not with syspatch? OpenOSPFD seems to be part of the OS, and I thought that
> > syspatch is the appropriate mechanism for that hence. What else if not 
> > syspatch?

We supply errata (and thus syspatches) for security issues and for problems
that can cause a lot of grief to many people.

depend on is a nice feature, but not critical to the use of ospfd, so this
probably wont get an errata. If you really need the fix, you can apply the
patch to /usr/src/usr.sbin/ospfd yourself (i believe it should apply without
problems), build and install it, until you update to 6.5.

/Benno

> A fix will go to -current which will then become the next release.
> 
> > > And I also don't see how it affects existing setups.
> > 
> > Well, setting Type 2 is a sign of interaction with different routing
> > software since most of it
> > use Type 2 by default. Then:
> > 
> > * if config isn't mixed it runs on Type 1 and fix won't affect it in a way;
> > * if it's mixed and doesn't use "depend on" it won't be broken as well.
> > 
> > But only if it's mixed and uses "depend on" it would be affected (read
> > "fixed") :)
> 
> Yes. But this feature is relatively new so I don't expect thousands of
> networks using it. ;-)

Re: Experiences with single mode fibre on OpenBSD ?

[Sebastian Benoit]

Rachel Roch(rr...@tutanota.de) on 2019.01.02 21:12:53 +0100:
> Hi,
> 
> I see the man pages mention the odd SM fibre NIC, which is a good start.
> 
> However I could do with some real-world feedback from people in terms of
> the SM NICs they're using and any other experiences with SM on OpenBSD.

Hi,

you are not giving much details what you are trying to do.

That said, if you do 10G use intel X520 DA2 cards (ix(4)) or onboard
hardware with the same chipset. These have SFP+ slots and you can insert
SFP+ tranceivers (coded for intel). They also support 1G SFP tranceivers.

Swapping tranceivers may require a reboot.

/Benno

Re: netstat *:* udp sockets

[Sebastian Benoit]

Sebastian Benoit(benoit-li...@fb12.de) on 2018.12.17 17:59:49 +0100:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.12.17 08:25:07 +0100:
> > On Sun, Dec 16, 2018 at 05:09:06PM -0500, Ted Unangst wrote:
> > > Claudio Jeker wrote:
> > > > On Fri, Dec 14, 2018 at 01:26:25PM -0500, Ted Unangst wrote:
> > > > > Philip Guenther wrote:
> > > > > > And, perhaps more directly, how would I block this in pf.conf?
> > > > > > >
> > > > > > 
> > > > > > Excellent choice, blocking dhclient from receiving the leases that 
> > > > > > it
> > > > > > requests.
> > > > > > "What problem are you trying to solve?"
> > > > > 
> > > > > Well, this may be something of a lost cause, but I would prefer that 
> > > > > chrome
> > > > > not listen for stuff I don't understand. It listens on port 5353 as 
> > > > > well, for
> > > > > mDNS, and I can block that easily enough. It's the socket without a 
> > > > > port
> > > > > that's giving me trouble.
> > > > 
> > > > But a socket without a port is not listening on anything. It will not 
> > > > get
> > > > any packets. It does not need to be filtered. This is how UDP works, it 
> > > > is
> > > > a connectionless protocol.
> > > 
> > > ok, thank you, I was confused because they show up in netstat -ln too. I 
> > > guess
> > > that's just historic how it is behavior.
> 
> nothing historic about it, i added -l last year.
> 
> but i wanted to keep it simple, i thought that its obvious what "listening"
> sockets mean in this context (i.e. that it only really is a concept in TCP).
> 
> > I guess we should change that. Problem is that UDP does not support
> > listen(2) and so there is no listening state. Should netstat exclude all
> > of UDP when using -l 
> 
> here is a diff for that
> 
> > or what should it show? Only sockets that are bound
> > but not connected (local port != 0 but remote addr/port = 0)?
> 
> see my other mail for that diff.

here. Ok for one or the other?

(netstat_l_udp_only_otherside_zero.diff)

diff --git usr.bin/netstat/inet.c usr.bin/netstat/inet.c
index e8e2a4dcd4f..d378bfe6280 100644
--- usr.bin/netstat/inet.c
+++ usr.bin/netstat/inet.c
@@ -225,6 +225,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
int addrlen = 22;
int isany = 0;
int istcp = 0;
+   int isudp = 0;
int isip6 = 0;
 
/* XXX should fix kinfo_file instead but not now */
@@ -282,6 +283,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
case IPPROTO_UDP:
name = "udp";
name6 = "udp6";
+   isudp = 1;
break;
case IPPROTO_DIVERT:
name = "divert";
@@ -303,6 +305,9 @@ netdomainpr(struct kinfo_file *kf, int proto)
if (!aflag && lflag && istcp &&
kf->t_state != TCPS_LISTEN)
return;
+   if (!aflag && lflag && isudp &&
+   (kf->inp_lport == 0 || kf->inp_fport != 0))
+   return;
 
if (af != kf->so_family || type != kf->so_type) {
af = kf->so_family;
@@ -310,7 +315,7 @@ netdomainpr(struct kinfo_file *kf, int proto)
printf("Active Internet connections");
if (aflag)
printf(" (including servers)");
-   else if (lflag)
+   else if (lflag && (istcp||isudp))
printf(" (only servers)");
putchar('\n');
if (Aflag) {

Re: netstat *:* udp sockets

[Sebastian Benoit]

Claudio Jeker(cje...@diehard.n-r-g.com) on 2018.12.17 08:25:07 +0100:
> On Sun, Dec 16, 2018 at 05:09:06PM -0500, Ted Unangst wrote:
> > Claudio Jeker wrote:
> > > On Fri, Dec 14, 2018 at 01:26:25PM -0500, Ted Unangst wrote:
> > > > Philip Guenther wrote:
> > > > > And, perhaps more directly, how would I block this in pf.conf?
> > > > > >
> > > > > 
> > > > > Excellent choice, blocking dhclient from receiving the leases that it
> > > > > requests.
> > > > > "What problem are you trying to solve?"
> > > > 
> > > > Well, this may be something of a lost cause, but I would prefer that 
> > > > chrome
> > > > not listen for stuff I don't understand. It listens on port 5353 as 
> > > > well, for
> > > > mDNS, and I can block that easily enough. It's the socket without a port
> > > > that's giving me trouble.
> > > 
> > > But a socket without a port is not listening on anything. It will not get
> > > any packets. It does not need to be filtered. This is how UDP works, it is
> > > a connectionless protocol.
> > 
> > ok, thank you, I was confused because they show up in netstat -ln too. I 
> > guess
> > that's just historic how it is behavior.

nothing historic about it, i added -l last year.

but i wanted to keep it simple, i thought that its obvious what "listening"
sockets mean in this context (i.e. that it only really is a concept in TCP).

> I guess we should change that. Problem is that UDP does not support
> listen(2) and so there is no listening state. Should netstat exclude all
> of UDP when using -l 

here is a diff for that

> or what should it show? Only sockets that are bound
> but not connected (local port != 0 but remote addr/port = 0)?

see my other mail for that diff.

(netstat_l_only_tcp.diff)

diff --git usr.bin/netstat/main.c usr.bin/netstat/main.c
index 17c889768a2..6bf155205ee 100644
--- usr.bin/netstat/main.c
+++ usr.bin/netstat/main.c
@@ -189,6 +189,8 @@ main(int argc, char *argv[])
break;
case 'l':
lflag = 1;
+   tp = knownname("tcp");
+   pflag = 1;
break;
case 'M':
memf = optarg;
@@ -203,7 +205,8 @@ main(int argc, char *argv[])
nflag = 1;
break;
case 'p':
-   if ((tp = name2protox(optarg)) == NULL) {
+   if (pflag == 0 &&
+   (tp = name2protox(optarg)) == NULL) {
(void)fprintf(stderr,
"%s: %s: unknown protocol\n",
__progname, optarg);

Re: netstat *:* udp sockets

[Sebastian Benoit]

Ted Unangst(t...@tedunangst.com) on 2018.12.13 13:38:58 -0500:
> netstat -an tells me I am listening to all the udp.
> 
> Active Internet connections (including servers)
> Proto   Recv-Q Send-Q  Local Address  Foreign Address(state)
> udp  0  0  *.**.*   
> udp  0  0  127.0.0.1.53   *.*   
> udp  0  0  *.**.*   
> udp  0  0  *.5353 *.*   
> udp  0  0  *.**.*   
> 
> What are those *.* sockets doing? How can you listen to all the ports?

In the case of dhclient, it opens that SOCK_RAW socket to send packets
to a dhcp server:

get_udp_sock() does socket(AF_INET, SOCK_RAW, IPPROTO_UDP). But it does not
bind() or connect(). Thats why you have "Local Address" and "Foreign
Address" *.*.

I think the second one might be the one it opens with ioctlfd =
socket(AF_INET, SOCK_DGRAM, 0). It only uses it to do ioctl() on it, see
section INTERFACES in netintro(4).

> According to fstat, two belong to dhclient and one to chrome.
> 
> root dhclient   552413* internet dgram udp *:0
> root dhclient   552415* internet dgram udp *:0
> tedu chrome 52839  107* internet dgram udp *:0
> 
> Although now they are printed as *:0. How do such sockets work?

The first socket above is used in send_packet() in sendmsg(ifi->ufdesc, msg,
&0) to a specific dhcp server. 
It is not used to receive packets and indeed it cannot receive any on that
socket.
It sends broadcast packets via bpf(4) and receives packets via bpf(4).
 
> And, perhaps more directly, how would I block this in pf.conf?

In the case of dhclient, you cant. Well, you can try, but it will break
things. The problem is that dhclient is special, it needs to send things
while there is no IP configuration on an interfaces. So it needs to do
things itself that the IP stack would do for normal programs.

If you run dhclient, you trust it not to send bad things, and not to receive
things it should not see (It configures the bpf filter to only get packets
to port 67).

As for chrome, i have no idea what it is doing... ;)

Re: Pflow granularity

[Sebastian Benoit]

Thomas Boernert(m...@tbits.net) on 2018.12.06 18:11:17 +0100:
> Hi,
> 
> i found this old thread and i have the same problem. i need an active 
> timeout of the netflow data.
> 
> i found this patch
> http://marc.info/?l=openbsd-misc&m=124661838923498&w=2
> which i can set the "set timeout pflowexport 60" for example
> 
> Have anyone tried that ?
> 
> Sebastian Benoit wrote:
> however right now some people are working on something similar.
> 
> Is the another solution?

No, the other solution never happened.

By all means, try the diff, maybe it still works.

/Benno

Re: Redistributing between bgpd and ospfd

[Sebastian Benoit]

Henry Bonath(he...@thebonaths.com) on 2018.10.27 19:21:15 -0400:
> Claudio -
> 
> One use case where I personally ran into this need in the past is in an
> MPLS PE-CE where OSPF is running between the Provider and Customer. (L3VPN)
> One would want to redistribute the Customers OSPF routes into BGP as VPNv4
> prefixes into the customers VRF in the provider network.
> 
> We typically run Cisco on our CPE's and do exactly this with our customers,
> with a redistribute ospf statement under "address-family vpnv4 vrf
> cusomerVRF"
> I'd *love* to be able to do the same with OpenBSD and not have to fork out
> Cisco money at the customer premise.

This should already be possible (as described my mail) with

  network inet priority 32
 
> That being said, EIGRPD would also benefit here, as I have customers that
> run EIGRP and want to use that on their CE's.

same there, use priority 28

/Benno
 
> Thanks for everything that you do, and keep up the great work!
> 
> On Mon, Oct 15, 2018 at 8:37 AM Claudio Jeker 
> wrote:
> 
> > On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote:
> > > On 15.10.18 12:58, Sebastian Benoit wrote:
> > > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200:
> > > > > Hello,
> > > > >
> > > > > I am trying to get bgpd and ospfd play nicely with route
> > redistribution.
> > > > >
> > > > > So far the only way I have found that suits my need is to use
> > > > > bgpd.conf network statements and rtlabels.
> > > > >
> > > > > So, to make ospfd learn route from bgpd I use rtlabels. So in
> > bgpd.conf:
> > > > > match from  set rtlabel from_bgpd
> > > > >
> > > > > And in ospfd.conf:
> > > > > redistribute rtlabel from_bgpd
> > > > >
> > > > >
> > > > > So far so good. But the other way around, to bake bgpd learn from
> > > > > ospfd it becomes a bit more tedious. The only way I have found to
> > make
> > > > > bgpd announce ospf originated routes (to its bgp peers) is via
> > network
> > > > > statements in bgpd.conf. These network statements are not conditional
> > > > > on the availability of such a route in ospf though so they are not
> > > > > very dynamic anymore.
> > > > >
> > > > > I understand that it according to standard
> > > > > (https://tools.ietf.org/html/rfc1364) should be something that is
> > > > > explicit for type 1 and 2 LSAs.
> > > > >
> > > > > What is the recommended way to achieve dynamic explicit route
> > > > > redistribution in both directions?
> > > > Network statements are the correct way.
> > > >
> > > > You can use
> > > >
> > > >   network (inet|inet6) priority ...
> > > >   network (inet|inet6) rtlabel ...
> > > >
> > > > So with
> > > >
> > > >network inet priority  32
> > > >
> > > > you should be able to redistribute all ospf routes into bgp.
> > > >
> > > > If this does not help, please explain your problem further (and
> > include your
> > > > config).
> > > >
> > > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot)
> > for
> > > > this as there was at least a bugfix for route-labels.)
> > > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer
> > > setting them per area, or per interface where a route was learned.
> > > just wondering why is it not implemented yet. is that too complex
> > change? or
> > > just not necessary?
> > >
> >
> > Until now there has not been a need for this. In general and probably best
> > common practice is to not mix BGP and OSPF. Instead OSPF is building the
> > underlaying network to run BGP on top of. This is why benno@ was asking
> > for the use case.
> >
> > By the way, because of the nature of OSPF it does not make sense to tag
> > routes by interface, doing it by area could be an option but that comes
> > with some edge cases that need further inspection.
> >
> > --
> > :wq Claudio
> >
> >
> 

-- 

Re: pf keep sate

[Sebastian Benoit]

Daniel Corbe(dco...@hammerfiber.com) on 2018.10.22 11:09:08 -0400:
> at 10:04 AM, Fr??d??ric Goudal  wrote:
> 
> >- is there any reason to add keep state to a pass rule ?

Only if you want to use one of the "Stateful Tracking Options" (see
pf.conf(5)).

For example, to add no-sync (dont send the state via pfsync(4)) you would
add "keep state (no-sync)" to a rule:

 pass in proto tcp from any to any
 port www keep state (no-sync)
 
(Of course you would only consider this if you actually have a pfsync(4)
interface configured).

> 1) UDP rules don???t keep state by default.

Yes, they do.

> 2) Even for TCP connections, it???s better to explicitly throw a keep state 
> on there for clarity, so that people who come in behind you and actually  
> bother reading the documentation don???t have to ask the same question.   

Thats a matter of taste, but i prefer not to read and write a useless
"keep state" on every line.

> There???s also other available options for TCP connections that you might  
> want to look into, such as flags S/SA (only allow initial handshake between 
> endpoints that don???t have an established state)

which is the default too.

> and modulate state, which generates strong, random ISNs for new connections.




> 
> 
> 
> 
> 

-- 

Re: relayd and radius

[Sebastian Benoit]

Shawn Southern(shawn.south...@entegrus.com) on 2018.10.19 18:01:41 +:
> So apparently this works... I was expecting relayd to listen on those ports, 
> but I'm guessing that since it hooks through pf, that's not necessary.

It only listens if you use "relay". If you use "redirect", it uses pf tables
with rdr rules.

You should see something like this:

# pfctl -sA
  relayd

# pfctl -sA -a relayd/*
  relayd/radius

# pfctl -sr -a relayd/radius
pass in quick on rdomain 0 inet proto tcp from any to xxx.xxx.xxx.xxx port =
 flags S/SA keep state (tcp.established 600) rdr-to
 port  round-robin

# pfctl -a relayd/radius -T show -t radius
a.b.c.d
a.b.c.e


Please read the section "REDIRECTIONS" in relayd.conf(5).

I admit the line "Specify an address and a port to listen on.  pf(4) will
redirect..." could be rewritten.

/Benno
 
> -Original Message-
> From: owner-m...@openbsd.org  On Behalf Of Shawn 
> Southern
> Sent: October 19, 2018 1:00 PM
> To: misc@openbsd.org
> Subject: relayd and radius
> 
> We have a lot of devices that use RADIUS, but they do not allow us to specify 
> a 2nd RADIUS server.  Since we use OpenBSD w/ CARP as our router/firewall, we 
> want to use relayd to provide some redundancy for the RADIUS servers.
> 
> There are two internal subnets - 10.10.10.0/24, which has our servers, and 
> 10.10.11.0/24 that has the devices using RADIUS to authenticate clients.  
> 10.10.10.1 and 10.10.11.1 are both carp interfaces.
> 
> When starting relayd, nothing appears to be listening on the RADIUS ports.  
> Is this even possible with relayd?  Is my configuration just horribly wrong?
> 
> relayd.conf:
> radius1 = "10.10.10.5"
> radius2 = "10.10.10.6"
> radius_listen = "10.10.11.1"
> 
> table  { $radius1 }
> table  { $radius2 }
> 
> redirect radius {
> listen on $radius_listen udp port 1812:1813
> forward to  check icmp
> forward to  check icmp
> }
> 
> Thanks in advance for any help!
> 

-- 

Re: relayd smtp traffic

[Sebastian Benoit]

Markus Rosjat(ros...@ghweb.de) on 2018.10.19 13:20:46 +0200:
> Hi all,
> 
> once again a silly question (but maybe someone is willing to answer) 
> about relayd. Is it spossible to determine the domain of the recipient 
> and depending on this redirect the traffic to da specific server behind 
> the relayd machine?

No.

> What I try to do is setup a test mailserver and just 
> redirect mailtraffic for a domain to this machine.

/Benno

Re: Redistributing between bgpd and ospfd

[Sebastian Benoit]

open...@kene.nu(open...@kene.nu) on 2018.10.17 12:44:02 +0200:
> Hello,
> 
> On Tue, Oct 16, 2018 at 4:56 PM Sebastian Benoit  wrote:
> >
> > Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200:
> > > On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote:
> > > > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote:
> > > > > Hello,
> > > > >
> > > > > Only relying on OSPF hellos effectively makes it mimic BGP with its
> > > > > keepalives. I will ponder the value of transporting the underlay in
> > > > > OSPF, effectively transporting loopback peering addresses for BGP in
> > > > > OSPF. I am not sure that it will make my life easier but will consider
> > > > > it.
> > > >
> > > > OSPF is generally faster at converging after reroute and it is possible 
> > > > to
> > > > set the router-dead-time to minimal which will give you a 1 second
> > > > timeout. Also the default of 40sec is lower than the 90sec of BGP.
> > > > Additionally OSPF may give you multipath routes so the failover for BGP
> > > > may be not noticable. Also GRE has a way to emulate link state but to be
> > > > honest if I use OSPF on a GRE link I will not turn it on (unless
> > > > requested).
> > >
> > > I guess the brewing BFD support would speed this up for BGP when it 
> > > arrives
> > > and make OSPF less useful if speed is the thing that needs to be solved.
> > >
> > > Also I've been thinking about the following config in ospfd
> > >
> > > rtlabel label external-tag number
> > >  Map route labels to external route tags and vice versa.  The
> > >external route tag is a non-negative 32-bit number
> > >attached to AS-external OSPF LSAs.
> > >
> > > What exactly does this mean? As I understand it is to map rtlabels to LSA
> > > Type 5 tags. But what do you do with it then? Could this be used for what
> > > this thread is talking about or is it totally off?
> >
> > If you do this on two (or more routers) you distribute the routes and they
> > end up in the fib with that rtlabel (note the "and vice versa").
> >
> > You can do all the things you can do with route labels, for example use
> > them in pf filters.
> >
> > And yes, you could also use it to redistribute them into bgp (although that
> > needs to happen on another router i think):
> >
> >  ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ...
> >  hostA  hostB hostBhostB
> >
> > /Benno
> 
> I might be wrong here but in prder to have ospfd generate type 5 LSAs
> one needs both a BGP speaker that announces the prefix in question
> into ospf and two different ospf areas in your network?

No need for a bgp speaker: a route in the routing table with the label is
enough.

So here is a rough description of how ospfd and bgpd announce new prefixes
(i.e. the ones not learned from other routers).

ospfd looks at whats in the kernel routing table (FIB), and depending on its
configuration (the interface statements _and_ redistribute commands) it adds
routes into its ospfd internal RIB. That RIB is then propagated into the
ospf network (skip ospf protocol details here).

ospfd needs routes in the FIB to inject new routes into OSPF.

By inject, i mean "add a new network to the routes in the RIB".

BGPD on the other hand has the "network " statement.

It adds the prefix given there to its RIB ("injects it into BGP") without
the need for a route in the FIB.

The additional options (network priority ..., network rtlabel ...) are
only there for convinience and special cases, they are not really needed
for standard bgp setups.

> Or can I make ospfd generate type5 LSAs in some other way? I see that
> rtlabels would do it but that implies I have an already existing route
> in the fib which preemptively I tag in some way. In my case the routes
> are generated by interface statements in ospfd.conf (so type1 and 2
> LSAs).

If you use interface statements, those interfaces have IPs on them, which you
will find have routes in the routing table.

Also, there is "ifconfig  rtlabel ..."

I don't know if ospfd will pick those route-labels up (with the rtlabel
statement). I think it should, but havent used that or looked at the code.

/Benno

Re: Redistributing between bgpd and ospfd

[Sebastian Benoit]

Tommy Nevtelen(to...@nevtelen.com) on 2018.10.16 15:11:51 +0200:
> On Tue, Oct 16, 2018 at 10:21:37AM +0200, Claudio Jeker wrote:
> > On Tue, Oct 16, 2018 at 09:13:20AM +0200, open...@kene.nu wrote:
> > > Hello,
> > > 
> > > Only relying on OSPF hellos effectively makes it mimic BGP with its
> > > keepalives. I will ponder the value of transporting the underlay in
> > > OSPF, effectively transporting loopback peering addresses for BGP in
> > > OSPF. I am not sure that it will make my life easier but will consider
> > > it.
> > 
> > OSPF is generally faster at converging after reroute and it is possible to
> > set the router-dead-time to minimal which will give you a 1 second
> > timeout. Also the default of 40sec is lower than the 90sec of BGP.
> > Additionally OSPF may give you multipath routes so the failover for BGP
> > may be not noticable. Also GRE has a way to emulate link state but to be
> > honest if I use OSPF on a GRE link I will not turn it on (unless
> > requested).
> 
> I guess the brewing BFD support would speed this up for BGP when it arrives 
> and make OSPF less useful if speed is the thing that needs to be solved.
> 
> Also I've been thinking about the following config in ospfd
> 
> rtlabel label external-tag number
>  Map route labels to external route tags and vice versa.  The
>external route tag is a non-negative 32-bit number
>attached to AS-external OSPF LSAs.
> 
> What exactly does this mean? As I understand it is to map rtlabels to LSA
> Type 5 tags. But what do you do with it then? Could this be used for what
> this thread is talking about or is it totally off?

If you do this on two (or more routers) you distribute the routes and they
end up in the fib with that rtlabel (note the "and vice versa").

You can do all the things you can do with route labels, for example use
them in pf filters.

And yes, you could also use it to redistribute them into bgp (although that
needs to happen on another router i think):

 ospfd ---type5 lsa---> ospfd --> fib with rtlabel --> bgpd ...
 hostA  hostB hostBhostB

/Benno

Re: Redistributing between bgpd and ospfd

[Sebastian Benoit]

open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200:
> Hello,
> 
> I am trying to get bgpd and ospfd play nicely with route redistribution.
> 
> So far the only way I have found that suits my need is to use
> bgpd.conf network statements and rtlabels.
> 
> So, to make ospfd learn route from bgpd I use rtlabels. So in bgpd.conf:
> match from  set rtlabel from_bgpd
> 
> And in ospfd.conf:
> redistribute rtlabel from_bgpd
> 
> 
> So far so good. But the other way around, to bake bgpd learn from
> ospfd it becomes a bit more tedious. The only way I have found to make
> bgpd announce ospf originated routes (to its bgp peers) is via network
> statements in bgpd.conf. These network statements are not conditional
> on the availability of such a route in ospf though so they are not
> very dynamic anymore.
> 
> I understand that it according to standard
> (https://tools.ietf.org/html/rfc1364) should be something that is
> explicit for type 1 and 2 LSAs.
> 
> What is the recommended way to achieve dynamic explicit route
> redistribution in both directions?

Network statements are the correct way.

You can use

 network (inet|inet6) priority ...
 network (inet|inet6) rtlabel ...

So with

  network inet priority  32

you should be able to redistribute all ospf routes into bgp.

If this does not help, please explain your problem further (and include your
config).

(Note that you should run OpenBSD 6.4 (just use the latest snapshot) for
this as there was at least a bugfix for route-labels.)