jamal wrote: > On Wed, 2006-08-02 at 22:50 +0200, Hasso Tepper wrote: > > jamal wrote: > > > Ok, thanks for the reminder Hasso. > > > so essentially at the moment the pid that will show up (if > > > quagga added the v6 route) will be that of quagga, correct? > > > > No. Quote from Alexey: > > I sense you missed my question. I understand the variants of PIDs that > can occur(real, 0 or ones that need you to do a getname()), the > question is: > At the moment if a route (v6 or v4) was added by quagga and i had a > socket that was listening in a different process - what pid will i see > (in my user space app)? Is it of the quagga process or is it 0?
No, it's 0xffffefff for most of Quagga users. The reason behind is that Quagga uses the first netlink socket it opens only for listening multicast groups. For sending messages to the kernel it opens second socket. Quagga lets kernel assign nl_pid's to the socket (by setting it to 0 before calling bind()). The first socket gets nl_pid equal to process pid of quagga (actually it's zebra daemon of quagga suite ;) and the second gets (0 - 4097) - see net/netlink/af_netlink.c:netlink_autobind() for details. As far as I understand it - the only connection between process pid and nl_pid member in sockaddr_nl structure is that Alexey happened to use pid of the process opening netlink socket as base of algorithm assigning unique unicast address to this socket if application doesn't set it itself (ie. it's 0 before calling bind()). -- Hasso Tepper Elion Enterprises Ltd. WAN administrator - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
