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
