Ah well... looks like I hit the end of the road for now. I tried kernel 2.6.6-rc3 (plus the two patches from this mailing list), and now I get a gazillion oopses from the kernel before I even hit the login prompt (the thing oopses so much I can't make anything out of it, except that it seems related to a process called consolelog.sh), well.. with that kinda state I can'd do any testing at all... even thought after I went back to 2.4 CDCEther failed to retrieve the MAC address.. which means the modem was indeed again messed up. I guess afterall the modem does has some kind of firmware bug when requesting strings based on indexes (but it works alright when requesting the whole descriptor string), and that's why it works with CDCEther... and the windows driver (I suppose that driver queries the modem that way as well, if it didn't and it didn't work then I'd have a very simple and valid argument to get it "changed" or updated with my isp). Well.. thanks for your time in trying to help me out. I'll have to wait for a usbnet upgrade that automagically fixes it or until I can convince my isp that my modem is buggy, whichever miracle happens first.
One minor question though... can power failures (or accidental disconnects, whichever) cause firmware corruption? That thing shouldn't happen, but considering that it is highly unlikely that my isp did any kind of firmware upgrade and that my modem WAS indeed working with usbnet before suggests that somehow the firmware just got "magically corrupted"... On Sun, 9 May 2004 15:31:19 -0400 (EDT) Alan Stern <[EMAIL PROTECTED]> wrote: > On Sun, 9 May 2004, Zariel Skotlex wrote: > > > Anyway, lsusb -v yields the following (I decided to include everything.. > > which is just the ohci, ehci and modem data): > > As you found out, the string descriptors values listed here each belong to > the previous descriptor: > > > > > Bus 002 Device 002: ID 07b2:5100 Motorola BCS, Inc. > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 1.10 > > bDeviceClass 2 Communications > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize0 32 > > idVendor 0x07b2 Motorola BCS, Inc. > > idProduct 0x5100 > > bcdDevice 1.01 > > iManufacturer 1 > > Blank, maybe because this is the first string query. > > > iProduct 2 Broadcom Corporation > > That's really the Manufacturer. > > > iSerial 3 USB Cable Modem > > That's really the Product. > > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 80 > > bNumInterfaces 2 > > bConfigurationValue 1 > > iConfiguration 4 > > I would expect that to be the Serial number but instead it's blank -- in > other words, it's correct. Who knows why... > > > bmAttributes 0xe0 > > Self Powered > > Remote Wakeup > > MaxPower 100mA > > unknown descriptor type: 05 24 00 10 01 > > unknown descriptor type: 05 24 06 00 01 > > unknown descriptor type: 0d 24 0f 03 00 00 00 00 ea 05 00 00 00 > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 1 > > bInterfaceClass 2 Communications > > bInterfaceSubClass 6 Ethernet Networking > > bInterfaceProtocol 0 > > iInterface 5 000CE53D2E1B > > That's really the Serial number. > > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x85 EP 5 IN > > bmAttributes 3 > > Transfer Type Interrupt > > Synch Type none > > wMaxPacketSize 8 > > bInterval 64 > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 1 > > bAlternateSetting 0 > > bNumEndpoints 0 > > bInterfaceClass 10 Data > > bInterfaceSubClass 0 Unused > > bInterfaceProtocol 0 > > iInterface 6 Communication Interface Class > > That's the string for the previous interface. Notice that the string > index listed here is 6. > > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 1 > > bAlternateSetting 1 > > bNumEndpoints 2 > > bInterfaceClass 10 Data > > bInterfaceSubClass 0 Unused > > bInterfaceProtocol 0 > > iInterface 6 Data Interface Class > > That's the string for the previous interface. Notice that the string > index again is 6. > > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x81 EP 1 IN > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type none > > wMaxPacketSize 64 > > bInterval 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x02 EP 2 OUT > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type none > > wMaxPacketSize 64 > > bInterval 0 > > Language IDs: (length=42) > > 0044 Tatar(Tatar) > > 0061 Nepali(Nepali) > > 0074 (null)((null)) > > 0061 Nepali(Nepali) > > 0020 Urdu(Urdu) > > 0049 Tamil(Tamil) > > 006e (null)((null)) > > 0074 (null)((null)) > > 0065 (null)((null)) > > 0072 (null)((null)) > > 0066 (null)((null)) > > 0061 Nepali(Nepali) > > 0063 (null)((null)) > > 0065 (null)((null)) > > 0020 Urdu(Urdu) > > 0043 Uzbek(Uzbek) > > 006c (null)((null)) > > 0061 Nepali(Nepali) > > 0073 (null)((null)) > > 0073 (null)((null)) > > If you go to the trouble of decoding the ASCII values, you'll find that > this says "Data Interface Class", which is the string for the previous > interface. These string values are corroborated by the 2.4 results: > > > Finally.. here's how usbls -v looks like under 2.4 (ie when the modem > > works): > > > > //------------------------------------------------------- > > Bus 002 Device 003: ID 07b2:5100 Motorola BCS, Inc. > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 1.10 > > bDeviceClass 2 Communications > > bDeviceSubClass 0 > > bDeviceProtocol 0 > > bMaxPacketSize0 32 > > idVendor 0x07b2 Motorola BCS, Inc. > > idProduct 0x5100 > > bcdDevice 1.01 > > iManufacturer 1 Broadcom Corporation > > iProduct 2 USB Cable Modem > > iSerial 3 000CE53D2E1B > > bNumConfigurations 1 > > Configuration Descriptor: > > bLength 9 > > bDescriptorType 2 > > wTotalLength 80 > > bNumInterfaces 2 > > bConfigurationValue 1 > > iConfiguration 4 > > bmAttributes 0xe0 > > Self Powered > > Remote Wakeup > > MaxPower 100mA > > unknown descriptor type: 05 24 00 10 01 > > unknown descriptor type: 05 24 06 00 01 > > unknown descriptor type: 0d 24 0f 03 00 00 00 00 ea 05 00 00 00 > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 0 > > bAlternateSetting 0 > > bNumEndpoints 1 > > bInterfaceClass 2 Communications > > bInterfaceSubClass 6 Ethernet Networking > > bInterfaceProtocol 0 > > iInterface 5 Communication Interface Class > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x85 EP 5 IN > > bmAttributes 3 > > Transfer Type Interrupt > > Synch Type none > > wMaxPacketSize 8 > > bInterval 64 > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 1 > > bAlternateSetting 0 > > bNumEndpoints 0 > > bInterfaceClass 10 Data > > bInterfaceSubClass 0 Unused > > bInterfaceProtocol 0 > > iInterface 6 Data Interface Class > > Interface Descriptor: > > bLength 9 > > bDescriptorType 4 > > bInterfaceNumber 1 > > bAlternateSetting 1 > > bNumEndpoints 2 > > bInterfaceClass 10 Data > > bInterfaceSubClass 0 Unused > > bInterfaceProtocol 0 > > iInterface 6 Data Interface Class > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x81 EP 1 IN > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type none > > wMaxPacketSize 64 > > bInterval 0 > > Endpoint Descriptor: > > bLength 7 > > bDescriptorType 5 > > bEndpointAddress 0x02 EP 2 OUT > > bmAttributes 2 > > Transfer Type Bulk > > Synch Type none > > wMaxPacketSize 64 > > bInterval 0 > > Language IDs: (length=4) > > 0409 English(US) > > //------------------------------------------------------- > > I ran a vimdiff between both, and lo and behold (CDCEther is on the left, > > usbnet on the right).... > > > > //------------------------------------------------------- > > iManufacturer 1 Broadcom Corporation | iManufacturer 1 > > iProduct 2 USB Cable Modem | iProduct 2 Broadcom > > Corporation > > iSerial 3 000CE53D2E1B | iSerial 3 > > USB > > Cable Modem > > iInterface 5 Communication Interface Class | iInterface > > 5 000CE53D2E1B > > //------------------------------------------------------- > > > > I looks like somewhere usbnet read the data with an offset it shouldn't have > > (or did the string descriptor came with an unexpected offset?). Hmm... > > interesting(this would explain why it fails on the get HW address... instead > > of the hardware address it is reading "Communication Interface Class"!) > > Just so. For some reason, under 2.6 the modem is returning for most of > the queries the answer to the _previous_ query. This makes no sense to me > at all. It's not a simple matter of changing the string index -- on the > two occasions the modem was asked for string 6 it gave two different > results! > > I can't imagine why it should behave like this. Firmware bug, obviously, > but a very strange one. > > However, I can tell you that the code responsible for retrieving string > descriptors changed between 2.4 and 2.6. Under 2.4 the code simply asks > for 255 bytes of data and accepts as much as the device will send. Under > 2.6 the code first asks just for 2 bytes (which contain the actual length) > and then asks for just that much data. But I can't see how this would > cause the modem to misbehave in the way you're seeing. > > Alan Stern >
pgp00000.pgp
Description: PGP signature
