Re: [Nbd] Wireshark dissector for NBD
- To: "Wouter Verhelst" <wouter@...3...>
- Cc: firstname.lastname@example.org
- Subject: Re: [Nbd] Wireshark dissector for NBD
- From: "ronnie sahlberg" <ronniesahlberg@...17...>
- Date: Tue, 31 Oct 2006 11:24:32 +0000
- Message-id: <c9a3e4540610310324v174a84a3l36ee040f32217669@...18...>
- In-reply-to: <c9a3e4540610310251o67721accu42cdeef3b78cf5d8@...18...>
- References: <c9a3e4540610291659o245c4c9byf007322e9b6cfea5@...18...> <20061030085415.GA27172@...39...> <c9a3e4540610310251o67721accu42cdeef3b78cf5d8@...18...>
I have checked in to SVN 19752 of wireshark a dissector for NBD.
Please test and provide comments on how to make it more useful for NBD people.
The dissector uses the common infrastructure in wireshark to track pdu
boundaries with regard to tcp sequencenumbers and should
handle the common cases with :
1, a pdu spanning multiple tcp segments
2, a pdu that does not start aligned to the beginning of a tcp segment
3, multiple pdus inside a single tcp segment
There is a new preference in Menu:/Edit/Preferences/Protocols/NBD to
control whether the dissector should also attempt to reassemble the
tcp stream for NBD which is enabled by default.
This consumes vast amounts of memory so you may want to disable tcp
reassembly on the global tcp preference
Menu:/Edit/Preferences/Protocols/TCP to disable tcp reassembly if
you work with very large captures.
The dissector attempts to track and match requests with responses
(for READ/WRITE commands) and will measure the response time on a
per command basis which can be filtered on by "nbd.time"
The dissector only handles
NBD_CMD_READ / NBD_CMD_WRITE for now and does not understand the
negotiate or the NBD_CMD_DISC commands yet.
On 10/31/06, ronnie sahlberg <ronniesahlberg@...17...> wrote:
The handles are 64 bits and still you reuse their values very frequently.
This makes it much more difficult to track request/responses which I
have to do in order to know how many bytes a response packet is.
On 10/30/06, Wouter Verhelst <wouter@...3...> wrote:
> On Mon, Oct 30, 2006 at 11:59:28AM +1100, ronnie sahlberg wrote:
> > List,
> > My name is ronnie sahlberg and im one of the wireshark developers.
> > I just read some discussion on the thread "tech documentation"
> > about a wireshark/ethereal dissector.
> > If you are interested I can write a dissector for this protocol.
> Hey, that'd be cool! Thanks!
> (Obviously, as you've seen in the discussion, Phil Howard was planning
> on writing this dissector, too; I don't know whether he's finished or
> even started this, but you may want to coordinate with him).
> > I would need a couple of example network traces to verify with and
> > to documentation.
> > (http://grep.be/blog/en/computer/nbd/ethereal_wanted is probably
> > for me to write the dissector if you can just confirm it is still a
> > description of the protocol)
> Yes, it's still valid; nothing has changed in the protocol since that
> blog post.
> > I.e. If you want me to I can write a dissector for this protocol.
> > I would need some help from you though
> > 1, some example network traces
> I've put some on my website, at http://grep.be/data/wireshark/ (because
> they're too large for email attachments).
> The first is a connection from nbd-tester-client to an nbd-server on the
> localhost. The server is running on port 12347; the client appears to be
> running on port 37745. The export is a small test export that I have,
> which is 20K large, so that's not much. What nbd-tester-client do is
> check the size of the export, and then run through it by reading every
> block in the export in sequence. It doesn't do any writes.
> The second is a connection from a real nbd-client running on
> 192.168.119.2 to a server running on 192.168.119.17. The exported file
> in this case is 64K large (since 20k was apparently too small for what I
> was about to do). After setting up the device, I ran 'mkfs -t ext2' on
> the device, mounted the file system, created a file, ran 'sync', removed
> the file again, umounted the file system, and closed the connection
> again with 'nbd-client -d' (which uses the in-protocol command to do
> so). This will give you a reasonable approximation of what it looks like
> when it's really in use (obviously I'm not asking you to decode the
> filesystem writes :).
> I hope that's enough; if not, please do let me know.
> > 2, later, if possible if someone could create a small NBD protocol page
> > wiki.wireshark.org
> Would it be enough to just copy the description from my blog?
> <Lo-lan-do> Home is where you have to wash the dishes.
> -- #debian-devel, Freenode, 2004-09-22