From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMCVt-0003Dz-Pi for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:30:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMCVo-0001AV-3H for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:30:49 -0500 References: <1453208963-16834-1-git-send-email-berrange@redhat.com> <1453208963-16834-10-git-send-email-berrange@redhat.com> <569E60E8.2040001@redhat.com> <20160119164443.GP26662@redhat.com> From: Paolo Bonzini Message-ID: <56A0B34B.6060103@redhat.com> Date: Thu, 21 Jan 2016 11:30:35 +0100 MIME-Version: 1.0 In-Reply-To: <20160119164443.GP26662@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org On 19/01/2016 17:44, Daniel P. Berrange wrote: >> > As a first reaction, I would really avoid magic unless the server >> > provides a single exports. But even in that case, I would prefer to >> > have some synchronization between the server and client command-line= . >> >=20 >> > Is an empty NBD_OPT_EXPORT_NAME valid? What about using new-style >> > negotiation with empty NBD_OPT_EXPORT_NAME if TLS is requested? > The main goal here is to ensure the NBD client gets a decent error > message if it tries to connect without TLS. Even if we are using > the fixed new style protocol, the client code will send > NBD_OPT_EXPORT_NAME as the first thing it does. Thanks to a bit of > crazyness is the NBD protocol spec, the server is unable to reply > with an error message to NBD_OPT_EXPORT_NAME. >=20 > So if the client connected to a server reqiuring TLS and does not > request TLS enablement, the server will have no choice but to just > close the connection with no error. I think this will be pretty > nasty for users trying to debug problems with TLS. That's fine. I'm just not sold on using the first answer from NBD_OPT_LIST as the argument to the subsequent NBD_OPT_EXPORT_NAME. In other words, I would prefer to do the following for no export name: 1) server, no TLS: accept either old-style negotiation or new-style negotation with an empty ("") export name; NBD_OPT_LIST returns a single export name, "". 2) server, TLS: accept only new-style negotiation with an empty ("") export name; NBD_OPT_LIST returns a single export name, "". 3) client, no TLS: use old-style negotiation; if the server rejects old-style negotiation, mention the possibility that the server requires T= LS 4) client, TLS: use new-style negotiation with an empty ("") export name. The only interesting case for named exports is client, no TLS. Then you can just send a dummy NBD_OPT_LIST unconditionally, and use the result to provide a good error message if the server requires TLS. If it makes the code simpler to use NBD_OPT_LIST always, even if the client supports TLS (making the sequence NBD_OPT_STARTTLS, NBD_OPT_LIST, NBD_OPT_EXPOR_NAME), then that's fine too. Paolo