Re: [Nbd] tech documentation

[Wouter Verhelst <wouter@...3...>]

On Thu, Oct 19, 2006 at 11:49:19AM -0500, Phil Howard wrote:
> On Thu, Oct 19, 2006 at 03:19:36PM +0200, Wouter Verhelst wrote:
[...]
> | some additional bookkeeping (not sure that's worth it), or increase the
> | request size (but then you increase the average amount of useless data
> | that gets pumped over the network, not very good for througput).
> 
> Looks like the first request in a new connection I just made was for 16384
> bytes.  Well, maybe not the request, but that much was sent in the reply.

Hmm, okay; so I was wrong then. Oh well, nbd-server doesn't care anyway;
I don't know the kernel side of things :-)

[...]
> WRT to your dissector request, I already have a tool that could be extended
> to do that.  It is a TCP relayer daemon.  I use it for a lot of things.  It
> has a capture option.  It captures raw.  There is a capture formatter that
> just gives traffic direction, length, and content, formatted for visual
> display (characters, escape codes, octal bytes).  I could make a capture
> formatter that understand NBD.

[...]
> Obviously, there is no security in this.  The administrator is clearly
> responsible for confining the connection to a safe and trusted network.

Yes, absolutely. nbd-server has a minimal way to limit something to a
given IP address, but that's not very advanced; having something else to
limit the connection (a firewall, probably) is an absolute requirement
whenever security is a concern.

> | > FYI, I am planning to look into implementing an NBD client directly into
> | > the QEMU emulator in system mode.  This would allow an emulated system
> | > to have one or more block devices mapped onto the network block devices
> | > served from nbd-server anywhere without using NBD in the host kernel.
> | > And the nbd-server can even be on the same machine running QEMU without
> | > the deadlock issues (nbd-server runing in the guest OS under QEMU would,
> | > of course, still have those issues).  This is another reason I wanted to
> | > see technical protocol details.
> | 
> | Right. I hope the blog post I pointed you to is sufficient; there really
> | isn't much else.
> 
> It does seem quite simple.  I'll try first to make a dissector in the form
> of a formatter for my tcprelay program, and use that to work up understanding
> what all is happening.

That'd work :-)

> What form of dissector would you have wanted:

Ethereal is a sniffer, with support for loads of network protocols; it
can visualize them, and allow you to see what is going over the wire
without requiring access to one or the other end. Obviously it requires
access to some point in between; but obviously anything like a hub,
managed switch, or 10BASE2 cable will work.

An ethereal dissector is a module that gets compiled into it and which
decodes a specific protocol, so that you can see the value of all the
fields and whatnot. I had a look at it once, and the API is so that you
can say "I have a protocol which is situated in this layer"; ethereal
will then only give you the data from that layer, so the IP and/or TCP
decoding is already done.

That being said...

> 5.  Something to dissect/format captured data from a tcprelay intercept
>     program?

... anything which can read libpcap data and format it somehow would
work, too; it doesn't /have/ to be ethereal (though I know that best).
But if you use that, it will do the IP and TCP decoding for you, so that
you can focus on "just" the NBD bits.

So, this option 5 would be the closest.

> A disadvantage of an intercept program is that the program has to be
> started before setting up the device connection, and the connection has
> to be taken down to stop capturing.
> 
> A disadvantage of a packet capture (e.g. via libpcap or the like) is
> that the implementation has to understand IP and TCP enough to put the
> corrected octet stream back together before any NBD dissecting can even
> take place.
[...]

Yes, that's right. I'd suggest you do whatever suits you best; I've been
maintaining the NBD tools for quite a while now without a dissector,
it'd be silly to request from you that you do things my way now,
especially if that would require you to put in quite some extra work...

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