This document is primarily of interest to developers who need to extend or modify the Mac OS X networking infrastructure.
This includes:
* Adding support for new, non-ethernet interface types. * Designing custom routing technologies. * Creating link-layer encryption technologies. It's the second example I'm interested in: "Designing custom routing technologies" Regards, Markus _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com I just reread the documentation document named "Introduction to Network Kernel Extensions Programming Guide". In the section "Technology Overview" of the "Introduction" I found the following interesting statement: I have already written network kernel extensions in the past, one of the type interface filters (in the very early days of OS X, since there was no better way available) and later on several ones of the type IP filter (which are much more convenient when dealing with IP traffic). So I can assure you that I have quite some knowledge about this topic, however I have absolutely no idea how I could implement my own custom routing technology in any kind of network extension. At the moment all routing related topics are handled by a user space process, that manipulates the routing table as appropriate by adding, removing and altering routes. This approach has two big drawbacks: 1) I'm in a constant race condition with the rest of the system, that tries to manage the routing table as well. E.g. plugging in an Ethernet cable modifies the routing table; a new default route might be set and if I have a router for the same network as the interface is been told via DHCP, my route is just overwritten (changed) from some indirect to a direct interface route. If my app is going to delete the routes it has created (and thinks its still in place), it would accidentally delete the interface route and that way "kill" the Ethernet interface or even worse, delete the default route. As there is no way to "lock" the routing table, it's also not possible to look up a route and only change/delete it if I get the expected look up result. Between the look up and my change request the table may have been altered again. 2) I'm limited to the routing capabilities of the system. E.g. I cannot set routing rules depending on service, as this is not support by Darwin. I can set a rule how to route 192.168.1.50, but I cannot have a different route depending if this is SMTP (port 21) or HTTP (port 80) traffic or possibly no TCP/UDP traffic at all. Of course I can create an IP filter, catch IP packets according to a set of "rules" and forward these directly to interfaces as I wish, but this approach has other issues. I can name at least 3: I) If the interface does not fragment IP packets on its own, I have to fragment them myself in my code. I might even have to caculate checksums myself, though I believe there is a function I can use to force the system to calculate all missing checksums immediately. II) If an application connects a socket to a remote address, even if this is just an UDP socket, and then calls getsockname() to find out the local address of this socket, it will retrieve the address according to the routing table; however, this may not be the right address, since my code may route this traffic to a different interface with a different IP address. If the app is using some protocol that includes the local IP address somewhere in the payload, this has a huge potential for all kind of problems. III) Similar to (II), if an application queries the routing table for a specific destination address, it might being told a wrong interface, including wrong interface parameters (e.g. think of MTU). I don't see any way a network kernel extension, or any other kernel extension for that matter, could register a callback for routing decisions of the system. Ideally there would be a way my code can tell the system how to route certain kind of traffic without having to ever touch the routing table at all. Is there a way an IP filter can influence how the packet is routed once it allowed it to pass on? If such a functionality exists, I have not been able to find it so far.