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
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
