pfkey: export tdb mtu
Hi,
here's a diff to export tdb MTUs via pfkey and view them with ipsecctl.
This turned out to be quite useful to debug path MTU discovery issues with
IPsec UDP encapsulation.
ok?
Index: sys/net/pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.215
diff -u -p -r1.215 pfkeyv2.c
--- sys/net/pfkeyv2.c 30 May 2021 21:01:27 - 1.215
+++ sys/net/pfkeyv2.c 4 Jul 2021 14:05:59 -
@@ -859,6 +859,9 @@ pfkeyv2_get(struct tdb *tdb, void **head
if (tdb->tdb_udpencap_port)
i += sizeof(struct sadb_x_udpencap);
+ if (tdb->tdb_mtu > 0)
+ i+= sizeof(struct sadb_x_mtu);
+
if (tdb->tdb_rdomain != tdb->tdb_rdomain_post)
i += sizeof(struct sadb_x_rdomain);
@@ -950,6 +953,11 @@ pfkeyv2_get(struct tdb *tdb, void **head
if (tdb->tdb_udpencap_port) {
headers[SADB_X_EXT_UDPENCAP] = p;
export_udpencap(, tdb);
+ }
+
+ if (tdb->tdb_mtu > 0) {
+ headers[SADB_X_EXT_MTU] = p;
+ export_mtu(, tdb);
}
/* Export rdomain switch, if present */
Index: sys/net/pfkeyv2.h
===
RCS file: /cvs/src/sys/net/pfkeyv2.h,v
retrieving revision 1.87
diff -u -p -r1.87 pfkeyv2.h
--- sys/net/pfkeyv2.h 25 May 2021 09:55:22 - 1.87
+++ sys/net/pfkeyv2.h 4 Jul 2021 14:06:01 -
@@ -239,6 +239,12 @@ struct sadb_x_counter {
uint64_t sadb_x_counter_ouncompbytes; /* Output bytes, uncompressed */
};
+struct sadb_x_mtu {
+ uint16_t sadb_x_mtu_len;
+ uint16_t sadb_x_mtu_exttype;
+ u_int32_t sadb_x_mtu_mtu;
+};
+
#ifdef _KERNEL
#define SADB_X_GETSPROTO(x) \
( (x) == SADB_SATYPE_AH ? IPPROTO_AH :\
@@ -285,7 +291,8 @@ struct sadb_x_counter {
#define SADB_X_EXT_SATYPE235
#define SADB_X_EXT_COUNTER36
#define SADB_X_EXT_RDOMAIN37
-#define SADB_EXT_MAX 37
+#define SADB_X_EXT_MTU38
+#define SADB_EXT_MAX 38
/* Fix pfkeyv2.c struct pfkeyv2_socket if SATYPE_MAX > 31 */
#define SADB_SATYPE_UNSPEC 0
@@ -419,6 +426,7 @@ void export_key(void **, struct tdb *, i
void export_udpencap(void **, struct tdb *);
void export_tag(void **, struct tdb *);
void export_rdomain(void **, struct tdb *);
+void export_mtu(void **, struct tdb *);
void export_tap(void **, struct tdb *);
void export_satype(void **, struct tdb *);
void export_counter(void **, struct tdb *);
Index: sys/net/pfkeyv2_convert.c
===
RCS file: /cvs/src/sys/net/pfkeyv2_convert.c,v
retrieving revision 1.70
diff -u -p -r1.70 pfkeyv2_convert.c
--- sys/net/pfkeyv2_convert.c 14 Dec 2020 20:20:06 - 1.70
+++ sys/net/pfkeyv2_convert.c 4 Jul 2021 14:06:02 -
@@ -853,6 +853,18 @@ export_udpencap(void **p, struct tdb *td
*p += sizeof(struct sadb_x_udpencap);
}
+/* Export mtu for SA */
+void
+export_mtu(void **p, struct tdb *tdb)
+{
+ struct sadb_x_mtu *smtu = (struct sadb_x_mtu *)*p;
+
+ smtu->sadb_x_mtu_mtu = tdb->tdb_mtu;
+ smtu->sadb_x_mtu_len =
+ sizeof(struct sadb_x_mtu) / sizeof(uint64_t);
+ *p += sizeof(struct sadb_x_mtu);
+}
+
/* Import rdomain switch for SA */
void
import_rdomain(struct tdb *tdb, struct sadb_x_rdomain *srdomain)
Index: sys/net/pfkeyv2_parsemessage.c
===
RCS file: /cvs/src/sys/net/pfkeyv2_parsemessage.c,v
retrieving revision 1.57
diff -u -p -r1.57 pfkeyv2_parsemessage.c
--- sys/net/pfkeyv2_parsemessage.c 25 May 2021 09:55:22 - 1.57
+++ sys/net/pfkeyv2_parsemessage.c 4 Jul 2021 14:06:03 -
@@ -128,6 +128,7 @@
#define BITMAP_X_SATYPE2 (1LL << SADB_X_EXT_SATYPE2)
#define BITMAP_X_RDOMAIN (1LL << SADB_X_EXT_RDOMAIN)
#define BITMAP_X_COUNTER (1LL << SADB_X_EXT_COUNTER)
+#define BITMAP_X_MTU (1LL << SADB_X_EXT_MTU)
uint64_t sadb_exts_allowed_in[SADB_MAX+1] =
{
@@ -214,7 +215,7 @@ const uint64_t sadb_exts_allowed_out[SAD
/* DELETE */
BITMAP_SA | BITMAP_ADDRESS_SRC | BITMAP_ADDRESS_DST | BITMAP_X_RDOMAIN,
/* GET */
- BITMAP_SA | BITMAP_LIFETIME | BITMAP_ADDRESS | BITMAP_KEY |
BITMAP_IDENTITY | BITMAP_X_UDPENCAP | BITMAP_X_LIFETIME_LASTUSE |
BITMAP_X_SRC_MASK | BITMAP_X_DST_MASK | BITMAP_X_PROTOCOL | BITMAP_X_FLOW_TYPE
| BITMAP_X_SRC_FLOW | BITMAP_X_DST_FLOW | BITMAP_X_TAG | BITMAP_X_TAP |
BITMAP_X_COUNTER | BITMAP_X_RDOMAIN,
+ BITMAP_SA | BITMAP_LIFETIME | BITMAP_ADDRESS | BITMAP_KEY |
BITMAP_IDENTITY | BITMAP_X_UDPENCAP | BITMAP_X_LIFETIME_LASTUSE |
BITMAP_X_SRC_MASK | BITMAP_X_DST_MASK | BITMAP_X_PROTOCOL | BITMAP_X_FLOW_TYPE
| BITMAP_X_SRC_FLOW | BITMAP_X_DST_FLOW | BITMAP_X_TAG | BITMAP_X_TAP |
Re: pfkey: export tdb mtu
On Sun, Jul 04, 2021 at 04:16:24PM +0200, Tobias Heider wrote:
> here's a diff to export tdb MTUs via pfkey and view them with ipsecctl.
> This turned out to be quite useful to debug path MTU discovery issues with
> IPsec UDP encapsulation.
>
> ok?
OK bluhm@
> Index: sys/net/pfkeyv2.c
> ===
> RCS file: /cvs/src/sys/net/pfkeyv2.c,v
> retrieving revision 1.215
> diff -u -p -r1.215 pfkeyv2.c
> --- sys/net/pfkeyv2.c 30 May 2021 21:01:27 - 1.215
> +++ sys/net/pfkeyv2.c 4 Jul 2021 14:05:59 -
> @@ -859,6 +859,9 @@ pfkeyv2_get(struct tdb *tdb, void **head
> if (tdb->tdb_udpencap_port)
> i += sizeof(struct sadb_x_udpencap);
>
> + if (tdb->tdb_mtu > 0)
> + i+= sizeof(struct sadb_x_mtu);
> +
> if (tdb->tdb_rdomain != tdb->tdb_rdomain_post)
> i += sizeof(struct sadb_x_rdomain);
>
> @@ -950,6 +953,11 @@ pfkeyv2_get(struct tdb *tdb, void **head
> if (tdb->tdb_udpencap_port) {
> headers[SADB_X_EXT_UDPENCAP] = p;
> export_udpencap(, tdb);
> + }
> +
> + if (tdb->tdb_mtu > 0) {
> + headers[SADB_X_EXT_MTU] = p;
> + export_mtu(, tdb);
> }
>
> /* Export rdomain switch, if present */
> Index: sys/net/pfkeyv2.h
> ===
> RCS file: /cvs/src/sys/net/pfkeyv2.h,v
> retrieving revision 1.87
> diff -u -p -r1.87 pfkeyv2.h
> --- sys/net/pfkeyv2.h 25 May 2021 09:55:22 - 1.87
> +++ sys/net/pfkeyv2.h 4 Jul 2021 14:06:01 -
> @@ -239,6 +239,12 @@ struct sadb_x_counter {
> uint64_t sadb_x_counter_ouncompbytes; /* Output bytes, uncompressed */
> };
>
> +struct sadb_x_mtu {
> + uint16_t sadb_x_mtu_len;
> + uint16_t sadb_x_mtu_exttype;
> + u_int32_t sadb_x_mtu_mtu;
> +};
> +
> #ifdef _KERNEL
> #define SADB_X_GETSPROTO(x) \
> ( (x) == SADB_SATYPE_AH ? IPPROTO_AH :\
> @@ -285,7 +291,8 @@ struct sadb_x_counter {
> #define SADB_X_EXT_SATYPE235
> #define SADB_X_EXT_COUNTER36
> #define SADB_X_EXT_RDOMAIN37
> -#define SADB_EXT_MAX 37
> +#define SADB_X_EXT_MTU38
> +#define SADB_EXT_MAX 38
>
> /* Fix pfkeyv2.c struct pfkeyv2_socket if SATYPE_MAX > 31 */
> #define SADB_SATYPE_UNSPEC0
> @@ -419,6 +426,7 @@ void export_key(void **, struct tdb *, i
> void export_udpencap(void **, struct tdb *);
> void export_tag(void **, struct tdb *);
> void export_rdomain(void **, struct tdb *);
> +void export_mtu(void **, struct tdb *);
> void export_tap(void **, struct tdb *);
> void export_satype(void **, struct tdb *);
> void export_counter(void **, struct tdb *);
> Index: sys/net/pfkeyv2_convert.c
> ===
> RCS file: /cvs/src/sys/net/pfkeyv2_convert.c,v
> retrieving revision 1.70
> diff -u -p -r1.70 pfkeyv2_convert.c
> --- sys/net/pfkeyv2_convert.c 14 Dec 2020 20:20:06 - 1.70
> +++ sys/net/pfkeyv2_convert.c 4 Jul 2021 14:06:02 -
> @@ -853,6 +853,18 @@ export_udpencap(void **p, struct tdb *td
> *p += sizeof(struct sadb_x_udpencap);
> }
>
> +/* Export mtu for SA */
> +void
> +export_mtu(void **p, struct tdb *tdb)
> +{
> + struct sadb_x_mtu *smtu = (struct sadb_x_mtu *)*p;
> +
> + smtu->sadb_x_mtu_mtu = tdb->tdb_mtu;
> + smtu->sadb_x_mtu_len =
> + sizeof(struct sadb_x_mtu) / sizeof(uint64_t);
> + *p += sizeof(struct sadb_x_mtu);
> +}
> +
> /* Import rdomain switch for SA */
> void
> import_rdomain(struct tdb *tdb, struct sadb_x_rdomain *srdomain)
> Index: sys/net/pfkeyv2_parsemessage.c
> ===
> RCS file: /cvs/src/sys/net/pfkeyv2_parsemessage.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 pfkeyv2_parsemessage.c
> --- sys/net/pfkeyv2_parsemessage.c25 May 2021 09:55:22 - 1.57
> +++ sys/net/pfkeyv2_parsemessage.c4 Jul 2021 14:06:03 -
> @@ -128,6 +128,7 @@
> #define BITMAP_X_SATYPE2 (1LL << SADB_X_EXT_SATYPE2)
> #define BITMAP_X_RDOMAIN (1LL << SADB_X_EXT_RDOMAIN)
> #define BITMAP_X_COUNTER (1LL << SADB_X_EXT_COUNTER)
> +#define BITMAP_X_MTU (1LL << SADB_X_EXT_MTU)
>
> uint64_t sadb_exts_allowed_in[SADB_MAX+1] =
> {
> @@ -214,7 +215,7 @@ const uint64_t sadb_exts_allowed_out[SAD
> /* DELETE */
> BITMAP_SA | BITMAP_ADDRESS_SRC | BITMAP_ADDRESS_DST | BITMAP_X_RDOMAIN,
> /* GET */
> - BITMAP_SA | BITMAP_LIFETIME | BITMAP_ADDRESS | BITMAP_KEY |
> BITMAP_IDENTITY | BITMAP_X_UDPENCAP | BITMAP_X_LIFETIME_LASTUSE |
> BITMAP_X_SRC_MASK | BITMAP_X_DST_MASK | BITMAP_X_PROTOCOL |
> BITMAP_X_FLOW_TYPE | BITMAP_X_SRC_FLOW | BITMAP_X_DST_FLOW | BITMAP_X_TAG |
> BITMAP_X_TAP | BITMAP_X_COUNTER | BITMAP_X_RDOMAIN,
> + BITMAP_SA | BITMAP_LIFETIME | BITMAP_ADDRESS |
dwiic(4): wait for tx empty when hitting tx limit
Hi,
I had trouble interfacing with a machine's IPMI through dwiic(4). What
I saw was that when sending 'bigger' commands, it would never receive
the STOP bit interrupt.
The trouble is, as can be seen in the log, that we want to send (it
says read, but it's a write OP, so it's send) 20 bytes, but the tx
limit says 14.
What we should do is send 14 bytes, then wait for it to send us the
tx empty interrupt (like we do when we first enable the controller),
and then re-read the tx limit. The last line in the log is some
debug print I added for myself, but is not part of the diff.
With this, I was finally able to change the IPMI password and regain
access to the web interface after updating the BMC's firmware...
dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 3, flags 0x00
dwiic0: dwiic_i2c_exec: need to read 3 bytes, can send 14 read reqs
dwiic0: dwiic_i2c_exec: op 5, addr 0x10, cmdlen 1, len 33, flags 0x00
dwiic0: dwiic_i2c_exec: need to read 33 bytes, can send 15 read reqs
dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 20, flags 0x00
dwiic0: dwiic_i2c_exec: need to read 20 bytes, can send 14 read reqs
dwiic0: new tx limit 8
Opinions? ok?
Patrick
diff --git a/sys/dev/ic/dwiic.c b/sys/dev/ic/dwiic.c
index 84d97b8645b..d04a7b03979 100644
--- a/sys/dev/ic/dwiic.c
+++ b/sys/dev/ic/dwiic.c
@@ -416,6 +416,21 @@ dwiic_i2c_exec(void *cookie, i2c_op_t op, i2c_addr_t addr,
const void *cmdbuf,
tx_limit = sc->tx_fifo_depth -
dwiic_read(sc, DW_IC_TXFLR);
}
+
+ if (I2C_OP_WRITE_P(op) && tx_limit == 0 && x < len) {
+ s = splbio();
+ dwiic_read(sc, DW_IC_CLR_INTR);
+ dwiic_write(sc, DW_IC_INTR_MASK, DW_IC_INTR_TX_EMPTY);
+
+ if (tsleep_nsec(>sc_writewait, PRIBIO, "dwiic",
+ MSEC_TO_NSEC(500)) != 0)
+ printf("%s: timed out waiting for tx_empty "
+ "intr\n", sc->sc_dev.dv_xname);
+ splx(s);
+
+ tx_limit = sc->tx_fifo_depth -
+ dwiic_read(sc, DW_IC_TXFLR);
+ }
}
if (I2C_OP_STOP_P(op) && I2C_OP_WRITE_P(op)) {
Re: ksh: require expression in while loop
On Sun, 04 Jul 2021 23:25:25 +0200, Alexander Hall wrote: > The "... do done" variant has been frequently used by me, and seems to appear > at least three times in install.sub, so if this goes in, please scan the scr > ipts in our tree first, at least for trivial cases. Fair enough, let's just require a non-empty expression but still allow an empty loop body. It would be a good idea to call this out as a portability issue in the ksh manual but that can be done separately. - todd Index: bin/ksh/syn.c === RCS file: /cvs/src/bin/ksh/syn.c,v retrieving revision 1.39 diff -u -p -u -r1.39 syn.c --- bin/ksh/syn.c 24 Apr 2018 08:25:16 - 1.39 +++ bin/ksh/syn.c 4 Jul 2021 22:21:39 - @@ -331,6 +331,8 @@ get_command(int cf) nesting_push(_nesting, c); t = newtp((c == WHILE) ? TWHILE : TUNTIL); t->left = c_list(true); + if (t->left == NULL) + syntaxerr(NULL); t->right = dogroup(); nesting_pop(_nesting); break;
iwx not getting to status: active
I stumbled upon a weird hotel WiFi which never gets to a fully running link with iwx0. I see ifconfig is stuck with: iwx0: flags=808847 mtu 1500 lladdr xx index 1 priority 4 llprio 3 groups: wlan egress media: IEEE802.11 autoselect (HT-MCS11 mode 11n) status: no network ieee80211: nwid MarlinGuest chan 4 bssid 38:ff:36:23:09:a8 68% wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher tkip The network is functional as evidenced by the assorted android and chromeos devices connecting to it. I start with $ doas ifconfig iwx0 inet nwid MarlinGuest wpakey <...> debug autoconf The following gets dumped into dmesg: iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x00, msix iwx0: hw rev 0x350, fw ver 48.1335886879.0, address xx ... iwx0: firmware has detected regulatory domain 'US' (0x5553) iwx0: SCAN -> AUTH iwx0: sending auth to 38:ff:36:23:09:a8 on channel 4 mode 11g iwx0: authentication timed out for 38:ff:36:23:09:a8 iwx0: AUTH -> SCAN iwx0: end active scan ... iwx0: + 38:ff:36:22:ce:b81 +19 54M ess privacy rsn "MarlinGuest" iwx0: + 38:ff:36:23:09:ac 52 +39 54M ess privacy rsn "MarlinGuest" ... iwx0: + f8:e7:1e:1b:85:f84 +22 54M ess privacy rsn "MarlinGuest" ... iwx0: firmware has detected regulatory domain 'US' (0x5553) iwx0: SCAN -> AUTH iwx0: sending auth to 38:ff:36:23:09:ac on channel 52 mode 11a iwx0: AUTH -> ASSOC iwx0: sending assoc_req to 38:ff:36:23:09:ac on channel 52 mode 11a iwx0: ASSOC -> RUN iwx0: associated with 38:ff:36:23:09:ac ssid "MarlinGuest" channel 52 start MCS 0 long preamble long slot time HT enabled iwx0: missed beacon threshold set to 30 beacons, beacon interval is 100 TU iwx0: received msg 1/4 of the 4-way handshake from 38:ff:36:23:09:ac iwx0: sending msg 2/4 of the 4-way handshake to 38:ff:36:23:09:ac iwx0: received msg 3/4 of the 4-way handshake from 38:ff:36:23:09:ac iwx0: sending msg 4/4 of the 4-way handshake to 38:ff:36:23:09:ac I never see "iwx0: sending action to" after this. Now, to send this email I tether to my cell phone which works much better: ... iwx0: + 0a:ab:60:xx:xx:xx9 +42 54M ess privacy rsn "gnezdo" ... iwx0: - 38:ff:36:22:04:b89 +16 54M ess privacy rsn "MarlinGuest"! iwx0: - 38:ff:36:22:ce:b81 +17 54M ess privacy rsn "MarlinGuest"! iwx0: - 38:ff:36:23:09:a84 +20 54M ess privacy rsn "MarlinGuest"! iwx0: - 38:ff:36:23:09:ac 52 +40 54M ess privacy rsn "MarlinGuest"! ... iwx0: - f8:e7:1e:1b:85:f84 +23 54M ess privacy rsn "MarlinGuest"! ... iwx0: firmware has detected regulatory domain 'US' (0x5553) iwx0: SCAN -> AUTH iwx0: sending auth to 0a:ab:60:xx:xx:xx on channel 9 mode 11g iwx0: AUTH -> ASSOC iwx0: sending assoc_req to 0a:ab:60:xx:xx:xx on channel 9 mode 11g iwx0: ASSOC -> RUN iwx0: associated with 0a:ab:60:xx:xx:xx ssid "gnezdo" channel 9 start MCS 0 short preamble short slot time HT enabled iwx0: missed beacon threshold set to 30 beacons, beacon interval is 100 TU iwx0: received msg 1/4 of the 4-way handshake from 0a:ab:60:xx:xx:xx iwx0: sending msg 2/4 of the 4-way handshake to 0a:ab:60:xx:xx:xx iwx0: received msg 3/4 of the 4-way handshake from 0a:ab:60:xx:xx:xx iwx0: sending msg 4/4 of the 4-way handshake to 0a:ab:60:xx:xx:xx iwx0: sending action to 0a:ab:60:xx:xx:xx on channel 9 mode 11n iwx0: sending action to 0a:ab:60:xx:xx:xx on channel 9 mode 11n iwx0: sending action to 0a:ab:60:xx:xx:xx on channel 9 mode 11n Any debugging clues? Thanks Greg
Re: ksh: require expression in while loop
The "... do done" variant has been frequently used by me, and seems to appear at least three times in install.sub, so if this goes in, please scan the scripts in our tree first, at least for trivial cases. /Alexander On July 2, 2021 8:20:44 PM GMT+02:00, "Todd C. Miller" wrote: >Currently, our ksh/sh accepts things like: > >while do done > >which cannot be interrupted via ^C by default. > >If, However, the expression is not empty everything is fine. E.g. > >while :; do done > >Most other shells require a non-empty expression which avoids this >problem (zsh is the outlier here). AT ksh and other shells also >require a non-empty loop body so I've added a check for that too. >So now the expression has to be at least: > >while :; do :; done > >There are other places we could tighten up the syntax checking but >I'll leave that for someone else ;-) > >The new behavior is: > >$ while do done >ksh: syntax error: `do' unexpected > >$ while :; do done >ksh: syntax error: `done' unexpected > >Which is similar to the error produced by bash and AT ksh. >The ksh regress still passes. > > - todd > >Index: bin/ksh/syn.c >=== >RCS file: /cvs/src/bin/ksh/syn.c,v >retrieving revision 1.39 >diff -u -p -u -r1.39 syn.c >--- bin/ksh/syn.c 24 Apr 2018 08:25:16 - 1.39 >+++ bin/ksh/syn.c 2 Jul 2021 18:14:21 - >@@ -331,7 +331,11 @@ get_command(int cf) > nesting_push(_nesting, c); > t = newtp((c == WHILE) ? TWHILE : TUNTIL); > t->left = c_list(true); >+ if (t->left == NULL) >+ syntaxerr(NULL); > t->right = dogroup(); >+ if (t->right == NULL) >+ syntaxerr(NULL); > nesting_pop(_nesting); > break; > >
Re: netlock ktrace nfs
On 02/07/21(Fri) 15:01, Alexander Bluhm wrote: > On Fri, Jul 02, 2021 at 01:05:39PM +0200, Martin Pieuchot wrote: > > Looks good to me. Grabbing solock() after calling pledge_socket() in > > sys_connect(), like it is already done in sys_bind(), means it is ok > > to read this field w/o lock. Is it true? > > I guess it is good enough. If MP rules are followed stictly, every > access without lock or memory barrier is problematic. But here the > SS_DNS flag is set during socket creation. Also racing against > pledge does not look like something we must be aware of. Does good enough means it OK to read so_state w/o serialization mechanism in poll & kqueue handlers? If so that would simplify a lot the work to reduce the contention on the NET_LOCK() in these code paths.
