linux-kernel - Re: bad endpoint address, MOTU FastLane

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 May 2009 10:22:10 -0500
From:	"Todd T. Fries" <todd@...es.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Clemens Ladisch <clemens@...isch.de>,
	David Fries <david@...es.net>,
	David Griffith <dgriffi@...csubak.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: bad endpoint address, MOTU FastLane

I'm actually the owner of said device, and have actually purchased
something that is complaint.  However, not all owners of said device
are as able or willing.

The point in my opinion is that it used to work and now after an upgrade
(to support a pchdtv.com tuner) the MOTU doesn't, only the software has
changed.  Thanks for giving me one more reason to avoid Linux.

IMHO the principal of 'be generous in what you accept, strict in what you give..'
for specs applies here..

Worst case, quirk entry, eh?

Penned by Alan Stern on 20090512 10:08.01, we have:
| On Tue, 12 May 2009, Clemens Ladisch wrote:
| 
| > David Fries wrote:
| > > usb_submit_urb returns -22 EINVAL invalid argument as it is trying to
| > > submit an interrupt packet to what is registered as an isoc endpoint.
| 
| How does one know which type the endpoint really is?  Through prior 
| experience with the device?
| 
| > > The second interface has the same end point addresses as the first.
| > > Any suggestions on how to deal with this class of broken hardware?
| > > 
| > > I:* If#= 0 Alt= 0 ...
| > > E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=1ms
| > > I:* If#= 1 Alt= 0 ...
| > > E:  Ad=81(I) Atr=01(Isoc) MxPS=   4 Ivl=1ms
| > 
| > AFAICS the USB core memorizes the descriptor belonging to a specific
| > endpoint number whenever usb_set_interface() is called.  In this case,
| > the second interface is initialized later, so the second set of
| > descriptors wins.
| > 
| > The driver could call usb_set_interface() again for the first interface
| > so that the USB core takes notice of the first set of endpoints again.
| > Please try the patch below.
| > 
| > I guess I'll have to write another quirk for this.
| > 
| > 
| > --- linux/sound/usb/usbmidi.c
| > +++ linux/sound/usb/usbmidi.c
| > @@ -1779,6 +1779,7 @@
| >  		err = snd_usbmidi_detect_per_port_endpoints(umidi, endpoints);
| >  		break;
| >  	case QUIRK_MIDI_RAW:
| > +		usb_set_interface(umidi->chip->dev, 0, 0);
| >  		umidi->usb_protocol_ops = &snd_usbmidi_raw_ops;
| >  		err = snd_usbmidi_detect_per_port_endpoints(umidi, endpoints);
| >  		break;
| 
| This is only a bandaid.  The underlying problem is still there.  
| Basically, the second interface shouldn't exist at all.  The only
| proper way to deal with it is to pretend there's only one interface --
| which would mean changing the descriptors before the kernel parses
| them.
| 
| A much easier approach is to throw the device away and replace it with 
| something that _is_ compliant with the USB specification.
| 
| Alan Stern

-- 
Todd Fries .. todd@...es.net

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \          250797 (FWD)
|                                             \
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/