Re: How do you do "family remote support"?

[Rupert Gallagher]

Never heard of port mapping on modem/routers?
Sent from ProtonMail Mobile

On Tue, Jul 11, 2017 at 11:33 PM, Kurt H Maier  wrote:

> On Tue, Jul 11, 2017 at 05:22:29PM -0400, Rupert Gallagher wrote: > Never 
> heard of whatismyip.org? > Sent from ProtonMail Mobile Never heard of NAT? 
> Sent from QMail Stationary

Re: How do you do "family remote support"?

[Sean Kamath]

> On Jul 11, 2017, at 2:42 PM, Niels Kobschätzki  wrote:
> 
> 
>> On 11. Jul 2017, at 23:33, Kurt H Maier  wrote:
>> 
>>> On Tue, Jul 11, 2017 at 05:22:29PM -0400, Rupert Gallagher wrote:
>>> Never heard of whatismyip.org?
>>> Sent from ProtonMail Mobile
>> 
>> Never heard of NAT?
> 
> Thank you all. I will probably get them into an OpenVPN-network and since 
> there are nice GUIs available on the Mac for that, they should be able to 
> connect (or I try to implement a launchd-service). I can give them always the 
> same IP and do not even have to check for that then. And then I use VNC with 
> the built-in VNC-server from MacOS.
> 
> Thanks again,
> 
> Niels
> 

Just to throw my US$0.02 in, I have three things set up:

1) vnc.myname.domain — I have static IPs, but you could use DynDNS to have a 
DNS name point to. . .
2) a static nat rule that takes the IP assigned to vnc.myname.domain and 
forwards port 5500 (the default listening VNC port) to. . 
3) a listening VNC viewer I run when I talk to my family members.

I have used (a variation) of this setup since the late 90s (with my grandmother 
— in her 80s, using one of the original iMacs; my mother — in her 70s now, with 
her goddamn PCs that make me want to scream (win XP -> 10); my sister-in-law — 
in her 60s.).  My sister-in-law’s is the most challenging.  Well, it was.  See, 
she used to ask me for help from work.  I could VPN in there and help her out.  
But then she started working a LOT more from home, and she didn’t like using 
VNC to connect to her PC, using RDP instead. . . Long story short, I set it up 
so she connects her Windows 10 laptop to my listening VNC server, where I can 
see her VPN to work, connect to her Windows 7 desktop, and run her Windows XP 
emulator so she can run Paradox for DOS.  You can’t make this shit up.

FML

Sean

PS Each person had a shortcut or whatever OS-equivilant thing to launch VNC 
server and connect to a listening VNC client. Occasionally they lose the 
shortcut, and I walk them through launching and connecting manually — it’s 
pretty easy, since they know how to type in a URL for the most part, and that’s 
about all they have to do.

Re: How do you do "family remote support"?

[Chris M]

They can use whatismyip.com to see their public IP address.

On Tue, Jul 11, 2017 at 4:44 PM Niels Kobschätzki 
wrote:

>
> > On 11. Jul 2017, at 23:33, Kurt H Maier  wrote:
> >
> >> On Tue, Jul 11, 2017 at 05:22:29PM -0400, Rupert Gallagher wrote:
> >> Never heard of whatismyip.org?
> >> Sent from ProtonMail Mobile
> >
> > Never heard of NAT?
>
> Thank you all. I will probably get them into an OpenVPN-network and since
> there are nice GUIs available on the Mac for that, they should be able to
> connect (or I try to implement a launchd-service). I can give them always
> the same IP and do not even have to check for that then. And then I use VNC
> with the built-in VNC-server from MacOS.
>
> Thanks again,
>
> Niels
>
-- 
There's no place like 127.0.0.1

Re: How do you do "family remote support"?

[Niels Kobschätzki]

> On 11. Jul 2017, at 23:33, Kurt H Maier  wrote:
> 
>> On Tue, Jul 11, 2017 at 05:22:29PM -0400, Rupert Gallagher wrote:
>> Never heard of whatismyip.org?
>> Sent from ProtonMail Mobile
> 
> Never heard of NAT?

Thank you all. I will probably get them into an OpenVPN-network and since there 
are nice GUIs available on the Mac for that, they should be able to connect (or 
I try to implement a launchd-service). I can give them always the same IP and 
do not even have to check for that then. And then I use VNC with the built-in 
VNC-server from MacOS.

Thanks again,

Niels

Re: How do you do "family remote support"?

[Kurt H Maier]

On Tue, Jul 11, 2017 at 05:22:29PM -0400, Rupert Gallagher wrote:
> Never heard of whatismyip.org?
> Sent from ProtonMail Mobile

Never heard of NAT?
Sent from QMail Stationary

Re: How do you do "family remote support"?

[Rupert Gallagher]

Never heard of whatismyip.org?
Sent from ProtonMail Mobile

On Tue, Jul 11, 2017 at 9:22 PM, Karel Gardas  wrote:

> On Tue, Jul 11, 2017 at 9:00 PM, Rupert Gallagher wrote: > Never heard of 
> VNC? but for this IIRC you need to know remote IP which OP told is "too 
> complicated" for his family members. @protonmail.com>

Re: How do you do "family remote support"?

[Mark Carroll]

On 11 Jul 2017, Karel Gardas wrote:

> On Tue, Jul 11, 2017 at 9:00 PM, Rupert Gallagher  wrote:
>> Never heard of VNC?
>
> but for this IIRC you need to know remote IP which OP told is "too
> complicated" for his family members.

For some people I add something in their scripts that tickles a set of
odd ports in sequence on one of my IPs as their machine's network
interface comes up. Nothing listens there but I can check in my firewall
reject logs for their script's port numbers to see what their latest IP
is.

-- Mark

Re: Skylake experience with -current

[Bryan C. Everly]

On Tue, Jul 11, 2017 at 3:20 PM, Ted Unangst  wrote:
>
> For the record, it wasn't me. Kettenis did some great work, though.

Well then!  Kettenis - I owe you many beers!  Thank you!!

Re: How do you do "family remote support"?

[Karel Gardas]

On Tue, Jul 11, 2017 at 9:00 PM, Rupert Gallagher  wrote:
> Never heard of VNC?

but for this IIRC you need to know remote IP which OP told is "too
complicated" for his family members.

Re: Skylake experience with -current

[Ted Unangst]

Bryan C. Everly wrote:
> Thanks again to tedu and everyone else who put in the effort to get us
> working on this architecture.  I can't imagine it was easy!

For the record, it wasn't me. Kettenis did some great work, though.

Skylake experience with -current

[Bryan C. Everly]

Hi misc@,

First off, I wanted to thank tedu and everyone else who worked hard on
getting Skylake DRM support into -current.  I was really excited to
read about that in Ted's post and thought I'd try it out on my
Thinkpad X1 Carbon (4th generation) laptop.

I renamed my /etc/x11.conf file to get it out of the way and so far my
experience has been:

1.  GDM works great under it
2.  Lumina 1.2.1 and 1.3.1 work great under it
3.  xfce4 worked great under it for me

Where I ran into trouble was in trying to run our port of Gnome3.  I
would get a black screen with a functional mouse pointer on it, then
after like 30 seconds it would crash.

I'm wondering if this is known and, if not, what debugging info I
could gather to help out the effort?  I know that Gnome3 requires
accelerated graphics and I also am aware that it's days are likely
numbered on non-Linux based systems but I thought if I could gather
some info that would help folks out who were working on it, I'd be
more than happy to do so.

Thanks again to tedu and everyone else who put in the effort to get us
working on this architecture.  I can't imagine it was easy!

Thanks,
Bryan

Re: How do you do "family remote support"?

[Rupert Gallagher]

Never heard of VNC?
Sent from ProtonMail Mobile

On Tue, Jul 11, 2017 at 8:39 PM, Niels Kobschätzki  
wrote:

> Hi, I am pondering to install OpenBSD on my main machine. But I just found a 
> possible showstopper: family remote support Right now I am using Teamviewer 
> to connect from my Linux-machine to the family-Mac. Now I am searching a 
> similar easy way to do that from a possible OpenBSD-machine. Is there any 
> software that could do that? Asking them for their IP or iCloud-hostname 
> would already be too complicated. What are you using in such cases? Is a 
> QEMU-VM performant enough for such a thing (I have a Thinkpad T460 with a 
> Skylake-i5) Niels

How do you do "family remote support"?

[Niels Kobschätzki]

Hi,

I am pondering to install OpenBSD on my main machine. But I just found a
possible showstopper: family remote support

Right now I am using Teamviewer to connect from my Linux-machine to the
family-Mac. Now I am searching a similar easy way to do that from
a possible OpenBSD-machine. Is there any software that could do that?
Asking them for their IP or iCloud-hostname would already be too
complicated. What are you using in such cases?
Is a QEMU-VM performant enough for such a thing (I have a Thinkpad T460
with a Skylake-i5)

Niels

Re: vio(4) stops working with debian 9.0 qemu-2.8+dfsg-6

[Karsten Horsmann]

Hi Stefan,

thank you for the bug report and your investigation on this.

Cheers
Karsten

Am 10.07.2017 10:27 nachm. schrieb "Mike Larkin" :

> On Mon, Jul 10, 2017 at 10:22:06PM +0200, Stefan Fritsch wrote:
> > On Saturday, 8 July 2017 14:58:59 CEST Stefan Fritsch wrote:
> > > A difference between i386 and amd64 is that on amd64, openbsd uses
> MSI-X for
> > > virtio. Maybe legacy interrupts are broken with vhost-net. This needs
> some
> > > more debugging. But its either a bug in qemu or in the linux kernel,
> not in
> > > openbsd.
> >
> > It's also broken with amd64 if MSI-X is disabled.
> >
> > It's fixed in qemu 2.9. Debian bug report:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867978
> >
> > Cheers,
> > Stefan
> >
>
> Thanks for tracking this down, Stefan!
>
> -ml
>

Re: BGP vpnv4 prefixes in RIB, not in FIB

[brad hendrickse]

Hi misc@,

If there's any more information I could provide that would help, please 
let me know. I'm a little out of my depth with the vpnv4 stuff, so any 
pointers as to where I should be looking would be very much appreciated.


Thank you


On Thu, 29 Jun 2017, brad hendrickse wrote:


Hi folks,

I have a problem with routes learnt from BGP vpnv4 not being inserted into 
the FIB I'd expect. A tcpdump on the OpenBSD box shows we are receiving the 
prefixes (from a Cisco) with the labels intact. The MPE interface is 
configured in rdomain 1 with MPLS label 200. The loopback interface lo1 was 
automatically created as mentioned in the 6.1 changelog.


We have this working on OpenBSD 5.4. My colleagues have seen this same 
behaviour since OpenBSD 5.9 explaining why we're still using 5.4. All configs 
and output below is from OpenBSD 6.1.


Any help with this would be much appreciated.

Thank you


/etc/bgpd.conf:
/
# global configuration
AS 65002
router-id 192.168.1.2
holdtime 180
listen on 192.168.1.2
log updates

group "peering AS65520" {
   remote-as 65520
   neighbor 192.168.1.1 {
   descr   "AS 65520"
   announce capabilities yes
   announce self
   announce IPv4 vpn
   announce refresh yes
   announce restart yes
   }
}

rdomain 1 {
   descr "200:1"
   rd 200:1
   import-target rt 200:1
   export-target rt 200:1
   depend on mpe1
   network 10.10.10.2/32
}


/
bash-4.4# bgpctl show summary
Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down 
State/PrfRcvd

AS 6552065520 30 27 0 00:23:23  4


/
bash-4.4# bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete

flags destination  gateway  lpref   med aspath origin
AI*>  rd 200:1 10.10.10.2/32 rd 0:0 0.0.0.0 100 0 i
*>rd 200:1 100.10.0.0/24 192.168.1.1100 0 65520 ?
*>rd 200:1 155.10.0.0/24 192.168.1.1100 0 65520 ?
*>rd 200:1 200.10.0.0/24 192.168.1.1100 0 65520 ?
*>rd 200:1 210.10.0.0/24 192.168.1.1100 0 65520 ?


The next-hop for 155.10.0.0/24 is pingable
/
bash-4.4# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.536 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.604 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.587 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.536/0.576/0.604/0.029 ms


/
bash-4.4# bgpctl show fib
flags: * = valid, B = BGP, C = Connected, S = Static, D = Dynamic
  N = BGP Nexthop reachable via this route R = redistributed
  r = reject route, b = blackhole route

flags prio destination  gateway
*S   8 0.0.0.0/010.0.2.1
*C   4 10.0.2.0/24  link#1
*C   0 127.0.0.0/8  link#0
*CN  4 192.168.1.0/30   link#2
*S   8 192.168.2.1/32   192.168.1.1
*1 192.168.2.2/32   192.168.2.2
*S  r8 224.0.0.0/4  127.0.0.1
*S  r8 ::/96::1
*S  r8 ::/104   ::1
*C   0 ::1/128  link#0
*1 ::1/128  ::1
*S  r8 ::127.0.0.0/104  ::1
*S  r8 ::224.0.0.0/100  ::1
*S  r8 ::255.0.0.0/104  ::1
*S  r8 :::0.0.0.0/96::1
*S  r8 2002::/24::1
*S  r8 2002:7f00::/24   ::1
*S  r8 2002:e000::/20   ::1
*S  r8 2002:ff00::/24   ::1
*S  r8 fe80::/10::1
*1 fe80:4::1/128fe80:4::1
*S  r8 fec0::/10::1
*S  r8 ff01::/16::1
*4 ff01:4::/32  ::1
*S  r8 ff02::/16::1
*4 ff02:4::/32  ::1


The tables are coupled
/
bash-4.4# bgpctl show table
Table Description  State
   0 Loc-RIB  coupled
   1 200:1coupled


I don't expect to be able to ping the destination, but not expecting "No 
route to host"

/
bash-4.4# ping -V 1 155.10.0.1
PING 155.10.0.1 (155.10.0.1): 56 data bytes
ping: sendmsg: No route to host
ping: wrote 155.10.0.1 64 chars, ret=-1
ping: sendmsg: No route to host
ping: wrote 155.10.0.1 64 chars, ret=-1
ping: sendmsg: No route to host


/
bash-4.4# ifconfig -a
lo0: flags=88049 mtu 32768
   index 4 priority 0 llprio 3
   groups: lo
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
   inet 192.168.2.2 netmask 0x
xnf0: flags=8843 mtu 1500
   lladdr 4a:2f:aa:55:45:89
   index 1 priority 0 llprio 3
   groups: egress
   media: Ethernet manual
   status: active
   inet 10.0.2.38 netmask 0xff00 broadcast 

Re: Pq rendering in ports(7)

[Ingo Schwarze]

Hi Jan,

Jan Stary wrote on Tue, Jul 11, 2017 at 11:50:01AM +0200:
> Ingo Schwarze wrote:

>> Maybe mandoc should warn about the portability issue?  Possibly,
>> but i would have to understand what exactly is broken in groff, so
>> what the permissible syntax is.  Or even better, we should fix groff?
>> That may be hard.

> Would you please kindly bring it up on the groff list,
> if you think groff should address this too? (I can do it,
> but it would get more momentum comming from you.)

No, i won't, and please don't.

Groff has no maintainer, and all the people working on it are
continuously overwhelmed with work.  So such a bug report will not
result in getting anything fixed, a bug report without a patch is
nothing but noise and distraction on the list and even in the
bugtracker.  Of course, people who don't know how badly groff is
pressed for manpower might still do it.  But people who know better
really shouldn't.

Even when i send patches that are fixing simple bugs, unconcontroversial,
small, and easy to verify, and that i have already tested according
to OpenBSD quality standards, it is very hard to get them them into
groff.  It often takes months for someone to come round and commit
them, even with occasional, non-intrusive reminders.  In one case,
it took about two years.

I have been offered groff commit access, which would mitigate the
problem, because with commit access, i would both commit my own patches
that are obviously uncontroversial and commit good patches that now
rot in the bugtracker.  But the FSF required me to sign an FSF
Copyright assignment contract according to Massachusetts Law that
i deem illegal according to International Law (and also according
to German Law) and that contains provisions that in some admittedly
unlikely cases of neglect, i may become liable to pay damages to the
FSF if i fail to comply with some of their legal rules.  So that is
two reasons why i feel unable and unwilling to sign that contract.

The former groff maintainer, Werner Lemberg, asked the FSF Board
of Directors to allow contributions from occasional contributors
without a copyright assignment, simply covered by either a ISC-style
license - which allows integration into a GPL project with no
problems whatsoever - or a public domain dedication - which might
also work, whichever of the two the FSF Directors and their lawyers
prefer.  Werner argued to the Board of Directors that allowing that
was required for the viability of the project, to help the already
very difficult task of acquiring urgently needed new contributors.
He wasn't the first maintainer of a core GNU project to argue that
way.  The FSF Copyright Clerk wrote to me in January 2014, "We are
going to look into allowing contributions with a license. This will
take time as it is a policy change. Thank you for your patience."

That is the last i heard about that matter so far.

>> Note that the .Pq is *outside* the .Lk, so it is logical that the
>> parentheses appear *outside* the display.

> Ah, so is this being "outside of the display"
> (meaning "outside of the kind-of-D1-line" here)
> that introduces the line breaks?

Yes.

>> If you want the parentheses
>> inside the display, you might feel tempted to write something like
>> 
>>  For more information about using ports, see
>>  The
>>  .Ox
>>  Ports System
>>  .Lk ( https://www.openbsd.org/faq/faq15.html#Ports ) .
>>  For information about creating new ports, see
>>  the
>>  .Ox
>>  Porter's Handbook
>>  .Lk ( https://www.openbsd.org/faq/ports/ ) .
>> 
>> But that also breaks with groff:
>> 
>>  For more information about using ports, see The OpenBSD Ports System
>>  https://www.openbsd.org/faq/faq15.html#Ports: (). For information about
>>  creating new ports, see the OpenBSD Porter's Handbook
>>  https://www.openbsd.org/faq/ports/: ().

> It would also be semantically wrong, right?
> The parentheses surely are not part of the link.

Not necessarily semantically wrong, no.
The mdoc(7) language uses a convention that leading opening and
trailing closing delimiters found on the input line of many macros
fall out of the logical scope of those macros, see the subsection
"Delimiters" in the mdoc(7) manual for details.

In mandoc, the .Lk macro already handles closing delimiters in an
even more special way than most other macros:  They fall out of the
(semantic) link description scope, but remain in the (physical,
.D1-like) display scope.  Note that the trailing full stop in
many of the examples we are discussing here already uses that, and
nobody asked how it works because it just feels natural in mdoc(7).
In mandoc, even the opening parenthesis falls out of the .Lk scope;
i merely didn't implement the additional complication that it should
yet remain in the .D1-like display scope.

In groff, .Lk is completely missing opening delimiter detection,
resulting in the broken output you see above.

> I was probably wrong in my original 

Re: Doubts about the successors of OpenBSD leadership and development

[Shazaum]

Incredible a Troll's ability to make you respond to a thread.

On 07/11/2017 07:04 AM, Gareth Nelson wrote:
> Only half joking: alcor.org
>
> Being serious: the OpenBSD Foundation will likely help choose someone
> should Theo retire or die.
>
> But we should probably backup Theo anyway..
>
> On 11 Jul 2017 7:53 am, "Dennis Davis"  wrote:
>
> On Mon, 10 Jul 2017, Stefan Sperling wrote:
>
>> From: Stefan Sperling 
>> To: SOUL_OF_ROOT 55 
>> Cc: misc@openbsd.org
>> Date: Mon, 10 Jul 2017 22:16:36
>> Subject: Re: Doubts about the successors of OpenBSD leadership and
> development
>> On Mon, Jul 10, 2017 at 06:04:53PM -0300, SOUL_OF_ROOT 55 wrote:
>>> Who will succeed Theo de Raadt in the leadership and development of
> OpenBSD?
>> Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership and
>> development of OpenBSD: http://marc.info/?l=openbsd-
> misc=137609553004700=2
>
> I have some doubts about the provenance of that message.  In
> particular:
>
> Date:   2013-08-10 0:45:10
>
> looks suspicious.
>
> Shouldn't it be dated 1st April ?
>
> Or is this a cunning ploy to mislead your favourite acronym agencies ?
> --
> Dennis Davis 

Re: Problems with IPv6 and routing domains

[Claus Lensbøl]

Hi misc (again),

After talking with the author of the article referenced (Joel Knight) I
will follow up with this.

First of all, I've created a version of this using IPv4 instead of IPv6,
with only the addresses changed. It works as supposed.
I am running 6.1.

Creating a return route to 2a01:7e8:35:fab::/64 via ::1 (in rdomain 0)
makes the packets loop in lo0:

# tcpdump -i lo0
14:49:19.691833 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691842 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691855 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691866 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691875 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691893 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691899 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691906 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691912 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691919 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691925 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691932 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691938 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691945 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691951 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691958 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691964 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691971 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691977 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691984 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691990 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.691997 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692003 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692010 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692016 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692023 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692029 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692039 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692050 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692057 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692064 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692070 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692076 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692083 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692090 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692096 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692102 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692109 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692115 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692122 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692128 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692134 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692141 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692147 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692154 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692160 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692166 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692173 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692179 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692186 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692192 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692199 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692205 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692211 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692218 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692224 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692231 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692237 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692243 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692250 2a01:7e8:1:800::2fd > 2a01:7e8:35:fab::2: icmp6: echo reply
14:49:19.692256 2a01:7e8:1:800::2fd > 

Re: authpf error: failed to create table (Device busy)

[md . obsd . bugs]

Did you test whether disabling ruleset optimization "fixes"
the issue in your case too?

\md
 
 

Gesendet: Freitag, 07. Juli 2017 um 02:59 Uhr
Von: "rafal.ramocki" 
An: misc@openbsd.org
Betreff: Re: authpf error: failed to create table (Device busy)
It looks like I've just hit the same bug. It looks like it is not related
with authpf but rather with anchors generaly. I'm loading anchor from
pf.conf, then this anchor loads another one with some rules. I have two
similar rules in there and disabling one of them will stop returning an
error from this anchor.

pass in quick log proto tcp to { 10.58.16.10 10.58.16.20 10.58.16.30 } port
1522
pass in quick log proto tcp to { 10.58.16.11 10.58.16.21 10.58.16.31 } port
1522

I have quite a bit ancors so I'm failing to load rules few anchors ahead
anyway.

Revelant parts of config are as follows:

/etc/pf.conf:
anchor "vpn1" in on $if_vpn1
load anchor vpn1 from "/etc/anchors/vpn1.conf"

/etc/anchors/vpn1.conf:
anchor "user4" in from 172.31.224.217
load anchor user4 from "/etc/anchors/vpn1/user4"

/etc/anchors/vpn1/user4:
pass in quick log proto tcp to { 10.58.16.10 10.58.16.20 10.58.16.30 } port
1522
pass in quick log proto tcp to { 10.58.16.11 10.58.16.21 10.58.16.31 } port
1522




--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/authpf-error-failed-to-create-table-Device-busy-tp321195p322214.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.
 

Re: Doubts about the successors of OpenBSD leadership and development

[Gareth Nelson]

Only half joking: alcor.org

Being serious: the OpenBSD Foundation will likely help choose someone
should Theo retire or die.

But we should probably backup Theo anyway..

On 11 Jul 2017 7:53 am, "Dennis Davis"  wrote:

On Mon, 10 Jul 2017, Stefan Sperling wrote:

> From: Stefan Sperling 
> To: SOUL_OF_ROOT 55 
> Cc: misc@openbsd.org
> Date: Mon, 10 Jul 2017 22:16:36
> Subject: Re: Doubts about the successors of OpenBSD leadership and
development
>
> On Mon, Jul 10, 2017 at 06:04:53PM -0300, SOUL_OF_ROOT 55 wrote:
> > Who will succeed Theo de Raadt in the leadership and development of
OpenBSD?
>
> Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership and
> development of OpenBSD: http://marc.info/?l=openbsd-
misc=137609553004700=2

I have some doubts about the provenance of that message.  In
particular:

Date:   2013-08-10 0:45:10

looks suspicious.

Shouldn't it be dated 1st April ?

Or is this a cunning ploy to mislead your favourite acronym agencies ?
--
Dennis Davis 

Re: Pq rendering in ports(7)

[Jan Stary]

Hi Ingo,

> > This is how ports.7 is rendered on my 6.1-current:
> > 
> >  For more information about using ports, see The OpenBSD Ports System (
> >https://www.openbsd.org/faq/faq15.html#Ports
> >  ).  For information about creating new ports, see the OpenBSD 
> > Porter's
> >  Handbook (
> >https://www.openbsd.org/faq/ports/
> >  ).
> 
> That is much better than what groff renders, which is:
> 
>  For more information about using ports, see The OpenBSD Ports System (
>  For information about creating new ports, see the
>  OpenBSD https://www.openbsd.org/faq/faq15.html#Ports).  Porter's Handbook
>  (
> 
>  For a detailed description of the build process, see
>  https://www.openbsd.org/faq/ports/).

I agree that the mandoc rendering is way better.

> > The code snippet is
> > 
> > .Pp
> > For more information about using ports, see
> > The
> > .Ox
> > Ports System
> > .Pq Lk https://www.openbsd.org/faq/faq15.html#Ports .
> > For information about creating new ports, see
> > the
> > .Ox
> > Porter's Handbook
> > .Pq Lk https://www.openbsd.org/faq/ports/ .
> 
>  ... so that mdoc(7) source code is not portable.
> 
> Maybe mandoc should warn about the portability issue?  Possibly,
> but i would have to understand what exactly is broken in groff, so
> what the permissible syntax is.  Or even better, we should fix groff?
> That may be hard.

Would you please kindly bring it up on the groff list,
if you think groff should address this too? (I can do it,
but it would get more momentum comming from you.)

> > The Pq rendering doesn't seem right: in the first case,
> > the whole "( http:/// )" would fit nicely on the second line;
> > in the second case, it would in fact fit nicely on the same line
> > - the breaks after the '(' and before the ')' seem superfluous.
> 
> In groff, there is a length threshold.  Shorter links are rendered
> inline, longer ones in what resembles a .D1 display.  That is not
> completely unreasonable, so mandoc should follow.

Yes.

> I recently did
> quite some work on .Lk rendering, and most valid constructs - i.e.
> those rendering reasonably with groff - now render identically with
> groff and mandoc.  There may still be bugs, of course.  At some
> point, i got tired of how complicated this macro is to implement
> and stopped digging for more edge cases.
> 
> Note that the .Pq is *outside* the .Lk, so it is logical that the
> parentheses appear *outside* the display.

Ah, so is this being "outside of the display"
(meaning "outside of the kind-of-D1-line" here)
that introduces the line breaks?

> If you want the parentheses
> inside the display, you might feel tempted to write something like
> 
>   For more information about using ports, see
>   The
>   .Ox
>   Ports System
>   .Lk ( https://www.openbsd.org/faq/faq15.html#Ports ) .
>   For information about creating new ports, see
>   the
>   .Ox
>   Porter's Handbook
>   .Lk ( https://www.openbsd.org/faq/ports/ ) .
> 
> But that also breaks with groff:
> 
>  For more information about using ports, see The OpenBSD Ports System
>  https://www.openbsd.org/faq/faq15.html#Ports: (). For information about
>  creating new ports, see the OpenBSD Porter's Handbook
>  https://www.openbsd.org/faq/ports/: ().

It would also be semantically wrong, right?
The parentheses surely are not part of the link.

> Since leading opening delimiters fail with groff, i was lazy and did
> not implement keeping them in scope in mandoc either, but the mandoc
> rendering is still better than the groff rendering:
> 
>  For more information about using ports, see The OpenBSD Ports System (
>https://www.openbsd.org/faq/faq15.html#Ports).
>  For information about creating new ports, see the OpenBSD Porter's
>  Handbook (
>https://www.openbsd.org/faq/ports/).

Ugh.

> The .Lk macro is relatively young.  If i read the source history
> correctly, it was added as part of the big groff-1.17 mdoc rewrite
> in 2000.  Lk is more fragile than most other mdoc(7) macros.
> Probably, some work should be done to make the implementation more
> robust or at least to document the valid syntax more strictly.  The
> current groff implementation looks rather sloppy to me.  I already
> got two improvements committed to groff back in April 2017, but the
> situation with .Lk is still far from satisfactory.

I was probably wrong in my original impression that it is a Pq problem
- it's the Lk that' the issue here, right?

> All that said, see below for what i just committed to improve the
> quality and in particular the portability of the manual, using the
> standard idiom rather than some hand-rolled approach.

This looks better to me.

Thanks,

Jan

> Index: ports.7
> ===
> RCS file: 

Re: Doubts about the successors of OpenBSD leadership and development

[Dennis Davis]

On Mon, 10 Jul 2017, Stefan Sperling wrote:

> From: Stefan Sperling 
> To: SOUL_OF_ROOT 55 
> Cc: misc@openbsd.org
> Date: Mon, 10 Jul 2017 22:16:36
> Subject: Re: Doubts about the successors of OpenBSD leadership and development
>
> On Mon, Jul 10, 2017 at 06:04:53PM -0300, SOUL_OF_ROOT 55 wrote:
> > Who will succeed Theo de Raadt in the leadership and development of OpenBSD?
>
> Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership and
> development of OpenBSD: http://marc.info/?l=openbsd-misc=137609553004700=2

I have some doubts about the provenance of that message.  In
particular:

Date:   2013-08-10 0:45:10

looks suspicious.

Shouldn't it be dated 1st April ?

Or is this a cunning ploy to mislead your favourite acronym agencies ?
-- 
Dennis Davis