On Monday 20 November 2006 2:36 am, Francois Barre wrote:
> 
> 2. What doesn't work :
> Although things work great between two Penguins, it did fail while
> trying to connect a Linux box to a Windows XP host, with the
> proprietary driver at MS side and the changed detailed  in 1. for the
> open-source side . 

Right; vendors all too regularly avoid publishing specifications,
or using straightforward implementations that wouldn't need specs.
They want to promote vendor lock-in.


> And that's why I'm writing here. 
> At linux side, a tcpdump of a windows-originating arp query prompts this way :
> 23:04:59.793605 00:ff:ff:ff:ff:ff (oui Unknown) > 01:00:07:00:31:00
> (oui Unknown), ethertype Unknown (0xff30), length 49:
>       0x0000:  0100 0700 3100 00ff ffff ffff ff30 00c9
>       0x0010:  eb72 0208 0600 0108 0006 0400 0130 00c9
>       0x0020:  eb72 02c0 a80d 0100 0000 0000 00c0 a80d
>       0x0030:  02
> 
> It is clear that the ARP query packet is prefixed by 7 bytes which
> don't look like ARP. If you remove the "0100 0700 3100 00", you come
> up with a 42-byte perfect ARP query. As the Windows box can't
> understand the Linux reply to this ARP query, connections stop here.
> For sure, the byte 5 "0x31" matches the length of the packet.

That reminds me of what I saw when I was trying to figure out
what the ALI M5632 windows driver does.  Same seven bytes, at
least in _most_ cases.  Unfortunately I didn't have the patience
to really sort through what was going on.  I suspect that if you
were to take one of those cables apart, you'd see that ALI chip
inside, and that Sitecom just re-badged their silicon along with
the driver for the M5632.  (The "inf" file on Windows might show
much the same thing.)

The reason to want to know more about what Windows does is that
the chip vendor doesn't seem to have published any documentation
on how to make the chip behave when e.g. one end gets unplugged;
or in several other cases here a simple "throw the packets through
the adapter" approach causes trouble.  The M5632 likes to enter
some nasty fault modes, and Linux can't currently recover from
them because the chip is effectively unspecified.


> I am a pure newbie in USB protocols, but after digging the Net I found
> that USB queries have 8-byte header :
> (http://www.beyondlogic.org/usbnutshell/usb6.htm).
> Did a byte fade away, or am I facing an absolutely non-standard 7-byte header 
> ?

That's a different thing you're seeing.  The bulk transfers can have
whatever layout an application protocol needs, and in this case they
stuck seven bytes at the beginning.

Those eight byte headers are for control transfers ... which are very
different, and are only rarely used for transferring data since they
don't have the same kind of throughput as bulk transfers.

- Dave

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

Reply via email to