Re: diff: ipsec.conf(5), clarify "aes" accepts 128:256 bits
Hi, On Tue, 2 Nov 2021 07:03:43 + Jason McIntyre wrote: > On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote: >> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits. >> >> sbin/ipsecctl/ike.c: >> 201 case ENCXF_AES: >> 202 enc_alg = "AES"; >> 203 key_length = "128,128:256"; >> 204 break; >> >> >> ok? >> >> Clarify "aes" will accept keys which length is in 128:256 bits. >> > > i notice that the enc lists in ipsec.conf.5 and iked.conf.5 differ. > aren;t they supposed to be in sync? > > for example, iked.conf.5 doesn;t mention "aes" or "aesctr". also the > *-gmac and *-gcm-12 discrepancy. As for "aes", *only isakmpd(8)* supports "aes" keyword or having a range for the key length. So there isn't need to sync it to iked.conf.5. Also I belive "aesctr" is to support 160:288 range for key length, but the implemention doesn't seem to be completed. I have another plan to handle this separately, then I'll update the man page. Other than the key length range, it seems there are some differences between iked.conf.5 and ipsec.conf.5. 1. "-gcm-12" missing this in ipsec.conf.5 is ok since isakmpd(8) doesn't support it yet. (It is actually an alias ID for "-gcm" though.) 2. "-gmac" and "null" iked.conf.5 has a separeted list for them to clarify they don't do encryption. Applied the same to isakmpd.conf.5. 3. "chacha20-poly1305" It is missing in ipsec.conf.5. 4. explanation of "[IKE only]" or "[phase 2]" It is missing in ipsec.conf.5. Copied the section from iked.conf and modified it. 5. explanation of "keysize" for AES-CTR and so on The explanation in ipsec.conf.5 is better. Copied that to iked.conf.5. 6. "cast" ipsecctl(8) program doesn't support "cast" keyword actually, it supports "cast128" instead. Correct "cast" to "cast128" ok? Index: sbin/iked/iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.87 diff -u -p -r1.87 iked.conf.5 --- sbin/iked/iked.conf.5 26 Oct 2021 17:31:22 - 1.87 +++ sbin/iked/iked.conf.5 3 Nov 2021 05:42:48 - @@ -998,9 +998,9 @@ keyword. 3DES requires 24 bytes to form its 168-bit key. This is because the most significant bit of each byte is used for parity. .Pp -The keysize of AES-CTR is actually 128-bit. +The keysize of AES-CTR can be 128, 192, or 256 bits. However as well as the key, a 32-bit nonce has to be supplied. -Thus 160 bits of key material have to be supplied. +Thus 160, 224, or 288 bits of key material, respectively, have to be supplied. The same applies to AES-GCM, AES-GMAC and Chacha20-Poly1305, however in the latter case the keysize is 256 bit. .Pp Index: sbin/ipsecctl/ipsec.conf.5 === RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v retrieving revision 1.160 diff -u -p -r1.160 ipsec.conf.5 --- sbin/ipsecctl/ipsec.conf.5 22 Oct 2021 12:30:54 - 1.160 +++ sbin/ipsecctl/ipsec.conf.5 3 Nov 2021 05:42:49 - @@ -637,10 +637,10 @@ keyword: The following cipher types are permitted with the .Ic enc keyword: -.Bl -column "aes-128-gmac" "Key Length" "Description" -offset indent +.Bl -column "chacha20-poly1305" "128-256 bits" "Description" -offset indent .It Em "Cipher" Ta Em "Key Length" Ta "" .It Li 3des Ta "168 bits" Ta "" -.It Li aes Ta "128 bits" Ta "" +.It Li aes Ta "128-256 bits" Ta "" .It Li aes-128 Ta "128 bits" Ta "" .It Li aes-192 Ta "192 bits" Ta "" .It Li aes-256 Ta "256 bits" Ta "" @@ -651,21 +651,37 @@ keyword: .It Li aes-128-gcm Ta "160 bits" Ta "[phase 2 only, IKE only]" .It Li aes-192-gcm Ta "224 bits" Ta "[phase 2 only, IKE only]" .It Li aes-256-gcm Ta "288 bits" Ta "[phase 2 only, IKE only]" +.It Li blowfish Ta "160 bits" Ta "" +.It Li cast128 Ta "128 bits" Ta "" +.It Li chacha20-poly1305 Ta "288 bits" Ta "" +.El +.Pp +The following cipher types provide only authentication, not encryption: +.Bl -column "chacha20-poly1305" "128-256 bits" "Description" -offset indent .It Li aes-128-gmac Ta "160 bits" Ta "[phase 2 only, IKE only]" .It Li aes-192-gmac Ta "224 bits" Ta "[phase 2 only, IKE only]" .It Li aes-256-gmac Ta "288 bits" Ta "[phase 2 only, IKE only]" -.It Li blowfish Ta "160 bits" Ta "" -.It Li cast Ta "128 bits" Ta "" .It Li null Ta "(none)" Ta "[phase 2 only]" .El .Pp +Transforms followed by +.Bq IKE only +can only be used with the +.Ic ike +keyword, transforms with +.Bq phase 2 only +can only be used with the +.Ic quick +keyword. +.Pp 3DES requires 24 bytes to form its 168-bit key. This is because the most significant bit of each byte is used for parity. .Pp The keysize of AES-CTR can be 128, 192, or 256 bits. However as well as the key, a 32-bit nonce has to be supplied. Thus 160, 224, or 288 bits of key material,
Re: New hw.perfpolicy behavior
On Tue, 2 Nov 2021, Theo de Raadt wrote: > Paul de Weerd wrote: > > > A recent commit by Theo changed the hw.perfpolicy behavior to always > > run at full speed when AC power is on. This means that my workstation > > (and servers, once I upgrade them) now consumes significantly more > > power, even though they usually idle. > > Did you measure how much more power? > > You must measure, to make such a claim. > > Your OptiPlex 9020 is probably a modern i5/i7, which probably contains > C states similar to this: > > acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > > Which means when the idle loop calls the "mwait" instruction, the cpu > will 'instantly' slow down to a lower clock and make other power use > reductions, until an interrupt happens and requires labour again. See also https://en.wikichip.org/wiki/race-to-sleep - it's generally more energy efficient to run the CPU at full speed so it can finish its work faster and get back to a low-power state sooner
Re: ifconfig: zap dead code
I am sure swabips died before you were born.
Klemens Nanni wrote:
> No idea what it was supposed to do back then; cvs blame points at
>
> revision 1.19
> date: 1998/09/03 06:24:18; author: jason; state: Exp; lines: +502
> -38;
> o OpenBSD gets if_media support (from NetBSD)
> o rework/simplify if_xl to use
>
> OK?
>
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.447
> diff -u -p -r1.447 ifconfig.c
> --- ifconfig.c2 Nov 2021 23:39:27 - 1.447
> +++ ifconfig.c2 Nov 2021 23:46:28 -
> @@ -411,11 +411,6 @@ const struct cmd {
> { "alias", IFF_UP, 0, notealias },
> { "-alias", -IFF_UP,0, notealias },
> { "delete", -IFF_UP,0, notealias },
> -#ifdef notdef
> -#define EN_SWABIPS 0x1000
> - { "swabips",EN_SWABIPS, 0, setifflags },
> - { "-swabips", -EN_SWABIPS,0, setifflags },
> -#endif /* notdef */
> { "netmask",NEXTARG,0, setifnetmask },
> { "mtu",NEXTARG,0, setifmtu },
> { "nwid", NEXTARG,0, setifnwid },
>
ifconfig: zap dead code
No idea what it was supposed to do back then; cvs blame points at
revision 1.19
date: 1998/09/03 06:24:18; author: jason; state: Exp; lines: +502
-38;
o OpenBSD gets if_media support (from NetBSD)
o rework/simplify if_xl to use
OK?
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.447
diff -u -p -r1.447 ifconfig.c
--- ifconfig.c 2 Nov 2021 23:39:27 - 1.447
+++ ifconfig.c 2 Nov 2021 23:46:28 -
@@ -411,11 +411,6 @@ const struct cmd {
{ "alias", IFF_UP, 0, notealias },
{ "-alias", -IFF_UP,0, notealias },
{ "delete", -IFF_UP,0, notealias },
-#ifdef notdef
-#defineEN_SWABIPS 0x1000
- { "swabips",EN_SWABIPS, 0, setifflags },
- { "-swabips", -EN_SWABIPS,0, setifflags },
-#endif /* notdef */
{ "netmask",NEXTARG,0, setifnetmask },
{ "mtu",NEXTARG,0, setifmtu },
{ "nwid", NEXTARG,0, setifnwid },
Re: config.8: add EXIT STATUS
On Tue, 02 Nov 2021 22:22:16 -, Klemens Nanni wrote: > I looked at > I had to look at the source to be sure what the three different return > codes 0, 1 and 2 would mean and if there was more to it. > > Depending on the error, config(8) exists 1 or 2. 0 on success as usual. OK millert@ - todd
config.8: add EXIT STATUS
I looked at I had to look at the source to be sure what the three different return codes 0, 1 and 2 would mean and if there was more to it. Depending on the error, config(8) exists 1 or 2. 0 on success as usual. OK? Index: config.8 === RCS file: /cvs/src/usr.sbin/config/config.8,v retrieving revision 1.73 diff -u -p -r1.73 config.8 --- config.813 Sep 2021 17:43:26 - 1.73 +++ config.82 Nov 2021 22:17:14 - @@ -322,6 +322,8 @@ Show all devices for which attribute has the value .Ar val . .El +.Sh EXIT STATUS +.Ex -std .Sh EXAMPLES The Ethernet card is not detected at boot because the kernel configuration does not match the physical hardware configuration,
Re: ifconfig: return non-zero on failed "nwkey"
On Tue, Nov 02, 2021 at 06:38:24PM +0100, Stefan Sperling wrote: > It looks like bwfm(4) does support WEP but the C_WEP capability is missing > from ic_caps so net80211 believes WEP was not supported by this driver. > > I don't think we have any supported wifi device that does not support WEP. > Even an(4) supports WEP! I considered this a feature not a bug!
Re: New hw.perfpolicy behavior
Solene Rapenne wrote:
> On mardi 2 novembre 2021 19:19:03 CET, Paul de Weerd wrote:
> > A recent commit by Theo changed the hw.perfpolicy behavior to always
> > run at full speed when AC power is on. This means that my workstation
> > (and servers, once I upgrade them) now consumes significantly more
> > power, even though they usually idle.
> >
> > [weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,setperf,cpuspeed}
> > hw.vendor=Dell Inc.
> > hw.product=OptiPlex 9020
> > hw.perfpolicy=auto
> > hw.setperf=100
> > hw.cpuspeed=3401
> >
> > If I'd want to use the old behavior on "non laptop" systems, what
> > would be the best approach to try to achieve that? I mean, I can
> > revert the commit, but then I'm stuck with a frankenstein system.
> >
> > Would another "economy" perfpolicy be better, or would it make more
> > sense to try to divine the type of system and adjust accordingly?
> >
> > Paul
> >
>
> Hello,
>
> I noticed a 1 watt or so increase on idle on a T470
> which is perfectly acceptable for me given the
> responsiveness boost that comes with this change.
>
How dare you
Re: New hw.perfpolicy behavior
> Date: Tue, 2 Nov 2021 19:19:03 +0100
> From: Paul de Weerd
>
> A recent commit by Theo changed the hw.perfpolicy behavior to always
> run at full speed when AC power is on. This means that my workstation
> (and servers, once I upgrade them) now consumes significantly more
> power, even though they usually idle.
>
> [weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,setperf,cpuspeed}
> hw.vendor=Dell Inc.
> hw.product=OptiPlex 9020
> hw.perfpolicy=auto
> hw.setperf=100
> hw.cpuspeed=3401
>
> If I'd want to use the old behavior on "non laptop" systems, what
> would be the best approach to try to achieve that? I mean, I can
> revert the commit, but then I'm stuck with a frankenstein system.
>
> Would another "economy" perfpolicy be better, or would it make more
> sense to try to divine the type of system and adjust accordingly?
Did you measure the power consumption?
Re: New hw.perfpolicy behavior
Paul de Weerd wrote:
> A recent commit by Theo changed the hw.perfpolicy behavior to always
> run at full speed when AC power is on. This means that my workstation
> (and servers, once I upgrade them) now consumes significantly more
> power, even though they usually idle.
Did you measure how much more power?
You must measure, to make such a claim.
Your OptiPlex 9020 is probably a modern i5/i7, which probably contains
C states similar to this:
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
Which means when the idle loop calls the "mwait" instruction, the cpu
will 'instantly' slow down to a lower clock and make other power use
reductions, until an interrupt happens and requires labour again.
Most modern cpus dynamically downscale in such way, which mostly
obliterates the requirement to manually control things, or even handle
it in a slow-paced data-weak way in the scheduler.
So you must back your claim up with power measurements.
> [weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,setperf,cpuspeed}
> hw.vendor=Dell Inc.
> hw.product=OptiPlex 9020
> hw.perfpolicy=auto
> hw.setperf=100
> hw.cpuspeed=3401
>
> If I'd want to use the old behavior on "non laptop" systems, what
> would be the best approach to try to achieve that? I mean, I can
> revert the commit, but then I'm stuck with a frankenstein system.
>
> Would another "economy" perfpolicy be better, or would it make more
> sense to try to divine the type of system and adjust accordingly?
>From false premises straight to conclusions that we (OpenBSD) must do
something. Come on.
I purchased every one of my machines to get the maximum performance out
of them when they are doing work, and I expect everyone else is in the
same group. Otherwise they would have saved money by buying slower
machines. Lucky for us that modern cpus do this automatically.
Re: New hw.perfpolicy behavior
Paul de Weerd wrote:
> A recent commit by Theo changed the hw.perfpolicy behavior to always
> run at full speed when AC power is on. This means that my workstation
> (and servers, once I upgrade them) now consumes significantly more
> power, even though they usually idle.
Did you measure how much more power?
You must measure, to make the claim.
The OptiPlex 9020 is a modern i7, approximately 4785T generation, and
these contain C states:
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
Which means when the idle loop calls the "mwait" instruction, the cpu
will 'instantly' slow down, until an interrupt happens. And thus, save
power. That is how modern cpus work.
You must back your claim up with power measurements.
> [weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,setperf,cpuspeed}
> hw.vendor=Dell Inc.
> hw.product=OptiPlex 9020
> hw.perfpolicy=auto
> hw.setperf=100
> hw.cpuspeed=3401
>
> If I'd want to use the old behavior on "non laptop" systems, what
> would be the best approach to try to achieve that? I mean, I can
> revert the commit, but then I'm stuck with a frankenstein system.
>
> Would another "economy" perfpolicy be better, or would it make more
> sense to try to divine the type of system and adjust accordingly?
>From false premises straight to conclusions that we (OpenBSD) must do
something.
New hw.perfpolicy behavior
A recent commit by Theo changed the hw.perfpolicy behavior to always
run at full speed when AC power is on. This means that my workstation
(and servers, once I upgrade them) now consumes significantly more
power, even though they usually idle.
[weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,setperf,cpuspeed}
hw.vendor=Dell Inc.
hw.product=OptiPlex 9020
hw.perfpolicy=auto
hw.setperf=100
hw.cpuspeed=3401
If I'd want to use the old behavior on "non laptop" systems, what
would be the best approach to try to achieve that? I mean, I can
revert the commit, but then I'm stuck with a frankenstein system.
Would another "economy" perfpolicy be better, or would it make more
sense to try to divine the type of system and adjust accordingly?
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: ifconfig: return non-zero on failed "nwkey"
On Tue, Nov 02, 2021 at 11:30:11AM -0600, Theo de Raadt wrote:
> Klemens Nanni wrote:
>
> > At least bwfm(4) does not support WEP:
> >
> > # ifconfig bwfm0 nwkey 12345
> > ifconfig: SIOCS80211NWKEY: Operation not supported by device
> > # echo $?
> > 0
> >
> > ifconfig(8) must return non-zero in this case.
> >
> > This is relevant for an upcoming installer fix, but also worth itself.
> >
> > OK?
> >
> > Index: ifconfig.c
> > ===
> > RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> > retrieving revision 1.445
> > diff -u -p -r1.445 ifconfig.c
> > --- ifconfig.c 6 Oct 2021 06:14:08 - 1.445
> > +++ ifconfig.c 2 Nov 2021 17:20:01 -
> > @@ -2033,7 +2033,7 @@ setifnwkey(const char *val, int d)
> > }
> >
> > if (ioctl(sock, SIOCS80211NWKEY, (caddr_t)) == -1)
> > - warn("SIOCS80211NWKEY");
> > + err("SIOCS80211NWKEY");
> > }
>
>
> If you do this, then a multi-parameter ifconfig will fail, without
> trying other operations.
I'm happy to fail early instead of humping along best-effort.
Which multiple parameters would you do in one ifconfig invocation?
Maybe WEP, then autoconf/address setup? I'd assume they somewhat depend
on each other or are logically grouped (in hostname.if).
> That might be desireable. Or it might not be.
Better fail hard and early. If a long `ifconfig ...' command "worked"
now while it didn't, I'm happy to show users now that it never worked.
Re: ifconfig: return non-zero on failed "nwkey"
On Tue, Nov 02, 2021 at 05:26:17PM +, Klemens Nanni wrote:
> At least bwfm(4) does not support WEP:
>
> # ifconfig bwfm0 nwkey 12345
> ifconfig: SIOCS80211NWKEY: Operation not supported by device
> # echo $?
> 0
>
> ifconfig(8) must return non-zero in this case.
>
> This is relevant for an upcoming installer fix, but also worth itself.
>
> OK?
>
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.445
> diff -u -p -r1.445 ifconfig.c
> --- ifconfig.c6 Oct 2021 06:14:08 - 1.445
> +++ ifconfig.c2 Nov 2021 17:20:01 -
> @@ -2033,7 +2033,7 @@ setifnwkey(const char *val, int d)
> }
>
> if (ioctl(sock, SIOCS80211NWKEY, (caddr_t)) == -1)
> - warn("SIOCS80211NWKEY");
> + err("SIOCS80211NWKEY");
> }
>
> /* ARGSUSED */
>
I noticed the above mentioned error^Wwarning in the installer:
Which network interface do you wish to configure? (or 'done') [bse0]
bwfm0
ifconfig: SIOCS80211NWKEY: Operation not supported by device
Access point? (ESSID, 'any', list# or '?') [any] 2
Security protocol? (O)pen, (W)EP, WPA-(P)SK [O]
This comes from ieee80211_scan():
Reset 802.11 settings and determine WPA capability.
ifconfig $_if -nwid -nwkey
ifconfig $_if -wpa 2>/dev/null && _has_wpa=1
With ifconfig and installer fixed, we can properly detect and skip WEP:
Which network interface do you wish to configure? (or 'done') [bse0]
bwfm0
Access point? (ESSID, 'any', list# or '?') [any] 2
Security protocol? (O)pen, WPA-(P)SK [O] w
'w' is not a valid choice.
Security protocol? (O)pen, WPA-(P)SK [O] p
WPA passphrase? (will echo)
OK?
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1184
diff -u -p -r1.1184 install.sub
--- install.sub 2 Nov 2021 16:54:01 - 1.1184
+++ install.sub 2 Nov 2021 17:26:40 -
@@ -1228,11 +1228,12 @@ ieee80211_scan() {
# Configure 802.11 interface $1 and append ifconfig options to hostname.if $2.
# Ask the user for the access point ESSID, the security protocol and a secret.
ieee80211_config() {
- local _if=$1 _hn=$2 _prompt _nwid _haswpa=0 _err
+ local _if=$1 _hn=$2 _prompt _nwid _has_wep=0 _has_wpa=0 _err
- # Reset 802.11 settings and determine wpa capability.
- ifconfig $_if -nwid -nwkey
- ifconfig $_if -wpa 2>/dev/null && _haswpa=1
+ # Reset 802.11 settings and determine WEP and WPA capabilities.
+ ifconfig $_if -nwid
+ ifconfig $_if -nwkey 2>/dev/null && _has_wep=1
+ ifconfig $_if -wpa 2>/dev/null && _has_wpa=1
# Empty scan cache.
rm -f $WLANLIST
@@ -1256,17 +1257,19 @@ ieee80211_config() {
# 'any' implies that only open access points are considered.
if [[ $_nwid != any ]]; then
- _prompt="Security protocol? (O)pen, (W)EP"
- ((_haswpa == 1)) && _prompt="$_prompt, WPA-(P)SK"
+ _prompt="Security protocol? (O)pen"
+ ((_has_wep == 1)) && _prompt="$_prompt, (W)EP"
+ ((_has_wpa == 1)) && _prompt="$_prompt, WPA-(P)SK"
while :; do
ask_until "$_prompt" "O"
- case "$_haswpa-$resp" in
- ?-[Oo]) # No further questions
+ case "${_has_wep}${_has_wpa}-${resp}" in
+ ??-[Oo]) # No further questions
ifconfig $_if join "$_nwid"
quote join "$_nwid" >>$_hn
break
;;
- ?-[Ww]) ask_passphrase "WEP key?"
+ 1?-[Ww])
+ ask_passphrase "WEP key?"
# Make sure ifconfig accepts the key.
if _err=$(ifconfig $_if join "$_nwid" nwkey
"$_passphrase" 2>&1) &&
[[ -z $_err ]]; then
@@ -1275,7 +1278,8 @@ ieee80211_config() {
fi
echo "$_err"
;;
- 1-[Pp]) ask_passphrase "WPA passphrase?"
+ ?1-[Pp])
+ ask_passphrase "WPA passphrase?"
# Make sure ifconfig accepts the key.
if ifconfig $_if join "$_nwid" wpakey
"$_passphrase"; then
quote join "$_nwid" wpakey
"$_passphrase" >>$_hn
Re: ifconfig: return non-zero on failed "nwkey"
On Tue, Nov 02, 2021 at 05:26:17PM +, Klemens Nanni wrote:
> At least bwfm(4) does not support WEP:
>
> # ifconfig bwfm0 nwkey 12345
> ifconfig: SIOCS80211NWKEY: Operation not supported by device
> # echo $?
> 0
>
> ifconfig(8) must return non-zero in this case.
>
> This is relevant for an upcoming installer fix, but also worth itself.
>
> OK?
Yes, ok.
But regardless, this error should never happen.
It looks like bwfm(4) does support WEP but the C_WEP capability is missing
from ic_caps so net80211 believes WEP was not supported by this driver.
I don't think we have any supported wifi device that does not support WEP.
Even an(4) supports WEP!
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.445
> diff -u -p -r1.445 ifconfig.c
> --- ifconfig.c6 Oct 2021 06:14:08 - 1.445
> +++ ifconfig.c2 Nov 2021 17:20:01 -
> @@ -2033,7 +2033,7 @@ setifnwkey(const char *val, int d)
> }
>
> if (ioctl(sock, SIOCS80211NWKEY, (caddr_t)) == -1)
> - warn("SIOCS80211NWKEY");
> + err("SIOCS80211NWKEY");
> }
>
> /* ARGSUSED */
>
>
Re: ifconfig: return non-zero on failed "nwkey"
Klemens Nanni wrote:
> At least bwfm(4) does not support WEP:
>
> # ifconfig bwfm0 nwkey 12345
> ifconfig: SIOCS80211NWKEY: Operation not supported by device
> # echo $?
> 0
>
> ifconfig(8) must return non-zero in this case.
>
> This is relevant for an upcoming installer fix, but also worth itself.
>
> OK?
>
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.445
> diff -u -p -r1.445 ifconfig.c
> --- ifconfig.c6 Oct 2021 06:14:08 - 1.445
> +++ ifconfig.c2 Nov 2021 17:20:01 -
> @@ -2033,7 +2033,7 @@ setifnwkey(const char *val, int d)
> }
>
> if (ioctl(sock, SIOCS80211NWKEY, (caddr_t)) == -1)
> - warn("SIOCS80211NWKEY");
> + err("SIOCS80211NWKEY");
> }
If you do this, then a multi-parameter ifconfig will fail, without
trying other operations.
That might be desireable. Or it might not be.
ospfd/ospf6d, interfaces in log messages
I've recently started seeing a number of flaps with ospfd/ospf6d
with invalid seq nums / "seq num mismatch, bad flags" logged.
Not quite sure what's going yet as they must be occurring on
various local switched segments on one nic and also on ethernet
wan circuits direct to router on a separate pcie nic, anyway
it's made it clear that very few of the log messages relating
to neighbours identify which interface is involved.
I don't know if it makes sense to commit or not, but there's a
diff below adding the interface wherever the neighbour ID is logged
if anyone's interested (same changes to both ospfd and ospf6d).
Nov 2 11:29:30 ospfd[78532]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 20d22487 his 20d22485
Nov 2 11:29:30 ospf6d[89545]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 4cabc5c1 his 4cabc5c0
Nov 2 11:29:34 ospf6d[89545]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine 98360a5 his 98360a4
Nov 2 11:29:34 ospfd[78532]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine f708c646 his f708c645
Nov 2 11:29:38 ospfd[78532]: recv_db_description: neighbor ID xx.11:
invalid seq num, mine e4068bcc his e4068bcb
Nov 2 11:30:06 ospf6d[89545]: recv_db_description: neighbor ID xx.3:
seq num mismatch, bad flags
Nov 2 11:30:14 ospf6d[89545]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine 98360ae his 98360ad
Nov 2 11:30:14 ospfd[78532]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine f708c64f his f708c64e
Nov 2 11:30:22 ospfd[78532]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 20d22493 his 20d22490
Nov 2 11:30:22 ospfd[78532]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 20d22493 his 20d22492
Nov 2 11:30:39 ospfd[78532]: recv_db_description: neighbor ID xx.2:
invalid seq num, mine 20d2249c his 20d2249b
Nov 2 11:30:59 ospf6d[89545]: recv_db_description: neighbor ID xx.11:
seq num mismatch, bad flags
Nov 2 11:30:59 ospfd[78532]: recv_db_description: neighbor ID xx.11:
seq num mismatch, bad flags
Nov 2 11:31:09 ospfd[78532]: recv_db_description: neighbor ID xx.1:
invalid seq num, mine f708c65c his f708c65b
Index: ospf6d/database.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/database.c,v
retrieving revision 1.20
diff -u -p -r1.20 database.c
--- ospf6d/database.c 15 Jul 2020 14:47:41 - 1.20
+++ ospf6d/database.c 2 Nov 2021 17:11:38 -
@@ -60,9 +60,9 @@ send_db_description(struct nbr *nbr)
case NBR_STA_INIT:
case NBR_STA_2_WAY:
case NBR_STA_SNAP:
- log_debug("send_db_description: neighbor ID %s: "
+ log_debug("send_db_description: neighbor ID %s (%s): "
"cannot send packet in state %s", inet_ntoa(nbr->id),
- nbr_state_name(nbr->state));
+ nbr->iface->name, nbr_state_name(nbr->state));
goto fail;
case NBR_STA_XSTRT:
bits |= OSPF_DBD_MS | OSPF_DBD_M | OSPF_DBD_I;
@@ -160,8 +160,8 @@ recv_db_description(struct nbr *nbr, cha
int dupe = 0;
if (len < sizeof(dd_hdr)) {
- log_warnx("recv_db_description: neighbor ID %s: "
- "bad packet size", inet_ntoa(nbr->id));
+ log_warnx("recv_db_description: neighbor ID %s (%s): "
+ "bad packet size", inet_ntoa(nbr->id), nbr->iface->name);
return;
}
memcpy(_hdr, buf, sizeof(dd_hdr));
@@ -170,9 +170,10 @@ recv_db_description(struct nbr *nbr, cha
/* db description packet sanity checks */
if (ntohs(dd_hdr.iface_mtu) > nbr->iface->mtu) {
- log_warnx("recv_db_description: neighbor ID %s: "
+ log_warnx("recv_db_description: neighbor ID %s (%s): "
"invalid MTU %d expected %d", inet_ntoa(nbr->id),
- ntohs(dd_hdr.iface_mtu), nbr->iface->mtu);
+ nbr->iface->name, ntohs(dd_hdr.iface_mtu),
+ nbr->iface->mtu);
return;
}
@@ -180,8 +181,9 @@ recv_db_description(struct nbr *nbr, cha
nbr->last_rx_bits == dd_hdr.bits &&
ntohl(dd_hdr.dd_seq_num) == nbr->dd_seq_num - nbr->dd_master ?
1 : 0) {
- log_debug("recv_db_description: dupe from neighbor ID %s",
- inet_ntoa(nbr->id));
+ log_debug("recv_db_description: dupe from "
+ "neighbor ID %s (%s)", inet_ntoa(nbr->id),
+ nbr->iface->name);
dupe = 1;
}
@@ -190,9 +192,9 @@ recv_db_description(struct nbr *nbr, cha
case NBR_STA_ATTEMPT:
case NBR_STA_2_WAY:
case NBR_STA_SNAP:
- log_debug("recv_db_description: neighbor ID %s: "
ifconfig: return non-zero on failed "nwkey"
At least bwfm(4) does not support WEP:
# ifconfig bwfm0 nwkey 12345
ifconfig: SIOCS80211NWKEY: Operation not supported by device
# echo $?
0
ifconfig(8) must return non-zero in this case.
This is relevant for an upcoming installer fix, but also worth itself.
OK?
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.445
diff -u -p -r1.445 ifconfig.c
--- ifconfig.c 6 Oct 2021 06:14:08 - 1.445
+++ ifconfig.c 2 Nov 2021 17:20:01 -
@@ -2033,7 +2033,7 @@ setifnwkey(const char *val, int d)
}
if (ioctl(sock, SIOCS80211NWKEY, (caddr_t)) == -1)
- warn("SIOCS80211NWKEY");
+ err("SIOCS80211NWKEY");
}
/* ARGSUSED */
Re: add 802.11n 40MHz support to iwn(4)
On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> This patch adds 802.11n 40MHz support to the iwn(4) driver.
>
> This driver supports many different devices. Please try to be precise
> about which device you have tested so I can maintain a record of our
> test coverage.
Here is a new version of the iwn 40MHz patch.
The previous version of this patch introduced a performance regression
on a 6200 device I have tested with. The only workaround I found so far
is to disable SGI on 40MHz for these devices. This hides the problem and
is not a real fix. But even without the 40MHz patch Tx performance is
suboptimal on this device. It never manages to transmit frames on MCS 5
or higher. Perhaps this device is not properly calibrated by our driver.
In any case, it is a separate issue which this 40MHz patch does not need
to solve.
Other changes are merely cosmetic.
diff refs/heads/master refs/heads/40mhz
blob - aff55acd0f19afbd39ffc78596af5349df58468f
blob + f94b88d85d595cc61209045370b51789262eedcd
--- sys/dev/pci/if_iwn.c
+++ sys/dev/pci/if_iwn.c
@@ -241,12 +241,16 @@ uint16_t iwn_get_passive_dwell_time(struct iwn_softc *
intiwn_scan(struct iwn_softc *, uint16_t, int);
void iwn_scan_abort(struct iwn_softc *);
intiwn_bgscan(struct ieee80211com *);
+void iwn_rxon_configure_ht40(struct ieee80211com *,
+ struct ieee80211_node *);
+intiwn_rxon_ht40_enabled(struct iwn_softc *);
intiwn_auth(struct iwn_softc *, int);
intiwn_run(struct iwn_softc *);
intiwn_set_key(struct ieee80211com *, struct ieee80211_node *,
struct ieee80211_key *);
void iwn_delete_key(struct ieee80211com *, struct ieee80211_node *,
struct ieee80211_key *);
+void iwn_updatechan(struct ieee80211com *);
void iwn_updateprot(struct ieee80211com *);
void iwn_updateslot(struct ieee80211com *);
void iwn_update_rxon(struct iwn_softc *);
@@ -489,13 +493,15 @@ iwn_attach(struct device *parent, struct device *self,
ic->ic_caps |= (IEEE80211_C_QOS | IEEE80211_C_TX_AMPDU);
/* Set HT capabilities. */
ic->ic_htcaps = IEEE80211_HTCAP_SGI20;
+ /* 6200 devices have issues with SGI40 for some reason. */
+ if ((sc->sc_flags & IWN_FLAG_INTERNAL_PA) == 0)
+ ic->ic_htcaps |= IEEE80211_HTCAP_SGI40;
+ ic->ic_htcaps |= IEEE80211_HTCAP_CBW20_40;
#ifdef notyet
ic->ic_htcaps |=
#if IWN_RBUF_SIZE == 8192
IEEE80211_HTCAP_AMSDU7935 |
#endif
- IEEE80211_HTCAP_CBW20_40 |
- IEEE80211_HTCAP_SGI40;
if (sc->hw_type != IWN_HW_REV_TYPE_4965)
ic->ic_htcaps |= IEEE80211_HTCAP_GF;
if (sc->hw_type == IWN_HW_REV_TYPE_6050)
@@ -541,6 +547,7 @@ iwn_attach(struct device *parent, struct device *self,
ic->ic_updateedca = iwn_updateedca;
ic->ic_set_key = iwn_set_key;
ic->ic_delete_key = iwn_delete_key;
+ ic->ic_updatechan = iwn_updatechan;
ic->ic_updateprot = iwn_updateprot;
ic->ic_updateslot = iwn_updateslot;
ic->ic_ampdu_rx_start = iwn_ampdu_rx_start;
@@ -1473,8 +1480,8 @@ iwn4965_read_eeprom(struct iwn_softc *sc)
/* Read regulatory domain (4 ASCII characters). */
iwn_read_prom_data(sc, IWN4965_EEPROM_DOMAIN, sc->eeprom_domain, 4);
- /* Read the list of authorized channels (20MHz ones only). */
- for (i = 0; i < 5; i++) {
+ /* Read the list of authorized channels. */
+ for (i = 0; i < 7; i++) {
addr = iwn4965_regulatory_bands[i];
iwn_read_eeprom_channels(sc, i, addr);
}
@@ -1558,8 +1565,8 @@ iwn5000_read_eeprom(struct iwn_softc *sc)
iwn_read_prom_data(sc, base + IWN5000_EEPROM_DOMAIN,
sc->eeprom_domain, 4);
- /* Read the list of authorized channels (20MHz ones only). */
- for (i = 0; i < 5; i++) {
+ /* Read the list of authorized channels. */
+ for (i = 0; i < 7; i++) {
addr = base + iwn5000_regulatory_bands[i];
iwn_read_eeprom_channels(sc, i, addr);
}
@@ -1629,7 +1636,7 @@ iwn_read_eeprom_channels(struct iwn_softc *sc, int n,
IEEE80211_CHAN_CCK | IEEE80211_CHAN_OFDM |
IEEE80211_CHAN_DYN | IEEE80211_CHAN_2GHZ;
- } else {/* 5GHz band */
+ } else if (n < 5) { /* 5GHz band */
/*
* Some adapters support channels 7, 8, 11 and 12
* both in the 2GHz and 4.9GHz bands.
@@ -1644,22 +1651,29 @@ iwn_read_eeprom_channels(struct iwn_softc *sc, int n,
ic->ic_channels[chan].ic_flags = IEEE80211_CHAN_A;
/* We have at
Re: uniq(1): ignore newline when comparing lines?
On Tue, Nov 02, 2021 at 08:12:00AM -0600, Todd C. Miller wrote:
> On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote:
>
> > Yes it would be simpler. However I didn't want to start changing the
> > input -- which we currently don't do -- without discussing it.
> >
> > The standard says we should "write one copy of each input line on the
> > output." So, if we are being strict, we don't add a newline that isn't
> > there, because that isn't what we read. Any other interpretation
> > requires handwaving about what an "input line" even is.
>
> The System V version of uniq actually ignores the last line if it
> doesn't end in a newline. For example:
>
> $ printf "bar\nfoo\nfool" | uniq
> bar
> foo
>
> AIX, Solaris, and HP-UX still exhibit this behavior. What happens
> is that the gline() function (which reads the line) returns non-zero
> when it hits EOF, discarding any input in that line. Interestingly,
> it does realloc the line buffer as needed to handle long lines.
>
> So really, this is a corner case where you can't count on consistent
> behavior among implementations and we just need to do what we think
> is best. If you prefer we retain the existing behavior wrt a final
> line without a newline that is OK with me.
NetBSD still does what we do. So there are three behaviors in the
wild.
Sigh.
Let's go with the FreeBSD/DragonFly/GNU unconditional newline
behavior. It's simpler to implement it this way if we're going to
adopt the POSIX.1-2008 change and start ignoring newlines when we
compare lines.
We can share the blame if it breaks something.
I'll wait a few days to let other people comment, as this is a
behavior change.
Here's an updated patch. Note that we do not (yet) use the line
length for anything but stubbing out the newline so we only need
a single variable for this purpose.
OK? Objections from people who are not millert@?
Index: uniq.c
===
RCS file: /cvs/src/usr.bin/uniq/uniq.c,v
retrieving revision 1.28
diff -u -p -r1.28 uniq.c
--- uniq.c 1 Nov 2021 23:20:35 - 1.28
+++ uniq.c 2 Nov 2021 15:34:48 -
@@ -60,6 +60,7 @@ main(int argc, char *argv[])
char *prevline, *t1, *t2, *thisline;
FILE *ifp = NULL, *ofp = NULL;
size_t prevsize, thissize, tmpsize;
+ ssize_t len;
int ch;
setlocale(LC_CTYPE, "");
@@ -133,16 +134,21 @@ main(int argc, char *argv[])
prevsize = 0;
prevline = NULL;
- if (getline(, , ifp) == -1) {
+ if ((len = getline(, , ifp)) == -1) {
free(prevline);
if (ferror(ifp))
err(1, "getline");
exit(0);
}
+ if (prevline[len - 1] == '\n')
+ prevline[len - 1] = '\0';
thissize = 0;
thisline = NULL;
- while (getline(, , ifp) != -1) {
+ while ((len = getline(, , ifp)) != -1) {
+ if (thisline[len - 1] == '\n')
+ thisline[len - 1] = '\0';
+
/* If requested get the chosen fields + character offsets. */
if (numfields || numchars) {
t1 = skip(thisline);
@@ -185,9 +191,9 @@ show(FILE *ofp, char *str)
{
if ((dflag && repeats) || (uflag && !repeats)) {
if (cflag)
- (void)fprintf(ofp, "%4d %s", repeats + 1, str);
+ fprintf(ofp, "%4d %s\n", repeats + 1, str);
else
- (void)fprintf(ofp, "%s", str);
+ fprintf(ofp, "%s\n", str);
}
}
Re: uniq: add HISTORY section
Hi Todd, Todd C. Miller wrote on Tue, Nov 02, 2021 at 08:20:47AM -0600: > uniq appeared in research Unix version 3. OK schwarze@. If - like in this case - the indicated release is the first one in any system to ever contain the feature, and not just the first one among the direct ancestors of OpenBSD, i prefer the wording "utility first appeared in", though. No big deal, your call. Yours, Ingo > Index: usr.bin/uniq/uniq.1 > === > RCS file: /cvs/src/usr.bin/uniq/uniq.1,v > retrieving revision 1.21 > diff -u -p -u -r1.21 uniq.1 > --- usr.bin/uniq/uniq.1 23 Dec 2017 00:52:33 - 1.21 > +++ usr.bin/uniq/uniq.1 2 Nov 2021 14:14:19 - > @@ -159,3 +159,8 @@ The historic > and > .Fl Ns Ar number > options have been deprecated but are still supported in this implementation. > +.Sh HISTORY > +A > +.Nm > +utility appeared in > +.At v3 .
Re: uniq(1): ignore newline when comparing lines?
Hi, Todd C. Miller wrote on Tue, Nov 02, 2021 at 08:12:00AM -0600: > On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote: >> Yes it would be simpler. However I didn't want to start changing the >> input -- which we currently don't do -- without discussing it. >> >> The standard says we should "write one copy of each input line on the >> output." So, if we are being strict, we don't add a newline that isn't >> there, because that isn't what we read. Any other interpretation >> requires handwaving about what an "input line" even is. > The System V version of uniq actually ignores the last line if it > doesn't end in a newline. For example: > > $ printf "bar\nfoo\nfool" | uniq > bar > foo > > AIX, Solaris, and HP-UX still exhibit this behavior. What happens > is that the gline() function (which reads the line) returns non-zero > when it hits EOF, discarding any input in that line. Interestingly, > it does realloc the line buffer as needed to handle long lines. > > So really, this is a corner case where you can't count on consistent > behavior among implementations and we just need to do what we think > is best. If you prefer we retain the existing behavior wrt a final > line without a newline that is OK with me. Just a quick comment without looking at the code: POSIX says on https://pubs.opengroup.org/onlinepubs/9699919799/utilities/uniq.html : INPUT FILES The input file shall be a text file. By definition, a file that does not end in a newline character is *NOT* a text file. Consequently, what uniq(1) does in this case is unspecified. My personal opinion is that in general, if utilities are specified to process text files and the terminating newline is missing, it is best to behave as if the mandatory terminating newline were present. The reason why i think so is that forgetting the terminating newline is a popular user error, and silently assuming a terminating newline causes less surprise with users than silently discarding the incomplete last line. Most users are not even aware that a file without a terminating newline is not a text file, so it definitely is less surprising for the vast majority. But even those who are aware of that quirk in the definition of what a text file is (like myself) are regularly surprised by the consequences... Yours, Ingo
uniq: add HISTORY section
uniq appeared in research Unix version 3. - todd Index: usr.bin/uniq/uniq.1 === RCS file: /cvs/src/usr.bin/uniq/uniq.1,v retrieving revision 1.21 diff -u -p -u -r1.21 uniq.1 --- usr.bin/uniq/uniq.1 23 Dec 2017 00:52:33 - 1.21 +++ usr.bin/uniq/uniq.1 2 Nov 2021 14:14:19 - @@ -159,3 +159,8 @@ The historic and .Fl Ns Ar number options have been deprecated but are still supported in this implementation. +.Sh HISTORY +A +.Nm +utility appeared in +.At v3 .
Re: uniq(1): ignore newline when comparing lines?
Actually, the historic version of uniq used static 1000 byte buffers. Solaris 2.6 includes a version that realloc()s the buffer but I don't know when exactly that behavior was added. - todd
Re: Enable Spleen 16x32 and 32x64 on riscv64
> Date: Tue, 2 Nov 2021 15:05:46 +0100 > From: Frederic Cambus > > On Fri, Oct 29, 2021 at 06:20:07PM -0400, Brad Smith wrote: > > > > Therefore, here is a diff to enable spleen16x32 and spleen32x64 on riscv64 > > > for GENERIC kernels, like we do on amd64, arm64, armv7, and i386. > > > > > > Comments? OK? > > > > Sounds like this should be enabled on powerpc64 too? > > I got an OK for the riscv64 part so I committed it. > > Looking at the GENERIC kernel conf file for powerpc64, it indeed appears > that it has radeondrm(4) support, and that it would be useful to enable > the fonts on this platform as well. The following diff does that. > > Thanks for pointing this out, Brad. > > Comments? OK? ok kettenis@ > Index: sys/dev/wsfont/wsfont.c > === > RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v > retrieving revision 1.60 > diff -u -p -r1.60 wsfont.c > --- sys/dev/wsfont/wsfont.c 1 Nov 2021 18:43:04 - 1.60 > +++ sys/dev/wsfont/wsfont.c 2 Nov 2021 13:51:52 - > @@ -102,7 +102,8 @@ > #endif > > #if !defined(SMALL_KERNEL) && (defined(__amd64__) || defined(__i386__) || \ > -defined(__arm64__) || defined(__armv7__) || defined(__riscv64__)) > +defined(__arm64__) || defined(__armv7__) || defined(__riscv64__) || \ > +defined(__powerpc64__)) > #define FONT_SPLEEN16x32 > #define FONT_SPLEEN32x64 > #endif > >
Re: uniq(1): ignore newline when comparing lines?
On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote: > Yes it would be simpler. However I didn't want to start changing the > input -- which we currently don't do -- without discussing it. > > The standard says we should "write one copy of each input line on the > output." So, if we are being strict, we don't add a newline that isn't > there, because that isn't what we read. Any other interpretation > requires handwaving about what an "input line" even is. The System V version of uniq actually ignores the last line if it doesn't end in a newline. For example: $ printf "bar\nfoo\nfool" | uniq bar foo AIX, Solaris, and HP-UX still exhibit this behavior. What happens is that the gline() function (which reads the line) returns non-zero when it hits EOF, discarding any input in that line. Interestingly, it does realloc the line buffer as needed to handle long lines. So really, this is a corner case where you can't count on consistent behavior among implementations and we just need to do what we think is best. If you prefer we retain the existing behavior wrt a final line without a newline that is OK with me. - todd
Re: Enable Spleen 16x32 and 32x64 on riscv64
On Fri, Oct 29, 2021 at 06:20:07PM -0400, Brad Smith wrote: > > Therefore, here is a diff to enable spleen16x32 and spleen32x64 on riscv64 > > for GENERIC kernels, like we do on amd64, arm64, armv7, and i386. > > > > Comments? OK? > > Sounds like this should be enabled on powerpc64 too? I got an OK for the riscv64 part so I committed it. Looking at the GENERIC kernel conf file for powerpc64, it indeed appears that it has radeondrm(4) support, and that it would be useful to enable the fonts on this platform as well. The following diff does that. Thanks for pointing this out, Brad. Comments? OK? Index: sys/dev/wsfont/wsfont.c === RCS file: /cvs/src/sys/dev/wsfont/wsfont.c,v retrieving revision 1.60 diff -u -p -r1.60 wsfont.c --- sys/dev/wsfont/wsfont.c 1 Nov 2021 18:43:04 - 1.60 +++ sys/dev/wsfont/wsfont.c 2 Nov 2021 13:51:52 - @@ -102,7 +102,8 @@ #endif #if !defined(SMALL_KERNEL) && (defined(__amd64__) || defined(__i386__) || \ -defined(__arm64__) || defined(__armv7__) || defined(__riscv64__)) +defined(__arm64__) || defined(__armv7__) || defined(__riscv64__) || \ +defined(__powerpc64__)) #define FONT_SPLEEN16x32 #define FONT_SPLEEN32x64 #endif
Re: unwind.conf.5: Zap duplicate bits, mention route nameserver
On Tue, Oct 26, 2021 at 01:24:30PM +, Klemens Nanni wrote:
> Mentioning `route nameserver' relevance made it obvious that the
> `preference' block duplicates lots of information and I despise adding
> to that.
route(8) is fixed/polished, unwind.conf(5) still lacks behind.
> So rearrange the list of types such that conceptually related ones are
> subsequent and can reference each user to not repeat things.
>
> This looks like this:
>
> preference {type ...}
>A list of DNS name server types to specify the order in which
>name servers are picked when measured round-trip time medians are
>equal. Additionally, the first mentioned type gets a time bonus.
>Validating name servers are always picked over non-validating
>name servers. DNS name server types are:
>
>autoconfName servers learned via DHCP, SLAAC or route
>nameserver.
>oDoT-autoconf autoconf with opportunistic DNS over TLS.
>stubautoconf via libc functions. See asr_run(3).
>Will never validate. Useful when running behind
>broken middle boxes that do not like edns0. DNS
>answers from stub name servers are not cached.
>forwarder Name servers configured in unwind.conf.
>DoT forwarder with DNS over TLS.
>oDoT-forwarder Opportunistic DoT.
>recursorRecursively resolve names.
>
> Emphasize "edns0" while here and simplify "unwind does X" to just "X".
>
> Fist I tried listing types in the default order such that the sentence
> afterwards is obsoleted by the self-documenting manner, but that
> conflicts with the logical order I picked above.
>
> Feedback? Objections? OK?
Anyone?
Index: unwind.conf.5
===
RCS file: /cvs/src/sbin/unwind/unwind.conf.5,v
retrieving revision 1.31
diff -u -p -r1.31 unwind.conf.5
--- unwind.conf.5 24 Oct 2021 15:57:17 - 1.31
+++ unwind.conf.5 26 Oct 2021 13:17:56 -
@@ -93,33 +93,32 @@ Validating name servers are always picke
DNS name server types are:
.Pp
.Bl -tag -width "oDoT-forwarder" -compact
+.It Ic autoconf
+Name servers learned via DHCP, SLAAC or
+.Cm route nameserver .
+.It Ic oDoT-autoconf
+.Ic autoconf
+with opportunistic DNS over TLS.
.It Ic stub
-Name servers learned via DHCP or SLAAC, queried using the libc functions.
+.Ic autoconf
+via libc functions.
See
.Xr asr_run 3 .
Will never validate.
-Useful when running behind broken middle boxes that do not like edns0.
+Useful when running behind broken middle boxes that do not like
+.Cm edns0 .
DNS answers from stub name servers are not cached.
-.It Ic autoconf
-Name servers learned via DHCP or SLAAC.
-.It Ic oDoT-autoconf
-Name servers learned via DHCP or SLAAC.
-.Nm unwind
-tries to opportunistically use DNS over TLS.
-.It Ic DoT
-DNS over TLS name servers configured in
-.Nm .
.It Ic forwarder
Name servers configured in
.Nm .
+.It Ic DoT
+.Ic forwarder
+with DNS over TLS.
.It Ic oDoT-forwarder
-Name servers configured in
-.Nm .
-.Nm unwind
-tries to opportunistically use DNS over TLS.
+Opportunistic
+.Ic DoT .
.It Ic recursor
-.Nm unwind
-itself recursively resolves names.
+Recursively resolve names.
.El
.Pp
The default preference is
Re: diff: ipsec.conf(5), clarify "aes" accepts 128:256 bits
On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote: > I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits. > > sbin/ipsecctl/ike.c: > 201 case ENCXF_AES: > 202 enc_alg = "AES"; > 203 key_length = "128,128:256"; > 204 break; > > > ok? > > Clarify "aes" will accept keys which length is in 128:256 bits. > i notice that the enc lists in ipsec.conf.5 and iked.conf.5 differ. aren;t they supposed to be in sync? for example, iked.conf.5 doesn;t mention "aes" or "aesctr". also the *-gmac and *-gcm-12 discrepancy. jmc > Index: sbin/ipsecctl/ipsec.conf.5 > === > RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v > retrieving revision 1.160 > diff -u -p -r1.160 ipsec.conf.5 > --- sbin/ipsecctl/ipsec.conf.522 Oct 2021 12:30:54 - 1.160 > +++ sbin/ipsecctl/ipsec.conf.52 Nov 2021 02:58:13 - > @@ -637,10 +637,10 @@ keyword: > The following cipher types are permitted with the > .Ic enc > keyword: > -.Bl -column "aes-128-gmac" "Key Length" "Description" -offset indent > +.Bl -column "aes-128-gmac" "128-256 bits" "Description" -offset indent > .It Em "Cipher" Ta Em "Key Length" Ta "" > .It Li 3des Ta "168 bits" Ta "" > -.It Li aes Ta "128 bits" Ta "" > +.It Li aes Ta "128-256 bits" Ta "" > .It Li aes-128 Ta "128 bits" Ta "" > .It Li aes-192 Ta "192 bits" Ta "" > .It Li aes-256 Ta "256 bits" Ta "" >
Re: diff: isakmpd.conf.5, clarify ANY can be used for some params
On Tue, Nov 02, 2021 at 12:04:25PM +0900, YASUOKA Masahiko wrote: > ok? > > Clarify that ANY can be used for several parameters of IPsec transform. > > Index: sbin/isakmpd/isakmpd.conf.5 > === > RCS file: /cvs/src/sbin/isakmpd/isakmpd.conf.5,v > retrieving revision 1.135 > diff -u -p -r1.135 isakmpd.conf.5 > --- sbin/isakmpd/isakmpd.conf.5 17 Apr 2018 12:13:29 - 1.135 > +++ sbin/isakmpd/isakmpd.conf.5 2 Nov 2021 02:57:23 - > @@ -726,7 +726,7 @@ See below. > Parameters for IPsec transform configuration > .Bl -tag -width Ds > .It Em AUTHENTICATION_ALGORITHM > -The optional authentication algorithm in the case of this > +The optional authentication algorithm or ANY in the case of this hi. i think it would be clearer to add a comma after "algorithm", like you do below after "RFCs". it makes it clearer that only "ANY" relates to "being an ESP transform", and not "the optional authentication algorithm" as well. otherwise ok by me. jmc > being an ESP transform. > .It Em ENCAPSULATION_MODE > The encapsulation mode as given by the RFCs. > @@ -745,7 +745,8 @@ List of lifetimes, each element is a > .Aq Sy Lifetime > section name. > .It Em TRANSFORM_ID > -The transform ID as given by the RFCs. > +The transform ID as given by the RFCs, or ANY to denote that any > +transform proposed will be accepted. > .El > .It Aq Sy IPsec-ID > Parameters for IPsec ID configuration >
