Forwarding USB devices over the network using USB Network Gate.

💖 Do you like it? Share the link with your friends

Good afternoon, amigos, I’m glad that you visited my site, today we will look at the question of how to organize USB over a network and how to use it in virtualization. The topic is quite relevant, and such a task is encountered more and more often.

usb via network

As you already know, virtualization has been a part of our lives for a long time. Server capacities are growing, and naturally technologies for their rational use have emerged, implying isolation and normal utilization of resources, which has given rise to virtual machines, which are already used in hosting and data centers. I have already talked about all this, if you are interested, look at the links on the left and above.

As you know sometimes some licensed programs, I require for usb work key. Previously, in the classic version, when there were only physical servers, there were no problems with the operation of such a scheme, but with the advent of virtualization it came to light.

Unfortunately, some hypervisors do not have the ability to forward directly from the server USB devices A. An example is Hyper-V from Microsoft, which since 208 still does not carry such an opportunity, unlike the vMvare company, which allows this and I have already told you how to forward a USB modem to vmware esxi.

Don’t rush to get upset, followers of the Redmond giant, technology is coming to your rescue USB over IP or AnywhereUSB. USB over IP allows you to connect usb via network.

AnywhereUSB is small network usb hub. Below are sample models on the market.

  • AnywhereUSB /2 – 2 USB ports


  • AnywhereUSB/ 5 – 5 USB ports


  • AnywhereUSB /14 – 14 USB ports



Setting up AnywhereUSB

Let's look at how the hardware is configured in order to make USB access over the network.

This is what it will look like.


There are several interfaces for setting up and managing the device:
• Web interface for configuration, monitoring and administration;
• AnywhereUSB configuration utility;
• Telnet Command-Line Interface;
• Simple Network Management Protocol (SNMP).

To configure the device, consider the Web interface - as the most convenient and simplest option.

IP address management

There are several options for assigning an IP address to AnywhereUSB:
• Static IP;
• Dynamic IP assignment - Using Dynamic Host Configuration Protocol (DHCP);
• Auto Private IP Addressing (APIPA), best known as Auto-IP;

How do you understand the most The right way this is a static IP address. It is set in the Network Configuration item.


In the same menu it is very convenient to set the network services available on it.



On the Connection Management tab you can view your current connections.



Now, what needs to be done next on the virtual machine, everything is incredibly logical here, you need to install drivers from AnywhereUSB there and set the IP address of the device. As you can see, I have already connected it and it has an internal IP address.


By using special utility, Anywhere View can check the availability and busyness of all devices. Perhaps this is the simplest and most reliable method of forwarding tokens, flash drives and various modems to your virtual machines, the devices themselves cost differently, but if you have already spent money on software and hypervisors, I think buy this too if necessary :).


These instructions are correct starting from version 2.

It seems like, why write anything else when there are official instructions? However, there is something here that is not there.

There are two options for transferring a USB device to guest system:

  • transfer a specific device to the “guest”;
  • transfer the USB port to which this device is connected.

Forwarding USB devices

If you have a USB security key, or external storage, then it is more convenient to transfer the device itself directly to the guest system, regardless of which USB port this device is physically connected to. After all, during maintenance, we can connect it to a different connector next time.

# lsusb Bus 002 Device 002: ID 8087:8000 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 004: ID 051d:0002 American Power Conversion Uninterruptible Power Supply Bus 003 Device 003: ID 051d :0002 American Power Conversion Uninterruptible Power Supply Bus 003 Device 002: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

We find the device we need and take its ID, which we will use.

My task was to forward UPS.
(The situation is actually not typical, it’s more like a series of how it shouldn’t be: To the server and network hardware 2 of the simplest uninterruptible power supplies for workstations were supplied. UPS turned out to be delicate and began to scream with or without reason. In order to quickly cut their voice and not yet have to deal with managing the UPS from Debian, it was decided to attach two uninterruptible power supplies to the Windows guests.)

At this stage, I discovered that both devices I needed had the same ID... But let’s try.

Forwarded devices are registered in configuration file the corresponding virtual machine.

# nano /etc/pve/qemu-server/101.conf usb0: host=051d:0002

Rebooted. The device was picked up, everything seemed to be fine. But then we remember that the second device has the same identifier. How to distinguish them? And indeed, experience has shown that if you assign the same identifier to two virtual machines, they will take the same device from each other when turned on. Despite the fact that the host system has several USB devices with this identifier.

This is where we remember that there is another way of forwarding.

USB port forwarding

We need to determine which port the device we need is connected to.

First way:

# lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M |__ Port 4: Dev 2, If 0, Class=HID, Driver=usbhid, 1.5M |__ Port 7: Dev 3, If 0, Class=HID, Driver=usbfs, 12M |__ Port 8: Dev 4, If 0, Class=HID, Driver=usbfs, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/ 8p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

As it turned out later, the devices I needed were on bus 3, ports 7 and 8. But for now this is not obvious to us, and here is the second option:

Qm monitor qm> info usbhost Bus 3, Addr 4, Port 8, Speed ​​12 Mb/s Class 00: USB device 051d:0002, Back-UPS XS 650CI FW:892.R2.I USB FW:R2 Bus 3, Addr 3, Port 7, Speed ​​12 Mb/s Class 00: USB device 051d:0002, Back-UPS XS 650CI FW:892.R2.I USB FW:R2 Bus 3, Addr 2, Port 4, Speed ​​1.5 Mb/s Class 00: USB device 046d:c00c, USB Optical Mouse

Here we clearly see who is who. And now boldly:

# nano /etc/pve/qemu-server/101.conf usb0: host=3-7

To complete the picture, I’ll supplement the instructions with an example from the official documentation.

The following option is possible:

Qm monitor qm> info usbhost Bus 3 , Addr 2, Port 1.2 , Speed ​​1.5 Mb/s Vendor Specific: USB device 0529:0001, HASP 2.17

One of the blog readers, Vovets666, tried out the free USBIP software and suggested writing an article about it.

Disclaimer:
everything described below is my personal vision of the problem and ways to solve it, which is not the ultimate truth. It is quite possible that there are other options, I would be happy to hear about them. As instructions for working with the software, we used materials found on the Internet, I don’t even remember where... In addition, being a Windows administrator, I am quite superficially familiar with Linux, I worked under deadline conditions and had a lot of time to study hardware/dance with tambourines I didn’t, so I’m describing how I did it to make it work, and I’m sure there are other ways.

So, we have virtual machines - 1C servers, raised on MSWindowsServer 2008R2. For the software to work, server HASP keys connected to them are required. As you know, it is impossible to directly connect them to a VM on Hyper-V. Task: somehow forward HASP keys to virtual machines, preferably using a minimum of additional hardware and license costs.

(Offtopic: 1C in Lately it became possible to license software without using HASP keys (something like activation using PIN codes). But there are some nuances: exchanging for a license with software activation is not free, if you change the configuration of the machine, re-activation is required, after a certain limit, permission to activate remains at the discretion of technical support, which is not at all an ice-breaker. Therefore, it was decided to use old way with HASP keys).

Options considered:

- a method provided by Microsoft (though for other purposes):
RemoteFX+RDP7.1. I didn’t like it for the following reasons: equipment with RemoteFX support is required, additional services must be installed on the 1C server (remote desktop access service), an RDP session must be constantly hanging from the host to the virtual machine, through which the key is forwarded, a client license is required to access RDS . Perhaps I am mistaken in some of the points on this list, but the total number of them killed the method in the bud.

— hardware devices from third-party manufacturers. Disadvantages: they cost money, and some devices had problems with compatibility with the operating systems they were using (for example, the Ubox 4100 that we have) and which the manufacturer did not intend to solve. Now the problems seem to have been resolved (in other models), but the residue remains.

- Third-party software. Disadvantages: they require a separate machine to work as a server for USB devices and, as a rule, are paid. After searching
of acceptable software, it turned out that of all the software discovered, only the USBIP package is free for commercial use. I stopped there.

The installation and configuration of the software itself did not cause any big problems; the package included a short manual, plus the Internet.

The USBIP () package requires two configured machines to work: a server (the key is directly connected to it) and a client (this key is forwarded to it). Server room
The USBIP part exists only under Linux, the client part exists under Linux and Windows (including 7 and 2008R2).

1) Installing a server (a machine into which a USB device is connected).

As a server we use a machine with installed Linux. I used Linux Ubuntu v.11.04 (Lubuntu build, which is declared to be the least demanding of resources) as the simplest (for me) system: installed without any problems, automatically picks up new connected USB devices, after installation the necessary components are installed by default, in addition, USBIP is present in the repository. In order to save on hardware, this machine was created as a virtual one, raised on an existing ESXi 4.1 host, and a HASP key from the host was sent to it in the standard ESXi way.

The installation did not cause any problems: we install the system, connect it to the network, issue an IP, install USBIP and the components necessary for operation through the package manager. In addition, VMware tools were installed (since this machine is a VM on ESXi).

Just in case, let me remind you how this is done:

From the VMware snap-in we connect the disk with the software (Inventory -> Virtual Machine -> Guest -> Install/Upgrade VMware Tools). From this disk we unpack the archive with the software onto the desktop. We launch the terminal and type in it:

<имя пользователя>@<имя машины>:~$ sudo<путь до файла>\vmware-install.pl —default

2) Server TuningUSBkeys.

Let's launch the terminal. Further actions– from the command line.

· Load the following modules.

<имя пользователя>@<имя машины>:~$ sudo modprobe usbip

<имя пользователя>@<имя машины>:~$ sudo modprobe usbip_common_mod

· Launch usbip as a system daemon:

<имя пользователя>@<имя машины>:~$ sudo usbipd D

we get:

Bind usbip.ko to a usb device to be exportable!

<имя пользователя>@<имя машины>:~$

Attention! You must first start the daemon and only then connect devices, otherwise errors may occur on the client when connecting. (see notes)

· To view connected USB devices, run the command

<имя пользователя>@<имя машины>:~$ lsusb

we get a list of connected USB devices with their identifiers like:

Bus XXX Device YYY: ID VendorID:DeviceID< Name devices>

something like:

Bus 002 Device 004: ID 0529:0001 Aladdin Knowledge Systems HASP v0.06

Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Remember the combination VendorID:DeviceID

· Execute the command:

<имя пользователя>@<имя машины>:~$ sudo usbip_bind_driver --list

USBIP checks the list of connected equipment and displays it indicating their bus-ID in the form:

— busid 2-1 (0529:0001)

2-1:1.0 -> none

- busid 2-2 (0e0f:0002)

2-2:1.0 -> hub

……..

In this case, the bus-ID indicating the USB device we need is “2-1”.

· Now we connect the device to the server. We dial:

<имя пользователя>@<имя машины>::~$ sudo usbip_bind_driver --usbip 2-1

we get:

** (process:1483): DEBUG: 2-1:1.0 -> none

** (process:1483): DEBUG: write “add 2-1” to /sys/bus/usb/drivers/usbip/match_busid

** Message: bind 2-1 to usbip, complete!

The device is connected to USBIP, access from the local server machine is lost.

· You can also see which devices are connected to USBIP in this moment. To do this we type:

<имя пользователя>@<имя машины>:~$ sudo usbip_bind_driver --list

We get:

— busid 2-1 (0529:0001)

2-1:1.0 -> usbip

- busid 2-2 (0e0f:0002)

2-2:1.0 -> hub

The device with bus-ID 2-1 is connected to USBIP. The system can transmit data about this USB device from your system to remote clients.

Server setup is complete. If necessary, you can add and remove
exported devices.

OptionsUSBIP - Linuxservers Usage: usbip_bind_driver

-?, --help call
certificates
--usbip busid make a device exportable
-other busid use a device by a local
driver
--list print usb devices and them
drivers
--list2 print usb devices and them
drivers in parseable mode
—allusbip make all devices exportable

3) MS Windows client settings

· Download the distribution. We will need both versions - 0.1 and 0.2.

· Install USB/IPEnumenator. It is installed as an arbitrary system device with drivers on disk. We take the drivers from the distribution version 0.2:

For Windows XP:

1. Unpack the files into a local folder.

2. In the Control Panel, click “Installing Hardware”, in the Wizard’s Welcome Window that opens, click “Next”.

3. Select “Yes, the device is already connected” -> “Next”.

4. Select “Add a new device” -> “Next”.

5. Select “Installing equipment selected from the list manually” -> “Next”.

7. Select “Install from disk”, -> “View”, select the folder with the unzipped driver -> “OK”.

9. “The wizard is ready to install new equipment” -> Select “Next” -> Finish.”

For Window 7 (and 2008r2):

1. To allow installation of unsigned drivers: run cmd from
administrator and execute “bcdedit /settestsigningon”.

2. Unpack the files into a local folder..

3. Open “Device Manager”.

4. Right-click on the “computer name” - “Install old device” (or select “Action” from the menu).

5. In the Wizard’s Welcome Window that opens, click “Next”.

6. Select “Installing equipment selected from the list manually” -> “Next”.

8. Select “Install from disk”, -> “View”, select the folder with the unzipped driver -> “OK”.

10. “The wizard is ready to install new equipment” -> Select “Next” -> “Finish”.

All of these actions are also described in the “usage” file that comes with the USBIP package in English.

· We connect USB devices designated as exportable on the server we need. To connect we use USBIP from distribution version 0.1

Launch cmd. Let's see which devices are ready to connect:

path-to-usbip :> usbip.exe -l

(server-ip – IP address of the USB device server from point 2)

C:\ usbip> usbip l 192.168.1.13

usbip dbg: usbip_network.c: 229 (tcp_connect) trying 192.168.1.13 port 3240

usbip dbg: usbip_network.c: 249 (tcp_connect) connected to 192.168.1.13:3240

— 192.168.1.13

usbip dbg: usbip.c: 423 (query_exported_devices) exportable 2 devices

2-1: unknown vendor: unknown product (0529:0001)

: /sys/devices/pci0000:00/0000:00:11.0/0000:02:02.0/usb2/2-1

: unknown class / unknown subclass / unknown protocol (ff/00/00)

: 0 — unknown class / unknown subclass / unknown protocol (ff/00/00)

As a result, we see that on server 192.168.1.13 a device with bus-ID 2-1 is ready for connection - the one we configured in step 2. There may be more devices.

pathtousbip:> usbip . exe a < server ip > USB ID

USB-ID in our case is 2-1.

We get multi-letters (parameter listing) and finally:

new usb device attached to usbvbus port 2

The USB device should appear on the client system. It is advisable not to close the terminal window.

OptionsUSBIP - windowsclient Usage: usbip

a, --attach Attach a remote USB device
-x, --attachall Attach all remote USB
devices on the specific host
-d, --detach Detach an imported USB
device
-l, --list List exported USB devices
p, --port List virtual USB port status
-D, --debug Print debugging information
-v, --version Show version
-?, -h, --help Print this help

Notes: Problems encountered and their solutions:

1. I used system version 11.04 on kernel 2.6. After updating the system to version 11.10 (kernel 3.0.4), usbip stopped working - it gave an error that the component was not found. I had to restore the car and refuse updates. On the other hand, since this is a highly specialized official machine and access to it is limited, this was not considered critical.

2. At first, hasp keys refused to connect to the client, giving an error. During the experiments, it was found that it is first necessary to launch the usbip daemon, and only then connect the keys to the machine. Subsequently, the errors disappeared, the keys began to be connected in any order, and the errors could not be repeated. This is exactly one of those oddities that I mentioned.

3. After rebooting the client VM - 1C server, sometimes it is not possible to connect some of the keys to it - it gives errors. This may be due to stuck exchange sessions with USB devices on the HASP server. It can be cured by rebooting the HASP server and re-forwarding the keys to the client.

Today, there are quite a few ways to transfer a USB device to another computer or virtual machine over the network.
The most popular are hardware products such as AnywhereUSB and pure software products, from those that I tried myself: USB Redirector and USB/IP.
I'd like to tell you one more thing in an interesting way, which works directly with the QEMU emulator.
It is also part of the spice project, officially supported by RedHat.

UsbRedir is an open protocol for forwarding USB devices via TCP to a remote virtual server, developed with the support of RedHat as part of the spice project. But as it turns out, you can use it quite successfully without spice. The role of the server is usbredirserver, which sends a USB device to a specific port, and the client is QEMU itself, which emulates connecting an exported USB device to a specific USB controller of your virtual machine. Thanks to this approach, absolutely any OS can be used as a guest system, since it does not even know that the device is forwarded remotely, and all the logic falls on QEMU.

First, a few words about the above solutions

  • AnywhereUSB is a pretty good solution, but expensive, and has unpleasant glitches, for example, if a shared flash drive falls off, you can only reconnect it back by physically removing and inserting it.
  • USB/IP - OpenSource project. It looks like it was abandoned. In fact, it's quite buggy. When the connection is lost, the machine often goes into complete freezee, and windows shows BSOD
  • USB Redirector - Wonderful software. For sharing devices from Linux to Linux it is free, in all other cases it already costs money, not as much as AnywhereUSB, but not free as we would like :)
As you can see, there is plenty to choose from, but let’s finally try another method - UsbRedir?

Setting up a virtual machine

In order to have somewhere to connect the exported devices, you need to create the necessary USB controllers on the virtual machine:

  • uhci - for USB1.0
  • ehci - for USB2.0
  • xhci - for USB3.0
For qemu (without libvirt)

Add options to the virtual machine startup command:
-device ich9-usb-ehci1,id=ehci,addr=1d.7,multifunction=on -device ich9-usb-uhci1,id=uhci-1,addr=1d.0,multifunction=on,masterbus=ehci.0 ,firstport=0 -device ich9-usb-uhci2,id=uhci-2,addr=1d.1,multifunction=on,masterbus=ehci.0,firstport=2 -device ich9-usb-uhci3,id=uhci-3 ,addr=1d.2,multifunction=on,masterbus=ehci.0,firstport=4

For libvirt
In the source virtual machine configuration file in the node <devices> remove all USB controllers and add the following block:

By the way, if you use spice, then by adding 3 more special devices to the controllers, it will be possible to forward USB devices from the spice client to the server.

Example under spoiler

For qemu
We add the following options to the virtual machine startup command, in addition to the controllers we defined earlier:
-chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id =usbredirdev2,debug=3 -chardev spicevmc,name=usbredir,id=usbredirchardev3 -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,debug=3
For libvirt
In the initial virtual machine configuration file in the <devices> node, we add the following options, in addition to the controllers we defined earlier:

Now everything is ready for forwarding.

Starting the server

The usbredirserver package can be found in the standard repositories of almost all popular Linux distributions.

Insert the USB flash drive into the computer, look at the output of USB devices:
$ lsusb ... Bus 003 Device 011: ID 125f:c82a A-DATA Technology Co., Ltd. ...

We see that the vendorid:prodid pair is equal to 125f:c82a, and the kernel has identified the flash drive as 003-001 usbbus-usbaddr, respectively.

Now let's share it on port 4000:

# Using the vendorid:prodid pair $ usbredirserver -p 4000 125f:c82a # Using the usbbus-usbaddr pair $ usbredirserver -p 4000 003-011

Connecting a device to a virtual machine

Through options when starting the VM

The device that needs to be connected to the VM can be specified at startup by adding the following options to the startup command

For qemu
-chardev socket,id=usbredirchardev1,port=4000,host=192.168.1.123 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=4
For libvirt
This block is placed before the tag </devices>, next to the controllers we defined earlier:
It can also be executed by the command virsh attach-device

Or via qemu-monitor

We go to the hypervisor and execute the following commands in the qemu-monitor of our machine:
# Add our device chardev-add socket,id=usbredirchardev1,port=4000,host=192.168.1.123 # Connect it to the ehci controller (USB-2.0) device_add usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci. 0,debug=4
To disable the flash drive, just use the following command:
device_del usbredirdev1

That's all, after these steps your VM will see your flash drive and will be able to work with it natively.

If there are many devices and they are all the same

Here an interesting problem appeared: how to forward several identical devices to different VMs?
At the same time, it is worth noting that all devices have the same vendorid:prodid pair, and the usbbus-usbaddr pair is not at all constant, as soon as you remove and insert the device, it will immediately change its usbaddr.

I solved it using udev.
By the way, if you don’t quite understand how udev works, there’s a cool one on the Debian Wiki

And so let's get started

First, we need to find out the serial number of our device, by which we will identify it in udev:

Let's launch the udev monitor:
$ udevadm monitor --environment --udev
And insert our device, after that we will immediately see a list of variables of this device that udev kindly initialized for us:
... UDEV add /devices/virtual/bdi/8:16 (bdi) ACTION=add DEVPATH=/devices/virtual/bdi/8:16 ID_SERIAL_SHORT=11C130317234004B SEQNUM=4352 SUBSYSTEM=bdi USEC_INITIALIZED=189056149826 ...
Information about the serial number and other attributes can be obtained in another way, but it is worth considering that to write the rules we will use the variables from the command above, and not the attributes from the command below. Otherwise, the remove trigger will not fire when the device is disconnected.
$ udevadm info -a -n /dev/bus/usb/003/011 | grep "(serial)"

Now let's create a file /etc/udev/rules.d/99-usb-serial.rules and write the following rules into it:
ACTION=="add", ENV(ID_SERIAL_SHORT)="11C130317234004B", RUN+="/usr/bin/usbredirserver -p 4000 $attr(busnum)-$attr(devnum)" ACTION=="remove", ENV(ID_SERIAL_SHORT )="11C130317234004B", RUN+="/usr/bin/fuser -k 4000/tcp"

Let's reload the udev rules:
$ udevadm control --reload-rules
Done, now when we connect our device, it will automatically search for the port we need, and when we disconnect usbredirserver it will stop working.
By analogy, we add other devices.

That's all. Thank you for your interest:)

USB Network Gate is a program that allows users to connect USB devices connected to other computers using IP channels.

There are different implementations of remote USB connections devices, both hardware and software. Some of them require users to have certain knowledge and skills; in some cases, setting up can take a lot of time. USB Network Gate surprised me with its simplicity. I downloaded the program, installed it, clicked the Share button and the device was immediately available for connection on a remote machine with the client installed.

USB Network Gate can be indispensable, for example, when using USB tokens on the RDP server, the program allows you to configure exclusive access to devices for an individual remote desktop user, isolating him from other users. The program can also be used in a virtual environment if for some reason the device cannot be connected directly. There are versions for Windows, Linux (RPM and Deb packages), Apple OS X and, most interestingly, for Android. Now let's talk about how it works.

Server

The program is both a server and a client. When launched, by default it shows all USB devices connected to the computer. But you can display and customize general access to all ports.

It is possible to configure the connection separately for each device or port, allowing connection only for specific address. To protect the connection, authorization and encryption are provided.


Client

When using USB Network Gate as a client, the application scans local network For the presence of servers, displays all devices available for connection. If the server is on a different subnet, for example when connecting via VPN, you can add it using the “Add server” button. After I shared the printer, it appeared in the list of available connections on my MacBook. In addition to the printer, I connected USB HDD with HFS+ partitions, it also connected, but the partitions took about three minutes to mount, apparently due to their large size.

Summary

The trial version allows you to open access to only one device, the registered version - depending on the license level, from one to $89, 95 up to unlimited for $699,95 . If you need to quickly connect a device over a network, USB Network Gate is what you need, especially if you do not have strong knowledge of computer hardware.



tell friends