[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] Wireshark dissector for NBD



Ill continue to prettify the dissector which shouldnt take that much time since it is already in reasonable shape.
Some cosmetic updates but that should be it.


I have created an initial page for NBD on our wiki.     http://wiki.wireshark.org/NBD
and if someone could have a look at it and add some nice content (and an example trace?    also upload the example trace to wiki.wireshark.org/SampleCaptures    it should probably go under the section for SAN Protocol Captures)


The NBD page is where a user is sent when he/she right-clicks on the NetworkBlockDevice line in the dissect pane and select "Wiki Protocol Page".
Feel free to update and add whatever information you want the page to display to be helpful for your NBD users.



I dont know how much wireshark useage you have, so forgive me if this is old news:
Also please note that in the request/response matching   wireshark will put a time field   nbd.time   in all matched responses that indicates the response time from the original request.
This field is in seconds and allows you to filter   or  colorize packets using
"nbd.time>0.010"    if for example you want to find all NBD commands that took longer than 10ms to complete.




On 11/1/06, Wouter Verhelst <wouter@...3...> wrote:
On Tue, Oct 31, 2006 at 05:12:38PM +0100, Wouter Verhelst wrote:
> On Tue, Oct 31, 2006 at 11:24:32AM +0000, ronnie sahlberg wrote:
> > List
> >
> >
> > 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.
>
> Could be me, but I can't seem to be able to enable it. When I go to
> Analyze->Decode as->Transport, then NBD isn't listed there (it is in a
> number of other places, though).

Actually, it autodetects that the conversation is NBD. Cool, I didn't
know wireshark could do that. So, it is me :)

One thing that might help is if the Info column would contain things
like "Read request" and "Read reply" instead of (or in addition to)
"NBD_CMD_READ 0x1000 28672" and "NBD_CMD_READ Error:0". Obviously Source
and Destination explain what's going on, but it would be slightly
clearer if they explicitly said that one is the request and the other is
the reply.

Other than that, it seems pretty neat. Oh, and you do handle the
NBD_CMD_DISC okay -- there isn't much more to say about that than "if we
see that pass by as a command, the connection will drop"...

--
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


Reply to: