How to restrict ip to access a directory in OpenBSD's httpd

[Fung]

apache support somthing like

Order Allow,Deny
Allow from all
Deny from 1.2.3.4


How to achieve in OpenBSD's httpd?
We are using OpenBSD 6.4.

Re: Resume interrupted system build

[Theo de Raadt]

>This has surely been asked before, but searching turned up nothing.
>
>Is there a recommended way to resume an interrupted system build? I run on
>very old and slow machines. I haven't completed a full system build yet,
>but on my main system (Intel Celeron single core 2GB RAM from 2003) 8 hours
>didn't get me very far. A fresh kernel build takes about 90 minutes on that
>machine.
>
>"make build" does a complete clean of the build tree from what I can tell
>by looking at the Makefile. It would be nice to pick up where I left off in
>case a power failure or my own stupidity interrupts a build.

If you are well-studied and aware of how the build system works, sure
there are ways to hand-play.  Then you wouldn't need to ask..

If you aren't aware of how it works, then no.  Restart it.

Unabled to build Xenocara

[Adam Steen]

Hi All

I am trying to update my system from the latest snapshot (success) and then 
rebuild everything from source (done many times before).

following release(8), i have been able to build the kernel and base, but not 
Xenocara, i get the following error.

checking whether libxcb was compiled against xcb-proto >= 1.6... checking for 
gawk... (cached) awk
no
configure: error: libxcb was compiled against xcb-proto ; it needs to be 
compiled against version 1.6 or higher
*** Error 1 in lib/xcb-util (/usr/X11R6/share/mk/bsd.xorg.mk:158 
'config.status')
*** Error 1 in lib/xcb-util (/usr/X11R6/share/mk/bsd.xorg.mk:196 'build')
*** Error 1 in lib (:48 'build')
*** Error 1 in . (:48 'realbuild')
*** Error 1 in . (Makefile:38 'do-build')
*** Error 1 in /usr/xenocara (Makefile:27 'build')

Before my second build attempt i ensured /usr/xojb was empty and owned by 
build:wobj with mode 770, but still got the above error.

any tips would be welcome.

Cheers
Adam

Resume interrupted system build

[Lee Nelson]

This has surely been asked before, but searching turned up nothing.

Is there a recommended way to resume an interrupted system build? I run on
very old and slow machines. I haven't completed a full system build yet,
but on my main system (Intel Celeron single core 2GB RAM from 2003) 8 hours
didn't get me very far. A fresh kernel build takes about 90 minutes on that
machine.

"make build" does a complete clean of the build tree from what I can tell
by looking at the Makefile. It would be nice to pick up where I left off in
case a power failure or my own stupidity interrupts a build.

Re: Add current rtable to PS1

[Henry Bonath]

Pierre, you have my thanks as well!!

On Tue, Apr 2, 2019 at 6:00 PM Tom Smyth 
wrote:

> Pierre, Henry
>  thanks for that  I have wanted this on my systems for a while
> Cheers for asking and answering  this one
>
>
> On Tue, 2 Apr 2019 at 22:21, Pierre Emeriaud
>  wrote:
> >
> > Le mar. 2 avr. 2019 à 23:00, Henry Bonath  a
> écrit :
> > >
> > > Hello,
> > > Does anyone have any suggestions as to how to add the current rtable
> to the
> > > $PS1 prompt?
> > >
> > > I tend to flip back and forth between routing domains and tend to lose
> track
> > > of which rdomain I am currently using.
> > >
> > > I've been attempting an approach by trying to run 'ps -aux -o rtable'
> > > and using some grep/cut-fu but I am not happy with the results.
> > >
> > > Perhaps there is something simpler that I am missing?
> >
> > Yes, `id -R` "Display the routing table of the current process":
> >
> > PS1="[\u@$\h:\w](rdomain$(id -R))\$ "
> >
>
>
> --
> Kindest regards,
> Tom Smyth
>
> The information contained in this E-mail is intended only for the
> confidential use of the named recipient. If the reader of this message
> is not the intended recipient or the person responsible for
> delivering it to the recipient, you are hereby notified that you have
> received this communication in error and that any review,
> dissemination or copying of this communication is strictly prohibited.
> If you have received this in error, please notify the sender
> immediately by telephone at the number above and erase the message
> You are requested to carry out your own virus check before
> opening any attachment.
>

Re: Viewing SFP diagnostic data in OpenBSD ?

[Tom Smyth]

+1 for me also :)  ix :)

On Tue, 2 Apr 2019 at 23:38, Stuart Henderson  wrote:

>
>  :-)
>

Re: Viewing SFP diagnostic data in OpenBSD ?

[Stuart Henderson]

On 2019/04/03 08:19, David Gwynne wrote:
> 
> 
> > On 3 Apr 2019, at 04:52, Stuart Henderson  wrote:
> > 
> > On 2019-04-02, Rachel Roch  wrote:
> >> Hi,
> >> 
> >> Hopefully I'm just searching the man pages wrong but I can't seem to find 
> >> any hints as to how I can view SFP diagnostics in OpenBSD (i.e. light 
> >> power etc.)
> >> 
> >> Perhaps someone could kindly point me in the right direction ?
> >> 
> >> Rachel
> >> 
> >> 
> > 
> > I don't think that code has been written yet.
> 
> You're right, it hasn't.
> 
> Rachel, which nic are you interested in having this on?
> 
> dlg

 :-)

Re: Trouble forwarding between mpw's in bridge (6.4)

[David Gwynne]

Thanks to Mitchell for figuring this out.

> On 3 Apr 2019, at 05:25, Lee Nelson  wrote:
> 
> Since Mitchell's last email, this appeared from CVS in the place where
> the patch was supposed to be applied:
> 
> CLR(m0->m_flags, M_BCAST|M_MCAST);
> 
> I skipped the patch and compiled the kernel with the source as I found
> it from CVS.  With this new kernel everything works as I expected. arp
> broadcast requests coming into the bridge on one mpw are being seen by
> the router on the other mpw and arp replies are getting back to the
> requesting router.
> 
> Thank you to everyone!!!
> 
> On Tue, Apr 2, 2019 at 4:52 AM Mitchell Krome  wrote:
>> 
>> 
>> 
>> On 2/04/2019 7:57 pm, Mitchell Krome wrote:
>>> 
>>> 
>>> On 2/04/2019 7:24 pm, David Gwynne wrote:
 
 
> On 2 Apr 2019, at 6:41 pm, Mitchell Krome  wrote:
> 
> On 2/04/2019 2:08 pm, David Gwynne wrote:
>> Can you send me the hostname.* files and the output of ifconfig (showing 
>> all interfaces)?
>> 
>> You're using -current now, right?
>> 
>> dlg
>> 
>>> On 2 Apr 2019, at 08:15, lnel...@nelnet.org wrote:
>>> 
>>> 
>>> First of all the protected domain seems to do the opposite of what I
>>> need, but it may only appear to be the case because of the strageness
>>> with broadcast.  When trying to ping (or send any traffic) between
>>> rtr01 and rtr02 and the two mpw2's are in the same protected domain,
>>> the arp requests die in the bridge.  The arp never shows up at all on
>>> the other mpw. If I remove the mpw's from the protected domain, then
>>> the arp traffic gets through to the other mpw, but it doesn't get sent
>>> out properly by MPLS.  It's sent out as MPLS broadcast traffic
>>> originating on the physical ethernet interface but with the right label
>>> for the pseudowire. Even though the arp request itself is broadcast
>>> traffic, I would expect it to be encapsulated in a unicast MPLS packet
>>> which is sent from the MAC of the bridge or the originating router and
>>> and sent as unicast to the destination router with the pseudowire's
>>> label.  As it is now, even if the destination router could figure out
>>> what to do with these MPLS broadcast packets, it would respond to the
>>> physical interface and not the bridge.
> 
> You only need the protected domain if you do a full mesh vpls (I.E.
> every router has a mpw to every other router). That wasn't the config
> you showed initially so I don't think you need it in your case.
> 
> I am running the following diff to get MPLS to work with GRE as I had a
> similar ARP issue that was caused by gre_input tagging the packets as
> MCAST and then mpls_input dropping them. When I looked into it I didn't
> think that should cause the issue I was seeing for a real interface as
> ether_input didn't re-add the MCAST flag, but I also don't have a real
> box to test on. You can give it a go and see if it helps.
 
 I think you've found the problem. mpls_output replaces if_output though, 
 so for interfaces with mpls enabled on this, this change causes 
 BCAST|MCAST to be cleared for all outgoing packets. ie, it might break 
 things like ipv6 nd on ethernet interfaces.
>>> 
>>> Yeah I had no idea what the impact of that change was, it seemed like a
>>> hack when I wrote it...
>>> 
 
 What are you running on top of GRE that hit this?
>>> 
>>> I have a vpls over GRE. And I had some weird behaviour where arp was
>>> being dropped only on paths that skipped the outer MPLS label. I.E.
>>> we're directly connected to the next-hop and implicit null means we
>>> never add the LSP label, only the service label. Thanks to tcpdump not
>>> knowing about multicast MPLS over GRE and printing weirdness I worked
>>> out what was going on and tracked it down to this.
>>> 
 
 For now it might be better to have mpw etc clear the flags before calling 
 mpls_output.
>>> 
>>> That make sense - anything going over an LSP (even if it's one that has
>>> no label due to implicit null) should never be multicast.
>>> 
 
 Cheers,
 dlg
 
>> 
>> Give this diff a try. I totally didn't see the initial post showing the
>> remote routers as microtik, so it's entirely possible they drop the
>> multicast MPLS ethertype, where as openbsd just treats it as normal
>> unicast unless you have it over gre. An almost identical diff can be
>> applied to mpe.
>> 
>> diff --git sys/net/if_mpw.c sys/net/if_mpw.c
>> index 4348dff3f..e591e2a77 100644
>> --- sys/net/if_mpw.c
>> +++ sys/net/if_mpw.c
>> @@ -672,6 +672,9 @@ mpw_start(struct ifnet *ifp)
>> 
>>m0->m_pkthdr.ph_rtableid = ifp->if_rdomain;
>> 
>> +   /* Once we add a label it's a P2P tunnel */
>> +   m0->m_flags &= ~(M_BCAST | M_MCAST);
>> +
>>mpls_output(ifp0, m0, (struct sockaddr *)&smpls, rt);
>>}
>> 
>> 
> 
> 
>

Re: Viewing SFP diagnostic data in OpenBSD ?

[David Gwynne]

> On 3 Apr 2019, at 04:52, Stuart Henderson  wrote:
> 
> On 2019-04-02, Rachel Roch  wrote:
>> Hi,
>> 
>> Hopefully I'm just searching the man pages wrong but I can't seem to find 
>> any hints as to how I can view SFP diagnostics in OpenBSD (i.e. light power 
>> etc.)
>> 
>> Perhaps someone could kindly point me in the right direction ?
>> 
>> Rachel
>> 
>> 
> 
> I don't think that code has been written yet.

You're right, it hasn't.

Rachel, which nic are you interested in having this on?

dlg

Re: Add current rtable to PS1

[Tom Smyth]

Pierre, Henry
 thanks for that  I have wanted this on my systems for a while
Cheers for asking and answering  this one


On Tue, 2 Apr 2019 at 22:21, Pierre Emeriaud
 wrote:
>
> Le mar. 2 avr. 2019 à 23:00, Henry Bonath  a écrit :
> >
> > Hello,
> > Does anyone have any suggestions as to how to add the current rtable to the
> > $PS1 prompt?
> >
> > I tend to flip back and forth between routing domains and tend to lose track
> > of which rdomain I am currently using.
> >
> > I've been attempting an approach by trying to run 'ps -aux -o rtable'
> > and using some grep/cut-fu but I am not happy with the results.
> >
> > Perhaps there is something simpler that I am missing?
>
> Yes, `id -R` "Display the routing table of the current process":
>
> PS1="[\u@$\h:\w](rdomain$(id -R))\$ "
>


-- 
Kindest regards,
Tom Smyth

The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

Re: Add current rtable to PS1

[Pierre Emeriaud]

Le mar. 2 avr. 2019 à 23:00, Henry Bonath  a écrit :
>
> Hello,
> Does anyone have any suggestions as to how to add the current rtable to the
> $PS1 prompt?
>
> I tend to flip back and forth between routing domains and tend to lose track
> of which rdomain I am currently using.
>
> I've been attempting an approach by trying to run 'ps -aux -o rtable'
> and using some grep/cut-fu but I am not happy with the results.
>
> Perhaps there is something simpler that I am missing?

Yes, `id -R` "Display the routing table of the current process":

PS1="[\u@$\h:\w](rdomain$(id -R))\$ "

Add current rtable to PS1

[Henry Bonath]

Hello,
Does anyone have any suggestions as to how to add the current rtable to the
$PS1 prompt?

I tend to flip back and forth between routing domains and tend to lose track
of which rdomain I am currently using.

I've been attempting an approach by trying to run 'ps -aux -o rtable'
and using some grep/cut-fu but I am not happy with the results.

Perhaps there is something simpler that I am missing?

Thanks!
-Henry

Re: Console UX - UTF8, tmux colors, font sizes ?

[Stuart Henderson]

On 2019-04-02, shewhos...@riseup.net  wrote:
> Hello
>
> Coming from Linux I do like OpenBSD's minimalism, but there are a few small
> UX things I do miss:
>
> Will the console ever be supporting UTF8 ?
> US-ASCII makes math symbols a lot more cryptic ! Also causes some chaos when
> copying and pasting, with tmux, any text with undisplayable chars, into an
> editor.
>
> Also noticed that colors stop working when a CLI/TUI program that uses colors
> is run within tmux - any good fix ?

I have this in .tmux.conf

set -g default-terminal tmux-256color

but I think you can use any colour variant of tmux/screen.

> Was originally also trying to change the font & font size, but after a few 
> hours
> messing with wsloadfont all I could get was a Missingno-style (Pokemon 
> reference) font. Grown to accept Spleen, though it makes OpenBSD less unique
> alongside Terminus on FreeBSD and Linux, compared to Gallant. But a few
> different sizes built into the kernel wouldn't go a miss - my computer shows
> only 12x24 available.
> Any tested-and-working recommendations ?

You can load other fonts at runtime, but for the usual x86 video
adapters they currently need to be the same size as the one chosen
by rasops. See the pkg-readme for terminus-font in -current for more
details.

> Admittedly I am not interested in any GUI answers, sorry.

Depending on what you consider a GUI, you could run X11 with just a
maximised terminal (no window manager) and then remove the .Xauthority
file if you want to prevent running other X applications.

Re: Trouble forwarding between mpw's in bridge (6.4)

[Lee Nelson]

Since Mitchell's last email, this appeared from CVS in the place where
the patch was supposed to be applied:

CLR(m0->m_flags, M_BCAST|M_MCAST);

I skipped the patch and compiled the kernel with the source as I found
it from CVS.  With this new kernel everything works as I expected. arp
broadcast requests coming into the bridge on one mpw are being seen by
the router on the other mpw and arp replies are getting back to the
requesting router.

Thank you to everyone!!!

On Tue, Apr 2, 2019 at 4:52 AM Mitchell Krome  wrote:
>
>
>
> On 2/04/2019 7:57 pm, Mitchell Krome wrote:
> >
> >
> > On 2/04/2019 7:24 pm, David Gwynne wrote:
> >>
> >>
> >>> On 2 Apr 2019, at 6:41 pm, Mitchell Krome  wrote:
> >>>
> >>> On 2/04/2019 2:08 pm, David Gwynne wrote:
>  Can you send me the hostname.* files and the output of ifconfig (showing 
>  all interfaces)?
> 
>  You're using -current now, right?
> 
>  dlg
> 
> > On 2 Apr 2019, at 08:15, lnel...@nelnet.org wrote:
> >
> >
> > First of all the protected domain seems to do the opposite of what I
> > need, but it may only appear to be the case because of the strageness
> > with broadcast.  When trying to ping (or send any traffic) between
> > rtr01 and rtr02 and the two mpw2's are in the same protected domain,
> > the arp requests die in the bridge.  The arp never shows up at all on
> > the other mpw. If I remove the mpw's from the protected domain, then
> > the arp traffic gets through to the other mpw, but it doesn't get sent
> > out properly by MPLS.  It's sent out as MPLS broadcast traffic
> > originating on the physical ethernet interface but with the right label
> > for the pseudowire. Even though the arp request itself is broadcast
> > traffic, I would expect it to be encapsulated in a unicast MPLS packet
> > which is sent from the MAC of the bridge or the originating router and
> > and sent as unicast to the destination router with the pseudowire's
> > label.  As it is now, even if the destination router could figure out
> > what to do with these MPLS broadcast packets, it would respond to the
> > physical interface and not the bridge.
> >>>
> >>> You only need the protected domain if you do a full mesh vpls (I.E.
> >>> every router has a mpw to every other router). That wasn't the config
> >>> you showed initially so I don't think you need it in your case.
> >>>
> >>> I am running the following diff to get MPLS to work with GRE as I had a
> >>> similar ARP issue that was caused by gre_input tagging the packets as
> >>> MCAST and then mpls_input dropping them. When I looked into it I didn't
> >>> think that should cause the issue I was seeing for a real interface as
> >>> ether_input didn't re-add the MCAST flag, but I also don't have a real
> >>> box to test on. You can give it a go and see if it helps.
> >>
> >> I think you've found the problem. mpls_output replaces if_output though, 
> >> so for interfaces with mpls enabled on this, this change causes 
> >> BCAST|MCAST to be cleared for all outgoing packets. ie, it might break 
> >> things like ipv6 nd on ethernet interfaces.
> >
> > Yeah I had no idea what the impact of that change was, it seemed like a
> > hack when I wrote it...
> >
> >>
> >> What are you running on top of GRE that hit this?
> >
> > I have a vpls over GRE. And I had some weird behaviour where arp was
> > being dropped only on paths that skipped the outer MPLS label. I.E.
> > we're directly connected to the next-hop and implicit null means we
> > never add the LSP label, only the service label. Thanks to tcpdump not
> > knowing about multicast MPLS over GRE and printing weirdness I worked
> > out what was going on and tracked it down to this.
> >
> >>
> >> For now it might be better to have mpw etc clear the flags before calling 
> >> mpls_output.
> >
> > That make sense - anything going over an LSP (even if it's one that has
> > no label due to implicit null) should never be multicast.
> >
> >>
> >> Cheers,
> >> dlg
> >>
>
> Give this diff a try. I totally didn't see the initial post showing the
> remote routers as microtik, so it's entirely possible they drop the
> multicast MPLS ethertype, where as openbsd just treats it as normal
> unicast unless you have it over gre. An almost identical diff can be
> applied to mpe.
>
> diff --git sys/net/if_mpw.c sys/net/if_mpw.c
> index 4348dff3f..e591e2a77 100644
> --- sys/net/if_mpw.c
> +++ sys/net/if_mpw.c
> @@ -672,6 +672,9 @@ mpw_start(struct ifnet *ifp)
>
> m0->m_pkthdr.ph_rtableid = ifp->if_rdomain;
>
> +   /* Once we add a label it's a P2P tunnel */
> +   m0->m_flags &= ~(M_BCAST | M_MCAST);
> +
> mpls_output(ifp0, m0, (struct sockaddr *)&smpls, rt);
> }
>
>


-- 
https://keybase.io/nelsonov

Re: Viewing SFP diagnostic data in OpenBSD ?

[Tom Smyth]

Hi Rachel
Im not certain..  i havent tried this on openbsd  but i would do an snmp
walk and see if there are stats displayed on  your sfp interfaces  can you
check the mib from the chipset manufacturer ?

Also if you  check  man driver name  e.g.
man ix  for intel 10g nics there may be additional info specific to the
cards there

I hope this helps

Tom Smyth

On Tuesday, 2 April 2019, Rachel Roch  wrote:

> Hi,
>
> Hopefully I'm just searching the man pages wrong but I can't seem to find
> any hints as to how I can view SFP diagnostics in OpenBSD (i.e. light power
> etc.)
>
> Perhaps someone could kindly point me in the right direction ?
>
> Rachel
>
>

-- 
Kindest regards,
Tom Smyth

The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

Re: Viewing SFP diagnostic data in OpenBSD ?

[Stuart Henderson]

On 2019-04-02, Rachel Roch  wrote:
> Hi,
>
> Hopefully I'm just searching the man pages wrong but I can't seem to find any 
> hints as to how I can view SFP diagnostics in OpenBSD (i.e. light power etc.)
>
> Perhaps someone could kindly point me in the right direction ?
>
> Rachel
>
>

I don't think that code has been written yet.

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

[Rachel Roch]

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 ?

Viewing SFP diagnostic data in OpenBSD ?

[Rachel Roch]

Hi,

Hopefully I'm just searching the man pages wrong but I can't seem to find any 
hints as to how I can view SFP diagnostics in OpenBSD (i.e. light power etc.)

Perhaps someone could kindly point me in the right direction ?

Rachel

Re: PF force egress route to a user

[Enric Morales]

On 2019-04-01 05:14, Riccardo Giuntoli wrote:

Hello there,

Riccardo Giuntoli writing from Spain, nice to hear from you.
In my pf.conf i want to force all outgoing connection from a specific 
user
in egress from a machine take a route different from the default. 
Something

like this (it doesn't work):

match out on egress inet proto {tcp udp} from self nat-to ($vpn_if) 
user

_tor

Is it possible? Can i isolate a specific user with rdomain and rtable?

Nice regards,


Hi Riccardo,

it is possible to match according to user but there might be an issue. 
man pf.conf states that the socket's owner is the one that created it. I 
don't know about Tor, but perhaps it starts as root, creates a socket on 
a privileged port and then drops privileges? If that is the case the 
rule won't match, as according to pf, the socket will be owned by root.


I'm not a PF wizard but I want to give you ideas. I'm sure other people 
can provide more help.


Best regards from Barcelona too,

Enric

Re: Is it worth considering compling a generic MPPF kernel for user convenience

[kolargol]

so this is about setting MULTIPROCESSOR, WITH_PF_LOCK and NET_TASKQ ? or 
something else? i been using it since a while and as in basic router all seem 
fine.

__
kolargol

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 2, 2019 6:28 PM, Tom Smyth  
wrote:

> Hi, you can re-compile the BSD kernel to allow multi Processor PF,
> (but it is deemd by people who know more about PF and Programming
> than my self that it is not fully up to OpenBSD standards for Release yet
>
> I was referring to it as BSDMPPF as a continuation of the BSD vs BSDMP
> kernel ...
>
> sorry for the confusion that I have caused in this case...
>
> On Tue, 2 Apr 2019 at 17:25, kolargol kolar...@protonmail.com wrote:
>
> > MPPF is multi processor for pf or what? Where can i learn more about it? I 
> > was searching sources but could not find anything related to "MPPF", any 
> > clue?
> > thanks,
> > __
> > kolargol
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Tuesday, April 2, 2019 1:30 PM, Tom Smyth tom.sm...@wirelessconnect.eu 
> > wrote:
> >
> > > Hello,
> > > I was wondering what devs / more experienced users think about
> > > having BSDMPPF kernel as an option in the upcoming release
> > > so that users could opt to test that by selecting alternate BSDMPPF kernel
> > > (without having to re-compile the kernel)
> > > the tested benefits on a PC engines apuc2 is at least 2x performance
> > > from my lab testing here
> > > I think having a higher install base of consistently complied generic
> > > kernels with
> > > pf enabled would be beneficial
> > > what do the more experienced users of OpenBSD think about this?
> > > are there any down sides with this approach ?
> > > Thanks,
> > > Tom Smyth
>
> --
>
> Kindest regards,
> Tom Smyth
>
> The information contained in this E-mail is intended only for the
> confidential use of the named recipient. If the reader of this message
> is not the intended recipient or the person responsible for
> delivering it to the recipient, you are hereby notified that you have
> received this communication in error and that any review,
> dissemination or copying of this communication is strictly prohibited.
> If you have received this in error, please notify the sender
> immediately by telephone at the number above and erase the message
> You are requested to carry out your own virus check before
> opening any attachment.

Re: Console UX - UTF8, tmux colors, font sizes ?

[Ingo Schwarze]

Hi,

shewhos...@riseup.net wrote on Tue, Apr 02, 2019 at 04:16:06PM +:

> Will the console ever be supporting UTF8 ?

Questions of the form "Will OpenBSD ever provide feature X?" rarely
allow a definitive answer.  It deepends on whether someone does the
work, the work is of sufficient quality, and doesn't cause too much
bloat.  Currently, i'm not aware of anybody planning to work on it.

Console UTF-8 support is not the easiest task one could pick because
it would require limited UTF-8 handling in the kernel, and whoever
attempts that must be very careful to avoid bloat.

I'll leave commenting on tmux(1) and wsfontload(8) to others as i don't
use those programs and know little about them.

Yours,
  Ingo

Re: Is it worth considering compling a generic MPPF kernel for user convenience

[Tom Smyth]

Hi, you can re-compile the BSD kernel to allow multi Processor PF,
(but it is deemd by people who know more about PF and Programming
than my self that it is not fully up to OpenBSD standards for Release yet

I was referring to it as BSDMPPF as a continuation of the BSD vs BSDMP
kernel ...

sorry for the confusion that I have caused in this case...


On Tue, 2 Apr 2019 at 17:25, kolargol  wrote:
>
> MPPF is multi processor for pf or what? Where can i learn more about it? I 
> was searching sources but could not find anything related to "MPPF", any clue?
>
> thanks,
>
> __
> kolargol
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, April 2, 2019 1:30 PM, Tom Smyth  
> wrote:
>
> > Hello,
> >
> > I was wondering what devs / more experienced users think about
> > having BSDMPPF kernel as an option in the upcoming release
> > so that users could opt to test that by selecting alternate BSDMPPF kernel
> > (without having to re-compile the kernel)
> >
> > the tested benefits on a PC engines apuc2 is at least 2x performance
> > from my lab testing here
> >
> > I think having a higher install base of consistently complied generic
> > kernels with
> > pf enabled would be beneficial
> >
> > what do the more experienced users of OpenBSD think about this?
> >
> > are there any down sides with this approach ?
> >
> > Thanks,
> >
> > Tom Smyth
>
>


-- 
Kindest regards,
Tom Smyth

The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

Re: Is it worth considering compling a generic MPPF kernel for user convenience

[kolargol]

MPPF is multi processor for pf or what? Where can i learn more about it? I was 
searching sources but could not find anything related to "MPPF", any clue?

thanks,

__
kolargol

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, April 2, 2019 1:30 PM, Tom Smyth  
wrote:

> Hello,
>
> I was wondering what devs / more experienced users think about
> having BSDMPPF kernel as an option in the upcoming release
> so that users could opt to test that by selecting alternate BSDMPPF kernel
> (without having to re-compile the kernel)
>
> the tested benefits on a PC engines apuc2 is at least 2x performance
> from my lab testing here
>
> I think having a higher install base of consistently complied generic
> kernels with
> pf enabled would be beneficial
>
> what do the more experienced users of OpenBSD think about this?
>
> are there any down sides with this approach ?
>
> Thanks,
>
> Tom Smyth

Console UX - UTF8, tmux colors, font sizes ?

[shewhosays]

Hello

Coming from Linux I do like OpenBSD's minimalism, but there are a few small
UX things I do miss:

Will the console ever be supporting UTF8 ?
US-ASCII makes math symbols a lot more cryptic ! Also causes some chaos when
copying and pasting, with tmux, any text with undisplayable chars, into an
editor.

Also noticed that colors stop working when a CLI/TUI program that uses colors
is run within tmux - any good fix ?

Was originally also trying to change the font & font size, but after a few hours
messing with wsloadfont all I could get was a Missingno-style (Pokemon 
reference) font. Grown to accept Spleen, though it makes OpenBSD less unique
alongside Terminus on FreeBSD and Linux, compared to Gallant. But a few
different sizes built into the kernel wouldn't go a miss - my computer shows
only 12x24 available.
Any tested-and-working recommendations ?

Admittedly I am not interested in any GUI answers, sorry.

turn off ngpu / power

[su-]

Is there any chance in hell one might be able to implement a method to turn off 
ngpu? I have an nvidia optiums which i am unable to turn off in the bios 
setting. An acpi_call / script is used in another BSD to achieve this. Am just 
wondering if this is a categorial no chance in hell kind of thing.   




-- 
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
 https://tutanota.com

Re: Trouble forwarding between mpw's in bridge (6.4)

[Mitchell Krome]

On 2/04/2019 7:57 pm, Mitchell Krome wrote:
> 
> 
> On 2/04/2019 7:24 pm, David Gwynne wrote:
>>
>>
>>> On 2 Apr 2019, at 6:41 pm, Mitchell Krome  wrote:
>>>
>>> On 2/04/2019 2:08 pm, David Gwynne wrote:
 Can you send me the hostname.* files and the output of ifconfig (showing 
 all interfaces)?

 You're using -current now, right?

 dlg

> On 2 Apr 2019, at 08:15, lnel...@nelnet.org wrote:
>
>
> First of all the protected domain seems to do the opposite of what I
> need, but it may only appear to be the case because of the strageness
> with broadcast.  When trying to ping (or send any traffic) between
> rtr01 and rtr02 and the two mpw2's are in the same protected domain,
> the arp requests die in the bridge.  The arp never shows up at all on
> the other mpw. If I remove the mpw's from the protected domain, then
> the arp traffic gets through to the other mpw, but it doesn't get sent
> out properly by MPLS.  It's sent out as MPLS broadcast traffic
> originating on the physical ethernet interface but with the right label
> for the pseudowire. Even though the arp request itself is broadcast
> traffic, I would expect it to be encapsulated in a unicast MPLS packet
> which is sent from the MAC of the bridge or the originating router and
> and sent as unicast to the destination router with the pseudowire's
> label.  As it is now, even if the destination router could figure out
> what to do with these MPLS broadcast packets, it would respond to the
> physical interface and not the bridge.
>>>
>>> You only need the protected domain if you do a full mesh vpls (I.E.
>>> every router has a mpw to every other router). That wasn't the config
>>> you showed initially so I don't think you need it in your case.
>>>
>>> I am running the following diff to get MPLS to work with GRE as I had a
>>> similar ARP issue that was caused by gre_input tagging the packets as
>>> MCAST and then mpls_input dropping them. When I looked into it I didn't
>>> think that should cause the issue I was seeing for a real interface as
>>> ether_input didn't re-add the MCAST flag, but I also don't have a real
>>> box to test on. You can give it a go and see if it helps.
>>
>> I think you've found the problem. mpls_output replaces if_output though, so 
>> for interfaces with mpls enabled on this, this change causes BCAST|MCAST to 
>> be cleared for all outgoing packets. ie, it might break things like ipv6 nd 
>> on ethernet interfaces.
> 
> Yeah I had no idea what the impact of that change was, it seemed like a
> hack when I wrote it...
> 
>>
>> What are you running on top of GRE that hit this?
> 
> I have a vpls over GRE. And I had some weird behaviour where arp was
> being dropped only on paths that skipped the outer MPLS label. I.E.
> we're directly connected to the next-hop and implicit null means we
> never add the LSP label, only the service label. Thanks to tcpdump not
> knowing about multicast MPLS over GRE and printing weirdness I worked
> out what was going on and tracked it down to this.
> 
>>
>> For now it might be better to have mpw etc clear the flags before calling 
>> mpls_output.
> 
> That make sense - anything going over an LSP (even if it's one that has
> no label due to implicit null) should never be multicast.
> 
>>
>> Cheers,
>> dlg
>>

Give this diff a try. I totally didn't see the initial post showing the
remote routers as microtik, so it's entirely possible they drop the
multicast MPLS ethertype, where as openbsd just treats it as normal
unicast unless you have it over gre. An almost identical diff can be
applied to mpe.

diff --git sys/net/if_mpw.c sys/net/if_mpw.c
index 4348dff3f..e591e2a77 100644
--- sys/net/if_mpw.c
+++ sys/net/if_mpw.c
@@ -672,6 +672,9 @@ mpw_start(struct ifnet *ifp)

m0->m_pkthdr.ph_rtableid = ifp->if_rdomain;

+   /* Once we add a label it's a P2P tunnel */
+   m0->m_flags &= ~(M_BCAST | M_MCAST);
+
mpls_output(ifp0, m0, (struct sockaddr *)&smpls, rt);
}

Re: Is it worth considering compling a generic MPPF kernel for user convenience

[Tom Smyth]

Ok,  under stood re ,prototype code...
thought the Project was being extra conservative :) and
that more people trying MPPF would be helpful, but if it aint
ready for release it aint ready for release

re PF going away... I thought that was a Calendar Coincidence...
now im feeling a slight up tick in my blood pressure  :)


On Tue, 2 Apr 2019 at 12:33, Theo de Raadt  wrote:
>
> No, this is not our style, it very much doesn't fit the development
> process to have users running prototype code for 6 months.
>
> And anyways why do you want this, since pf is going away.
>
> Tom Smyth  wrote:
>
> > I was wondering what devs / more experienced users think about
> > having BSDMPPF kernel as an option in the upcoming release
> > so that users could opt to test that  by selecting alternate BSDMPPF kernel
> > (without having to re-compile the kernel)
> >
> > the tested benefits on a  PC engines  apuc2 is at least 2x performance
> > from my lab testing here
> >
> > I think having a higher install base of consistently complied generic
> > kernels with
> > pf enabled would be beneficial
> >
> > what do the more experienced users of OpenBSD think about this?
> >
> > are there any down sides with this approach ?
> >
> > Thanks,
> >
> > Tom Smyth
> >



-- 
Kindest regards,
Tom Smyth

The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

Re: Is it worth considering compling a generic MPPF kernel for user convenience

[Janne Johansson]

With MPPF it can go away almost ~5x as fast on a 6-core machine.


Den tis 2 apr. 2019 kl 13:35 skrev Theo de Raadt :

> No, this is not our style, it very much doesn't fit the development
> process to have users running prototype code for 6 months.
>
> And anyways why do you want this, since pf is going away.
>
> Tom Smyth  wrote:
>
> > I was wondering what devs / more experienced users think about
> > having BSDMPPF kernel as an option in the upcoming release
> > so that users could opt to test that  by selecting alternate BSDMPPF
> kernel
> > (without having to re-compile the kernel)
> >
> > the tested benefits on a  PC engines  apuc2 is at least 2x performance
> > from my lab testing here
> >
> > I think having a higher install base of consistently complied generic
> > kernels with
> > pf enabled would be beneficial
> >
> > what do the more experienced users of OpenBSD think about this?
> >
> > are there any down sides with this approach ?
> >
> > Thanks,
> >
> > Tom Smyth
> >
>
>

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

Re: Is it worth considering compling a generic MPPF kernel for user convenience

[Theo de Raadt]

No, this is not our style, it very much doesn't fit the development
process to have users running prototype code for 6 months.

And anyways why do you want this, since pf is going away.

Tom Smyth  wrote:

> I was wondering what devs / more experienced users think about
> having BSDMPPF kernel as an option in the upcoming release
> so that users could opt to test that  by selecting alternate BSDMPPF kernel
> (without having to re-compile the kernel)
> 
> the tested benefits on a  PC engines  apuc2 is at least 2x performance
> from my lab testing here
> 
> I think having a higher install base of consistently complied generic
> kernels with
> pf enabled would be beneficial
> 
> what do the more experienced users of OpenBSD think about this?
> 
> are there any down sides with this approach ?
> 
> Thanks,
> 
> Tom Smyth
> 

Is it worth considering compling a generic MPPF kernel for user convenience

[Tom Smyth]

Hello,

I was wondering what devs / more experienced users think about
having BSDMPPF kernel as an option in the upcoming release
so that users could opt to test that  by selecting alternate BSDMPPF kernel
(without having to re-compile the kernel)

the tested benefits on a  PC engines  apuc2 is at least 2x performance
from my lab testing here

I think having a higher install base of consistently complied generic
kernels with
pf enabled would be beneficial

what do the more experienced users of OpenBSD think about this?

are there any down sides with this approach ?

Thanks,

Tom Smyth

Re: Trouble forwarding between mpw's in bridge (6.4)

[Mitchell Krome]

On 2/04/2019 7:24 pm, David Gwynne wrote:
> 
> 
>> On 2 Apr 2019, at 6:41 pm, Mitchell Krome  wrote:
>>
>> On 2/04/2019 2:08 pm, David Gwynne wrote:
>>> Can you send me the hostname.* files and the output of ifconfig (showing 
>>> all interfaces)?
>>>
>>> You're using -current now, right?
>>>
>>> dlg
>>>
 On 2 Apr 2019, at 08:15, lnel...@nelnet.org wrote:


 First of all the protected domain seems to do the opposite of what I
 need, but it may only appear to be the case because of the strageness
 with broadcast.  When trying to ping (or send any traffic) between
 rtr01 and rtr02 and the two mpw2's are in the same protected domain,
 the arp requests die in the bridge.  The arp never shows up at all on
 the other mpw. If I remove the mpw's from the protected domain, then
 the arp traffic gets through to the other mpw, but it doesn't get sent
 out properly by MPLS.  It's sent out as MPLS broadcast traffic
 originating on the physical ethernet interface but with the right label
 for the pseudowire. Even though the arp request itself is broadcast
 traffic, I would expect it to be encapsulated in a unicast MPLS packet
 which is sent from the MAC of the bridge or the originating router and
 and sent as unicast to the destination router with the pseudowire's
 label.  As it is now, even if the destination router could figure out
 what to do with these MPLS broadcast packets, it would respond to the
 physical interface and not the bridge.
>>
>> You only need the protected domain if you do a full mesh vpls (I.E.
>> every router has a mpw to every other router). That wasn't the config
>> you showed initially so I don't think you need it in your case.
>>
>> I am running the following diff to get MPLS to work with GRE as I had a
>> similar ARP issue that was caused by gre_input tagging the packets as
>> MCAST and then mpls_input dropping them. When I looked into it I didn't
>> think that should cause the issue I was seeing for a real interface as
>> ether_input didn't re-add the MCAST flag, but I also don't have a real
>> box to test on. You can give it a go and see if it helps.
> 
> I think you've found the problem. mpls_output replaces if_output though, so 
> for interfaces with mpls enabled on this, this change causes BCAST|MCAST to 
> be cleared for all outgoing packets. ie, it might break things like ipv6 nd 
> on ethernet interfaces.

Yeah I had no idea what the impact of that change was, it seemed like a
hack when I wrote it...

> 
> What are you running on top of GRE that hit this?

I have a vpls over GRE. And I had some weird behaviour where arp was
being dropped only on paths that skipped the outer MPLS label. I.E.
we're directly connected to the next-hop and implicit null means we
never add the LSP label, only the service label. Thanks to tcpdump not
knowing about multicast MPLS over GRE and printing weirdness I worked
out what was going on and tracked it down to this.

> 
> For now it might be better to have mpw etc clear the flags before calling 
> mpls_output.

That make sense - anything going over an LSP (even if it's one that has
no label due to implicit null) should never be multicast.

> 
> Cheers,
> dlg
> 
>>
>>
>> diff --git sys/netmpls/mpls_output.c sys/netmpls/mpls_output.c
>> index b2be1fcc9..fe6e0ec42 100644
>> --- sys/netmpls/mpls_output.c
>> +++ sys/netmpls/mpls_output.c
>> @@ -53,6 +53,9 @@ mpls_output(struct ifnet *ifp, struct mbuf *m, struct
>> sockaddr *dst,
>>  int  error;
>>  u_int8_t ttl;
>>
>> +/* reset broadcast and multicast flags, this is a P2P tunnel */
>> +m->m_flags &= ~(M_BCAST | M_MCAST);
>> +
>>  if (rt == NULL || (dst->sa_family != AF_INET &&
>>  dst->sa_family != AF_INET6 && dst->sa_family != AF_MPLS)) {
>>  if (!ISSET(ifp->if_xflags, IFXF_MPLS))
>> @@ -132,9 +135,6 @@ mpls_output(struct ifnet *ifp, struct mbuf *m,
>> struct sockaddr *dst,
>>  goto bad;
>>  }
>>
>> -/* reset broadcast and multicast flags, this is a P2P tunnel */
>> -m->m_flags &= ~(M_BCAST | M_MCAST);
>> -
>>  smpls->smpls_label = shim->shim_label & MPLS_LABEL_MASK;
>>  error = ifp->if_ll_output(ifp, m, smplstosa(smpls), rt);
>>  return (error);
> 

Re: Trouble forwarding between mpw's in bridge (6.4)

[David Gwynne]

> On 2 Apr 2019, at 6:41 pm, Mitchell Krome  wrote:
> 
> On 2/04/2019 2:08 pm, David Gwynne wrote:
>> Can you send me the hostname.* files and the output of ifconfig (showing all 
>> interfaces)?
>> 
>> You're using -current now, right?
>> 
>> dlg
>> 
>>> On 2 Apr 2019, at 08:15, lnel...@nelnet.org wrote:
>>> 
>>> 
>>> First of all the protected domain seems to do the opposite of what I
>>> need, but it may only appear to be the case because of the strageness
>>> with broadcast.  When trying to ping (or send any traffic) between
>>> rtr01 and rtr02 and the two mpw2's are in the same protected domain,
>>> the arp requests die in the bridge.  The arp never shows up at all on
>>> the other mpw. If I remove the mpw's from the protected domain, then
>>> the arp traffic gets through to the other mpw, but it doesn't get sent
>>> out properly by MPLS.  It's sent out as MPLS broadcast traffic
>>> originating on the physical ethernet interface but with the right label
>>> for the pseudowire. Even though the arp request itself is broadcast
>>> traffic, I would expect it to be encapsulated in a unicast MPLS packet
>>> which is sent from the MAC of the bridge or the originating router and
>>> and sent as unicast to the destination router with the pseudowire's
>>> label.  As it is now, even if the destination router could figure out
>>> what to do with these MPLS broadcast packets, it would respond to the
>>> physical interface and not the bridge.
> 
> You only need the protected domain if you do a full mesh vpls (I.E.
> every router has a mpw to every other router). That wasn't the config
> you showed initially so I don't think you need it in your case.
> 
> I am running the following diff to get MPLS to work with GRE as I had a
> similar ARP issue that was caused by gre_input tagging the packets as
> MCAST and then mpls_input dropping them. When I looked into it I didn't
> think that should cause the issue I was seeing for a real interface as
> ether_input didn't re-add the MCAST flag, but I also don't have a real
> box to test on. You can give it a go and see if it helps.

I think you've found the problem. mpls_output replaces if_output though, so for 
interfaces with mpls enabled on this, this change causes BCAST|MCAST to be 
cleared for all outgoing packets. ie, it might break things like ipv6 nd on 
ethernet interfaces.

What are you running on top of GRE that hit this?

For now it might be better to have mpw etc clear the flags before calling 
mpls_output.

Cheers,
dlg

> 
> 
> diff --git sys/netmpls/mpls_output.c sys/netmpls/mpls_output.c
> index b2be1fcc9..fe6e0ec42 100644
> --- sys/netmpls/mpls_output.c
> +++ sys/netmpls/mpls_output.c
> @@ -53,6 +53,9 @@ mpls_output(struct ifnet *ifp, struct mbuf *m, struct
> sockaddr *dst,
>   int  error;
>   u_int8_t ttl;
> 
> + /* reset broadcast and multicast flags, this is a P2P tunnel */
> + m->m_flags &= ~(M_BCAST | M_MCAST);
> +
>   if (rt == NULL || (dst->sa_family != AF_INET &&
>   dst->sa_family != AF_INET6 && dst->sa_family != AF_MPLS)) {
>   if (!ISSET(ifp->if_xflags, IFXF_MPLS))
> @@ -132,9 +135,6 @@ mpls_output(struct ifnet *ifp, struct mbuf *m,
> struct sockaddr *dst,
>   goto bad;
>   }
> 
> - /* reset broadcast and multicast flags, this is a P2P tunnel */
> - m->m_flags &= ~(M_BCAST | M_MCAST);
> -
>   smpls->smpls_label = shim->shim_label & MPLS_LABEL_MASK;
>   error = ifp->if_ll_output(ifp, m, smplstosa(smpls), rt);
>   return (error);

Re: Trouble forwarding between mpw's in bridge (6.4)

[Mitchell Krome]

On 2/04/2019 2:08 pm, David Gwynne wrote:
> Can you send me the hostname.* files and the output of ifconfig (showing all 
> interfaces)?
> 
> You're using -current now, right?
> 
> dlg
> 
>> On 2 Apr 2019, at 08:15, lnel...@nelnet.org wrote:
>>
>>
>> First of all the protected domain seems to do the opposite of what I
>> need, but it may only appear to be the case because of the strageness
>> with broadcast.  When trying to ping (or send any traffic) between
>> rtr01 and rtr02 and the two mpw2's are in the same protected domain,
>> the arp requests die in the bridge.  The arp never shows up at all on
>> the other mpw. If I remove the mpw's from the protected domain, then
>> the arp traffic gets through to the other mpw, but it doesn't get sent
>> out properly by MPLS.  It's sent out as MPLS broadcast traffic
>> originating on the physical ethernet interface but with the right label
>> for the pseudowire. Even though the arp request itself is broadcast
>> traffic, I would expect it to be encapsulated in a unicast MPLS packet
>> which is sent from the MAC of the bridge or the originating router and
>> and sent as unicast to the destination router with the pseudowire's
>> label.  As it is now, even if the destination router could figure out
>> what to do with these MPLS broadcast packets, it would respond to the
>> physical interface and not the bridge.

You only need the protected domain if you do a full mesh vpls (I.E.
every router has a mpw to every other router). That wasn't the config
you showed initially so I don't think you need it in your case.

I am running the following diff to get MPLS to work with GRE as I had a
similar ARP issue that was caused by gre_input tagging the packets as
MCAST and then mpls_input dropping them. When I looked into it I didn't
think that should cause the issue I was seeing for a real interface as
ether_input didn't re-add the MCAST flag, but I also don't have a real
box to test on. You can give it a go and see if it helps.


diff --git sys/netmpls/mpls_output.c sys/netmpls/mpls_output.c
index b2be1fcc9..fe6e0ec42 100644
--- sys/netmpls/mpls_output.c
+++ sys/netmpls/mpls_output.c
@@ -53,6 +53,9 @@ mpls_output(struct ifnet *ifp, struct mbuf *m, struct
sockaddr *dst,
int  error;
u_int8_t ttl;

+   /* reset broadcast and multicast flags, this is a P2P tunnel */
+   m->m_flags &= ~(M_BCAST | M_MCAST);
+
if (rt == NULL || (dst->sa_family != AF_INET &&
dst->sa_family != AF_INET6 && dst->sa_family != AF_MPLS)) {
if (!ISSET(ifp->if_xflags, IFXF_MPLS))
@@ -132,9 +135,6 @@ mpls_output(struct ifnet *ifp, struct mbuf *m,
struct sockaddr *dst,
goto bad;
}

-   /* reset broadcast and multicast flags, this is a P2P tunnel */
-   m->m_flags &= ~(M_BCAST | M_MCAST);
-
smpls->smpls_label = shim->shim_label & MPLS_LABEL_MASK;
error = ifp->if_ll_output(ifp, m, smplstosa(smpls), rt);
return (error);

Re: openbgpd; strip private ASNs from bgp updates

[openbsd]

Hello,

I agree, changing the AS-PATH is not preferred in an ideal world.

My case is one where we have a large WAN, with 100+ routers. Designing
and traffic engineering that with a single AS is non-trivial so we
rely on private ASNs to leverage the excellent eBGP vs iBGP
differences to our advantage.

That said, we now also do BGP peering with our providers so the need
to strip private ASNs is needed, lest we re-engineer our entire WAN.
But I do agree, if I really need the feature I am welcome to implement
it myself or find another edge router that can accomplish this.

On Sun, Mar 31, 2019 at 1:09 PM Claudio Jeker  wrote:
>
> On Fri, Mar 29, 2019 at 08:36:26AM +0100, open...@kene.nu wrote:
> > 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?
>
> I think changing the AS PATH is a bad thing, removing elements from your
> AS path has a major impact on the route selection and opens doors for
> routing loops. In general I will only add features like 'as-override' when
> there is a clear reason why it is needed.
> So my question is, why do you need to use private AS numbers in your
> internal network?
>
> > On Thu, Mar 28, 2019 at 2:55 PM  wrote:
> > >
> > > That will indeed help. Will check it out.
> > >
> > > How I have solved it now is by having network statements on the edge
> > > (/24s). To make the internal routing work I announce more specific
> > > prefixes from the internal router, so externally I announce a /24
> > > (from edge to peering partners) but internally I announce two /25s
> > > (from internal to edge). That way internet knows how to find my /24
> > > and edge knows how to find its way internally due to /25 being more
> > > specific compared to /24.
> > >
> > > On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit  
> > > wrote:
> > > >
> > > > 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
> > > >
> >
>
> --
> :wq Claudio