With the extension of the timer for this project to tbe 10th of December,
I'm updating the materials submmitted to cover changes required to
support the eventual filtering of WiFi packets.
The changes are (see below for more details):
- additional section in "spec.txt" covering the reason, why for, etc.
- changes to hook_pkt_event(9s)
Darren
--- spec.txt Wed Dec 3 11:30:31 2008
+++ spec.txt.new Wed Dec 3 13:37:48 2008
@@ -3,8 +3,9 @@
This case will extend PSARC/2005/334, by adding the ability to intercept
packets in MAC layer using the PFHooks infrastructure.
-This case only makes one change, an addition, to the interfaces that were
-committed to by PSARC/2008/219 (see "new NIC event" below for details)
+This case only makes two changes, an addition, to the interfaces that were
+committed to by PSARC/2008/219 (see "hook_pkt_event_t" and "new NIC event"
+below for details)
Release Biding
--------------
@@ -72,7 +73,42 @@
hpe_hdr - points to the start of the MAC header
hpe_mb - points to the start of the mblk_t that holds hpe_hdr;
hpe_mp - points to the mblk_t that is the start of the packet.
+hpe_hpeinfo - points to mac_header_info_t which contains MAC header
information
+hook_pkt_event_t
+----------------
+In order to intercept IP packets at MAC layer, IPFilter needs to know the
+size of the MAC header to locate the IP header start. The problems is
the wifi
+header is not self explained, parsing it requires information from mac
handle
+thus IPFilter cannot do the parsing itself, so we need to rely on the MAC
+plugin to parse the header, pass the information through Hook framework to
+IPFilter, so it can identify IP header start correctly.
+
+While adding a header length field to hook_pkt_info_t solves the
problem above,
+down the road we may want to provide the ability to match wifi header,
which
+requires information of the wifi header fields in IPFilter, not just
the header
+length, thus we propose to add a pointer to hook_pkt_info_t, which
points at
+a structure of mac_header_info_t, and pass this through the Hook framework,
+so the hook consumers, like IPFilter, can have the needed information for
+the MAC header. The new hook_pkt_info_t strucuture would look like:
+
+typedef struct hook_pkt_event {
+ net_handle_t hpe_protocol;
+ phy_if_t hpe_ifp;
+ phy_if_t hpe_ofp;
+ void *hpe_hdr;
+ mblk_t **hpe_mp;
+ mblk_t *hpe_mb;
+ int hpe_flags;
+- void *hpe_reserved[2];
++ void *hpe_hdrinfo;
++ void *hpe_reserved[1];
+} hook_pkt_event_t;
+
+For existing IP/ARP Hooks, the header format is self explained, so
hpe_hdrinfo
+will be NULL and IPFilter does the header parsing itself as before.
+
+
Name to interface resolution
----------------------------
After Clearview UV all the data link related operations use link names,
this
Kernel functions hook_pkt_event(9s)
NAME
hook_pkt_event - packet event structure passed through to
hooks
SYNOPSIS
#include <sys/neti.h>
#include <sys/hook.h>
#include <sys/hook_event.h>
INTERFACE LEVEL
Solaris DDI specific (Solaris DDI)
DESCRIPTION
hook_pkt_event contains fields that relate to a packet as is
in a network protocol handler. This structure is passed
through to a callback for NH_PRE_ROUTING, NH_FORWARDING,
NH_POST_ROUTING, NH_LOOPBACK_IN and NH_LOOPBACK_OUT events.
A callback may modify the hpe_hdr, hpe_mp and hpe_mb fields.
A callback may not modify either of hpe_ifp or hpe_ofp.
The following table documents which fields can be safely
used as a result of each event.
_________________________________________________________________
| Event | hpe_ifp | hpe_ofp | hpe_hdr | hpe_mp | hpe_mb |
|_________________|_________|_________|_________|________|________|
| NH_PRE_ROUTING | Yes | | Yes | Yes | Yes |
| NH_POST_ROUTING | | Yes | Yes | Yes | Yes |
| NH_FORWARDING | Yes | Yes | Yes | Yes | Yes |
| NH_LOOPBACK_IN | Yes | | Yes | Yes | Yes |
| NH_LOOPBACK_OUT | | Yes | Yes | Yes | Yes |
|_________________|_________|_________|_________|________|________|
STRUCTURE MEMBERS
net_data_t hpe_family;
phy_if_t hpe_ifp;
phy_if_t hpe_ofp;
void *hpe_hdr;
mblk_t **hpe_mp;
mblk_t *hpe_mb;
uint32_t hpe_flags;
+ void *hpe_hdrinfo;
hpe_family
The protocol family for this packet. The value found
here will match the corresponding value returned from a
call to net_protocol_lookup(9f).
hpe_ifp
The inbound interface for a packet.
hpe_ofp
The outbound interface for a packet.
hpe_hdr
Pointer to the start of the network protocol header,
within an mblk_t.
hpe_mp
Pointer to the mblk_t pointer that points to the first
mblk_t in this packet.
hpe_mb
Pointer to the mblk_t that contains hpe_hdr.
+ hpe_hdrinfo
+ Optional pointer to packet header information.
The relationship of hpe_hdr, hpe_mp and hpe_mb can be illus-
trated as follows.
hpe_mp
|
V
mb hpe_mb
| |
V V
+--------+ +----------+ +--------+ __-------->+-------+
| mblk_t | | mblk_t | | b_rptr--/ |data |
| b_cont----->| db_datap----->| b_wptr--\ hpe_hdr->|header |
+--------+ +----------+ +--------+ \ |data |
\ +-------+
\________________^
hpe_flags
This field is used to carry additional properties of
packets. THe current collection of defined bits is:
HPE_BROADCAST
Set if the packet was recognised as a broadcast
packet from the link layer. Cannot be set if
HPE_MULTICAST is set, currently oly possible with
physical in packat events.
HPE_MULTICAST
Set if the packet was recognised as a multicast
packet from the link layer. Cannot be set if
HPE_BROADCAST is set, currently oly possible with
physical in packat events.
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Interface Stability | Committed |
|_____________________________|_____________________________|
SunOS 5.10 Last change: DD Month 2007 2
Kernel functions hook_pkt_event(9s)
SEE ALSO
netinfo(9f),
SunOS 5.10 Last change: DD Month 2007 3
