Re: [Nbd] tech documentation

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

On Thu, Oct 19, 2006 at 04:24:59PM -0500, Phil Howard wrote:
> On Thu, Oct 19, 2006 at 09:23:12PM +0200, Wouter Verhelst wrote:
> 
> | > 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.
> 
> I could at least add some code that expands that test a bit by allowing
> a CIDR format specified subnet range.

Yes, I intend to write something similar for the 2.9 release.

> | > 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.
> 
> Strange.  I've never heard of Ethereal.  I'll have to go look at it.

Strange indeed :)

I should add that it's called wireshark these days, because of trademark
madness (it wasn't at the time of that post).

> I tend to not like sniffers like that for the TCP/SCTP layers.  The reason
> is because it can lose packets.  Since it isn't participating in the TCP
> or SCTP layer protocol, it can't request recovery, and thus get out of
> sync.  If what it loses is an NBD header, it won't know where the next
> header is in what data it does manage to get.

It's pretty intelligent in that regard; it will obviously give an error,
but I believe dissectors will also be informed that packets are missing
so that it can handle this.

> | 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.
> 
> That's certainly what I would want to focus on.

Thought as much :)

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