Re: USB networking (cdce) with Linux host (g_ether)

[Ryo ONODERA <ryo_on%yk.rim.or.jp@localhost>]

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