snmp(1) Let walk options work on bulkwalk
When originally writing snmp(1) I wanted to stay as close to netsnmp as possible to make sure I didn't introduce anything I would regret. Now that 6.6 is out the door and I'm feeling more comfortable with the tool I want to start being a little more lenient. Here's a first step by allowing the -C options that work on walk to also work on bulkget. I see no reason why these should be exclusive to walk. OK? martijn@ Index: snmp.1 === RCS file: /cvs/src/usr.bin/snmp/snmp.1,v retrieving revision 1.8 diff -u -p -r1.8 snmp.1 --- snmp.1 26 Oct 2019 17:43:52 - 1.8 +++ snmp.1 28 Oct 2019 06:22:33 - @@ -202,7 +202,9 @@ On some devices that return MIBs out of this may cause an infinite loop. .It Cm E Ar endoid For -.Cm walk , +.Cm walk +and +.Cm bulkwalk , walk the tree up to but excluding .Ar endoid . The blank before @@ -210,7 +212,9 @@ The blank before is mandatory. .It Cm I For -.Cm walk , +.Cm walk +and +.Cm bulkwalk do not fall back to returning the original MIB via a .Cm get request. @@ -258,7 +262,9 @@ No blank is allowed before .Ar maxrep . .It Cm t For -.Cm walk , +.Cm walk +and +.Cm bulkwalk , Show how long it took to walk the entire tree. .El .It Fl c Ar community Index: snmpc.c === RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v retrieving revision 1.17 diff -u -p -r1.17 snmpc.c --- snmpc.c 26 Oct 2019 19:34:15 - 1.17 +++ snmpc.c 28 Oct 2019 06:22:33 - @@ -328,12 +328,14 @@ main(int argc, char *argv[]) i = strtolp - optarg - 1; break; case 't': - if (strcmp(snmp_app->name, "walk")) + if (strcmp(snmp_app->name, "walk") && + strcmp(snmp_app->name, "bulkwalk")) usage(); print_time = 1; break; case 'E': - if (strcmp(snmp_app->name, "walk")) + if (strcmp(snmp_app->name, "walk") && + strcmp(snmp_app->name, "bulkwalk")) usage(); if (smi_string2oid(argv[optind], &walk_end) != 0) @@ -343,7 +345,8 @@ main(int argc, char *argv[]) optind++; continue; case 'I': - if (strcmp(snmp_app->name, "walk")) + if (strcmp(snmp_app->name, "walk") && + strcmp(snmp_app->name, "bulkwalk")) usage(); walk_fallback_oid = 0; break;
Re: HID devices without numbered reports
On Mon, 28 Oct 2019, Damien Miller wrote: > BTW, the token still becomes unresponsive after the first transaction, > but looking at a sniff (using an OpenViszla), it seems we're getting the > DATA0/DATA1 flipping incorrect on the wire. > > On OpenBSD, this is the last rx of the transaction with the card: > > [] 12.992349 d= 0.001951 [154.0 + 3.500] [ 3] IN : 8.4 > [] 12.992352 d= 0.03 [154.0 + 6.667] [ 67] DATA0: 00 10 00 01 > 0e 1b 4a 78 ec 87 06 bd 47 d4 a0 49 d9 c7 2d 89 d9 7e 2c c5 62 87 53 92 9b 90 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 3a e8 > > and this is the first tx of the first packet of the subsequent transaction > that hangs: > > [] 22.201067 d= 0.001998 [146.0 + 4.333] [ 3] OUT : 8.4 > [] 22.201070 d= 0.03 [146.0 + 7.583] [ 67] DATA0: ff ff ff ff > 86 00 08 c0 65 eb 53 9a 48 04 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 d6 1d Since I don't really understand how USB sequence numbers work, it just occurred to me to check the sequence bit on the last sent packet. It too is a DATA0, so the sequence is definitiely getting lost across close+open. Here's an annotated trace - starting with the last command sent to a Yk5 token during key enrollment: [] 9.212345 d= 0.001992 [ 2 + 4.333] [ 3] OUT : 10.4 [] 9.212349 d= 0.03 [ 2 + 7.583] [ 67] DATA1: 00 13 00 01 83 00 47 00 01 00 00 00 00 40 a9 dc 95 51 0e ec 44 6d 7a b1 14 88 d1 84 93 b4 aa d2 e5 10 11 db 9c fa b4 b3 0b 89 2c ea 3f b9 e3 06 10 e8 a1 62 11 59 60 fe 1e c2 23 e6 52 9c 9f 4b 8a c8 [] 9.212395 d= 0.46 [ 2 + 53.750] [ 1] ACK [] 9.212397 d= 0.02 [ 2 + 55.667] [ 3] IN : 10.4 [] 9.212400 d= 0.03 [ 2 + 58.833] [ 1] NAK [] 9.214346 d= 0.001946 [ 4 + 4.500] [ 3] OUT : 10.4 [] 9.214349 d= 0.03 [ 4 + 7.750] [ 67] DATA0: 00 13 00 01 00 6e 80 20 0d cb 5e 5c 32 1c 8a f1 e2 b1 bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 7c [] 9.214395 d= 0.46 [ 4 + 53.750] [ 1] ACK [] 9.214397 d= 0.02 [ 4 + 55.667] [ 3] IN : 10.4 [] 9.214400 d= 0.03 [ 4 + 58.833] [ 1] NAK [] 9.216345 d= 0.001945 [ 6 + 4.000] [ 3] IN : 10.4 [] 9.216349 d= 0.03 [ 6 + 7.167] [ 1] NAK Note that the last OUT was a DATA0. The token replies with a bunch of data: [] 9.350355 d= 0.001997 [140 + 3.250] [ 3] IN : 10.4 [] 9.350358 d= 0.03 [140 + 6.417] [ 67] DATA1: 00 13 00 01 83 03 8d 05 04 f6 80 b1 df 4d 8e fe 30 cd a0 2c 42 e1 a1 46 52 9f 8a 06 80 21 78 7a 73 71 e3 f3 0a e6 f6 e0 74 54 ef df 0c 74 ed be 3f 35 1d dd 35 cf 33 14 fc 33 6e b6 45 11 bd f5 79 99 [] 9.350404 d= 0.46 [140 + 52.417] [ 1] ACK [] 9.352356 d= 0.001951 [142 + 3.750] [ 3] IN : 10.4 [] 9.352359 d= 0.03 [142 + 6.917] [ 67] DATA0: 00 13 00 01 00 61 98 66 2c 14 5f 65 e5 4c 40 df 01 56 e8 d8 2b e8 f7 a8 ff 00 96 a6 f3 95 00 d9 93 87 cb c8 b1 02 23 ec 8f 38 37 b8 cf da 73 62 18 90 ff 8b 01 cf a1 78 61 3e cc 48 ac 7b 45 4f b0 6b [] 9.352405 d= 0.46 [142 + 53.167] [ 1] ACK [] 9.354356 d= 0.001950 [144 + 3.500] [ 3] IN : 10.4 [] 9.354359 d= 0.03 [144 + 6.667] [ 67] DATA1: 00 13 00 01 01 4a 0d 3a 6d d7 ca fc 00 e1 ad 7e 78 b1 9d 88 30 82 02 bd 30 82 01 a5 a0 03 02 01 02 02 04 18 ac 46 c0 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 30 2e 31 2c 30 2a 06 03 55 04 83 af [] 9.354405 d= 0.46 [144 + 52.833] [ 1] ACK [] 9.356356 d= 0.001951 [146 + 3.583] [ 3] IN : 10.4 [] 9.356359 d= 0.03 [146 + 6.750] [ 67] DATA0: 00 13 00 01 02 03 13 23 59 75 62 69 63 6f 20 55 32 46 20 52 6f 6f 74 20 43 41 20 53 65 72 69 61 6c 20 34 35 37 32 30 30 36 33 31 30 20 17 0d 31 34 30 38 30 31 30 30 30 30 30 30 5a 18 0f 32 30 98 68 [] 9.356405 d= 0.46 [146 + 52.667] [ 1] ACK [] 9.358356 d= 0.001951 [148 + 3.583] [ 3] IN : 10.4 [] 9.358359 d= 0.03 [148 + 6.750] [ 67] DATA1: 00 13 00 01 03 35 30 30 39 30 34 30 30 30 30 30 30 5a 30 6e 31 0b 30 09 06 03 55 04 06 13 02 53 45 31 12 30 10 06 03 55 04 0a 0c 09 59 75 62 69 63 6f 20 41 42 31 22 30 20 06 03 55 04 0b 0c 19 69 76 [] 9.358405 d= 0.46 [148 + 52.667] [ 1] ACK [] 9.360357 d= 0.001952 [150 + 4.833] [ 3] IN : 10.4 [] 9.360361 d= 0.03 [150 + 8.000] [ 67] DATA0: 00 13 00 01 04 41 75 74 68 65 6e 74 69 63 61 74 6f 72 20 41 74 74 65 73 74 61 74 69 6f 6e 31 27 30 25 06 03 55 04 03 0c 1e 59 75 62 69 63 6f 20 55 32 4
Re: vmctl: start: Require one interface at minimium with -i
On Sat, Oct 26, 2019 at 12:57:56AM +0200, Klemens Nanni wrote:
> It makes no sense to allow zero interfaces; either a positive count is
> given or -i is omitted entirely. vm.conf(5) does not allow interface
> configuration that results in zero interfaces either.
>
> $ doas vmctl start -Li0 -b ~/bsd.rd foo
> vmctl: starting without disks
> vmctl: started vm 6 successfully, tty /dev/ttyph
>
> Diff below raises the minimum to one and tells more about invalid counts
> with the usual strtonum(3) idiom:
>
> $ doas vmctl start -Li-1 -b ~/bsd.rd foo
> vmctl: invalid count "-1": too small
> vmctl: invalid interface count: -1
> $ doas ./obj/vmctl start -Li0 -b ~/bsd.rd foo
> vmctl: count is too small: 0
> vmctl: invalid interface count: 0
>
> Those duplicate errors aren't easily merged without breaking consistency
> with how all the command line flags are passed, so I did nothing about
> this.
>
> OK?
>
>
> Index: main.c
> ===
> RCS file: /cvs/src/usr.sbin/vmctl/main.c,v
> retrieving revision 1.58
> diff -u -p -r1.58 main.c
> --- main.c23 Aug 2019 07:55:20 - 1.58
> +++ main.c25 Oct 2019 22:48:49 -
> @@ -373,9 +373,9 @@ parse_ifs(struct parse_result *res, char
> const char *error;
>
> if (word != NULL) {
> - val = strtonum(word, 0, INT_MAX, &error);
> + val = strtonum(word, 1, INT_MAX, &error);
> if (error != NULL) {
> - warnx("invalid count \"%s\": %s", word, error);
> + warnx("count is %s: %s", error, word);
> return (-1);
> }
> }
>
ok mlarkin@ if you are still looking to do this.
[patch]: www/errata66.html: remove self reference
Index: errata66.html === RCS file: /cvs/www/errata66.html,v retrieving revision 1.2 diff -u -p -u -r1.2 errata66.html --- errata66.html 27 Oct 2019 20:01:00 - 1.2 +++ errata66.html 27 Oct 2019 22:07:59 - @@ -67,8 +67,7 @@ For errata on a certain release, click b 6.2, 6.3, 6.4, -6.5, -6.6. +6.5.
Re: HID devices without numbered reports
On Fri, 25 Oct 2019, Patrick Wildt wrote:
> > So from what I understood the Yubikey expects the transfer to happen
> > on the Interrupt OUT pipe instead of doing a control transfer. Read-
> > ing some code and documentation, it looks like that we should by de-
> > fault send our reports on the interrupt pipe, and only if it does not
> > exist fall back to control transfers. Linux seems to do exactly that.
> >
> > I tried to come up with the following diff, which appeard to make a
> > test program work for me. Though I'm not sure I got all the specifics
> > right.
> >
> > Can you give this a go with your test progam?
> >
> > Patrick
>
> Oops, obvious error. Though I still cannot write/read multiple times
> in a row, so there is probably still something wrong (unless my test
> is as well).
It didn't work for me - I think because uhidev_set_report() (and _async)
is still prepending a report ID. If I modify uhid.c to send writes
without a report ID, then it does work:
Index: uhid.c
===
RCS file: /cvs/src/sys/dev/usb/uhid.c,v
retrieving revision 1.71
diff -u -p -r1.71 uhid.c
--- uhid.c 1 May 2018 18:14:46 - 1.71
+++ uhid.c 27 Oct 2019 22:03:16 -
@@ -322,7 +322,7 @@ uhid_do_write(struct uhid_softc *sc, str
error = uiomove(sc->sc_obuf, size, uio);
if (!error) {
if (uhidev_set_report(sc->sc_hdev.sc_parent,
- UHID_OUTPUT_REPORT, sc->sc_hdev.sc_report_id, sc->sc_obuf,
+ 0, sc->sc_hdev.sc_report_id, sc->sc_obuf,
size) != size)
error = EIO;
}
I don't think this is optimal though - perhaps we should do something
like Linux: if the endpoint has an output report then use it, and fall
back to not prepending a report ID otherwise. This should be compatible
with current devices too (well, at least it shouldn't break any that
aren't already broken.)
(again, caveat - I don't know much about USB programming).
-d
/etc/daily : flexible df output
In version 1.78 of /etc/daily, the -i flag was added to the df output.
Apparently, some people run out of inodes.
I only seem to run out of disk space, and too often, my eye skims
the daily report from a machine, looks at the last column,sees a
small percentage, and I decide, "all is good", even if I were
look a couple columns in, the actual disk space is low.
To try to avoid bikeshedding and flopping this back and forth,
I offer this diff. With no change, daily df output is unchanged.
Those of us that don't worry about running out of inodes, we can
set DF_FLAGS in /etc/daily.local to be whatever we want, in my
case, I like "-hl" (currently, it's "-ikl")
(inline and attached)
Index: daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.93
diff -u -r1.93 daily
--- daily 9 Sep 2019 20:02:26 - 1.93
+++ daily 27 Oct 2019 18:03:18 -
@@ -44,6 +44,10 @@
start_part "Running daily.local:"
run_script "daily.local"
+if [ -z "$DF_FLAGS" ]; then
+ DF_FLAGS="-ikl"
+fi
+
next_part "Removing scratch and junk files:"
if [ -d /tmp -a ! -L /tmp ]; then
cd /tmp && {
@@ -140,7 +144,7 @@
if [ "X$VERBOSESTATUS" != X0 ]; then
echo ""
echo "disks:"
- df -ikl
+ df "$DF_FLAGS"
echo ""
dump W
else
Index: daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.93
diff -u -r1.93 daily
--- daily 9 Sep 2019 20:02:26 - 1.93
+++ daily 27 Oct 2019 18:24:16 -
@@ -44,6 +44,10 @@
start_part "Running daily.local:"
run_script "daily.local"
+if [ -z "$DF_FLAGS" ]; then
+ DF_FLAGS="-ikl"
+fi
+
next_part "Removing scratch and junk files:"
if [ -d /tmp -a ! -L /tmp ]; then
cd /tmp && {
@@ -140,7 +144,7 @@
if [ "X$VERBOSESTATUS" != X0 ]; then
echo ""
echo "disks:"
- df -ikl
+ df "$DF_FLAGS"
echo ""
dump W
else
Re: [PATCH] ksh: Fail gracefully if sethistsize() fails
On Sat, Oct 19 2019, tho...@habets.se wrote:
> On Sat, 19 Oct 2019 16:32:56 +0100, Jeremie Courreges-Anglas
> said:
>> > Before:
>> > $ HISTSIZE=10 /bin/sh
>> > /bin/sh: internal error: unable to allocate memory
>> > <--- no ksh
>> Could you provide more details please? A fatal error and a crash are
>> very different problems.
>
> Yes, it's a fatal error resulting in a termination since nothing
> "catches" the internal_errorf() from the allocation failure.
>
>> Does "no ksh" imply that the *current* shell
>> exited or crashed, leaving you with no shell at all?
>
> It does not crash the current shell. But if the current shell is not
> ksh, then the experience is:
>
> bash$ /bin/sh
> ksh: internal error: unable to allocate memory
> bash$
>
> Which is not hugely informative. My actual experience was that running
> "some commands" failed with this error, because they ran shell scripts
> either directly or indirectly. So I was not directly running ksh or
> /bin/sh when I first got these errors.
>
> I don't have a specific use case where this would lock you out of
> troubleshooting, but seems plausible.
>
>> Note that setting HISTSIZE like this affects your *current* shell and
>> prevents it to run /bin/sh. Use env to only affect the child shell:
>
> My current shell is usually bash, which handles large HISTSIZE (I
> don't know if by mmaping the file, a capped effective size, or some
> other way).
Ok, thankd for those details.
>> Your diff doesn't apply as is.
>
> Sorry about that. I used github.com/openbsd/src HEAD, and am looking
> forward to got (https://gameoftrees.org/). Maybe I still screwed up somehow.
>
>> After applying it, the child ksh will
>> indeed keep running even if setting HISTSIZE fails. But it reliably
>> crashes on exit if HISTSIZE was set in its startup environment:
>>
>> --8<--
>> ritchie /usr/src/bin/ksh$ env ENV=/dev/null HISTFILE=ksh_history
>> HISTSIZE=1000 obj/ksh
>> ritchie$ ^D
>> Unable to set the history size to 0
>> Trace/BPT trap (core dumped)
>> -->8--
>
> Confirmed that I made it crash on exit if and only if the HISTSIZE is
> *low*. I was missing a quitenv(NULL) as the last line in
> sethistsize(). After adding that it works as it should for both normal
> and oversized HISTSIZE.
>
> I'm not familiar with the "environment" concept in the code, and could
> not find it documented, thus missed that.
>
>> I think we can do ourselves a favor and not involve unwinding/setjmps
>> for this simple error case.
>> Using alloc.c to allocate histbase is not useful,
>
> That would be ideal, yes, if there's no reason to use alloc.c here.
>
>> so just switch to reallocarray. Allocation failure at startup
>> is still fatal because the code can't cope with a NULL history array.
>>
>> ok?
>
> Yeah, that looks better, and I can confirm that it works as expected
> for me now, both for small and large HISTSIZE.
Committed.
> I don't know what the general philosophy of footguns are for you, but
> a cap on HISTSIZE could prevent someone having ksh consume 764MB RAM
> (as seen by top with HISTSIZE=1).
The allocation policy could be smarter indeed. Pre-allocating such
a huge array doesn't bring much value. If someone wants to take a stab
at it they're welcome to do so.
> Thanks!
Sure. Thank you too for caring.
>>
>>
>> Index: history.c
>> ===
>> RCS file: /cvs/src/bin/ksh/history.c,v
>> retrieving revision 1.82
>> diff -u -p -r1.82 history.c
>> --- history.c28 Jun 2019 13:34:59 - 1.82
>> +++ history.c19 Oct 2019 15:29:04 -
>> @@ -554,6 +554,7 @@ void
>> sethistsize(int n)
>> {
>> if (n > 0 && (uint32_t)n != histsize) {
>> +char **tmp;
>
> why not void* ?
Because char ** is the right type here. I see no reason to use the
weaker semantics of void * where they aren't not needed.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
