Re: bgpd set nexthop 198.51.100.42 clarifications
On Wed, May 29, 2019 at 03:21:34PM +0200, Claudio Jeker wrote:
> On Tue, May 28, 2019 at 07:09:00PM +0200, Job Snijders wrote:
> > On Tue, May 28, 2019 at 05:17:08PM +0200, Claudio Jeker wrote:
> > > On Tue, May 28, 2019 at 01:28:32PM +0200, Job Snijders wrote:
> > > > On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote:
> > > > > When using a rule forcing the nexthop to a specific address bgpd
> > > > > currently does not mark that nexthop as no-modify. In other words
> > > > > the default rules for nexthop propagation applies. This means that
> > > > > for ebgp it only sends out the set nexthop when this nexthop is
> > > > > connected
> > > > > and on the same network as the peer. So while the Adj-RIB-Out shows
> > > > > the
> > > > > right nexthop it is actually not on the wire.
> > > > >
> > > > > This diff changes set nexthop 198.51.100.42 to also imply set nexthop
> > > > > no-modify. This way the set nexthop is always on the wire.
> > > > > The problem with that is that it will hand you a nice footgun ready to
> > > > > blow of your big toe (but in the end the current behaviour is doing
> > > > > the
> > > > > same just with a different angle of attack) .
> > > > >
> > > > > The set nexthop section in bgpd.conf.5 needs to be adjusted once a
> > > > > decision is made on how to handle this.
> > > >
> > > > I think I'm not a big fan of this change.
> > > >
> > > > Section 5.1.3 of RFC 4271 (the core BGP spec) is very explicit on
> > > > what NEXT_HOPs are valid to send over a non-multihop BGP session.
> > > > Only addresses that are part of the linknet between the two routers
> > > > are valid NEXT_HOP addresses on the wire. This changes makes it
> > > > trivial to send not-valid NEXT_HOPs to a neighbor, this may result
> > > > in very hard to debug troublecases. Feels like we'll be handing way
> > > > too much rope to users, especially since it facilitates protocol
> > > > violations.
> > > >
> > > > I am not aware of a real world BGP implementation that would allow
> > > > you to send completely arbitrary NEXT_HOPs.
> > >
> > > I came to a similar conclusion and will send out a better diff. The
> > > idea is that for the non-multihop BGP sessions we should require the
> > > nexthop to be in the same network.
> >
> > With 'same network', you mean the NEXT_HOP IP address must be part of
> > the router-to-router linknet, right?
> >
> > > The ebgp multihop case is currently always sticking to the local
> > > address and should probably respect the nexthop if set explicitly
> > > (that is also what the RFC suggests).
> >
> > Right.
> >
> > > ibgp seems to do the right thing.
> >
> > yup, in IBGP the NEXT_HOP can be anything.
> >
> > > The same rules need to be applied to "set nexthop no-modify" since
> > > that is currently on massive hammer.
> >
> > Right.
> >
>
> So here is the diff for this change. In short nexthop no-modify has only
> relevance for ebgp multihop links now (for the other cases it is either
> the default or ignored). set nexthop self is still overriding all
> decisions. ebgp just does the same net check and decides based on that
> data. I refactored up_get_nexthop in a way that allows it to be used
> for all AFI/SAFI cases and so 3 of the 4 almost identical code versions
> did go away and the resulting up_get_nexthop() is a lot nicer now.
>
> I decided to drop the implied NEXTHOP_NOMODIFY on set nexthop 198.51.100.42.
> It makes more sense to set this on a per ebgp multihop session if that is
> requested. The reason is that a NEXTHOP_NOMODIFY can not be toggled off
> again and so it may cause nasty config hacks in complex setups. People
> should just use 'set nexthop no-modify' on the ebgp multihop neighbor
> block or in the filters.
>
> Tested with IPv4 and IPv6. OK?
Ping
--
:wq Claudio
Index: rde_update.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_update.c,v
retrieving revision 1.111
diff -u -p -r1.111 rde_update.c
--- rde_update.c13 May 2019 21:13:04 - 1.111
+++ rde_update.c29 May 2019 13:07:31 -
@@ -238,59 +238,84 @@ up_generate_default(struct filter_head *
}
/* only for IPv4 */
-static in_addr_t
-up_get_nexthop(struct rde_peer *peer, struct filterstate *state)
+static struct bgpd_addr *
+up_get_nexthop(struct rde_peer *peer, struct filterstate *state, u_int8_t aid)
{
- in_addr_t mask;
+ struct bgpd_addr *peer_local;
- /* nexthop, already network byte order */
- if (state->nhflags & NEXTHOP_NOMODIFY) {
- /* no modify flag set */
- if (state->nexthop == NULL)
- return (peer->local_v4_addr.v4.s_addr);
- else
- return (state->nexthop->exit_nexthop.v4.s_addr);
- } else if (state->nhflags & NEXTHOP_SELF)
- return (peer->local_v4_addr.v4.s_addr);
- else if (!peer->conf.ebgp) {
+ switch (aid) {
+ case AID
Re: net80211: fix ifconfig mode command
On Wed, May 22, 2019 at 02:49:43PM +0200, Stefan Sperling wrote:
> On Mon, Apr 15, 2019 at 04:56:52PM +0200, Stefan Sperling wrote:
> > The ifconfig mode command is broken; It is supposed to force a wireless
> > interface into 11a/b/g/n media mode. This stopped working some time ago,
> > probably during my work on background scanning. Problem spotted by mlarkin@
> > who noticed that interfaces were using 11g mode while forced to 11b mode.
> >
> > The diff below allows me to force media modes again on iwm(4), urtwn(4),
> > and athn(4), with e.g. 'ifconfig iwm0 mode 11b' More tests welcome.
> >
> > Note that the stack will autoselect a mode by default and things will
> > usually just work. So this isn't a critical issue unless a mode needs to
> > be forced for some reason. The main purpose of switching modes is to
> > restrict drivers to a particular set of channels and Tx rates.
>
> The previous version of this diff had a bug which would cause recursion
> in ieee80211_end_scan() followed by a panic in ieee80211_fix_rate().
>
> Here is a new diff with that problem fixed; ok?
That problem was not quite fixed yet so the previous diff was backed out.
The problem should be fixed with this version.
diff 108b98dc66011292b9ce4c54c4d31191422de773 /usr/src
blob - 6c4cbc0a4eb31dc30a7dcac705e5c79bdee3320b
file + sys/net80211/ieee80211.c
--- sys/net80211/ieee80211.c
+++ sys/net80211/ieee80211.c
@@ -1007,6 +1007,7 @@ enum ieee80211_phymode
ieee80211_next_mode(struct ifnet *ifp)
{
struct ieee80211com *ic = (void *)ifp;
+ uint16_t mode;
if (IFM_MODE(ic->ic_media.ifm_cur->ifm_media) != IFM_AUTO) {
/*
@@ -1018,36 +1019,54 @@ ieee80211_next_mode(struct ifnet *ifp)
}
/*
-* Get the next supported mode
+* Always scan in AUTO mode if the driver scans all bands, and
+* leave the current mode as it is.
*/
- for (++ic->ic_curmode;
- ic->ic_curmode <= IEEE80211_MODE_MAX;
- ic->ic_curmode++) {
+ if (ic->ic_caps & IEEE80211_C_SCANALLBAND)
+ return (IEEE80211_MODE_AUTO);
+
+ /*
+* Get the next supported mode; effectively, this alternates between
+* the 11a (5GHz) and 11b/g (2GHz) modes. What matters is that each
+* supported channel gets scanned.
+*/
+ for (mode = ic->ic_curmode + 1; mode <= IEEE80211_MODE_MAX; mode++) {
/*
* Skip over 11n mode. Its set of channels is the superset
* of all channels supported by the other modes.
*/
- if (ic->ic_curmode == IEEE80211_MODE_11N)
+ if (mode == IEEE80211_MODE_11N)
continue;
/*
* Skip over 11ac mode. Its set of channels is the set
* of all channels supported by 11a.
*/
- if (ic->ic_curmode == IEEE80211_MODE_11AC)
+ if (mode == IEEE80211_MODE_11AC)
continue;
- /* Always scan in AUTO mode if the driver scans all bands. */
- if (ic->ic_curmode >= IEEE80211_MODE_MAX ||
- (ic->ic_caps & IEEE80211_C_SCANALLBAND)) {
- ic->ic_curmode = IEEE80211_MODE_AUTO;
+ if (ic->ic_modecaps & (1 << IEEE80211_MODE_11G)) {
+ /*
+* Skip over 11b mode. Its set of channels is
+* the set of all channels supported by 11g.
+*/
+ if (mode == IEEE80211_MODE_11B)
+ continue;
+ }
+
+ /* Start over if we have already tried all modes. */
+ if (mode == IEEE80211_MODE_MAX) {
+ mode = IEEE80211_MODE_AUTO;
break;
}
- if (ic->ic_modecaps & (1 << ic->ic_curmode))
+ if (ic->ic_modecaps & (1 << mode))
break;
}
- ieee80211_setmode(ic, ic->ic_curmode);
+ if (mode != ic->ic_curmode)
+ ieee80211_setmode(ic, mode);
+ else
+ ieee80211_reset_scan(ifp);
return (ic->ic_curmode);
}
@@ -1058,26 +1077,41 @@ ieee80211_next_mode(struct ifnet *ifp)
* work here assumes how things work elsewhere in this code.
*
* Because the result of this function is ultimately used to select a
- * rate from the rate set of the returned mode, it must not return
- * IEEE80211_MODE_11N, which uses MCS instead of rates for unicast frames.
+ * rate from the rate set of the returned mode, it must return one of the
+ * legacy 11a/b/g modes; 11n and 11ac modes use MCS instead of rate sets.
*/
enum ieee80211_phymode
ieee80211_chan2mode(struct ieee80211com *ic,
const struct ieee80211_channel *chan)
{
/*
+* Are we fixed in 11a/b/g mode?
* NB: this assumes the channel w
Re: bfd: respond to poll sequence from peer
On Mon, Jun 03, 2019 at 08:37:17PM +1000, Mitchell Krome wrote:
> Hi,
>
> Testing bfd against frr on linux, their bfd implementation sends polls
> as soon as the session is up even if the session timers haven't
> changed from what it was advertising while it was in the down state.
> Currently openbsd bfd doesn't respond to polls, so this diff adds that
> support. tcpdump output during session setup (.9 is openbsd):
>
> 14:56:31.225339 10.10.20.9.58974 > 10.10.20.10.bfd-control: [udp sum ok] BFD
> v1 length 24 state down flags [] diag none my-discrim 3396727743 your-discrim
> 0 mintx 100 minrx 100 minecho 0 multiplier 3 [to s 0xc0] (ttl 255, id
> 48014, len 52)
> 14:56:31.533645 10.10.20.10.49143 > 10.10.20.9.bfd-control: [udp sum ok] BFD
> v1 length 24 state init flags [] diag neighbor-down my-discrim 2 your-discrim
> 3396727743 mintx 150 minrx 150 minecho 5 mul tiplier 3 (DF) [tos
> 0xc0] (ttl 255, id 36838, len 52)
> 14:56:32.022601 10.10.20.9.58974 > 10.10.20.10.bfd-control: [udp sum ok] BFD
> v1 length 24 state up flags [] diag none my-discrim 3396727743 your-discrim 2
> mintx 100 minrx 150 minecho 0 multiplier 3 [tos 0xc0] (ttl 255, id
> 21474, len 52)
> 14:56:32.023134 10.10.20.10.49143 > 10.10.20.9.bfd-control: [udp sum ok] BFD
> v1 length 24 state up flags [P] diag none my-discrim 2 your-discrim
> 3396727743 mintx 150 minrx 150 minecho 5 multiplier 3 (DF) [tos
> 0xc0] (ttl 255, id 36952, len 52)
> 14:56:32.023207 10.10.20.9.58974 > 10.10.20.10.bfd-control: [udp sum ok] BFD
> v1 length 24 state up flags [F] diag none my-discrim 3396727743 your-discrim
> 2 mintx 150 minrx 150 minecho 0 multiplier 3 [tos 0xc0] (ttl 255, id
> 23805, len 52)
> 14:56:32.997091 10.10.20.10.49143 > 10.10.20.9.bfd-control: [udp sum ok] BFD
> v1 length 24 state up flags [] diag none my-discrim 2 your-discrim 3396727743
> mintx 150 minrx 150 minecho 5 multiplier 3 ( DF) [tos 0xc0] (ttl
> 255, id 36991, len 52)
>
> I also added some handling for generating polls and receiving finals while
> in there, but there isn't any code to actually start our own poll
> sequence just yet.
>
> I only have frr and openbsd peers to test with - if anybody has
> something else hooked up would be good to check what they do.
>
Diff is OK claudio@. I would probably pass the BFD_FLAG_P as argument to
bfd_send_control() instead of storing that in struct bfd_config.
But that is just a minor detail.
> diff --git sys/net/bfd.c sys/net/bfd.c
> index 42995531a8a..2ae287a15bb 100644
> --- sys/net/bfd.c
> +++ sys/net/bfd.c
> @@ -741,6 +741,8 @@ bfd_reset(struct bfd_config *bfd)
>
> bfd->bc_mode = BFD_MODE_ASYNC;
> bfd->bc_state = BFD_STATE_DOWN;
> + bfd->bc_poll_seq = 0;
> + bfd->bc_poll_rcvd = 0;
>
> /* rfc5880 6.8.18 */
> bfd->bc_neighbor->bn_lstate = BFD_STATE_DOWN;
> @@ -825,7 +827,10 @@ bfd_input(struct bfd_config *bfd, struct mbuf *m)
> bfd->bc_neighbor->bn_rdiscr = ntohl(peer->bfd_my_discriminator);
> bfd->bc_neighbor->bn_rstate = state;
> bfd->bc_neighbor->bn_rdemand = (flags & BFD_FLAG_D);
> - bfd->bc_poll = (flags & BFD_FLAG_F);
> +
> + if (flags & BFD_FLAG_F && bfd->bc_poll_seq) {
> + bfd->bc_poll_seq = 0;
> + }
>
> /* Local change to the algorithm, we don't accept below 50ms */
> if (ntohl(peer->bfd_required_min_rx_interval) < BFD_MINIMUM)
> @@ -891,6 +896,12 @@ bfd_input(struct bfd_config *bfd, struct mbuf *m)
>
> bfd->bc_error = 0;
>
> + /* Reply to poll if we aren't down */
> + if (flags & BFD_FLAG_P && bfd->bc_state > BFD_STATE_DOWN) {
> + bfd->bc_poll_rcvd = 1;
> + bfd_send_control(bfd);
> + }
> +
> discard:
> bfd->bc_neighbor->bn_rdiag = diag;
> m_free(m);
> @@ -979,6 +990,13 @@ bfd_send_control(void *x)
>
> h->bfd_ver_diag = ((BFD_VERSION << 5) | (bfd->bc_neighbor->bn_ldiag));
> h->bfd_sta_flags = (bfd->bc_state << 6);
> + /* Can't send a poll and a final in the same packet. */
> + if (bfd->bc_poll_rcvd) {
> + h->bfd_sta_flags |= BFD_FLAG_F;
> + bfd->bc_poll_rcvd = 0;
> + } else if (bfd->bc_poll_seq) {
> + h->bfd_sta_flags |= BFD_FLAG_P;
> + }
> h->bfd_detect_multi = bfd->bc_neighbor->bn_mult;
> h->bfd_length = BFD_HDRLEN;
> h->bfd_my_discriminator = htonl(bfd->bc_neighbor->bn_ldiscr);
> diff --git sys/net/bfd.h sys/net/bfd.h
> index 3e8da45086f..8ee372faa5d 100644
> --- sys/net/bfd.h
> +++ sys/net/bfd.h
> @@ -143,7 +143,8 @@ struct bfd_config {
> time_t bc_lastuptime;
> unsigned int bc_laststate;
> unsigned int bc_state;
> - unsigned int bc_poll;
> + unsigned int bc_poll_seq;
> + unsigned int bc_poll_rcvd;
> unsigned int bc_error;
> uint32_t bc_minrx;
> uint32_t
Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority
On 2.6.2019. 21:41, Martin Pieuchot wrote: > On 01/06/19(Sat) 18:55, Martin Pieuchot wrote: >> Diff below exists mainly for documentation and test purposes. If >> you're not interested about how to break the scheduler internals in >> pieces, don't read further and go straight to testing! > Updated diff to use IPL_SCHED and rebased to apply on top of -current :) i'm running this diff together with proctreelk diff on openbsd desktop with gnome and samba server and everything seems fine
Re: if_netisr(): trade NET_LOCK() for NET_RLOCK()
On 04/06/19(Tue) 01:37, Alexandr Nedvedicky wrote:
> Hello,
>
> diff below is just cosmetic change, which has no impact on current
> functionality, because there is just single network task to deliver packets to
> IP stack. I just want to push this small change to tree to minimize delta
> between current and my experimental branch.
But why is it fine? Is it because the read version of the netlock is
enough to protect the packet processing path? Or is it because it
guarantees that no ioctl will be executed in the meantime? And why do
we need that? To parallelise the packet processing path?
ok mpi@ :)
> 8<---8<---8<--8<
> diff --git a/sys/net/if.c b/sys/net/if.c
> index e355f44e80d..15b5f94f188 100644
> --- a/sys/net/if.c
> +++ b/sys/net/if.c
> @@ -976,14 +976,14 @@ if_netisr(void *unused)
> {
> int n, t = 0;
>
> - NET_LOCK();
> + NET_RLOCK();
>
> while ((n = netisr) != 0) {
> /* Like sched_pause() but with a rwlock dance. */
> if (curcpu()->ci_schedstate.spc_schedflags & SPCF_SHOULDYIELD) {
> - NET_UNLOCK();
> + NET_RUNLOCK();
> yield();
> - NET_LOCK();
> + NET_RLOCK();
> }
>
> atomic_clearbits_int(&netisr, n);
> @@ -1044,7 +1044,7 @@ if_netisr(void *unused)
> }
> #endif
>
> - NET_UNLOCK();
> + NET_RUNLOCK();
> }
>
> void
>
Re: [patch] use acme-client to sign certificated with ecdsa keys
On 6/3/19 11:53 AM, Renaud Allard wrote:
On 5/29/19 9:58 AM, Florian Obser wrote:
On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote:
The key needs to be generated manually
i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem
why not let acme-client generate the key?
Here is a more complete diff where you can use the -E switch to
generate a ECDSA key instead of the RSA one.
I refined a little bit the patch to not put ecdsa functions into rsa.c.
So I renamed rsa.c to key.c and removed the rsa references to functions
which apply to both rsa and ecdsa.
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/acme-client/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile 3 Jul 2017 22:21:47 - 1.8
+++ Makefile 4 Jun 2019 13:50:28 -
@@ -2,7 +2,7 @@
PROG= acme-client
SRCS= acctproc.c base64.c certproc.c chngproc.c dbg.c dnsproc.c
SRCS+= fileproc.c http.c jsmn.c json.c keyproc.c main.c netproc.c
-SRCS+= parse.y revokeproc.c rsa.c util.c
+SRCS+= parse.y revokeproc.c key.c util.c
MAN= acme-client.1 acme-client.conf.5
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.12
diff -u -p -r1.12 acctproc.c
--- acctproc.c 28 Jul 2018 15:25:23 - 1.12
+++ acctproc.c 4 Jun 2019 13:50:28 -
@@ -82,8 +82,8 @@ op_thumb_rsa(EVP_PKEY *pkey)
warnx("bn2string");
else if ((exp = bn2string(r->e)) == NULL)
warnx("bn2string");
- else if ((json = json_fmt_thumb_rsa(exp, mod)) == NULL)
- warnx("json_fmt_thumb_rsa");
+ else if ((json = json_fmt_thumb_key(exp, mod)) == NULL)
+ warnx("json_fmt_thumb_key");
free(exp);
free(mod);
@@ -175,10 +175,10 @@ op_sign_rsa(char **head, char **prot, EV
warnx("bn2string");
else if ((exp = bn2string(r->e)) == NULL)
warnx("bn2string");
- else if ((*head = json_fmt_header_rsa(exp, mod)) == NULL)
- warnx("json_fmt_header_rsa");
- else if ((*prot = json_fmt_protected_rsa(exp, mod, nonce)) == NULL)
- warnx("json_fmt_protected_rsa");
+ else if ((*head = json_fmt_header_key(exp, mod)) == NULL)
+ warnx("json_fmt_header_key");
+ else if ((*prot = json_fmt_protected_key(exp, mod, nonce)) == NULL)
+ warnx("json_fmt_protected_key");
else
rc = 1;
@@ -338,7 +338,7 @@ acctproc(int netsock, const char *acctke
goto out;
dodbg("%s: generated RSA account key", acctkey);
} else {
- if ((pkey = rsa_key_load(f, acctkey)) == NULL)
+ if ((pkey = key_load(f, acctkey)) == NULL)
goto out;
doddbg("%s: loaded RSA account key", acctkey);
}
Index: acme-client.1
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v
retrieving revision 1.29
diff -u -p -r1.29 acme-client.1
--- acme-client.1 3 Feb 2019 20:39:35 - 1.29
+++ acme-client.1 4 Jun 2019 13:50:28 -
@@ -79,7 +79,9 @@ The options are as follows:
.It Fl A
Create a new RSA account key if one does not already exist.
.It Fl D
-Create a new RSA domain key if one does not already exist.
+Create a new (RSA) domain key if one does not already exist.
+.It Fl E
+Switch the new domain key algorithm to ECDSA instead of RSA.
.It Fl F
Force certificate renewal, even if it's too soon.
.It Fl f Ar configfile
Index: ecdsa.h
===
RCS file: ecdsa.h
diff -N ecdsa.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ecdsa.h 4 Jun 2019 13:50:28 -
@@ -0,0 +1,22 @@
+/* $Id: rsa.h,v 1.1 2016/08/31 22:01:42 florian Exp $ */
+/*
+ * Copyright (c) 2019 Renaud Allard
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+#ifndef ECDSA_H
+#define ECDSA_H
+
+EVP_PKEY *ec_key_create(FILE *, const char *);
+
+#endif /* ! ECDSA_H */
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/acme-client/extern.h,v
retrieving revision 1.10
diff -u -p -r1.10 extern.h
--- extern.h 31 Jan 2019 15:55:48 - 1.10
+++ extern.h 4 Jun 2019 13:50:28 -
@@ -18,6 +18,7 @@
#define EXTERN_H
#include "parse.h"
+#include "stdbool.h"
#define MAX_SERVERS_DNS 8
@@ -240,11 +241,11 @@ char *json_fmt_challenge(const char *,
char *json_fmt_new
Re: [Patch] Driver for Keyspan USA-19HS
On Mon, Jun 03, 2019 at 11:44:37PM -0400, Cody Cutler wrote: > Hi jcs and tech, the following is a patch which implements jcs's feedback and > adds a man page. > > Note that one must execute `make -C sys/dev/usb' after applying to build. > > Thanks! > > diff --git share/man/man4/Makefile share/man/man4/Makefile > index 7d470b6ca47..999621c7889 100644 > --- share/man/man4/Makefile > +++ share/man/man4/Makefile > @@ -71,7 +71,7 @@ MAN=aac.4 abcrtc.4 ac97.4 acphy.4 acrtc.4 \ > tlphy.4 thmc.4 tpm.4 tqphy.4 trm.4 trunk.4 tsl.4 tty.4 tun.4 tap.4 \ > twe.4 \ > txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ > - ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 uslhcom.4 \ > + ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ > uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uipaq.4 \ > uk.4 ukbd.4 \ > diff --git share/man/man4/ucom.4 share/man/man4/ucom.4 > index e14df75675b..bde53a2c5e1 100644 > --- share/man/man4/ucom.4 > +++ share/man/man4/ucom.4 > @@ -42,6 +42,7 @@ > .Cd "ucom* at ucycom?" # Cypress > .Cd "ucom* at uftdi?"# FTDI > .Cd "ucom* at uipaq?"# iPAQ > +.Cd "ucom* at ukspan?" # Keyspan > .Cd "ucom* at umcs?" # MosChip Semiconductor multiport > .Cd "ucom* at umct?" # MCT > .Cd "ucom* at umodem?" # Standardized umodem > diff --git share/man/man4/ukspan.4 share/man/man4/ukspan.4 > new file mode 100644 > index 000..2b98f1efcb5 > --- /dev/null > +++ share/man/man4/ukspan.4 > @@ -0,0 +1,39 @@ > +.\" Copyright (c) 2019 Cody Cutler > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate$ > +.Dt UKSPAN 4 > +.Os > +.Sh NAME > +.Nm ukspan > +.Nd Keyspan USB serial adapter > +.Sh SYNOPSIS > +.Cd "ukspan* at uhub?" > +.Cd "ucom* at ukspan?" > +.Sh DESCRIPTION > +The > +.Nm > +driver supports the TrippLite Keyspan USA-19HS serial adapter, which is made > +accessible through > +.Xr ucom 4 . > +.Sh SEE ALSO > +.Xr tty 4 , > +.Xr ucom 4 , > +.Xr uhub 4 , > +.Xr usb 4 > +.Sh AUTHORS > +The > +.Nm > +driver was written by > +.An Cody Cutler Aq Mt ccut...@csail.mit.edu . > diff --git share/man/man4/usb.4 share/man/man4/usb.4 > index 520d513f5b1..81a4abd8c70 100644 > --- share/man/man4/usb.4 > +++ share/man/man4/usb.4 > @@ -188,6 +188,8 @@ FTDI USB serial adapter > iPAQ USB units > .It Xr ulpt 4 > USB printer support > +.It Xr ukspan 4 > +Keyspan serial adapter > .It Xr umcs 4 > MosChip Semiconductor based USB multiport serial adapter > .It Xr umct 4 > diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC > index ad192f4ea1d..5b5d37c24e2 100644 > --- sys/arch/amd64/conf/GENERIC > +++ sys/arch/amd64/conf/GENERIC > @@ -224,6 +224,8 @@ uvscom* at uhub?# SUNTAC Slipper U > VS-10U serial > ucom*at uvscom? > ubsa*at uhub?# Belkin serial adapter > ucom*at ubsa? > +ukspan* at uhub? # Keyspan USA19HS serial adapter > +ucom*at ukspan? > uftdi* at uhub?# FTDI FT8U100AX serial adapter > ucom*at uftdi? > uplcom* at uhub? # I/O DATA USB-RSAQ2 serial adapter > diff --git sys/dev/usb/files.usb sys/dev/usb/files.usb > index 1036cf36232..29bc1205540 100644 > --- sys/dev/usb/files.usb > +++ sys/dev/usb/files.usb > @@ -317,6 +317,11 @@ device ubsa: ucombus > attach ubsa at uhub > file dev/usb/ubsa.c ubsa > > +# Keyspan USA19HS serial > +device ukspan: ucombus > +attach ukspan at uhub > +file dev/usb/ukspan.cukspan > + > # Silicon Laboratories CP210x serial > device uslcom: ucombus > attach uslcom at uhub > diff --git sys/dev/usb/ukspan.c sys/dev/usb/ukspan.c > new file mode 100644 > index 000..5f5e9583641 > --- /dev/null > +++ sys/dev/usb/ukspan.c > @@ -0,0 +1,594 @@ > +/* > + * Copyright (c) 2019 Cody Cutler > + * > + * Permission to use, copy, modify, and distribute this software for any > + * purpose with or without fee is hereby granted, provided that the above > + * copyright notice and this permission notice appear in all copies. > + * > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRAN
Re: Pump my sched: fewer SCHED_LOCK() & kill p_priority
On Mon, Jun 03, 2019 at 11:50:14AM +0200, Solene Rapenne wrote: > On Sat, Jun 01, 2019 at 06:55:20PM -0300, Martin Pieuchot wrote: > > Diff below exists mainly for documentation and test purposes. If > > you're not interested about how to break the scheduler internals in > > pieces, don't read further and go straight to testing! > > I'm running it since a few hours. > > - games/gzdoom feels smoother with this patch (stuttering was certainly > related to audio) > - mpd playback doesn't seem interrupted under heavy load as it > occasionnaly did > > this may be coincidences or placebo effect. > On one of my machines, I'm running this diff and the unlock more syscalls diff (the one from mpi@ that claudio@ recently reposted). It does indeed seem more responsive (unclear which diff is doing this, though). The combination is also stable without anything out of the ordinary. -ml
Re: [patch] rsync: fix another double close socket descriptor
Christian Weisgerber(na...@mips.inka.de) on 2019.06.03 14:39:14 -:
> On 2019-06-02, Hiltjo Posthuma wrote:
>
> > I noticed when using openrsync with a remote and a ssh_prog set (-e option)
> > the
> > socket is closed twice also.
>
> Yes, we need to decide whether rsync_socket() should close the
> socket itself or not. Since rsync_socket() doesn't open the socket,
> I guess it shouldn't close it either. Matches rsync_client().
>
> ok?
ok
>
> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/rsync/main.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 main.c
> --- main.c28 May 2019 18:20:30 - 1.46
> +++ main.c3 Jun 2019 14:30:06 -
> @@ -428,8 +428,10 @@ main(int argc, char *argv[])
>
> if (fargs->remote && opts.ssh_prog == NULL) {
> assert(fargs->mode == FARGS_RECEIVER);
> - if ((rc = rsync_connect(&opts, &sd, fargs)) == 0)
> + if ((rc = rsync_connect(&opts, &sd, fargs)) == 0) {
> rc = rsync_socket(&opts, sd, fargs);
> + close(sd);
> + }
> exit(rc);
> }
>
> @@ -484,14 +486,7 @@ main(int argc, char *argv[])
> break;
> }
>
> - /*
> - * If the client has an error and exits, the server may be
> - * sitting around waiting to get data while we waitpid().
> - * So close the connection here so that they don't hang.
> - */
> -
> - if (rc)
> - close(fds[0]);
> + close(fds[0]);
>
> if (waitpid(child, &st, 0) == -1)
> err(1, "waitpid");
> Index: socket.c
> ===
> RCS file: /cvs/src/usr.bin/rsync/socket.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 socket.c
> --- socket.c 8 May 2019 21:30:11 - 1.24
> +++ socket.c 3 Jun 2019 14:26:44 -
> @@ -455,6 +455,5 @@ rsync_socket(const struct opts *opts, in
> rc = 0;
> out:
> free(args);
> - close(sd);
> return rc;
> }
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
Re: if_netisr(): trade NET_LOCK() for NET_RLOCK()
Hello, I see, I owe some clarification to share wider context of this change. On Tue, Jun 04, 2019 at 10:32:57AM -0300, Martin Pieuchot wrote: > On 04/06/19(Tue) 01:37, Alexandr Nedvedicky wrote: > > Hello, > > > > diff below is just cosmetic change, which has no impact on current > > functionality, because there is just single network task to deliver packets > > to > > IP stack. I just want to push this small change to tree to minimize delta > > between current and my experimental branch. > > But why is it fine? currently all packets reaching IP stack are processed by if_netisr(), which runs as a task. The task pops up a packet from its queue (a.k.a. taskq) and passes the packet to corresponding xintr() handler for further processing. We still have a single taskq (see NET_TASKQ defined as 1 in net/if.c), hence there is just one instance of if_netisr() running. Therefore I say 'the change has no impact'. We still need to make sure the network stack is ready to deal with multiple tasks for local bound packets. > Is it because the read version of the netlock is > enough to protect the packet processing path? from network stack point of view the packets acquire netlock as readers as they do not perform any changes to network subsystem configuration. > Or is it because it > guarantees that no ioctl will be executed in the meantime? yes, the purpose of netlock is to synchronize packets with ioctl() operations, which change configuration of networks stack (e.g. adding/removing interface). > And why do > we need that? To parallelise the packet processing path? correct. the plan is to have more netisr tasks to process packets. those will run in parallel/concurrently as netlock readers. we still have to make sure the network stack is able to run on multiple tasks for local bound packets. > > ok mpi@ :) thanks regards sashan
Re: [patch] use acme-client to sign certificated with ecdsa keys
On Tue, Jun 04, 2019 at 03:54:11PM +0200, Renaud Allard wrote:
>
>
> On 6/3/19 11:53 AM, Renaud Allard wrote:
> > > >
> > > > On 5/29/19 9:58 AM, Florian Obser wrote:
> > > > > On Wed, May 22, 2019 at 01:33:11PM +0200, Renaud Allard wrote:
> > > > > > The key needs to be generated manually
> > > > > > i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem
> > > > >
> > > > > why not let acme-client generate the key?
> > > >
> > >
> > > Here is a more complete diff where you can use the -E switch to
> > > generate a ECDSA key instead of the RSA one.
>
> I refined a little bit the patch to not put ecdsa functions into rsa.c. So I
> renamed rsa.c to key.c and removed the rsa references to functions which
> apply to both rsa and ecdsa.
>
reads, builds and works fine for me
a couple comments inlined
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/Makefile,v
> retrieving revision 1.8
> diff -u -p -r1.8 Makefile
> --- Makefile 3 Jul 2017 22:21:47 - 1.8
> +++ Makefile 4 Jun 2019 13:50:28 -
> @@ -2,7 +2,7 @@
> PROG=acme-client
> SRCS=acctproc.c base64.c certproc.c chngproc.c dbg.c
> dnsproc.c
> SRCS+= fileproc.c http.c jsmn.c json.c keyproc.c main.c
> netproc.c
> -SRCS+= parse.y revokeproc.c rsa.c util.c
> +SRCS+= parse.y revokeproc.c key.c util.c
>
> MAN= acme-client.1 acme-client.conf.5
>
> Index: acctproc.c
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 acctproc.c
> --- acctproc.c28 Jul 2018 15:25:23 - 1.12
> +++ acctproc.c4 Jun 2019 13:50:28 -
> @@ -82,8 +82,8 @@ op_thumb_rsa(EVP_PKEY *pkey)
> warnx("bn2string");
> else if ((exp = bn2string(r->e)) == NULL)
> warnx("bn2string");
> - else if ((json = json_fmt_thumb_rsa(exp, mod)) == NULL)
> - warnx("json_fmt_thumb_rsa");
> + else if ((json = json_fmt_thumb_key(exp, mod)) == NULL)
> + warnx("json_fmt_thumb_key");
>
> free(exp);
> free(mod);
> @@ -175,10 +175,10 @@ op_sign_rsa(char **head, char **prot, EV
> warnx("bn2string");
> else if ((exp = bn2string(r->e)) == NULL)
> warnx("bn2string");
> - else if ((*head = json_fmt_header_rsa(exp, mod)) == NULL)
> - warnx("json_fmt_header_rsa");
> - else if ((*prot = json_fmt_protected_rsa(exp, mod, nonce)) == NULL)
> - warnx("json_fmt_protected_rsa");
> + else if ((*head = json_fmt_header_key(exp, mod)) == NULL)
> + warnx("json_fmt_header_key");
> + else if ((*prot = json_fmt_protected_key(exp, mod, nonce)) == NULL)
> + warnx("json_fmt_protected_key");
> else
> rc = 1;
>
> @@ -338,7 +338,7 @@ acctproc(int netsock, const char *acctke
> goto out;
> dodbg("%s: generated RSA account key", acctkey);
> } else {
> - if ((pkey = rsa_key_load(f, acctkey)) == NULL)
> + if ((pkey = key_load(f, acctkey)) == NULL)
> goto out;
> doddbg("%s: loaded RSA account key", acctkey);
> }
> Index: acme-client.1
> ===
> RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v
> retrieving revision 1.29
> diff -u -p -r1.29 acme-client.1
> --- acme-client.1 3 Feb 2019 20:39:35 - 1.29
> +++ acme-client.1 4 Jun 2019 13:50:28 -
> @@ -79,7 +79,9 @@ The options are as follows:
> .It Fl A
> Create a new RSA account key if one does not already exist.
> .It Fl D
> -Create a new RSA domain key if one does not already exist.
> +Create a new (RSA) domain key if one does not already exist.
why is RSA in parenthesis here ?
> +.It Fl E
> +Switch the new domain key algorithm to ECDSA instead of RSA.
the E option should be added to the SYNOPSIS too
> .It Fl F
> Force certificate renewal, even if it's too soon.
> .It Fl f Ar configfile
> Index: ecdsa.h
> ===
> RCS file: ecdsa.h
> diff -N ecdsa.h
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ ecdsa.h 4 Jun 2019 13:50:28 -
> @@ -0,0 +1,22 @@
> +/* $Id: rsa.h,v 1.1 2016/08/31 22:01:42 florian Exp $ */
> +/*
> + * Copyright (c) 2019 Renaud Allard
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIA
Re: [patch] use acme-client to sign certificated with ecdsa keys
On 6/5/19 8:20 AM, Gilles Chehade wrote:
On Tue, Jun 04, 2019 at 03:54:11PM +0200, Renaud Allard wrote:
On 6/3/19 11:53 AM, Renaud Allard wrote:
On 5/29/19 9:58 AM, Florian Obser wrote:
why not let acme-client generate the key?
Here is a more complete diff where you can use the -E switch to
generate a ECDSA key instead of the RSA one.
I refined a little bit the patch to not put ecdsa functions into rsa.c. So I
renamed rsa.c to key.c and removed the rsa references to functions which
apply to both rsa and ecdsa.
reads, builds and works fine for me
a couple comments inlined
I removed the parenthesis and used another wording, removed the RSA from
a "Load RSA key" as it might not be RSA and added E to the SYNOPSYS.
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/acme-client/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile 3 Jul 2017 22:21:47 - 1.8
+++ Makefile 5 Jun 2019 06:37:00 -
@@ -2,7 +2,7 @@
PROG= acme-client
SRCS= acctproc.c base64.c certproc.c chngproc.c dbg.c dnsproc.c
SRCS+= fileproc.c http.c jsmn.c json.c keyproc.c main.c netproc.c
-SRCS+= parse.y revokeproc.c rsa.c util.c
+SRCS+= parse.y revokeproc.c key.c util.c
MAN= acme-client.1 acme-client.conf.5
Index: acctproc.c
===
RCS file: /cvs/src/usr.sbin/acme-client/acctproc.c,v
retrieving revision 1.12
diff -u -p -r1.12 acctproc.c
--- acctproc.c 28 Jul 2018 15:25:23 - 1.12
+++ acctproc.c 5 Jun 2019 06:37:00 -
@@ -82,8 +82,8 @@ op_thumb_rsa(EVP_PKEY *pkey)
warnx("bn2string");
else if ((exp = bn2string(r->e)) == NULL)
warnx("bn2string");
- else if ((json = json_fmt_thumb_rsa(exp, mod)) == NULL)
- warnx("json_fmt_thumb_rsa");
+ else if ((json = json_fmt_thumb_key(exp, mod)) == NULL)
+ warnx("json_fmt_thumb_key");
free(exp);
free(mod);
@@ -175,10 +175,10 @@ op_sign_rsa(char **head, char **prot, EV
warnx("bn2string");
else if ((exp = bn2string(r->e)) == NULL)
warnx("bn2string");
- else if ((*head = json_fmt_header_rsa(exp, mod)) == NULL)
- warnx("json_fmt_header_rsa");
- else if ((*prot = json_fmt_protected_rsa(exp, mod, nonce)) == NULL)
- warnx("json_fmt_protected_rsa");
+ else if ((*head = json_fmt_header_key(exp, mod)) == NULL)
+ warnx("json_fmt_header_key");
+ else if ((*prot = json_fmt_protected_key(exp, mod, nonce)) == NULL)
+ warnx("json_fmt_protected_key");
else
rc = 1;
@@ -338,7 +338,7 @@ acctproc(int netsock, const char *acctke
goto out;
dodbg("%s: generated RSA account key", acctkey);
} else {
- if ((pkey = rsa_key_load(f, acctkey)) == NULL)
+ if ((pkey = key_load(f, acctkey)) == NULL)
goto out;
doddbg("%s: loaded RSA account key", acctkey);
}
Index: acme-client.1
===
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v
retrieving revision 1.29
diff -u -p -r1.29 acme-client.1
--- acme-client.1 3 Feb 2019 20:39:35 - 1.29
+++ acme-client.1 5 Jun 2019 06:37:00 -
@@ -22,7 +22,7 @@
.Nd ACME client
.Sh SYNOPSIS
.Nm acme-client
-.Op Fl ADFnrv
+.Op Fl ADEFnrv
.Op Fl f Ar configfile
.Ar domain
.Sh DESCRIPTION
@@ -79,7 +79,9 @@ The options are as follows:
.It Fl A
Create a new RSA account key if one does not already exist.
.It Fl D
-Create a new RSA domain key if one does not already exist.
+Create a new domain key if one does not already exist. Defaults to RSA.
+.It Fl E
+Switch the new domain key algorithm to ECDSA instead of RSA.
.It Fl F
Force certificate renewal, even if it's too soon.
.It Fl f Ar configfile
Index: ecdsa.h
===
RCS file: ecdsa.h
diff -N ecdsa.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ ecdsa.h 5 Jun 2019 06:37:00 -
@@ -0,0 +1,22 @@
+/* $Id: rsa.h,v 1.1 2016/08/31 22:01:42 florian Exp $ */
+/*
+ * Copyright (c) 2019 Renaud Allard
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHORS DISCLAIM ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+#ifndef ECDSA_H
+#define ECDSA_H
+
+EVP_PKEY *ec_key_create(FILE *, const char *);
+
+#endif /* ! ECDSA_H */
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/acme-client/extern.h,v
retrieving revision 1
