Darren Reed writes:
> 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.
A few quick questions and checks:
1. I assume that "net_getlifaddr" in the context of a MAC hook
actually returns a MAC layer address, and not an IP address as the
name "lif" might otherwise suggest. Right?
2. You give the new rule processing as:
[INPUT] -> L2 firewall -> "layer2" IP NAT -> "layer2" IP firewall ->
... -> IP NAT -> IP firewall -> { IP } -> IP firewall -> IP NAT -> ...
-> L2 firewall -> "layer2" IP firewall -> "layer2" IP NAT -> [OUTPUT]
I don't understand why the ordering of operations isn't just
reversed on output. Assuming the input order is correct (and it
appears to me to be right), the "L2 firewall" element should be
the last operation before "[OUTPUT]."
3. We're defining these bits of syntax ourselves, and we're expecting
that administrators are going to rely on them for the security of
their systems. Given that, is "Volatile" the right classification
for the new "family ether" and "layer2" configuration keywords?
4. Why is hpe_hdrinfo "void *" rather than "hook_pkt_info_t *"? Void
pointers are mildly evil, as they prevent the compiler and lint
from doing their type-checking jobs. What else would hpe_hdrinfo
point to?
(One very small code review nit: as an argument in a function
definition [dls_devnet_*name2*name], 'const size_t' doesn't do
anything that 'size_t' alone wouldn't do.)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
