On Thu, 2008-11-20 at 10:54 -0800, Inaky Perez-Gonzalez wrote: > On Thursday 20 November 2008, Dan Williams wrote: > > On Wed, 2008-11-19 at 11:50 -0800, Inaky Perez-Gonzalez wrote: > > > On Wednesday 19 November 2008, charles zhuang wrote: > > > > The Asus dongle will be seen as a mass storage device, it contain > > > > bunches of windows program, setup.exe, dll, cab file. When I plug in to > > > > windows, it will install the wimax driver, but failed to install the > > > > usb driver. From the network connection (windows), I do see a new > > > > Ethernet connection.\ > > > > > > My guess is you see that connection *after* you install the driver, is > > > that correct? > > > > > > > I found this confusing, is there a separate wimax dongle for linux and > > > > for windows? I thought dongle itself will only contain the wimax mac > > > > and RF, download a firmware from host to drive it, but looks like not. > > > > > > Not necessarily, but it is becoming more common that makers of USB device > > > implement also an small flash disk (I guess it is cheap enough) so it > > > also serves to distribute drivers. > > > > > > Chances are this dongle won't work in Linux -- unless ASus goes around > > > and implements the support for it. > > > > If the mass-storage device is a "driver cd" thing, then the correct > > method for "fixing" these devices is to write a small shim driver for > > libusual that (by default) simply ejects the mass-storage device > > whenever it's inserted, but allows override of this behavior using a > > module parameter. See the following Sierra TruInstall patches for how > > this should happen: > > Oh, so that's how they do it? They wait for a eject command to "change" > personas and become their real device? Yep. Some Option devices need to be sent the SCSI REZERO command instead of a simple eject. Firmware dependent method really. The Option 'hso' devices have: - bDeviceClass 0 (Defined at Interface level) - bDeviceSubClass 0 - bDeviceProtocol 0 + bDeviceClass 255 Vendor Specific Class + bDeviceSubClass 255 Vendor Specific Subclass + bDeviceProtocol 255 Vendor Specific Protocol that's - == pre REZERO, + == post REZERO. Same thing for the Huawei modems. So you can at least usually tell whether it's supposed to be the modem or the mass-storage device on the first plug. > Out of curiosity, how would it work when the device is reconnected and/or the > system boots? The device requires another eject to switch into being what it > should be? Yep. On Windows and Mac OS X, the custom drivers that the devices have on their mass-storage CD thing probably handle this for you automatically. As should we under Linux :) Dan
