James Carlson wrote: > Darren Reed writes: > >> - does it give you the access to packets that you need? >> >> - is the ordering mechanism for hooks useful/useless? >> >> - is enough basic infrastructure supplied for you to >> work with and process packets? >> >> - what do you want to do that this won't let you do? >> > > There seem to be some missing parts in the man pages. In particular, > I wasn't able to find definitions of these things, though they're > referred to in the other man pages: > > 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. > net_ifgetnext(9f) > Should be net_phygetnext(9f). > net_getforwarding(9f) > net_setforwarding(9f) > Cleanup is required here - these two are both to disappear. > And some other things seem to be both undefined and not referenced as > man pages: > > phy_if_t > net_data_t > net_if_t > > My guess is that these are intended to be opaque structures and that > access to the members is provided by certain accessor functions, but I > think it'd help to have a summary somewhere of what those accessors > (and related functions) are. I'd suggest having phy_if(9s), > net_data(9s), and net_if(9s) man pages that explain what the > structures are (without providing the member names) and what utility > functions exist. Otherwise, it's hard to make the connections. > You're correct in your guess and I'll pickup on your suggestion here. > 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. 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>. 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. > 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.) 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. 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. 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. > 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. Tunnel source/destination is not currently covered but can be included. > 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? > > Is it possible to invoke L2 (ARP/NDP) look-up? Not through this interface, no. > 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. >> The create function in the set of callbacks is called after a new instance >> of IP has been created and before any traffic will appear for that instance. >> The only argument to the create function is an identifier that uniquely >> identifies this instance from all others. The return value from the create >> is passed back in as the 2nd argument to the destroy and shutdown functions. >> > > 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(). > (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.. >> 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. 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.) 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 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? A way out of this might be to replace the words "first" and "last" with fuzzier variations, such as "earlier" and "later". Darren _______________________________________________ networking-discuss mailing list [email protected]
