I've experienced this need recently. Current pfhook API is really good for making a synchronous decision about hooked packets. The only way to effect async packet handling, though, is to drop the inbound packet within the hook callback and requeue it for IP later.
There isn't currently a portable way to mark a packet so that it can be ignored after being "rehooked". It probably isn't realistic to predict all the creative ways that developers will want to use pfhooks, but I think the ability to tag or append "upper data" to a packet would cover a lot of requirements. It would certainly satisfy my situation. One beautiful thing about this API is there's no mucking about required in the IP module. For that, I'm very grateful to the designers and I hope it continues. Erik, you make a great point about multiple pfhook occupants and that would certainly be a design constraint for the final mechanism. I'm already worried about deploying to Solaris 10/4 and bumping into another driver using the API. Thanks, Fred On 9/6/07, Erik Nordmark <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > > It's not just me who'd like this capability. > > > > At the very least, it would be desirable to add "something" to a > > packet receiving via pfhooks on the inbound side and be able to > > see that "something" again on the outbound side. > > That is a much more well-defined problem. > > And with IP datapath refatoring in mind, it can be solved by passing > around an IP attribute as a procedure call argument inside IP. > > Things are easy if there is only one occupant of each pfhook. If there > can be multiple there has to be a way to name what the different > occupants use to that their corresponding piece on the outbound side can > find the right attribute. And that complexity is there independent of > the actual attribute mechanism. > > Erik > > > > _______________________________________________ > networking-discuss mailing list > [email protected] >
_______________________________________________ networking-discuss mailing list [email protected]
