similar to: nbdkit does not support NBD_OPT_GO?

This is only lightly tested (against just qemu NBD client), and the code might be structured a little better as the _negotiate_handshake_newstyle_options function has now grown to be huge. Anyway works for me. Rich.

On Sat, Aug 4, 2018 at 10:58 PM Nir Soffer <nsoffer@redhat.com> wrote: > On Sat, Aug 4, 2018 at 4:04 PM Richard W.M. Jones <rjones@redhat.com> > wrote: > >> This is only lightly tested (against just qemu NBD client), and the >> code might be structured a little better as the >> _negotiate_handshake_newstyle_options function has now grown to be >> huge.

On 08/02/2018 11:51 AM, Nir Soffer wrote: > When trying to connect to nbdkit with imageio nbd client, I get this error: > > $ rm -f /tmp/nbd.sock && nbdkit file file=/var/tmp/fedora-27.img -e export > -U /tmp/nbd.sock > > ovirt_imageio_common.nbd.Error: The option sent by the client is unknown by > this server implementation [message=]) Correct, nbdkit has not yet

There's no substantial difference over v1, I simply fixed a few whitespace issues, moved one struct around and tidied up the comments. Rich.

On Sat, Aug 4, 2018 at 4:04 PM Richard W.M. Jones <rjones@redhat.com> wrote: > This is only lightly tested (against just qemu NBD client), and the > code might be structured a little better as the > _negotiate_handshake_newstyle_options function has now grown to be > huge. Anyway works for me. > Works for my python nbd client: $ rm -f /tmp/nbd.sock && src/nbdkit -f

Actually I was wrong, there *is* one substantive change over v1, which is this: > + /* The client is buggy. The last option must be NBD_OPT_GO or > + * NBD_OPT_EXPORT_NAME. > + */ > + else { > + nbdkit_error ("client options list didn't finish with NBD_OPT_GO " > + "or NBD_OPT_EXPORT_NAME"); > + return -1; > + } > + >

On 08/06/2018 09:31 AM, Nir Soffer wrote: > Eric, can you point us to the part of the spec allowing ignoring the export > name sent by the client? Nothing in the NBD spec requires the server to reject unknown export names. So nbdkit never rejects export names (which means it behaves as if all names work, regardless of whether or not it was the name it was configured with, since it

Some of these affect attempts to connect to older qemu-nbd versions, some of them were triggered by manual edits to qemu-nbd source code to provoke various other compliant (if uncommon) server behaviors. Eric Blake (4): starttls: Skip error payload if falling back to unencrypted states: Reject payload to NBD_REP_ACK meta-context: Skip error payload if server lacks meta_context states: Add

I'm hoping to implement .extents for the nbd plugin; this is a prerequisite. I'm not sure about patch 3 - if we like it, I'll squash it to 2, if we don't, I think we are okay just dropping it. I'm also wondering if we have to worry about malicious plugins that don't populate the entire .pread buffer in an effort to get nbdkit to expose portions of the heap; my patch 7 loses

Updated based on other changes that have happened in the meantime: - rely more on cleanup.h (throughout) - split structured read for easier review (patch 2 and 3 were combined in v1) - rely on nbdkit not leaking a server's partial answer (patch 3) - add tests (patch 5) - other bug fixes I found while testing it - drop EOVERFLOW patch for now; it will be separate once upstream NBD protocol

v2 was here: https://lists.debian.org/nbd/2022/11/msg00030.html The bulk of the changes since then are: - forbid NBD_OPT_EXPORT_NAME once extended headers are negotiated (Wouter) - consistently use 'maximum payload', rather than a haphazard mix of 'maximum block payload' (Vladimir) At this point, I want to make sure we are happy with the spec before re-posting patches for

--- src/connections.c | 233 +++++++++++++++++++++++++++++++++++++--------- src/protocol.h | 27 ++++-- 2 files changed, 209 insertions(+), 51 deletions(-) diff --git a/src/connections.c b/src/connections.c index ba6e91d..4e9b191 100644 --- a/src/connections.c +++ b/src/connections.c @@ -75,7 +75,9 @@ struct connection { void **handles; size_t nr_handles; + uint32_t cflags;

The NBD spec was recently patched (nbd.git commit 7827f3ae and friends) to require NBD_OPT_GO for baseline interoperability, with the aim of fewer servers and clients falling back to NBD_OPT_EXPORT_NAME. And since nbdkit as server recently started supporting NBD_OPT_GO (commit f7dd9799), our nbd client as plugin should take advantage of it. This patch is a prerequisite to teaching the nbd plugin

These are a couple of patches in preparation for the Block Status implementation. While the patches (especially the second one) are very large they are really just elementary code motion. Rich.

Fuzzing with afl found a bug where a 27 byte client sequence can cause nbdkit to report a strange error message: $ printf %s $'000\1IHAVEOPT000\6'$'000\7'$'000\1x00' | tr 0 '\0' | ./nbdkit -s memory size=1m >/dev/null nbdkit: memory: error: client exceeded maximum number of options (32) The culprit? The client is hanging up on a message boundary, so

On Tue, Sep 24, 2019 at 05:24:34PM -0500, Eric Blake wrote: > On 9/24/19 4:07 PM, Richard W.M. Jones wrote: > > /* New-style handshake server reply when using NBD_OPT_EXPORT_NAME. > > * Modern clients use NBD_OPT_GO instead of this. > > @@ -167,7 +167,7 @@ struct nbd_new_handshake_finish { > > uint64_t exportsize; > > uint16_t eflags; /*

Hi Eric, Busy days, busy times. Sorry about the insane delays here. On Mon, Nov 14, 2022 at 04:46:51PM -0600, Eric Blake wrote: > Commit 9f30fedb improved the spec to allow non-payload requests that > exceed any advertised maximum block size. Take this one step further > by permitting the server to use NBD_EOVERFLOW as a hint to the client > when a request is oversize (while

Patch 1 played with an early draft of Rich's Fedora 30 libnbd package: https://bugzilla.redhat.com/show_bug.cgi?id=1713767#c17 Note that comment 21 provides a newer package 0.1.1-1 with a different API; and that libnbd has more unreleased API changes in the pipeline (whether that will be called 0.2 or 0.1.2); so we'll have to tweak things based on what is actually available in distros.

Since the v1 series (0/4, at [1]), I've applied patches 1 and 2, rewritten patch 3 [Forbid NUL in export and context names] into patch 4 here, patch 4 there turned into patch 6 here, and everything else here is new. [1]https://www.redhat.com/archives/libguestfs/2019-September/msg00180.html I don't know if there is a handy reusable function for checking whether a string contains valid

We should have only one NBD protocol file. Let's make nbdkit's version the canonical one, and use it in libnbd. Rich.