site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry _______________________________________________ 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... On Mar 8, 2008, at 12:46 AM, Justin Delegard wrote: In my attempts to practice both programming in cocoa and low level system interaction, I created a small program to give basically the same info as netstat -nr does. Netstat makes a sysctl call which returns what amounts to an array of struct rt_msghdr2's (declared in net/route.h). Immediately following each struct rt_msghd2 is an array of struct sockaddrs, the length of which is determined by how many flags in the rt_msghdr2->rtm_addrs are set. Generally there are three sockaddrs returned: the destination, the netmask, and the gateway. Both the destination and the gateway are normal struct sockaddrs and when I mask them as struct sockaddr_ins they all behave as I would expect. The problem is with the netmask. For several routes it exists with a length of zero, and for others longer than you would expect an ipv4 netmask to be. Is there something going on with the implementation of routing tables that I am unaware of, or perhaps some netmask convention that I don't know? Why are these values so strange? If you want to look at my project you can download it at http://j-dizzle.net/Routes.zip Typically, you would need to look at the source to netstat in the network_cmds version corresponding to the specific kernel version to answer this question. The sysctl() for this type of thing is SPI - System Programming Interface - and constitutes a contract between the user space utility and the kernel. It's _NOT_ API - Application Programming Interface - so the contract does not extend to non-Apple code. This contract is only as valid as the synchronization between the user space utility and the kernel code, which in turn is only really guaranteed to be valid at release time, mostly because the user space utility and the kernel are released in lock-step. If you need to present this information, you would likely be better off using a popen() of the netstat command, and reading the resulting data of the output of the command, rather than fishing for the information yourself via the sysctl(). If you go fishing, there will not be any guarantee that you are using the right structures, and any software update could shoot you in the foot. Though we reserve the right to fiddle around with the netstat output as well, it's much less likely to change a lot than the underlying sysctl() might. This email sent to site_archiver@lists.apple.com