use DRM_IOCTL_GET_PCIINFO in libdrm
Support libdrm functions required for Mesa versions >= 13.
On linux this information is pulled out of a psuedo filesystem, here the
new DRM_IOCTL_GET_PCIINFO ioctl is used for the same.
Only primary drm nodes are handled, render and control nodes which we
don't have aren't. This also only handles devices with PCI ids.
drmGetMinorNameForFD() based on code the Mesa loader used to have.
diff --git xf86drm.c xf86drm.c
index 3c2c5d4..03fe257 100644
--- xf86drm.c
+++ xf86drm.c
@@ -62,6 +62,10 @@
#endif
#include
+#ifdef __OpenBSD__
+#include
+#endif
+
/* Not all systems have MAP_FAILED defined */
#ifndef MAP_FAILED
#define MAP_FAILED ((void *)-1)
@@ -2851,7 +2855,25 @@ static char *drmGetMinorNameForFD(int fd, int type)
out_close_dir:
closedir(sysdir);
#else
-#warning "Missing implementation of drmGetMinorNameForFD"
+struct stat sbuf;
+unsigned int maj, min;
+char buf[0x40];
+int n;
+
+if (fstat(fd, ))
+return NULL;
+
+maj = major(sbuf.st_rdev);
+min = minor(sbuf.st_rdev);
+
+if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+return NULL;
+
+n = snprintf(buf, sizeof(buf), DRM_DEV_NAME, DRM_DIR_NAME, min);
+if (n == -1 || n >= sizeof(buf))
+return NULL;
+
+return strdup(buf);
#endif
return NULL;
}
@@ -2887,6 +2909,8 @@ static int drmParseSubsystemType(int maj, int min)
return DRM_BUS_PCI;
return -EINVAL;
+#elif defined(__OpenBSD__)
+ return DRM_BUS_PCI;
#else
#warning "Missing implementation of drmParseSubsystemType"
return -EINVAL;
@@ -2929,6 +2953,26 @@ static int drmParsePciBusInfo(int maj, int min,
drmPciBusInfoPtr info)
info->func = func;
return 0;
+#elif defined(__OpenBSD__)
+struct drm_pciinfo pinfo;
+int fd;
+
+fd = drmOpenMinor(min, 0, DRM_NODE_PRIMARY);
+if (fd < 0)
+return -errno;
+
+if (drmIoctl(fd, DRM_IOCTL_GET_PCIINFO, )) {
+close(fd);
+return -errno;
+}
+close(fd);
+
+info->domain = pinfo.domain;
+info->bus = pinfo.bus;
+info->dev = pinfo.dev;
+info->func = pinfo.func;
+
+return 0;
#else
#warning "Missing implementation of drmParsePciBusInfo"
return -EINVAL;
@@ -3004,6 +3048,37 @@ static int drmParsePciDeviceInfo(const char *d_name,
device->subdevice_id = config[46] | (config[47] << 8);
return 0;
+#elif defined(__OpenBSD__)
+struct drm_pciinfo pinfo;
+char buf[0x40];
+int fd, n;
+
+n = snprintf(buf, sizeof(buf), "%s/%s", DRM_DIR_NAME, d_name);
+if (n == -1 || n >= sizeof(buf))
+return -errno;
+
+#ifndef X_PRIVSEP
+fd = open(buf, O_RDWR, 0);
+#else
+fd = priv_open_device(buf);
+#endif
+
+if (fd < 0)
+return -errno;
+
+if (drmIoctl(fd, DRM_IOCTL_GET_PCIINFO, )) {
+close(fd);
+return -errno;
+}
+close(fd);
+
+device->vendor_id = pinfo.vendor_id;
+device->device_id = pinfo.device_id;
+device->revision_id = pinfo.revision_id;
+device->subvendor_id = pinfo.subvendor_id;
+device->subdevice_id = pinfo.subdevice_id;
+
+return 0;
#else
#warning "Missing implementation of drmParsePciDeviceInfo"
return -EINVAL;
@@ -3117,6 +3192,46 @@ static void drmFoldDuplicatedDevices(drmDevicePtr
local_devices[], int count)
*/
int drmGetDevice(int fd, drmDevicePtr *device)
{
+#ifdef __OpenBSD__
+drmDevicePtr d;
+struct stat sbuf;
+char node[PATH_MAX + 1];
+char d_name[PATH_MAX + 1];
+int maj, min, n;
+int ret;
+int max_count = 1;
+
+if (fd == -1 || device == NULL)
+return -EINVAL;
+
+if (fstat(fd, ))
+return -errno;
+
+maj = major(sbuf.st_rdev);
+min = minor(sbuf.st_rdev);
+
+if (maj != DRM_MAJOR || !S_ISCHR(sbuf.st_mode))
+return -EINVAL;
+
+n = snprintf(d_name, PATH_MAX, "drm%d", min);
+if (n == -1 || n >= PATH_MAX)
+ return -errno;
+
+n = snprintf(node, PATH_MAX, DRM_DEV_NAME, DRM_DIR_NAME, min);
+if (n == -1 || n >= PATH_MAX)
+ return -errno;
+if (stat(node, ))
+return -EINVAL;
+
+ret = drmProcessPciDevice(, d_name, node, DRM_NODE_PRIMARY,
+ maj, min, true);
+if (ret)
+return ret;
+
+*device = d;
+
+return 0;
+#else
drmDevicePtr *local_devices;
drmDevicePtr d;
DIR *sysdir;
@@ -3224,6 +3339,7 @@ free_devices:
free_locals:
free(local_devices);
return ret;
+#endif
}
/**
Re: ospfd - add metric and type to print_redistribute
On 2016/11/19 10:06, Remi Locherer wrote: > Hi, > > In the output of ospfd -nv I miss metric and type for the redistribute > statement. The below patch adds this. OK with me. This prints the values when they're at defaults as well, but I don't think that is a problem.
add a new DRM_IOCTL_GET_PCIINFO ioctl
To pull pci information from the kernel for drm devices we need a common
drm ioctl. This is a requirement for implementing functions in libdrm
which are used by Mesa >= 13.
To not clash with drm headers this is added via pciio.h at kettenis'
suggestion.
The ioctl number reuses that of DRM_IOCTL_ADD_MAP, a DRI1 ioctl
we dropped support for, to avoid using a number that might be later
used in linux.
The currently unused values in the latest linux drm.h seem to be
0x0e
0x0f
0x2f
0x3b
0x3c
0x3d
0x3e
0xbf - 0xff ?
(driver specific ioctls 0x40 -> 0x9f)
Index: dev/pci/drm/drm_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_drv.c,v
retrieving revision 1.149
diff -u -p -r1.149 drm_drv.c
--- dev/pci/drm/drm_drv.c 15 Sep 2016 02:00:17 - 1.149
+++ dev/pci/drm/drm_drv.c 19 Nov 2016 07:12:06 -
@@ -50,6 +50,7 @@
#include
#include /* for TIOCSGRP */
#include
+#include /* for DRM_IOCTL_GET_PCIINFO */
#include
#include
@@ -81,6 +82,7 @@ intdrm_version(struct drm_device *, vo
int drm_setversion(struct drm_device *, void *, struct drm_file *);
int drm_getmagic(struct drm_device *, void *, struct drm_file *);
int drm_authmagic(struct drm_device *, void *, struct drm_file *);
+int drm_getpciinfo(struct drm_device *, void *, struct drm_file *);
int drm_file_cmp(struct drm_file *, struct drm_file *);
SPLAY_PROTOTYPE(drm_file_tree, drm_file, link, drm_file_cmp);
@@ -120,6 +122,8 @@ static struct drm_ioctl_desc drm_ioctls[
DRM_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_setsareactx,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_getsareactx, DRM_AUTH),
#else
+ DRM_IOCTL_DEF(DRM_IOCTL_GET_PCIINFO, drm_getpciinfo, 0),
+
DRM_IOCTL_DEF(DRM_IOCTL_SET_SAREA_CTX, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_GET_SAREA_CTX, drm_noop, DRM_AUTH),
#endif
@@ -254,11 +258,12 @@ pledge_ioctl_drm(struct proc *p, long co
if (ioctl->flags & DRM_RENDER_ALLOW)
return 0;
+ switch (com) {
+ case DRM_IOCTL_GET_PCIINFO:
/*
* These are dangerous, but we have to allow them until we
* have prime/dma-buf support.
*/
- switch (com) {
case DRM_IOCTL_GET_MAGIC:
case DRM_IOCTL_GEM_OPEN:
return 0;
@@ -1345,5 +1350,23 @@ int drm_pcie_get_speed_cap_mask(struct d
DRM_INFO("probing gen 2 caps for device 0x%04x:0x%04x = %x/%x\n",
PCI_VENDOR(id), PCI_PRODUCT(id), lnkcap, lnkcap2);
+ return 0;
+}
+
+int
+drm_getpciinfo(struct drm_device *dev, void *data, struct drm_file *file_priv)
+{
+ struct drm_pciinfo *info = data;
+
+ info->domain = 0;
+ info->bus = dev->pdev->bus->number;
+ info->dev = PCI_SLOT(dev->pdev->devfn);
+ info->func = PCI_FUNC(dev->pdev->devfn);
+ info->vendor_id = dev->pdev->vendor;
+ info->device_id = dev->pdev->device;
+ info->subvendor_id = dev->pdev->subsystem_vendor;
+ info->subdevice_id = dev->pdev->subsystem_device;
+ info->revision_id = 0;
+
return 0;
}
Index: sys/pciio.h
===
RCS file: /cvs/src/sys/sys/pciio.h,v
retrieving revision 1.7
diff -u -p -r1.7 pciio.h
--- sys/pciio.h 5 Sep 2010 18:14:33 - 1.7
+++ sys/pciio.h 19 Nov 2016 07:12:06 -
@@ -60,6 +60,18 @@ struct pci_vga {
int pv_decode;
};
+struct drm_pciinfo {
+ uint16_tdomain;
+ uint8_t bus;
+ uint8_t dev;
+ uint8_t func;
+ uint16_tvendor_id;
+ uint16_tdevice_id;
+ uint16_tsubvendor_id;
+
ospfd - add metric and type to print_redistribute
Hi,
In the output of ospfd -nv I miss metric and type for the redistribute
statement. The below patch adds this.
Sample output:
remi@mistral:..in/ospfd% doas obj/ospfd -nv
WARNING: IP forwarding NOT enabled, running as stub router
router-id 10.10.10.1
fib-update yes
rfc1583compat yes
stub router yes
redistribute rtlabel r1 set { metric 200 type 1 }
^
redistribute rtlabel r2 set { metric 100 type 1 }
^
spf-delay msec 1000
spf-holdtime msec 5000
area 0.0.0.0 {
interface pair0:10.0.0.1 {
metric 500
retransmit-interval 5
router-dead-time 40
hello-interval 10
router-priority 1
transmit-delay 1
auth-type none
}
}
Remi
Index: printconf.c
===
RCS file: /cvs/src/usr.sbin/ospfd/printconf.c,v
retrieving revision 1.16
diff -u -p -r1.16 printconf.c
--- printconf.c 6 Mar 2013 15:43:23 - 1.16
+++ printconf.c 19 Nov 2016 08:46:46 -
@@ -76,24 +76,27 @@ print_redistribute(struct redist_list *r
SIMPLEQ_FOREACH(r, rlh, entry) {
switch (r->type & ~REDIST_NO) {
case REDIST_STATIC:
- printf("%sredistribute static\n", print_no(r->type));
+ printf("%sredistribute static ", print_no(r->type));
break;
case REDIST_CONNECTED:
- printf("%sredistribute connected\n", print_no(r->type));
+ printf("%sredistribute connected ", print_no(r->type));
break;
case REDIST_LABEL:
- printf("%sredistribute rtlabel %s\n",
+ printf("%sredistribute rtlabel %s ",
print_no(r->type), rtlabel_id2name(r->label));
break;
case REDIST_ADDR:
- printf("%sredistribute %s/%d\n",
+ printf("%sredistribute %s/%d ",
print_no(r->type), inet_ntoa(r->addr),
mask2prefixlen(r->mask.s_addr));
break;
case REDIST_DEFAULT:
- printf("%sredistribute default\n", print_no(r->type));
+ printf("%sredistribute default ", print_no(r->type));
break;
}
+ printf("set { metric %d type %d }\n",
+ (r->metric & LSA_METRIC_MASK),
+ ((r->metric & LSA_ASEXT_E_FLAG) == 0 ? 1 : 2));
}
}
Re: ospfd - add metric and type to print_redistribute
On Sat, Nov 19, 2016 at 11:38:56AM +, Stuart Henderson wrote: > On 2016/11/19 10:06, Remi Locherer wrote: > > Hi, > > > > In the output of ospfd -nv I miss metric and type for the redistribute > > statement. The below patch adds this. > > OK with me. This prints the values when they're at defaults as well, > but I don't think that is a problem. > Same here. I'm OK with the diff. -- :wq Claudio
Re: Looking for iwn testers (was: Re: add MCS support to radiotap)
On Sat, Oct 29, 2016 at 01:13:47PM +0200, Stefan Sperling wrote:
> On Sat, Oct 08, 2016 at 07:34:55PM +0200, Mark Kettenis wrote:
> > > The addition might need to be tested on a 1TR1 and 2T3R setups. I can
> > > test the latter, but I have no hardware to test the former.
> >
> > FWIW, this seems to cause no regressions on:
> >
> > iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO
> > 3T3R, MoW, address 00:21:6a:13:67:82
>
> The 1T1R devices listed in the man page are:
>
> Intel Centrino Wireless-N 135
> Intel Centrino Wireless-N 105
>
> Does anybody have either of these devices?
Nobody seems to have these devices.
I am going to proceed soon and just hope that I won't break them.
> If so, please test the diff below during regular usage,
> and with these commands:
>
> ifconfig iwn0 mediaopt monitor up
> tcpdump -n -i iwn0 -y IEEE802_11_RADIO
>
> The expected behaviour is that tcpdump displays some frames
> (at least beacons from APs on the current channel).
>
> Index: if_iwn.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
> retrieving revision 1.175
> diff -u -p -r1.175 if_iwn.c
> --- if_iwn.c 28 Oct 2016 10:11:22 - 1.175
> +++ if_iwn.c 29 Oct 2016 10:10:19 -
> @@ -4504,13 +4504,18 @@ iwn_config(struct iwn_softc *sc)
> sc->rxon.ht_triple_mask = 0xff;
> rxchain =
> IWN_RXCHAIN_VALID(sc->rxchainmask) |
> - IWN_RXCHAIN_MIMO_COUNT(2) |
> - IWN_RXCHAIN_IDLE_COUNT(2);
> + IWN_RXCHAIN_MIMO_COUNT(sc->nrxchains) |
> + IWN_RXCHAIN_IDLE_COUNT(sc->nrxchains);
> + if (ic->ic_opmode == IEEE80211_M_MONITOR) {
> + rxchain |= IWN_RXCHAIN_FORCE_SEL(sc->rxchainmask);
> + rxchain |= IWN_RXCHAIN_FORCE_MIMO_SEL(sc->rxchainmask);
> + rxchain |= (IWN_RXCHAIN_DRIVER_FORCE | IWN_RXCHAIN_MIMO_FORCE);
> + }
> sc->rxon.rxchain = htole16(rxchain);
> DPRINTF(("setting configuration\n"));
> - DPRINTF(("%s: rxon chan %d flags %x cck %x ofdm %x\n", __func__,
> - sc->rxon.chan, le32toh(sc->rxon.flags), sc->rxon.cck_mask,
> - sc->rxon.ofdm_mask));
> + DPRINTF(("%s: rxon chan %d flags %x cck %x ofdm %x rxchain %x\n",
> + __func__, sc->rxon.chan, le32toh(sc->rxon.flags), sc->rxon.cck_mask,
> + sc->rxon.ofdm_mask, sc->rxon.rxchain));
> error = iwn_cmd(sc, IWN_CMD_RXON, >rxon, sc->rxonsz, 0);
> if (error != 0) {
> printf("%s: RXON command failed\n", sc->sc_dev.dv_xname);
>
Re: pf af-to route output
Hello, > The !r->rt case is only used by af-to. pf_route6() calls ip6_output() > to do the work while pf_route() has some custom implementation for > that. It is simpler to call ip_output() or ip6_output() from > pf_test() directly. It looks good to me. I'm O.K. with change. regards sasha
make tcpdump indicate basic rates
ok?
Index: print-802_11.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
retrieving revision 1.34
diff -u -p -r1.34 print-802_11.c
--- print-802_11.c 8 Oct 2016 14:45:11 - 1.34
+++ print-802_11.c 19 Nov 2016 19:21:53 -
@@ -679,8 +679,10 @@ ieee80211_print_elements(uint8_t *frm)
if (!vflag)
break;
for (i = len; i > 0; i--, data++)
- printf(" %uM",
- (data[0] & IEEE80211_RATE_VAL) / 2);
+ printf(" %uM%s",
+ (data[0] & IEEE80211_RATE_VAL) / 2,
+ (data[0] & IEEE80211_RATE_BASIC
+ ? "*" : ""));
break;
case IEEE80211_ELEMID_FHPARMS:
ELEM_CHECK(5);
reduce iwm's RTS retry limit
The RTS retry limit we inherited from Linux seems insanely high.
It seems to be the cause for "bursty" pings and high latency for
smaller packets while larger packets from TCP streams are stuck
in the Tx queue:
64 bytes from 192.168.1.12: icmp_seq=84 ttl=251 time=380.203 ms
64 bytes from 192.168.1.12: icmp_seq=85 ttl=251 time=710.714 ms
64 bytes from 192.168.1.12: icmp_seq=86 ttl=251 time=279.594 ms
64 bytes from 192.168.1.12: icmp_seq=87 ttl=251 time=893.879 ms
64 bytes from 192.168.1.12: icmp_seq=88 ttl=251 time=34800.236 ms
64 bytes from 192.168.1.12: icmp_seq=89 ttl=251 time=33815.364 ms
64 bytes from 192.168.1.12: icmp_seq=90 ttl=251 time=32824.247 ms
64 bytes from 192.168.1.12: icmp_seq=91 ttl=251 time=31822.355 ms
64 bytes from 192.168.1.12: icmp_seq=92 ttl=251 time=30817.395 ms
64 bytes from 192.168.1.12: icmp_seq=93 ttl=251 time=29822.478 ms
64 bytes from 192.168.1.12: icmp_seq=94 ttl=251 time=28817.508 ms
With this diff, while in bad channel conditions, instead of the above
I am seeing 22% lost ping packets, and reasonable latency for those
packets which make it through.
SSH into the machine is even possible (yet rather unusable), whereas
before it didn't work at all.
ok?
Index: if_iwmreg.h
===
RCS file: /cvs/src/sys/dev/pci/if_iwmreg.h,v
retrieving revision 1.19
diff -u -p -r1.19 if_iwmreg.h
--- if_iwmreg.h 20 Sep 2016 11:46:09 - 1.19
+++ if_iwmreg.h 19 Nov 2016 16:36:21 -
@@ -4268,7 +4268,7 @@ struct iwm_lq_cmd {
*/
#define IWM_DEFAULT_TX_RETRY 15
#define IWM_MGMT_DFAULT_RETRY_LIMIT3
-#define IWM_RTS_DFAULT_RETRY_LIMIT 60
+#define IWM_RTS_DFAULT_RETRY_LIMIT 3
#define IWM_BAR_DFAULT_RETRY_LIMIT 60
#define IWM_LOW_RETRY_LIMIT7
Re: pf af-to route output
On Mon, 14 Nov 2016, Alexander Bluhm wrote: > Hi, > > The !r->rt case is only used by af-to. pf_route6() calls ip6_output() > to do the work while pf_route() has some custom implementation for > that. It is simpler to call ip_output() or ip6_output() from > pf_test() directly. > > ok? Note, pf_route() calls pf_test() only if (pd->kif->pfik_ifp != ifp). (I read this as 'pf changed the packet's interface'.) Using ip_output() avoids this guard. If it's an optimisation, no problem, but that's unclear to me. (I suspect it's ok, as af-to is invalid in out-bound rules: so the guard is always true and pf_test() is always called, unless the af-to packet is being sent out the interface it arrived on. But pf_test() should be called for all output packets, so this patch would improve the situation.) With that proviso, ok procter@ best, Richard.
Re: pine64: working bootloader
On Thu, Nov 17, 2016 at 04:25:14AM -0500, Ian Sutton wrote: > (resending as list seemed to eat my last mail) > > Hi, > > I've got a natively-built bootloader working on the pine64 boards > generously donated to the foundation. Simply dd(1) the following image > directly to a uSD card, insert it, reset the pine64, and you will be > greeted by a u-boot prompt over the serial terminal: > > https://ce.gl/pine64-uboot-openbsd.img > > To provide a better understanding of what's going on here, I've devised > a tarball that (attempts) to build such an image, found here: > > http://ce.gl/pine64-openbsd-bootloader-tool.tgz > > Note -- I cobbled this together pretty quickly just as a > proof-of-concept: there will likely be mundane bugs in the Makefile > > In the above tarball, there are a few important items: > > - gcc aarch64 cross-tools & binutils, from patrick@'s excellent patch > > - modified u-boot port, also patrick > > - boot0img, small tool, generates final image > > - ARM trusted firmware tool, generates board-specific firmware binaries >used early-on in the boot process. It informs the hardware logic >where the u-boot binary lives, how big it is, what its checksum is, >etc. > > - boot0.bin, the (I think) very first bit of code executed at power-on >time. I stripped this from around the top of the vendor-provided boot >images. i sure hope it is legally distributable > > I suggest editing the makefile and setting -j8 or similar flags on the > lines that build u-boot and the aarch64-none-elf tools as they take an > insanely long amount of time. > > Similar to most ARM boards, the boot process on the pine64 is not at all > trivial -- about 5 discrete bodies of code that could be construed as > 'bootloaders' exist between the power jack & userspace. To the best of > my understanding, the process is as follows: > > 1.) at power-on, hardware logic checks for presence of boot media (in > our case only uSD card). If no card is inserted, hardware falls back > to some arcane USB boot/firmware upgrade mode we don't care about > > 2.) hardware logic seeks to ~0x2000 and reads a few KB from uSD card > and writes it to on-silicon SRAM. > > 3.) boot0.img code gleans hints about the "real" bootloader, u-boot, > such that it can safely load an image. I don't know if it's loaded > to DRAM or SRAM; something here happens that involves trampolining > which I do not understand. Ostensibly the ARM trusted firmware code > runs around here, checksumming the purported u-boot image and > comparing it against the sum written near the top of the "disk" The proposed patches to implement SPL support for A64 have not been merged to the main u-boot repository yet. The SPL support does what the closed boot0 did. http://lists.denx.de/pipermail/u-boot/2016-November/271722.html ATF runs in trustzone and persists to implement PSCI. And of course you'd have to jump back to 32 bit to actually run the kernel.
[PATCH] pf: fold pf_headers into pf_pdesc
Hi,
This patch folds pf_headers into pf_pdesc, and eliminates pf_pdesc's
header pointers. It's mostly mechanical except for strengthening a guard
in pf_socket_lookup().
I've an OK from bluhm@ but to give others a heads-up I won't commit for
another 48 hours.
+ve removes the header buffer indirection
+ve shaves a parameter from pf_setup_pdesc; no need to allocate
a separate header struct on the stack.
+ve lets us scrub a few (void*) casts
+ve shaves ~200 bytes from pf.o on i386 (adds ~20 on amd64).
-ve it's relatively big
-ve? pf_headers is now bzero'ed on init (28 bytes).
As per usual I've broken this into an easier-to-review series
of patches, which is available at http://203.79.107.124/hdr
Compiled and tested for basic sanity on i386.
best,
Richard.
--
(includes whitespace fixes from bluhm@)
Index: net/pf.c
===
--- net.orig/pf.c
+++ net/pf.c
@@ -773,25 +773,22 @@ pf_state_key_addr_setup(struct pf_pdesc
{
struct pf_state_key_cmp *key = arg;
#ifdef INET6
- struct nd_neighbor_solicit *nd;
struct pf_addr *target;
if (af == AF_INET || pd->proto != IPPROTO_ICMPV6)
goto copy;
- switch (pd->hdr.icmp6->icmp6_type) {
+ switch (pd->hdr.icmp6.icmp6_type) {
case ND_NEIGHBOR_SOLICIT:
if (multi)
return (-1);
- nd = (void *)pd->hdr.icmp6;
- target = (struct pf_addr *)>nd_ns_target;
+ target = (struct pf_addr *)>hdr.nd_ns.nd_ns_target;
daddr = target;
break;
case ND_NEIGHBOR_ADVERT:
if (multi)
return (-1);
- nd = (void *)pd->hdr.icmp6;
- target = (struct pf_addr *)>nd_ns_target;
+ target = (struct pf_addr *)>hdr.nd_ns.nd_ns_target;
saddr = target;
if (IN6_IS_ADDR_MULTICAST(>dst->v6)) {
key->addr[didx].addr32[0] = 0;
@@ -1978,7 +1975,7 @@ pf_icmp_mapping(struct pf_pdesc *pd, u_i
/* FALLTHROUGH */
case ICMP_ECHOREPLY:
*virtual_type = ICMP_ECHO;
- *virtual_id = pd->hdr.icmp->icmp_id;
+ *virtual_id = pd->hdr.icmp.icmp_id;
break;
case ICMP_TSTAMP:
@@ -1986,7 +1983,7 @@ pf_icmp_mapping(struct pf_pdesc *pd, u_i
/* FALLTHROUGH */
case ICMP_TSTAMPREPLY:
*virtual_type = ICMP_TSTAMP;
- *virtual_id = pd->hdr.icmp->icmp_id;
+ *virtual_id = pd->hdr.icmp.icmp_id;
break;
case ICMP_IREQ:
@@ -1994,7 +1991,7 @@ pf_icmp_mapping(struct pf_pdesc *pd, u_i
/* FALLTHROUGH */
case ICMP_IREQREPLY:
*virtual_type = ICMP_IREQ;
- *virtual_id = pd->hdr.icmp->icmp_id;
+ *virtual_id = pd->hdr.icmp.icmp_id;
break;
case ICMP_MASKREQ:
@@ -2002,7 +1999,7 @@ pf_icmp_mapping(struct pf_pdesc *pd, u_i
/* FALLTHROUGH */
case ICMP_MASKREPLY:
*virtual_type = ICMP_MASKREQ;
- *virtual_id = pd->hdr.icmp->icmp_id;
+ *virtual_id = pd->hdr.icmp.icmp_id;
break;
case ICMP_IPV6_WHEREAREYOU:
@@ -2060,14 +2057,14 @@ pf_icmp_mapping(struct pf_pdesc *pd, u_i
/* FALLTHROUGH */
case ICMP6_ECHO_REPLY:
*virtual_type = ICMP6_ECHO_REQUEST;
- *virtual_id = pd->hdr.icmp6->icmp6_id;
+ *virtual_id = pd->hdr.icmp6.icmp6_id;
break;
case MLD_LISTENER_QUERY:
*icmp_dir = PF_IN;
/* FALLTHROUGH */
case MLD_LISTENER_REPORT: {
- struct mld_hdr *mld = (void *)pd->hdr.icmp6;
+ struct mld_hdr *mld = >hdr.mld;
u_int32_t h;
*virtual_type = MLD_LISTENER_QUERY;
@@ -2104,7 +2101,7 @@ pf_icmp_mapping(struct pf_pdesc *pd, u_i
*icmp_dir = PF_IN;
/* FALLTHROUGH */
case ND_NEIGHBOR_ADVERT: {
- struct nd_neighbor_solicit *nd = (void *)pd->hdr.icmp6;
+ struct nd_neighbor_solicit *nd = >hdr.nd_ns;
u_int32_t h;
*virtual_type = ND_NEIGHBOR_SOLICIT;
@@ -2307,7 +2304,7 @@ pf_translate_af(struct pf_pdesc *pd)
/* flush pd->pcksum */
if (copyback)
- m_copyback(pd->m, pd->off, pd->hdrlen, pd->hdr.any, M_NOWAIT);
+
