Re: Patch suggestion for sysupgrade

[NilsOla Nilsson]

I have upgraded a machine where /home was NFS-mounted,
like this:
- check that the / partition has space for the files
  that will populate /home/_sysupgrade
- unmount /home
- comment ut the /home line in /etc/fstab
- upgrade with sysupgrade
- restore the line in /etc/fstab
- mount -a

All this could be done remote.

Note that I can log in to a user where the home
directory is not NFS-mounted, in our case
/local_home/

On Thu, Nov 14, 2019 at 03:01:18PM +0100, Raimo Niskanen wrote:
> The use case for this patch is that in our lab network we have NFS
> automounted /home/* directories, so using /home/_sysupgrade
> for sysupgrade does not work.
> 
> With this patch it is easy to modify /usr/sbin/sysupgrade and change
> just the line SETSDIR=/home/_sysupgrade to point to some other local file
> system that is outside hier(7) for example /opt/_sysupgrade
> or /srv/_sysupgrade.
> 
> Even using /var/_sysupgrade or /usr/_sysupgrade should work.  As far as
> I can tell the sysupgrade directory only has to be on a local file system,
> and not get overwritten by the base system install.
> 
> The change for mkdir -p ${SETSDIR} is to make the script more defensive about
> the result of mkdir, e.g in case the umask is wrong, or if the directory
> containing the sysupgrade directory has got the wrong group, etc.
> 
> 
> A follow-up to this patch, should it be accepted, could be to add an option
> -d SysupgradeDir, but I do not know if that would be considered as a too odd
> and error prone feature to merit an option.  Or?
> 
> The patch is on 6.6 stable.
> 
> Index: usr.sbin/sysupgrade/sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.25
> diff -u -u -r1.25 sysupgrade.sh
> --- usr.sbin/sysupgrade/sysupgrade.sh 28 Sep 2019 17:30:07 -  1.25
> +++ usr.sbin/sysupgrade/sysupgrade.sh 14 Nov 2019 13:27:34 -
> @@ -119,6 +119,7 @@
>   URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
>  fi
>  
> +[[ -e ${SETSDIR} ]] || mkdir -p ${SETSDIR}
>  if [[ -e ${SETSDIR} ]]; then
>   eval $(stat -s ${SETSDIR})
>   [[ $st_uid -eq 0 ]] ||
> @@ -127,8 +128,6 @@
>ug_err "${SETSDIR} needs to be owned by root:wheel"
>   [[ $st_mode -eq 040755 ]] || 
>   ug_err "${SETSDIR} is not a directory with permissions 0755"
> -else
> - mkdir -p ${SETSDIR}
>  fi
>  
>  cd ${SETSDIR}
> @@ -185,7 +184,7 @@
>  
>  cat <<__EOT >/auto_upgrade.conf
>  Location of sets = disk
> -Pathname to the sets = /home/_sysupgrade/
> +Pathname to the sets = ${SETSDIR}/
>  Set name(s) = done
>  Directory does not contain SHA256.sig. Continue without verification = yes
>  __EOT
> @@ -193,7 +192,7 @@
>  if ! ${KEEP}; then
>   CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
>   cat <<__EOT > /etc/rc.firsttime
> -rm -f /home/_sysupgrade/{${CLEAN}}
> +rm -f ${SETSDIR}/{${CLEAN}}
>  __EOT
>  fi
> 
> Best regards
> --  
> / Raimo Niskanen, Erlang/OTP, Ericsson AB

-- 
Nils Ola Nilsson, email nils...@abc.se, tel +46-70-374 69 89


signature.asc
Description: PGP signature

Re: [OpenIKED] Network traffic over VPN site-to-site tunnel stalls few times a day

[Stuart Henderson]

On 2019-11-13, radek  wrote:
> After upgrading my two endpoints to i386/6.6 it started to work flawlessly. 
> There wasn't even one IKED restart within first two days of running.
> Thank you Patrick, Stuart and everyone involved in making IKED work as 
> expected. I really appreciate it.

Thanks for the update. The main person to thank for the improvements in iked
between 6.5->6.6 is tobhe@, he has done a lot of work on it in that period.

Re: pfsync on VLAN - supported ?

[Stuart Henderson]

On 2019-11-13, Chris Cappuccio  wrote:
> Rachel Roch [rr...@tutanota.de] wrote:
>> Hi,
>> 
>> Both the man page and FAQ (https://www.openbsd.org/faq/pf/carp.html) 
>>  talk about "physical interface" 
>> in relation to the syncdev parameter.
>> 
>> Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan 
>> interface for pfsync ?
>> 
>
> It's as secure as your ethernet network is. There is no privacy or
> authentication with pfsync. I don't think that using a vlan is 
> considered a big problem these days. I'm absolutely amazed at the
> volume of data that pfsync generates. Since so many boxes come with extra
> ports, using a vlan may be more complicated than directly connecting
> the boxes together (unless you have more than two machines)
>
>

Use jumbos if you can.

Re: OpenIKED: IPv4 traffic over IPv6 tunnel

[Stuart Henderson]

On 2019-11-14, Pulz, Joerg  wrote:
>
> IKEv2 tunnel using OpenIKED between the external IPv6 addresses of both sites.
> IPv4 networks of Site-A should be able to communicate with the IPv4  
> network of Site-B and the other way round through the IKEv2 tunnel.
>
>
> The actual state:
>
> The IKEv2 tunnel is established and all flows and SAs are showing up  
> correctly in 'ipsecctl -s all'.
> If I run a ping on a host in Site-A to another host in Site-B I can  
> see the packets arrive on the internal interface of the  
> OpenIKED/OpenBSD machine. The pinging host in Site-A immediately  
> receives a "Destination Host Unreachable" from the OpenIKED/OpenBSD  
> machine.

OpenBSD uses the classic IPsec style of "flows" which are apart from
the routing table. You need a route table entry covering the packet
destination (even if the gateway is set to a dummy address), otherwise
that packet doesn't make it far enough up the stack for the IPsec flow
to "hijack" it.

Even something like "route add -inet default 127.0.0.1" maybe enough.

Re: Redraw of terminal change in 6.6?

[Hiltjo Posthuma]

On Wed, Nov 13, 2019 at 03:00:05PM +0100, Mischa wrote:
> > On 4 Nov 2019, at 16:51, Mischa  wrote:
> >> On 2 Nov 2019, at 15:19, Hiltjo Posthuma  wrote:
> >> On Sat, Nov 02, 2019 at 08:32:50AM +0100, Mischa wrote:
> >>> Hi All,
> >>> 
> >>> Not sure if this is on my side, setting, or if something has changed with 
> >>> tmux or top redrawing of the terminal.
> >>> I am using tmux, over mosh, on one of my jump hosts to connect to other 
> >>> hosts. In some of the windows I have a remote top -C running.
> >>> When I am attaching the tmux session on a smaller display, for example my 
> >>> phone, the output of top is fine.
> >>> 
> >>> However when I connect back with a larger display the output of top is 
> >>> completely garbled. It does recover line by line when processes jump to a 
> >>> different “rank”.
> >>> 
> >>> Below are two screenshots with roughly 5 minutes between them.
> >>> Anything I can test? Change? Do?
> >>> 
> >>> Thanx!!
> >>> 
> >>> Mischa
> >>> 
> >> 
> >> Hi,
> >> 
> >> Same issue here since upgrading from 6.5 to 6.6.
> >> 
> >> I don't use mosh, but connect via SSH to a remote machine and attaching to 
> >> tmux
> >> running irssi.  It is attached to a shared session. The first attached
> >> resolution/window size is bigger.
> >> 
> >> Maybe it is fixed already:
> >> https://cvsweb.openbsd.org/src/usr.bin/tmux/server-client.c
> >> rev 1.296
> > 
> > Thanx! Will check it out.
> 
> With -current I am still seeing the issue. Anybody else?
> 
> Mischa
> 
> 

Hey Mischa,

Assuming we have the same issue: I have bisected my issue to this commit now:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/tmux/server-client.c.diff?r1=1.293=1.294
server-client.c Revision 1.294, Wed Aug 28 07:34:32 2019 UTC

It can be reproduced now also in a local single tmux session with these steps:

- Start tmux.
- C-b c (new window).
- Start top -C -s 1 in one window.
- Let top refresh one second.
- Switch to the other tmux window.
- Resize the client in some way.
- Wait a second for top to redraw.
- Switch back to the window that is running top.
- The text is not drawn correctly.

In practise this happens for me when irssi redraws its contents in a similar
way.

I'll try to figure out a patch, but can you confirm if reverting this commit
also fixes your issue?

-- 
Kind regards,
Hiltjo

Re: Home NAS

[gwes]

On 11/14/19 3:52 PM, Andrew Luke Nesbit wrote:

Hi Dave,

On 15/11/2019 07:44, Raymond, David wrote:

I hadn't heard about file corruption on OpenBSD.  It would be good to
get to the bottom of this if it occurred.


I was surprised when I read mention of it too, without any real claim 
or detailed analysis to back it up.  This is why I added my disclaimer 
about "correcting me if I'm wrong because I don't want to spread 
incorrect information".


The reason why I brought it up on a public mailing list was to find 
out if anybody else has heard any inkling _at all_ regarding this, 
even a skerrick of a mention.


I have a feeling I may have even heard about it on this list but I'm 
not sure.  If somebody out there genuinely suspects that this happened 
then it would be good to know so we can clear it up.


Kind regards,

Andrew


There was a thread a couple of months ago started by someone either pretty
ignorant or a troll.
The consensus answer: no more than any other OS, less than many.

On 11/14/19, U'll Be King of the Stars  
wrote:


A couple of months ago I read a couple of reports of filesystem
corruption on OpenBSD.  I didn't have time to investigate deeply and I
don't know if these issues were even real.  Even if they were real I
don't know if the problem was due to user error or a defect in the OS.

This is an excellent reason for implementing a system that includes not
only backups, but long term storage /archives/ too.

Andrew

One size definitely doesn't fit all.
Backup strategies depend on user's criteria, cost of design and
cost of doing the backups - administration & storage, etc.

In an ideal world every version of every file lasts forever.
Given real limitations, versioning filesystems can't and don't.

If your data are critical, invest in a dozen or more portable
USB drives. Cycle them off-site. Reread them (not too often)
to check for decay. If you have much  available, get a
modern tape system.

The backup system used over 50 years ago still suitable for many
circumstances looks something like this:
  daily backups held for 1 month
  weekly backups held for 6-12 months
  monthly backups held indefinitely offsite.
Hold times vary according to circumstances.

The backup(8) program can assist this by storing deltas so that
more frequent backups only contain deltas from the previous
less frequent backup.

The compromise between backup storage requirements and granularity
of recovery points can be mitigated. The way to do it depends on
the type and structure of the data:

Some data are really transient and can be left out.

Source code control systems (or whatever the name is this week)
are a good way for intermittent backups to capture a good history
of whatever data is around if it's text.

DBs often have their own built-in backup mechanisms.

Binary files can be regenerated if the source *and* environment
are backed up.

Etc.

YMMV and MEGO
geoff steckel
been there, mounted the wrong tape... what write protect ring?

Re: Home NAS

[Jon Tabor]

I'm running a small home NAS on OpenBSD, in a very similar configuration
as your intended configuration, right down to the rsync backup scripts.
It's worked very well so far, though I've only had it in place for a bit
over a year.

I chose OpenBSD over FreeBSD due to being far more comfortable with
OpenBSD than FreeBSD, and my desire to run my favorite OS in a
meaningful way.

I say go for it, and (like all systems) make sure your backups are good
(that means test them periodically).

-- 
Jon Tabor
tab...@obsolete.site

"I desire peace. I also *require* freedom. Not only for myself, but for Earth. 
If it can be achieved through peaceful ends, wonderful. War is waste. However, 
the only thing worse than war is the loss of liberty."
-John Ringo, _The Hot Gate_

Re: Home NAS

[Andrew Luke Nesbit]

Hi Dave,

On 15/11/2019 07:44, Raymond, David wrote:

I hadn't heard about file corruption on OpenBSD.  It would be good to
get to the bottom of this if it occurred.


I was surprised when I read mention of it too, without any real claim or 
detailed analysis to back it up.  This is why I added my disclaimer 
about "correcting me if I'm wrong because I don't want to spread 
incorrect information".


The reason why I brought it up on a public mailing list was to find out 
if anybody else has heard any inkling _at all_ regarding this, even a 
skerrick of a mention.


I have a feeling I may have even heard about it on this list but I'm not 
sure.  If somebody out there genuinely suspects that this happened then 
it would be good to know so we can clear it up.


Kind regards,

Andrew


On 11/14/19, U'll Be King of the Stars  wrote:

On 15/11/2019 04:45, Raymond, David wrote:

I have done similar things on Linux for years and am now doing them on
OpenBSD.  Sounds like what you want to do can be done with a simple
rsync script.  OpenBSD ffs (ufs) should be stable, it has been around
for decades in various incarnations.  I have never noticed bit rot in
this system, though I imagine it could happen if a disk is gradually
going bad.


Please correct me if I'm wrong because I don't want to spread incorrect
information.

A couple of months ago I read a couple of reports of filesystem
corruption on OpenBSD.  I didn't have time to investigate deeply and I
don't know if these issues were even real.  Even if they were real I
don't know if the problem was due to user error or a defect in the OS.

Does anybody know anything about this?


That's why multiple backups help.


Agreed.  See below.


You might want to set
up a raid5 backup, as this detects parity errors.  More complicated
though.


This is exactly the kind of reason that hybrid volume management systems
+ filesystems such as Btrfs and ZFS have become popular.

I do not know anything about OpenBSD's LVM.


One weakness in such as system (ask me how I know!) is that
if the NAS goes gradually bad, the errors will propagate to the
backup.  Using rsync without the --delete option most of the time
alleviates this somewhat.  Only run with --delete when the backup
starts getting full and you are confident that your NAS drive is ok.


This is an excellent reason for implementing a system that includes not
only backups, but long term storage /archives/ too.

Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9






--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Re: Home NAS

[Raymond, David]

Andrew,

I hadn't heard about file corruption on OpenBSD.  It would be good to
get to the bottom of this if it occurred.

Dave

On 11/14/19, U'll Be King of the Stars  wrote:
> On 15/11/2019 04:45, Raymond, David wrote:
>> I have done similar things on Linux for years and am now doing them on
>> OpenBSD.  Sounds like what you want to do can be done with a simple
>> rsync script.  OpenBSD ffs (ufs) should be stable, it has been around
>> for decades in various incarnations.  I have never noticed bit rot in
>> this system, though I imagine it could happen if a disk is gradually
>> going bad.
>
> Please correct me if I'm wrong because I don't want to spread incorrect
> information.
>
> A couple of months ago I read a couple of reports of filesystem
> corruption on OpenBSD.  I didn't have time to investigate deeply and I
> don't know if these issues were even real.  Even if they were real I
> don't know if the problem was due to user error or a defect in the OS.
>
> Does anybody know anything about this?
>
>> That's why multiple backups help.
>
> Agreed.  See below.
>
>> You might want to set
>> up a raid5 backup, as this detects parity errors.  More complicated
>> though.
>
> This is exactly the kind of reason that hybrid volume management systems
> + filesystems such as Btrfs and ZFS have become popular.
>
> I do not know anything about OpenBSD's LVM.
>
>> One weakness in such as system (ask me how I know!) is that
>> if the NAS goes gradually bad, the errors will propagate to the
>> backup.  Using rsync without the --delete option most of the time
>> alleviates this somewhat.  Only run with --delete when the backup
>> starts getting full and you are confident that your NAS drive is ok.
>
> This is an excellent reason for implementing a system that includes not
> only backups, but long term storage /archives/ too.
>
> Andrew
> --
> OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9
>


-- 
David J. Raymond
david.raym...@nmt.edu
http://physics.nmt.edu/~raymond

Re: Home NAS

[U'll Be King of the Stars]

On 15/11/2019 04:45, Raymond, David wrote:

I have done similar things on Linux for years and am now doing them on
OpenBSD.  Sounds like what you want to do can be done with a simple
rsync script.  OpenBSD ffs (ufs) should be stable, it has been around
for decades in various incarnations.  I have never noticed bit rot in
this system, though I imagine it could happen if a disk is gradually
going bad.


Please correct me if I'm wrong because I don't want to spread incorrect 
information.


A couple of months ago I read a couple of reports of filesystem 
corruption on OpenBSD.  I didn't have time to investigate deeply and I 
don't know if these issues were even real.  Even if they were real I 
don't know if the problem was due to user error or a defect in the OS.


Does anybody know anything about this?


That's why multiple backups help.


Agreed.  See below.


You might want to set
up a raid5 backup, as this detects parity errors.  More complicated
though.


This is exactly the kind of reason that hybrid volume management systems 
+ filesystems such as Btrfs and ZFS have become popular.


I do not know anything about OpenBSD's LVM.


One weakness in such as system (ask me how I know!) is that
if the NAS goes gradually bad, the errors will propagate to the
backup.  Using rsync without the --delete option most of the time
alleviates this somewhat.  Only run with --delete when the backup
starts getting full and you are confident that your NAS drive is ok.


This is an excellent reason for implementing a system that includes not 
only backups, but long term storage /archives/ too.


Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Re: aggr vs Nexus 3K

[Szél Gábor]

Sorry!, I was not attentive.

in earlier oBSD versions, i think it was not necessary "up" in 
hostname.* configuration file when interface have IP address.

if I add it to hostname.aggr0:
trunkport oce0 trunkport oce1 172.20.253.12 netmask 255.255.255.255 
description "." up


LACP trunk is working!

but interesting! hostname.trunk* is working without up! :)

--
Üdvözlettel,
Szél Gábor

WanTax Kft.

tel.: +36 20 3838 171
fax: +36 82 357 585
email: gabor.s...@wantax.hu
web: http://wantax.hu
web: http://halozatom.hu



2019. 11. 14. 17:45 keltezéssel, Szél Gábor írta:

Yes of course! :)

if aggr up, Nexus suspend port channel:
"not receiving any LACP BPDUs  suspending"

If trunk up, nexus not suspend port channel.
--
Üdvözlettel,
Szél Gábor

WanTax Kft.

tel.: +36 20 3838 171
fax: +36 82 357 585
email:gabor.s...@wantax.hu
web:http://wantax.hu
web:http://halozatom.hu


2019. 11. 14. 17:35 keltezéssel, hrv...@srce.hr írta:

Can you do ifconfig aggr1 up ... Is it active then?




Dana 14. stu 2019. 04:51 PM osoba Szél Gábor  
napisala je:


Dear @misc

We want to try use aggr pseudo LACP device.

We have a working setup with trunk interface:

oBSD: hostname.trunk0
trunkproto lacp trunkport oce0 trunkport oce1 172.20.253.11 netmask
255.255.255.255 description ""


trunk0:
flags=8943 mtu 9000
    lladdr 28:80:23:e0:ab:40
    description: C1 LACP
    index 25 priority 0 llprio 3
    trunk: trunkproto lacp
    trunk id: [(8000,28:80:23:e0:ab:40,40CD,,),
(7F9B,00:23:04:ee:be:0a,8002,,)]
    trunkport oce1 active,collecting,distributing
    trunkport oce0 active,collecting,distributing
    groups: trunk
    media: Ethernet autoselect
    status: active
    inet 172.20.253.11 netmask 0x


Nexus 3K:

Cisco LACP|vPC config is very simple:

interface Ethernet1/2
  description FW2-oce1
  switchport mode trunk
  channel-group 2 mode active

interface port-channel2
  speed 1
  description FW2
  switchport mode trunk
  vpc 2


lacp rate normal


vPC domain id : 10
Peer status   : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status  : success
Per-vlan consistency status   : success
Type-2 consistency status : success
vPC role  : primary
Number of vPCs configured : 8
Peer Gateway  : Disabled
Dual-active excluded VLANs    : -
Graceful Consistency Check    : Enabled
Auto-recovery status  : Disabled

vPC Peer-link status
-

id   Port   Status Active vlans
--      --
--
1    Po99   up 1-2,10,12-13,20,30,40,50-53,60,62,101

vPC status


id Port    Status Consistency Reason Active vlans
-- --- -- --- --
---
2  Po2 up success success 1-2,10,12-1
3,20,30,40,
50-53,60,62
,101

If we change trunk driver to aggr driver:

oBSD: hostname.aggr1
trunkport oce0 trunkport oce1 172.20.253.12 netmask 255.255.255.255
description ""

LACP is not working:

oce0: flags=8843 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    index 1 priority 0 llprio 3
    trunk: trunkdev aggr1
    media: Ethernet autoselect (10GbaseSR
full-duplex,rxpause,txpause)
    status: active
oce1: flags=8843 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    index 2 priority 0 llprio 3
    trunk: trunkdev aggr1
    media: Ethernet autoselect (10GbaseSR
full-duplex,rxpause,txpause)
    status: active


aggr1: flags=8802 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    description: C1 LACP
    index 7 priority 0 llprio 7
    trunk: trunkproto lacp
    trunk id: [(8000,fe:e1:ba:d0:cc:92,0007,,),
         (,00:00:00:00:00:00,,,)]
        oce0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:cc:92, key
0x7, port pri 0x8000 number 0x1
        oce0 lacp actor state activity,aggregation,defaulted
        oce0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key
0x0, port pri 0x0 number 0x0
        oce0 lacp partner state activity,sync
        oce0 port
        oce1 lacp actor system pri 0x8000 mac fe:e1:ba:d0:cc:92, key
0x7, port pri 0x8000 number 0x2
        oce1 lacp actor state activity,aggregation,defaulted
        oce1 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key
0x0, port pri 0x0 number 0x0
  

Re: Home NAS

[Raymond, David]

I have done similar things on Linux for years and am now doing them on
OpenBSD.  Sounds like what you want to do can be done with a simple
rsync script.  OpenBSD ffs (ufs) should be stable, it has been around
for decades in various incarnations.  I have never noticed bit rot in
this system, though I imagine it could happen if a disk is gradually
going bad.  That's why multiple backups help.  You might want to set
up a raid5 backup, as this detects parity errors.  More complicated
though.  One weakness in such as system (ask me how I know!) is that
if the NAS goes gradually bad, the errors will propagate to the
backup.  Using rsync without the --delete option most of the time
alleviates this somewhat.  Only run with --delete when the backup
starts getting full and you are confident that your NAS drive is ok.

Dave

On 11/14/19, Jan Betlach  wrote:
>
> Hi guys,
>
> I am setting up a home NAS for five users. Total amount of data stored
> on NAS will not exceed 5 TB.
> Clients are Macs and OpenBSD machines, so that SSHFS works fine from
> both (no need for NFS or Samba).
> I am much more familiar and comfortable with OpenBSD than with FreeBSD.
> My dilema while stating the above is as follows:
>
> Will the OpenBSD’s UFS stable and reliable enough for intended
> purpose? NAS will consist of just one encrypted drive, regularly backed
> to hardware RAID encrypted two-disks drive via rsync.
>
> Should I byte the bullet and build the NAS on FreeBSD taking advantage
> of ZFS, snapshots, replications, etc? Or is this an overkill?
>
> BTW my most important data is also backed off-site.
>
> Thank you in advance for your comments.
>
> Jan
>
>


-- 
David J. Raymond
david.raym...@nmt.edu
http://physics.nmt.edu/~raymond

Re: Patch suggestion for sysupgrade

[gilles]

A similar patch for this was sent to tech@ by Renaud Allard, you might want to
go review the "sysupgrade: Allow to use another directory for data sets" thread
and comment it.


November 14, 2019 3:01 PM, "Raimo Niskanen"  
wrote:

> The use case for this patch is that in our lab network we have NFS
> automounted /home/* directories, so using /home/_sysupgrade
> for sysupgrade does not work.
> 
> With this patch it is easy to modify /usr/sbin/sysupgrade and change
> just the line SETSDIR=/home/_sysupgrade to point to some other local file
> system that is outside hier(7) for example /opt/_sysupgrade
> or /srv/_sysupgrade.
> 
> Even using /var/_sysupgrade or /usr/_sysupgrade should work. As far as
> I can tell the sysupgrade directory only has to be on a local file system,
> and not get overwritten by the base system install.
> 
> The change for mkdir -p ${SETSDIR} is to make the script more defensive about
> the result of mkdir, e.g in case the umask is wrong, or if the directory
> containing the sysupgrade directory has got the wrong group, etc.
> 
> A follow-up to this patch, should it be accepted, could be to add an option
> -d SysupgradeDir, but I do not know if that would be considered as a too odd
> and error prone feature to merit an option. Or?
> 
> The patch is on 6.6 stable.
> 
> Index: usr.sbin/sysupgrade/sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.25
> diff -u -u -r1.25 sysupgrade.sh
> --- usr.sbin/sysupgrade/sysupgrade.sh 28 Sep 2019 17:30:07 - 1.25
> +++ usr.sbin/sysupgrade/sysupgrade.sh 14 Nov 2019 13:27:34 -
> @@ -119,6 +119,7 @@
> URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
> fi
> 
> +[[ -e ${SETSDIR} ]] || mkdir -p ${SETSDIR}
> if [[ -e ${SETSDIR} ]]; then
> eval $(stat -s ${SETSDIR})
> [[ $st_uid -eq 0 ]] ||
> @@ -127,8 +128,6 @@
> ug_err "${SETSDIR} needs to be owned by root:wheel"
> [[ $st_mode -eq 040755 ]] || 
> ug_err "${SETSDIR} is not a directory with permissions 0755"
> -else
> - mkdir -p ${SETSDIR}
> fi
> 
> cd ${SETSDIR}
> @@ -185,7 +184,7 @@
> 
> cat <<__EOT >/auto_upgrade.conf
> Location of sets = disk
> -Pathname to the sets = /home/_sysupgrade/
> +Pathname to the sets = ${SETSDIR}/
> Set name(s) = done
> Directory does not contain SHA256.sig. Continue without verification = yes
> __EOT
> @@ -193,7 +192,7 @@
> if ! ${KEEP}; then
> CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
> cat <<__EOT > /etc/rc.firsttime
> -rm -f /home/_sysupgrade/{${CLEAN}}
> +rm -f ${SETSDIR}/{${CLEAN}}
> __EOT
> fi
> 
> Best regards
> -- 
> / Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: SPAM: Re: aggr vs Nexus 3K

[Szél Gábor]

Yes of course! :)

if aggr up, Nexus suspend port channel:
"not receiving any LACP BPDUs  suspending"

If trunk up, nexus not suspend port channel.

--
Üdvözlettel,
Szél Gábor

WanTax Kft.

tel.: +36 20 3838 171
fax: +36 82 357 585
email: gabor.s...@wantax.hu
web: http://wantax.hu
web: http://halozatom.hu



2019. 11. 14. 17:35 keltezéssel, hrv...@srce.hr írta:

Can you do ifconfig aggr1 up ... Is it active then?




Dana 14. stu 2019. 04:51 PM osoba Szél Gábor  
napisala je:


Dear @misc

We want to try use aggr pseudo LACP device.

We have a working setup with trunk interface:

oBSD: hostname.trunk0
trunkproto lacp trunkport oce0 trunkport oce1 172.20.253.11 netmask
255.255.255.255 description ""


trunk0: flags=8943
mtu 9000
    lladdr 28:80:23:e0:ab:40
    description: C1 LACP
    index 25 priority 0 llprio 3
    trunk: trunkproto lacp
    trunk id: [(8000,28:80:23:e0:ab:40,40CD,,),
(7F9B,00:23:04:ee:be:0a,8002,,)]
    trunkport oce1 active,collecting,distributing
    trunkport oce0 active,collecting,distributing
    groups: trunk
    media: Ethernet autoselect
    status: active
    inet 172.20.253.11 netmask 0x


Nexus 3K:

Cisco LACP|vPC config is very simple:

interface Ethernet1/2
  description FW2-oce1
  switchport mode trunk
  channel-group 2 mode active

interface port-channel2
  speed 1
  description FW2
  switchport mode trunk
  vpc 2


lacp rate normal


vPC domain id : 10
Peer status   : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status  : success
Per-vlan consistency status   : success
Type-2 consistency status : success
vPC role  : primary
Number of vPCs configured : 8
Peer Gateway  : Disabled
Dual-active excluded VLANs    : -
Graceful Consistency Check    : Enabled
Auto-recovery status  : Disabled

vPC Peer-link status
-
id   Port   Status Active vlans
--      -- --
1    Po99   up 1-2,10,12-13,20,30,40,50-53,60,62,101

vPC status


id Port    Status Consistency Reason Active vlans
-- --- -- --- --
---
2  Po2 up success success 1-2,10,12-1
3,20,30,40,
50-53,60,62
,101

If we change trunk driver to aggr driver:

oBSD: hostname.aggr1
trunkport oce0 trunkport oce1 172.20.253.12 netmask 255.255.255.255
description ""

LACP is not working:

oce0: flags=8843 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    index 1 priority 0 llprio 3
    trunk: trunkdev aggr1
    media: Ethernet autoselect (10GbaseSR
full-duplex,rxpause,txpause)
    status: active
oce1: flags=8843 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    index 2 priority 0 llprio 3
    trunk: trunkdev aggr1
    media: Ethernet autoselect (10GbaseSR
full-duplex,rxpause,txpause)
    status: active


aggr1: flags=8802 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    description: C1 LACP
    index 7 priority 0 llprio 7
    trunk: trunkproto lacp
    trunk id: [(8000,fe:e1:ba:d0:cc:92,0007,,),
         (,00:00:00:00:00:00,,,)]
        oce0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:cc:92, key
0x7, port pri 0x8000 number 0x1
        oce0 lacp actor state activity,aggregation,defaulted
        oce0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key
0x0, port pri 0x0 number 0x0
        oce0 lacp partner state activity,sync
        oce0 port
        oce1 lacp actor system pri 0x8000 mac fe:e1:ba:d0:cc:92, key
0x7, port pri 0x8000 number 0x2
        oce1 lacp actor state activity,aggregation,defaulted
        oce1 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key
0x0, port pri 0x0 number 0x0
        oce1 lacp partner state activity,sync
        oce1 port
    groups: aggr
    media: Ethernet autoselect
    status: no carrier
    inet 172.20.253.12 netmask 0x

N3K logs:
2019 Nov 14 15:28:16 s1b %ETHPORT-5-SPEED: Interface Ethernet1/2,
operational speed changed to 10 Gbps
2019 Nov 14 15:28:16 s1b %ETHPORT-5-IF_DUPLEX: Interface Ethernet1/2,
operational duplex mode changed to Full
2019 Nov 14 15:28:16 s1b %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface
Ethernet1/2, operational Receive Flow Control state changed to off
2019 

Re: Home NAS

[Roderick]

On Thu, 14 Nov 2019, Jan Betlach wrote:

Should I byte the bullet and build the NAS on FreeBSD taking advantage of 
ZFS, snapshots, replications, etc? Or is this an overkill?


I built my "NAS" with FreeBSD due to the self healing properties of
ZFS with checksums and redundant data, and due to the fact that
ZFS became more or less a standard that run in many OS and will not
be forgotten from one day to other.

But I am unhappy with ZFS, it is too heavy and complicated for my
purpose, do not pass to the unix environement, and my use is for less
than NAS, "only" for archival purposes. But I do not see at the
moment a simple alternative that fulfill my expectations.

Rodrigo

aggr vs Nexus 3K

[Szél Gábor]

Dear @misc

We want to try use aggr pseudo LACP device.

We have a working setup with trunk interface:

oBSD: hostname.trunk0
trunkproto lacp trunkport oce0 trunkport oce1 172.20.253.11 netmask 
255.255.255.255 description ""



trunk0: flags=8943 mtu 9000
    lladdr 28:80:23:e0:ab:40
    description: C1 LACP
    index 25 priority 0 llprio 3
    trunk: trunkproto lacp
    trunk id: [(8000,28:80:23:e0:ab:40,40CD,,),
 (7F9B,00:23:04:ee:be:0a,8002,,)]
    trunkport oce1 active,collecting,distributing
    trunkport oce0 active,collecting,distributing
    groups: trunk
    media: Ethernet autoselect
    status: active
    inet 172.20.253.11 netmask 0x


Nexus 3K:

Cisco LACP|vPC config is very simple:

interface Ethernet1/2
  description FW2-oce1
  switchport mode trunk
  channel-group 2 mode active

interface port-channel2
  speed 1
  description FW2
  switchport mode trunk
  vpc 2


lacp rate normal


vPC domain id : 10
Peer status   : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status  : success
Per-vlan consistency status   : success
Type-2 consistency status : success
vPC role  : primary
Number of vPCs configured : 8
Peer Gateway  : Disabled
Dual-active excluded VLANs    : -
Graceful Consistency Check    : Enabled
Auto-recovery status  : Disabled

vPC Peer-link status
-
id   Port   Status Active vlans
--      -- --
1    Po99   up 1-2,10,12-13,20,30,40,50-53,60,62,101

vPC status

id Port    Status Consistency Reason Active vlans
-- --- -- --- -- ---
2  Po2 up success success 1-2,10,12-1
3,20,30,40,
50-53,60,62
,101

If we change trunk driver to aggr driver:

oBSD: hostname.aggr1
trunkport oce0 trunkport oce1 172.20.253.12 netmask 255.255.255.255 
description ""


LACP is not working:

oce0: flags=8843 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    index 1 priority 0 llprio 3
    trunk: trunkdev aggr1
    media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause)
    status: active
oce1: flags=8843 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    index 2 priority 0 llprio 3
    trunk: trunkdev aggr1
    media: Ethernet autoselect (10GbaseSR full-duplex,rxpause,txpause)
    status: active


aggr1: flags=8802 mtu 1500
    lladdr fe:e1:ba:d0:cc:92
    description: C1 LACP
    index 7 priority 0 llprio 7
    trunk: trunkproto lacp
    trunk id: [(8000,fe:e1:ba:d0:cc:92,0007,,),
         (,00:00:00:00:00:00,,,)]
        oce0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:cc:92, key 
0x7, port pri 0x8000 number 0x1

        oce0 lacp actor state activity,aggregation,defaulted
        oce0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 
0x0, port pri 0x0 number 0x0

        oce0 lacp partner state activity,sync
        oce0 port
        oce1 lacp actor system pri 0x8000 mac fe:e1:ba:d0:cc:92, key 
0x7, port pri 0x8000 number 0x2

        oce1 lacp actor state activity,aggregation,defaulted
        oce1 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 
0x0, port pri 0x0 number 0x0

        oce1 lacp partner state activity,sync
        oce1 port
    groups: aggr
    media: Ethernet autoselect
    status: no carrier
    inet 172.20.253.12 netmask 0x

N3K logs:
2019 Nov 14 15:28:16 s1b %ETHPORT-5-SPEED: Interface Ethernet1/2, 
operational speed changed to 10 Gbps
2019 Nov 14 15:28:16 s1b %ETHPORT-5-IF_DUPLEX: Interface Ethernet1/2, 
operational duplex mode changed to Full
2019 Nov 14 15:28:16 s1b %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface 
Ethernet1/2, operational Receive Flow Control state changed to off
2019 Nov 14 15:28:16 s1b %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface 
Ethernet1/2, operational Transmit Flow Control state changed to off
2019 Nov 14 15:28:16 s1b %ETHPORT-5-SPEED: Interface port-channel1, 
operational speed changed to 10 Gbps
2019 Nov 14 15:28:16 s1b %ETHPORT-5-IF_DUPLEX: Interface port-channel1, 
operational duplex mode changed to Full
2019 Nov 14 15:28:16 s1b %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface 
port-channel1, operational Receive Flow Control state changed to off
2019 Nov 14 15:28:16 s1b %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface 
port-channel1, operational Transmit Flow Control state changed to off
2019 Nov 14 15:28:26 s1b %LACP-5-LACP_SUSPEND_INDIVIDUAL: LACP port 
Ethernet1/2(0x1a00) of port-channel port-channel1(0x1600) not 
receiving any LACP BPDUs  suspending (individual) port


LACP interface status:
Interface Ethernet1/2 is individual
  Channel group is 1 port 

Re: Home NAS

[Eduardo Minguez Perez]

On Thu, Nov 14, 2019 at 3:29 PM Jan Betlach  wrote:

>
> Hi guys,
>
> I am setting up a home NAS for five users. Total amount of data stored
> on NAS will not exceed 5 TB.
> Clients are Macs and OpenBSD machines, so that SSHFS works fine from
> both (no need for NFS or Samba).
> I am much more familiar and comfortable with OpenBSD than with FreeBSD.
> My dilema while stating the above is as follows:
>
> Will the OpenBSD’s UFS stable and reliable enough for intended
> purpose? NAS will consist of just one encrypted drive, regularly backed
> to hardware RAID encrypted two-disks drive via rsync.
>
> Should I byte the bullet and build the NAS on FreeBSD taking advantage
> of ZFS, snapshots, replications, etc? Or is this an overkill?
>
> BTW my most important data is also backed off-site.
>
> Thank you in advance for your comments.
>
>
See https://www.vincentdelft.be/post/post_20190203 (slides here
https://www.vincentdelft.be/static/post/post_20190203/openbsd-as-nas.pdf and
video recording here
https://archive.fosdem.org/2019/schedule/event/openbsd_nas_system/ )


> Jan
>
>

-- 
eduardominguez.es

Home NAS

[Jan Betlach]

Hi guys,

I am setting up a home NAS for five users. Total amount of data stored 
on NAS will not exceed 5 TB.
Clients are Macs and OpenBSD machines, so that SSHFS works fine from 
both (no need for NFS or Samba).

I am much more familiar and comfortable with OpenBSD than with FreeBSD.
My dilema while stating the above is as follows:

Will the OpenBSD’s UFS stable and reliable enough for intended 
purpose? NAS will consist of just one encrypted drive, regularly backed 
to hardware RAID encrypted two-disks drive via rsync.


Should I byte the bullet and build the NAS on FreeBSD taking advantage 
of ZFS, snapshots, replications, etc? Or is this an overkill?


BTW my most important data is also backed off-site.

Thank you in advance for your comments.

Jan

Patch suggestion for sysupgrade

[Raimo Niskanen]

The use case for this patch is that in our lab network we have NFS
automounted /home/* directories, so using /home/_sysupgrade
for sysupgrade does not work.

With this patch it is easy to modify /usr/sbin/sysupgrade and change
just the line SETSDIR=/home/_sysupgrade to point to some other local file
system that is outside hier(7) for example /opt/_sysupgrade
or /srv/_sysupgrade.

Even using /var/_sysupgrade or /usr/_sysupgrade should work.  As far as
I can tell the sysupgrade directory only has to be on a local file system,
and not get overwritten by the base system install.

The change for mkdir -p ${SETSDIR} is to make the script more defensive about
the result of mkdir, e.g in case the umask is wrong, or if the directory
containing the sysupgrade directory has got the wrong group, etc.


A follow-up to this patch, should it be accepted, could be to add an option
-d SysupgradeDir, but I do not know if that would be considered as a too odd
and error prone feature to merit an option.  Or?

The patch is on 6.6 stable.

Index: usr.sbin/sysupgrade/sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.25
diff -u -u -r1.25 sysupgrade.sh
--- usr.sbin/sysupgrade/sysupgrade.sh   28 Sep 2019 17:30:07 -  1.25
+++ usr.sbin/sysupgrade/sysupgrade.sh   14 Nov 2019 13:27:34 -
@@ -119,6 +119,7 @@
URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
 fi
 
+[[ -e ${SETSDIR} ]] || mkdir -p ${SETSDIR}
 if [[ -e ${SETSDIR} ]]; then
eval $(stat -s ${SETSDIR})
[[ $st_uid -eq 0 ]] ||
@@ -127,8 +128,6 @@
 ug_err "${SETSDIR} needs to be owned by root:wheel"
[[ $st_mode -eq 040755 ]] || 
ug_err "${SETSDIR} is not a directory with permissions 0755"
-else
-   mkdir -p ${SETSDIR}
 fi
 
 cd ${SETSDIR}
@@ -185,7 +184,7 @@
 
 cat <<__EOT >/auto_upgrade.conf
 Location of sets = disk
-Pathname to the sets = /home/_sysupgrade/
+Pathname to the sets = ${SETSDIR}/
 Set name(s) = done
 Directory does not contain SHA256.sig. Continue without verification = yes
 __EOT
@@ -193,7 +192,7 @@
 if ! ${KEEP}; then
CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
cat <<__EOT > /etc/rc.firsttime
-rm -f /home/_sysupgrade/{${CLEAN}}
+rm -f ${SETSDIR}/{${CLEAN}}
 __EOT
 fi

Best regards
--  
/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: pfsync on VLAN - supported ?

[Rachel Roch]

14 Nov 2019, 11:21 by liste...@wernig.net:

> On 14.11.2019 11:30, Rachel Roch wrote:
>
 Does this mean Bad Things (TM) will happen if I try to use a dedicated 
 vlan interface for pfsync ?

> I have had pfsync running happily over a vlan interface for years, never
> a problem.
>
>> Regarding the extra port, in my case I'm using that for LACP (my switches 
>> support distributed LACP, so i can have two cables going into two switches)
>>
> Having the sync port physically redundant and connected to a switch is a
> very good idea, because a crossover cable will cause a carp demote
> whenever the other firewall goes down or is rebooted, afair.
>
> best /m
>

Regarding your last point, if your recollection is correct, then surely it is 
something the powers that be should consider adding to the FAQ and man pages 
forthwith ? It seems to me like a rather important thing to know.  ;-)

Thanks for your input, much appreciated.

Re: pfsync on VLAN - supported ?

[Markus Wernig]

On 14.11.2019 11:30, Rachel Roch wrote:
>>> Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan 
>>> interface for pfsync ?
I have had pfsync running happily over a vlan interface for years, never
a problem.

> Regarding the extra port, in my case I'm using that for LACP (my switches 
> support distributed LACP, so i can have two cables going into two switches)
Having the sync port physically redundant and connected to a switch is a
very good idea, because a crossover cable will cause a carp demote
whenever the other firewall goes down or is rebooted, afair.

best /m

Re: random packet drops with syncookies/synproxy

[Markus Wernig]

On 09.11.2019 15:24, Claudio Jeker wrote:

>> So nobody is using syncookies/synproxy at all?
> 
> I guess that is a reasonably safe assumption. syncookies are rather new
> and probably need more battle testing.

OK, then I will send a bug report.

> synproxy never helped me much in
> case of a SYN attack since it will cause pf(4) to hit the state limit no
> matter what you do and then stuff starts to break.

Yes, synproxy will not help with that, but syncookies should. But the
syncookies entry in the man page also states that a connection opened
via syncookie will then run through synproxy, so the problem I'm seeing
might be in either one.

best /

Re: urtwn(4) gets wedged periodically

[Roderick]

On Wed, 13 Nov 2019, Theo de Raadt wrote:


The mailing lists are full of discussions of bugs in usb.


This could explain, why devices that have problems in OpenBSD have
no problem in FreeBSD, although they ported the driver from OpenBSD.


But no, let's keep concluding these problems is narrowly restricted
to a specific brand of device...


But there is indeed diferences on brands. And I have run(4) devices
that works and other that do not work.

Rodrigo.

Re: pfsync on VLAN - supported ?

[Rachel Roch]

13 Nov 2019, 20:21 by ch...@nmedia.net:

> Rachel Roch [rr...@tutanota.de] wrote:
>
>> Hi,
>>
>> Both the man page and FAQ (https://www.openbsd.org/faq/pf/carp.html) 
>>  talk about "physical interface" 
>> in relation to the syncdev parameter.
>>
>> Does this mean Bad Things (TM) will happen if I try to use a dedicated vlan 
>> interface for pfsync ?
>>
>
> It's as secure as your ethernet network is. There is no privacy or
> authentication with pfsync. I don't think that using a vlan is 
> considered a big problem these days. I'm absolutely amazed at the
> volume of data that pfsync generates. Since so many boxes come with extra
> ports, using a vlan may be more complicated than directly connecting
> the boxes together (unless you have more than two machines)
>

Thanks Chris !

Regarding the extra port, in my case I'm using that for LACP (my switches 
support distributed LACP, so i can have two cables going into two switches)

Re: syspatch -c (amd64) ftp: connect: Permission denied

[Dimitrios Moustos]

Hello Strahil,

I get this very often when pf does not allow traffic out.
First check that pf allows traffic out.

Hope it helps, Dimitrios

On Wed, Nov 13, 2019 at 10:51:45PM +, Strahil Nikolov wrote:
> Hello Community,
> 
> it seems that syspatch and pkg_add are having an issue with 'ftp: connect: 
> Permission denied'.
> System is 6.5 and access via ftp (based on my automatic syspatch script) has 
> seized on 03 Nov 2019.
> /etc/installurl is pointing to https://cdn.openbsd.org/pub/OpenBSD/ 
> 
> Is syspatch working for you ?
> 
> 
> Thanks in advance.
> 
> Best Regards,
> Strahil Nikolov
> 

OpenIKED: IPv4 traffic over IPv6 tunnel

[Pulz, Joerg]

Hi,

I'm trying to connect IPv4 networks over an IPv6 tunnel using OpenIKED  
without success.


Here a short overview:

Site-A:
- several IPv4 networks
- OpenIKED (OpenBSD 6.5) on a multihomed host, internal IPv4 address,  
external IPv6 address


Site-B:
- one IPv4 network
- Cisco something (not under my control), external IPv6 address

IKEv2 tunnel using OpenIKED between the external IPv6 addresses of both sites.
IPv4 networks of Site-A should be able to communicate with the IPv4  
network of Site-B and the other way round through the IKEv2 tunnel.



The actual state:

The IKEv2 tunnel is established and all flows and SAs are showing up  
correctly in 'ipsecctl -s all'.
If I run a ping on a host in Site-A to another host in Site-B I can  
see the packets arrive on the internal interface of the  
OpenIKED/OpenBSD machine. The pinging host in Site-A immediately  
receives a "Destination Host Unreachable" from the OpenIKED/OpenBSD  
machine.
If I listen on 'enc0' to see the packets traveling through the tunnel  
nothing appears at all.
It seems that the flows are not correctly evaluated so the  
OpenIKED/OpenBSD machine has no route to the destination host/network.



Testing:

If both sites use IPv4 addresses on the external interface to  
establish the IKEv2 tunnel, everything is working as expected without  
changing the configuration beside the IP address relevant parts.



Question:

Is the above scenario, routing IPv4 networks over IPv6-only IKEv2  
tunnel. supported at all?

Am I hitting some sort of bug?
Am I missing something in my configuration?

Kind regards
Joerg


smime.p7s
Description: S/MIME Signature

Re: Questions regarding unwind.conf (block list)

[Raf Czlonka]

On Wed, Nov 13, 2019 at 11:14:11PM GMT, Felix Maschek wrote:
> Hi,
> 
> I'm using unwind for a time and it is running perfect for me.
> 
> Now with the upcoming new plugin api of chrome with limited support for
> uBlock I'm looking for an alternative.
> 
> Unfortunately I'm not able to specify a valid block list in unwind.conf.
> I've added
> 
>     block list /etc/unwind.blocklist
> 
> My blocklist file contains (for testing purpose)
> 
>     heise.de
>     stern.de
> 
> But there seems to be a syntax error I can't solve. In the log I have the
> following entries:
> 
>     Nov 14 00:09:29 vatrox unwind[52933]: /etc/unwind.conf:4: syntax error
>     Nov 14 00:09:29 vatrox unwind[52933]: configuration reload failed
> 
> So, what is wrong here?
> 
> And a follow-up question: is it possible to load a huge blocklist (with, say
> 200.000) entries to replace the blocking within chrome?
> 
> Kind regards
> 
> Felix
> 

Hi Felix,

I find this to be a fairly common syntax in OpenBSD - if you get
this type of error message, double-quote file/directory paths.

block list "/etc/unwind.blocklist"

works just fine.

Regards,

Raf

Re: syspatch -c (amd64) ftp: connect: Permission denied

[Strahil Nikolov]

On November 14, 2019 11:04:15 AM GMT+02:00, Dimitrios Moustos 
 wrote:
>Hello Strahil,
>
>I get this very often when pf does not allow traffic out.
>First check that pf allows traffic out.
>
>Hope it helps, Dimitrios
>
>On Wed, Nov 13, 2019 at 10:51:45PM +, Strahil Nikolov wrote:
>> Hello Community,
>> 
>> it seems that syspatch and pkg_add are having an issue with 'ftp:
>connect: Permission denied'.
>> System is 6.5 and access via ftp (based on my automatic syspatch
>script) has seized on 03 Nov 2019.
>> /etc/installurl is pointing to https://cdn.openbsd.org/pub/OpenBSD/ 
>> 
>> Is syspatch working for you ?
>> 
>> 
>> Thanks in advance.
>> 
>> Best Regards,
>> Strahil Nikolov
>> 

Thanks Dimitrios,

I will check it out as this is my 'PF' learning lab... I might have messed the 
stuff last time.

Best Regards,
Strahil Nikolov

Re: urtwn(4) gets wedged periodically

[Stefan Sperling]

On Wed, Nov 13, 2019 at 12:30:23PM -0700, Theo de Raadt wrote:
> These are usb devices.  There are multiple usb bus drivers, with
> usb2 and usb3 variations, and the usb subsystem itself.  The mailing
> lists are full of discussions of bugs in usb.
> 
> But no, let's keep concluding these problems is narrowly restricted
> to a specific brand of device...

I have given up on trying to figure out non-obvious bugs in USB wifi
drivers for this reason. We need someone to look into USB issues in
order to make progress on the various hangs and power consumption
problems people have been reporting against drivers such as urtwn(4).

Granted, there could always be a bug in the wifi driver, but not having
reliable USB drivers beneath does not exactly help with debugging.

xhci(4) has problems on certain host controller models for instance.
We don't even have all the quirks and workarounds which other operating
systems apply to various host controller chipsets in our xhci(4) driver.
And then there are bugs specific to our implementation, such as this one
which was recently discovered by gerhard@:
https://marc.info/?l=openbsd-tech=157355206323832=2
We need more research into this area of bugs but we don't currently have
people who do it.

I also believe that bus power management in xhci(4) and ehci(4) is broken.
I cannot prove it, but it would be great if somebody looked into this to
find answers. athn(4) on USB seems to be suffering from something like this.