Hello, > I am not clear on this. Is Client and server behind different > firewalls? No. The firewall is in between internet and <intranet, soho, home, etc.> > So the above doesn't apply to a) and it works? Yes. > What does this mean? Why is this connection from outside? 'usbip attach -r' tries to establish connection. > Is this something that could be solved by opening ports in > the firewall? Usually, http(80) and https(443) from inside is opened for internet Access. > Can we use server and client terminology which is we use in instead of > App and Dev. In https://www.kernel.org/doc/readme/tools-usb-usbip-README, I couldn't find the definition. Do you mean 'server' is a linux machine which has devices or linux machine which runs server daemon? In existing way, they are same. In new way, they are not. The linux machine which has device doesn't have server daemon. I'd like to confirm the definition to answer rest of questions. Best Regards, n.iwata // > -----Original Message----- > From: Shuah Khan [mailto:shuah.kh@xxxxxxxxxxx] > Sent: Friday, December 02, 2016 9:39 AM > To: fx IWATA NOBUO; valentina.manea.m@xxxxxxxxx; > gregkh@xxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx > Cc: fx MICHIMURA TADAO; Shuah Khan > Subject: Re: [PATCH v13 00/10] usbip: exporting devices > > On 11/23/2016 10:01 PM, fx IWATA NOBUO wrote: > > Hello, > > > Looks like you removed the text. Let's go back to the goals. > Can we use server and client terminology which is we use in instead of App > and Dev. It makes lot easier to understand. > > https://www.kernel.org/doc/readme/tools-usb-usbip-README > > >>1. Goal > > >>1-1) To give flexibility to direction of connection Using USB/IP in > >>internet, there can be two cases. > >> a) an application is inside firewall and devices are outside. > > This is the case Client is behind firewall and server is outside the > firewall. > > >>b) devices are inside firewall and an application is inside. > > I am not clear on this. Is Client and server behind different firewalls? > > >>In case-a, import works because the connection is from inside. > > > EXISTING) > > APP# usbip attach -----------(passed)--------> DEV# usbipd > > DEV# usbipd (blocked)|| <--------- APP# usbip attach > > So the above doesn't apply to a) and it works? > > >> In case-b, import doesn't works because the connection is from outside. > > What does this mean? Why is this connection from outside? > > >> Connection from device side is needed. This patch set adds the > >> direction of connection establishment. > > Is this something that could be solved by opening ports in the firewall? > > > >> Can you elaborate on the use-case a bit more? What does it mean to > >> "Connection from device side is needed"? > > > > I'd like to update ending part of use case as following. > > --- > > Firewall, proxy, or router in front of internet usually blocks > > connections from internet regarding all TCP ports. They opens some > > ports, usually HTTP(80) and HTTPS(443), for connection from inside. > > In combination with WebSocket proxy, USB/IP can establish connection > > from inside of the firewall. > > > > Enterprise/SOHO/Home Firewall/Proxy/Router Internet > > > > EXISTING) > > APP# usbip attach -----------(passed)--------> DEV# usbipd > > DEV# usbipd (blocked)|| <--------- APP# usbip attach > > > > NEW) > > DEV# usbip connect ----------(passed)--------> DEV# usbipa > > APP# usbipa (blocked)|| <--------- APP# usbip connect > > > > Attach operation can invite devices in internet but cannot invite > > devices from internet. On the other hand, connect operation can > > dedicate devices to internet but cannot dedicate devices in internet. > > The above isn't very clear. Do you mean to say, client can find devices > exported by a server? When you say Internet how many servers are we looking > at? Random servers or known servers? > > Current USB/IP use-cases are: > > - Server could export USB devices to virtual machines running on it. > Access is confined and limited to that one system. > - Server could export USB devices and clients as long as no firewalls > in between. > > In the above two models, user has permissions to use server and client. > In this new proposed model, how does this work? Who sets up the server to > export or push exports to clients. How does server know which clients to > push exports to? > > With a feature like this, it is important to understand the use-cases in > detail. > > thanks, > -- Shuah > > > --- > > > >> I would like to see server side and client side operations clearly. > >> It would help me understand the use-case you are trying to add. > > > > It's shown in README and manual page added by patch 9/10 as below. > > > > app:# insmod usbip-core.ko > > app:# insmod vhci-hcd.ko > > > > app:# usbipa -D > > - Start usbip daemon. > > > > dev:# (Physically attach your USB device.) > > > > dev:# insmod usbip-core.ko > > dev:# insmod usbip-host.ko > > > > dev:# usbip list -l > > - List driver assignments for USB devices and their busid. > > > > dev:# usbip connect --remote <host> --busid <busid> > > - Bind usbip-host.ko to the device with <busid>. > > - The USB device of <busid> is connected to remote host! > > > > dev:# usbip disconnect --remote <host> --busid <busid> > > - The USB device with <busid> is disconnected from remote host. > > - Unbind usbip-host.ko from the device. > > > >> I do have some concerns about security on client side. User sits on > >> the client side and it should be a pull from client side as opposed > >> to push from server side. > > > > Connection level consideration is described in "5. Security > > Consideration". As you know, USB/IP already has TCP wrapper option. > > With SSL or WebSocket(wss) tunneling proxy, client authentication can > > be applied using the proxies. > > > > I didn't write device level consideration. It's same as local device > > plug-and-play. I will add description below in cover letter and README. > > > > --- > > Udev rules can allow only known devices. To identify a device is > > remote, the local bus-id (KERNEL parameter in the rule) will be found > > the last in column of /sys/devices/platform/vhci_hcd/status[.N]. When > > device is found, the port number in USB/IP can be found in the first > > column of the matched line. The udev can finish the connection using > > detach operation with the port number. > > --- > > > >> It sounds like this patch series adds push from server side. > > > > Yes. > > But it's only the initiation request and response. > > URBs direction is just same as before. Applications send submit and > > unlink, devices process them. > > > > Your comment is at goal #1. I'm also considering goal #2. > > > > Thanks for reviewing, > > > > nobuo.iwata > > // > >> -----Original Message----- > >> From: Shuah Khan [mailto:shuah.kh@xxxxxxxxxxx] > >> Sent: Thursday, November 24, 2016 1:43 AM > >> To: fx IWATA NOBUO; valentina.manea.m@xxxxxxxxx; > >> gregkh@xxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx > >> Cc: fx MICHIMURA TADAO; Shuah Khan; Shuah Khan > >> Subject: Re: [PATCH v13 00/10] usbip: exporting devices > >> > >> On 11/21/2016 11:48 PM, Nobuo Iwata wrote: > >>> Dear all, > >>> > >>> This series of patches adds exporting device operation to USB/IP. > >>> > >>> NOTE: > >>> This patch set modifies only userspace codes in tools/usb/usbip. > >>> > >>> 1. Goal > >>> > >>> 1-1) To give flexibility to direction of connection Using USB/IP in > >>> internet, there can be two cases. > >>> a) an application is inside firewall and devices are outside. > >>> b) devices are inside firewall and an application is inside. > >>> In case-a, import works because the connection is from inside. > >>> In case-b, import doesn't works because the connection is from outside. > >>> Connection from device side is needed. This patch set adds the > >>> direction of connection establishment. > >>> > >> > >> Can you elaborate on the use-case a bit more? What does it mean to > >> "Connection from device side is needed"? > >> > >> I would like to see server side and client side operations clearly. > >> It would help me understand the use-case you are trying to add. > >> > >> I do have some concerns about security on client side. User sits on > >> the client side and it should be a pull from client side as opposed > >> to push from server side. > >> > >> It sounds like this patch series adds push from server side. > >> > >> thanks, > >> -- Shuah > >> > >>> NOTE: > >>> Directions of URBs requests and responses are not changed. Only > >>> direction of connection establishment initiated with usbip command > >>> is added to exsiting one. > >>> > >>> 1-2) To improve usability of operations When two Linux machines are > >>> in a small distance, it's OK to bind (makes > >>> importable) at device side machine and attach (import) at > >>> application side. > >>> If application is as cloud service or in blade server, it's not > >>> practical to attach from application side. It's useful to connect > >>> (export) from device side. This patch set adds the new operation to > >>> connect from device side. > >>> > >>> 2. What's 'exporting' device > >>> > >>> Exporting devices is not new. The request and response PDU have > >>> already been defined in tools/usbip/usbip/src/usbip_network.h. > >>> #/* Export a USB device to a remote host. */ > >>> #define OP_EXPORT 0x06 > >>> #define OP_REQ_EXPORT (OP_REQUEST | OP_EXPORT) > >>> #define OP_REP_EXPORT (OP_REPLY | OP_EXPORT) > >>> # struct op_export_request > >>> # struct op_export_reply > >>> #/* un-Export a USB device from a remote host. */ > >>> #define OP_UNEXPORT 0x07 > >>> #define OP_REQ_UNEXPORT (OP_REQUEST | OP_UNEXPORT) > >>> #define OP_REP_UNEXPORT (OP_REPLY | OP_UNEXPORT) > >>> # struct op_unexport_request > >>> # struct op_unexport_reply > >>> > >>> But they have not been used yet. This series adds new operations: > >>> 'connect' and 'disconnect' using these PDUs. > >>> > >>> EXISTING) - invites devices from application(vhci)-side > >>> +------+ > >> +------------------+ > >>> device--+ STUB | | application/VHCI > | > >>> +------+ > >> +------------------+ > >>> 1) usbipd ... start daemon > >>> = = = > >>> 2) usbip list --local > >>> 3) usbip bind > >>> <--- list bound devices --- 4) usbip list > --remote > >>> <--- import a device ------ 5) usbip attach > >>> = = = > >>> X disconnected 6) usbip detach > >>> 7) usbip unbind > >>> > >>> NEW) - dedicates devices from device(stb)-side > >>> +------+ > >> +------------------+ > >>> device--+ STUB | | application/VHCI > | > >>> +------+ > >> +------------------+ > >>> 1) usbipa ... start > >>> daemon = = = > >>> 2) usbip list --local > >>> 3) usbip connect --- export a device ------> > >>> = = = > >>> 4) usbip disconnect --- un-export a device ---> > >>> > >>> Bind and unbind are done in connect and disconnect internally. > >>> > >>> 3. The use cases > >>> > >>> EXISTING) > >>> > >>> In existing way, computers in small distance, having same user > >>> account, can be easily managed by a same user. Bind in local machine > >>> and attach in remote machine by the user. The devices can be > >>> exporsed automatically in the local machine, for example, at strat > >>> up. They can be attached from remote. > >>> > >>> When there are distributes linux nodes with USB devices in internet, > >>> they are exposed by bind operation at start up, server behind > >>> firewall can list and attach the devices. > >>> Internet > >>> Exposed +----------+ +--------+ > +--------+ > >>> +------+ |Linux |+ |Router, | |Service | > >>> +|device|--|Controller||-------------------|proxy, |----|on | > >>> |+------+ +----------+| |firewall| |Linux | > >>> +------+ +----------+ +--------+ +--------+ > >>> <--- attach(import) > >>> USB/IP + WS proxy WS proxy + > USB/IP > >>> > >>> NEW) > >>> > >>> Assuming that a server computer which runs application and VHCI is > >>> in a server room and device side machines are small distributed > >>> nodes outside of the server room, the operator of the server compter > >>> is different form the distributed nodes. The server computer may be > >>> in unattended operation. In the new way, after the daemon has been > >>> started, device can be connected with connect command in the > >>> distributed nodes. If the distributed nodes doesn't have user > >>> interface, the connect command can be executed from start up procedure. > >>> > >>> In another senario to connect devices to a Linux based cloud service > >>> using WebSocket proxy, it's needed to establish connection from a > >>> device inside of firewall to a service outside. Exporting is > >>> suitable for the senario. > >>> > >>> Home/SOHO/Intranet Internet > >>> +----------+ +--------+ > +--------+ > >>> +------+ |Linux |+ |Router, | |Internet| > >>> +|device|--|Controller||----|proxy, |-------------------|service | > >>> |+------+ +----------+| |firewall| |on Linux| > >>> +------+ +----------+ +--------+ +--------+ > >>> connect(export) --> > >>> USB/IP + WS proxy WS proxy + > USB/IP > >>> ex) > >>> Device Service > >>> sensors ......................................... environment > >>> analysis cameras ......................................... > >>> monitoring, recording ID/biometric readers > >>> ............................ authentication > >>> > >>> Connection from outside firewall is usually blocked. > >>> So existing import request sent with attach command doesn't work. > >>> > >>> # usbipd (blocked)|| <--------- # usbip attach > >>> > >>> Firewall opens some ports, usually HTTP(80) and HTTPS(443), from inside. > >>> Then export request sent with new connect command works. > >>> > >>> # usbip connect -----------------------------> # usbipa > >>> (passed) > >>> > >>> 4. Combination with vUDC > >>> > >>> New operations work with vUDC. --device option specifies vUDC mode > >>> as well as list operaion. With stub, connect and disconnect execute > >>> bind and unbind internally. With vUDC, they do not execute bind and > unbind. > >>> They are done by UDC interface. > >>> > >>> 5. Security consideration > >>> > >>> When application side daemon is not started, this patch set doesn't > >>> affect exsiting security. > >>> > >>> Daemons accept following requests form network : > >>> EXISTING) 'list --remote' and 'attach' > >>> NEW) 'connect' and 'disconnect' > >>> > >>> TCP wrappers allows and/or denies network access. It is enabled when > >>> the daemons are compiled with ./configure --with-tcp-wrappers. > >>> > >>> When the daemons are running with SSL or Secure WebSocket tunneling > >>> proxy, the proxy can use client authentication with certificate files. > >>> > >>> 6. Mixed usage > >>> > >>> Both existing and new way work in same machines simultaneously. > >>> Status of devices and ports are controlled in stub and vhci driver. > >>> > >>> 7. Wording > >>> > >>> Adding the new operation, some inconsistnecies in wording are > >>> appeared in documentation, function name, etc. If needed, they are > fixed. > >>> > >>> 'export' is used for bind and 'exported' is used for bound. They are > >>> changed to 'make importable' and 'imported' respectively. The words > >>> are not new. For example, in the output of port operation, 'imported > >>> devices' is already used. > >>> > >>> 'client' and 'server' are switched between existing and new operation. > >>> Sometimes they implies device-side and application-side. So, words > >>> 'device-side' and 'application-side' are used in documentations as > >>> needed for clarity. > >>> > >>> --- > >>> Version information > >>> > >>> This series is divided from "USB/IP over WebSocket" patch set. > >>> Rest of the set will be sent as another series. > >>> > >>> v13) > >>> # Recreated based on linux-next 20161117. > >>> # Updated cover letter: added goal, rewrote overview as explanation > >>> of 'exporting' and added that this patch dosn't affect security > >>> condition in existing usage. > >>> # Moved protocol documentation as the last patch. > >>> # Added explanation to each patch. > >>> # Removed copyright from usbip_bind.c, usbip_unbind.c, > >>> usbip_network.h and usb_list.c in which size of modification is > >>> small and functional change is not included. > >>> # Fixed help string about position of --parsable option. > >>> > >>> v12) > >>> # Recreated based on linux-next 20161012. > >>> # Fixed checkpatch a warning about symbolic permission. > >>> # Fixed checkpatch warnings about traling space in a document. > >>> > >>> v11) > >>> # Corrected program name of each daemon which are used in version > >>> string, info messages and daemon name for tcp wrappers. > >>> # Added description about tcp wrappers in security consideration of > >>> cover letter. > >>> # Added security consideration for existing requests in > >>> contradistinction to new requests. > >>> # Recreated based on linux-next 20160928. > >>> > >>> v10) > >>> # Recreated based on linux-next 20160810. > >>> > >>> v9) > >>> # Moved a set_nodelay() from usbipd_dev.c to usbipd.c to affect both > >>> device side and application side daemon. > >>> # Removed redundant blank line at the end of files. > >>> > >>> v8) > >>> # Divided into smaller patches. > >>> # Excluded low-related patches. > >>> # Improved change log. > >>> # Changed info level logs in usbip_ux.c to debug level logs. > >>> # Added options to vUDC. > >>> # Tested with vUDC. > >>> > >>> v7) > >>> # Removed userspace transmission and WebSocket command/daemon. > >>> # Fixed checkpatch errors and warnings. > >>> > >>> v6) > >>> # Added __rcu annotation to a RCU pointer to clear sparse warnings. > >>> # Corrected a copy to RCU pointer with rcu_rcu_assign_pointer(). > >>> # Added __user annotations to arguments of read/write method. > >>> # Added static to some functions which are not called from other files. > >>> # Removed unnecessary EXPORT_SYMBOLs. > >>> > >>> v5) > >>> # Added vendor/pruduct name conversion to port command. > >>> # Put initial value to pool_head in name.c. > >>> # Fixed list command exception when host option is omitted. > >>> # Fixed exception in case gai_strerror() returns NULL. > >>> # Fixed WebSocket connection close via proxy. > >>> # Fixed to stop WebSocket ping-pong on connection close. > >>> # Removed redundant usbipd daemon option. > >>> # Removed redundant SSL code had not been deleted. > >>> # Removed an unused local variable in WebSocket code. > >>> # Modified C++ reserved word in names.c as same as headers. > >>> > >>> v4) > >>> # Fixed regression of usbip list --remote > >>> > >>> v3) > >>> # Coding style for goto err labels are fixed. > >>> # Defined magic numbers for open_hc_device() argument. > >>> # Corrected include .../uapi/linux/usbip_ux.h as <linux/usbip_ux.h>. > >>> # Modified parameter notation in manuals not to use '='. > >>> # Fixed inappropriate version definition in > >>> tools/.../websocket/configure.ac. > >>> # Remved unnecessary COPYING and AUTHORS fil from tools/.../websocket/. > >>> # Added -version-info to libraries in tools/.../src. > >>> > >>> v2) > >>> # Formatted patches from linux-next. > >>> # Fixed change log word wrapping. > >>> # Removed SSL patches. > >>> # Fixed a bug that vendor and product names are not shown by 'usbws > >>> list -l' because usbip_names_init() was not called in libusbip.la. > >>> > >>> Thank you, > >>> > >>> Nobuo Iwata <nobuo.iwata@xxxxxxxxxxxxxxx> // > >>> > >>> *** BLURB HERE *** > >>> > >>> Nobuo Iwata (10): > >>> usbip: exporting devices: modifications to network header > >>> usbip: exporting devices: modifications to host side libraries > >>> usbip: exporting devices: new connect operation > >>> usbip: exporting devices: new disconnect operation > >>> usbip: exporting devices: modifications to daemon > >>> usbip: exporting devices: modifications to attach and detach > >>> usbip: exporting devices: new application-side daemon > >>> usbip: exporting devices: change to usbip_list.c > >>> usbip: exporting devices: chage to documenattion > >>> usbip: exporting devices: modifications to protocol text > >>> > >>> Documentation/usb/usbip_protocol.txt | 204 ++++++++++++++-- > >>> tools/usb/usbip/Makefile.am | 2 +- > >>> tools/usb/usbip/README | 70 ++++-- > >>> tools/usb/usbip/doc/usbip.8 | 136 +++++++++-- > >>> tools/usb/usbip/doc/usbipa.8 | 78 +++++++ > >>> tools/usb/usbip/doc/usbipd.8 | 38 +-- > >>> tools/usb/usbip/libsrc/usbip_host_common.c | 6 +- > >>> tools/usb/usbip/libsrc/usbip_host_common.h | 8 +- > >>> tools/usb/usbip/libsrc/vhci_driver.c | 118 ++++++++-- > >>> tools/usb/usbip/libsrc/vhci_driver.h | 7 +- > >>> tools/usb/usbip/src/Makefile.am | 12 +- > >>> tools/usb/usbip/src/usbip.c | 15 +- > >>> tools/usb/usbip/src/usbip.h | 10 +- > >>> tools/usb/usbip/src/usbip_attach.c | 50 +--- > >>> tools/usb/usbip/src/usbip_bind.c | 4 +- > >>> tools/usb/usbip/src/usbip_connect.c | 228 > ++++++++++++++++++ > >>> tools/usb/usbip/src/usbip_detach.c | 13 +- > >>> tools/usb/usbip/src/usbip_disconnect.c | 215 +++++++++++++++++ > >>> tools/usb/usbip/src/usbip_list.c | 17 +- > >>> tools/usb/usbip/src/usbip_network.h | 4 +- > >>> tools/usb/usbip/src/usbip_unbind.c | 4 +- > >>> tools/usb/usbip/src/usbipd.c | 258 > >> +++------------------ > >>> tools/usb/usbip/src/usbipd.h | 39 ++++ > >>> tools/usb/usbip/src/usbipd_app.c | 242 > +++++++++++++++++++ > >>> tools/usb/usbip/src/usbipd_dev.c | 252 > >> ++++++++++++++++++++ > >>> 25 files changed, 1631 insertions(+), 399 deletions(-) create mode > >>> 100644 tools/usb/usbip/doc/usbipa.8 create mode 100644 > >>> tools/usb/usbip/src/usbip_connect.c > >>> create mode 100644 tools/usb/usbip/src/usbip_disconnect.c > >>> create mode 100644 tools/usb/usbip/src/usbipd.h create mode 100644 > >>> tools/usb/usbip/src/usbipd_app.c create mode 100644 > >>> tools/usb/usbip/src/usbipd_dev.c > >>> > >> > >> > >> -- > >> Shuah Khan > >> Sr. Linux Kernel Developer > >> Open Source Innovation Group > >> Samsung Research America(Silicon Valley) shuah.kh@xxxxxxxxxxx > > > > > -- > Shuah Khan > Sr. Linux Kernel Developer > Open Source Innovation Group > Samsung Research America(Silicon Valley) shuah.kh@xxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
