From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lu5o6-0001kk-Rk for qemu-devel@nongnu.org; Wed, 15 Apr 2009 10:09:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lu5o2-0001jo-6V for qemu-devel@nongnu.org; Wed, 15 Apr 2009 10:09:42 -0400 Received: from [199.232.76.173] (port=47059 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lu5o2-0001jl-2u for qemu-devel@nongnu.org; Wed, 15 Apr 2009 10:09:38 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:19929) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lu5o1-00043H-Ov for qemu-devel@nongnu.org; Wed, 15 Apr 2009 10:09:38 -0400 Message-ID: <49E5EA9F.2090206@siemens.com> Date: Wed, 15 Apr 2009 16:09:35 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090414172954.15035.73053.stgit@mchn012c.ww002.siemens.net> <20090414172955.15035.35614.stgit@mchn012c.ww002.siemens.net> <1239801006.4431.132.camel@blaa> In-Reply-To: <1239801006.4431.132.camel@blaa> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 6/7] net: Add support for capturing VLANs Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin , qemu-devel@nongnu.org Mark McLoughlin wrote: > On Tue, 2009-04-14 at 19:29 +0200, Jan Kiszka wrote: >> This patch is derived from Tristan Gingold's patch. It adds a new VLAN >> client type that writes all traffic on the VLAN it is attached to into a >> pcap file. Such a file can then be analyzed offline with Wireshark or >> tcpdump. > > Personally, I'd use a tap device and 'tcpdump -w' to do this. > > Any particular reason to add support to qemu itself other than > convenience? You have to have the right privileges (for me the key argument) + you have to add the tap device in the right order, see below. If we were talking about thousands of LoC, I would say, let's stick with these limitations. But the capturing features is really small and self-contained (you may also consider it as a feature extension of slirp, which you could basically also replace with a tap device + iptables rules). > >> Besides rebasing and some minor cleanups, the major differences to the >> original version are: >> - support for enabling/disabling via the monitor (host_net_add/remove) >> - always register dump client at the head of a VLAN queue >> (instead of special handling for slirp) > > Could you explain why you need this? > > I'd prefer if we didn't have to add qemu_new_vlan_head_client() Packet ordering: If you are sniffing from behind a vlan client in the queue, you may see its immediate reply to a certain packet before the triggering packet. Tristan solved this by pushing slirp (the only source for reordering so far) at the end of the queue, but I think it's rather the sniffer which has special requirements, so I pushed that one to the top. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux