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

David Brownell wrote:
> 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.  :)
> 
Not nice, but handy :)

>> [snip Introduction]
>>
>> 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.
> 
I also have serious doubts in the locking, the performance (OK, not on
my link, but theoretical you can achieve 14MBit (more with newer
devices, but they do not have a USB connection (ATM))), and a tainted
kernel (for no good reason, source is fully available) is impractical
for my home server.

> 
>> 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?  :)
> 
Handy? More than that!
I basically looked at two drivers and mostly imitated them (net1080 &
mcs7830). All i've written besides the module foo is a bind to get the
MAC address (i think even this could have come from cdc_ether, can i
export get_ethernet_addr from cdc_ether.c?) & a tx_fixup.

[snip - cdc-ether debug]
>> 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".
> 
Thanks for this analysis.
Maybe i dumped the wrong bytes, but anyway, i couldn't make any sense
out off these bytes. Seems to be some vendor specific stuff...


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

> If you contact the vendor, you should tell them their
> USB descriptors are bogus.
;(
Hmmm, sigh.

> Their simple fix would be to update the config descriptors to stop claiming
> conformance with cdc ethernet.
> 
This would be surely the right fix, but has two caveats:
Convince them, they have done something wrong (the pessimist in me knows
the answer: "We cannot reproduce your problem, works with Windows") and
persuade them, to fix it (equals time equals money equals "don't do it").

Esp. because i think they have taken over this bug from their upstream
vendor which produces these PLC-Chips (Intellon, see usb vendor id)

Oh, and wait a sec, that usbnet works like a charm with it is surely
connected to the fact, it's a half backed cdc device..

>> 2) My own driver, "contributing back"
>> Believe it or not, my own driver worked "out of the box", after i moved
>> it into place:
[snip - my_module@work]
>> 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 ...
> 
??
What kind of interesting do you mean this? The chatty output? Seems i
filled in to long values in all those .name & .description fields...
Which raises another question: Should i rename the module to "intellon",
the vendor of the chipset? Maybe Devolo wants to build a real USB
network card one day, also called "dLan USB", would be confusing...

> 
>> 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).
I allow myself to disagree here with you, expecting/guessing at the
intend in legal things...
(sorry, optimistic pessimist in this field: Expect the worst, be pleased
if it takes a turn for the better)

> You might contact the vendor and tell them
> their code needs license statements.
> 
On the one hand, you are right, it would clarify a lot of things, OTOH
let sleeping dogs lie... ("What? We forgot the license? Fix it ASAP!
Apply $MEGA_RESTRICTIVE_LICENSE" and sign-on before download and...)

> 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 ...
Puh, so at least i will not be struct by_lightning ^-^

> but, I'm not a lawyer,
#include <IANAL.h> ;)
I expected nothing else, never saw a lawyer coding, i appreciate your
comments in this regard, they are valuable input.

> so if you're worried, then contact one.
> 
I think i will ask a lawyer at our LUG, but this will take a little
time. I'm only afraid he will say "I'm only a lawyer, ask a court"...

> 
[snip]
> 
> Feel free to contact the vendor and point those out.
This will also take a little time, need to find the time and courage to
do so...

> 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;
/me too

> but maybe they'd give you better specs
Would be fine, but basically a working device is a big win.
I don't expect much from the MII or regs side (highly confidential
HomePlug "standard"? These devices can encrypt their connection, a
little bit obscurity is always a win... :-\ ).
Multicast filtering would be nice, OTOS thats probably not implemented
in HW, maybe in the newer AV (audio video streaming aware) chips (if
they still can be equipped with USB).

> and be glad to know that a driver might be mainlined.
> 
> - Dave
> 
Greetings
	Jan

-- 
Live proud, live free - code in C

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