Re: [usb-cdc-ether/usbnet] Devolo dLan duo

On Thursday 15 March 2007 6:46 pm, Jan 'RedBully' Seiffert wrote:
> Hi,
> 
> product i'm talking about:
> http://www.devolo.com/co_EN/produkte/dlan/mldlanduo.html

Networking over power lines.  :)


> Introduction:
> 
> Due to some cabeling constrains, i decided connecting some clients over
> powerline communication (PLC) to my network would be the solution to my
> problems. Additional constrains (-EOUTOFSLOTS) made the above mentioned
> product quite interesting, because you can connect it over USB to your
> PC. After i found out they offer a Linux driver, i was convinced.
> On the same evening i downloaded the driver, took a look at it, was not
> so convinced,

Yeah, a 2.4/2.6 driver gets no respect any more.


> and hacked up my own driver from scratch in 200 lines, 
> thanks to the usbnet framework (even before i own the device...).

Kind of handy, eh?  :)


> Next day i bought a pair of those.
> 
> Problem description (or why i write this email):
> 
> 1) device claims to be cdc-ether, but seems to be non conformant
> After i connected one of those devices to my linux box (2.6.19 series,
> yes, i know, i should update for such experiments, need to forward port
> some patches, -ENOTIME), the cdc-ether driver got loaded, only to
> directly bail out:
> > usb 1-1: new full speed USB device using uhci_hcd and address 6
> > usb 1-1: configuration #1 chosen from 1 choice
> > usb 1-1: bad CDC descriptors
> > usbcore: registered new driver cdc_ether
> 
> after some debugging, i found out that the following test in
> cdc_ether.c::usbnet_generic_cdc_bind()@96 seems to fail:
> if (info->header->bLength != sizeof *info->header)
> 
> Another printk revealed, the length seems to be really wrong:
> bLength: 18, sizeof header: 5
> 
> changing the comparison to:
> if (info->header->bLength < sizeof *info->header)
> 
> lead to:
> cdc_ether 1-1:1.0: missing cdc union ether descriptor
> usb 1-1: bad CDC descriptors
> 
> The bLength bytes at *buf are (in hex):
> 12 24 00 10 01 0D 24 0F 03 00 00 00 01 EA 05 80

Clearly bogus, as the code reported.  Using the 0x24
as an internal marker, it looks like that's trying
to be (a) a cdc 1.1 header, then (b) a "multi-channel
management functional descriptor" saying it supports
"clear unit parameter" requests and stores params in
non-volatile memory, then finally (c) garbage,
the "00 00 00 01 EA 05 80".


> From here i don't know any further. So the questions are:
> Any further hints on debugging? Where to look next?
> Could this device maybe used with cdc-ether?
> (lsusb -v attached)

No.

If you contact the vendor, you should tell them their
USB descriptors are bogus.  Their simple fix would be
to update the config descriptors to stop claiming
conformance with cdc ethernet.


> 
> 2) My own driver, "contributing back"
> Believe it or not, my own driver worked "out of the box", after i moved
> it into place:
> > usb 1-1: new full speed USB device using uhci_hcd and address 8
> > usb 1-1: configuration #1 chosen from 1 choice
> > usb0: register 'devolo_dLan_USB' at usb-0000:00:07.2-1, Devolo dLan USB-NET powerline adapter, My:MA:CA:dd:re:ss
> > usbcore: registered new driver devolo_dLan_USB
> > usbcore: registered new driver cdc_ether
> 
> and:
> usb0      Link encap:Ethernet  HWaddr My:MA:CA:dd:re:ss
>           inet addr:192.168.2.254  Bcast:192.168.2.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:52652 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:93866 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:4087973 (3.8 Mb)  TX bytes:70982661 (67.6 Mb)
> 
> RX & TX from dhcp over icmp to tcp/udp seem to work (even with the
> original win driver on the other side of the PLC-bridge).

Interesting ...


> I would love to contribute this driver, but i'm not sure on the legal
> side of this: I used two informations gained by reading the original
> drivers source code.
> 
> module license looks like:
> MODULE_LICENSE ("devolo AG");
> 
> but i could not find any license.

I expect that they intended to be GPL compatible, but just did
not understand the meaning of MODULE_LICENSE (it's not the same
as copyright-owner).  You might contact the vendor and tell them
their code needs license statements.

However, looking at that URL I observe there are no restrictions
on the download, so the information you derived from that driver
is clearly not NDA material.  And the package doesn't have any
kind of shrink-wrap license, so there's no attempt at all on their
part to restrict that information.  So I wouldn't worry about
having used that info ... but, I'm not a lawyer, so if you're
worried, then contact one.


> The head-region of the driver file looks a little sparse on the license
> side, only a copyright and the restriction, to only use it with Devolo
> devices.

The comment I saw was informative; not worded as a legal restriction.


> (the userspace tool (in source form) to configure the encryption
> (without any usage of the kernel-driver, guessing from the driver side)
> contains a little bit more license-alike within the "header" of the
> files, but would this also apply to the kernel driver (as in "this is
> the mentioned license")?)

Each source code file needs its own copyright and licence statement.
So -- no, the kernel code and userspace code don't necessarily share
the same license.


> Maybe someone could give me an advise on this?
> Should i contact Devolo and ask, what they think of a GPL'ed driver
> using the usbnet framework?

As sketched above, I see one technical issue (bogus descriptors,
fixable by product revision) and a potential legal issue (they
ought to specify their code's license).

Feel free to contact the vendor and point those out.  I don't
believe what they think matters in any way, they've more or
less given out a partial operational spec for the product; but
maybe they'd give you better specs and be glad to know that
a driver might be mainlined.

- Dave


> 
> Greetings
> 	Jan
> 
> -- 
> "...by all means, do not use a hammer."
> (taken from an IBM documentation for technicians, approx. 1920)
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel