On /dev/lo0.
Why are we fabricating the ethernet header rather than having
snoop ask lo0 what MAC type it is and using that to understand
that there is no MAC header to speak of?
The insertion of a fake ethernet header incorrectly leads one
to believe that it is an ethernet medium and/or could be used
with ethernet filtering expressions. For example, if you're
pretending lo0 is ethernet for IPv4, where are my ARP packets?
Another kludge that this path requires is to assume that the
ethernet address of 00:00:00:00:00:00 is available for this
kind of hack. It's not exactly clear to me that it is or isn't
and could probably be argued either way.
I think you would be better off adding a new ioctl that would
return the data link layer type and changed snoop to use that
when it is forming knowledge about how to write its filter
expressions. If doing that ioctl fails then fallback to using
ethernet. This would limit the amount of work to just adding
the ioctl to your new lo driver. It would also be useful for
later building on support for porting the BPF driver to Solaris
and should be part of what is used and ends up in libdlpi.so.
The current plan just seems wrong here...very very wrong.
How will the inter-zone obersvability play with pfhooks?
And how will this compare with seen with packet going in
out of a physical interface? For example, now with snoop,
you see all packets that are "on the wire" - how does this
translate to inter-zone traffic with pfhooks and snoop?
On the topic of zones, you mention that you'll publish the
appropriate zoneid "where available." Are you making any
changes to IP to increase or improve the availability of
zone information with respect to packets?
e.g the problem observed in this bug might be relevant:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6352430
In your document, you write:
> However,
right now there is no generic hook framework or PEF and so the only choice is
to implement our own. The Packet Filtering Hook case does not provide a generic
framework.
Would you like to expand on where the pfhooks case does not provide
you with a generic framework?
If the NH_PHYSICAL_IN/NH_PHYSICAL_OUT/NH_LOOPBACK_IN/NH_LOOKBACK_OUT
do not provide you with the correct locations then it could be worth
your while mentioning this.
It is true that the framework only supports one consumer of events at
any given time but this is a different limitation.
The description of dl_netinfo_t needs some work. Rather
than using uint64_t for zones, you should be using zoneid_t.
It's more important to use the correct type for storing data
than it is to use a specific size. If you're really concerned
about the field width thing, consider using a union to pad it
up but use the zoneid_t field as the active member.
Also, the current sizing of fields doesn't lead to useful
packing (there's a 32 bit hole between dli_len and dli_srczone.)
Consider making dli_version sa_family_t and assigning it either
AF_INET or AF_INET6, appropriately, rather than a magical 4 or 6.
Also, for dli_len, consider using something like size_t rather
than an intX_t.
struct dl_netinfo_s {
uint16_t dli_version;
sa_family_t dli_family;
uint32_t dli_len;
union {
unit64_t dliu_spad;
zoneid_t dliu_srczone;
} dli_srcun;
union {
unit64_t dliu_dpad;
zoneid_t dliu_dstzone;
} dli_dstun;
};
#define dli_srczone dli_srcun.dliu_srczone
#define dli_dstzone dli_srcun.dliu_dstzone
...the only problem (for packing) is that size_t will be 64bits
on UltraSPARC.
But so long as dli_version always comes first and remains the
same size forever, how the rest of the structure is packed
should not be a problem.
Regarding changes to other software...
Why are we changing 3rd party software to interface with
libdlpi.so and not snoop as well?
Is there any value in snoop'ing based on zones when Solaris
isn't correctly tagging packets with the right zone?
(See above.)
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
