Darren Reed writes:
> James Carlson wrote:
> > net_protocol_register(9f)
> > net_protocol_unregister(9f)
> > net_event_register(9f)
> > net_event_unregister(9f)
> >
>
> The references to these should be removed as they are not intended to
> be committed interfaces - at this point in time.
OK. They seem to be related to the ability for hook providers to plug
into the framework. This is something that's interesting to me
... but if it's not for this pass, that's ok.
> > How do zones figure in here? I see no features related to zones, and
> > I would have expected interfaces that allow one to determine whether a
> > given net_if_t is within a particular zone, and which zone is the
> > source or destination of a given packet.
> >
>
> This isn't as easily solved as you might expect, especially if we take
> into account
> that there are shared IP instance zones as well as exclusive IP instance
> zones.
Right; there's certainly added complexity here.
> For each exclusive IP instance, there is a seperate net_data_t and so a
> given
> net_if_t by itself is not unique, the correct key becomes <net_data_t,
> net_if_t>.
I don't quite follow that. The net_protocol_lookup() function[1], which
seems to be the way that one finds net_data_t instances, takes only a
single string argument, which I *think* should be "inet" for IPv4 and
"inet6" for IPv6.
So, if there's a separate net_data_t for each exclusive IP stack
instance, how do you find it?
[1] As a detailed comment, it seems that net_protocol_lookup() returns
net_data_t *, but that all of the other functions take net_data_t.
Are the callers expected to dereference, or are the types
confused?
> If you have a process context when registering hooks and you track your
> own instances of data, the zoneid_t can be recorded from cred_t to match
> up with the net_data_t that's used to register the hooks. By itself,
> the zoneid_t
> from the cred_t on a mblk isn't reliable enough here, even though it
> does pop
> into usefulness with shared instance zones.
The problem I see is that it's unclear when and if the consumer of
pfhooks has access to zone information. I understand that it may be
the case that some hooks can't provide this, but that others can, but
I don't think that the consumer of pfhooks should need to understand
how the hooks themselves are implemented -- the existence of zone
information should be called out where it is known.
> > How do net stacks (exclusive IP zones) work? Shouldn't the zone ID be
> > (in some way) an argument to net_protocol_lookup(9f) so that the right
> > instance of the network layer protocol is found? I see the
> > net_callback_t functionality and the netid_t handle, but I don't see
> > how it relates to either the zone identity or can be used to identify
> > the separate stack instances. It's not the same net_data_t for two
> > separate instances of IP, is it?
> >
>
> No, it's not.
>
> The net_callback_t functionality interfaces to IP instances, which has its
> own identifier space (netstackid_t), separate to that of zones (zoneid_t.)
OK.
> What value does one get from knowing what the zoneid_t is when (say)
> the create callback is being activated? I'd argue very little.
I don't care about zoneid_t versus zone name -- all I was asking for
was some identifier, and when and how that information would be
accessible.
> What's really required is a way to identify the name of a zone with an
> instance of IP. For example, if I specify some configuration option (say
> a firewall rule) in user space to apply to a particular zone, there may be
> no mapping of that name to an identifier at that point in time and I may
> have to wait until the create callback is activated.
Sure. (Or you might do as we do elsewhere and fail such a call, and
let zoneadmd do the work of installing the rules when the zone is
created.)
> Now even if I do that,
> I'll get a netid_t, at which point I need a way to equate (or at least
> attempt
> to match up) my zone name with that, bringing to life the need for at
> least a function to map netid_t onto zoneid_t and convert a name into
> a zoneid_t (and probably the inverse of that too.)
>
> ... but the caveat here is that none of the existing code requires any of
> the above, so there are no existing consumers.
That could be why I'm finding it hard to put it together ...
> > What about other non-Ethernet features? This doesn't seem to support
> > tunnels or point-to-point interfaces -- there's no net_getlifdstaddr
> > function, nor any tsrc/tdst access.
>
> If you issue net_getlifaddr() with NA_PEER as the type, then you are
> returned the destination address for a PtP interface. More documentation
> is needed for that.
Oh, ok; I see it now.
> Tunnel source/destination is not currently covered
> but can be included.
OK.
> > Are there any features visible
> > through the SIOC* ioctls that would be useful here, but that are not
> > included? If so, what are those things?
I think it'd be really helpful to have a listing of the SIOC* ioctls
and the corresponding pfhooks/netinfo functions -- both so that we
know where there might be gaps, as so that we have some help in
porting code from user to kernel space.
> > Is it possible to invoke L2 (ARP/NDP) look-up?
>
> Not through this interface, no.
I think this was one of the SDP/IB requests, so that's why I was
asking.
> > What about getting the
> > results of a forwarding table look-up? (Is that net_routeto ... ?)
> >
>
> Yes, that is correct in that it will return the outgoing interface,
> but not the address of the next hop.
Oh ... I'd suggest changing that, as I don't think you have a complete
forwarding result if you don't have (for non-point-to-point
interfaces) the next hop address.
> > I think you might be missing an iterator here. What happens if a hook
> > is loaded *after* zones are started? How does such a hook know what
> > zones are already running when it is installed?
> >
>
> A successful call to net_callack_register() results in the _create()
> being called
> for each instance that currently exists. This needs to be mentioned in
> the doc
> for net_callback_register().
OK; that'll do the job.
> > (As far as naming goes, I'm not sure "callback" is a good name for
> > "stack instance.")
> >
>
> I kind of ran out of names...I wasn't sure what to name this.
> Name for a structure to define a set of functions to call when there
> is a change in the instances? Well, I suppose net_instance_t?
> I'm open to suggestions..
I like net_instance_t.
> >> The word "hint" is used here deliberately as two of the optional hints,
> >> first and last, may not be continually satisified beyond the initial
> >> registration of the hook - they only represent the ordering requirement
> >> at the time of insertion. Furthermore, the "before" and "after" hints
> >> do not gaurantee "immediately before/after".
> >>
> >
> > Why not? What happens if the hint isn't honored? Is it possible that
> > correctness is sacrificed?
> >
>
> Well, the hint being given is that X wants to be before Y, not that after
> directly after X should be Y. Yes, I suppose I'm cheating by playing on
> the definition of words here but that's somewhat deliberate.
I have no problem with "X wants to be before Y" translating into
"X->Q->Y" in the stack.
I'm not so sure I agree with "X wants to be first" translating into
"Q->X" in the stack. I'm not even sure I understand what "first"
means in those circumstances. Depending on load order, which doesn't
seem defined, it seems that a module specifying "first" could silently
be placed last after a long list of other modules.
> Elsewhere I've mentioned the problem of two different products (from
> different vendors) saying they want to be first - I'm wary that a similar
> situation may result of two vendors/products both say "I want to be before
> IPFilter" (assuming the hook names for that are stabilised.)
Right ... I'm asking whether that's really a problem. Suppose there
*are* two such products. Aren't they incompatible with each other?
Why not prevent incompatible products from being loaded
simultaneously?
> So, strictly speaking, the correctness is defined here in terms of the
> relationship between the two hooks - one that wants to be inserted
> and the one it wants to be before/after - and is silent on whether
> there should be anything in-between, so things can go either way.
I have no problem with that. The relative ordering makes sense, and
an intermediate module doesn't bother me. Instead, I'm confused about
the absolute ordering that's not really absolute.
> > I think it may well be the case that certain types of hints --
> > particularly "first" and "last" -- cannot be absolutely guaranteed
> > without making two users incompatible with each other. But so what?
> > Is it a bad thing if two hook users can't (by design) be used
> > together?
> >
>
> What I'm afraid of is incompatibility between various products
> that always want to be "first" or "last". For example, I could imagine
> a firewall vendor saying they want to be first and then maybe another
> vendor of intrusion detection software also wants to be first. The rules
> that each must program to are the same, so why should the presence
> of one mean the other cannot be present?
I'd answer that by saying that since they've both demanded to be
first, and only one can actually be first, then one must lose. As
long as that's a constraint listed in the documentation, and that
hook-using module writers explain to their customers, I don't see it
as a big problem.
> A way out of this might be to replace the words "first" and "last" with
> fuzzier variations, such as "earlier" and "later".
Even those don't seem to work, as it all depends on load order. The
service you seem to be offering is "insert head" and "insert tail,"
but without (as best I can tell) offering control over the order in
which those operations occur.
Dumb question time: this is all global, right? You can't have
per-interface hook lists, or per-exclusive-IP-stack hook lists, right?
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
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
_______________________________________________
networking-discuss mailing list
[email protected]
