Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: USB networking (cdce) with Linux host (g_ether)
From: Christof Meerwald <cmeerw%cmeerw.org@localhost>, Date: Sat, 4 Apr 2015 11:55:35 +0200
> On Sat, Apr 04, 2015 at 04:15:40PM +0900, Ryo ONODERA wrote:
>> From: Christof Meerwald <cmeerw%cmeerw.org@localhost>, Date: Sat, 4 Apr 2015 08:42:23 +0200
>> > On Sat, Apr 04, 2015 at 08:50:01AM +0900, Ryo ONODERA wrote:
>> >> Please remove cdce(4) and umodem(4) entries from your kernel configuration
>> >> file (your device should be recognized as ugen(4)) and run
>> >> $ gcc -o probe_usb probe_usb.c
>> >> # ./probe_usb /dev/ugen0.00
>> >
>> > # ./probe_usb /dev/ugen0.00
>> > length: 9
>> > descriptor type: 2
>> > total length: 2147470578
>> > num interface: 2
>> > config value: 2
>> > configuration: 0
>> > Attributes: (0xc0) Self powered
>> > max power: 500 mA
>> >
>> > Interface 0:
>> > Length: 9
>> > Descriptor Type: 4
>> > Interface No: 0
>> > Alt Setting: 0
>> > Num Endpoints: 1
>> > Interface Class: 2
>> > Interface SubClass: 2
>> Your cdce(4) has Interface Class Subclass = 2.
>> According to table 16 of
>> http://cscott.net/usb_dev/data/devclass/usbcdc11.pdf
>> Universal Serial Bus Class Definitions for Communication Devices Version 1.1,
>> 02h is assigned to Abstract Control Model.
>> As far as I understand correctly, Abstract Control Model is used for
>> RS-232C emulation devices, for example USB modem.
>
> I don't think that's actually causing the problem - if you look in
> umodem.c it checks for
>
> if (uaa->class != UICLASS_CDC ||
> uaa->subclass != UISUBCLASS_ABSTRACT_CONTROL_MODEL ||
> !(uaa->proto == UIPROTO_CDC_NOCLASS || uaa->proto == UIPROTO_CDC_AT))
> return (UMATCH_NONE);
>
> and the proto is 255 in my case and that causes it to return
> UMATCH_NONE
>
>> > Interface 1:
>> > Length: 9
>> > Descriptor Type: 4
>> > Interface No: 1
>> > Alt Setting: 0
>> > Num Endpoints: 2
>> > Interface Class: 10
>> > Interface SubClass: 0
>> > Interface Protocol: 0
>
> I think that's actually the one that causes the problem in r1.66 of
> umodem.c
>
> id = usbd_get_interface_descriptor(uaa->iface);
> if (uaa->subclass != UISUBCLASS_ABSTRACT_CONTROL_MODEL &&
> (id->bInterfaceClass == UICLASS_CDC_DATA &&
> id->bInterfaceSubClass == UISUBCLASS_DATA))
> return (UMATCH_IFACECLASS_IFACESUBCLASS);
>
> Now I have to say that I don't have much understanding of the NetBSD
> code base or USB, but this is my understanding:
>
> Looking at usbd_attachinterfaces uiaa (which I think is then uaa in
> umodem.c) gets populated as:
>
> uiaa.iface = ifaces[i];
> uiaa.class = ifaces[i]->idesc->bInterfaceClass;
> uiaa.subclass = ifaces[i]->idesc->bInterfaceSubClass;
>
> usbd_get_interface_descriptor(uaa->iface) just returns uaa->iface->idesc
>
> I would therefore always expect id->bInterfaceClass == uaa->class and
> id->bInterfaceSubClass == uaa->subclass and the above 'if' could then
> be rewritten as:
>
> if (uaa->class == UICLASS_CDC_DATA &&
> uaa->subclass == UISUBCLASS_DATA)
> return (UMATCH_IFACECLASS_IFACESUBCLASS);
>
> which clearly looks wrong to me.
>
>
> I could of course be wrong here, but I don't see how uaa->subclass can
> be different from id->bInterfaceSubClass in that code.
I see. It may be wrong.
Sadly I am not kernel developer and I cannot answer your question...
By the way I have cdce(4) device and it works fine for me.
cdce0 at uhub1 port 2 configuration 2 interface 0
cdce0: Realtek USB 10/100 LAN, rev 2.10/20.00, addr 6
$ sudo usbdevs -a 6 -v
Controller /dev/usb0:
addr 6: high speed, power 100 mA, config 2, USB 10/100 LAN(0x8152), Realtek(0x0bda), rev 20.00, serial XX...XX
My machine is busy now and I will post the output of probe_usb later.
--
Ryo ONODERA // ryo_on%yk.rim.or.jp@localhost
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB FD1B F404 27FA C7D1 15F3
Home |
Main Index |
Thread Index |
Old Index