Re: [PATCH] add ping(1)-like stats to tcpbench(1)
Hi, On 02/05/2020 12:41, richard.n.proc...@gmail.com wrote: >> More assumptions are implied here. How do I measure a 2400 bps link >> with this >> report? The precision is lost in "%.3Lf". > I highly doubt anyone needs to benchmark a 2400 bps link. The display is > in any case precise to 1000 bps. I am commonly working with 1200bps and 9600bps links in HamBSD with the kiss(4) network interface, is there any reason to *not* be flexible on the output here? Thanks, Iain. -- https://hambsd.org/
Re: pipex(4) man page fix
Hi, On 02/04/2020 12:47, Vitaliy Makkoveev wrote: > +.Xr pppax 4 , I guess you meant pppac here. Thanks, Iain.
Re: ifTypes, if_data->if_type, conflicts and too small
Hi, On 18/10/2019 17:19, Theo de Raadt wrote: >> 3. Track down all the places that this might be used, and make sure they >> are also changed to handle a u_int32_t. > > Gigantic ABI breakage. > > Hope you have fun upgrading bsd, ifconfig, and other tools through that > change. Yeah, I didn't say this would be fun. >> The only place that I can think of that really might break is SNMP >> clients, > > If you change the offset of all the fields in if_data, and all the macros > that access inside it, you'll break a lot more than the snmp tools. I'm assuming that within OpenBSD base and ports everything can be fixed. I mean SNMP clients like monitoring appliances, because these numbers (maybe, I didn't check) appear on the wire. > Some problems created by IANA cannot be solved. In the coming decade I > expect they'll come to realize they've allocated all the numbers in the > protocols and services files, and start allocating out-of-range numbers > there also. They get into this situation reasons: they hand out numbers > for things which don't actually need unique numbers, then don't delete > ancient irrelevant things. > > Should fix? Very debatable. I can also just say everything is fine and make up another "private" assignment. If people don't feel the work is worth doing, then I won't do it. We have 31 numbers we didn't assign to something yet in if_types.h, which is probably enough for some years yet. Thanks, Iain.
ifTypes, if_data->if_type, conflicts and too small
Hi, For context: I'm currently working on a patch set for OpenBSD that adds support for AX.25 network interfaces. Constants for interface types are defined in based on the IANA registry for ifTypes maintained as: https://www.iana.org/assignments/ianaiftype-mib As the bottom of this file, we see a comment: /* private usage... how should we define these? */ Oh dear. There is no private use range defined in this registry, and as far as I can tell once we'd made up our own assignments here no questions were asked when we made up more. There are a total of 11 "private" interface types defined, all of which clash with types defined in the IANA registry we claim to base these defines on. Before I'd looked too far into this, I read about the IANA registry and went and registered an interface type for AX.25, which is now allocated as 298. The process for this was entirely painless and they responded within days. This presents another problem because the if_type member of the if_data struct is defined as a u_char and so the type I've been assigned isn't even going to fit. Before I go any further here, I wanted to ask whether this has come up before, whether anyone is looking at it, any ideas, etc? If no one has yet looked at this and no one cares how it is fixed, I would do the following: 1. Register each of the types we have as "private" allocations with IANA. 2. Increase the if_type member to be a u_int32_t. 3. Track down all the places that this might be used, and make sure they are also changed to handle a u_int32_t. 4. See how badly things break during an upgrade, and if some compatibility things need to be done (e.g. have two sets of ioctls for a release period). 5. Sync if_types.h with the IANA registry again, which will mean that the private use types change their numerical value. The only place that I can think of that really might break is SNMP clients, because I think that the ifType may appear in the SNMP tree. This is unfortunate, but there are probably more clients that are currently interpreting CARP interfaces as "Internal LAN on a bridge per IEEE 802.1ap" and MBIM as "Gigabit-capable passive optical networks (G-PON) as per ITU-T G.948". If we want to have standards compliance, we *should* fix this. Any comments and thoughts are welcome. Thanks, Iain.
pstat(8): display text for msts/endrun line disciplines
ping.
pstat(8) will display text description for the nmea line
discipline, but not for msts/endrun. This patch adds support
for displaying text for msts and endrun line disciplines in
the output of pstat -t.
comments? ok?
diff --git usr.sbin/pstat/pstat.8 usr.sbin/pstat/pstat.8
index d523b0014..d2631f834 100644
--- usr.sbin/pstat/pstat.8
+++ usr.sbin/pstat/pstat.8
@@ -212,11 +212,17 @@ TTYDISC (see
.Xr termios 4 ) ,
.Ql ppp
for PPPDISC (see
-.Xr ppp 4 )
-and
+.Xr ppp 4 ) ,
.Ql nmea
for NMEADISC (see
-.Xr nmea 4 ) .
+.Xr nmea 4 ) ,
+.Ql msts
+for MSTSDISC (see
+.Xr msts 4 ) ,
+and
+.Ql endrun
+for ENDRUNDISC (see
+.Xr endrun 4 ) .
.El
.It Fl v
Print the active vnodes.
diff --git usr.sbin/pstat/pstat.c usr.sbin/pstat/pstat.c
index 1684975c5..986dee90b 100644
--- usr.sbin/pstat/pstat.c
+++ usr.sbin/pstat/pstat.c
@@ -999,6 +999,12 @@ ttyprt(struct itty *tp)
case NMEADISC:
(void)printf("nmea\n");
break;
+ case MSTSDISC:
+ (void)printf("msts\n");
+ break;
+ case ENDRUNDISC:
+ (void)printf("endrun\n");
+ break;
default:
(void)printf("%d\n", tp->t_line);
break;
Re: [patch] pstat(8): display text for msts/endrun line disciplines
Hi, On 06/09/2019 14:24, Iain R. Learmonth wrote with a patch. I'd really like to see this included in 6.6. Thanks, Iain.
[patch] pstat(8): display text for msts/endrun line disciplines
pstat(8) will display text description for the nmea line
discipline, but not for msts/endrun. This patch adds support
for displaying text for msts and endrun line disciplines in
the output of pstat -t.
diff --git usr.sbin/pstat/pstat.8 usr.sbin/pstat/pstat.8
index d523b0014..d2631f834 100644
--- usr.sbin/pstat/pstat.8
+++ usr.sbin/pstat/pstat.8
@@ -212,11 +212,17 @@ TTYDISC (see
.Xr termios 4 ) ,
.Ql ppp
for PPPDISC (see
-.Xr ppp 4 )
-and
+.Xr ppp 4 ) ,
.Ql nmea
for NMEADISC (see
-.Xr nmea 4 ) .
+.Xr nmea 4 ) ,
+.Ql msts
+for MSTSDISC (see
+.Xr msts 4 ) ,
+and
+.Ql endrun
+for ENDRUNDISC (see
+.Xr endrun 4 ) .
.El
.It Fl v
Print the active vnodes.
diff --git usr.sbin/pstat/pstat.c usr.sbin/pstat/pstat.c
index 1684975c5..986dee90b 100644
--- usr.sbin/pstat/pstat.c
+++ usr.sbin/pstat/pstat.c
@@ -999,6 +999,12 @@ ttyprt(struct itty *tp)
case NMEADISC:
(void)printf("nmea\n");
break;
+ case MSTSDISC:
+ (void)printf("msts\n");
+ break;
+ case ENDRUNDISC:
+ (void)printf("endrun\n");
+ break;
default:
(void)printf("%d\n", tp->t_line);
break;
[patch] pstat: print names for msts and endrun line discs
Hi,
I've been working on a line discipline for something else and I noticed
that the msts and endrun line disciplines are not displayed in pstat.
Here attached is a simple patch that fixes the issue.
This is also a practice run for me at submitting patches, so please let
me know if I'm doing things wrong.
Thanks,
Iain.
diff --git usr.sbin/pstat/pstat.8 usr.sbin/pstat/pstat.8
index d523b0014..d2631f834 100644
--- usr.sbin/pstat/pstat.8
+++ usr.sbin/pstat/pstat.8
@@ -212,11 +212,17 @@ TTYDISC (see
.Xr termios 4 ) ,
.Ql ppp
for PPPDISC (see
-.Xr ppp 4 )
-and
+.Xr ppp 4 ) ,
.Ql nmea
for NMEADISC (see
-.Xr nmea 4 ) .
+.Xr nmea 4 ) ,
+.Ql msts
+for MSTSDISC (see
+.Xr msts 4 ) ,
+and
+.Ql endrun
+for ENDRUNDISC (see
+.Xr endrun 4 ) .
.El
.It Fl v
Print the active vnodes.
diff --git usr.sbin/pstat/pstat.c usr.sbin/pstat/pstat.c
index 1684975c5..986dee90b 100644
--- usr.sbin/pstat/pstat.c
+++ usr.sbin/pstat/pstat.c
@@ -999,6 +999,12 @@ ttyprt(struct itty *tp)
case NMEADISC:
(void)printf("nmea\n");
break;
+ case MSTSDISC:
+ (void)printf("msts\n");
+ break;
+ case ENDRUNDISC:
+ (void)printf("endrun\n");
+ break;
default:
(void)printf("%d\n", tp->t_line);
break;
