Re: missing newlines in est.c printfs
On Thu, Aug 12, 2021 at 03:01:37PM +1000, Jonathan Gray wrote:
> On Thu, Aug 12, 2021 at 06:44:51AM +0200, Theo Buehler wrote:
> > There doesn't seem to be a good reason for omitting the newlines here.
> > If those are ever hit, it will look odd. Am I missing something?
>
> See the i386 p3_get_bus_clock() which is where this came from.
> i386 prints the msr value and a newline.
>
> Wether that part is added to amd64 or removed from i386 it would be best
> to keep them in sync as much as possible.
Thanks. This syncs the print_msr code path from i386 in p3_get_bus_clock
and adds the missing newlines in est_acpi_pss_changed() in i386.
Index: sys/arch/i386/i386/est.c
===
RCS file: /cvs/src/sys/arch/i386/i386/est.c,v
retrieving revision 1.52
diff -u -p -r1.52 est.c
--- sys/arch/i386/i386/est.c31 Mar 2018 13:45:03 - 1.52
+++ sys/arch/i386/i386/est.c12 Aug 2021 05:46:12 -
@@ -1017,14 +1017,14 @@ est_acpi_pss_changed(struct acpicpu_pss
if ((acpilist = malloc(sizeof(struct fqlist), M_DEVBUF, M_NOWAIT))
== NULL) {
printf("est_acpi_pss_changed: cannot allocate memory for new "
- "est state");
+ "est state\n");
return;
}
if ((acpilist->table = mallocarray(npss, sizeof(struct est_op),
M_DEVBUF, M_NOWAIT)) == NULL) {
printf("est_acpi_pss_changed: cannot allocate memory for new "
- "operating points");
+ "operating points\n");
free(acpilist, M_DEVBUF, sizeof(*acpilist));
return;
}
Index: sys/arch/amd64/amd64/est.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
retrieving revision 1.40
diff -u -p -r1.40 est.c
--- sys/arch/amd64/amd64/est.c 11 Aug 2021 18:15:50 - 1.40
+++ sys/arch/amd64/amd64/est.c 12 Aug 2021 05:32:49 -
@@ -187,7 +187,7 @@ p3_get_bus_clock(struct cpu_info *ci)
default:
printf("%s: unknown Core FSB_FREQ value %d",
ci->ci_dev->dv_xname, bus);
- break;
+ goto print_msr;
}
break;
case 0x1c: /* Atom */
@@ -211,13 +211,20 @@ p3_get_bus_clock(struct cpu_info *ci)
default:
printf("%s: unknown Atom FSB_FREQ value %d",
ci->ci_dev->dv_xname, bus);
- break;
+ goto print_msr;
}
break;
default:
/* no FSB on modern Intel processors */
break;
}
+ return;
+print_msr:
+ /*
+* Show the EBL_CR_POWERON MSR, so we'll at least have
+* some extra information, such as clock ratio, etc.
+*/
+ printf(" (0x%llx)\n", rdmsr(MSR_EBL_CR_POWERON));
}
#if NACPICPU > 0
@@ -291,14 +298,14 @@ est_acpi_pss_changed(struct acpicpu_pss
if ((acpilist = malloc(sizeof(struct fqlist), M_DEVBUF, M_NOWAIT))
== NULL) {
printf("est_acpi_pss_changed: cannot allocate memory for new "
- "est state");
+ "est state\n");
return;
}
if ((acpilist->table = mallocarray(npss, sizeof(struct est_op),
M_DEVBUF, M_NOWAIT)) == NULL) {
printf("est_acpi_pss_changed: cannot allocate memory for new "
- "operating points");
+ "operating points\n");
free(acpilist, M_DEVBUF, sizeof(struct fqlist));
return;
}
Re: missing newlines in est.c printfs
On Thu, Aug 12, 2021 at 06:44:51AM +0200, Theo Buehler wrote:
> There doesn't seem to be a good reason for omitting the newlines here.
> If those are ever hit, it will look odd. Am I missing something?
See the i386 p3_get_bus_clock() which is where this came from.
i386 prints the msr value and a newline.
Wether that part is added to amd64 or removed from i386 it would be best
to keep them in sync as much as possible.
>
> Index: est.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 est.c
> --- est.c 11 Aug 2021 18:15:50 - 1.40
> +++ est.c 12 Aug 2021 04:40:14 -
> @@ -185,7 +185,7 @@ p3_get_bus_clock(struct cpu_info *ci)
> bus_clock = BUS333;
> break;
> default:
> - printf("%s: unknown Core FSB_FREQ value %d",
> + printf("%s: unknown Core FSB_FREQ value %d\n",
> ci->ci_dev->dv_xname, bus);
> break;
> }
> @@ -209,7 +209,7 @@ p3_get_bus_clock(struct cpu_info *ci)
> bus_clock = BUS200;
> break;
> default:
> - printf("%s: unknown Atom FSB_FREQ value %d",
> + printf("%s: unknown Atom FSB_FREQ value %d\n",
> ci->ci_dev->dv_xname, bus);
> break;
> }
> @@ -291,14 +291,14 @@ est_acpi_pss_changed(struct acpicpu_pss
> if ((acpilist = malloc(sizeof(struct fqlist), M_DEVBUF, M_NOWAIT))
> == NULL) {
> printf("est_acpi_pss_changed: cannot allocate memory for new "
> - "est state");
> + "est state\n");
> return;
> }
>
> if ((acpilist->table = mallocarray(npss, sizeof(struct est_op),
> M_DEVBUF, M_NOWAIT)) == NULL) {
> printf("est_acpi_pss_changed: cannot allocate memory for new "
> - "operating points");
> + "operating points\n");
> free(acpilist, M_DEVBUF, sizeof(struct fqlist));
> return;
> }
>
>
missing newlines in est.c printfs
There doesn't seem to be a good reason for omitting the newlines here.
If those are ever hit, it will look odd. Am I missing something?
Index: est.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
retrieving revision 1.40
diff -u -p -r1.40 est.c
--- est.c 11 Aug 2021 18:15:50 - 1.40
+++ est.c 12 Aug 2021 04:40:14 -
@@ -185,7 +185,7 @@ p3_get_bus_clock(struct cpu_info *ci)
bus_clock = BUS333;
break;
default:
- printf("%s: unknown Core FSB_FREQ value %d",
+ printf("%s: unknown Core FSB_FREQ value %d\n",
ci->ci_dev->dv_xname, bus);
break;
}
@@ -209,7 +209,7 @@ p3_get_bus_clock(struct cpu_info *ci)
bus_clock = BUS200;
break;
default:
- printf("%s: unknown Atom FSB_FREQ value %d",
+ printf("%s: unknown Atom FSB_FREQ value %d\n",
ci->ci_dev->dv_xname, bus);
break;
}
@@ -291,14 +291,14 @@ est_acpi_pss_changed(struct acpicpu_pss
if ((acpilist = malloc(sizeof(struct fqlist), M_DEVBUF, M_NOWAIT))
== NULL) {
printf("est_acpi_pss_changed: cannot allocate memory for new "
- "est state");
+ "est state\n");
return;
}
if ((acpilist->table = mallocarray(npss, sizeof(struct est_op),
M_DEVBUF, M_NOWAIT)) == NULL) {
printf("est_acpi_pss_changed: cannot allocate memory for new "
- "operating points");
+ "operating points\n");
free(acpilist, M_DEVBUF, sizeof(struct fqlist));
return;
}
Re: date -j and seconds since the Epoch
On Wed, Aug 11, 2021 at 03:44:33PM +0200, Ingo Schwarze wrote: > Hi, > > > ok gerhard@ > > Thanks for reporting, for the initial patch, and for checking the > final one. This now committed. > > Yours, > Ingo Thanks to all for working together and getting this fixed. Bryan
Re: [External] : TCP missing window update stalls connection
Hello, On Mon, Aug 09, 2021 at 01:17:27PM +0200, Alexander Bluhm wrote: > On Fri, Aug 06, 2021 at 05:22:18PM +0200, Alexandr Nedvedicky wrote: > > > Although I did not obverve it, there seems to be the same problem > > > for snd_wl1 and rcv_up. For rcv_up I copied the comparison with > > > rcv_nxt from urgent processing to keep future urgent data. > > Over the weekend I thought about the SEQ_GT(tp->rcv_nxt, tp->rcv_up) > check. I think FreeBSD is right and we don't need it. > > In the regular case we may receive a retransmit of an old packet. > This check preserves the rcv_up from packets that we received earlier > but with higher sequence number. But in the header prediction code > we know that TAILQ_EMPTY(>t_segq). So the current packet is > the most recent one and we can blindly take its rcv_nxt as urgent > pointer. > > So maybe we want take the simplified diff below. I agree here. > > > can you also share some details about testing you have done? > > (tool + command line options) > > That is quite tricky. I do not have a simple test case for that. > One of our OpenBSD based product guarantees unidirectional traffic. > We habe a userland process that receives the data, sends it to > another OpenBSD machine. There it goes to socket splicing and > finaly it ends in a Linux FTP server. > > some magic -> user land sending process --> socket splicing --> Linux FTP > > I suspect that with all the machines and processes involved, we > have strange timing and run into the race. > looks like one has to be (un)lucky enough to trigger the session stale. I think it's worth to get it in. OK sashan
Re: libedit: stop playing hopeless games with FIONBIO
On Wed, 11 Aug 2021 18:50:10 +0200, Ingo Schwarze wrote: > in its current state, the editline(3) library is completely unfit > to work with non-blocking I/O. Neither the API nor the implementation > are even designed for that purpose. > > Consequently, i propose that we document the facts up front and > simply delete some code that isn't going to do any good in practice. > For programs not using non-blocking I/O on the editline input file > descriptor, this patch makes no difference. Programs that do set > FIONBIO on a file descriptor and then call editline(3) on it anyway > can't possibly work as intended as far as i can see. Either setting > FIONBIO is needless in the first place, or el_gets(3) clearing it > will ruin the rest of the program's functionality. Fine with me. - todd
Re: snmp(1): Fix unsafe defaults
On Wed, 2021-08-11 at 18:59 +0100, Stuart Henderson wrote:
> On 2021/08/11 19:34, Martijn van Duren wrote:
> > On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> > > On 2021/08/11 16:35, Martijn van Duren wrote:
> > > > Following snmpd, remove the public default community and move to snmpv3
> > > > by default. This is also what net-snmp does. I originally chose this
> > > > default because that's what snmpctl did and it allowed for easier
> > > > interoperability with snmpd(8).
> > >
> > > v3 by default makes sense to me.
> > >
> > > I'm not sure how much it buys to remove the default community in snmp(1),
> > > though, there doesn't seem a lot of benefit to removing it?
> >
> > My reasoning being that setting having public the default in snmp(1)
> > might encourage users to set public in snmpd(8) as well, which is what
> > we tried to discourage.
>
> Hmm maybe. I won't object to that.
>
>
Forgot the manpage bits.
OK?
martijn@
Index: snmp.1
===
RCS file: /cvs/src/usr.bin/snmp/snmp.1,v
retrieving revision 1.19
diff -u -p -r1.19 snmp.1
--- snmp.1 8 Aug 2021 13:41:26 - 1.19
+++ snmp.1 11 Aug 2021 18:22:18 -
@@ -303,12 +303,11 @@ Show how long it took to walk the entire
Set the
.Ar community
string.
-Defaults to
-.Cm public .
This option is only used by
.Fl v Cm 1
and
-.Fl v Cm 2c .
+.Fl v Cm 2c
+and has no default.
.It Fl e Ar secengineid
The USM security engine id.
Under normal circumstances this value is discovered via snmpv3 discovery and
@@ -425,7 +424,7 @@ to either
or
.Cm 3 .
Currently defaults to
-.Cm 2c .
+.Cm 3 .
.It Fl X Ar privpass
The privacy password for the user.
This will be tansformed to
Index: snmpc.c
===
RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v
retrieving revision 1.35
diff -u -p -r1.35 snmpc.c
--- snmpc.c 8 Aug 2021 13:41:26 - 1.35
+++ snmpc.c 11 Aug 2021 18:22:18 -
@@ -84,12 +84,12 @@ struct snmp_app snmp_apps[] = {
};
struct snmp_app *snmp_app = NULL;
-char *community = "public";
+char *community = NULL;
struct snmp_v3 *v3;
char *mib = "mib_2";
int retries = 5;
int timeout = 1;
-enum snmp_version version = SNMP_V2C;
+enum snmp_version version = SNMP_V3;
int print_equals = 1;
int print_varbind_only = 0;
int print_summary = 0;
@@ -468,7 +468,10 @@ main(int argc, char *argv[])
argc -= optind;
argv += optind;
- if (version == SNMP_V3) {
+ if (version == SNMP_V1 || version == SNMP_V2C) {
+ if (community == NULL || community[0] == '\0')
+ errx(1, "No community name specified.");
+ } else if (version == SNMP_V3) {
/* Setup USM */
if (user == NULL || user[0] == '\0')
errx(1, "No securityName specified");
Re: snmp(1): Fix unsafe defaults
On Wed, 2021-08-11 at 18:59 +0100, Stuart Henderson wrote: > On 2021/08/11 19:34, Martijn van Duren wrote: > > On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote: > > > On 2021/08/11 16:35, Martijn van Duren wrote: > > > > Following snmpd, remove the public default community and move to snmpv3 > > > > by default. This is also what net-snmp does. I originally chose this > > > > default because that's what snmpctl did and it allowed for easier > > > > interoperability with snmpd(8). > > > > > > v3 by default makes sense to me. > > > > > > I'm not sure how much it buys to remove the default community in snmp(1), > > > though, there doesn't seem a lot of benefit to removing it? > > > > My reasoning being that setting having public the default in snmp(1) > > might encourage users to set public in snmpd(8) as well, which is what > > we tried to discourage. > > Hmm maybe. I won't object to that. > > > And it's easy enough to do something like > > alias snmp_get="snmp get -v2c -ccommunity" > > in .profile for interactive use > > and walk, bulkwalk, df, [...] > > FWIW I have this for now. > > - > #!/bin/ksh > if [[ -z $2 ]]; then > /usr/bin/snmp 2>&1 | sed "s/snmp/`basename $0`/" >&2 > exit 1 > fi > cmd=$1 > shift > exec /usr/bin/snmp $cmd -v 3 -l authPriv -u xxx [etc] $* > - > > > and in scripts you always want to be > > explicit with such parameters. > > Maybe. I do quite like keeping the secrets out of ps/top though. > > While I'm thinking about it, thoughts on this? No objection from me. OK martijn@ > > Index: snmpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v > retrieving revision 1.56 > diff -u -p -r1.56 snmpd.conf.5 > --- snmpd.conf.510 Aug 2021 07:53:57 - 1.56 > +++ snmpd.conf.511 Aug 2021 17:57:53 - > @@ -402,12 +402,13 @@ Example configuration file. > .Sh EXAMPLES > The following example will tell > .Xr snmpd 8 > -to listen on localhost for SNMPv2c messages only with the public community, > -override the default system OID, set the magic services value and provides > some > -custom OID values: > +to listen on localhost for SNMPv2c messages only with the community > +.Dq 8LHQtm1QLGzk , > +override the default system OID, set the magic services value, > +and provide some custom OID values: > .Bd -literal -offset indent > listen on 127.0.0.1 snmpv2c > -read-only community public > +read-only community 8LHQtm1QLGzk > > system oid 1.3.6.1.4.1.30155.23.2 > system services 74 >
Re: snmp(1): Fix unsafe defaults
On 2021/08/11 19:34, Martijn van Duren wrote: > On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote: > > On 2021/08/11 16:35, Martijn van Duren wrote: > > > Following snmpd, remove the public default community and move to snmpv3 > > > by default. This is also what net-snmp does. I originally chose this > > > default because that's what snmpctl did and it allowed for easier > > > interoperability with snmpd(8). > > > > v3 by default makes sense to me. > > > > I'm not sure how much it buys to remove the default community in snmp(1), > > though, there doesn't seem a lot of benefit to removing it? > > My reasoning being that setting having public the default in snmp(1) > might encourage users to set public in snmpd(8) as well, which is what > we tried to discourage. Hmm maybe. I won't object to that. > And it's easy enough to do something like > alias snmp_get="snmp get -v2c -ccommunity" > in .profile for interactive use and walk, bulkwalk, df, [...] FWIW I have this for now. - #!/bin/ksh if [[ -z $2 ]]; then /usr/bin/snmp 2>&1 | sed "s/snmp/`basename $0`/" >&2 exit 1 fi cmd=$1 shift exec /usr/bin/snmp $cmd -v 3 -l authPriv -u xxx [etc] $* - > and in scripts you always want to be > explicit with such parameters. Maybe. I do quite like keeping the secrets out of ps/top though. While I'm thinking about it, thoughts on this? Index: snmpd.conf.5 === RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v retrieving revision 1.56 diff -u -p -r1.56 snmpd.conf.5 --- snmpd.conf.510 Aug 2021 07:53:57 - 1.56 +++ snmpd.conf.511 Aug 2021 17:57:53 - @@ -402,12 +402,13 @@ Example configuration file. .Sh EXAMPLES The following example will tell .Xr snmpd 8 -to listen on localhost for SNMPv2c messages only with the public community, -override the default system OID, set the magic services value and provides some -custom OID values: +to listen on localhost for SNMPv2c messages only with the community +.Dq 8LHQtm1QLGzk , +override the default system OID, set the magic services value, +and provide some custom OID values: .Bd -literal -offset indent listen on 127.0.0.1 snmpv2c -read-only community public +read-only community 8LHQtm1QLGzk system oid 1.3.6.1.4.1.30155.23.2 system services 74
Re: libedit: stop playing hopeless games with FIONBIO
On Wed, 2021-08-11 at 18:50 +0200, Ingo Schwarze wrote:
> Hi,
>
> in its current state, the editline(3) library is completely unfit
> to work with non-blocking I/O. Neither the API nor the implementation
> are even designed for that purpose.
>
> I do have some candidate ideas to minimally extend the API - without
> adding any new functions - to also work with non-blocking I/O, but
> frankly, i don't see any sane use case for it yet. Why would anyone
> desire to mix non-blocking I/O and interactive line editing with the
> editline(3) library on the same file descriptor?
I can't think of anything. If you want to combine with something that
also uses other resources you should probably put something like kqueue
in front of it anyway.
That being said and a completely different issue: if this construct is
the case and someone enters a single byte of a UTF-8 character your
whole event-based system grinds to a halt until the rest of the
character is read.
>
> Consequently, i propose that we document the facts up front and
> simply delete some code that isn't going to do any good in practice.
> For programs not using non-blocking I/O on the editline input file
> descriptor, this patch makes no difference. Programs that do set
> FIONBIO on a file descriptor and then call editline(3) on it anyway
> can't possibly work as intended as far as i can see. Either setting
> FIONBIO is needless in the first place, or el_gets(3) clearing it
> will ruin the rest of the program's functionality.
>
> Do any of you have any doubts, and if so, which ones?
Sounds reasonable, but I'm not aware enough of the libedit consumers
to make a definitive statement.
Patch reads mostly OK to me.
>
> Or is anybody willing to OK this patch?
>
>
> If soembody comes up with a sane use case for mixing FIONBIO with
> editline(3) at a later point in time, we can still consider my plans
> to make that work. In that case, deleting the junk deleted by this
> patch would be required as the first step anyway.
>
>
> I'm appending a simple test program at the end.
>
> Before the patch:
>
> nbio is on
> ?test
> the user said: test
> nbio is off /* oops, what is this? */
>
> After the patch:
>
> nbio is on
> ?progname: el_gets: Resource temporarily unavailable
>
> I think the latter makes more sense and is less surprising.
>
> Yours,
> Ingo
>
>
> Index: editline.3
> ===
> RCS file: /cvs/src/lib/libedit/editline.3,v
> retrieving revision 1.46
> diff -u -p -r1.46 editline.3
> --- editline.3 22 May 2016 22:08:42 - 1.46
> +++ editline.3 11 Aug 2021 16:20:00 -
> @@ -169,6 +169,20 @@ Programs should be linked with
> .Pp
> The
> .Nm
> +library is designed to work with blocking I/O only.
> +If the
> +.Dv FIONBIO
> +.Xr ioctl 2
I'm not sure if FIONBIO should be mentioned here.
Else you would also have to mention O_NONBLOCK and O_NDELAY.
> +is set on
> +.Ar fin ,
> +.Fn el_gets
> +and
> +.Fn el_wgets
> +will almost certainly fail with
> +.Ar EAGAIN .
> +.Pp
> +The
> +.Nm
> library respects the
> .Ev LC_CTYPE
> locale set by the application program and never uses
> Index: read.c
> ===
> RCS file: /cvs/src/lib/libedit/read.c,v
> retrieving revision 1.47
> diff -u -p -r1.47 read.c
> --- read.c 11 Aug 2021 15:13:46 - 1.47
> +++ read.c 11 Aug 2021 16:20:00 -
> @@ -66,7 +66,6 @@ struct el_read_t {
> int read_errno;
> };
>
> -static int read__fixio(int, int);
> static int read_char(EditLine *, wchar_t *);
> static int read_getcmd(EditLine *, el_action_t *, wchar_t *);
> static voidread_clearmacros(struct macros *);
> @@ -132,26 +131,6 @@ el_read_getfn(struct el_read_t *el_read)
> }
>
>
> -/* read__fixio():
> - * Try to recover from a read error
> - */
> -static int
> -read__fixio(int fd, int e)
> -{
> - int zero = 0;
> -
> - switch (e) {
> - case EAGAIN:
> - if (ioctl(fd, FIONBIO, ) == -1)
> - return -1;
> - return 0;
> -
> - default:
> - return -1;
> - }
> -}
> -
> -
> /* el_push():
> * Push a macro
> */
> @@ -231,15 +210,12 @@ static int
> read_char(EditLine *el, wchar_t *cp)
> {
> ssize_t num_read;
> - int tried = 0;
> char cbuf[MB_LEN_MAX];
> int cbp = 0;
> - int save_errno = errno;
>
> again:
> el->el_signal->sig_no = 0;
> while ((num_read = read(el->el_infd, cbuf + cbp, 1)) == -1) {
> - int e = errno;
> if (errno == EINTR) {
> switch (el->el_signal->sig_no) {
> case SIGCONT:
> @@ -252,14 +228,8 @@ read_char(EditLine *el, wchar_t *cp)
> break;
> }
> }
> - if (!tried &&
Re: snmp(1): Fix unsafe defaults
On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> On 2021/08/11 16:35, Martijn van Duren wrote:
> > Following snmpd, remove the public default community and move to snmpv3
> > by default. This is also what net-snmp does. I originally chose this
> > default because that's what snmpctl did and it allowed for easier
> > interoperability with snmpd(8).
>
> v3 by default makes sense to me.
>
> I'm not sure how much it buys to remove the default community in snmp(1),
> though, there doesn't seem a lot of benefit to removing it?
My reasoning being that setting having public the default in snmp(1)
might encourage users to set public in snmpd(8) as well, which is what
we tried to discourage.
And it's easy enough to do something like
alias snmp_get="snmp get -v2c -ccommunity"
in .profile for interactive use and in scripts you always want to be
explicit with such parameters.
>
> (net-snmp tools do have that, but they also have /etc/snmp/snmp.conf or
> .snmp/snmp.conf so there's less to type on the command line).
>
> > Now that snmpd(8) moved on, so should snmp(1).
> >
> > OK?
> >
> > martijn@
> >
> > Index: snmpc.c
> > ===
> > RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v
> > retrieving revision 1.35
> > diff -u -p -r1.35 snmpc.c
> > --- snmpc.c 8 Aug 2021 13:41:26 - 1.35
> > +++ snmpc.c 11 Aug 2021 14:34:08 -
> > @@ -84,12 +84,12 @@ struct snmp_app snmp_apps[] = {
> > };
> > struct snmp_app *snmp_app = NULL;
> >
> > -char *community = "public";
> > +char *community = NULL;
> > struct snmp_v3 *v3;
> > char *mib = "mib_2";
> > int retries = 5;
> > int timeout = 1;
> > -enum snmp_version version = SNMP_V2C;
> > +enum snmp_version version = SNMP_V3;
> > int print_equals = 1;
> > int print_varbind_only = 0;
> > int print_summary = 0;
> > @@ -468,7 +468,10 @@ main(int argc, char *argv[])
> > argc -= optind;
> > argv += optind;
> >
> > - if (version == SNMP_V3) {
> > + if (version == SNMP_V1 || version == SNMP_V2C) {
> > + if (community == NULL || community[0] == '\0')
> > + errx(1, "No community name specified.");
> > + } else if (version == SNMP_V3) {
> > /* Setup USM */
> > if (user == NULL || user[0] == '\0')
> > errx(1, "No securityName specified");
> >
> >
Re: snmp(1): Fix unsafe defaults
On 2021/08/11 16:35, Martijn van Duren wrote:
> Following snmpd, remove the public default community and move to snmpv3
> by default. This is also what net-snmp does. I originally chose this
> default because that's what snmpctl did and it allowed for easier
> interoperability with snmpd(8).
v3 by default makes sense to me.
I'm not sure how much it buys to remove the default community in snmp(1),
though, there doesn't seem a lot of benefit to removing it?
(net-snmp tools do have that, but they also have /etc/snmp/snmp.conf or
.snmp/snmp.conf so there's less to type on the command line).
> Now that snmpd(8) moved on, so should snmp(1).
>
> OK?
>
> martijn@
>
> Index: snmpc.c
> ===
> RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 snmpc.c
> --- snmpc.c 8 Aug 2021 13:41:26 - 1.35
> +++ snmpc.c 11 Aug 2021 14:34:08 -
> @@ -84,12 +84,12 @@ struct snmp_app snmp_apps[] = {
> };
> struct snmp_app *snmp_app = NULL;
>
> -char *community = "public";
> +char *community = NULL;
> struct snmp_v3 *v3;
> char *mib = "mib_2";
> int retries = 5;
> int timeout = 1;
> -enum snmp_version version = SNMP_V2C;
> +enum snmp_version version = SNMP_V3;
> int print_equals = 1;
> int print_varbind_only = 0;
> int print_summary = 0;
> @@ -468,7 +468,10 @@ main(int argc, char *argv[])
> argc -= optind;
> argv += optind;
>
> - if (version == SNMP_V3) {
> + if (version == SNMP_V1 || version == SNMP_V2C) {
> + if (community == NULL || community[0] == '\0')
> + errx(1, "No community name specified.");
> + } else if (version == SNMP_V3) {
> /* Setup USM */
> if (user == NULL || user[0] == '\0')
> errx(1, "No securityName specified");
>
>
libedit: stop playing hopeless games with FIONBIO
Hi,
in its current state, the editline(3) library is completely unfit
to work with non-blocking I/O. Neither the API nor the implementation
are even designed for that purpose.
I do have some candidate ideas to minimally extend the API - without
adding any new functions - to also work with non-blocking I/O, but
frankly, i don't see any sane use case for it yet. Why would anyone
desire to mix non-blocking I/O and interactive line editing with the
editline(3) library on the same file descriptor?
Consequently, i propose that we document the facts up front and
simply delete some code that isn't going to do any good in practice.
For programs not using non-blocking I/O on the editline input file
descriptor, this patch makes no difference. Programs that do set
FIONBIO on a file descriptor and then call editline(3) on it anyway
can't possibly work as intended as far as i can see. Either setting
FIONBIO is needless in the first place, or el_gets(3) clearing it
will ruin the rest of the program's functionality.
Do any of you have any doubts, and if so, which ones?
Or is anybody willing to OK this patch?
If soembody comes up with a sane use case for mixing FIONBIO with
editline(3) at a later point in time, we can still consider my plans
to make that work. In that case, deleting the junk deleted by this
patch would be required as the first step anyway.
I'm appending a simple test program at the end.
Before the patch:
nbio is on
?test
the user said: test
nbio is off/* oops, what is this? */
After the patch:
nbio is on
?progname: el_gets: Resource temporarily unavailable
I think the latter makes more sense and is less surprising.
Yours,
Ingo
Index: editline.3
===
RCS file: /cvs/src/lib/libedit/editline.3,v
retrieving revision 1.46
diff -u -p -r1.46 editline.3
--- editline.3 22 May 2016 22:08:42 - 1.46
+++ editline.3 11 Aug 2021 16:20:00 -
@@ -169,6 +169,20 @@ Programs should be linked with
.Pp
The
.Nm
+library is designed to work with blocking I/O only.
+If the
+.Dv FIONBIO
+.Xr ioctl 2
+is set on
+.Ar fin ,
+.Fn el_gets
+and
+.Fn el_wgets
+will almost certainly fail with
+.Ar EAGAIN .
+.Pp
+The
+.Nm
library respects the
.Ev LC_CTYPE
locale set by the application program and never uses
Index: read.c
===
RCS file: /cvs/src/lib/libedit/read.c,v
retrieving revision 1.47
diff -u -p -r1.47 read.c
--- read.c 11 Aug 2021 15:13:46 - 1.47
+++ read.c 11 Aug 2021 16:20:00 -
@@ -66,7 +66,6 @@ struct el_read_t {
int read_errno;
};
-static int read__fixio(int, int);
static int read_char(EditLine *, wchar_t *);
static int read_getcmd(EditLine *, el_action_t *, wchar_t *);
static voidread_clearmacros(struct macros *);
@@ -132,26 +131,6 @@ el_read_getfn(struct el_read_t *el_read)
}
-/* read__fixio():
- * Try to recover from a read error
- */
-static int
-read__fixio(int fd, int e)
-{
- int zero = 0;
-
- switch (e) {
- case EAGAIN:
- if (ioctl(fd, FIONBIO, ) == -1)
- return -1;
- return 0;
-
- default:
- return -1;
- }
-}
-
-
/* el_push():
* Push a macro
*/
@@ -231,15 +210,12 @@ static int
read_char(EditLine *el, wchar_t *cp)
{
ssize_t num_read;
- int tried = 0;
char cbuf[MB_LEN_MAX];
int cbp = 0;
- int save_errno = errno;
again:
el->el_signal->sig_no = 0;
while ((num_read = read(el->el_infd, cbuf + cbp, 1)) == -1) {
- int e = errno;
if (errno == EINTR) {
switch (el->el_signal->sig_no) {
case SIGCONT:
@@ -252,14 +228,8 @@ read_char(EditLine *el, wchar_t *cp)
break;
}
}
- if (!tried && read__fixio(el->el_infd, e) == 0) {
- errno = save_errno;
- tried = 1;
- } else {
- errno = e;
- *cp = L'\0';
- return -1;
- }
+ *cp = L'\0';
+ return -1;
}
/* Test for EOF */
- 8< - schnipp - >8 - 8< - schnapp - >8 -
#include
#include
#include
#include
#include
int
main(void)
{
EditLine*el;
const char *line;
int len;
int flags = O_NONBLOCK;
if (fcntl(STDIN_FILENO, F_SETFL, ) == -1)
err(1, "fcntl(F_SETFL)");
flags = fcntl(STDIN_FILENO, F_GETFL);
printf("nbio is %s\n", flags & O_NONBLOCK ? "on" : "off");
if ((el = el_init("test", stdin, stdout, stderr)) == NULL)
err(1, "el_init");
if ((line = el_gets(el, )) ==
Diff for www:errata69
Hi, Here a diff for www page: errata69 Typo errors Right? Index: errata69.html === RCS file: /cvs/www/errata69.html,v retrieving revision 1.18 diff -u -r1.18 errata69.html --- errata69.html 10 Aug 2021 18:48:57 - 1.18 +++ errata69.html 11 Aug 2021 10:20:30 - @@ -200,7 +200,7 @@ 010: SECURITY FIX: July 25, 2021 All architectures -relayd(8), when using the the http protocol strip filter directive or http +relayd(8), when using the http protocol strip filter directive or http protocol macro expansion, processes format strings. https://ftp.openbsd.org/pub/OpenBSD/patches/6.9/common/010_relayd.patch.sig;>
snmp(1): Fix mibree usage
Probably not something many people will run into. $ snmp mibtree -q snmp: unknown option -- q usage: snmp mibtree[-O fnS] [oid ...] $ ./obj/snmp mibtree -q snmp: unknown option -- q usage: snmp mibtree [-O fnS] [oid ...] mibtree is the only one not setting the usecommonopt. OK? martijn@ Index: snmpc.c === RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v retrieving revision 1.35 diff -u -p -r1.35 snmpc.c --- snmpc.c 8 Aug 2021 13:41:26 - 1.35 +++ snmpc.c 11 Aug 2021 14:47:51 - @@ -1572,7 +1572,7 @@ usage(void) "[-E ctxengineid] [-K localpriv] [-k localauth] [-l seclevel]\n" "[-n ctxname] [-O afnqvxSQ] [-r retries] [-t timeout] [-u user]\n" "[-v version] [-X privpass] [-x cipher] [-Z boots,time]\n" - "" : "", + "" : " ", snmp_app->usage == NULL ? "" : snmp_app->usage); exit(1); }
snmp(1): Fix unsafe defaults
Following snmpd, remove the public default community and move to snmpv3
by default. This is also what net-snmp does. I originally chose this
default because that's what snmpctl did and it allowed for easier
interoperability with snmpd(8).
Now that snmpd(8) moved on, so should snmp(1).
OK?
martijn@
Index: snmpc.c
===
RCS file: /cvs/src/usr.bin/snmp/snmpc.c,v
retrieving revision 1.35
diff -u -p -r1.35 snmpc.c
--- snmpc.c 8 Aug 2021 13:41:26 - 1.35
+++ snmpc.c 11 Aug 2021 14:34:08 -
@@ -84,12 +84,12 @@ struct snmp_app snmp_apps[] = {
};
struct snmp_app *snmp_app = NULL;
-char *community = "public";
+char *community = NULL;
struct snmp_v3 *v3;
char *mib = "mib_2";
int retries = 5;
int timeout = 1;
-enum snmp_version version = SNMP_V2C;
+enum snmp_version version = SNMP_V3;
int print_equals = 1;
int print_varbind_only = 0;
int print_summary = 0;
@@ -468,7 +468,10 @@ main(int argc, char *argv[])
argc -= optind;
argv += optind;
- if (version == SNMP_V3) {
+ if (version == SNMP_V1 || version == SNMP_V2C) {
+ if (community == NULL || community[0] == '\0')
+ errx(1, "No community name specified.");
+ } else if (version == SNMP_V3) {
/* Setup USM */
if (user == NULL || user[0] == '\0')
errx(1, "No securityName specified");
Re: date -j and seconds since the Epoch
Hi, > ok gerhard@ Thanks for reporting, for the initial patch, and for checking the final one. This now committed. Yours, Ingo >> Index: date.c >> === >> RCS file: /cvs/src/bin/date/date.c,v >> retrieving revision 1.56 >> diff -u -p -r1.56 date.c >> --- date.c 8 Aug 2019 02:17:51 - 1.56 >> +++ date.c 6 Aug 2021 17:48:01 - >> @@ -219,7 +219,11 @@ setthetime(char *p, const char *pformat) >> } >> >> /* convert broken-down time to UTC clock time */ >> -if ((tval = mktime(lt)) == -1) >> +if (pformat != NULL && strstr(pformat, "%s") != NULL) >> +tval = timegm(lt); >> +else >> +tval = mktime(lt); >> +if (tval == -1) >> errx(1, "specified date is outside allowed range"); >> >> if (jflag)
Sync list of supported device in INSTALL.octeon with octeon.html
Hi, It seems to me that src/distrib/notes/octeon/hardware is out-of-sync with www/octeon.html and some models are missing. The following patch attempts to update src/distrib/notes/octeon/hardware so it contains the same device list as octeon.html. There is one thing I'm unsure about, in octeon/hardware: D-Link DSR-500 The onboard CompactFlash is not yet supported. ... but this line doesn't exist in octeon.html, is it still unsupported? I don't have such device so can't test here. Index: notes/octeon/hardware === RCS file: /cvs/src/distrib/notes/octeon/hardware,v retrieving revision 1.8 diff -u -r1.8 hardware --- notes/octeon/hardware 2 Aug 2015 09:54:29 - 1.8 +++ notes/octeon/hardware 11 Aug 2021 02:29:19 - @@ -2,14 +2,42 @@ The following machines are targeted by OpenBSD/MACHINE: Portwell CAM-0100 - onboard serial port, CompactFlash and Ethernet are supported; + Onboard serial port, CompactFlash and Ethernet are supported; it's possible to install OpenBSD/MACHINE on this machine with some effort. - Ubiquiti Networks EdgeRouter Lite / PoE - onboard serial port, Ethernet and USB controller are supported. - D-Link DSR-500 - onboard serial port, Ethernet and USB controller are supported; - it's possible to boot OpenBSD/MACHINE on this machine over NFS. + D-Link DSR-500N + Onboard serial port, Ethernet and USB controller are supported; + it's possible to boot OpenBSD/MACHINE on those machines over NFS. The onboard CompactFlash is not yet supported. + + Netgear ProSecure UTM25 + Ports LAN1-4 and WAN1 are connected to the same internal switch, + but U-Boot puts these LAN and WAN segments in two separate + port-based VLANs. Port WAN2 does not work yet. + + Rhino Labs Inc. SDNA Shasta + Rhino Labs Inc. SDNA-7130 + + Ubiquiti Networks EdgeRouter LITE + Ubiquiti Networks EdgeRouter PoE + Onboard serial port, Ethernet and USB controller are supported. + Switch ports are not supported yet. + + Ubiquiti Networks EdgeRouter Infinity + 10G SFP+ ports are not supported yet. + + Ubiquiti Networks EdgeRouter 4 + Ubiquiti Networks EdgeRouter 6P + Ubiquiti Networks EdgeRouter 12 + Switch ports are not supported yet. + + Ubiquiti Networks EdgeRouter + Ubiquiti Networks EdgeRouter PRO + Ubiquiti Networks UniFi Security Gateway + Ubiquiti Networks UniFi Security Gateway PRO-4 + SFP slots are not supported yet. + + Ubiquiti Networks EdgeRouter Infinity + 10G SFP+ ports are not supported yet.
Re: [patch] Preserve keymap adjustments on suspend/resume
On 10 Aug 2021, at 11:26, ropers wrote: > Would this also preserve the LED status (Num, Scroll Lock, etc.)? Nope, only encoding, custom keymap (if any), bell and repeat. LEDs have escaped my attention because they are handled by lower level drivers (pckbd, ukbd, etc), not wskbd. Preserving LEDs would also require preserving caps/num/scroll lock statuses. I am reluctant to add this extra complexity with no clear use cases. > On 09/08/2021, Sergii Rudchenko wrote: > > I was in doubt about locking, but tracing the path of ioctl handling > > I have not found anything preventing two CPU cores from executing > > wskbd ioctls in parallel on amd64 (and it is a NOLOCK syscall). In > > fact, now I wonder why wskbd_softc is not protected. I have found that wskbd_softc does not need a lock because if there is an open file descriptor to wskbd other calls to open(2) fail with EBUSY. The lock is still needed for the new wskbd_config because it can accessed by iocts on different wskbd units. On 10 Aug 2021, at 11:26, ropers wrote: > (I'm nobody important and probably can't help, but I'm curious.) That makes two of us). Thank you for replying! Best regards, Sergii Rudchenko
