Re: Let Geode-based systems restart automatically after power failure
Miod,
the Soerkis 5501 doesn't have any power switch. If automatic power on
mode wouldn't have been enabled for them by default, any power failure
would've bricked them.
Gerhard
On Tue, 12 Mar 2013 21:50:57 + Miod Vallat wrote:
> The Geode companion chip, part of which attaches as glxpcib(4), can be
> configured to restart automatically after a power failure, when power is
> restored.
>
> The following diff enables this functionality. Tested on a Lemote
> Fuloong (where it works) and on a Lemote Yeeloong (where this feature is
> disabled in hardware) only. Tests on x86 systems based upon the Geode,
> such as the Soekris 5501 or the ALIX boards, would be appreciated.
>
> Running a kernel with this diff, if you `shutdown -h now', remove the
> power plug, and plug it back, your system should restart immediately,
> unless some other part of the hardware forces this feature to be
> disabled (e.g. on laptops such as the Lemote Yeeloong).
>
> Note that this feature might have already been enabled by the BIOS on
> the Soekrisens or the ALIXes, but this was definitely not the case on
> Fuloongs.
>
> Regardless of your kind system, this diff should not break anything. If
> it does, please let me know.
>
> Miod
>
> Index: glxpcib.c
> ===
> RCS file: /cvs/src/sys/dev/pci/glxpcib.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 glxpcib.c
> --- glxpcib.c 16 Jan 2013 07:17:59 - 1.9
> +++ glxpcib.c 12 Mar 2013 21:30:28 -
> @@ -166,6 +166,15 @@
> #define AMD5536_SMB_CTL2_FREQ0x78 /* 100 kHz */
> #define AMD5536_SMB_CTL3 0x06 /* control 3 */
>
> +/* PMS */
> +#define MSR_LBAR_PMSDIVIL_LBAR_PMS
> +#define MSR_PMS_SIZE0x80
> +#define MSR_PMS_ADDR_MASK 0xff80
> +#define AMD5536_PMS_SSC 0x54
> +#define AMD5536_PMS_SSC_PI 0x0004
> +#define AMD5536_PMS_SSC_CLR_PI 0x0002
> +#define AMD5536_PMS_SSC_SET_PI 0x0001
> +
> /*
> * MSR registers we want to preserve accross suspend/resume
> */
> @@ -275,6 +284,7 @@ glxpcib_attach(struct device *parent, st
> u_int64_t sa;
> struct i2cbus_attach_args iba;
> int i2c = 0;
> + bus_space_handle_t tmpioh;
> #endif
> tc->tc_get_timecount = glxpcib_get_timecount;
> tc->tc_counter_mask = 0x;
> @@ -383,6 +393,18 @@ glxpcib_attach(struct device *parent, st
> iba.iba_name = "iic";
> iba.iba_tag = &sc->sc_smb_ic;
> i2c = 1;
> + }
> +
> + /* Map PMS I/O space and enable the ``Power Immediate'' feature */
> + sa = rdmsr(MSR_LBAR_PMS);
> + if (sa & MSR_LBAR_ENABLE &&
> + !bus_space_map(pa->pa_iot, sa & MSR_PMS_ADDR_MASK,
> + MSR_PMS_SIZE, 0, &tmpioh)) {
> + bus_space_write_4(pa->pa_iot, tmpioh, AMD5536_PMS_SSC,
> + AMD5536_PMS_SSC_SET_PI);
> + bus_space_barrier(pa->pa_iot, tmpioh, AMD5536_PMS_SSC, 4,
> + BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE);
> + bus_space_unmap(pa->pa_iot, tmpioh, MSR_PMS_SIZE);
> }
> #endif /* SMALL_KERNEL */
> pcibattach(parent, self, aux);
>
Re: Soekris net6501 GPIO & LED support
* Matt Dainty [2013-01-14 11:13:59]:
> Attached is a patch that adds soekris(4) which provides access to the
> GPIO and LEDs as implemented by the onboard Xilinx FPGA on the Soekris
> net6501. The driver provides two GPIO buses; one for the 16 real GPIO
> pins exposed on the board, and another which has the LEDs coerced into
> the GPIO framework as output-only pins.
>
> I kept them separate to prevent confusion and make the code slightly
> simpler, if it's preferred to have just one GPIO bus let me know.
>
> It's enabled in the kernel config with:
>
> soekris0 at isa? port 0x680
> gpio*at soekris?
>
> The driver cannot be enabled by default as there's no reliable way to
> detect the hardware, it's just a handful of I/O ports at a known
> address, (GPIO isn't enabled by default in GENERIC so a kernel compile
> is required regardless).
>
> This is what is shown at boot:
>
> soekris0 at isa0 port 0x680/32
> gpio0 at soekris0: 16 pins
> gpio1 at soekris0: 2 pins
>
> I then have the following in /etc/rc.securelevel:
>
> gpioctl -q gpio1 0 set out error_led
> gpioctl -q gpio1 1 set out ready_led
>
> If this driver is acceptable I can send a further patch with man pages.
> Tested on a Soekris net6501 running amd64, LEDs work and I've put
> simple LED and pushbutton circuits on the GPIO pins.
Here's an updated patch for the driver, the only change is in the
*_match() function that is now simplified and much more reliable thanks
to the committed Soekris comBIOS patch to bios(4).
I've still left the GENERIC config unchanged as there's no other gpio(4)
drivers enabled, I'm guessing as general policy.
I'll send a separate patch with the various man page changes.
Matt
--- /dev/null Wed Mar 13 10:27:40 2013
+++ sys/dev/isa/soekris.c Tue Feb 19 08:31:10 2013
@@ -0,0 +1,239 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2013 Matt Dainty
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF MIND, USE, DATA OR PROFITS, WHETHER IN
+ * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+ * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/*
+ * Soekris net6501 GPIO and LEDs as implemented by the onboard Xilinx FPGA
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include
+
+#defineSOEKRIS_BASE0x680 /* Base address of FPGA I/O */
+#defineSOEKRIS_IOSIZE 32 /* I/O region size */
+
+#defineSOEKRIS_NPINS 16 /* Number of Pins */
+#defineSOEKRIS_GPIO_INPUT 0x000 /* Current state of pins */
+#defineSOEKRIS_GPIO_OUTPUT 0x004 /* Set state of output pins */
+#defineSOEKRIS_GPIO_RESET 0x008 /* Reset output pins */
+#defineSOEKRIS_GPIO_SET0x00c /* Set output pins */
+#defineSOEKRIS_GPIO_DIR0x010 /* Direction, set for output */
+
+#defineSOEKRIS_NLEDS 2 /* Number of LEDs */
+#defineSOEKRIS_LED_ERROR 0x01c /* Offset to error LED */
+#defineSOEKRIS_LED_READY 0x01d /* Offset to ready LED */
+
+extern char *hw_vendor, *hw_prod;
+
+const u_int soekris_led_offset[SOEKRIS_NLEDS] = {
+ SOEKRIS_LED_ERROR, SOEKRIS_LED_READY
+};
+
+struct soekris_softc {
+ struct devicesc_dev;
+
+ bus_space_tag_t sc_iot;
+ bus_space_handle_t sc_ioh;
+
+ struct gpio_chipset_tag sc_gpio_gc;
+ gpio_pin_t sc_gpio_pins[SOEKRIS_NPINS];
+
+ /* Fake GPIO device for the LEDs */
+ struct gpio_chipset_tag sc_led_gc;
+ gpio_pin_t sc_led_pins[SOEKRIS_NLEDS];
+};
+
+int soekris_match(struct device *, void *, void *);
+voidsoekris_attach(struct device *, struct device *, void *);
+int soekris_gpio_read(void *, int);
+voidsoekris_gpio_write(void *, int, int);
+voidsoekris_gpio_ctl(void *, int, int);
+int soekris_led_read(void *, int);
+voidsoekris_led_write(void *, int, int);
+voidsoekris_led_ctl(void *, int, int);
+
+struct cfattach soekris_ca = {
+ sizeof(struct soekris_softc), soekris_match, soekris_attach
+};
+
+struct cfdriver soekris_cd = {
+ NULL, "soekris", DV_DULL
+};
+
+int
+soekris_match(struct device *parent, void *match, void *aux)
+{
+ struct isa_attach_args *ia = aux;
+ bus_space_handle_t ioh;
+
+ if (strcmp(hw_vendor, "Soekris Engineering") ||
+ strcmp(hw_prod, "net6501"))
Re: Soekris net6501 GPIO & LED support
* Matt Dainty [2013-03-13 07:56:14]: > > I'll send a separate patch with the various man page changes. And here's the man page changes. Matt --- /dev/null Wed Mar 13 10:31:11 2013 +++ share/man/man4/man4.amd64/soekris.4 Tue Feb 19 08:34:54 2013 @@ -0,0 +1,57 @@ +.\" $OpenBSD$ +.\" +.\" Copyright (c) 2013 Matt Dainty +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate$ +.Dt SOEKRIS 4 amd64 +.Os +.Sh NAME +.Nm soekris +.Nd Soekris net6501 GPIO and LEDs +.Sh SYNOPSIS +.Cd "soekris0 at isa? port 0x680" +.Cd "gpio* at soekris?" +.Sh DESCRIPTION +The +.Nm +driver provides support for the GPIO and LEDs as implemented by the Xilinx +Spartan FGPA integrated into the Soekris net6501 programmed with the default +bitstream found in the BIOS. +.Pp +Two standard +.Xr gpio 4 +interfaces are provided, one for the 16 real pins which can be configured as +either inputs or outputs and another with 2 output-only pins that map +to the error and ready LEDs respectively. +Both may be used with +.Xr gpioctl 8 . +.Sh SEE ALSO +.Xr intro 4 , +.Xr isa 4 , +.Xr gpio 4 , +.Xr gpioctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 5.3 . +.Sh AUTHORS +The +.Nm +driver was written by +.An Matt Dainty Aq m...@bodgit-n-scarper.com . +.Sh BUGS +If the Xilinx FPGA is programmed with a different bistream, the driver will +likely not function. --- /dev/null Wed Mar 13 10:31:27 2013 +++ share/man/man4/man4.i386/soekris.4 Tue Feb 19 08:35:23 2013 @@ -0,0 +1,57 @@ +.\" $OpenBSD$ +.\" +.\" Copyright (c) 2013 Matt Dainty +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate$ +.Dt SOEKRIS 4 i386 +.Os +.Sh NAME +.Nm soekris +.Nd Soekris net6501 GPIO and LEDs +.Sh SYNOPSIS +.Cd "soekris0 at isa? port 0x680" +.Cd "gpio* at soekris?" +.Sh DESCRIPTION +The +.Nm +driver provides support for the GPIO and LEDs as implemented by the Xilinx +Spartan FGPA integrated into the Soekris net6501 programmed with the default +bitstream found in the BIOS. +.Pp +Two standard +.Xr gpio 4 +interfaces are provided, one for the 16 real pins which can be configured as +either inputs or outputs and another with 2 output-only pins that map +to the error and ready LEDs respectively. +Both may be used with +.Xr gpioctl 8 . +.Sh SEE ALSO +.Xr intro 4 , +.Xr isa 4 , +.Xr gpio 4 , +.Xr gpioctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 5.3 . +.Sh AUTHORS +The +.Nm +driver was written by +.An Matt Dainty Aq m...@bodgit-n-scarper.com . +.Sh BUGS +If the Xilinx FPGA is programmed with a different bistream, the driver will +likely not function. --- share/man/man4/man4.amd64/Makefile.orig Tue Jan 8 15:20:04 2013 +++ share/man/man4/man4.amd64/Makefile Tue Jan 8 15:21:00 2013 @@ -1,7 +1,7 @@ # $OpenBSD: Makefile,v 1.15 2012/05/27 12:24:33 jsg Exp $ MAN= amdpcib.4 apm.4 autoconf.4 bios.4 cpu.4 intro.4 ioapic.4 \ - mem.4 mpbios.4 nvram.4 mtrr.4 pctr.4 tcpcib.4 + mem.4 mpbios.4 nvram.4 mtrr.4 pctr.4 soekris.4 tcpcib.4 MLINKS+= mem.4 kmem.4 MANSUBDIR=amd64 --- share/man/man4/man4.i386/Makefile.orig Tue Jan 8 15:19:56 2013 +++ share/man/man4/man4.i386/Makefile Tue Jan 8 15:20:36 2013 @@ -7,7 +7,7 @@ ichpcib.4 intro.4 ioapic.4 \ joy.4 le.4 lms.4 mem.4 mms.4 mpbios.4 mtrr.4 npx.4 nvram.4 \ pas.4 pcibios.4 pctr.4 piixpcib.4 sb.4 \ - sea.4 tcpcib.4 uha.4 wds.4 wdt.4 wss.4 + sea.4 soekris.4 tcpcib.4 uha.4 wds.4 wdt.4 wss.4 MLINKS+= mem.4 kmem.4 MANSUBDIR=i386 --- share/man/man4/gpio.4.orig Tue Jan 8 15:22:00 2013 +++ share/man/man4/gpio.4 Tue Jan 8 15:23
Re: tedu faith(4) and faithd(8)
On 12 March 2013 19:25, Ted Unangst wrote: > On Tue, Mar 12, 2013 at 15:30, Martin Pieuchot wrote: >> Diffs below kill respectively faith(4) and faithd(8) as suggested some >> weeks ago after a submission by dhill. >> >> ok? > > I am, of course, implicitly ok will all deletions of obsolete code. > even subject says so!
Re: IKEd support for ECDSA key authentication?
Reyk,
I've taken the liberty of patching ca.c, crypto.c, ikev2.h, parse.y,
iked.8 and iked.conf.5. I'm no expert on this, but this seems to work
for me. SAs and Flows are established, it hasn't crashed, and I'm
passing data.
Let me know what you think.
Thanks,
-Jason
diff -u sbin/iked.orig/ca.c sbin/iked/ca.c
--- sbin/iked.orig/ca.c Tue Mar 12 18:15:44 2013
+++ sbin/iked/ca.c Wed Mar 13 09:17:37 2013
@@ -346,6 +346,9 @@
case IKEV2_CERT_RSA_KEY:
ret = ca_validate_pubkey(env, &id, ptr, len);
break;
+ case IKEV2_CERT_EC_KEY:
+ ret = ca_validate_pubkey(env, &id, ptr, len);
+ break;
default:
log_debug("%s: unsupported cert type %d", __func__, type);
ret = -1;
@@ -754,6 +757,7 @@
int len;
u_int8_t*d;
RSA *rsa;
+ EC_KEY *eckey;
switch (key->type) {
case EVP_PKEY_RSA:
@@ -776,6 +780,26 @@
id->id_type = IKEV2_CERT_RSA_KEY;
break;
+ case EVP_PKEY_EC:
+ id->id_type = 0;
+ id->id_offset = 0;
+ ibuf_release(id->id_buf);
+
+ if ((eckey = EVP_PKEY_get1_EC_KEY(key)) == NULL)
+ return (-1);
+ if ((len = i2d_ECPrivateKey(eckey, NULL)) <= 0)
+ return (-1);
+ if ((id->id_buf = ibuf_new(NULL, len)) == NULL)
+ return (-1);
+
+ d = ibuf_data(id->id_buf);
+ if (i2d_ECPrivateKey(eckey, &d) != len) {
+ ibuf_release(id->id_buf);
+ return (-1);
+ }
+
+ id->id_type = IKEV2_CERT_EC_KEY;
+ break;
default:
log_debug("%s: unsupported key type %d", __func__, key->type);
return (-1);
@@ -819,6 +843,7 @@
{
BIO *rawcert = NULL;
RSA *rsa = NULL;
+ EC_KEY *eckey = NULL;
EVP_PKEY*peerkey = NULL, *localkey = NULL;
int ret = -1;
FILE*fp = NULL;
@@ -856,12 +881,16 @@
if ((rawcert = BIO_new_mem_buf(data, len)) == NULL)
goto done;
- if ((rsa = d2i_RSAPublicKey_bio(rawcert, NULL)) == NULL)
- goto sslerr;
+ if ((rsa = d2i_RSAPublicKey_bio(rawcert, NULL)) == NULL) {
+ if ((eckey = d2i_EC_PUBKEY_bio(rawcert, NULL )) == NULL)
+ goto sslerr;
+ }
if ((peerkey = EVP_PKEY_new()) == NULL)
goto sslerr;
- if (!EVP_PKEY_set1_RSA(peerkey, rsa))
- goto sslerr;
+ if (!EVP_PKEY_set1_RSA(peerkey, rsa)) {
+ if (!EVP_PKEY_set1_EC_KEY(peerkey, eckey))
+ goto sslerr;
+ }
}
lc_string(idstr);
@@ -892,6 +921,8 @@
EVP_PKEY_free(peerkey);
if (rsa != NULL)
RSA_free(rsa);
+ if (eckey != NULL)
+ EC_KEY_free(eckey);
if (rawcert != NULL)
BIO_free(rawcert);
diff -u sbin/iked.orig/crypto.c sbin/iked/crypto.c
--- sbin/iked.orig/crypto.c Tue Mar 12 18:15:44 2013
+++ sbin/iked/crypto.c Wed Mar 13 09:17:37 2013
@@ -542,6 +542,7 @@
BIO *rawcert = NULL;
X509*cert = NULL;
RSA *rsa = NULL;
+ EC_KEY *eckey = NULL;
EVP_PKEY*pkey = NULL;
ibuf_release(dsa->dsa_keydata);
@@ -576,6 +577,25 @@
if ((pkey = EVP_PKEY_new()) == NULL)
goto sslerr;
if (!EVP_PKEY_set1_RSA(pkey, rsa))
+ goto sslerr;
+
+ dsa->dsa_cert = NULL;
+ dsa->dsa_key = pkey;
+ break;
+ case IKEV2_CERT_EC_KEY:
+ if (dsa->dsa_sign) {
+ if ((eckey = d2i_ECPrivateKey_bio(rawcert,
+ NULL)) == NULL)
+ goto sslerr;
+ } else {
+ if ((eckey = d2i_EC_PUBKEY_bio(rawcert,
+ NULL)) == NULL)
+ goto sslerr;
+ }
+
+ if ((pkey = EVP_PKEY_new()) == NULL)
+ goto sslerr;
+ if (!EVP_PKEY_set1_EC_KEY(pkey, eckey))
goto sslerr;
dsa->dsa_cert = NULL;
diff -u sbin/iked.orig/iked.8 sbin/iked/iked.8
--- sbin/iked.orig/iked.8 Tue Mar 12 18:15:45 2013
+++ sbin/iked/iked.8Wed Mar 13 09:17:37 2013
@@ -46,7 +46,7 @@
.Xr isakmpd 8 .
.Pp
.Nm
-supports mutual authentication using RSA public keys and X.509
certificates.
+supports mutual authentication using RSA, or ECDSA, publ
Re: IKEd support for ECDSA key authentication?
On 2013/03/13 09:52, Jason Hall wrote:
> Reyk,
>
> I've taken the liberty of patching ca.c, crypto.c, ikev2.h, parse.y,
> iked.8 and iked.conf.5. I'm no expert on this, but this seems to
> work for me. SAs and Flows are established, it hasn't crashed, and
> I'm passing data.
>
> Let me know what you think.
Looking at received: headers it looks like you're in the US - if so,
and if my understanding of the restrictions is correct, I don't think
we would be able to use this diff directly.
> Thanks,
> -Jason
>
> diff -u sbin/iked.orig/ca.c sbin/iked/ca.c
> --- sbin/iked.orig/ca.c Tue Mar 12 18:15:44 2013
> +++ sbin/iked/ca.cWed Mar 13 09:17:37 2013
> @@ -346,6 +346,9 @@
> case IKEV2_CERT_RSA_KEY:
> ret = ca_validate_pubkey(env, &id, ptr, len);
> break;
> + case IKEV2_CERT_EC_KEY:
> + ret = ca_validate_pubkey(env, &id, ptr, len);
> + break;
> default:
> log_debug("%s: unsupported cert type %d", __func__, type);
> ret = -1;
> @@ -754,6 +757,7 @@
> int len;
> u_int8_t*d;
> RSA *rsa;
> + EC_KEY *eckey;
>
> switch (key->type) {
> case EVP_PKEY_RSA:
> @@ -776,6 +780,26 @@
>
> id->id_type = IKEV2_CERT_RSA_KEY;
> break;
> + case EVP_PKEY_EC:
> + id->id_type = 0;
> + id->id_offset = 0;
> + ibuf_release(id->id_buf);
> +
> + if ((eckey = EVP_PKEY_get1_EC_KEY(key)) == NULL)
> + return (-1);
> + if ((len = i2d_ECPrivateKey(eckey, NULL)) <= 0)
> + return (-1);
> + if ((id->id_buf = ibuf_new(NULL, len)) == NULL)
> + return (-1);
> +
> + d = ibuf_data(id->id_buf);
> + if (i2d_ECPrivateKey(eckey, &d) != len) {
> + ibuf_release(id->id_buf);
> + return (-1);
> + }
> +
> + id->id_type = IKEV2_CERT_EC_KEY;
> + break;
> default:
> log_debug("%s: unsupported key type %d", __func__, key->type);
> return (-1);
> @@ -819,6 +843,7 @@
> {
> BIO *rawcert = NULL;
> RSA *rsa = NULL;
> + EC_KEY *eckey = NULL;
> EVP_PKEY*peerkey = NULL, *localkey = NULL;
> int ret = -1;
> FILE*fp = NULL;
> @@ -856,12 +881,16 @@
> if ((rawcert = BIO_new_mem_buf(data, len)) == NULL)
> goto done;
>
> - if ((rsa = d2i_RSAPublicKey_bio(rawcert, NULL)) == NULL)
> - goto sslerr;
> + if ((rsa = d2i_RSAPublicKey_bio(rawcert, NULL)) == NULL) {
> + if ((eckey = d2i_EC_PUBKEY_bio(rawcert, NULL )) == NULL)
> + goto sslerr;
> + }
> if ((peerkey = EVP_PKEY_new()) == NULL)
> goto sslerr;
> - if (!EVP_PKEY_set1_RSA(peerkey, rsa))
> - goto sslerr;
> + if (!EVP_PKEY_set1_RSA(peerkey, rsa)) {
> + if (!EVP_PKEY_set1_EC_KEY(peerkey, eckey))
> + goto sslerr;
> + }
> }
>
> lc_string(idstr);
> @@ -892,6 +921,8 @@
> EVP_PKEY_free(peerkey);
> if (rsa != NULL)
> RSA_free(rsa);
> + if (eckey != NULL)
> + EC_KEY_free(eckey);
> if (rawcert != NULL)
> BIO_free(rawcert);
>
> diff -u sbin/iked.orig/crypto.c sbin/iked/crypto.c
> --- sbin/iked.orig/crypto.c Tue Mar 12 18:15:44 2013
> +++ sbin/iked/crypto.cWed Mar 13 09:17:37 2013
> @@ -542,6 +542,7 @@
> BIO *rawcert = NULL;
> X509*cert = NULL;
> RSA *rsa = NULL;
> + EC_KEY *eckey = NULL;
> EVP_PKEY*pkey = NULL;
>
> ibuf_release(dsa->dsa_keydata);
> @@ -576,6 +577,25 @@
> if ((pkey = EVP_PKEY_new()) == NULL)
> goto sslerr;
> if (!EVP_PKEY_set1_RSA(pkey, rsa))
> + goto sslerr;
> +
> + dsa->dsa_cert = NULL;
> + dsa->dsa_key = pkey;
> + break;
> + case IKEV2_CERT_EC_KEY:
> + if (dsa->dsa_sign) {
> + if ((eckey = d2i_ECPrivateKey_bio(rawcert,
> + NULL)) == NULL)
> + goto sslerr;
> + } else {
> + if ((eckey = d2i_EC_PUBKEY_bio(rawcert,
> + NULL)) == NULL)
> + goto sslerr;
> + }
> +
> + if ((pkey = EVP_PKEY_new()) == NULL)
> + goto sslerr;
> + if (!EVP_PKEY_set1_EC_KEY(pkey, eckey))
> goto sslerr;
>
> dsa->dsa_cert = NULL;
> diff -u sbin/iked.orig/ike
Re: IKEd support for ECDSA key authentication?
Stu, I am in the US. While I am no lawyer, I believe the export resctrictions are on the actual cryptography software, namely OpenSSL, which is developed in your neck of the woods. As my patch doesn't provide any actual cryptography, just using existing methods, it should be ok. But, as I said, I'm not a lawyer. If you can't use it, I greatly appreciate if someone not in the US would write something similar. Thanks, -Jason On 03/13/13 10:10, Stuart Henderson wrote: Looking at received: headers it looks like you're in the US - if so, and if my understanding of the restrictions is correct, I don't think we would be able to use this diff directly.
Add family 15h devices, km(4) sensor.
So someone sent me a new toy, this adds the k15 PCIe devices. Names are
copied from the equivalent k14.. because I'm not sure wherefrom they
were originally sourced.
For km(4), it seems the temperature calculations are off.. according to
the BKDG curtmp doesn't seem to actually reflect the real temperature,
but some sort of value in relation to the max temperature.
On my system is shows around <10degC when idle, reaching 40degC when all
cores are under load. So.. the value increases! :P
The FreeBSD driver has all sorts of workarounds I'm not sure we want,
but it shows similar temperatures values.
ok?
-Bryan.
Index: dev/pci/km.c
===
RCS file: /cvs/src/sys/dev/pci/km.c,v
retrieving revision 1.5
diff -u -p -u -r1.5 km.c
--- dev/pci/km.c31 May 2011 00:19:55 - 1.5
+++ dev/pci/km.c12 Mar 2013 22:19:16 -
@@ -70,7 +70,8 @@ struct cfdriver km_cd = {
static const struct pci_matchid km_devices[] = {
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_10_MISC },
{ PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_11_MISC },
- { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_14_MISC }
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_14_MISC },
+ { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_AMD64_15_MISC }
};
Index: dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1669
diff -u -p -u -r1.1669 pcidevs
--- dev/pci/pcidevs 8 Feb 2013 07:58:18 - 1.1669
+++ dev/pci/pcidevs 12 Mar 2013 22:19:16 -
@@ -693,6 +693,12 @@ product AMD AMD64_14_PCIE_20x1513 AMD64
product AMD AMD64_14_PCIE_30x1514 AMD64 14h PCIE
product AMD AMD64_14_PCIE_40x1515 AMD64 14h PCIE
product AMD AMD64_14_PCIE_50x1516 AMD64 14h PCIE
+product AMD AMD64_15_LINK 0x1600 AMD64 15h Link Cfg
+product AMD AMD64_15_ADDR 0x1601 AMD64 15h Address Map
+product AMD AMD64_15_DRAM 0x1602 AMD64 15h DRAM Cfg
+product AMD AMD64_15_MISC 0x1603 AMD64 15h Misc Cfg
+product AMD AMD64_15_CPU_PM0x1604 AMD64 15h CPU Power
+product AMD AMD64_15_HB0x1605 AMD64 15h Host
product AMD AMD64_14_LINK 0x1700 AMD64 14h Link Cfg
product AMD AMD64_14_ADDR 0x1701 AMD64 14h Address Map
product AMD AMD64_14_DRAM 0x1702 AMD64 14h DRAM Cfg
Re: tedu faith(4) and faithd(8)
2013/3/12 Martin Pieuchot > Diffs below kill respectively faith(4) and faithd(8) as suggested some > weeks ago after a submission by dhill. > > Should this teduing include removal from : distrib/sets/lists/base/mi distrib/sets/lists/man/mi ..also, or does that always fall on todd/theo to sync? -- May the most significant bit of your life be positive.
pfctl(8) manual: list "-s info" counters
already discussed with jmc, does anyone have comments regarding the descriptions of counters? Index: pfctl.8 === RCS file: /cvs/src/sbin/pfctl/pfctl.8,v retrieving revision 1.156 diff -u -p -r1.156 pfctl.8 --- pfctl.8 29 Sep 2012 01:41:01 - 1.156 +++ pfctl.8 13 Mar 2013 16:26:43 - @@ -345,7 +345,7 @@ Show the filter parameters specified by .Ar modifier (may be abbreviated): .Pp -.Bl -tag -width x -compact +.Bl -tag -width xx -compact .It Fl s Cm queue Show the currently loaded queue rules. When used together with @@ -422,6 +422,45 @@ can be used to select an interface or a .It Fl s Cm all Show all of the above, except for the lists of interfaces and operating system fingerprints. +.El +.Pp +Counters shown with +.Fl s Cm info +are: +.Pp +.Bl -tag -width xx -compact +.It match +explicit rule match +.It bad-offset +currently unused +.It fragment +invalid fragments dropped +.It short +short packets dropped +.It normalize +dropped by normalizer: illegal packets +.It memory +memory could not be allocated +.It bad-timestamp +bad TCP timestamp; RFC 1323 +.It congestion +network interface queue congested +.It ip-option +bad IP/IPv6 options +.It proto-cksum +invalid protocol checksum +.It state-mismatch +packet was associated with a state entry, but sequence numbers did not match +.It state-insert +state insertion failure +.It state-limit +configured state limit was reached +.It src-limit +source node/connection limit +.It synproxy +dropped by synproxy +.It translate +no free ports in translation port range .El .It Fl T Ar command Op Ar address ... Specify the
Re: find(1) manpage bug
Alexander Hall writes: > find(1) claims -follow is the same as -H, which is wrong. Indeed, but this confusion is present twice in the manpage. > OK? > > /Alexander Index: find.1 === RCS file: /cvs/src/usr.bin/find/find.1,v retrieving revision 1.85 diff -u -p -r1.85 find.1 --- find.1 5 Jan 2012 13:16:10 - 1.85 +++ find.1 13 Mar 2013 17:30:33 - @@ -273,7 +273,7 @@ flags specified exactly match those of t .It Ic -follow This primary always evaluates to true. The same as specifying the -.Fl H +.Fl L option. .Pp .It Ic -fstype Ar type @@ -633,7 +633,7 @@ primary was inspired by GNU find. .Pp Historically, the .Fl d , -.Fl H , +.Fl L , and .Fl x options were implemented using the primaries
Re: find(1) manpage bug
On 03/13/13 19:17, Jérémie Courrèges-Anglas wrote: Alexander Hall writes: find(1) claims -follow is the same as -H, which is wrong. Indeed, but this confusion is present twice in the manpage. I don't know the history myself, but I can only assume the switch went wrong in r1.14, where it was changed from '-s' to '-H', the former of which I cannot see any trace of in the sources at all. Unless someone has opinions on the historical correctness, I'll commit with this bit too. More OK's are obviously still fine as well. :-) /Alexander OK? /Alexander Index: find.1 === RCS file: /cvs/src/usr.bin/find/find.1,v retrieving revision 1.85 diff -u -p -r1.85 find.1 --- find.1 5 Jan 2012 13:16:10 - 1.85 +++ find.1 13 Mar 2013 17:30:33 - @@ -273,7 +273,7 @@ flags specified exactly match those of t .It Ic -follow This primary always evaluates to true. The same as specifying the -.Fl H +.Fl L option. .Pp .It Ic -fstype Ar type @@ -633,7 +633,7 @@ primary was inspired by GNU find. .Pp Historically, the .Fl d , -.Fl H , +.Fl L , and .Fl x options were implemented using the primaries
Re: Add family 15h devices, km(4) sensor.
On Wed, Mar 13, 2013 at 10:51:12AM -0400, Brynet wrote: > So someone sent me a new toy, this adds the k15 PCIe devices. Names are > copied from the equivalent k14.. because I'm not sure wherefrom they > were originally sourced. > > For km(4), it seems the temperature calculations are off.. according to > the BKDG curtmp doesn't seem to actually reflect the real temperature, > but some sort of value in relation to the max temperature. > > On my system is shows around <10degC when idle, reaching 40degC when all > cores are under load. So.. the value increases! :P I've the same problem with km and 14h. > > The FreeBSD driver has all sorts of workarounds I'm not sure we want, > but it shows similar temperatures values. > > ok? > > -Bryan. OpenBSD 5.3 (GENERIC.MP) #62: Tue Mar 12 18:21:20 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8566591488 (8169MB) avail mem = 831602 (7930MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb0d0 (65 entries) bios0: vendor American Megatrends Inc. version "0901" date 09/30/2012 bios0: ASUSTeK COMPUTER INC. F1A55 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT acpi0: wakeup devices SBAZ(S4) PS2K(S4) PS2M(S4) UAR1(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4) RLAN(S4) PE22(S4) PE23(S4) PCE2(S4) PCE4(S4) P0PC(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2700.25 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2699.94 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PE20) acpiprt2 at acpi0: bus 4 (PE21) acpiprt3 at acpi0: bus -1 (PE22) acpiprt4 at acpi0: bus 5 (PE23) acpiprt5 at acpi0: bus -1 (BR13) acpiprt6 at acpi0: bus -1 (PCE2) acpiprt7 at acpi0: bus -1 (PCE4) acpiprt8 at acpi0: bus 1 (P0PC) acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpibtn0 at acpi0: PWRB cpu0: 2700 MHz: speeds: 2700 2400 2200 2000 1800 1400 1100 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 12h Host" rev 0x00 ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed t10.ATA_ST3250310AS_5RY0ZTKS sd0: 238475MB, 512 bytes/sector, 488397168 sectors sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c500142c3ef3 sd1: 476940MB, 512 bytes/sector, 976773168 sectors sd2 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed naa.5000c5004fab5f8b sd2: 953869MB, 512 bytes/sector, 1953525168 sectors ohci0 at pci0 dev 18 function 0 "AMD Hudson-2 USB" rev 0x11: apic 3 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 3 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "AMD Hudson-2 USB" rev 0x11: apic 3 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 3 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 "AMD Hudson-2 SMBus" rev 0x13: polling iic0 at piixpm0 iic0: addr 0x20 01=0d 02=17 03=26 04=8c 05=8c 06=8c 07=8c 08=00 09=00 0a=10 0b=10 0c=10 0d=10 0e=07 0f=8b 10=00 11=00 12=00 13=00 14=00 15=0f 16=19 17=20 18=e0 19=fb 1a=a8 1b=a3 1c=ac 1d=80 1e=04 1f=03 20=09 21=09 22=09 23=09 24=37 3e=a3 words 00=ff0d 01=0d17 02=1726 03=268c 04=8c8c 05=8c8c 06=8c8c 07=8c00 spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 spdmem1 at iic0 addr 0x51: 4
Bug (Minor) - iked print_policy() prints EAP ikeauth type when RSA specified
Reyk, When 'rsa' is specified for ikeauth in iked.conf, parse.y -> print_policy() reports 'eap ""' where ### is a random number, observed to be between 1 and 255. If 'rsa' is not specified in iked.conf, print_policy() correctly reports 'rsa'. This is seen when running "iked -dv". This doesn't seem to affect operations, just confusing in the debug output. Thanks, -Jason
Re: find(1) manpage bug
Alexander Hall writes: > On 03/13/13 19:17, Jérémie Courrèges-Anglas wrote: >> Alexander Hall writes: >> >>> find(1) claims -follow is the same as -H, which is wrong. >> >> Indeed, but this confusion is present twice in the manpage. > > I don't know the history myself, but I can only assume the switch went wrong > in r1.14, where it was changed from '-s' to '-H', the former of which I cannot > see any trace of in the sources at all. It seems like '-s' was actually replaced by '-h': http://svnweb.freebsd.org/csrg/usr.bin/find/main.c?r1=51832&r2=53779 which then was replaced by '-L': http://svnweb.freebsd.org/csrg/usr.bin/find/main.c?r1=61995&r2=66587 NetBSD find got an unrelated '-s' switch (for 'sort') option after the fork. > Unless someone has opinions on the historical correctness, I'll commit with > this bit too. > > More OK's are obviously still fine as well. :-) > > /Alexander > >> >>> OK? >>> >>> /Alexander >> >> Index: find.1 >> === >> RCS file: /cvs/src/usr.bin/find/find.1,v >> retrieving revision 1.85 >> diff -u -p -r1.85 find.1 >> --- find.1 5 Jan 2012 13:16:10 - 1.85 >> +++ find.1 13 Mar 2013 17:30:33 - >> @@ -273,7 +273,7 @@ flags specified exactly match those of t >> .It Ic -follow >> This primary always evaluates to true. >> The same as specifying the >> -.Fl H >> +.Fl L >> option. >> .Pp >> .It Ic -fstype Ar type >> @@ -633,7 +633,7 @@ primary was inspired by GNU find. >> .Pp >> Historically, the >> .Fl d , >> -.Fl H , >> +.Fl L , >> and >> .Fl x >> options were implemented using the primaries >> > -- Jérémie Courrèges-Anglas GPG Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: PF divert(4) bugfix: recalculate checksums on packet reinjection
On Mon, Mar 04, 2013 at 11:37:32PM -0500, Lawrence Teo wrote:
> Brief background: divert(4) sockets can be used to send packets to a
> userspace program. The program can inspect the packets and decide to
> either reinject them back into the kernel or drop them.
>
> According to the divert(4) man page, "The packets' checksums are
> recalculated upon reinjection." This makes sense, because the userspace
> program could have modified the packet.
>
> However, in my tests, I found that the checksums are not actually
> recalculated upon reinjection. I ran into this bug when trying to use
> divert-packet PF rules together with nat-to and rdr-to, e.g.:
>
> match out on em5 inet nat-to (em5:0)
> pass out on em5 proto tcp to port 80 divert-packet port 700
> pass in on em5 proto tcp to port 22 divert-packet port 700 rdr-to
> 192.168.30.8
>
> With the above rules, inbound packets would drop and "netstat -p ip -s"
> shows that "bad header checksums" consistently increments by one for
> every inbound packet.
>
> The diff below fixes this bug by making divert(4) recalculate the IP(v4)
> and TCP/UDP/ICMP/ICMPv6 checksums of reinjected packets on both IPv4 and
> IPv6 (done with a ton of help and feedback from blambert@ who reviewed
> many versions of this diff, thank you!).
>
> If you are using divert(4), could you please test this diff to ensure
> that it does not break your setup? Note that this diff only applies to
> divert-packet PF rules, not divert-to/divert-reply.
>
> I am also looking for feedback from developers to review the approach
> and code that was used to fix this bug.
This revised diff uses ip6_lasthdr() to walk the IPv6 header chain,
which makes the diff a lot shorter and simpler.
The IPv4 part remains unchanged from the original diff that I sent last
week.
Thank you to those who have tested so far; more tests and feedback
welcome!
Lawrence
Index: netinet/ip_divert.c
===
RCS file: /cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.10
diff -u -p -r1.10 ip_divert.c
--- netinet/ip_divert.c 21 Oct 2012 13:06:03 - 1.10
+++ netinet/ip_divert.c 12 Mar 2013 03:50:15 -
@@ -37,6 +37,9 @@
#include
#include
#include
+#include
+#include
+#include
struct inpcbtable divbtable;
struct divstat divstat;
@@ -83,8 +86,12 @@ divert_output(struct mbuf *m, ...)
struct sockaddr_in *sin;
struct socket *so;
struct ifaddr *ifa;
- int s, error = 0;
+ int s, error = 0, p_hdrlen = 0;
va_list ap;
+ struct ip *ip;
+ u_int16_t off, csum = 0;
+ u_int8_t nxt;
+ size_t p_off = 0;
va_start(ap, m);
inp = va_arg(ap, struct inpcb *);
@@ -102,15 +109,68 @@ divert_output(struct mbuf *m, ...)
sin = mtod(nam, struct sockaddr_in *);
so = inp->inp_socket;
+ /* Do basic sanity checks. */
+ if (m->m_pkthdr.len < sizeof(struct ip))
+ goto fail;
+ if ((m = m_pullup(m, sizeof(struct ip))) == NULL) {
+ /* m_pullup() has freed the mbuf, so just return. */
+ divstat.divs_errors++;
+ return (ENOBUFS);
+ }
+ ip = mtod(m, struct ip *);
+ if (ip->ip_v != IPVERSION)
+ goto fail;
+ off = ip->ip_hl << 2;
+ if (off < sizeof(struct ip) || ntohs(ip->ip_len) < off ||
+ m->m_pkthdr.len < ntohs(ip->ip_len))
+ goto fail;
+
+ /*
+* Recalculate IP and protocol checksums since the userspace application
+* may have modified the packet prior to reinjection.
+*/
+ ip->ip_sum = 0;
+ ip->ip_sum = in_cksum(m, off);
+ nxt = ip->ip_p;
+ switch (ip->ip_p) {
+ case IPPROTO_TCP:
+ p_hdrlen = sizeof(struct tcphdr);
+ p_off = offsetof(struct tcphdr, th_sum);
+ break;
+ case IPPROTO_UDP:
+ p_hdrlen = sizeof(struct udphdr);
+ p_off = offsetof(struct udphdr, uh_sum);
+ break;
+ case IPPROTO_ICMP:
+ p_hdrlen = sizeof(struct icmp);
+ p_off = offsetof(struct icmp, icmp_cksum);
+ nxt = 0;
+ break;
+ default:
+ /* nothing */
+ break;
+ }
+ if (p_hdrlen) {
+ if (m->m_pkthdr.len < off + p_hdrlen)
+ goto fail;
+
+ if ((error = m_copyback(m, off + p_off, sizeof(csum), &csum,
M_NOWAIT)))
+ goto fail;
+ csum = in4_cksum(m, nxt, off, m->m_pkthdr.len - off);
+ if (ip->ip_p == IPPROTO_UDP && csum == 0)
+ csum = 0x;
+ if ((error = m_copyback(m, off + p_off, sizeof(csum), &csum,
M_NOWAIT)))
+ goto fail;
+ }
+
m->m_pkthdr.pf.flags |= PF_TAG_DIVERTED_PACKET;
if (sin->sin_addr.s_addr != INADDR_
