Re: iwm 11n mode roaming fix needs testing

[Björn Ketelaars]

On Sun 03/10/2021 22:49, Stefan Sperling wrote:
> While working on 40MHz support for iwm(4) I noticed that throughput
> dropped from 200 Mbit/s to about 2 Mbit/s whenever the laptop roamed
> between APs. Sometimes traffic even stalled completely.
> The patch below fixes this problem for me.


$ dmesg | grep iwm0
iwm0 at pci2 dev 0 function 0 "Intel AC 8260" rev 0x3a, msi
iwm0: hw rev 0x200, fw ver 36.ca7b901d.0, address f4:8c:50:7c:6b:90


Without your diff, before and after roaming:

bandwidth min/avg/max/std-dev = 52.712/83.545/102.649/11.431 Mbps
bandwidth min/avg/max/std-dev = 0.000/1.842/2.124/0.306 Mbps

Oct  4 19:02:41 zeus /bsd: iwm0: roaming from 74:ac:b9:6e:fc:f1 chan 52 to 
f4:92:bf:5e:68:67 chan 36
Oct  4 19:02:41 zeus /bsd: iwm0: RUN -> AUTH
Oct  4 19:02:41 zeus /bsd: iwm0: sending auth to f4:92:bf:5e:68:67 on channel 
36 mode 11a
Oct  4 19:02:41 zeus /bsd: iwm0: AUTH -> ASSOC
Oct  4 19:02:41 zeus /bsd: iwm0: sending assoc_req to f4:92:bf:5e:68:67 on 
channel 36 mode 11a
Oct  4 19:02:41 zeus /bsd: iwm0: received msg 1/4 of the 4-way handshake from 
f4:92:bf:5e:68:67
Oct  4 19:02:41 zeus /bsd: iwm0: sending msg 2/4 of the 4-way handshake to 
f4:92:bf:5e:68:67
Oct  4 19:02:41 zeus /bsd: iwm0: ASSOC -> RUN
Oct  4 19:02:41 zeus /bsd: iwm0: associated with f4:92:bf:5e:68:67 ssid 
"rfc1918" channel 36 start MCS 0 long preamble short slot time HT enabled


With your diff, before and after roaming:

bandwidth min/avg/max/std-dev = 51.428/87.759/103.712/13.885 Mbps
bandwidth min/avg/max/std-dev = 37.244/79.405/102.738/17.689 Mbps

Oct  4 19:10:10 zeus /bsd: iwm0: roaming from f4:92:bf:5e:68:67 chan 36 to 
74:ac:b9:6e:fc:f1 chan 52
Oct  4 19:10:10 zeus /bsd: iwm0: RUN -> AUTH
Oct  4 19:10:10 zeus /bsd: iwm0: sending auth to 74:ac:b9:6e:fc:f1 on channel 
52 mode 11a
Oct  4 19:10:10 zeus /bsd: iwm0: AUTH -> ASSOC
Oct  4 19:10:10 zeus /bsd: iwm0: sending assoc_req to 74:ac:b9:6e:fc:f1 on 
channel 52 mode 11a
Oct  4 19:10:10 zeus /bsd: iwm0: ASSOC -> RUN
Oct  4 19:10:10 zeus /bsd: iwm0: associated with 74:ac:b9:6e:fc:f1 ssid 
"rfc1918" channel 52 start MCS 0 long preamble short slot time HT enabled


Also here, works as advertised!

Re: iwm(4): use new firmware images with fragattack fixes

[Björn Ketelaars]

On Tue 25/05/2021 15:48, Stefan Sperling wrote:
> This patch allows iwm(4) to use new firmware images which are part
> of the iwm-20210512 firmware package, available via fw_update (you
> need to run fw_update *before* booting with this patch).
> 
> The new firmware images were published right after the fragattacks
> embargo period ended. An advisory was published by Intel:
> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html
> 
> I have tested the following cards successfully:
>   7265, 8265, 9260, 9560
> 
> I cannot test any other devices myself right now; help with testing this
> patch would be much appreciated. It is likely that all devices will work.
> But I would still prefer to see test reports for the following cards before
> committing this patch:
>   7260, 3160, 3165, 3168, 8260
> 
> The 7260 and 3160 cards did not receive firmware updates from Intel. Which
> could be good or bad news, depending on whether the devices are vulnerable
> to fragattacks. The fragattacks test tools might shed light on this if you
> are curious. I'd be interested to learn more if you have test results or
> any other solid information regarding this.

iwm0 at pci2 dev 0 function 0 "Intel AC 8260" rev 0x3a, msi
iwm0: hw rev 0x200, fw ver 36.ca7b901d.0

Tested:
- Downloading some big files
- Doing stuff in a couple of SSH sessions
- Roaming between some APs

No regression...so far

Re: sys/ufs/ffs/ffs_softdep.c: use TAILQ_CONCAT(3)

[Björn Ketelaars]

On Mon 27/01/2020 20:01, Björn Ketelaars wrote:
> cheloha@ recently replaced custom TAILQ concatenation loops in pool(9)
> with TAILQ_CONCAT(3) [0]. I was curious as how often these custom
> concatenations loops are used and grepped src. I found a couple of them.
> One being in sys/ufs/ffs/ffs_softdep.c, and the others in userland.
> 
> I build a kernel using the diff below and gave it a spin. So far it
> didn't blow up.

OK?

Diff enclosed again for your convenience.


diff --git sys/ufs/ffs/ffs_softdep.c sys/ufs/ffs/ffs_softdep.c
index 2f2a2edc224..d0fd3a15278 100644
--- sys/ufs/ffs/ffs_softdep.c
+++ sys/ufs/ffs/ffs_softdep.c
@@ -4486,10 +4486,7 @@ merge_inode_lists(struct inodedep *inodedep)
}
newadp = TAILQ_FIRST(>id_newinoupdt);
}
-   while ((newadp = TAILQ_FIRST(>id_newinoupdt)) != NULL) {
-   TAILQ_REMOVE(>id_newinoupdt, newadp, ad_next);
-   TAILQ_INSERT_TAIL(>id_inoupdt, newadp, ad_next);
-   }
+   TAILQ_CONCAT(>id_inoupdt, >id_newinoupdt, ad_next);
 }
 
 /*

sbin/pfctl: use TAILQ_CONCAT(3)

[Björn Ketelaars]

Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).

Comments/OK?


diff --git sbin/pfctl/parse.y sbin/pfctl/parse.y
index d524f9e92bc..67de79215e4 100644
--- sbin/pfctl/parse.y
+++ sbin/pfctl/parse.y
@@ -5637,16 +5637,11 @@ mv_rules(struct pf_ruleset *src, struct pf_ruleset *dst)
 {
struct pf_rule *r;
 
-   while ((r = TAILQ_FIRST(src->rules.active.ptr)) != NULL) {
-   TAILQ_REMOVE(src->rules.active.ptr, r, entries);
-   TAILQ_INSERT_TAIL(dst->rules.active.ptr, r, entries);
+   TAILQ_FOREACH(r, src->rules.active.ptr, entries)
dst->anchor->match++;
-   }
+   TAILQ_CONCAT(dst->rules.active.ptr, src->rules.active.ptr, entries);
src->anchor->match = 0;
-   while ((r = TAILQ_FIRST(src->rules.inactive.ptr)) != NULL) {
-   TAILQ_REMOVE(src->rules.inactive.ptr, r, entries);
-   TAILQ_INSERT_TAIL(dst->rules.inactive.ptr, r, entries);
-   }
+   TAILQ_CONCAT(dst->rules.inactive.ptr, src->rules.inactive.ptr, entries);
 }
 
 void
diff --git sbin/pfctl/pfctl_optimize.c sbin/pfctl/pfctl_optimize.c
index 3526dcce962..fe74c435980 100644
--- sbin/pfctl/pfctl_optimize.c
+++ sbin/pfctl/pfctl_optimize.c
@@ -687,11 +687,7 @@ reorder_rules(struct pfctl *pf, struct superblock *block, 
int depth)
 * it based on a more optimal skipstep order.
 */
TAILQ_INIT();
-   while ((por = TAILQ_FIRST(>sb_rules))) {
-   TAILQ_REMOVE(>sb_rules, por, por_entry);
-   TAILQ_INSERT_TAIL(, por, por_entry);
-   }
-
+   TAILQ_CONCAT(, >sb_rules, por_entry);
 
while (!TAILQ_EMPTY()) {
largest = 1;
@@ -712,11 +708,7 @@ reorder_rules(struct pfctl *pf, struct superblock *block, 
int depth)
 * Nothing useful left.  Leave remaining rules in order.
 */
DEBUG("(%d) no more commonality for skip steps", depth);
-   while ((por = TAILQ_FIRST())) {
-   TAILQ_REMOVE(, por, por_entry);
-   TAILQ_INSERT_TAIL(>sb_rules, por,
-   por_entry);
-   }
+   TAILQ_CONCAT(>sb_rules, , por_entry);
} else {
/*
 * There is commonality.  Extract those common rules
@@ -830,10 +822,7 @@ block_feedback(struct pfctl *pf, struct superblock *block)
 */
 
TAILQ_INIT();
-   while ((por1 = TAILQ_FIRST(>sb_rules)) != NULL) {
-   TAILQ_REMOVE(>sb_rules, por1, por_entry);
-   TAILQ_INSERT_TAIL(, por1, por_entry);
-   }
+   TAILQ_CONCAT(, >sb_rules, por_entry);
 
while ((por1 = TAILQ_FIRST()) != NULL) {
TAILQ_REMOVE(, por1, por_entry);

usr.sbin/snmpd: use TAILQ_CONCAT(3)

[Björn Ketelaars]

Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).

Comments/OK?


diff --git usr.sbin/snmpd/control.c usr.sbin/snmpd/control.c
index 54b58bbb7b6..dda18c1bad5 100644
--- usr.sbin/snmpd/control.c
+++ usr.sbin/snmpd/control.c
@@ -487,10 +487,7 @@ control_dispatch_agentx(int fd, short event, void *arg)
TAILQ_INSERT_TAIL(, miboid, o_list);
} while (++oid.bo_id[rhdr.subrange] <= ubound);
 
-   while ((miboid = TAILQ_FIRST()) != NULL) {
-   TAILQ_REMOVE(, miboid, o_list);
-   TAILQ_INSERT_TAIL(>oids, miboid, o_list);
-   }
+   TAILQ_CONCAT(>oids, , o_list);
  dodone:
break;
}

usr.sbin/bgpd: use TAILQ_CONCAT(3)

[Björn Ketelaars]

Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).

Comments/OK?


diff --git usr.sbin/bgpd/config.c usr.sbin/bgpd/config.c
index cb43afb81fe..fc81a3efd3b 100644
--- usr.sbin/bgpd/config.c
+++ usr.sbin/bgpd/config.c
@@ -195,7 +195,6 @@ void
 merge_config(struct bgpd_config *xconf, struct bgpd_config *conf)
 {
struct listen_addr  *nla, *ola, *next;
-   struct network  *n;
struct peer *p, *np, *nextp;
 
/*
@@ -250,10 +249,7 @@ merge_config(struct bgpd_config *xconf, struct bgpd_config 
*conf)
 
/* switch the network statements, but first remove the old ones */
free_networks(>networks);
-   while ((n = TAILQ_FIRST(>networks)) != NULL) {
-   TAILQ_REMOVE(>networks, n, entry);
-   TAILQ_INSERT_TAIL(>networks, n, entry);
-   }
+   TAILQ_CONCAT(>networks, >networks, entry);
 
/* switch the l3vpn configs, first remove the old ones */
free_l3vpns(>l3vpns);

usr.sbin/ldapd: use TAILQ_CONCAT(3)

[Björn Ketelaars]

Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).

Comments/OK?


diff --git usr.sbin/ldapd/search.c usr.sbin/ldapd/search.c
index 3033823eb18..887af5fb6a1 100644
--- usr.sbin/ldapd/search.c
+++ usr.sbin/ldapd/search.c
@@ -764,11 +764,8 @@ search_planner(struct namespace *ns, struct ber_element 
*filter)
/* Select an index to use. */
TAILQ_FOREACH(arg, >args, next) {
if (arg->indexed) {
-   while ((indx = TAILQ_FIRST(>indices))) {
-   TAILQ_REMOVE(>indices, indx, next);
-   TAILQ_INSERT_TAIL(>indices, indx,
-   next);
-   }
+   TAILQ_CONCAT(>indices, >indices,
+   next);
plan->indexed = arg->indexed;
break;
}
@@ -796,11 +793,9 @@ search_planner(struct namespace *ns, struct ber_element 
*filter)
plan->indexed = 0;
break;
}
-   while ((indx = TAILQ_FIRST(>indices))) {
-   TAILQ_REMOVE(>indices, indx, next);
-   TAILQ_INSERT_TAIL(>indices, indx,next);
+   TAILQ_FOREACH(indx, >indices, next)
plan->indexed++;
-   }
+   TAILQ_CONCAT(>indices, >indices, next);
}
break;
case LDAP_FILT_NOT:

sbin/unwind: use TAILQ_CONCAT(3)

[Björn Ketelaars]

Replace custom TAILQ concatenation loop by TAILQ_CONCAT(3).

Comments/OK?


diff --git sbin/unwind/frontend.c sbin/unwind/frontend.c
index b64036c4332..d2b69084db7 100644
--- sbin/unwind/frontend.c
+++ sbin/unwind/frontend.c
@@ -1011,10 +1011,7 @@ merge_tas(struct trust_anchor_head *newh, struct 
trust_anchor_head *oldh)
 
if (chg) {
free_tas(oldh);
-   while((i = TAILQ_FIRST(newh)) != NULL) {
-   TAILQ_REMOVE(newh, i, entry);
-   TAILQ_INSERT_TAIL(oldh, i, entry);
-   }
+   TAILQ_CONCAT(oldh, newh, entry);
} else {
free_tas(newh);
}
diff --git sbin/unwind/resolver.c sbin/unwind/resolver.c
index 15d2c90b1e8..c12bdbdab26 100644
--- sbin/unwind/resolver.c
+++ sbin/unwind/resolver.c
@@ -1650,10 +1650,7 @@ replace_forwarders(struct uw_forwarder_head *new_list, 
struct
free(uw_forwarder);
}
 
-   while ((uw_forwarder = TAILQ_FIRST(new_list)) != NULL) {
-   TAILQ_REMOVE(new_list, uw_forwarder, entry);
-   TAILQ_INSERT_TAIL(old_list, uw_forwarder, entry);
-   }
+   TAILQ_CONCAT(old_list, new_list, entry);
 }
 
 int

sys/ufs/ffs/ffs_softdep.c: use TAILQ_CONCAT(3)

[Björn Ketelaars]

cheloha@ recently replaced custom TAILQ concatenation loops in pool(9)
with TAILQ_CONCAT(3) [0]. I was curious as how often these custom
concatenations loops are used and grepped src. I found a couple of them.
One being in sys/ufs/ffs/ffs_softdep.c, and the others in userland.

I build a kernel using the diff below and gave it a spin. So far it
didn't blow up.

I was wondering if it makes sense to address these custom concatenations
and provide diffs, or is this considered nitpicking?


[0] 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/subr_pool.c.diff?r1=1.229=1.230


diff --git sys/ufs/ffs/ffs_softdep.c sys/ufs/ffs/ffs_softdep.c
index 2f2a2edc224..d0fd3a15278 100644
--- sys/ufs/ffs/ffs_softdep.c
+++ sys/ufs/ffs/ffs_softdep.c
@@ -4486,10 +4486,7 @@ merge_inode_lists(struct inodedep *inodedep)
}
newadp = TAILQ_FIRST(>id_newinoupdt);
}
-   while ((newadp = TAILQ_FIRST(>id_newinoupdt)) != NULL) {
-   TAILQ_REMOVE(>id_newinoupdt, newadp, ad_next);
-   TAILQ_INSERT_TAIL(>id_inoupdt, newadp, ad_next);
-   }
+   TAILQ_CONCAT(>id_inoupdt, >id_newinoupdt, ad_next);
 }
 
 /*

Re: unwind and split-horizon DNS

[Björn Ketelaars]

On Fri 29/11/2019 21:35, Otto Moerbeek wrote:
> On Fri, Nov 29, 2019 at 10:27:57AM +0100, Florian Obser wrote:
> 
> > On Fri, Nov 29, 2019 at 07:28:20AM +0100, Otto Moerbeek wrote:
> > > On Fri, Nov 29, 2019 at 07:02:27AM +0100, Björn Ketelaars wrote:
> > > > I experienced no regression while using the free wifi service of the
> > > > Dutch railways, which is known to do strange things with DNS.
> > > 
> > > Thanks for testing. The Dutch railways have been a great inspiration
> > > to unwind work, as florian@ can telll you :-)
> > 
> > They have got to be good at *something*. Not sure if it's their core
> > business to annoy the hell out of me, but hey...
> > 
> > Only joking, overall I'm quite happy with the Dutch railway. I use
> > them every work day and they get me where I need to go most of the
> > time.
> > 
> > -- 
> > I'm not entirely sure you are real.
> > 
> 
> And here's a rebased diff for your convenience,

The rebased diff results in a different behaviour than the first diff.
More precise, 'force acceptbogus forwarder' is not respected any more
resulting in issues with DNSSEC.

I compared the old- and the rebased diff and noticed that some bits have
been left out. Functionality is restored after applying the diff below.


diff --git sbin/unwind/unwind.c sbin/unwind/unwind.c
index 5a97dcccec4..4687a7cc122 100644
--- sbin/unwind/unwind.c
+++ sbin/unwind/unwind.c
@@ -675,6 +675,12 @@ merge_config(struct uw_conf *conf, struct uw_conf *xconf)
uw_forwarder, entry);
}
 
+   for (n = RB_MIN(force_tree, >force); n != NULL; n = nxt) {
+   nxt = RB_NEXT(force_tree, >force, n);
+   RB_REMOVE(force_tree, >force, n);
+   RB_INSERT(force_tree, >force, n);
+   }
+
free(xconf);
 }
 

Re: unwind and split-horizon DNS

[Björn Ketelaars]

On Thu 28/11/2019 16:16, Otto Moerbeek wrote:
> On Thu, Nov 28, 2019 at 03:26:34PM +0100, Otto Moerbeek wrote:
> 
> > Hi,
> > 
> > In many offices, split horizon DNS is used. This means that if you are
> > in the office you are supposed to use a specific resolver that will
> > hand out different results than when asking for the same name on the
> > rest of the internet.
> > 
> > Until now unwind could not really handle that, e.g. in recursing mode,
> > it would produce the view as from outside of the office. 
> > 
> > With this diff, it becomes possible to force using a specific resolver
> > when resolving names in specific domains.
> > 
> > For example, with this unwind.conf:
> > 
> > # Office forwarder
> > forwarder 1.2.3.4 
> > force forwarder {
> > myoffice.com
> > dmz.colocation.com
> > }
> > 
> > This will make unwind always use the mentioned forwarder for anything
> > under office.com or dmz.colocation.com. If the forwarder is dead,
> > regular resolving is done for these names and www.office.com will
> > likely return the external address.
> > 
> > Often split-horizon DNS breaks DNSSEC for these specific domains. If
> > that is the case, you can use
> > 
> > force acceptbogus forwarder { 
> > ... 
> > }
> > 
> > please test this,
> > 
> > -Otto
> > 
> > OAIndex: frontend.c
> 
> Dont know hwre that OA is comming from.  But it confuses patch, making
> it skip first part of the diff. Proper diff below:

@Home I'm redirecting all DNS requests to a machine with unbound serving
a couple of local-zones. unwind didn't work for me as these local-zones
would not resolve because of DNSSEC. With your diff, and the config
below unwind works perfect.

forwarder 10.0.0.1
force acceptbogus forwarder {
lan
}

I experienced no regression while using the free wifi service of the
Dutch railways, which is known to do strange things with DNS.

Re: call if_input only once per Rx interrupt from net80211

[Björn Ketelaars]

On Mon 09/09/2019 16:37, Stefan Sperling wrote:
> On Mon, Sep 09, 2019 at 03:10:04PM +0200, Stefan Sperling wrote:
> > The wifi stack currently calls if_input once per packet instead of once
> > per interrupt. To make the wifi layer play nicely with the network stack
> > we can split ieee80211_input() into two parts:
> 
> Updated diff which avoids purging the input queue at every state
> change, e.g. even during SCAN->SCAN. With this we only purge the
> queue if we're leaving RUN state or going back to INIT state.

I tested the updated diff by downloading a 400M file and looking at the
throughput and Idrop before, and after each run. I also tried different
values for net.link.ifrxq.pressure_drop.

$ dmesg | grep iwn
iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34:
msi, MIMO 2T2R, MoW, address

Before applying your diff:
pressure_drop   MB/sIdrop beforeIdrop after
8   3.0 21944117
32  4.3 41174345
128 4.1 43454345

After applying your diff:
pressure_drop   MB/sIdrop beforeIdrop after
8   5.4 33543606
32  6.2 36063606
128 6.2 36063606

It seems that your diff improves throughput, and reduces number of
Idrops. At higher values of net.link.ifrxq.pressure_drop throughput is
even higher and delta Idrop is 0.

Re: [patch] rsync: fix free() on uninitialized pointer with -rx and same device

[Björn Ketelaars]

On Thu 06/06/2019 00:37, Christian Weisgerber wrote:
> Christian Weisgerber:
> 
> > > To reproduce:
> > > 
> > >   mkdir -p /tmp/test /tmp/plop
> > >   openrsync -rx /tmp/test/ /tmp/plop/
> > > 
> > > Result:
> > > 
> > >   openrsync(3470) in free(): bogus pointer (double free?) 0x7f7dcdc8
> > >   Abort trap (core dumped)
> > > 
> > > The patch below fixes it and simplifies the logic:
> > 
> > I agree.  However, the (re)allocation of xdev also looks bogus.
> > 
> > How about this?
> > 
> > (Also, the realloc idiom is exactly the one the man page warns
> > against.  Do we care here?)
> 
> Well, let's not set a bad example.
> 

Guess I'm late to the party...I only read Hiltjo's mail, and the
replies, after being contacted offlist by naddy@.

Diff below is based on the latest diff from naddy@. Changes:
- reallocarray likes type_t, as such changes type of nxdev and i;
- use reallocarray instead of malloc as xdev is initialised as NULL.

diff --git flist.c flist.c
index e1f41b1a108..4c552ce3c5c 100644
--- flist.c
+++ flist.c
@@ -803,12 +803,12 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
 size_t *max)
 {
char*cargv[2], *cp;
-   int  rc = 0, nxdev = 0, flag, i;
+   int  rc = 0, flag;
FTS *fts;
FTSENT  *ent;
struct flist*f;
-   size_t   flsz = 0, stripdir;
-   dev_t   *xdev;
+   size_t   i, flsz = 0, nxdev = 0, stripdir;
+   dev_t   *newxdev, *xdev = NULL;
struct stat  st;
 
cargv[0] = root;
@@ -931,11 +931,6 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
!S_ISDIR(ent->fts_statp->st_mode))
continue;
 
-   if ((xdev = malloc(sizeof(dev_t))) == NULL) {
-   ERRX1("malloc");
-   goto out;
-   }
-
flag = 0;
for (i = 0; i < nxdev; i++)
if (xdev[i] == ent->fts_statp->st_dev) {
@@ -945,12 +940,12 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
if (flag)
continue;
 
-   if (nxdev)
-   if ((xdev = realloc(xdev, sizeof(dev_t))) ==
-   NULL) {
-   ERRX1("realloc");
-   goto out;
-   }
+   if ((newxdev = reallocarray(xdev, nxdev + 1,
+   sizeof(dev_t))) == NULL) {
+   ERRX1("reallocarray");
+   goto out;
+   }
+   xdev = newxdev;
xdev[nxdev] = ent->fts_statp->st_dev;
nxdev++;
}
@@ -1008,8 +1003,7 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
rc = 1;
 out:
fts_close(fts);
-   if (sess->opts->one_file_system)
-   free(xdev);
+   free(xdev);
return rc;
 }
 

Re: rsync: add --one-file-system

[Björn Ketelaars]

On Mon 01/04/2019 21:36, Björn Ketelaars wrote:
> Add --one-file-system, which prevents openrsync to cross filesystem
> boundaries. Option and behaviour is the same as GPL rsync.

Thanks for all the feedback!

New diff:
- Without the long option;
- Appropriate changes to usage and rsync.1;
- '-x' / '-xx' is passed to the other side;
- Special case for >1 '-x' option has been addressed;
- More important, permit fts to walk the whole filesystem and use dev_t
  comparison.

Florian's proposed scenario seems to work, as do several variants of
'-x' / '-xx' and '--delete'.

Comments?


diff --git usr.bin/rsync/extern.h usr.bin/rsync/extern.h
index 9ae08e7515e..038997aa164 100644
--- usr.bin/rsync/extern.h
+++ usr.bin/rsync/extern.h
@@ -117,6 +117,7 @@ struct  opts {
int  devices;   /* --devices */
int  specials;  /* --specials */
int  numeric_ids;   /* --numeric-ids */
+   int  one_file_system;   /* -x */
char*rsync_path;/* --rsync-path */
char*ssh_prog;  /* --rsh or -e */
char*port;  /* --port */
diff --git usr.bin/rsync/fargs.c usr.bin/rsync/fargs.c
index 55bf1b4b8af..a185d0c6a5d 100644
--- usr.bin/rsync/fargs.c
+++ usr.bin/rsync/fargs.c
@@ -106,6 +106,10 @@ fargs_cmdline(struct sess *sess, const struct fargs *f, 
size_t *skip)
addargs(, "-v");
if (sess->opts->verbose > 0)
addargs(, "-v");
+   if (sess->opts->one_file_system)
+   addargs(, "-x");
+   if (sess->opts->one_file_system > 1)
+   addargs(, "-x");
if (sess->opts->specials && !sess->opts->devices)
addargs(, "--specials");
if (!sess->opts->specials && sess->opts->devices)
diff --git usr.bin/rsync/flist.c usr.bin/rsync/flist.c
index b39599583e3..a3d1f338b74 100644
--- usr.bin/rsync/flist.c
+++ usr.bin/rsync/flist.c
@@ -804,11 +804,12 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
 size_t *max)
 {
char*cargv[2], *cp;
-   int  rc = 0;
+   int  rc = 0, nxdev = 0, flag, i;
FTS *fts;
FTSENT  *ent;
struct flist*f;
size_t   flsz = 0, stripdir;
+   dev_t   *xdev;
struct stat  st;
 
cargv[0] = root;
@@ -913,6 +914,48 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
continue;
}
 
+   /*
+* If rsync is told to avoid crossing a filesystem
+* boundary when recursing, then replace all mount point
+* directories with empty directories.  The latter is
+* prevented by telling rsync multiple times to avoid
+* crossing a filesystem boundary when recursing.
+* Replacing mount point directories is tricky. We need
+* to sort out which directories to include.  As such,
+* keep track of unique device inodes, and use these for
+* comparison.
+*/
+
+   if (sess->opts->one_file_system &&
+   ent->fts_statp->st_dev != st.st_dev) {
+   if (sess->opts->one_file_system > 1 ||
+   !S_ISDIR(ent->fts_statp->st_mode))
+   continue;
+
+   if ((xdev = malloc(sizeof(dev_t))) == NULL) {
+   ERRX1(sess, "malloc");
+   goto out;
+   }
+
+   flag = 0;
+   for (i = 0; i < nxdev; i++)
+   if (xdev[i] == ent->fts_statp->st_dev) {
+   flag = 1;
+   break;
+   }
+   if (flag)
+   continue;
+
+   if (nxdev)
+   if ((xdev = realloc(xdev, sizeof(dev_t))) ==
+   NULL) {
+   ERRX1(sess, "realloc");
+   goto out;
+   }
+   xdev[nxdev] = ent->fts_statp->st_dev;
+   nxdev++;
+   }
+
/* Allocate a new file entry. */
 
if (!flist_realloc(sess, fl, sz, max)) {
@@ -966,6 +1009,8 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
rc = 1;
 out:
fts_close(

rsync: add --one-file-system

[Björn Ketelaars]

Add --one-file-system, which prevents openrsync to cross filesystem
boundaries. Option and behaviour is the same as GPL rsync.

OK?


diff --git usr.bin/rsync/extern.h usr.bin/rsync/extern.h
index 12aceae566c..602cd24cede 100644
--- usr.bin/rsync/extern.h
+++ usr.bin/rsync/extern.h
@@ -117,6 +117,7 @@ struct  opts {
int  devices;   /* --devices */
int  specials;  /* --specials */
int  numeric_ids;   /* --numeric-ids */
+   int  one_file_system;   /* --one-file-system or -x */
char*rsync_path;/* --rsync-path */
char*ssh_prog;  /* --rsh or -e */
char*port;  /* --port */
diff --git usr.bin/rsync/flist.c usr.bin/rsync/flist.c
index b39599583e3..7f18966d85d 100644
--- usr.bin/rsync/flist.c
+++ usr.bin/rsync/flist.c
@@ -804,7 +804,7 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
 size_t *max)
 {
char*cargv[2], *cp;
-   int  rc = 0;
+   int  rc = 0, xdev = 0;
FTS *fts;
FTSENT  *ent;
struct flist*f;
@@ -890,9 +890,15 @@ flist_gen_dirent(struct sess *sess, char *root, struct 
flist **fl, size_t *sz,
 * files and directory components, so use fts(3).
 * Copying the information file-by-file into the flstat.
 * We'll make sense of it in flist_send.
+* If one-file-system is used, prevent fts(3) from descending
+* into directories that have a different device number than
+* the file from which the descent began.
 */
 
-   if ((fts = fts_open(cargv, FTS_PHYSICAL, NULL)) == NULL) {
+   if (sess->opts->one_file_system)
+   xdev = FTS_XDEV;
+
+   if ((fts = fts_open(cargv, FTS_PHYSICAL | xdev, NULL)) == NULL) {
ERR(sess, "fts_open");
return 0;
}
@@ -1129,7 +1135,7 @@ flist_gen_dels(struct sess *sess, const char *root, 
struct flist **fl,
 size_t *sz,const struct flist *wfl, size_t wflsz)
 {
char**cargv = NULL;
-   int   rc = 0, c;
+   int   rc = 0, c, xdev = 0;
FTS  *fts = NULL;
FTSENT   *ent;
struct flist *f;
@@ -1235,9 +1241,15 @@ flist_gen_dels(struct sess *sess, const char *root, 
struct flist **fl,
 * Now we're going to try to descend into all of the top-level
 * directories stipulated by the file list.
 * If the directories don't exist, it's ok.
+* If one-file-system is used, prevent fts(3) from descending
+* into directories that have a different device number than
+* the file from which the descent began.
 */
 
-   if ((fts = fts_open(cargv, FTS_PHYSICAL, NULL)) == NULL) {
+   if (sess->opts->one_file_system)
+   xdev = FTS_XDEV;
+
+   if ((fts = fts_open(cargv, FTS_PHYSICAL | xdev, NULL)) == NULL) {
ERR(sess, "fts_open");
goto out;
}
diff --git usr.bin/rsync/main.c usr.bin/rsync/main.c
index dd598d93eb2..3dbf6dd6028 100644
--- usr.bin/rsync/main.c
+++ usr.bin/rsync/main.c
@@ -305,6 +305,7 @@ main(int argc, char *argv[])
{ "no-times",   no_argument,_times,   0 },
{ "verbose",no_argument,,  1 },
{ "no-verbose", no_argument,,  0 },
+   { "one-file-system", no_argument, NULL, 'x' },
{ NULL, 0,  NULL,   0 }};
 
/* Global pledge. */
@@ -315,7 +316,7 @@ main(int argc, char *argv[])
 
memset(, 0, sizeof(struct opts));
 
-   while ((c = getopt_long(argc, argv, "Dae:ghlnoprtvz", lopts, NULL))
+   while ((c = getopt_long(argc, argv, "Dae:ghlnoprtvxz", lopts, NULL))
!= -1) {
switch (c) {
case 'D':
@@ -359,6 +360,9 @@ main(int argc, char *argv[])
case 'v':
opts.verbose++;
break;
+   case 'x':
+   opts.one_file_system = 1;
+   break;
case 'z':
fprintf(stderr, "%s: -z not supported yet\n", 
getprogname());
break;
diff --git usr.bin/rsync/rsync.1 usr.bin/rsync/rsync.1
index c16168fff8f..911c848da7e 100644
--- usr.bin/rsync/rsync.1
+++ usr.bin/rsync/rsync.1
@@ -141,6 +141,8 @@ Increase verbosity.
 Specify once for files being transferred, twice for specific status,
 thrice for per-file transfer information, and four times for per-file
 breakdowns.
+.It Fl x , -one-file-system
+Do not cross filesystem boundaries.
 .It Fl -version
 Print version and exit.
 .El

Setting MTU in slaacd (4/4)

[Björn Ketelaars]

Assuming that the other patches have been applied this patch enables
slaacctl(8) to print the set, advertised MTU.


diff --git usr.sbin/slaacctl/slaacctl.c usr.sbin/slaacctl/slaacctl.c
index 5b2a22f12e6..97b460aee08 100644
--- usr.sbin/slaacctl/slaacctl.c
+++ usr.sbin/slaacctl/slaacctl.c
@@ -228,6 +228,8 @@ show_interface_msg(struct imsg *imsg)
printf("\t\tDefault Router Preference: %s\n", cei_ra->rpref);
printf("\t\tReachable Time: %9ums, Retrans Timer: %9ums\n",
cei_ra->reachable_time, cei_ra->retrans_time);
+   if (cei_ra->mtu)
+   printf("\t\tMTU: %u bytes\n", cei_ra->mtu);
break;
case IMSG_CTL_SHOW_INTERFACE_INFO_RA_PREFIX:
cei_ra_prefix = imsg->data;

Setting MTU in slaacd (3/4)

[Björn Ketelaars]

Diff below makes an advertised MTU available from slaacd(8) to
slaacctl(8).


diff --git sbin/slaacd/engine.c sbin/slaacd/engine.c
index 762fb3af7a3..88e8b6531aa 100644
--- sbin/slaacd/engine.c
+++ sbin/slaacd/engine.c
@@ -887,6 +887,7 @@ send_interface_info(struct slaacd_iface *iface, pid_t pid)
cei_ra.router_lifetime = ra->router_lifetime;
cei_ra.reachable_time = ra->reachable_time;
cei_ra.retrans_time = ra->retrans_time;
+   cei_ra.mtu = ra->mtu;
engine_imsg_compose_frontend(IMSG_CTL_SHOW_INTERFACE_INFO_RA,
pid, _ra, sizeof(cei_ra));
 
diff --git sbin/slaacd/slaacd.h sbin/slaacd/slaacd.h
index e2306438fda..e49eb22a549 100644
--- sbin/slaacd/slaacd.h
+++ sbin/slaacd/slaacd.h
@@ -111,6 +111,7 @@ struct ctl_engine_info_ra {
uint16_t router_lifetime;   /* in seconds */
uint32_t reachable_time;/* in milliseconds */
uint32_t retrans_time;  /* in milliseconds */
+   uint32_t mtu;
 };
 
 struct ctl_engine_info_ra_prefix {

Setting MTU in slaacd (2/4)

[Björn Ketelaars]

Assuming that the pledge bits are in, the diff below enables setting of
MTU on the interface by slaacd.

If a MTU is advertised it is checked that it is at least 1280 bytes. If
not MTU is set to 1280. If no MTU is advertised nothing is done.


diff --git sbin/slaacd/engine.c sbin/slaacd/engine.c
index 58c39fb5c4a..762fb3af7a3 100644
--- sbin/slaacd/engine.c
+++ sbin/slaacd/engine.c
@@ -164,6 +164,7 @@ struct radv {
LIST_HEAD(, radv_rdns)   rdns_servers;
uint32_t dnssl_lifetime;
LIST_HEAD(, radv_dnssl)  dnssls;
+   uint32_t mtu;
 };
 
 struct address_proposal {
@@ -185,6 +186,7 @@ struct address_proposal {
uint32_t vltime;
uint32_t pltime;
uint8_t  soiikey[SLAACD_SOIIKEY_LEN];
+   uint32_t mtu;
 };
 
 struct dfr_proposal {
@@ -1193,6 +1195,7 @@ parse_ra(struct slaacd_iface *iface, struct imsg_ra *ra)
struct nd_opt_prefix_info *prf;
struct nd_opt_rdnss *rdnss;
struct nd_opt_dnssl *dnssl;
+   struct nd_opt_mtu *mtu;
struct in6_addr *in6;
int i;
char *nssl;
@@ -1293,11 +1296,23 @@ parse_ra(struct slaacd_iface *iface, struct imsg_ra *ra)
 
LIST_INSERT_HEAD(>dnssls, ra_dnssl, entries);
 
+   break;
+   case ND_OPT_MTU:
+   if (nd_opt_hdr->nd_opt_len != 1) {
+   log_warnx("invalid ND_OPT_MTU: len != 1");
+   goto err;
+   }
+   mtu = (struct nd_opt_mtu*) nd_opt_hdr;
+   radv->mtu = ntohl(mtu->nd_opt_mtu_mtu);
+
+   /* path MTU cannot be less than IPV6_MMTU */
+   if (radv->mtu < IPV6_MMTU)
+   radv->mtu = IPV6_MMTU;
+
break;
case ND_OPT_REDIRECTED_HEADER:
case ND_OPT_SOURCE_LINKADDR:
case ND_OPT_TARGET_LINKADDR:
-   case ND_OPT_MTU:
case ND_OPT_ROUTE_INFO:
 #if 0
log_debug("\tOption: %u (len: %u) not implemented",
@@ -1902,6 +1917,7 @@ configure_address(struct address_proposal *addr_proposal)
address.vltime = addr_proposal->vltime;
address.pltime = addr_proposal->pltime;
address.privacy = addr_proposal->privacy;
+   address.mtu = addr_proposal->mtu;
 
engine_imsg_compose_main(IMSG_CONFIGURE_ADDRESS, 0, ,
sizeof(address));
@@ -1950,6 +1966,8 @@ gen_address_proposal(struct slaacd_iface *iface, struct 
radv *ra, struct
addr_proposal->pltime = prefix->pltime;
}
 
+   addr_proposal->mtu = ra->mtu;
+
gen_addr(iface, prefix, addr_proposal, privacy);
 
tv.tv_sec = 0;
diff --git sbin/slaacd/engine.h sbin/slaacd/engine.h
index e7f520f1fba..4493b621b13 100644
--- sbin/slaacd/engine.h
+++ sbin/slaacd/engine.h
@@ -34,6 +34,7 @@ struct imsg_configure_address {
struct in6_addr  mask;
uint32_t vltime;
uint32_t pltime;
+   uint32_t mtu;
int  privacy;
 };
 
diff --git sbin/slaacd/slaacd.c sbin/slaacd/slaacd.c
index 7afd9dc3ec7..617c6620e20 100644
--- sbin/slaacd/slaacd.c
+++ sbin/slaacd/slaacd.c
@@ -761,6 +761,18 @@ configure_interface(struct imsg_configure_address *address)
 
if (ioctl(ioctl_sock, SIOCAIFADDR_IN6, _addreq) < 0)
fatal("SIOCAIFADDR_IN6");
+
+   if (address->mtu) {
+   struct ifreq ifr;
+
+   (void) strlcpy(ifr.ifr_name, in6_addreq.ifra_name,
+   sizeof(ifr.ifr_name));
+   ifr.ifr_mtu = address->mtu;
+   log_debug("Setting MTU to %d", ifr.ifr_mtu);
+
+   if (ioctl(ioctl_sock, SIOCSIFMTU, ) < 0)
+   fatal("SIOCSIFMTU");
+   }
 }
 
 void

Setting MTU in slaacd (1/4)

[Björn Ketelaars]

I recently sent a diff for enabling slaacctl(8) to show the advertised
MTU [0]. florian@ commented that it is confusing that slaacctl is
showing a different MTU than ifconfig, and noted that setting MTU is
"perfectly simple to do it in slaacd".

This is the first in a series of 4 patches, which enables:
1.) slaacd(8) to set MTU on an interface, and
2.) slaacctl(8) to show the set MTU

slaacd has been pledged, and setting mtu on the interface requires
additional bits in pledge.

[0] https://marc.info/?l=openbsd-tech=153223732924245=2


diff --git sys/kern/kern_pledge.c sys/kern/kern_pledge.c
index d2d1b0a9cbb..2e22166 100644
--- sys/kern/kern_pledge.c
+++ sys/kern/kern_pledge.c
@@ -1256,6 +1256,10 @@ pledge_ioctl(struct proc *p, long com, struct file *fp)
if (fp->f_type == DTYPE_SOCKET)
return (0);
break;
+   case SIOCSIFMTU:
+   if (fp->f_type == DTYPE_SOCKET)
+   return (0);
+   break;
}
}
 

Re: show advertised MTU in slaacctl

[Björn Ketelaars]

On Mon 23/07/2018 17:38, Florian Obser wrote:
> On Sun, Jul 22, 2018 at 10:32:31AM +0200, Björn Ketelaars wrote:
> > On Sun 22/07/2018 07:27, Björn Ketelaars wrote:
> > > Now that rad(8) is able to advertise a MTU I think it would be nice to
> > > have slaacctl(8) show this advertisement. The patch below touches both
> > > sbin/slaacd and usr.sbin/slaacctl. The addition to sbin/slaacd/engine.c
> > > makes sure that MTU RA messages are parsed, and that the result is made
> > > available. BTW running slaacd in the foreground already enables one to
> > > see the advertised MTU, see debug_log_ra().
> > > The addition to usr.sbin/slaacctl/slaacctl.c enables one to view the
> > > advertised MTU.
> > 
> > New diff as tb@ found a mistake in the first one affecting
> > ND_OPT_REDIRECTED_HEADER, ND_OPT_SOURCE_LINKADDR and
> > ND_OPT_TARGET_LINKADDR as well.
> > 
> 
> Do you intend to set the mtu on the interface?  If not I'm a bit
> reluctand to parse and show it.  I know that we are showing the
> nameservers and not do anything with them. When I wrote that code
> there was every intention to do something with the nameservers. For
> various reasons that didn't happen (yet). Maybe we shoud not parse &
> show the nameservers, either (until if and when we do something with
> them).


On some hosts I use advertised DNS information to put together
resolv.conf (quick-and-dirty hack using slaacctl and grep). Intention is
to do the same for setting MTU on an interface.

I'm not sure if a problem is solved by not parsing and showing
nameservers from slaacctl. It would be helpful to keep this feature
around.
I'm guessing that parsing/showing MTU would not be missed by anyone
(except me). On the other hand, it nicely complements rad(8), and could
help with testing.

Re: show advertised MTU in slaacctl

[Björn Ketelaars]

On Sun 22/07/2018 07:27, Björn Ketelaars wrote:
> Now that rad(8) is able to advertise a MTU I think it would be nice to
> have slaacctl(8) show this advertisement. The patch below touches both
> sbin/slaacd and usr.sbin/slaacctl. The addition to sbin/slaacd/engine.c
> makes sure that MTU RA messages are parsed, and that the result is made
> available. BTW running slaacd in the foreground already enables one to
> see the advertised MTU, see debug_log_ra().
> The addition to usr.sbin/slaacctl/slaacctl.c enables one to view the
> advertised MTU.

New diff as tb@ found a mistake in the first one affecting
ND_OPT_REDIRECTED_HEADER, ND_OPT_SOURCE_LINKADDR and
ND_OPT_TARGET_LINKADDR as well.


diff --git sbin/slaacd/engine.c sbin/slaacd/engine.c
index 961e1b115b6..2e114cdaf0b 100644
--- sbin/slaacd/engine.c
+++ sbin/slaacd/engine.c
@@ -156,6 +156,7 @@ struct radv {
uint16_t router_lifetime; /* in seconds */
uint32_t reachable_time; /* in milliseconds */
uint32_t retrans_time; /* in milliseconds */
+   uint32_t mtu;
LIST_HEAD(, radv_prefix) prefixes;
uint32_t rdns_lifetime;
LIST_HEAD(, radv_rdns)   rdns_servers;
@@ -832,6 +833,7 @@ send_interface_info(struct slaacd_iface *iface, pid_t pid)
cei_ra.router_lifetime = ra->router_lifetime;
cei_ra.reachable_time = ra->reachable_time;
cei_ra.retrans_time = ra->retrans_time;
+   cei_ra.mtu = ra->mtu;
engine_imsg_compose_frontend(IMSG_CTL_SHOW_INTERFACE_INFO_RA,
pid, _ra, sizeof(cei_ra));
 
@@ -1125,6 +1127,7 @@ parse_ra(struct slaacd_iface *iface, struct imsg_ra *ra)
while ((size_t)len >= sizeof(struct nd_opt_hdr)) {
struct nd_opt_hdr *nd_opt_hdr = (struct nd_opt_hdr *)p;
struct nd_opt_prefix_info *prf;
+   struct nd_opt_mtu *mtu;
struct nd_opt_rdnss *rdnss;
struct nd_opt_dnssl *dnssl;
struct in6_addr *in6;
@@ -1227,11 +1230,18 @@ parse_ra(struct slaacd_iface *iface, struct imsg_ra *ra)
 
LIST_INSERT_HEAD(>dnssls, ra_dnssl, entries);
 
+   break;
+   case ND_OPT_MTU:
+   if (nd_opt_hdr->nd_opt_len != 1) {
+   log_warnx("invalid ND_OPT_MTU: len != 1");
+   goto err;
+   }
+   mtu = (struct nd_opt_mtu*) nd_opt_hdr;
+   radv->mtu = ntohl(mtu->nd_opt_mtu_mtu);
break;
case ND_OPT_REDIRECTED_HEADER:
case ND_OPT_SOURCE_LINKADDR:
case ND_OPT_TARGET_LINKADDR:
-   case ND_OPT_MTU:
case ND_OPT_ROUTE_INFO:
 #if 0
log_debug("\tOption: %u (len: %u) not implemented",
diff --git sbin/slaacd/slaacd.h sbin/slaacd/slaacd.h
index 910be91e687..33e85909ce9 100644
--- sbin/slaacd/slaacd.h
+++ sbin/slaacd/slaacd.h
@@ -109,6 +109,7 @@ struct ctl_engine_info_ra {
uint16_t router_lifetime;   /* in seconds */
uint32_t reachable_time;/* in milliseconds */
uint32_t retrans_time;  /* in milliseconds */
+   uint32_t mtu;
 };
 
 struct ctl_engine_info_ra_prefix {
diff --git usr.sbin/slaacctl/slaacctl.c usr.sbin/slaacctl/slaacctl.c
index 5b2a22f12e6..97b460aee08 100644
--- usr.sbin/slaacctl/slaacctl.c
+++ usr.sbin/slaacctl/slaacctl.c
@@ -228,6 +228,8 @@ show_interface_msg(struct imsg *imsg)
printf("\t\tDefault Router Preference: %s\n", cei_ra->rpref);
printf("\t\tReachable Time: %9ums, Retrans Timer: %9ums\n",
cei_ra->reachable_time, cei_ra->retrans_time);
+   if (cei_ra->mtu)
+   printf("\t\tMTU: %u bytes\n", cei_ra->mtu);
break;
case IMSG_CTL_SHOW_INTERFACE_INFO_RA_PREFIX:
cei_ra_prefix = imsg->data;

show advertised MTU in slaacctl

[Björn Ketelaars]

Now that rad(8) is able to advertise a MTU I think it would be nice to
have slaacctl(8) show this advertisement. The patch below touches both
sbin/slaacd and usr.sbin/slaacctl. The addition to sbin/slaacd/engine.c
makes sure that MTU RA messages are parsed, and that the result is made
available. BTW running slaacd in the foreground already enables one to
see the advertised MTU, see debug_log_ra().
The addition to usr.sbin/slaacctl/slaacctl.c enables one to view the
advertised MTU.

$ slaacctl show interface iwn0 
iwn0:
 index:   2 running: yes privacy: yes
lladdr: 60:67:20:60:44:70
 inet6: fe80::abc2:230e:d3d9:b321%iwn0
Router Advertisement from fe80::a562:1f47:a75c:a5fc%iwn0
received: 2018-07-22 07:20:15; 18s ago
Cur Hop Limit:   0, M: 0, O: 0, Router Lifetime:  1800s
Default Router Preference: Medium
Reachable Time: 0ms, Retrans Timer: 0ms
MTU: 1480 bytes
...
...

Any opinions?


diff --git sbin/slaacd/engine.c sbin/slaacd/engine.c
index 961e1b115b6..7e1e6eb5850 100644
--- sbin/slaacd/engine.c
+++ sbin/slaacd/engine.c
@@ -156,6 +156,7 @@ struct radv {
uint16_t router_lifetime; /* in seconds */
uint32_t reachable_time; /* in milliseconds */
uint32_t retrans_time; /* in milliseconds */
+   uint32_t mtu;
LIST_HEAD(, radv_prefix) prefixes;
uint32_t rdns_lifetime;
LIST_HEAD(, radv_rdns)   rdns_servers;
@@ -832,6 +833,7 @@ send_interface_info(struct slaacd_iface *iface, pid_t pid)
cei_ra.router_lifetime = ra->router_lifetime;
cei_ra.reachable_time = ra->reachable_time;
cei_ra.retrans_time = ra->retrans_time;
+   cei_ra.mtu = ra->mtu;
engine_imsg_compose_frontend(IMSG_CTL_SHOW_INTERFACE_INFO_RA,
pid, _ra, sizeof(cei_ra));
 
@@ -1125,6 +1127,7 @@ parse_ra(struct slaacd_iface *iface, struct imsg_ra *ra)
while ((size_t)len >= sizeof(struct nd_opt_hdr)) {
struct nd_opt_hdr *nd_opt_hdr = (struct nd_opt_hdr *)p;
struct nd_opt_prefix_info *prf;
+   struct nd_opt_mtu *mtu;
struct nd_opt_rdnss *rdnss;
struct nd_opt_dnssl *dnssl;
struct in6_addr *in6;
@@ -1232,6 +1235,13 @@ parse_ra(struct slaacd_iface *iface, struct imsg_ra *ra)
case ND_OPT_SOURCE_LINKADDR:
case ND_OPT_TARGET_LINKADDR:
case ND_OPT_MTU:
+   if (nd_opt_hdr->nd_opt_len != 1) {
+   log_warnx("invalid ND_OPT_MTU: len != 1");
+   goto err;
+   }
+   mtu = (struct nd_opt_mtu*) nd_opt_hdr;
+   radv->mtu = ntohl(mtu->nd_opt_mtu_mtu);
+   break;
case ND_OPT_ROUTE_INFO:
 #if 0
log_debug("\tOption: %u (len: %u) not implemented",
diff --git sbin/slaacd/slaacd.h sbin/slaacd/slaacd.h
index 910be91e687..33e85909ce9 100644
--- sbin/slaacd/slaacd.h
+++ sbin/slaacd/slaacd.h
@@ -109,6 +109,7 @@ struct ctl_engine_info_ra {
uint16_t router_lifetime;   /* in seconds */
uint32_t reachable_time;/* in milliseconds */
uint32_t retrans_time;  /* in milliseconds */
+   uint32_t mtu;
 };
 
 struct ctl_engine_info_ra_prefix {
diff --git usr.sbin/slaacctl/slaacctl.c usr.sbin/slaacctl/slaacctl.c
index 5b2a22f12e6..97b460aee08 100644
--- usr.sbin/slaacctl/slaacctl.c
+++ usr.sbin/slaacctl/slaacctl.c
@@ -228,6 +228,8 @@ show_interface_msg(struct imsg *imsg)
printf("\t\tDefault Router Preference: %s\n", cei_ra->rpref);
printf("\t\tReachable Time: %9ums, Retrans Timer: %9ums\n",
cei_ra->reachable_time, cei_ra->retrans_time);
+   if (cei_ra->mtu)
+   printf("\t\tMTU: %u bytes\n", cei_ra->mtu);
break;
case IMSG_CTL_SHOW_INTERFACE_INFO_RA_PREFIX:
cei_ra_prefix = imsg->data;

Re: call for testing: rad(8) - a rtadvd(8) replacement

[Björn Ketelaars]

On Fri 20/07/2018 07:57, Florian Obser wrote:
> On Thu, Jul 19, 2018 at 09:47:06PM +0200, Björn Ketelaars wrote:
> > On Wed 18/07/2018 08:54, Florian Obser wrote:
> > > During g2k18 I commited rad(8).
> > > 
> > > The latest amd64 and i386 snapshots should contain it with enough
> > > features to replace rtadvd(8). If you are using rtadvd(8) I'd
> > > appreciate if you could switch to rad(8) and report back if any
> > > features are missing.
> > 
> > Florian,
> > 
> > Thank you for rad(8). I like the configuration format, and it seems to
> > work for me as replacement for rtadvd(8). For reference purposes:
> > 
> > $ cat /etc/rtadvd.conf
> > vlan1003:\
> > :mtu#1480:\
> > :rdnss="2001:470:7ce4:1::1":\
> > :dnssl="guest":
> > 
> > $ cat /etc/rad.conf
> > interface vlan1003 {
> > dns {
> > resolver 2001:470:7ce4:1::1
> > search guest
> > }
> > }
> > 
> > There is one thing that I'm missing, and that is the MTU option in RA
> > messages (RFC 4861 Section 4.6.4). I've baked up a diff which works for
> > me. My current rad.conf looks like:
> > 
> > interface vlan1003 {
> > dns {
> > resolver 2001:470:7ce4:1::1
> > search guest
> > }
> > 
> > mtu 1480
> > }
> > 
> > Output "tcpdump - -ttt -i vlan1003 icmp6 and 'ip6[40] = 134'":
> > 
> > Jul 19 21:26:10.009348 fe80::a562:1f47:a75c:a5fc > ff02::1: icmp6: router 
> > advertisement(chlim=0, pref=medium, router_ltime=1800, reachable_time=0, 
> > retrans_time=0)(prefix info: LA valid_ltime=2592000, 
> > preferred_ltime=604800, prefix=2001:470:7ce4:1::/64)(mtu: mtu=1480)[ndp 
> > opt] (len 88, hlim 255)
> > 
> > I'm not sure this is an option for rad(8) that is useful for anyone else
> > but me. What do you think? Also, what do you think of the diff below?
> 
> I like it, I think we should have it. Out of curiosity, which clients
> pay attention to the MTU option? I know that slaacd does not. If you
> are sufficiently bored you might want to implement it there, too! ;)
> (hint: you will need to add to the wroute pledge in the kernel)
> 
> Diff reads mostly ok but needs a few tweaks, see inline:
> 
> > 
> > 
> > diff --git engine.c engine.c
> > index 5d186439dd8..4ade634a689 100644
> > --- engine.c
> > +++ engine.c
> > @@ -355,6 +355,9 @@ engine_dispatch_main(int fd, short event, void *bula)
> > SIMPLEQ_INSERT_TAIL(_iface_conf->ra_prefix_list,
> > ra_prefix_conf, entry);
> > break;
> > +   case IMSG_RECONF_RA_MTU:
> > +   ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
> > +   break;
> 
> no need for the extra IMSG, ra_mtu is not a substructure in
> ra_iface_conf, it will be copied with the rest of the ra_iface_conf in
> IMSG_RECONF_RA_IFACE
> 
> > case IMSG_RECONF_RA_RDNS_LIFETIME:
> > ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
> > break;
> > diff --git frontend.c frontend.c
> > index b06fa43038c..06c4cc5cb2b 100644
> > --- frontend.c
> > +++ frontend.c
> > @@ -397,6 +397,9 @@ frontend_dispatch_main(int fd, short event, void *bula)
> > SIMPLEQ_INSERT_TAIL(_iface_conf->ra_prefix_list,
> > ra_prefix_conf, entry);
> > break;
> > +   case IMSG_RECONF_RA_MTU:
> > +   ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
> > +   break;
> 
> same here
> 
> > case IMSG_RECONF_RA_RDNS_LIFETIME:
> > ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
> > break;
> > @@ -888,6 +891,7 @@ build_packet(struct ra_iface *ra_iface)
> >  {
> > struct nd_router_advert *ra;
> > struct nd_opt_prefix_info   *ndopt_pi;
> > +   struct nd_opt_mtu   *ndopt_mtu;
> > struct ra_iface_conf*ra_iface_conf;
> > struct ra_options_conf  *ra_options_conf;
> > struct ra_prefix_conf   *ra_prefix_conf;
> > @@ -960,6 +964,15 @@ build_packet(struct ra_iface *ra_iface)
> > p += sizeof(*ndopt_pi);
> > }
> >  
> > +   if (ra_iface_conf->ra_mtu > 0) {
> > +   ndopt_mtu = (struct nd_opt_mt

Re: call for testing: rad(8) - a rtadvd(8) replacement

[Björn Ketelaars]

On Wed 18/07/2018 08:54, Florian Obser wrote:
> During g2k18 I commited rad(8).
> 
> The latest amd64 and i386 snapshots should contain it with enough
> features to replace rtadvd(8). If you are using rtadvd(8) I'd
> appreciate if you could switch to rad(8) and report back if any
> features are missing.

Florian,

Thank you for rad(8). I like the configuration format, and it seems to
work for me as replacement for rtadvd(8). For reference purposes:

$ cat /etc/rtadvd.conf
vlan1003:\
:mtu#1480:\
:rdnss="2001:470:7ce4:1::1":\
:dnssl="guest":

$ cat /etc/rad.conf
interface vlan1003 {
dns {
resolver 2001:470:7ce4:1::1
search guest
}
}

There is one thing that I'm missing, and that is the MTU option in RA
messages (RFC 4861 Section 4.6.4). I've baked up a diff which works for
me. My current rad.conf looks like:

interface vlan1003 {
dns {
resolver 2001:470:7ce4:1::1
search guest
}

mtu 1480
}

Output "tcpdump - -ttt -i vlan1003 icmp6 and 'ip6[40] = 134'":

Jul 19 21:26:10.009348 fe80::a562:1f47:a75c:a5fc > ff02::1: icmp6: router 
advertisement(chlim=0, pref=medium, router_ltime=1800, reachable_time=0, 
retrans_time=0)(prefix info: LA valid_ltime=2592000, preferred_ltime=604800, 
prefix=2001:470:7ce4:1::/64)(mtu: mtu=1480)[ndp opt] (len 88, hlim 255)

I'm not sure this is an option for rad(8) that is useful for anyone else
but me. What do you think? Also, what do you think of the diff below?


diff --git engine.c engine.c
index 5d186439dd8..4ade634a689 100644
--- engine.c
+++ engine.c
@@ -355,6 +355,9 @@ engine_dispatch_main(int fd, short event, void *bula)
SIMPLEQ_INSERT_TAIL(_iface_conf->ra_prefix_list,
ra_prefix_conf, entry);
break;
+   case IMSG_RECONF_RA_MTU:
+   ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
+   break;
case IMSG_RECONF_RA_RDNS_LIFETIME:
ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
break;
diff --git frontend.c frontend.c
index b06fa43038c..06c4cc5cb2b 100644
--- frontend.c
+++ frontend.c
@@ -397,6 +397,9 @@ frontend_dispatch_main(int fd, short event, void *bula)
SIMPLEQ_INSERT_TAIL(_iface_conf->ra_prefix_list,
ra_prefix_conf, entry);
break;
+   case IMSG_RECONF_RA_MTU:
+   ra_iface_conf->ra_mtu = *((uint32_t *)imsg.data);
+   break;
case IMSG_RECONF_RA_RDNS_LIFETIME:
ra_iface_conf->rdns_lifetime = *((uint32_t *)imsg.data);
break;
@@ -888,6 +891,7 @@ build_packet(struct ra_iface *ra_iface)
 {
struct nd_router_advert *ra;
struct nd_opt_prefix_info   *ndopt_pi;
+   struct nd_opt_mtu   *ndopt_mtu;
struct ra_iface_conf*ra_iface_conf;
struct ra_options_conf  *ra_options_conf;
struct ra_prefix_conf   *ra_prefix_conf;
@@ -960,6 +964,15 @@ build_packet(struct ra_iface *ra_iface)
p += sizeof(*ndopt_pi);
}
 
+   if (ra_iface_conf->ra_mtu > 0) {
+   ndopt_mtu = (struct nd_opt_mtu *)p;
+   ndopt_mtu->nd_opt_mtu_type = ND_OPT_MTU;
+   ndopt_mtu->nd_opt_mtu_len = 1;
+   ndopt_mtu->nd_opt_mtu_reserved = 0;
+   ndopt_mtu->nd_opt_mtu_mtu = htonl(ra_iface_conf->ra_mtu);
+   p += sizeof(*ndopt_mtu);
+   }
+
if (ra_iface_conf->rdnss_count > 0) {
ndopt_rdnss = (struct nd_opt_rdnss *)p;
ndopt_rdnss->nd_opt_rdnss_type = ND_OPT_RDNSS;
diff --git parse.y parse.y
index 582d165c7d6..9696ac58213 100644
--- parse.y
+++ parse.y
@@ -115,7 +115,7 @@ typedef struct {
 %token DEFAULT ROUTER HOP LIMIT MANAGED ADDRESS
 %token CONFIGURATION OTHER LIFETIME REACHABLE TIME RETRANS TIMER
 %token AUTO PREFIX VALID PREFERRED LIFETIME ONLINK AUTONOMOUS
-%token ADDRESS_CONFIGURATION DNS RESOLVER SEARCH
+%token ADDRESS_CONFIGURATION DNS RESOLVER SEARCH MTU
 
 %token   STRING
 %token   NUMBER
@@ -265,6 +265,9 @@ ra_ifaceoptsl   : NO AUTO PREFIX {
} ra_prefix_block {
ra_prefix_conf = NULL;
}
+   | MTU NUMBER {
+   ra_iface_conf->ra_mtu = $2;
+   }
| DNS dns_block
| ra_opt_block
;
@@ -423,6 +426,7 @@ lookup(char *s)
{"lifetime",LIFETIME},
{"limit",   LIMIT},
{"managed", MANAGED},
+   {"mtu", MTU},
{"no",  NO},
{"on-link", ONLINK},
{"other",  

umsm(4) support for Vodafone k3772

[Björn Ketelaars]

I received a Vodafone k3772 USB modem, which is not supported out of the
box in current. dmesg:

umass0 at uhub3 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 6
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
cd0 at scsibus4 targ 1 lun 0:  SCSI2 5/cdrom 
removable


Diff below adds support for this device. dmesg:

umsm0 at uhub0 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
umsm0 detached
umsm0 at uhub0 port 2 configuration 1 interface 0 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
ucom0 at umsm0
umsm1 at uhub0 port 2 configuration 1 interface 1 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
ucom1 at umsm1
umsm2 at uhub0 port 2 configuration 1 interface 2 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
ucom2 at umsm2
umass0 at uhub0 port 2 configuration 1 interface 3 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
cd0 at scsibus2 targ 1 lun 0:  SCSI2 5/cdrom 
removable
umass1 at uhub0 port 2 configuration 1 interface 4 "Vodafone (Huawei) Vodafone 
Mobile Broadband (Huawei)" rev 2.00/1.02 addr 2
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd1 at scsibus3 targ 1 lun 0:  SCSI2 0/direct 
removable


I'm able to set up an internet connection using this device in
combination with a Vodafone subscription on a x230. Actually I've been
using this device for the last few weeks during my daily commute. There
seems to be however one issue, which does not interfere with reliability
or stability. dmesg: 

umsm0: this device is not using CDC notify message in intr pipe.
Please send your dmesg to , thanks.
umsm0: intr buffer 0xc1 0x1 0x3 0x0 0x0 0x0 0x0


A search on misc@ revealed that this is not an isolated issue, e.g.
https://marc.info/?l=openbsd-misc=142477847307314=2


Comments?


Index: share/man/man4/umsm.4
===
RCS file: /cvs/src/share/man/man4/umsm.4,v
retrieving revision 1.94
diff -u -p -r1.94 umsm.4
--- share/man/man4/umsm.4   20 Mar 2018 07:30:10 -  1.94
+++ share/man/man4/umsm.4   10 Apr 2018 17:39:52 -
@@ -113,6 +113,7 @@ driver:
 .It Li "Toshiba 3G HSDPA MiniCard" Ta "PCI Express Mini Card"
 .It Li "Vodafone Mobile Connect 3G" Ta "CardBus"
 .It Li "Vodafone Mobile Broadband K3765" Ta "USB"
+.It Li "Vodafone Mobile Broadband K3772" Ta "USB"
 .It Li "ZTE AC2746" Ta "USB"
 .It Li "ZTE MF112" Ta "USB"
 .It Li "ZTE MF190" Ta "USB"
Index: sys/dev/usb/umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.111
diff -u -p -r1.111 umsm.c
--- sys/dev/usb/umsm.c  20 Mar 2018 07:30:10 -  1.111
+++ sys/dev/usb/umsm.c  10 Apr 2018 17:39:52 -
@@ -142,6 +142,8 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_Mobile }, DEV_HUAWEI},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3765_INIT }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3765 }, 0},
+   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3772_INIT }, DEV_UMASS5},
+   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K3772 }, 0},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_MU609 }, DEV_TRUINSTALL},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K4510 }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_K4511 }, DEV_UMASS5},
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.683
diff -u -p -r1.683 usbdevs
--- sys/dev/usb/usbdevs 20 Mar 2018 07:30:10 -  1.683
+++ sys/dev/usb/usbdevs 10 Apr 2018 17:39:52 -
@@ -2217,12 +2217,14 @@ product HUAWEI E182 0x1429  HUAWEI Mobil
 product HUAWEI E3372   0x1442  HUAWEI Mobile Modem
 product HUAWEI E1610x1446  HUAWEI Mobile Modem
 product HUAWEI K3765   0x1465  HUAWEI Mobile K3765
+product HUAWEI K3772   0x14cf  HUAWEI Mobile K3772
 product HUAWEI E1820   0x14ac  HUAWEI Mobile Modem
 product HUAWEI K4510   0x14c5  HUAWEI Mobile Modem
 product HUAWEI K4511   0x14b7  HUAWEI Mobile Modem K4511
 product HUAWEI E353_INIT   0x14fe  HUAWEI Mobile E353 Initial
 product HUAWEI E392_INIT   0x1505  HUAWEI Mobile E392 Initial
 product HUAWEI K3765_INIT  0x1520  HUAWEI Mobile K3765 Initial
+product HUAWEI K3772_INIT  0x1526  HUAWEI Mobile K3772 Initial
 product HUAWEI MU609   0x1573  HUAWEI Mobile ME906 
 product HUAWEI E173S   0x1c05  HUAWEI Mobile E173s
 

Re: kernel relinking depending on ctfstrip

[Björn Ketelaars]

On Sun 20/08/2017 14:20, Björn Ketelaars wrote:
> I just upgraded my machine to a newer snapshot. Unfortunately the kernel
> relinking bit failed. Root cause is that strip has been replaced by ctfstrip,
> which is part of the comp set, which I have not installed.
> 
> The exact same thing happened when strip was part of the comp set. Solution
> then was that strip was thrown in base [0].
> 
> Does it make sense to move ctfstrip and ctfconv to base?
> 
> [0]
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/sets/lists/base/mi?rev=1.847=text/x-cvsweb-markup
> 

I forgot about objcopy, which is also use by ctfstrip. New diff.


diff --git distrib/sets/lists/base/md.alpha distrib/sets/lists/base/md.alpha
index e99541e063f..e6d18ed71c2 100644
--- distrib/sets/lists/base/md.alpha
+++ distrib/sets/lists/base/md.alpha
@@ -61,6 +61,7 @@
 ./sbin/kbd
 ./sbin/mount_ntfs
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.amd64 distrib/sets/lists/base/md.amd64
index 22ba5bcf5f5..035d75553df 100644
--- distrib/sets/lists/base/md.amd64
+++ distrib/sets/lists/base/md.amd64
@@ -66,6 +66,7 @@
 ./sbin/kbd
 ./sbin/mount_ntfs
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/bin/pctr
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
diff --git distrib/sets/lists/base/md.arm64 distrib/sets/lists/base/md.arm64
index 76d487c34d7..04f6662ddc1 100644
--- distrib/sets/lists/base/md.arm64
+++ distrib/sets/lists/base/md.arm64
@@ -29,6 +29,7 @@
 ./etc/firmware/zd1211b
 ./sbin/kbd
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.armv7 distrib/sets/lists/base/md.armv7
index f4b6f7d..e53c7909275 100644
--- distrib/sets/lists/base/md.armv7
+++ distrib/sets/lists/base/md.armv7
@@ -29,6 +29,7 @@
 ./etc/firmware/zd1211b
 ./sbin/kbd
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.hppa distrib/sets/lists/base/md.hppa
index ccdca21a99e..05cd23b760d 100644
--- distrib/sets/lists/base/md.hppa
+++ distrib/sets/lists/base/md.hppa
@@ -63,6 +63,7 @@
 ./etc/firmware/zd1211b
 ./sbin/kbd
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.i386 distrib/sets/lists/base/md.i386
index b223174485b..7ab7798e78a 100644
--- distrib/sets/lists/base/md.i386
+++ distrib/sets/lists/base/md.i386
@@ -68,6 +68,7 @@
 ./sbin/kbd
 ./sbin/mount_ntfs
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/bin/pctr
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
diff --git distrib/sets/lists/base/md.landisk distrib/sets/lists/base/md.landisk
index 3999d2d8eac..15d36fbcfc2 100644
--- distrib/sets/lists/base/md.landisk
+++ distrib/sets/lists/base/md.landisk
@@ -29,6 +29,7 @@
 ./etc/firmware/zd1211b
 ./sbin/kbd
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.loongson 
distrib/sets/lists/base/md.loongson
index 520f420b88b..6c1b8dcfd30 100644
--- distrib/sets/lists/base/md.loongson
+++ distrib/sets/lists/base/md.loongson
@@ -34,6 +34,7 @@
 ./etc/firmware/zd1211b
 ./sbin/kbd
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.luna88k distrib/sets/lists/base/md.luna88k
index 8416386f3cf..2712353cb31 100644
--- distrib/sets/lists/base/md.luna88k
+++ distrib/sets/lists/base/md.luna88k
@@ -1,6 +1,7 @@
 ./etc/examples/wsconsctl.conf
 ./sbin/kbd
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.macppc distrib/sets/lists/base/md.macppc
index abca7e80bb3..81f1fc9399a 100644
--- distrib/sets/lists/base/md.macppc
+++ distrib/sets/lists/base/md.macppc
@@ -64,6 +64,7 @@
 ./sbin/kbd
 ./sbin/pdisk
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.octeon distrib/sets/lists/base/md.octeon
index 6200a23eac9..3bba5606695 100644
--- distrib/sets/lists/base/md.octeon
+++ distrib/sets/lists/base/md.octeon
@@ -32,6 +32,7 @@
 ./etc/firmware/zd1211
 ./etc/firmware/zd1211-license
 ./etc/firmware/zd1211b
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.sgi distrib/sets/lists/base/md.sgi
index 0b9bfc0b7e7..08b9f746dbf 100644
--- distrib/sets/lists/base/md.sgi
+++ distrib/sets/lists/base/md.sgi
@@ -63,6 +63,7 @@
 ./etc/firmware/zd1211b
 ./sbin/kbd
 ./sbin/wsconsctl
+./usr/bin/objcopy
 ./usr/lib/crtbegin.o
 ./usr/lib/crtbeginS.o
 ./usr/lib/crtend.o
diff --git distrib/sets/lists/base/md.socppc distrib/sets/lists/base/md.socppc
index 2427b99604a..d15d32a322a 100644
--- distrib/sets/lists/base/md.socppc
+++ distri

kernel relinking depending on ctfstrip

[Björn Ketelaars]

I just upgraded my machine to a newer snapshot. Unfortunately the kernel
relinking bit failed. Root cause is that strip has been replaced by ctfstrip,
which is part of the comp set, which I have not installed.

The exact same thing happened when strip was part of the comp set. Solution
then was that strip was thrown in base [0].

Does it make sense to move ctfstrip and ctfconv to base?

[0]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/sets/lists/base/mi?rev=1.847=text/x-cvsweb-markup

-- 
Björn Ketelaars
GPG key: 0x4F0E5F21


diff --git distrib/sets/lists/base/mi distrib/sets/lists/base/mi
index f83e9efdb24..d34e68df431 100644
--- distrib/sets/lists/base/mi
+++ distrib/sets/lists/base/mi
@@ -353,6 +353,8 @@
 ./usr/bin/crontab
 ./usr/bin/csplit
 ./usr/bin/ctags
+./usr/bin/ctfconv
+./usr/bin/ctfstrip
 ./usr/bin/cu
 ./usr/bin/cut
 ./usr/bin/cvs
diff --git distrib/sets/lists/comp/mi distrib/sets/lists/comp/mi
index 819e4df1d1b..cf5323bfaba 100644
--- distrib/sets/lists/comp/mi
+++ distrib/sets/lists/comp/mi
@@ -2,9 +2,7 @@
 ./usr/bin/c++
 ./usr/bin/c++filt
 ./usr/bin/cpp
-./usr/bin/ctfconv
 ./usr/bin/ctfdump
-./usr/bin/ctfstrip
 ./usr/bin/flex
 ./usr/bin/flex++
 ./usr/bin/gprof

Re: kernel relinking at install/upgrade time

[Björn Ketelaars]

On Mon 26/06/2017 14:35, Theo de Raadt wrote:
> There is a diff in snapshots which does kernel relinking during
> install or upgrade.
> 
> Really amazing...

Works as advertised, assuming that compXX is installed. The relinking bit uses
strip, which is part of the compiler collection.

Does it make sense to include strip in the base system?

Re: r1.21 of sys/net/hfsc.c cripples networking speed

[Björn Ketelaars]

On Fri 24/04/2015 16:25, David Gwynne wrote:
 
  On 24 Apr 2015, at 3:39 pm, Theo de Raadt dera...@cvs.openbsd.org wrote:
  
  After updating one of my machines to a more recent snapshot I noticed that
  networking speed was reduced and that the machine was 'less' responsive.
  
  Be aware there is a fairly expensive debugging diff in the snapshots
  (it is not actually commited).
 
 yeah. have you tried the speed of a current kernel you've built yourself?
 
 dlg

Just tested a current kernel without a hitch. Guess my observation is the result
from the fairly expensive debugging diff. Sorry for the noise...

For future references: is it possible to see if a kernel from snapshots contains
'non committed' code?

-- 
Björn Ketelaars
GPG key: 0x4F0E5F21

r1.21 of sys/net/hfsc.c cripples networking speed

[Björn Ketelaars]

Hello,

After updating one of my machines to a more recent snapshot I noticed that
networking speed was reduced and that the machine was 'less' responsive. Quick
look in systat revealed that softnet was hammering the processor (90% interrupt
on CPU0). After reverting to a backup (older kernel) the issue with softnet
claiming the processor was gone.

I once more attempted the more recent kernel disabling queuing in pf (wild
guess). This resolved my issue with networking speed. After some digging in the
CVS log I noticed that revision 1.21 of sys/net/hfsc.c [0] altered code related
to pf queueing.

A test, using a kernel without the above changeset, results in a machine that is
behaving as expected. As I do not understand the changed code I was wondering if
there is a reason why the commit has such an impact on the system resulting in
a decreased networking speed? 

[0]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/hfsc.c.diff?r1=1.20r2=1.21f=h
-- 
Björn Ketelaars
GPG key: 0x4F0E5F21

etc/mtree/special: remove nsd.conf

[Björn Ketelaars]

/etc/nsd.conf has been moved to /var/nsd/etc/nsd.conf. /etc/changelist has been
changed accordingly, /etc/mtree/special has not. NSD's configuration file
resides in a root:_nsd owned directory with permission set at 0750. As such
there should be no need for inclusion of nsd.conf in the mtree specification for
dangerous files.

Included a small diff file.


-- 
Björn Ketelaars
GPG key: 0x4F0E5F21
Index: mtree/special
===
RCS file: /cvs/src/etc/mtree/special,v
retrieving revision 1.99
diff -u -p -r1.99 special
--- mtree/special   10 Jul 2013 05:23:18 -  1.99
+++ mtree/special   3 Dec 2013 07:53:51 -
@@ -72,7 +72,6 @@ npppd type=dir mode=0755 uname=root gna
 npppd.conf type=file mode=0640 uname=root gname=wheel
 npppd-userstype=file mode=0600 uname=root gname=wheel
 .. #npppd
-nsd.conf   type=file mode=0640 uname=root gname=_nsd
 ntpd.conf  type=file mode=0644 uname=root gname=wheel
 ospfd.conf type=file mode=0600 uname=root gname=wheel
 ospf6d.conftype=file mode=0600 uname=root gname=wheel

Re: etc/mtree/special: remove nsd.conf

[Björn Ketelaars]

On 03/12/2013, Ian McWilliam wrote:
 On 3/12/2013 7:12 PM, Björn Ketelaars wrote:
 /etc/nsd.conf has been moved to /var/nsd/etc/nsd.conf. /etc/changelist has 
 been
 changed accordingly, /etc/mtree/special has not. NSD's configuration file
 resides in a root:_nsd owned directory with permission set at 0750. As such
 there should be no need for inclusion of nsd.conf in the mtree specification 
 for
 dangerous files.
 
 Included a small diff file.
 
 
 
 Does a conf file really need to be executable?
 
 Ian McWilliam

The directory has permission 0750, not the configuration file (which is 0640).
So, no executable config file.

Guess that my crappy English is to blame...

-- 
Björn Ketelaars
GPG key: 0x4F0E5F21

Re: login_yubikey does not accept user.name

[Björn Ketelaars]

On Thu, Apr 5, 2012 at 6:51 AM, Otto Moerbeek o...@drijf.net wrote:
 That sounds like timing bases attacks to guess a username still will work.

-Otto

First thing I thought when reading your reply: absolute nonsense. With
that mindset I really wanted to disprove your suggestion. For this I
have set-up two different scenarios:

1.) Local 'attack' without use of getpwnam (plain-vanilla login_yubikey)
2.) Local 'attack' with use of getpwnam (altered version, read: with
applied diff)

Each scenario was run two times: one time targeting existing users and
one time targeting not existing users. I measured the time it took to
get a reply (accept / reject) after sending a password. Each test-run
was done a couple ten thousand times. I compared data from the two
test-runs within each scenario using a simple t-test. For scenario 1,
I found that the probability that one can guess that a user exist or
not is less than 0,0014%. For scenario 2 the probability is less
than 0.0021%. Albeit the probability is small, it increased four
orders in magnitude.

In my own opinion I have failed to disprove your suggestion. I now can
imagine that somebody who has knowledge on the subject can derive
useful information as a result from the alteration to login_yubikey.
So, in a nutshell: I guess you are right!

From the different diffs I've send in I learned that code needs to be
readable, regexp is a no-no and that the use of getpwnam is probably
not a good idea. I changed my first diff to reflect the above
learning's.

As I am out of alternative ideas: Opinions? / Alternatives? / Comments?


Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -p -r1.4 login_yubikey.c
--- login_yubikey.c 1 Feb 2012 16:07:28 -   1.4
+++ login_yubikey.c 5 Apr 2012 10:53:57 -
@@ -165,10 +165,18 @@ main(int argc, char *argv[])
 static int
 clean_string(const char *s)
 {
+   int nlim, n = 1;
+
+   nlim = strlen(s);
while (*s) {
-   if (!isalnum(*s)  *s != '-'  *s != '_')
+   if (n == 1  !isalnum(*s)  *s != '_')
+   return (0);
+   else if (n == nlim  !isalnum(*s)  *s != '_'  *s != '-')
+   return (0);
+   else if (!isalnum(*s)  *s != '_'  *s != '-'  *s != '.')
return (0);
++s;
+   ++n;
}
return (1);
 }

Re: login_yubikey does not accept user.name

[Björn Ketelaars]

2012/4/3 Theo de Raadt dera...@cvs.openbsd.org:
 Hmm, I'd like to see that refactored somehow.

 Also, '-' should not be legal at the start of a login name.  There
 are things that care.  I think at the end it is OK, though.

 Crazy eh.  Isn't there something else in libc that checks this?

New diff:

Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -r1.4 login_yubikey.c
--- login_yubikey.c 1 Feb 2012 16:07:28 -   1.4
+++ login_yubikey.c 4 Apr 2012 13:23:01 -
@@ -36,6 +36,7 @@
 #include ctype.h
 #include login_cap.h
 #include pwd.h
+#include regex.h
 #include stdarg.h
 #include stdio.h
 #include stdlib.h
@@ -165,12 +166,15 @@
 static int
 clean_string(const char *s)
 {
-   while (*s) {
-   if (!isalnum(*s)  *s != '-'  *s != '_')
-   return (0);
-   ++s;
-   }
-   return (1);
+   char p[] = ^[0-9a-z_]+(($|[0-9a-z_-]$)|([0-9a-z\\._-]+[0-9a-z_-]$));
+   int ret = 0;
+   regex_t r;
+
+   regcomp(r,p,REG_EXTENDED);
+   if (regexec(r,s,0,0,0) == 0)
+   ret = 1;
+   regfree(r);
+   return (ret);
 }

 static int

Re: login_yubikey does not accept user.name

[Björn Ketelaars]

 Why doesn't login_yubikey just use getpwnam() to check if the
 user exists like the other login_* mechs?

Why make it simple if there are exciting pattern matching options like
regexp or multiple if-statements ;-)

Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -r1.4 login_yubikey.c
--- login_yubikey.c 1 Feb 2012 16:07:28 -   1.4
+++ login_yubikey.c 4 Apr 2012 15:00:10 -
@@ -54,7 +54,6 @@

 static const char *path = /var/db/yubikey;

-static int clean_string(const char *);
 static int yubikey_login(const char *, const char *);

 int
@@ -102,8 +101,8 @@
/* passed by sshd(8) for non-existing users */
if (!strcmp(username, NOUSER))
exit(EXIT_FAILURE);
-   if (!clean_string(username)) {
-   syslog(LOG_ERR, clean_string username);
+   if (getpwnam(username) == NULL) {
+   syslog(LOG_ERR, invalid user %s, username);
exit(EXIT_FAILURE);
}

@@ -160,17 +159,6 @@
}
closelog();
return (EXIT_SUCCESS);
-}
-
-static int
-clean_string(const char *s)
-{
-   while (*s) {
-   if (!isalnum(*s)  *s != '-'  *s != '_')
-   return (0);
-   ++s;
-   }
-   return (1);
 }

 static int

Re: login_yubikey does not accept user.name

[Björn Ketelaars]

2012/4/4 Todd C. Miller todd.mil...@courtesan.com:
 Why do we care if the user exists?  Ideally, you want the code to
 behave more or less the same whether the user is real or not.
 Otherwise, a remote attacker can guess valid usernames by timing a
 login attempt.

 For safety's sake, it makes sense to reject a username with a '/'
 in it since the yubikey database is just a directory where each
 user has a file.  But I don't see the need to bail early just because
 the user is not in the passwd database since yubikey_login() will
 only succeed if the user has an entry.

You are right! It does not make sense to bail out early if the user
does not exist in the passwd database. However, I still like the idea
of using the same database for looking up purposes. So another
attempt: This time every type of username is accepted (comparable - in
behaviour - to login_passwd). The username and the password are then
passed to yubikey_login() which first checks if the username is valid,
i.e. exists in the passwd database. If not, then the user will receive
AUTH_FAILED).

OK?


Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -r1.4 login_yubikey.c
--- login_yubikey.c 1 Feb 2012 16:07:28 -   1.4
+++ login_yubikey.c 4 Apr 2012 19:04:23 -
@@ -54,7 +54,6 @@

 static const char *path = /var/db/yubikey;

-static int clean_string(const char *);
 static int yubikey_login(const char *, const char *);

 int
@@ -102,10 +101,6 @@
/* passed by sshd(8) for non-existing users */
if (!strcmp(username, NOUSER))
exit(EXIT_FAILURE);
-   if (!clean_string(username)) {
-   syslog(LOG_ERR, clean_string username);
-   exit(EXIT_FAILURE);
-   }

if (f == NULL  (f = fdopen(3, r+)) == NULL) {
syslog(LOG_ERR, user %s: fdopen: %m, username);
@@ -163,17 +158,6 @@
 }

 static int
-clean_string(const char *s)
-{
-   while (*s) {
-   if (!isalnum(*s)  *s != '-'  *s != '_')
-   return (0);
-   ++s;
-   }
-   return (1);
-}
-
-static int
 yubikey_login(const char *username, const char *password)
 {
char fn[MAXPATHLEN];
@@ -183,6 +167,10 @@
yubikey_token_st tok;
u_int32_t last_ctr = 0, ctr;

+   if (getpwnam(username) == NULL) {
+   syslog(LOG_INFO, user %s: invalid username, username);
+   return (AUTH_FAILED);
+   }
if (strlen(password)  32)
password = password + strlen(password) - 32;
if (strlen(password) != 32) {

Re: login_yubikey does not accept user.name

[Björn Ketelaars]

2012/4/1 Theo de Raadt dera...@cvs.openbsd.org:
 You should really re-do that so that the login name cannot start or
 end with a '.'

Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -r1.4 login_yubikey.c
--- login_yubikey.c 1 Feb 2012 16:07:28 -   1.4
+++ login_yubikey.c 1 Apr 2012 08:37:07 -
@@ -165,10 +165,15 @@
 static int
 clean_string(const char *s)
 {
+   int nlim, n = 0;
+
+   nlim = strlen(s) - 1;
while (*s) {
-   if (!isalnum(*s)  *s != '-'  *s != '_')
+   if (!isalnum(*s)  *s != '-'  *s != '_' 
+   !(*s == '.'  !(n == 0 || n == nlim)))
return (0);
++s;
+   n++;
}
return (1);
 }

login_yubikey does not accept user.name

[Björn Ketelaars]

login_yubikey does not accept user names with a dot (e.g. user.name).
If one is offered login fails. As other authentication types (e.g.
login_passwd) do accept the use of a dot, it seems that this is a
'feature' related to login_yubikey.

A small patch:

ok?



Index: login_yubikey.c
===
RCS file: /cvs/src/libexec/login_yubikey/login_yubikey.c,v
retrieving revision 1.4
diff -u -r1.4 login_yubikey.c
--- login_yubikey.c 1 Feb 2012 16:07:28 -   1.4
+++ login_yubikey.c 31 Mar 2012 12:57:30 -
@@ -166,7 +166,7 @@
 clean_string(const char *s)
 {
while (*s) {
-   if (!isalnum(*s)  *s != '-'  *s != '_')
+   if (!isalnum(*s)  *s != '-'  *s != '_'  *s != '.')
return (0);
++s;
}




--
Bjvrn Ketelaars

Re: turn on nginx via rc.conf rc

[Björn Ketelaars]

2012/3/27 Gonzalo L. R. gonz...@x61.com.ar:
 you need to send the patch inline only ports@ allow attach.

My mistake...again. This time inline:

Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.399
diff -u -r1.399 rc
--- rc  10 Mar 2012 10:37:13 -  1.399
+++ rc  27 Mar 2012 20:07:32 -
@@ -503,7 +503,7 @@
fi
 fi

-start_daemon hostapd rwhod lpd sendmail smtpd httpd ftpd ftpproxy tftpd
+start_daemon hostapd rwhod lpd sendmail smtpd nginx httpd ftpd ftpproxy tftpd
 start_daemon identd inetd rarpd bootparamd rbootd mopd popa3d
 start_daemon spamd spamlogd kdc kadmind kpasswdd sndiod
 echo '.'
Index: rc.conf
===
RCS file: /cvs/src/etc/rc.conf,v
retrieving revision 1.166
diff -u -r1.166 rc.conf
--- rc.conf 5 Mar 2012 10:43:42 -   1.166
+++ rc.conf 27 Mar 2012 20:07:32 -
@@ -16,6 +16,7 @@
 rbootd_flags=NO# for normal use: 
 sshd_flags=  # for normal use: 
 named_flags=NO # for normal use: 
+nginx_flags=NO # for normal use: 
 nsd_flags=NO   # for normal use: 
 ldattach_flags=NO  # for normal use: [options] linedisc cua-device
 ntpd_flags=NO  # for normal use: 

Unbound in base (review)

[Björn Ketelaars]

2012/3/14 Jakob Schlyter ja...@kirei.se (mailto:ja...@kirei.se):
 Could you provide an update complete tarfil for review by other developers?
I think we should start considering importing this.


Latest iteration:

http://gateway.hydroxide.nl/OpenBSD/unbound-wip.9.tar.gz

Current status includes work on suggestions / remarks from Jakob:

- run unbound-control-setup if no keys found;
- shipping of a default root.key (for use with auto-trust-anchor-file in
unbound.conf). This 'solves' a difficult and ugly workaround with
unbound-anchor as suggested in previous iterations;
- start nsd before unbound.

Detailed information can be found in the tarball (README).


--
BjC6rn Ketelaars

Re: Unbound in base

[Björn Ketelaars]

 The latest iteration includes:
 
 - Removal of ldns-includes, -library and -manpages;
 - Static link of ldns;
 - No shared libraries.


There was a nasty config-error in Makefile.bsd-wrapper which has been fixed in:

http://gateway.hydroxide.nl/OpenBSD/unbound-wip.8.tar.gz

This iteration also has removed some cruft files from both ldns and unbound. 
The tarball includes a README with additional information. 

Re: Unbound in base

[Björn Ketelaars]

 - Could you try to link ldns static and not install neither the ldns
library, include files nor the man-pages?

The latest iteration includes:

- Removal of ldns-includes, -library and -manpages;
- Static link of ldns;
- No shared libraries.

Tarball:

http://gateway.hydroxide.nl/OpenBSD/unbound-wip.6.tar.gz

Additional points of discussion:

1.) This iteration installs both drill and unbound-host as
dns-tooling. Unbound-host is part of unbound and, preferably, should
be installed. Drill however is a different story: it is part of ldns.
Are there arguments for installing / not installing drill?
2.) Are there arguments for installing / not installing both tools?
OpenBSD base already has some dns-tooling (dig, host, nslookup - from
BIND). Installing unbound-host and drill might be abundant?

--
Bjvrn Ketelaars

Re: Unbound in base

[Björn Ketelaars]

Latest iteration of trying to get unbound to fit in OpenBSD base can be
found here:

http://gateway.hydroxide.nl/OpenBSD/unbound-wip.5.tar.gz

Quite a few things have changed:

- better integration of ldns in unbound by writing a better
Makefile.bsd-wrapper (thanks to Ralf -at- ackstorm -dot- de);
- builds and installs on amd64 / i386
- builds and installs on sparc64 (thanks to Ralf)
- builds and installs on vax - simh emulator (again, thanks to Ralf)

From README (included with tarball):

- Use of unbound 1.4.16 and ldns 1.6.12
- Integration of unbound is non invasive. Meaning no other pieces of
software are being removed. Just another flag in rc.conf
- drill is installed (as possible addition to BIND-tooling)
- Unbound-control-setup generates self-signed certificate and private keys
- etc/rc - make_keys()
- Added _unbound user and group (picked 102 as uid)
- Some additions to etc/Makefile (directory creation and installation of
root.hint and unbound.conf)
- rc.d-script for control of unbound daemon
- rc.d-script contains rc_pre() to create anchor file (root.key). However,
this function does not run per default (depending on specific setting in
unbound.conf)


Anybody feels like testing and / or commenting the above?

Re: Unbound in base

[Björn Ketelaars]

 I agree, however I cannot help with these arches as I do not have
 access to them. Anyone does?

 I tested another arch, alpha with -current from 2012-02-12. A couple
 of build scripts needed executable bits to build successfully, like
 install-sh and libtool (hppa had the same issue, of course, forgot to
 mention that). Other than that, it works fine.

Thanks for the feedback! The executable bits got lost during archiving
(using tar _without_ the -p flag). My fault...

I made an update based on unbound 1.4.16 and different pieces of
feedback. Current status:

- Use of unbound 1.4.16 and ldns 1.6.12
- Integration of unbound is non invasive. Meaning no other pieces of
software are being removed. Just another flag in rc.conf
- drill is installed (as possible addition to BIND-tooling)
- Unbound-control-setup generates self-signed certificate and private
keys - etc/rc - make_keys()
- Added _unbound user and group (picked 102 as uid)
- Some additions to etc/Makefile (directory creation and installation
of root.hint and unbound.conf)
- rc.d-script for control of unbound daemon
- rc.d-script contains rc_pre() to create anchor file (root.key).
However, this function does not run per default (depending on specific
setting in unbound.conf)
- executable bits are preserved

Updated set of files and diffs are here:

http://gateway.hydroxide.nl/OpenBSD/unbound-wip.2.tar.gz

--
Bjvrn Ketelaars

Re: Unbound in base

[Björn Ketelaars]

2012/2/13 Stuart Henderson s...@spacehopper.org:
...
 After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit
to
 large to send to this list. if anyone feels like looking at the workbdo
not
 hesitate to mail me.

 Please do. It would be nice to put them on a public server.


WIP can be found here:

http://goo.gl/BIRR5

.tar.gz contains a README which explains the status


--
Bjvrn Ketelaars

Re: Unbound in base

[Björn Ketelaars]

On Tue, Feb 14, 2012 at 9:17 PM, roberth rob...@openbsd.pap.st wrote:
 On Mon, 13 Feb 2012 22:35:15 +0100
 Bjvrn Ketelaars bjorn.ketela...@hydroxide.nl wrote:

 How and when do we automatically generate unbound-control keys? if
 so, where should that be done?

 Simply don't bother?
 rndc keys aren't setup automagically either.
 The daemon will work just fine without it, let it be up to the admin
 who wants to use it.

For basic operation (read: local starting and / or stopping of the
daemon) the use of unbound-control is not necessary. One could use
/etc/rc.d/unbound for this. However, for the neat stuff [1] one needs
unbound-control and therefore signed keys.

Concerning rndc and generating shared secret. This is done by the
system startup script run by init on autoboot or after single-user.
From /etc/rc:


if [ X${named_flags} != XNO ]; then
if ! cmp -s /etc/rndc.key /var/named/etc/rndc.key ; then
echo -n rndc-confgen: generating shared secret... 
if rndc-confgen -a -t /var/named /dev/null 21;
then
chmod 0640 /var/named/etc/rndc.key \
/dev/null 21
echo done.
else
echo failed.
fi
fi
fi


The option is there, it is easy to implement and is easy to use. So,
why not make it default?


[1] http://www.rootr.net/man/man/unbound-control/8

--
Bjvrn Ketelaars

Re: Unbound in base

[Björn Ketelaars]

 2.) Testing (read: does it compile and work) on AMD64.

 amd64 is easy, better questions are things like does it build/work on vax
 (gcc2, no shared libs), does it work on unusual arch like hppa, etc.

I agree, however I cannot help with these arches as I do not have
access to them. Anyone does?

 What to do with the BIND tools (dig/host/nslookup)?

 I don't think drill is quite a sufficient replacement for dig yet,
 and the other tools are certainly still used and I'd expect to find them
 in the base OS. So at this point I think they should stay.

Clear on this point! I will loo

 From unbound-anchor.8 I understand that unbound-anchor can be run from the
 command line, or run as part of startup scripts _before_ the actual
(unbound)
 DNS server is started. So there is no need for DNS. Proposal therefor is
to
 run unbound-anchor automatically before starting the unbound daemon (rc_pre
in
 unbound rc-script).

 This (i.e. connecting out to https://data.iana.org from the system startup
 scripts) should *not* happen by default even if unbound is enabled. There
 would need to be a separate option controlling this.

This is tricky! Using unbound-anchor - as a function of unbound_flags
(rc.conf) and some 'magic' in the unbound rc.d-script - is the easy
part.
It is possible to use 'auto-trust-anchor-file' (unbound.conf) as
default. However, when there is no anchor-file a built-in value is
used. Not a pretty solution. Now the hard part: How do we make
unbound.conf listen to unbound_flags (rc.conf)? Any ideas or
alternative solutions?


--
Bjvrn Ketelaars

Unbound in base

[Björn Ketelaars]

Hello,

After some recent discussions [1, 2] on the topic of unbound in base, and
(more important) really liking the idea of an alternative for BIND in base, I
made a start with fitting the different pieces of the puzzle. What is
finished:

1.) Integration of ldns 1.6.12 and unbound 1.4.15 and writing of relevant
Makefile wrappers. Wrapper script also compiles and installs drill;
2.) Testing (read: does it compile and work) on AMD64.

Stuart Henderson had some good remarks on integrating the above [3]. What do
you guys think of the following:

What to do with the BIND tools (dig/host/nslookup)?

Unbound offers drill. From drill.1: The name drill is a pun on dig. With
drill you should be able get even more information than with dig.. Proposal
therefore is to replace the BIND tools with drill.

Do we run unbound-anchor automatically? if so, how do we handle possibly not
having working DNS at that time to resolve data.iana.org
(http://data.iana.org) (http://data.iana.org)?

From unbound-anchor.8 I understand that unbound-anchor can be run from the
command line, or run as part of startup scripts _before_ the actual (unbound)
DNS server is started. So there is no need for DNS. Proposal therefor is to
run unbound-anchor automatically before starting the unbound daemon (rc_pre in
unbound rc-script).



How and when do we automatically generate unbound-control keys? if so, where
should that be done? b

From unbound-control.8: The script unbound-control-setup generates these
control keys in the default run directory. If you change the access control
permissions on the key files you can decide who can use unbound-control. Run
the script under the same username as you have configured in unbound.conf or
as root, so that the daemon is permitted to read the files, for example with:
sudo -u unbound unbound-control-setup. If you have not configured a username
in unbound.conf, the keys need read permission for the user credentials under
which the daemon is started. The script preserves private keys present in the
directory. After running the script as root, turn on control-enable in
unbound.conf.

The unbound-control-script can be called from rc-make_keys(). The knob
'control-enable' can be set as default.

After tar/gzip the source files and Makefile wrappers weigh ~4.6MB. A bit to
large to send to this list. if anyone feels like looking at the workbdo not
hesitate to mail me.

Again, what do you guys think?

Kind regards,

BjC6rn


[1] http://marc.info/?l=openbsd-miscm=132205020820910w=2
[2] http://marc.info/?l=openbsd-techm=132573371521516w=2
[3] http://marc.info/?l=openbsd-miscm=132217547525487w=2