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

[Nick Hudson <skrll%netbsd.org@localhost>]

On 04/04/15 10:55, Christof Meerwald wrote:
> 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

I guess this isn't your main concern right now....

> > > 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.

Yeah, I agree with this.

What's the full dmesg when you have umodem.c:1.66 reverted?


> I could of course be wrong here, but I don't see how uaa->subclass can
> be different from id->bInterfaceSubClass in that code.
>
>
> Christof

Nick