Thread: [zd1211-devs] Shuttle PN18G; re-used USB device ID
Status: Beta
Brought to you by:
mayne
From: Forest B. <fo...@al...> - 2007-08-14 19:39:31
Attachments:
shuttle-pn18g-zd1211rw.patch
|
Hi, Quick device info: Vendor: Shuttle Model: PN18G (although it doesn't seem to be marked as such) USB Device ID: 07b8:6001 Chip: ZD1211B RF: AL2230S You can see this product here: http://www.newegg.com/Product/Product.aspx?Item=N82E16856997001 The chip description from dmesg: [ 1378.268000] zd1211rw 5-6:1.0: zd1211b chip 07b8:6001 v4810 high 00-12-0e AL2230S_RF pa0 ----- It is a USB device designed to be connected directly to a pin header or other internal connector. It has the large coax antenna mount, and also provides an alternative U.FL connector that a pigtail may be attached to. Anyway, it looks like this is a re-use of a previously existing device ID. I had to modify the driver to get it working (patch attached). I hope this is enough info to get this working in mainline. BTW, it would be nice if the driver printed an error message if a ZD1211 is assumed but the chip is actually a ZD1211B, or vice-versa. It currently fails silently. I'm not sure if there is a good way to determine at runtime what kind of chip you are actually talking to ... ? Thanks for your time. -Forest -- Forest Bond http://www.alittletooquiet.net |
From: Ulrich K. <ku...@de...> - 2007-08-15 06:00:01
|
> Vendor: Shuttle > Model: PN18G (although it doesn't seem to be marked as such) > USB Device ID: 07b8:6001 > Chip: ZD1211B > RF: AL2230S > > The chip description from dmesg: > > [ 1378.268000] zd1211rw 5-6:1.0: zd1211b chip 07b8:6001 v4810 high 00-12-0e AL2230S_RF pa0 ----- > > It is a USB device designed to be connected directly to a pin header or other > internal connector. It has the large coax antenna mount, and also provides an > alternative U.FL connector that a pigtail may be attached to. I know it, I have the older product in my Shuttle. (Actually this was the device that started me to go into this.) > Anyway, it looks like this is a re-use of a previously existing device ID. I > had to modify the driver to get it working (patch attached). We have seen this now several times. Zydas/Atheros told us that this shouldn't happen, because this was the only method, we have been aware to distinguish between both products. > I hope this is enough info to get this working in mainline. Not really, we need to find another way to identify the chip. > BTW, it would be nice if the driver printed an error message if a ZD1211 is > assumed but the chip is actually a ZD1211B, or vice-versa. It currently fails > silently. I'm not sure if there is a good way to determine at runtime what kind > of chip you are actually talking to ... ? That's exactly the problem. The problem is also that resetting the device doesn't work reliably. We need to work on it. > static struct usb_device_id usb_ids[] = { > /* ZD1211 */ > { USB_DEVICE(0x0ace, 0x1211), .driver_info = DEVICE_ZD1211 }, > - { USB_DEVICE(0x07b8, 0x6001), .driver_info = DEVICE_ZD1211 }, > + /* Work-around for Shuttle PN18G, which re-uses this device ID: */ > + { USB_DEVICE(0x07b8, 0x6001), .driver_info = DEVICE_ZD1211B }, > { USB_DEVICE(0x126f, 0xa006), .driver_info = DEVICE_ZD1211 }, > { USB_DEVICE(0x6891, 0xa727), .driver_info = DEVICE_ZD1211 }, > { USB_DEVICE(0x0df6, 0x9071), .driver_info = DEVICE_ZD1211 }, -- Uli Kunitz |
From: Forest B. <fo...@al...> - 2007-08-15 14:55:18
|
Hi, On Wed, Aug 15, 2007 at 07:59:51AM +0200, Ulrich Kunitz wrote: >> Vendor: Shuttle >> Model: PN18G (although it doesn't seem to be marked as such) >> USB Device ID: 07b8:6001 >> Chip: ZD1211B >> RF: AL2230S [...] >> Anyway, it looks like this is a re-use of a previously existing device I= D. >> I had to modify the driver to get it working (patch attached). > We have seen this now several times. Zydas/Atheros told us that > this shouldn't happen, because this was the only method, we have > been aware to distinguish between both products. I see. So, the only apparent solution is to notify Atheros of the problem,= and hope that they chastise the module manufacturer appropriately? >> I hope this is enough info to get this working in mainline. > Not really, we need to find another way to identify the chip. It wouldn't be something you could find in /proc/bus/usb/devices, would it? >> BTW, it would be nice if the driver printed an error message if a ZD1211= is >> assumed but the chip is actually a ZD1211B, or vice-versa. It currently >> fails silently. I'm not sure if there is a good way to determine at run= time >> what kind of chip you are actually talking to ... ? > That's exactly the problem. Clearly :) Sorry for stating the obvious. > The problem is also that resetting the device doesn't work reliably. We n= eed > to work on it. Ah, so you can't use a EAFP/trial-and-error approach (and LBYL is not an op= tion due to the chip not making any mechanism available by which it can be identified)? -Forest --=20 Forest Bond http://www.alittletooquiet.net |
From: Daniel D. <ds...@ge...> - 2007-08-30 12:28:53
|
Forest Bond wrote: > I see. So, the only apparent solution is to notify Atheros of the problem, and > hope that they chastise the module manufacturer appropriately? Your mac OUI is Abocom. We had a previous report of abocom doing this exact crime with the same ID a while ago. It's unfortunate that they are a supplier of shuttle and others... We should look for a better solution to this (I'll ask zydas for advice) but in the mean time there is one other option, you can reprogram your EEPROM with new device ID's. http://sourceforge.net/project/showfiles.php?group_id=129083&package_id=238745 ./zd1211memtool --action=e2pmodify --device=zd1211b \ --usbvid=07b8 --usbpid=6001 \ --modify-vid=0ace --modify-pid=1215 This tool is very lightly tested (only by me, as far as I know). If I made a mistake, it may well destroy your device, so proceed with caution. However, it does work for me. I suggest you use e2pdump to backup the EEPROM first, just in case. Daniel |
From: Ulrich K. <ku...@de...> - 2007-08-15 21:00:51
|
Forest Bond wrote: > Hi, > > On Wed, Aug 15, 2007 at 07:59:51AM +0200, Ulrich Kunitz wrote: > >> Vendor: Shuttle > >> Model: PN18G (although it doesn't seem to be marked as such) > >> USB Device ID: 07b8:6001 > >> Chip: ZD1211B > >> RF: AL2230S > > [...] > > >> Anyway, it looks like this is a re-use of a previously existing device ID. > >> I had to modify the driver to get it working (patch attached). > > > We have seen this now several times. Zydas/Atheros told us that > > this shouldn't happen, because this was the only method, we have > > been aware to distinguish between both products. > > I see. So, the only apparent solution is to notify Atheros of the problem, and > hope that they chastise the module manufacturer appropriately? I would not call that a solution because the devices are out there. > >> I hope this is enough info to get this working in mainline. > > > Not really, we need to find another way to identify the chip. > > It wouldn't be something you could find in /proc/bus/usb/devices, would it? I don't think so, I'm thinking more specific entries in the EEPROM. We would need a debug version that dumps the EEPROM before we load the firmware. We will have to find data at some offset, which reliably would tell us, whether we deal with a ZD1211B instead of a ZD1211. Just classical reverse engineering. If I have such code ready I would send it to you and I would need your dump. I happened to own the old PN18 and so we could compare the EEPROM contents and do something with this. But don't expect any working code before the weekend. > Ah, so you can't use a EAFP/trial-and-error approach (and LBYL is not an option > due to the chip not making any mechanism available by which it can be > identified)? I don't want to try it, we had several problems with reloading issues. -- Uli Kunitz |
From: Forest B. <fo...@al...> - 2007-08-16 00:20:30
|
On Wed, Aug 15, 2007 at 11:00:47PM +0200, Ulrich Kunitz wrote: > Forest Bond wrote: > > >> I hope this is enough info to get this working in mainline. > >=20 > > > Not really, we need to find another way to identify the chip. > >=20 > > It wouldn't be something you could find in /proc/bus/usb/devices, would= it? >=20 > I don't think so, I'm thinking more specific entries in the > EEPROM. We would need a debug version that dumps the EEPROM before > we load the firmware. We will have to find data at some offset, > which reliably would tell us, whether we deal with a ZD1211B > instead of a ZD1211. Just classical reverse engineering. If I have > such code ready I would send it to you and I would need your dump. I > happened to own the old PN18 and so we could compare the EEPROM > contents and do something with this. But don't expect any working > code before the weekend. Ok. I'm not in a huge rush, although it would be nice to see this work out positively. I'm available to help out however I can. > > Ah, so you can't use a EAFP/trial-and-error approach (and LBYL is not an > > option due to the chip not making any mechanism available by which it c= an be > > identified)? >=20 > I don't want to try it, we had several problems with reloading > issues. Got it. -Forest --=20 Forest Bond http://www.alittletooquiet.net |
From: Remco <re...@d-...> - 2007-08-16 17:48:35
|
> I don't think so, I'm thinking more specific entries in the > EEPROM. We would need a debug version that dumps the EEPROM before > we load the firmware. We will have to find data at some offset, > which reliably would tell us, whether we deal with a ZD1211B > instead of a ZD1211. Just classical reverse engineering. ... > Hopefully this will help. I don't really know the zd1211rw code so I'm not sure if / how the following might fit. I seem to be able to make my ZD1211 appear as a ZD1211B. I used some code I worked on more then 1.5 year ago but it all boils down to changing the WS11Ub firmware data and using the firmware/EEPROM writing code that was originally in the vendor driver. (I don't recall which version of the vendor driver I used as a basis but it's some code that I don't expect to have changed) I accomplished the following: 1) Use my code to write WS11Ub data with a ZD1211B product ID (1215) and a bogus version (4331) to my ZD1211 device. Logging excerpts from loading the zd1211rw driver after this "firmware update" show it's detected as a ZD1211B: usb 1-2: print_id() 0ace:1215 v4331 high usb 1-2: request_fw_file() fw name zd1211/zd1211b_ub usb 1-2: firmware version 0x4810 and device bootcode version 0x4331 differ usb 1-2: request_fw_file() fw name zd1211/zd1211b_ur usb 1-2: upload_code() transfer size 3584 usb 1-2: upload_code() firmware confirm return value 0x01 usb 1-2: upload_code() transfer size 3720 usb 1-2: upload_code() firmware confirm return value 0x01 usb 1-2: request_fw_file() fw name zd1211/zd1211b_uphr usb 1-2: upload_code() transfer size 4096 usb 1-2: upload_code() transfer size 1024 usb 1-2: upload_code() firmware confirm return value 0x01 zd1211rw 1-2:1.0: RF2959 is currently not supported for ZD1211B devices I didn't actually try to use it for WLAN at this point. 2) Use my code to write the original WS11Ub data to my ZD1211 device. Logging excerpts from loading the zd1211rw driver after this "firmware update" show it's detected as a ZD1211: print_id() 0ace:1211 v4330 high usb 1-2: request_fw_file() fw name zd1211/zd1211_ub usb 1-2: upload_firmware() firmware device id 0x4330 is equal to the actual device id usb 1-2: request_fw_file() fw name zd1211/zd1211_uphr usb 1-2: upload_code() transfer size 4096 usb 1-2: upload_code() transfer size 1024 usb 1-2: upload_code() firmware confirm return value 0x01 I could still use it for WLAN at this point. After an update the MAC address appears as 00:00:55:66:66:66. Unplug/replug of the device will show the original MAC. The code I used is known as function "int zd1211_Download_IncludeFile(struct zd1205_private *macp)" in file "zd1211.c" of the vendor driver. The part executed in "if (macp->release != EEPVer){ ... } " is responsible for updating the data in the device. I determined the following by scanning the WS11Ub data of the vendor driver for things like vendor ID, product ID, HW version. I annotated the interesting spots in the WS11Ub data: T) trigger that determines whether a firmware update will run or not M) default MAC address ??? U) USB vendor/product ID/HW version (Note: the ZD1211B data uses a ZD1211 product ID 0x1211, this should probably be 0x1215) Annotated WS11Ub data: (only the first 128 bytes) for ZD1211: 0x00, 0xF0, 0x66, 0xFE, 0x67, 0xFE, 0x68, 0xFE, 0x69, 0xFE, 0x6A, 0xFE, 0x6B, 0xFE, 0x6C, 0xFE, 0x6D, 0xFE, 0x09, 0x63, 0xD6, 0x79, 0x57, 0x94, 0xD1, 0xD4, 0x0A, 0x95, 0x17, 0xF8, 0xD1, 0xD4, 0x0A, 0x95, 0xD2, 0x07, 0x00, 0xEE, 0xC1, 0xD4, 0x00, 0xEE, 0x0F, 0x9F, 0x95, 0xF8, ==> 0x30, 0x43, <== T) 0x10, 0x00, 0x0D, 0x00, 0x00, 0x00, ==> 0x00, 0x00, M) 0x55, 0x66, 0x66, 0x66, <== 0x00, 0x00, 0x6A, 0x6A, M) 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xFF, 0x07, 0x00, 0x00, 0x12, 0x01, 0x00, 0x02, 0xFF, 0xFF, 0xFF, 0x40, ==> 0xCE, 0x0A, 0x11, 0x12, 0x30, 0x43, <== U) 0x10, 0x20, 0x00, 0x01, 0x04, 0x03, 0x09, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x52, 0x52, for ZD1211B: 0x00, 0xF0, 0x66, 0xFE, 0x67, 0xFE, 0x68, 0xFE, 0x69, 0xFE, 0x6A, 0xFE, 0x6B, 0xFE, 0x6C, 0xFE, 0x6D, 0xFE, 0x09, 0x63, 0xD6, 0x79, 0x57, 0x94, 0xD1, 0xD4, 0x0A, 0x95, 0x17, 0xF8, 0xD1, 0xD4, 0x0A, 0x95, 0xD2, 0x07, 0x00, 0xEE, 0xC1, 0xD4, 0x00, 0xEE, 0x0F, 0x9F, 0x95, 0xF8, ==> 0x10, 0x48, <== T) 0x10, 0x00, 0x0D, 0x00, 0x00, 0x00, ==> 0x00, 0x00, M) 0x55, 0x66, 0x66, 0x66, <== 0x00, 0x00, 0x6A, 0x6A, M) 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0x6A, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xB2, 0xFF, 0x07, 0x00, 0x00, 0x12, 0x01, 0x00, 0x02, 0xFF, 0xFF, 0xFF, 0x40, ==> 0xCE, 0x0A, 0x11, 0x12, 0x10, 0x48, <== U) 0x10, 0x20, 0x00, 0x01, 0x04, 0x03, 0x09, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x52, 0x52, |