site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com I'm posting my intention to port pf (4) (http://www.freebsd.org/cgi/ man.cgi?query=pf&sektion=4) to an NKE for use as a replacement or complement to the current ipfw2. According to the Network Kernel Extensions Programming Guide (http:// developer.apple.com/documentation/Darwin/Conceptual/NKEConceptual/ index.html) it seems I might use an Interface Filter KPI mechanism to accomplish such a task. So I ask those who are more familiar with NKEs, is this a reasonable task, am I sane to try it, and do you have any words of advice? Ryan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I can tell you from experience you're going to have a hard time doing things at the IP filter layer. IPFW is kind of hacked in the Mac OS X stack between the interface layer and the IP layer. Therefore it can do things that are not possible at either layer alone. My experience comes from trying to write a similar replacement for IPFW. I'm not familiar with PF per-se but I imagine our requirements were pretty close to what PF and IPFW provide. - An IP filter only receives unfragmented packets. You cannot filter on unfragmented packets. - An IP filter receives outgoing packets before they have been routed, so you won't be able to filter based on the interface. And sometimes the mbuf_pkthdr_rcvif wasn't set for incoming packets either. (That might have been a bug.) - An IP filter receives packets after they have been "filtered" out by the IP stack, which is both good and bad. If you want to filter those packets yourself, then you're SOL. If you don't care then it's a good thing because checking for those packets can be tedius. - An interface filter receives fragmented packets and you can filter on the interface. However an interface filter is harder to write correctly/safely, especially for IPv6 (finding the protocol headers in IPv6 was not very fun). In summary, to completely emulate IPFW I concluded I'd need an interface filter, not an IP filter. But if you're OK with not implementing some parts of pf's interface, or if pf doesn't support those tests, then use an IP filter. It's easy to switch between the two implementations, btw. Just write the entrypoints to your packet filtering so that it takes a pointer to the packet start and a pointer to the protocol header. This was all back in 10.4's early days as proof-of-concept. I never finished it because we moved on to other projects. I might have been running into bugs in 10.4.0, but I know some of these are not bugs but are limitations. Somebody from Apple might be able to comment more. This email sent to site_archiver@lists.apple.com