usbip-devel — usbip developers mailing list

[usbip-devel] usbip.sourceforge.net page is not current

[Benjamin D. <ben...@gm...>]

I'd like to fixup the main web page for the project to update the fact that
no further linux development is happening at sourceforge. And to clarify
how to make the windows client actually work with modern linux versions.

Currently the data on where development is happening is in the message
boards and mailing list. But for people getting exposed to the project for
the first time it looks quite dead. However the opposite is true because it
has been merged into the staging area of the linux kernel itself.

The first quote on the page says "Download the latest version" with a link
to the long dead repo on sourceforge instead of to the staging area of the
linux kernel.

We also need to fix the current "latest version" of the windows client. A
fix has been contributed (commit r191) that allows usbip.exe to work with
modern linux versions without re-compiling the driver (which is signed and
quite stable). This would be a simple update to one file in the released
.zip that would allow the 500+ people/week downloading to be able to
actually use it without modifying the linux version strings as found here:
http://jaxlucky.blogspot.com/2013/10/sharing-usb-devices-between-beaglebone.html

Someone has also contributed a fix in the forums for a BSOD in windows,
this needs to be committed to the windows driver so we can start testing
the fix. I would love to become a contributor and keep this side of the
project alive.

-Ben

Re: [usbip-devel] USB/IP

[Ricardo G. da S. <ca...@gm...>]

Hi Andy,

Oh, I see.. now I understand the staging :-) My focus itself wasn't the
usbip kernel modules, but the Windows port. I tried to keep up with the
staging code, but eventually I gave up as well (mainly because I moved to
another country and I didn't have the need for USB/IP at home anymore).

Unfortunately I haven't spoken with any of the original developers or the
"new ones" (the group that tried to keep up on the Windows port, which
includes me) in a long time. Quite some time ago we went through a huge
discussion how we should proceed regarding the Windows port and we managed
to fix a bunch of bugs, but then we stopped. My guess is that they moved on
to other projects as well.

Regarding the usbip-userpace: I personally think you should move as soon as
possible to somewhere else, mostly because it would simplify ports in the
future. Btw, just for curiosity, any chance that in the future a libusbip
might exist somewhere, almost ready to be ported? You know, it's always
easier to port a library then the whole userspace tools... :-)

Anyway, I believe most of the usbip-related discussions, at least for
Linux, are inside the kernel mailing lists, right? I mean, it has been a
while since I saw some activity around here, and most of it was regarding
the Windows port, not the original Linux code.


Regards,

Ricardo


2014-02-10 21:21 GMT+01:00 Andy Grover <ag...@re...>:

> On 02/10/2014 12:08 PM, Ricardo Gomes da Silva wrote:
> > Hi,
> >
> > I'd like to point out a small note: the code on SourceForge is a port of
> > USB/IP for Windows. The USB/IP itself (the original Linux code) has been
> > already merged into the kernel's code (actually this was a long time ago
> > as far as I know). For lack of time, I didn't continue my work fixing
> > the Windows port, but I'll do something about it.. eventually. There are
> > just too many patches to do and stuff to update.
> >
> > But anyway, from what I could see you're going to work with USB/IP on
> > Linux, not Windows, so follow Valentina's instructions and you should be
> > fine.
>
> Hi Ricardo,
>
> I am helping Valentina work on usbip for Linux, in association with the
> GNOME OPW[1] program. usbip was merged into the Linux kernel tree, but
> in the "staging" branch. This is not meant as a long-term location for
> things.
>
> When the usbip kernel driver is promoted out of staging, the usbip
> user-tools also need to go somewhere. Since it seems like the people
> working on usbip for Linux have moved on, we were planning on hosting
> usbip-userspace somewhere else, maybe on github. If this is incorrect,
> please say so. We'd love to work along with the original Linux
> developers, if they're around :-)
>
> Regards -- Andy
>
> [1] http://kernelnewbies.org/OPWIntro
>

Re: [usbip-devel] USB/IP

[Andy G. <ag...@re...>]

On 02/10/2014 12:08 PM, Ricardo Gomes da Silva wrote:
> Hi,
> 
> I'd like to point out a small note: the code on SourceForge is a port of
> USB/IP for Windows. The USB/IP itself (the original Linux code) has been
> already merged into the kernel's code (actually this was a long time ago
> as far as I know). For lack of time, I didn't continue my work fixing
> the Windows port, but I'll do something about it.. eventually. There are
> just too many patches to do and stuff to update.
> 
> But anyway, from what I could see you're going to work with USB/IP on
> Linux, not Windows, so follow Valentina's instructions and you should be
> fine.

Hi Ricardo,

I am helping Valentina work on usbip for Linux, in association with the
GNOME OPW[1] program. usbip was merged into the Linux kernel tree, but
in the "staging" branch. This is not meant as a long-term location for
things.

When the usbip kernel driver is promoted out of staging, the usbip
user-tools also need to go somewhere. Since it seems like the people
working on usbip for Linux have moved on, we were planning on hosting
usbip-userspace somewhere else, maybe on github. If this is incorrect,
please say so. We'd love to work along with the original Linux
developers, if they're around :-)

Regards -- Andy

[1] http://kernelnewbies.org/OPWIntro

Re: [usbip-devel] USB/IP

[Ricardo G. da S. <ca...@gm...>]

Hi,

I'd like to point out a small note: the code on SourceForge is a port of
USB/IP for Windows. The USB/IP itself (the original Linux code) has been
already merged into the kernel's code (actually this was a long time ago as
far as I know). For lack of time, I didn't continue my work fixing the
Windows port, but I'll do something about it.. eventually. There are just
too many patches to do and stuff to update.

But anyway, from what I could see you're going to work with USB/IP on
Linux, not Windows, so follow Valentina's instructions and you should be
fine.


Cheers,

Ricardo

PS: small tip - I saw that you're going to use Windows as a host for USB/IP
VMs. That might be a pain in the ass sometimes, at least with VirtualBox
(mostly because its USB stuff is tricky to deal with it). But anyway, that
was almost 2 years ago, so it should work fine now (it was working for me
at least).


2014-02-10 20:36 GMT+01:00 Valentina Manea <val...@gm...>:

> Hi Constantine,
>
> The most up-to-date version of the Linux version of USB/IP can be
> found here [1], in Greg Kroah-Hartman's Linux tree (just use git clone
> <URL> to clone it).
>
> > So, as far as I've concerned, I'd better build the whole
> > custom linux kernel with the usbip debug-driver built-in
> > to debug usbip, wouldn't I?
>
> Yes. You should use the kernel version in the above mentioned tree as
> USB/IP is guaranteed to work with it.
>
> >
> > If so, which linux distro is worth being chosen for
> > building and testing that custom kernel and, especially,
> > usbip, in particular, and does distro really matter?
> > I've got CentOS 6.5 and Ubuntu 13.10
> > on a virtual machine under Windows 7.
> > I prefer CenOS, but what if it I'd better choose
> > Ubuntu cause its' official version of the kernel
> > is most up-to-date?
>
> The distro doesn't really matter. I, personally, had issues with Linux
> Mint when using another kernel in the sense that the GUI wouldn't load
> any more, but if you're using VMs only for testing USB/IP and
> developing someplace else, you don't even need GUI. I'd say you should
> go with whatever distro you like.
>
> > And what else information might be useful for me
> > to manage to try debugging usbip?
>
> Just like in other C software projects, gdb and printk/printf are your
> best friends.
>
> However, I should point out that this driver is already under active
> developement (I am working on it as part of OPW); this means you
> should always make sure you have the latest source version.
>
> Hope I was able to help.
>
> Thanks,
> Valentina
>
> [1] http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
>
>
> ------------------------------------------------------------------------------
> Androi apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> usbip-devel mailing list
> usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbip-devel
>

Re: [usbip-devel] USB/IP

[Valentina M. <val...@gm...>]

Hi Constantine,

The most up-to-date version of the Linux version of USB/IP can be
found here [1], in Greg Kroah-Hartman's Linux tree (just use git clone
<URL> to clone it).

> So, as far as I've concerned, I'd better build the whole
> custom linux kernel with the usbip debug-driver built-in
> to debug usbip, wouldn't I?

Yes. You should use the kernel version in the above mentioned tree as
USB/IP is guaranteed to work with it.

>
> If so, which linux distro is worth being chosen for
> building and testing that custom kernel and, especially,
> usbip, in particular, and does distro really matter?
> I've got CentOS 6.5 and Ubuntu 13.10
> on a virtual machine under Windows 7.
> I prefer CenOS, but what if it I'd better choose
> Ubuntu cause its' official version of the kernel
> is most up-to-date?

The distro doesn't really matter. I, personally, had issues with Linux
Mint when using another kernel in the sense that the GUI wouldn't load
any more, but if you're using VMs only for testing USB/IP and
developing someplace else, you don't even need GUI. I'd say you should
go with whatever distro you like.

> And what else information might be useful for me
> to manage to try debugging usbip?

Just like in other C software projects, gdb and printk/printf are your
best friends.

However, I should point out that this driver is already under active
developement (I am working on it as part of OPW); this means you
should always make sure you have the latest source version.

Hope I was able to help.

Thanks,
Valentina

[1] http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/

[usbip-devel] USB/IP

[<kon...@ng...>]

Greetings.

I've got an educational challenging task to develop
my own or to improve an existing one USB
device over IP network sharing system. And I've
made a decision to explore USB/IP project.

I've tried to explore it on my own, but I still have
questions which I haven't found an answer yet.
More over, as far as I've concerned, the
information on the sourceforge page is rather
obsolete, especially what relates the latest
most up-to-date versions that are stored in
a git-repository of the linux-next integration tree.

Could you please help me a little bit by answering some
questions, if you're awared of that part of code in
git-repository.

The fact is that, moreover, I'm pretty new in git and
so can not, probably, get all the information out there, 
sorry.

So, as far as I've concerned, I'd better build the whole
custom linux kernel with the usbip debug-driver built-in
to debug usbip, wouldn't I?

If so, which linux distro is worth being chosen for
building and testing that custom kernel and, especially,
usbip, in particular, and does distro really matter?
I've got CentOS 6.5 and Ubuntu 13.10
on a virtual machine under Windows 7.
I prefer CenOS, but what if it I'd better choose
Ubuntu cause its' official version of the kernel
is most up-to-date?

In short, all I'm worring about is which distro to choose 
as
a base, which distro version to choose and which
kernel of a new version to choose to build it as a custom 
one,
load it to the distro and try to debug usbip in there, 
finally.

The kernel should be enough stable and contain
the most up-to-date usbip sources, I suppose.

And the distro and the kernel should be enough
compatible to each other, I suppose.

So what tools (distro, kernel) I'd better choose,
specifically?

And what else information might be useful for me
to manage to try debugging usbip?

Thanks in advance.

Best Regards,
Constantine Gorbunov

Re: [usbip-devel] Windows USB/IP client; can anyone fix it? How much will it cost?

[Xiaofan C. <xia...@gm...>]

On Mon, Jan 27, 2014 at 12:24 AM, Andrew Bobulsky <ru...@gm...> wrote:
> Is there a Windows driver developer familiar with the USB/IP project that
> can bring the Windows driver and client up to the level of functionality and
> reliability needed to make it generally useful?  If so, what is your asking
> price for this service, and how much time do you estimate that it will take?
>
> My plan is to fund this with a few hundred dollars of my own money and
> attempt tocrowdsource the remainder of the funds via other online forums
> such as Reddit and a few mailing lists where this would be popular, and tie
> it together on Kickstarter or similar.

You might want to ask in this mailing list (double as a forum as well).
It is where the Windows driver developers hang out, including some
people who are actively engaged in some Open Source Projects.
http://www.osronline.com/showlists.cfm?list=ntdev

One of them is James Harper who has contributed quite a lot to
the Xen project for the Windows Driver part.

Another expert Tim Roberts is quite active in the libusb project.

I believe to write a proper Windows driver and maintain it takes
a lot of time and efforts and the price will not be cheap. For example
I am involved in libusb-win32 and libusbK project as a support
admin (I do not code) and I can see that Travis (the main admin
doing the development) spent quite some time on it. And we
also need to purchase the code signing certificate to sign the
driver.

Your better hope may be to persuade companies like Redhat to
help. Apparently they have some Windows driver developers.
Eg: http://www.spice-space.org/download.html

-- 
Xiaofan

[usbip-devel] Windows USB/IP client; can anyone fix it? How much will it cost?

[Andrew B. <ru...@gm...>]

Hello USB/IP developers,

Like many a nerd before me, I've been in the situation where I have a
computer running a Linux kernel with plenty of open USB ports, and I want
to be able to connect USB devices to that computer and have them present
themselves as having been attached to a Windows machine somewhere else on
my LAN.  Similarly, I've tried many commercial products and they all work
very well---some are better than others---but am so frustrated by the
absurd cost of licensing that software that I can't even begin to justify
the expense it presents to me as a user in a home setting; the cost of my
multi-headed gaming rig would literally double, and for a machine that has
enough hardware in it to drive four gaming-grade Windows desktops, I'm sure
you can understand why I'm adverse to spending that cash when I could
purchase hardware that will do the same thing for a fraction of the price.

That said, I'm all too aware of the fact that this conundrum extends well
beyond myself and my niche application of getting mice, keyboards, and
audio devices connected to virtual machines in a way that allows me to
close the side of my computer case without carefully shoving things in
place and hoping that I don't end up with a PCIe riser cable getting
shredded by a cooling fan.  Countless others would benefit from being able
to use this software reliably and easily, and with robust virtualization
solutions being readily available to home users, the ability to extend a
USB device to a computer over the network is a critical missing link in
many projects that utilize free and/or open source software.

Currently, the problem that we all seem to have is that the USB/IP client
for Windows just doesn't work very well.  Attempts to use it are fraught
with pitfalls where devices either don't work, or trying to use them
results in BSODs.

Is there a Windows driver developer familiar with the USB/IP project that
can bring the Windows driver and client up to the level of functionality
and reliability needed to make it generally useful?  If so, what is your
asking price for this service, and how much time do you estimate that it
will take?

My plan is to fund this with a few hundred dollars of my own money and
attempt tocrowdsource the remainder of the funds via other online forums
such as Reddit and a few mailing lists where this would be popular, and tie
it together on Kickstarter or similar.

Thank you for your time and consideration!  I'm a huge fan of F/OSS, just
looking to do my part :)

Best Regards,
Andrew Bobulsky

[usbip-devel] [PATCH] staging: usbip: Fix build with --with-tcp-wrappers

[Dominik P. <dom...@fa...>]

With --with-tcp-wrappers=no specified, the build system reset LIBS to
the empty string and thus fails to link against libsysfs.

Signed-off-by: Dominik Paulus <dom...@fa...>
Signed-off-by: Tobias Polzer <tob...@fa...>
---
 drivers/staging/usbip/userspace/configure.ac | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/usbip/userspace/configure.ac b/drivers/staging/usbip/userspace/configure.ac
index 0b0e035..a1a1267 100644
--- a/drivers/staging/usbip/userspace/configure.ac
+++ b/drivers/staging/usbip/userspace/configure.ac
@@ -69,7 +69,6 @@ AC_ARG_WITH([tcp-wrappers],
 		       [AC_MSG_RESULT([not found]); exit 1])
 	     else
 		     AC_MSG_RESULT([no]);
-		     LIBS="$saved_LIBS"
 	     fi],
 	    dnl [ACTION-IF-NOT-GIVEN]
 	    [AC_MSG_RESULT([(default)])
-- 
1.8.4

[usbip-devel] [PATCH] Fix IPv6 support in usbipd

[Dominik P. <dom...@fa...>]

getaddrinfo() leaves the order of the returned addrinfo structs
unspecified. On systems with bindv6only disabled (this is the default),
PF_INET6 sockets bind to IPv4, too. Thus, IPv6 support in usbipd was
broken when getaddrinfo returned first IPv4 and then IPv6 addrinfos, as
the IPv6 bind failed with EADDRINUSE.

This patch uses seperate sockets for IPv4 and IPv6 and sets IPV6_V6ONLY
on all IPv6 sockets. Two command line arguments, -4 and -6 were added to
manually select the socket family.

Signed-off-by: Tobias Polzer <tob...@fa...>
Signed-off-by: Dominik Paulus <dom...@fa...>
---
 .../staging/usbip/userspace/src/usbip_network.c    | 12 ++++
 .../staging/usbip/userspace/src/usbip_network.h    |  1 +
 drivers/staging/usbip/userspace/src/usbipd.c       | 68 ++++++++++++++++------
 3 files changed, 63 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/usbip/userspace/src/usbip_network.c b/drivers/staging/usbip/userspace/src/usbip_network.c
index c39a07f..e78279c 100644
--- a/drivers/staging/usbip/userspace/src/usbip_network.c
+++ b/drivers/staging/usbip/userspace/src/usbip_network.c
@@ -239,6 +239,18 @@ int usbip_net_set_keepalive(int sockfd)
 	return ret;
 }
 
+int usbip_net_set_v6only(int sockfd)
+{
+	const int val = 1;
+	int ret;
+
+	ret = setsockopt(sockfd, IPPROTO_IPV6, IPV6_V6ONLY, &val, sizeof(val));
+	if (ret < 0)
+		dbg("setsockopt: IPV6_V6ONLY");
+
+	return ret;
+}
+
 /*
  * IPv6 Ready
  */
diff --git a/drivers/staging/usbip/userspace/src/usbip_network.h b/drivers/staging/usbip/userspace/src/usbip_network.h
index 2d0e427..f19ae19 100644
--- a/drivers/staging/usbip/userspace/src/usbip_network.h
+++ b/drivers/staging/usbip/userspace/src/usbip_network.h
@@ -180,6 +180,7 @@ int usbip_net_recv_op_common(int sockfd, uint16_t *code);
 int usbip_net_set_reuseaddr(int sockfd);
 int usbip_net_set_nodelay(int sockfd);
 int usbip_net_set_keepalive(int sockfd);
+int usbip_net_set_v6only(int sockfd);
 int usbip_net_tcp_connect(char *hostname, char *port);
 
 #endif /* __USBIP_NETWORK_H */
diff --git a/drivers/staging/usbip/userspace/src/usbipd.c b/drivers/staging/usbip/userspace/src/usbipd.c
index 1c76cfd..d48eea8 100644
--- a/drivers/staging/usbip/userspace/src/usbipd.c
+++ b/drivers/staging/usbip/userspace/src/usbipd.c
@@ -56,6 +56,13 @@ static const char usbip_version_string[] = PACKAGE_STRING;
 
 static const char usbipd_help_string[] =
 	"usage: usbipd [options]\n"
+	"\n"
+	"	-4, --ipv4\n"
+	"		Bind to IPv4. Default is both.\n"
+	"\n"
+	"	-6, --ipv6\n"
+	"		Bind to IPv6. Default is both.\n"
+	"\n"
 	"	-D, --daemon\n"
 	"		Run as a daemon process.\n"
 	"\n"
@@ -354,14 +361,15 @@ static void addrinfo_to_text(struct addrinfo *ai, char buf[],
 	snprintf(buf, buf_size, "%s:%s", hbuf, sbuf);
 }
 
-static int listen_all_addrinfo(struct addrinfo *ai_head, int sockfdlist[])
+static int listen_all_addrinfo(struct addrinfo *ai_head, int sockfdlist[],
+			     int maxsockfd)
 {
 	struct addrinfo *ai;
 	int ret, nsockfd = 0;
 	const size_t ai_buf_size = NI_MAXHOST + NI_MAXSERV + 2;
 	char ai_buf[ai_buf_size];
 
-	for (ai = ai_head; ai && nsockfd < MAXSOCKFD; ai = ai->ai_next) {
+	for (ai = ai_head; ai && nsockfd < maxsockfd; ai = ai->ai_next) {
 		int sock;
 		addrinfo_to_text(ai, ai_buf, ai_buf_size);
 		dbg("opening %s", ai_buf);
@@ -374,6 +382,9 @@ static int listen_all_addrinfo(struct addrinfo *ai_head, int sockfdlist[])
 
 		usbip_net_set_reuseaddr(sock);
 		usbip_net_set_nodelay(sock);
+		/* We use seperate sockets for IPv4 and IPv6
+		 * (see do_standalone_mode()) */
+		usbip_net_set_v6only(sock);
 
 		if (sock >= FD_SETSIZE) {
 			err("FD_SETSIZE: %s: sock=%d, max=%d",
@@ -402,11 +413,6 @@ static int listen_all_addrinfo(struct addrinfo *ai_head, int sockfdlist[])
 		sockfdlist[nsockfd++] = sock;
 	}
 
-	if (nsockfd == 0)
-		return -1;
-
-	dbg("listening on %d address%s", nsockfd, (nsockfd == 1) ? "" : "es");
-
 	return nsockfd;
 }
 
@@ -473,11 +479,11 @@ static void remove_pid_file()
 	}
 }
 
-static int do_standalone_mode(int daemonize)
+static int do_standalone_mode(int daemonize, int ipv4, int ipv6)
 {
 	struct addrinfo *ai_head;
 	int sockfdlist[MAXSOCKFD];
-	int nsockfd;
+	int nsockfd, family;
 	int i, terminate;
 	struct pollfd *fds;
 	struct timespec timeout;
@@ -501,21 +507,35 @@ static int do_standalone_mode(int daemonize)
 	set_signal();
 	write_pid_file();
 
-	ai_head = do_getaddrinfo(NULL, PF_UNSPEC);
+	info("starting " PROGNAME " (%s)", usbip_version_string);
+
+	/*
+	 * To suppress warnings on systems with bindv6only disabled
+	 * (default), we use seperate sockets for IPv6 and IPv4 and set
+	 * IPV6_V6ONLY on the IPv6 sockets.
+	 */
+	if (ipv4 && ipv6)
+		family = AF_UNSPEC;
+	else if (ipv4)
+		family = AF_INET;
+	else
+		family = AF_INET6;
+
+	ai_head = do_getaddrinfo(NULL, family);
 	if (!ai_head) {
 		usbip_host_driver_close();
 		return -1;
 	}
-
-	info("starting " PROGNAME " (%s)", usbip_version_string);
-
-	nsockfd = listen_all_addrinfo(ai_head, sockfdlist);
+	nsockfd = listen_all_addrinfo(ai_head, sockfdlist,
+		sizeof(sockfdlist) / sizeof(*sockfdlist));
 	if (nsockfd <= 0) {
 		err("failed to open a listening socket");
-		freeaddrinfo(ai_head);
 		usbip_host_driver_close();
 		return -1;
 	}
+
+	dbg("listening on %d address%s", nsockfd, (nsockfd == 1) ? "" : "es");
+
 	fds = calloc(nsockfd, sizeof(struct pollfd));
 	for (i = 0; i < nsockfd; i++) {
 		fds[i].fd = sockfdlist[i];
@@ -551,7 +571,6 @@ static int do_standalone_mode(int daemonize)
 
 	info("shutting down " PROGNAME);
 	free(fds);
-	freeaddrinfo(ai_head);
 	usbip_host_driver_close();
 
 	return 0;
@@ -560,6 +579,9 @@ static int do_standalone_mode(int daemonize)
 int main(int argc, char *argv[])
 {
 	static const struct option longopts[] = {
+		{ "ipv4",     no_argument,       NULL, '4' },
+		{ "ipv6",     no_argument,       NULL, '6' },
+		{ "daemon",   no_argument,       NULL, 'D' },
 		{ "daemon",   no_argument,       NULL, 'D' },
 		{ "debug",    no_argument,       NULL, 'd' },
 		{ "pid",      optional_argument, NULL, 'P' },
@@ -576,6 +598,7 @@ int main(int argc, char *argv[])
 	} cmd;
 
 	int daemonize = 0;
+	int ipv4 = 0, ipv6 = 0;
 	int opt, rc = -1;
 	pid_file = NULL;
 
@@ -587,12 +610,18 @@ int main(int argc, char *argv[])
 
 	cmd = cmd_standalone_mode;
 	for (;;) {
-		opt = getopt_long(argc, argv, "DdP::t:hv", longopts, NULL);
+		opt = getopt_long(argc, argv, "46DdP::t:hv", longopts, NULL);
 
 		if (opt == -1)
 			break;
 
 		switch (opt) {
+		case '4':
+			ipv4 = 1;
+			break;
+		case '6':
+			ipv6 = 1;
+			break;
 		case 'D':
 			daemonize = 1;
 			break;
@@ -618,9 +647,12 @@ int main(int argc, char *argv[])
 		}
 	}
 
+	if (!ipv4 && !ipv6)
+		ipv4 = ipv6 = 1;
+
 	switch (cmd) {
 	case cmd_standalone_mode:
-		rc = do_standalone_mode(daemonize);
+		rc = do_standalone_mode(daemonize, ipv4, ipv6);
 		remove_pid_file();
 		break;
 	case cmd_version:
-- 
1.8.4

[usbip-devel] linux driver/userland development

[<tob...@fa...>]

Hello,

as part of a university project, Dominik and I would like to make some
contributions to the usbip Linux driver/userland (like Stefan and Kurt did
earlier this year).

We noticed that usbip lacks a proper method for permanent configuration.
Would a config file be desirable or is it intentionally not done?

Furthermore, we would like to enable some kind of authentication (at least
for the handshake), for which gnutls looks very convenient. Would it be ok
to introduce a dependency on gnutls?

Regards,
Dominik Paulus and Tobias Polzer

[usbip-devel] Virtual USB Device

[Sven K. <sve...@gm...>]

Hi,

I'm looking for a way to implement a virtual USB device. The VHCI
controller developed in this project seems to provide a way to do that.
I see the VHCI driver is in the official kernel already. That's good.
But I have few questions:

1) Do you know of anybody who has attempted to implemented a virtual
device? I would like to take a look at the code.

2) Is there a library to speak to the VHCI driver in the kernel? I found
https://sourceforge.net/projects/usb-vhci/files/native%20libraries/
Is it related to this project and does version 0.6 work with the driver
in the kernel?


Regards,
  Sven

[usbip-devel] Bug: "Cannot Enable Port 1. Maybe the USB Cable is bad?" when tunneling thumb drive.

[Chuck R. <cjr...@gm...>]

When tunnelling USB flash drive from raspian/usbip 1.1.1 server to VM
debian/usbip 1.1.1 client, creation of tunnel is successful: the drive
shows up in lsusb on client. Then about a minute later the following error
occurs on the Debian (client) side, with no new messages by usbipd on
server side:

Cannot enable port 1. Maybe the USB cable is bad?
[repeat 6x]
unable to enumerate USB device on port 1

...and the drive disappears from lsusb on client side. The drive cannot be
successfully mounted in this ~1 minute grace-period and definitely not
after it. Unbinding on server side causes segfault on client side.

Here is breakdown of events:
HOST:
modprobe vhci-hcd ...[etc]
sudo usbipd --debug &
sudo usbip bind -b 1-1.3
sudo usbip --debug bind -b 1-1.3
usbip: debug:
/build/linux-tools-TqR1ks/linux-tools-3.2.17/drivers/staging/usbip/userspace/src/usbip.c:134:[run_command]
running command: `bind'
usbip: debug:
/build/linux-tools-TqR1ks/linux-tools-3.2.17/drivers/staging/usbip/userspace/src/usbip_bind.c:162:[unbind_other]
1-1.3:1.0 -> usb-storage
usbip: debug:
/build/linux-tools-TqR1ks/linux-tools-3.2.17/drivers/staging/usbip/userspace/src/utils.c:65:[modify_match_busid]
write "add 1-1.3" to /sys/bus/usb/drivers/usbip-host/match_busid
bind device on busid 1-1.3: complete

CLIENT:
modprobe vhci-hcd
sudo usbip attach -h xxx.xxx.xxx.xxx -b 1-1.3
[returns to prompt with no output]
[~1 minute passes]
"Cannot enable port 1. Maybe the USB cable is bad?"
[repeat 6x]
"unable to enumerate USB device on port 1"
...

snip of /var/log/syslog says:
kernel: Product: USB Mass Storage
...
mtp-probe: checking bus 2, device 4: /sys/devices/platform/vhci_hcd/usb2/2-1
mtp-probe: bus: 2, device: 4 was not an MTP device
kernel: Initializing USB Mass Storage driver...
kernel: scsi3: usb-storage 2-1:1.0
kernel: usbcore: registered new  interface driver usb-storage
kernel: USB Mass Storage support registered.
kernel: vhci_hcd: dequeue a urb ff88003773d180
kernel: vhci_hcd: Unlink after no-IRQ? Controller is probably using the
wrong IRQ.
kernel: vhci_hcd: device ffff8800... seems to be still connected
kernel: vhci_hcd: unlink->segnum 15
kernel: vhci_hcd: urb->status->-104
kernel: hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
kernel: hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
kernel: hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
kernel: usb 2-1: USB disconnect, device number 4
kernel: scsi 3:0:0:0: Device offlined - not ready after error recovery
kernel: hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
kernel: hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
kernel: hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
kernel: hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?

Thanks for reading.

[usbip-devel] Hi, can you supply tablet pc?

[<lv...@as...>]

Hi. Kejora here.

I find you on http://choon.net/forum/read.php?21,91298,91298

Can you do distributing to me also?
We have a clients who need tablet pc urgently(first order about 500 pcs).

If you can provide, please send you products with price(distribution price) to me before this weekend.
Quadcore with 3G 9,7 inch are prefered, dualcore is also accepable. Don't send me anything without 3G!

Tell me your phone or skype if you like to. I'll call you and let you know my contact details  if your tablet pc is good.

Thanks,
Kejora

[usbip-devel] Reg Linux Thin Client needs to share a usb device to Windows Server 2003 using rdesktop RDP

[Narayanan <nar...@pr...>]

 

Hi, I'm new to this USB/IP Project.

 

I'm having a linux thin client based on fedora KDE kernel 2.6.22

 

I use rdesktop remote desktop client to use a session on Windows 2003
server.

 

I need to share a usb from linux thin client to server. 

 

What I need to do ?

 

Whether I have to install the linux server USB/IP package (USBIPD) in linux
thin client and export the usb device ?

 

Then import it in windows client ?

 

Can anyone give clear steps to do this process ?

 

 

 

 

Thanks and Regards,

Narayanan,

09944628709

Precision Biometric (I) Pvt Ltd

Chennai - 17

 


This communication may contain confidential information. 
If you are not the intended recipient it may be unlawful for you to read, copy, distribute, disclose or otherwise use the information contained within this communication.. 
Errors and Omissions may occur in the contents of this Email arising out of or in connection with data transmission, network malfunction or failure, machine or software error, malfunction, or operator errors by the person who is sending the email. 
Precision Group accepts no responsibility for any such errors or omissions. The information, views and comments within this communication are those of the individual and not necessarily those of Precision Group. 
All email that is sent from/to Precision Group is scanned for the presence of computer viruses, security issues and inappropriate content. However, it is the recipient's responsibility to check any attachments for viruses before use.

[usbip-devel] usbip client connection to a custom port

[Federico F. <fed...@pa...>]

Hi everyone!
We have a setup where different machines connect (when requested) to a 
central one via SSH -R and expose a USB device via usbip. We "usbip 
attach" to this central machine and connect to the exposed USB device, 
and it works nicely.

We have a problem though: if two machines connect at the same time the 
two connections clash, since usbip sits on a single port. As a 
workaround we can configure (via SSH) the remote machines to expose 
their 3240 port each to a *different* port on the central machine, but 
then the usbip client should be able to specify which port to use... So 
I'd like to write a patch for this, basically I'd add

usbip list -r host[:port]
usbip add -h host[:port]

Would it be interesting? Should I write the patch against 
drivers/staging/usbip inside the latest kernel.org kernel?

Thanks for your attention!

[usbip-devel] usbip client connection to a custom port

[Federico F. <fed...@pa...>]

Hi everyone!
We have a setup where different machines connect (when requested) to a 
central one via SSH -R and expose a USB device via usbip. We "usbip 
attach" to this central machine and connect to the exposed USB device, 
and it works nicely.

We have a problem though: if two machines connect at the same time the 
two connections clash, since usbip sits on a single port. As a 
workaround we can configure (via SSH) the remote machines to expose 
their 3240 port each to a *different* port on the central machine, but 
then the usbip client should be able to specify which port to use... So 
I'd like to write a patch for this, basically I'd add

usbip list -r host[:port]
usbip add -h host[:port]

Would it be interesting? Should I write the patch against 
drivers/staging/usbip inside the latest kernel.org kernel?

Thanks for your attention!

Re: [usbip-devel] [PATCH 13/15] staging: usbip: userspace: libsrc: cleanup parsing

[Greg KH <gr...@li...>]

On Thu, Apr 04, 2013 at 04:03:14PM +0200, Stefan Reif wrote:
> From: Kurt Kanzenbach <ly8...@ci...>
> 
> Since the names.c/names.h are taken from another project, some
> functions which names.c provides aren't used by usbipd.
> This patch fixes:
>  - removed useless comments
>  - unified debug/error messages by using the macros
>    provided by usbip_common.h
>  - removed unnused code
> 
> The code cleanup includes:
>  - remove unused data structures
>  - remove code to create them
>  - remove code to access them
> 
> The file names.c is used to parse the `usb.ids' file. The parser
> stores a lot of information about usb devices that is never used.
> 
> The `usb.ids' file has several sections. Some variables (like
> `lasthut') store the ID of the current section, and those variables
> are used to decide which section is currently being parsed (i.e. in
> which data structure the current line will be  stored).
> 
> We removed the code to read those IDs because they are never used
> anyway. We replaced them by the pseudo-ID `1' (instead of reading the
> ID from the file) to indicate that the parser is in a section that
> can be ignored. If the parser is in such a section, the current line
> (which contains sub-items for this section) is discarded.

I'm not objecting to this patch, but you might want to switch to start
using the library that systemd/udev provides for this same type of
functionality, instead of using the usb.ids file, as that is going away
soon from systems.

thanks,

greg k-h

Re: [usbip-devel] [PATCH 13/15] staging: usbip: userspace: libsrc: cleanup parsing

[Dan C. <dan...@or...>]

On Thu, Apr 04, 2013 at 10:10:10PM +0300, Dan Carpenter wrote:
> > +		if (buf[0] == 'P' && buf[1] == 'H' && buf[2] == 'Y' &&
> > +		    buf[3] == 'S' && buf[4] == 'D' &&
> > +		    buf[5] == 'E' && buf[6] == 'S' && /*isspace(buf[7])*/
> > +		    buf[7] == ' ') {
> >  			continue;
> 
> 	if (strncmp(buf, "PHYSDES ", 8) == 0)
> 		continue;

Btw, this is obviously something that could be cleaned up in a later
patch.  Generally, if you didn't introduce it and it's not a bug
then fixing it in a later patch is fine.

regards,
dan carpenter

Re: [usbip-devel] [PATCH 03/15] staging: usbip: reformat function pickup_urb_and_free_priv

[Dan C. <dan...@or...>]

On Thu, Apr 04, 2013 at 04:03:04PM +0200, Stefan Reif wrote:
> +		switch (status) {
> +		case -ENOENT:
> +			/* fall through */
> +		case -ECONNRESET:

If two case statements are right next to each other then they don't
need a "fall through" comment.  (Don't resend.  I'm just pointing
that out for future reference).

regards,
dan carpenter

Re: [usbip-devel] [PATCH 13/15] staging: usbip: userspace: libsrc: cleanup parsing

[Dan C. <dan...@or...>]

This one could probably have been broken into separate patches.

> +		if (buf[0] == 'P' && buf[1] == 'H' && buf[2] == 'Y' &&
> +		    buf[3] == 'S' && buf[4] == 'D' &&
> +		    buf[5] == 'E' && buf[6] == 'S' && /*isspace(buf[7])*/
> +		    buf[7] == ' ') {
>  			continue;

	if (strncmp(buf, "PHYSDES ", 8) == 0)
		continue;

regards,
dan caprenter

[usbip-devel] [PATCH 09/15] staging: usbip: removed unnecessary for loop

[Stefan R. <ke4...@ci...>]

From: Kurt Kanzenbach <ly8...@ci...>

This for loop is not needed, since STUB_BUSID_OTHER is defined as 0.
In Addition added a comment if STUB_BUSID_OTHER changes sometime.

Signed-off-by: Kurt Kanzenbach <ly8...@ci...>
Signed-off-by: Stefan Reif <ke4...@ci...>
---
 drivers/staging/usbip/stub_main.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/usbip/stub_main.c b/drivers/staging/usbip/stub_main.c
index 629bfcb..33027cc 100644
--- a/drivers/staging/usbip/stub_main.c
+++ b/drivers/staging/usbip/stub_main.c
@@ -38,11 +38,11 @@ static spinlock_t busid_table_lock;
 
 static void init_busid_table(void)
 {
-	int i;
-
+	/*
+	 * This also sets the bus_table[i].status to
+	 * STUB_BUSID_OTHER, which is 0.
+	 */
 	memset(busid_table, 0, sizeof(busid_table));
-	for (i = 0; i < MAX_BUSID; i++)
-		busid_table[i].status = STUB_BUSID_OTHER;
 
 	spin_lock_init(&busid_table_lock);
 }
-- 
1.8.1

[usbip-devel] [PATCH 08/15] staging: usbip: removed unnecessary if-else-statements

[Stefan R. <ke4...@ci...>]

From: Kurt Kanzenbach <ly8...@ci...>

In each if-else case "return" is called. This is why
these if-else-statements are useless. Removing them
improves understanding and readability.

Signed-off-by: Kurt Kanzenbach <ly8...@ci...>
Signed-off-by: Stefan Reif <ke4...@ci...>
---
 drivers/staging/usbip/stub_main.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/usbip/stub_main.c b/drivers/staging/usbip/stub_main.c
index 705a9e5..629bfcb 100644
--- a/drivers/staging/usbip/stub_main.c
+++ b/drivers/staging/usbip/stub_main.c
@@ -167,22 +167,22 @@ static ssize_t store_match_busid(struct device_driver *dev, const char *buf,
 	strncpy(busid, buf + 4, BUSID_SIZE);
 
 	if (!strncmp(buf, "add ", 4)) {
-		if (add_match_busid(busid) < 0) {
+		if (add_match_busid(busid) < 0)
 			return -ENOMEM;
-		} else {
-			pr_debug("add busid %s\n", busid);
-			return count;
-		}
-	} else if (!strncmp(buf, "del ", 4)) {
-		if (del_match_busid(busid) < 0) {
+
+		pr_debug("add busid %s\n", busid);
+		return count;
+	}
+
+	if (!strncmp(buf, "del ", 4)) {
+		if (del_match_busid(busid) < 0)
 			return -ENODEV;
-		} else {
-			pr_debug("del busid %s\n", busid);
-			return count;
-		}
-	} else {
-		return -EINVAL;
+
+		pr_debug("del busid %s\n", busid);
+		return count;
 	}
+
+	return -EINVAL;
 }
 static DRIVER_ATTR(match_busid, S_IRUSR | S_IWUSR, show_match_busid,
 		   store_match_busid);
-- 
1.8.1

[usbip-devel] [PATCH 15/15] staging: usbip: userspace: show product name in `list -l' command

[Stefan R. <ke4...@ci...>]

From: Kurt Kanzenbach <ly8...@ci...>

The `usbip list -l' command shows your local usb-devices.
Example:
 $ usbip list -l
 $ Local USB devices
 $ =================
 $ - busid 1-1 (13fe:1d00)
 $         1-1:1.0 -> usb-storage
 $
 $ - busid 1-2 (0409:55aa)
 $         1-2:1.0 -> hub

However this list command doesn't show which device is connected
to this busid. Therefore you have to use another tool e.g. lsusb
to determine that.

This patches adds the possibility to see which device that is.
Example:
 $ usbip list -l
 $ Local USB devices
 $ =================
 $ - busid 1-1 (13fe:1d00)
 $   Kingston Technology Company Inc. : DataTraveler 2.0 1GB/4GB Flash Drive / Patriot Xporter 4GB Flash
 $         1-1:1.0 -> usb-storage
 $
 $ - busid 1-2 (0409:55aa)
 $   NEC Corp. : Hub (0409:55aa)
 $         1-2:1.0 -> hub

If parsable is specified the info will be not printed.

Signed-off-by: Kurt Kanzenbach <ly8...@ci...>
Signed-off-by: Stefan Reif <ke4...@ci...>
---
 drivers/staging/usbip/userspace/src/usbip_list.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/staging/usbip/userspace/src/usbip_list.c b/drivers/staging/usbip/userspace/src/usbip_list.c
index ed30d91..ff56255 100644
--- a/drivers/staging/usbip/userspace/src/usbip_list.c
+++ b/drivers/staging/usbip/userspace/src/usbip_list.c
@@ -159,6 +159,12 @@ static void print_device(char *busid, char *vendor, char *product,
 		printf(" - busid %s (%.4s:%.4s)\n", busid, vendor, product);
 }
 
+static void print_product_name(char *product_name, bool parsable)
+{
+	if (!parsable)
+		printf("   %s\n", product_name);
+}
+
 static void print_interface(char *busid, char *driver, bool parsable)
 {
 	if (parsable)
@@ -189,6 +195,7 @@ static int list_devices(bool parsable)
 {
 	char bus_type[] = "usb";
 	char busid[SYSFS_BUS_ID_SIZE];
+	char product_name[128];
 	struct sysfs_bus *ubus;
 	struct sysfs_device *dev;
 	struct sysfs_device *intf;
@@ -231,8 +238,13 @@ static int list_devices(bool parsable)
 			goto err_out;
 		}
 
+		/* get product name */
+		usbip_names_get_product(product_name, sizeof(product_name),
+					strtol(idVendor->value, NULL, 16),
+					strtol(idProduct->value, NULL, 16));
 		print_device(dev->bus_id, idVendor->value, idProduct->value,
 			     parsable);
+		print_product_name(product_name, parsable);
 
 		for (i = 0; i < atoi(bNumIntfs->value); i++) {
 			snprintf(busid, sizeof(busid), "%s:%.1s.%d",
-- 
1.8.1

[usbip-devel] [PATCH 12/15] staging: usbip: userspace: removed unnecessary code

[Stefan R. <ke4...@ci...>]

From: Kurt Kanzenbach <ly8...@ci...>

Since no usbip_name function is used in usbipd, it's not
necessary to parse "usb.ids" file at startup.

Signed-off-by: Kurt Kanzenbach <ly8...@ci...>
Signed-off-by: Stefan Reif <ke4...@ci...>
---
 drivers/staging/usbip/userspace/src/usbipd.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/usbip/userspace/src/usbipd.c b/drivers/staging/usbip/userspace/src/usbipd.c
index 3f10c51..3e913b8 100644
--- a/drivers/staging/usbip/userspace/src/usbipd.c
+++ b/drivers/staging/usbip/userspace/src/usbipd.c
@@ -436,9 +436,6 @@ static int do_standalone_mode(int daemonize)
 	struct timespec timeout;
 	sigset_t sigmask;
 
-	if (usbip_names_init(USBIDS_FILE))
-		err("failed to open %s", USBIDS_FILE);
-
 	if (usbip_host_driver_open()) {
 		err("please load " USBIP_CORE_MOD_NAME ".ko and "
 		    USBIP_HOST_DRV_NAME ".ko!");
@@ -507,7 +504,6 @@ static int do_standalone_mode(int daemonize)
 	free(fds);
 	freeaddrinfo(ai_head);
 	usbip_host_driver_close();
-	usbip_names_free();
 
 	return 0;
 }
-- 
1.8.1