Re: [Netlink] virtual interface
On Tue, Jan 24, 2006 at 09:19:02PM +0100, Mathieu Geli wrote: Here is a patch that add a netlink virtual interface. I really like the possibility that it offers. In fact, I always wanted something like a 'promiscuous netlink socket'. Whether it is the right thing to add a full-blown net_device for it, I don't know. This really only is a kludge for scapy/ethereal/whatever, since they just expect tu use network interfaces and AF_PACKET sockets. The question is whether we should introduce a net_device to work around scapy/ethereal limitations - or whether we'd rather have some different interface. I would like to hear comments from Dave, Jamal, Thomas Graf, Patrick McHardy on this... btw: There seem to be a number of coding style and whitespace issue in your patch. Please make sure you follow Documentation/CodingStyle as closely as possible. Dissectors are being developed for scapy [1] at the moment. please note that a number of netlink related data structures are host endian, and others are network endian, where again others are mixed host/network endian. This can create soem headache while writing dissectors ;) -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgpzqQ2CKzt4F.pgp Description: PGP signature
Re: [Netlink] virtual interface
Harald Welte wrote: On Tue, Jan 24, 2006 at 09:19:02PM +0100, Mathieu Geli wrote: Here is a patch that add a netlink virtual interface. I really like the possibility that it offers. In fact, I always wanted something like a 'promiscuous netlink socket'. Whether it is the right thing to add a full-blown net_device for it, I don't know. This really only is a kludge for scapy/ethereal/whatever, since they just expect tu use network interfaces and AF_PACKET sockets. The question is whether we should introduce a net_device to work around scapy/ethereal limitations - or whether we'd rather have some different interface. I would like to hear comments from Dave, Jamal, Thomas Graf, Patrick McHardy on this... Its a useful feature, but I also don't like the virtual device approach. Something like raw sockets for netlink seems cleaner to me. - 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
Re: [Netlink] virtual interface
On Tue, 2006-31-01 at 16:26 +0100, Harald Welte wrote: On Tue, Jan 24, 2006 at 09:19:02PM +0100, Mathieu Geli wrote: Here is a patch that add a netlink virtual interface. I really like the possibility that it offers. In fact, I always wanted something like a 'promiscuous netlink socket'. Whether it is the right thing to add a full-blown net_device for it, I don't know. This really only is a kludge for scapy/ethereal/whatever, since they just expect tu use network interfaces and AF_PACKET sockets. Sorry havent paid attention to the patch until now - i did quickly. On second thought - a Netdevice is really overkill for this (although i have in the past said this could be done by redirecting to a netdevice). This should be a feature of the socket interface not just netlink imo. i.e with the right permissions one should be able to attach on per protocol send/recvmsg and see what is being sent. The selinux stuff already has the hooks that could be used for this. I think one should just be able to dump to a file what is seen with headers which indicate things like where it was grabbed from etc. What would be really nice is to emulate the tc redir action and be able to steal data or to just mirror it. cheers, jamal - 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
Re: [Netlink] virtual interface
Hi, On 1/31/06, jamal [EMAIL PROTECTED] wrote: On Tue, 2006-31-01 at 16:26 +0100, Harald Welte wrote: On Tue, Jan 24, 2006 at 09:19:02PM +0100, Mathieu Geli wrote: Here is a patch that add a netlink virtual interface. I really like the possibility that it offers. In fact, I always wanted something like a 'promiscuous netlink socket'. Whether it is the right thing to add a full-blown net_device for it, I don't know. This really only is a kludge for scapy/ethereal/whatever, since they just expect tu use network interfaces and AF_PACKET sockets. Sorry havent paid attention to the patch until now - i did quickly. On second thought - a Netdevice is really overkill for this (although i have in the past said this could be done by redirecting to a netdevice). This should be a feature of the socket interface not just netlink imo. libpcap, tcpdump, ethereal users (application people) - would prefer some simulated device may be similar to the proposed or tun/tap, whereas for debugging is enough a 'promiscuous netlink socket' Unix-domain traffic remains also without a look optin in tcpdump/sniffer. This forced me once to develop a debugging traffic mode, using loopback interface. -- Sincerely, --- Robert Iakobashvili, coroberti at gmail dot com NAVIGARE NECESSE EST -- - 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
Re: [Netlink] virtual interface
Hi Mathieu, Here is a patch that add a netlink virtual interface. Through a hook in af_netlink.c every packets are duplicated and sent to that interface. Thus userspace sniffers can capture them. Looks like an interesting direction. Do you think, that such approach may be extended to unix-domain traffic as well, or there are other ways to sniff such packets? Security people will cry, but sometimes we need good troubleshooting means in userland. Sincerely, --- Robert Iakobashvili, coroberti at gmail dot com NAVIGARE NECESSE EST -- - 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
Re: [Netlink] virtual interface
Do you think, that such approach may be extended to unix-domain traffic as well, or there are other ways to sniff such packets? I don't know if similar things exists or have existed for UNIX sockets. That could be useful having an infrastructure that'll enable to redirect certain socket type traffic to a virtual netdev. Is it something that has already been discussed here ? Security people will cry, but sometimes we need good troubleshooting means in userland. Yes, the deed is to enable netlink troubleshooting from kernel and userland (and to learn more about the kernel actually). I'm aware that hooking af_netlink.c methods may not be very standard and is probably not done in a safe way. That's why I'm looking forward for any comments about how to do things properly. What I feel is done awkwardly is : * not setting up the interface flags (up running by default on my setup) * no tasklet scheduling, does it have to be envisaged for such interface type ? * having to do by hand a dev_queue_xmit + dev_put (refcnt problems in the past) * interface name hardcoded Cheers -- Mathieu Geli - 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
