[www] [faq] - IPSec -> IPsec [Was: Re: CVS: cvs.openbsd.org: www]
On Fri, Feb 22, 2019 at 10:07:05PM GMT, Landry Breuil wrote: > CVSROOT: /cvs > Module name: www > Changes by: lan...@cvs.openbsd.org 2019/02/22 15:07:05 > > Modified files: > faq: index.html > Added files: > faq: faq17.html > > Log message: > Add a (wip!) VPN FAQ, because 'How do i VPN with OpenBSD?' seems to be a > frequently asked question, and IPSec is hard. Now is the time to polish > it in-tree. > Spelling/capitalisation is harder still! ;^) As per https://marc.info/?t=15196474751=1=2 This patch is only for the faq directory. Regards, Raf Index: faq/faq10.html === RCS file: /cvs/www/faq/faq10.html,v retrieving revision 1.285 diff -u -p -r1.285 faq10.html --- faq/faq10.html 18 Oct 2018 03:14:38 - 1.285 +++ faq/faq10.html 23 Feb 2019 06:08:51 - @@ -358,7 +358,7 @@ In particular, YP is inadequate if poten to your network. Anybody gaining root access to any computer connected to your network segments carrying YP traffic can bind your YP domain and retrieve its data. -In some cases, passing YP traffic through SSL or IPSec tunnels might be +In some cases, passing YP traffic through SSL or IPsec tunnels might be an option. Setting Up a YP Server Index: faq/faq17.html === RCS file: /cvs/www/faq/faq17.html,v retrieving revision 1.1 diff -u -p -r1.1 faq17.html --- faq/faq17.html 22 Feb 2019 22:07:05 - 1.1 +++ faq/faq17.html 23 Feb 2019 06:08:51 - @@ -170,7 +170,7 @@ ikev2_recv: IKE_AUTH response from respo sa_state: VALID -> ESTABLISHED from 192.0.2.1:4500 to 198.51.100.1:4500 policy 'server2_rsa' -The IPSec flows can be viewed with https://man.openbsd.org/ipsecctl;>ipsecctl(8): @@ -291,7 +291,7 @@ ikev2 'responder_rsa' passive esp \ tag "ROADW" -It also needs to allow IPSec from any host (since clients might connect from +It also needs to allow IPsec from any host (since clients might connect from anywhere), allow traffic tagged ROADW on enc0 and apply NAT to it: @@ -356,7 +356,7 @@ After starting the initiator, this addit roadwarrior# ipsecctl -f /etc/ipsec.conf -This will happen at boot if IPSec has been enabled with +This will happen at boot if IPsec has been enabled with rcctl enable ipsec.
diff: add support for ANT-USBStick2 to uscom(4)
Hi,
The diff below adds support for the Dynastream "ANT USBStick2" to
uscom(4). The device attached with the following message:
uscom0 at uhub0 port 2 configuration 1 interface 0 "Dynastream Innovations ANT
USBStick2" rev 2.00/1.00 addr 2
ucom0 at uscom0 portno 0
Additionally, I tested the device with the command:
# cu -l /dev/cuaU0 | od -h
... a4 01 ae 00 0b ...
It returns a valid ANT binary error message.
Bye,
Jan
Index: dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.694
diff -u -p -r1.694 usbdevs
--- dev/usb/usbdevs 14 Jan 2019 03:28:03 - 1.694
+++ dev/usb/usbdevs 22 Feb 2019 17:54:59 -
@@ -1640,6 +1640,7 @@ product DVICO RT3070 0xb307 RT3070
product DYNASTREAM ANTDEVBOARD 0x1003 ANT dev board
product DYNASTREAM ANT2USB 0x1004 ANT2USB
product DYNASTREAM ANTDEVBOARD20x1006 ANT dev board
+product DYNASTREAM ANTUSB2 0x1008 ANTUSB-2 Stick
product DYNASTREAM ANTUSBM 0x1009 ANTUSB-m Stick
/* EasyDisk products */
Index: dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.706
diff -u -p -r1.706 usbdevs.h
--- dev/usb/usbdevs.h 14 Jan 2019 03:28:51 - 1.706
+++ dev/usb/usbdevs.h 22 Feb 2019 18:05:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.706 2019/01/14 03:28:51 jmatthew Exp $ */
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -1647,6 +1647,7 @@
#defineUSB_PRODUCT_DYNASTREAM_ANTDEVBOARD 0x1003 /* ANT
dev board */
#defineUSB_PRODUCT_DYNASTREAM_ANT2USB 0x1004 /* ANT2USB */
#defineUSB_PRODUCT_DYNASTREAM_ANTDEVBOARD2 0x1006 /* ANT
dev board */
+#defineUSB_PRODUCT_DYNASTREAM_ANTUSB2 0x1008 /* ANTUSB-2
Stick */
#defineUSB_PRODUCT_DYNASTREAM_ANTUSBM 0x1009 /* ANTUSB-m
Stick */
/* EasyDisk products */
Index: dev/usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.700
diff -u -p -r1.700 usbdevs_data.h
--- dev/usb/usbdevs_data.h 14 Jan 2019 03:28:51 - 1.700
+++ dev/usb/usbdevs_data.h 22 Feb 2019 18:05:14 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.700 2019/01/14 03:28:51 jmatthew Exp $
*/
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -2876,6 +2876,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTDEVBOARD2,
"ANT dev board",
+ },
+ {
+ USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTUSB2,
+ "ANTUSB-2 Stick",
},
{
USB_VENDOR_DYNASTREAM, USB_PRODUCT_DYNASTREAM_ANTUSBM,
Index: dev/usb/uscom.c
===
RCS file: /cvs/src/sys/dev/usb/uscom.c,v
retrieving revision 1.6
diff -u -p -r1.6 uscom.c
--- dev/usb/uscom.c 22 Aug 2018 15:32:49 - 1.6
+++ dev/usb/uscom.c 22 Feb 2019 17:55:44 -
@@ -53,6 +53,7 @@ struct ucom_methods uscom_methods = {
static const struct usb_devno uscom_devs[] = {
{ USB_VENDOR_HP,USB_PRODUCT_HP_HPX9GP },
+ { USB_VENDOR_DYNASTREAM,USB_PRODUCT_DYNASTREAM_ANTUSB2 },
{ USB_VENDOR_DYNASTREAM,USB_PRODUCT_DYNASTREAM_ANTUSBM }
};
Re: lockf: initialization order
On Fri, 22 Feb 2019 07:49:43 +0100, Anton Lindqvist wrote: > Initialize the fields of `struct lockf' in the same order as the struct > definition, with the ambition of making easier to inspect that all > fields are properly initialized. Similar work has already been done in > lf_split(). OK millert@ - todd
Re: pfctl should allow administrator to flush _anchors
On Fri, Feb 22, 2019 at 03:02:07PM +0100, Alexandr Nedvedicky wrote: > so the option '-F Anchors' will also perform a '-Fr' on main ruleset, is > that correct? No, my `-f /etc/pf.conf' is the equivalent to your `-F rules' here. > And also one more thing, which comes to my mind. How '-F Anchors' should > treat tables attached to anchors? If an unreferenced anchor contains a table, either destroy that table as well since it cannot be referenced or abort garbage collecting anchor completely, possibly prompting the user to clean tables in besaid anchors as well. I tend towards the first option since anchors may contain tables that were automatically created due to ruleset optimization. That is to say, while enforcing manual removal of tables as well, this may become annoying for big optimized rulesets where administrators would have to wield `-F Tables' and or `-a aname -T kill -t tname' before having `-F Anchors' run cleanly. Does that make sense? > the firewall service (which is a kind of rc-script in fact) on Solaris, > kills (removes) all tables first, then it removes anchors. > > What shall we do in case of '-F Anchors'? do we want '-F Anchors' to > kill attached tables too? Or should it just report "anchor can't be > removed, because table is still attached?" See above. What this "service" roughly seems like what I have in mind. > It looks like '-F Anchors' shifts pfctl(8) from simple tool, which does > exactly what it's told to do, to advanced tool, which does more things at > one step. But isn't that a perfect job for pfctl? It manipulates everything, it's the single interface for firewall related and that's a good. Cleaning things up after work is done is a necessity; this is about adding the missing peaces, imho. > The simple tools just seem to be more friendly for scripts, while advanced > tool is easier to use by human. pfctl is well suited for both, and it always should be.
Re: update ctype data to unicode 10
On Fri, Feb 22, 2019 at 11:29:49AM +0200, Lauri Tirkkonen wrote: > On Thu, Feb 21 2019 20:22:16 -0700, Andrew Hewus Fresh wrote: > > > I'm only including the diff because it took quite a long time to run the > > > script (177m08.01s real). > > > > There are a lot of unicode symbols. Someday if I get super bored I'll > > write something to do it in parallel :-) > > True, there's a lot of them, but it does also seem to be spending quite > a bit of time per symbol. In FreeBSD and also my hobby OS Unleashed, > data is taken from Unicode's CLDR, which I think *might* be faster (it's > been a long time since I did anything with that), but on the other hand > there are so many reasons to dislike that approach. It may be faster to run, but figuring out where the data I needed is in which file was definitely not faster. Although all this Unicode stuff is super interesting and I would like to understand all that, it's quite a way down my TODO list. > I quite like the simplicity of your script - it doesn't really matter > much if it takes a long time to run since you don't need to run it > very often. Especially since the result is used directly and not something that is part of the system build process that happens on every machine. I will mention that perl 5.29 already has Unicode 11 included, and so it will be a part of perl 5.30 when it is released and hopefully I won't get too far behind on that. Perl5's versioning scheme is that odd releases are for development and even releases are stable, so 5.9, 5.11, and 5.29 are all development releases while 5.28 and 5.30 will be maintenance releases. https://metacpan.org/pod/distribution/perl/Porting/pumpkin.pod#How-are-Perl-Releases-Numbered? l8rZ, -- andrew - http://afresh1.com Real programmers don't document. If it was hard to write, it should be hard to understand.
bridge/bif tweak
There's no need to get the `bif' pointer again, we already got it from
the list :)
ok?
diff --git sys/net/if_bridge.c sys/net/if_bridge.c
index 22f67c39dca..838f6d32886 100644
--- sys/net/if_bridge.c
+++ sys/net/if_bridge.c
@@ -770,7 +770,6 @@ bridge_output(struct ifnet *ifp, struct mbuf *m, struct
sockaddr *sa,
* get there, send to all interfaces.
*/
if (dst_if == NULL) {
- struct bridge_iflist *bif, *bif0;
struct mbuf *mc;
int used = 0;
@@ -804,9 +803,7 @@ bridge_output(struct ifnet *ifp, struct mbuf *m, struct
sockaddr *sa,
}
}
- bif0 = (struct bridge_iflist *)dst_if->if_bridgeport;
- KASSERT(bif0 != NULL);
- if (bridge_filterrule(>bif_brlout, eh, mc) ==
+ if (bridge_filterrule(>bif_brlout, eh, mc) ==
BRL_ACTION_BLOCK)
continue;
Re: [patch] cwm: tile only within active monitor
On Wed 2019.02.13 at 12:06 -0500, Okan Demirmen wrote: > On Sun 2019.01.06 at 14:46 -0500, Charles A Daniels wrote: > > Hi all, > > > > I'm new around here, so apologies in advance if I miss something > > obvious. > > > > I have written a patch to cwm so that the htile/vtile functionality > > only affect windows within the same monitor as the active window. For > > single monitor setups, this will have no effect. For multi-monitor > > setups, this will allow multiple different monitors to have windows > > tiled independently from one another (within the same group). > > > > This is implemented by modifying the relevant checks to ignore any > > clients (ci) where the client is outside of the area of the current > > display as returned by screen_area() (ci->geom not within area). > > > > Testing and feedback are welcome and appreciated! > > Hi, > > I don't use vtile/htile, nor do I have anything but one monitor > (laptop), so I'm not opposed to this. However, for those with > multi-monitors, the current behavior will change - that is, the > vtile/htile's will only take affect per monitor. > > That said, all other cwm-based client modifications operate within a > monitor, so this would be consistent. > > Would a large number of cwm users have their work-flow disrupted by this > change? No objections from other vtile/vtile users, so I've applied your diff to limit v/h tile actions to clients that exist fully within the screen of the master client. Thanks! > > Regards, > > > > ~ Charles > > > > P.S. I would be curious to heard about others' development workflows > > for window managers. I've been compiling cwm, copying it to > > /usr/X11R6/bin, logging out, and logging back in. This is really un- > > ergonomic, and I'd like to have a better setup, but I've never > > developed a window manager before so I'm unsure how to improve. > > cwm will re-exec itself so you don't need to; however I typically run > cwm out of an xterm when I really need. > > Thanks! >
Let bridge_rtlookup() insert that tag
Some plumbing to move the tag mechanism outside of net/if_bridge.c .
bridge_rtlookup() now returns an interface pointer and "bridge_rtnode"
are modified with the mutex held.
This will make locking in bridge_output() simpler.
Ok?
Index: net/bridgectl.c
===
RCS file: /cvs/src/sys/net/bridgectl.c,v
retrieving revision 1.16
diff -u -p -r1.16 bridgectl.c
--- net/bridgectl.c 20 Feb 2019 17:11:51 - 1.16
+++ net/bridgectl.c 22 Feb 2019 14:21:43 -
@@ -291,10 +291,11 @@ want:
return (error);
}
-struct bridge_rtnode *
-bridge_rtlookup(struct bridge_softc *sc, struct ether_addr *ea)
+struct ifnet *
+bridge_rtlookup(struct bridge_softc *sc, struct ether_addr *ea, struct mbuf *m)
{
struct bridge_rtnode *p = NULL;
+ struct ifnet *ifp = NULL;
u_int32_t h;
int dir;
@@ -309,9 +310,20 @@ bridge_rtlookup(struct bridge_softc *sc,
break;
}
}
+ if (p != NULL) {
+ ifp = p->brt_if;
+
+ if (p->brt_family != AF_UNSPEC && m != NULL) {
+ struct bridge_tunneltag *brtag;
+
+ brtag = bridge_tunneltag(m);
+ if (brtag != NULL)
+ bridge_copytag(>brt_tunnel, brtag);
+ }
+ }
mtx_leave(>sc_mtx);
- return (p);
+ return (ifp);
}
u_int32_t
@@ -795,5 +807,64 @@ bridge_flushrule(struct bridge_iflist *b
pf_tag_unref(p->brl_tag);
#endif
free(p, M_DEVBUF, sizeof *p);
+ }
+}
+
+struct bridge_tunneltag *
+bridge_tunnel(struct mbuf *m)
+{
+ struct m_tag*mtag;
+
+ if ((mtag = m_tag_find(m, PACKET_TAG_TUNNEL, NULL)) == NULL)
+ return (NULL);
+
+ return ((struct bridge_tunneltag *)(mtag + 1));
+}
+
+struct bridge_tunneltag *
+bridge_tunneltag(struct mbuf *m)
+{
+ struct m_tag*mtag;
+
+ if ((mtag = m_tag_find(m, PACKET_TAG_TUNNEL, NULL)) == NULL) {
+ mtag = m_tag_get(PACKET_TAG_TUNNEL,
+ sizeof(struct bridge_tunneltag), M_NOWAIT);
+ if (mtag == NULL)
+ return (NULL);
+ bzero(mtag + 1, sizeof(struct bridge_tunneltag));
+ m_tag_prepend(m, mtag);
+ }
+
+ return ((struct bridge_tunneltag *)(mtag + 1));
+}
+
+void
+bridge_tunneluntag(struct mbuf *m)
+{
+ struct m_tag*mtag;
+ if ((mtag = m_tag_find(m, PACKET_TAG_TUNNEL, NULL)) != NULL)
+ m_tag_delete(m, mtag);
+}
+
+void
+bridge_copyaddr(struct sockaddr *src, struct sockaddr *dst)
+{
+ if (src != NULL && src->sa_family != AF_UNSPEC)
+ memcpy(dst, src, src->sa_len);
+ else {
+ dst->sa_family = AF_UNSPEC;
+ dst->sa_len = 0;
+ }
+}
+
+void
+bridge_copytag(struct bridge_tunneltag *src, struct bridge_tunneltag *dst)
+{
+ if (src == NULL) {
+ memset(dst, 0, sizeof(*dst));
+ } else {
+ bridge_copyaddr(>brtag_peer.sa, >brtag_peer.sa);
+ bridge_copyaddr(>brtag_local.sa, >brtag_local.sa);
+ dst->brtag_id = src->brtag_id;
}
}
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.322
diff -u -p -r1.322 if_bridge.c
--- net/if_bridge.c 20 Feb 2019 17:11:51 - 1.322
+++ net/if_bridge.c 22 Feb 2019 14:21:43 -
@@ -768,17 +768,10 @@ bridge_output(struct ifnet *ifp, struct
eh = mtod(m, struct ether_header *);
if (!ETHER_IS_MULTICAST(eh->ether_dhost)) {
- struct bridge_rtnode *dst_p;
- struct bridge_tunneltag *brtag;
struct ether_addr *dst;
dst = (struct ether_addr *)>ether_dhost[0];
- if ((dst_p = bridge_rtlookup(sc, dst)) != NULL) {
- dst_if = dst_p->brt_if;
- if ((dst_p->brt_family != AF_UNSPEC) &&
- ((brtag = bridge_tunneltag(m)) != NULL))
- bridge_copytag(_p->brt_tunnel, brtag);
- }
+ dst_if = bridge_rtlookup(sc, dst, m);
}
/*
@@ -929,10 +922,7 @@ bridgeintr_frame(struct bridge_softc *sc
* side of the bridge, drop it.
*/
if (!ETHER_IS_MULTICAST(eh.ether_dhost)) {
- struct bridge_rtnode *dst_p;
-
- if ((dst_p = bridge_rtlookup(sc, dst)) != NULL)
- dst_if = dst_p->brt_if;
+ dst_if = bridge_rtlookup(sc, dst, NULL);
if (dst_if == src_if) {
m_freem(m);
return;
@@ -1970,63 +1960,4 @@ bridge_send_icmp_err(struct ifnet *ifp,
dropit:
m_freem(n);
-}
-
-struct bridge_tunneltag *
-bridge_tunnel(struct mbuf *m)
-{
Re: pfctl should allow administrator to flush _anchors
Hello Klemens, I just need to clarify some details. > > the 'unreferenced' means the anchor is not reachable by any packet. > > like there is no path for packet between main ruleset and that > > particular > > anchor (and all its descendants). > Yes. With the regress suite for example, the following should leave no > trace of regress anchors or rules: > > make > pfctl -f /etc/pf.conf > pfctl -F Anchors so the option '-F Anchors' will also perform a '-Fr' on main ruleset, is that correct? And also one more thing, which comes to my mind. How '-F Anchors' should treat tables attached to anchors? the firewall service (which is a kind of rc-script in fact) on Solaris, kills (removes) all tables first, then it removes anchors. What shall we do in case of '-F Anchors'? do we want '-F Anchors' to kill attached tables too? Or should it just report "anchor can't be removed, because table is still attached?" It looks like '-F Anchors' shifts pfctl(8) from simple tool, which does exactly what it's told to do, to advanced tool, which does more things at one step. The simple tools just seem to be more friendly for scripts, while advanced tool is easier to use by human. thanks and regards sasha
Re: bsd.{prog,lib}.mk: drop -S for install
On Thu, Feb 21, 2019 at 02:53:55PM +0200, Lauri Tirkkonen wrote: > Updated diff to remove -S from all files mentioned above. OK kn if anyone wants to commit, otherwise I'll do so on sunday unless I hear objections.
Re: bypass interface input queues for vlan(4)
On 22/02/19(Fri) 15:01, David Gwynne wrote: > On Thu, Feb 21, 2019 at 04:29:27PM -0300, Martin Pieuchot wrote: > > On 21/02/19(Thu) 14:19, David Gwynne wrote: > > > right now we add vlan_input as a possible input handler on the parent > > > interface, and if the packet is for a vlan we take it and pretend we > > > received it on the vlan interface by calling if_input against that mbuf. > > > > > > as mpi notes, the if input queue stuff looks like a lot of work, > > > especially for a single packet. my opinion is that we got away with > > > the if input stuff we've done to try and encourage an mpsafe network > > > stack because we amortised the cost of it over many packets off the > > > hardware ring. vlan does it a packet at a time. > > > > > > this moves the handling of vlan packets back into ether_input by > > > calling vlan_input directly on packets that are either marked as vlan > > > tagged or have a vlan ethertype. note that we have to do that anyway, > > > this just makes it explicit. > > > > > > vlan_input is then tweaked to implement all the important bits of if > > > input. part of what if input does is count the packets. because vlan > > > already has per cpu counters for bypassing queues on output, we can use > > > them again for input from any cpu. if i ever get round to making a > > > driver handle multiple rx rings this means we can rx vlan packets > > > concurrently, they don't get serialised to a single if input q. > > > > > > finally, hrvoje popovski has tested this diff and get's a significant > > > bump with it. on a machine that can forward 1100Kpps without vlan, it > > > goes from 790Kpps with vlan to 870Kpps. On a box that can do 730Kpps > > > without vlans, it goes from 550Kpps with vlan to 840Kpps. We're > > > still trying to figure that last one out, but it does appear to be > > > faster. > > > > > > thoughts? ok? > > > > Why do we need to move stuff to ether_input() if all we want is to > > bypass ifiq_input()? Isn't a 3 line diff enough^^ ? > > Fair point. It turns out it's not quite three lines, but it's still > smaller. I'm unhappy to see the bpf & packet magic reappear in pseudo-drivers. This is going to spread in every pseudo-driver, no? So why not keeping it in the new API? Should we document if_input() vs if_input_one()? Should we assert that if_input_one() is only called from a network thread? If yes, should we pick a better name?
Re: bgpctl mrt parser refactor
Diff reads good, although I'm not a BGP user. One nit inline: > @@ -689,31 +690,32 @@ mrt_parse_dump_mp(struct mrt_hdr *hdr, v > - case AF_VPNv4: > + case AID_VPN_IPv4: > if (len < MRT_PREFIX_LEN(r->prefixlen)) > goto fail; > - errx(1, "AF_VPNv4 handling not yet implemented"); > + errx(1, "AID_VPN_IPv4 handling not yet implemented"); > + goto fail; > + case AID_VPN_IPv6: > + if (len < MRT_PREFIX_LEN(r->prefixlen)) > + goto fail; > + errx(1, "AID_VPN_IPv6 handling not yet implemented"); > goto fail; These labels are unreachable after errx(3), so why add them?
Re: pfctl should allow administrator to flush _anchors
On Fri, Feb 22, 2019 at 12:42:02PM +0100, Alexandr Nedvedicky wrote: > yes, that's what I thought. We have a kind 'service' on Solaris, which > wraps pfctl to manage firewall. If firewall is being enabled, the service > cleans up all rules (anchors). We basically dump the rulesets (pfctl -vsA) > and then traverse from leaves to root to clean it up. That's probaly how I'd approach `-F Anchors'. > so if I understand you right, your scenario for ruleset from my > first email works as follows: > pfctl -Fr # makes the anchors _1 and _1/_2 unreferenced > # (they are not reachable from root any more) > > pfctl -FAnchors # purge all unreferenced anchors. > > the 'unreferenced' means the anchor is not reachable by any packet. > like there is no path for packet between main ruleset and that particular > anchor (and all its descendants). Yes. With the regress suite for example, the following should leave no trace of regress anchors or rules: make pfctl -f /etc/pf.conf pfctl -F Anchors > sure, I agree, adding -FAnchors options i more systemic approach, though > such change is more complex. I think I can give it a try to prototype it. Cool! I'm happy to help here.
Re: update ctype data to unicode 10
Hi Andrew, Lauri Tirkkonen wrote on Fri, Feb 22, 2019 at 01:57:01AM +0200: > Hi, the recent perl-5.28.1 and related unicore update brought the > unicode data from version 8.0.0 to version 10.0.0. That fixes some > character classifications (eg. emoji characters gained East_Asian_Width > value 'Wide', which causes them to correctly get a wcwidth() of 2). But > the ctype source data needs to be regenerated with this new perl/unicore > to gain the benefits. > > So I've done just that: > cd /usr/src/share/locale/ctype && ./gen_ctype_utf8.pl > en_US.UTF-8.src > and the resulting diff is below. You could obviously run this yourself - > I'm only including the diff because it took quite a long time to run the > script (177m08.01s real). > > The resulting LC_CTYPE generated from this new source gives a wcwidth() > of 2 to eg. U+1F3EE, as expected (it used to be 1 with unicode 8.0 > data). I looked through the diff (not checking each and every line thoroughly, but watching out for stuff that looks suspicious, and doing occasional random sampling tests), and i did not spot anything that looks wrong. Much of it is simply additions of new characters, which are unlikely to cause regressions in the first place, and some parts change width one to width two, which appears to be intended by what Lauri says above and which certainly isn't very dangerous either. So if the diff agrees with what you got, Andrew, it's OK schwarze@. Yours, Ingo
bgpctl mrt parser refactor
Instead of using and abusing sockaddr structs to parse addrs in mrt
messages use struct bgpd_addr since bgpctl can handle them much better.
I first wrote the mrt parser independet of bgpctl and decided to not use
bgpd internals. I no longer see the benefit of this. This makes the code
cleaner.
I tested this with a few table dumps I had around. OK?
--
:wq Claudio
Index: bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.232
diff -u -p -r1.232 bgpctl.c
--- bgpctl.c21 Feb 2019 12:12:46 - 1.232
+++ bgpctl.c22 Feb 2019 11:12:38 -
@@ -93,7 +93,6 @@ void show_mrt_dump(struct mrt_rib *, s
voidnetwork_mrt_dump(struct mrt_rib *, struct mrt_peer *, void *);
voidshow_mrt_state(struct mrt_bgp_state *, void *);
voidshow_mrt_msg(struct mrt_bgp_msg *, void *);
-voidmrt_to_bgpd_addr(union mrt_addr *, struct bgpd_addr *);
const char *msg_type(u_int8_t);
voidnetwork_bulk(struct parse_result *);
const char *print_auth_method(enum auth_method);
@@ -2000,11 +1999,11 @@ show_mrt_dump(struct mrt_rib *mr, struct
for (i = 0; i < mr->nentries; i++) {
mre = >entries[i];
bzero(, sizeof(ctl));
- mrt_to_bgpd_addr(>prefix, );
+ ctl.prefix = mr->prefix;
ctl.prefixlen = mr->prefixlen;
ctl.lastchange = mre->originated;
- mrt_to_bgpd_addr(>nexthop, _nexthop);
- mrt_to_bgpd_addr(>nexthop, _nexthop);
+ ctl.true_nexthop = mre->nexthop;
+ ctl.exit_nexthop = mre->nexthop;
ctl.origin = mre->origin;
ctl.local_pref = mre->local_pref;
ctl.med = mre->med;
@@ -2012,8 +2011,7 @@ show_mrt_dump(struct mrt_rib *mr, struct
ctl.aspath_len = mre->aspath_len;
if (mre->peer_idx < mp->npeers) {
- mrt_to_bgpd_addr(>peers[mre->peer_idx].addr,
- _addr);
+ ctl.remote_addr = mp->peers[mre->peer_idx].addr;
ctl.remote_id = mp->peers[mre->peer_idx].bgp_id;
}
@@ -2066,19 +2064,18 @@ network_mrt_dump(struct mrt_rib *mr, str
for (i = 0; i < mr->nentries; i++) {
mre = >entries[i];
bzero(, sizeof(ctl));
- mrt_to_bgpd_addr(>prefix, );
+ ctl.prefix = mr->prefix;
ctl.prefixlen = mr->prefixlen;
ctl.lastchange = mre->originated;
- mrt_to_bgpd_addr(>nexthop, _nexthop);
- mrt_to_bgpd_addr(>nexthop, _nexthop);
+ ctl.true_nexthop = mre->nexthop;
+ ctl.exit_nexthop = mre->nexthop;
ctl.origin = mre->origin;
ctl.local_pref = mre->local_pref;
ctl.med = mre->med;
ctl.aspath_len = mre->aspath_len;
if (mre->peer_idx < mp->npeers) {
- mrt_to_bgpd_addr(>peers[mre->peer_idx].addr,
- _addr);
+ ctl.remote_addr = mp->peers[mre->peer_idx].addr;
ctl.remote_id = mp->peers[mre->peer_idx].bgp_id;
}
@@ -2151,13 +2148,9 @@ print_time(struct timespec *t)
void
show_mrt_state(struct mrt_bgp_state *ms, void *arg)
{
- struct bgpd_addr src, dst;
-
- mrt_to_bgpd_addr(>src, );
- mrt_to_bgpd_addr(>dst, );
printf("%s %s[%u] -> ", print_time(>time),
- log_addr(), ms->src_as);
- printf("%s[%u]: %s -> %s\n", log_addr(), ms->dst_as,
+ log_addr(>src), ms->src_as);
+ printf("%s[%u]: %s -> %s\n", log_addr(>dst), ms->dst_as,
statenames[ms->old_state], statenames[ms->new_state]);
}
@@ -2530,16 +2523,13 @@ show_mrt_msg(struct mrt_bgp_msg *mm, voi
static const u_int8_t marker[MSGSIZE_HEADER_MARKER] = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
- struct bgpd_addr src, dst;
u_char *p;
u_int16_t len;
u_int8_t type;
- mrt_to_bgpd_addr(>src, );
- mrt_to_bgpd_addr(>dst, );
printf("%s %s[%u] -> ", print_time(>time),
- log_addr(), mm->src_as);
- printf("%s[%u]: size %u ", log_addr(), mm->dst_as, mm->msg_len);
+ log_addr(>src), mm->src_as);
+ printf("%s[%u]: size %u ", log_addr(>dst), mm->dst_as, mm->msg_len);
p = mm->msg;
len = mm->msg_len;
@@ -2612,25 +2602,6 @@ show_mrt_msg(struct mrt_bgp_msg *mm, voi
return;
}
printf("\n");
-}
-
-void
-mrt_to_bgpd_addr(union mrt_addr *ma, struct bgpd_addr *ba)
-{
- switch (ma->sa.sa_family) {
- case AF_INET:
- case AF_INET6:
- sa2addr(>sa, ba);
- break;
- case
Extend description of protected-subnet in iked.conf(5)
Hi, Attached patch adds more details about what protected-subnet's role is in configuration file, it may be useful for someone unfamiliar with the terminology used in IKEv2. Sevan Index: sbin/iked/iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.53 diff -u -p -u -r1.53 iked.conf.5 --- sbin/iked/iked.conf.5 31 Jan 2018 13:25:55 - 1.53 +++ sbin/iked/iked.conf.5 22 Feb 2019 11:55:15 - @@ -572,7 +572,12 @@ This option is provided for compatibilit .It Ic dhcp-server Ar address The address of an internal DHCP server for further configuration. .It Ic protected-subnet Ar address/prefix -The address of the protected subnet within the internal network. +The address of subnets in prefix notation which destined traffic for should be +sent over the established tunnel. +This option can be specified multiple times to compose a series of individual +routes which are pushed to peers. +If this option is not specified, the established tunnel is used as a +default gateway for all traffic by peers. .It Ic access-server Ar address The address of an internal remote access server. .El
Re: pfctl should allow administrator to flush _anchors
Hello, On Fri, Feb 22, 2019 at 10:55:17AM +0100, Klemens Nanni wrote: > On Fri, Feb 22, 2019 at 01:52:24AM +0100, Alexandr Nedvedicky wrote: > > > so far so good. Now let's flush the rules from kernel: > > > > lumpy# ./pfctl -Fr > > rules cleared > > lumpy# ./pfctl -sr > > lumpy# > > > > However the underscore anchors are still there: > Any unreferenced anchor will remain, not just internal ones. We have no > code/logic that clears them automatically. yes, that's what I thought. We have a kind 'service' on Solaris, which wraps pfctl to manage firewall. If firewall is being enabled, the service cleans up all rules (anchors). We basically dump the rulesets (pfctl -vsA) and then traverse from leaves to root to clean it up. > > > lumpy# ./pfctl -vsA > > _1 > > _1/_2 > > lumpy# > That's a known issue, easily visible if you run the pfctl regress tests. > I've been pondering this with different attempts but haven't come up > with a good/safe one yet. unlike named anchors, the Solaris service can't remove the 'underscore' anchors. my patch solves that glitch for Solaris. I was looking for the smallest change possible, which will fix Solaris without introducing too much risk/changes in upstream. > > Perhaps we can teach pfctl something like `-F Anchors`, such that it > looks at the ruleset as well as all anchors and removes those which are > not referenced. so if I understand you right, your scenario for ruleset from my first email works as follows: pfctl -Fr # makes the anchors _1 and _1/_2 unreferenced # (they are not reachable from root any more) pfctl -FAnchors # purge all unreferenced anchors. the 'unreferenced' means the anchor is not reachable by any packet. like there is no path for packet between main ruleset and that particular anchor (and all its descendants). > > The benefits are that we do not require any further > starts-with-underscore quirks and it remains a wilful action done by > root. sure, I agree, adding -FAnchors options i more systemic approach, though such change is more complex. I think I can give it a try to prototype it. > > > I could not figure out any existing way to remove them, hence I'm proposing > > small patch, which allows me to remove those 'underscore' anchors by doing > > this: > > > > lumpy# ./pfctl -a _1/_2 -Fr > > rules cleared > > lumpy# ./pfctl -a _1 -Fr > > rules cleared > Did you look at happens with _1/_2 when you flush _1 directly? yes, the ruleset becomes empty, but it still hanging around, because its descendant (_1/_2) contains the block rule. the terminal looks as follows: lumpy# pfctl -f /tmp/pf.conf lumpy# ./pfctl -Fr rules cleared lumpy# ./pfctl -a _1 -Fr rules cleared lumpy# ./pfctl -vsA _1 _1/_2 lumpy# ./pfctl -a _1 -sr lumpy# ./pfctl -a _1/_2 -sr block drop all lumpy# > > > Does patch below make sense? Or are there some pitfalls I'm not aware of? > Given your example, using named anchors seems like the right approach. > > > + /* > > +* we want enable administrator to flush anonymous anchors, > > +* thus '_' should be allowed for '-Fr' only. Also make sure > > +* we fail in case of option combination as follows: > > +* pfctl -a _1 -Fr -f /some/rules.conf > > +*/ > > if (mode == O_RDWR && tblcmdopt == NULL && > > + (clearopt == NULL || *clearopt != 'r' || > > + rulesopt != NULL) && > I'm not fond of adding an exception to what already is an exception. > The anchor handling code is tricky already and has big potential for > pitfalls and subtle bugs (as seen in the past). I completely agree here. > > > (anchoropt[0] == '_' || strstr(anchoropt, "/_") != NULL)) > > errx(1, "anchor names beginning with '_' cannot " > > "be modified from the command line"); > > That said, I think the internal semantics should stay purely internal to > avoid another can of worms. I partially agree here. As I don't think the current semantics is purely internal. IMO the underscore just denotes a kind of namespace, which requires special handling. I read it as 'name created by PF'. And as such is too weak to constitute a 'purely internal', because the rules contained in _1 anchor are coming from administrator not from PF itself. I agree with 'can of worms'. So let's see what else I'm going to find when I'll try to prototype '-FAnchors'. thanks and regards sashan
Re: update ctype data to unicode 10
Hi Andrew, Andrew Fresh wrote on Thu, Feb 21, 2019 at 08:22:16PM -0700: > On Fri, Feb 22, 2019 at 01:57:01AM +0200, Lauri Tirkkonen wrote: >> Hi, the recent perl-5.28.1 and related unicore update brought the >> unicode data from version 8.0.0 to version 10.0.0. That fixes some >> character classifications (eg. emoji characters gained East_Asian_Width >> value 'Wide', which causes them to correctly get a wcwidth() of 2). But >> the ctype source data needs to be regenerated with this new perl/unicore >> to gain the benefits. >> >> So I've done just that: >> cd /usr/src/share/locale/ctype && ./gen_ctype_utf8.pl > en_US.UTF-8.src >> and the resulting diff is below. You could obviously run this yourself - > I meant to do that and make sure it was OK with schwarze@, I'm certainly OK with the basic idea of doing an update in this way. > so it is OK afresh1@, I guess once we are confident that not just the idea, but the specific diff is OK, you'll not only get to OK it, but even to commit it, Andrew. :) > although I didn't compare your output to mine. Should be trivial to do, or would that cause any inconvenience? It seems like a free additional test to me, as another easy test to make sure that nothing unexpected went awry. >> I'm only including the diff because it took quite a long time to run the >> script (177m08.01s real). > There are a lot of unicode symbols. Someday if I get super bored I'll > write something to do it in parallel :-) I clearly prefer simplicity over performance in this respect. I'll now have a look at the diff itself to see whether anything looks suspicious. Yours, Ingo
Re: pfctl should allow administrator to flush _anchors
On Fri, Feb 22, 2019 at 01:52:24AM +0100, Alexandr Nedvedicky wrote: > so far so good. Now let's flush the rules from kernel: > > lumpy# ./pfctl -Fr > rules cleared > lumpy# ./pfctl -sr > lumpy# > > However the underscore anchors are still there: Any unreferenced anchor will remain, not just internal ones. We have no code/logic that clears them automatically. > lumpy# ./pfctl -vsA > _1 > _1/_2 > lumpy# That's a known issue, easily visible if you run the pfctl regress tests. I've been pondering this with different attempts but haven't come up with a good/safe one yet. Perhaps we can teach pfctl something like `-F Anchors`, such that it looks at the ruleset as well as all anchors and removes those which are not referenced. The benefits are that we do not require any further starts-with-underscore quirks and it remains a wilful action done by root. > I could not figure out any existing way to remove them, hence I'm proposing > small patch, which allows me to remove those 'underscore' anchors by doing > this: > > lumpy# ./pfctl -a _1/_2 -Fr > rules cleared > lumpy# ./pfctl -a _1 -Fr > rules cleared Did you look at happens with _1/_2 when you flush _1 directly? > Does patch below make sense? Or are there some pitfalls I'm not aware of? Given your example, using named anchors seems like the right approach. > + /* > + * we want enable administrator to flush anonymous anchors, > + * thus '_' should be allowed for '-Fr' only. Also make sure > + * we fail in case of option combination as follows: > + * pfctl -a _1 -Fr -f /some/rules.conf > + */ > if (mode == O_RDWR && tblcmdopt == NULL && > + (clearopt == NULL || *clearopt != 'r' || > + rulesopt != NULL) && I'm not fond of adding an exception to what already is an exception. The anchor handling code is tricky already and has big potential for pitfalls and subtle bugs (as seen in the past). > (anchoropt[0] == '_' || strstr(anchoropt, "/_") != NULL)) > errx(1, "anchor names beginning with '_' cannot " > "be modified from the command line"); That said, I think the internal semantics should stay purely internal to avoid another can of worms.
Re: update ctype data to unicode 10
On Thu, Feb 21 2019 20:22:16 -0700, Andrew Hewus Fresh wrote: > > I'm only including the diff because it took quite a long time to run the > > script (177m08.01s real). > > There are a lot of unicode symbols. Someday if I get super bored I'll > write something to do it in parallel :-) True, there's a lot of them, but it does also seem to be spending quite a bit of time per symbol. In FreeBSD and also my hobby OS Unleashed, data is taken from Unicode's CLDR, which I think *might* be faster (it's been a long time since I did anything with that), but on the other hand there are so many reasons to dislike that approach. I quite like the simplicity of your script - it doesn't really matter much if it takes a long time to run since you don't need to run it very often. -- Lauri Tirkkonen | lotheac @ IRCnet
