Re: [zd1211-devs] Shuttle PN18G; re-used USB device ID

2007-08-15 Thread Ulrich Kunitz
 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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs


Re: [zd1211-devs] zd1211rw 2.6.23-rc2 (git)

2007-08-15 Thread Steven
On Mon, 13 Aug 2007 07:50:44 +0200, Uli Kunitz wrote:

 cat /proc/version
 
 and could you send us the relevant output of /var/log/kern.log or dmesg.

I've repeated the process with a debug kernel and debugging zd1211rw 
driver.  Here is the output of /var/log/debug .  I've left it completely 
intact--page down to see the zd1211rw related material.

http://pastebin.com/m2079365a

kern.log:

http://pastebin.com/m734f8cb7

dmesg:

http://pastebin.com/m68fd0102

Starting at 56.765446 is a long series of `iwconfig eth0 essid off`.  
After each successive one I would check the output of `iwconfig`.  The 
first time the essid was set to the only available AP in the area.  The 
next four or five `iwconfig eth0 essid off` resulted in the essid being 
unchanged.  The next after that successfully set the essid to any/off 
but the connection was still successfully negotiated and the network was 
available for use.  I can't say exactly how many more after that but, at 
one point, the result of `iwconfig eth0 essid off` set the essid (as 
reported by iwconfig) to an AP which I have used before but is definitely 
not reachable from within this building.  Unless there was a stray beacon 
which just happened to bounce around the walls Just Right then I have no 
idea how it could've come up with that essid.

That's the output while running 1217432 Aug 15 10:57 vmlinuz-2.6.23-
rc3-070815-vnlla-dbg.  I forgot to capture the actual /proc/version on 
that boot.  Here's /proc/version now (same gcc and Debian version that 
was used to build the debug kernel this morning):

Linux version 2.6.23-rc2-070812-vanilla ([EMAIL PROTECTED]) (gcc version 
4.1.3 20070718 (prerelease) (Debian 4.1.2-14)) #1 Sun Aug 12 15:41:11 PDT 
2007

I'm not familiar with the particulars but, every so often, I see 
interrupt failures reported for usb 1-1.  Could this be a problem with 
UHCI and not zd1211rw?


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs


Re: [zd1211-devs] New device ID for zd1211rw driver: Telegent TG54USB

2007-08-15 Thread Ulrich Kunitz
Reinhard Speyerer wrote:

 I have checked that the Telegent TG54USB WLAN adapter works with the zd1211rw
 driver by adding the following to zd_usb.c and using it in managed mode with 
 WEP:
 
 $ diff -u linux-2.6.22.1/drivers/net/wireless/zd1211rw/zd_usb.c{.orig,}
 --- linux-2.6.22.1/drivers/net/wireless/zd1211rw/zd_usb.c.orig
 2007-08-09 16:09:52.0 +0200
 +++ linux-2.6.22.1/drivers/net/wireless/zd1211rw/zd_usb.c 2007-08-09 
 16:31:34.0 +0200
 @@ -54,6 +54,7 @@
   { USB_DEVICE(0x0586, 0x3401), .driver_info = DEVICE_ZD1211 },
   { USB_DEVICE(0x14ea, 0xab13), .driver_info = DEVICE_ZD1211 },
   { USB_DEVICE(0x13b1, 0x001e), .driver_info = DEVICE_ZD1211 },
 + { USB_DEVICE(0x129b, 0x1666), .driver_info = DEVICE_ZD1211 },
   /* ZD1211B */
   { USB_DEVICE(0x0ace, 0x1215), .driver_info = DEVICE_ZD1211B },
   { USB_DEVICE(0x157e, 0x300d), .driver_info = DEVICE_ZD1211B },
 
 Product: Telegent TG54USB WLAN Adapter
 USB ID: 129b:1666
 Chip ID: zd1211 chip 129b:1666 v4330 high 00-01-36 RF2959_RF pa0 -
 FCC ID: N89-UW620Z
 
 Regards, 
 Reinhard

Reinhard,

thank you. I have added the USB id to the zd1211rw and the
zd1211rw-mac80211 driver in my git tree.

-- 
Uli Kunitz

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs


Re: [zd1211-devs] zd1211rw 2.6.23-rc2 (git)

2007-08-15 Thread Ulrich Kunitz
Steven wrote:

 I've noticed this behavior in the zd1211rw driver for a few months now 
 and haven't seen anyone else mention it.  I think it's odd.  The system 
 is Debian Sid with a git kernel, usually daily.
 
 When I first boot and plug in the wireless usb stick Debian properly 
 identifies it and hotplugs it.  However, the usb stick will not actually 
 associate with any given AP until I use `iwconfig eth0 essid off` at 
 which point it will pick the first AP with which it can negotiate a 
 connection with.  Subsequent `iwconfig eth0 essid off` will toggle the 
 essid (and related AP) between off/any and the target essid.
 
 This is where things become hazy.  If, instead of `iwconfig eth0 essid 
 off` I used `iwconfig eth0 essid ap_essid` the `iwconfig` output will 
 change to reflect the desired essid (and related AP) but the wireless 
 connection will still not be negotiated until `iwconfig eth0 essid off`.  
 Well, sometimes it will--about one in ten tries.
 
 This leads me to, most often, need to do the following:
 
 On one tty (or screen), `ifdown eth0  ifup eth0` and then, while 
 dhclient is trying to find a connection, `iwconfig eth0 essid off` on 
 another tty (or screen).
 
 This is using an AirLink 101, firmware version 4605, zd1211 chip 
 0ace:1211 v4330 full 00-11-a3 AL2230_RF pa0

Steven, 

I have seen the later mail and starting now to see your problem.
It seems that you can get associated if you are not giving the
essidi (off), but you have trouble with the initial setup. I have
not a lot of experience with Debians init scripts and WLAN
installation, but there have been reports that they doesn't work
well with WLAN adapters. I know this a poor situation, but
currently we cannot do a lot about it.

For the softmac driver I'm always recommending to set all the
necessary parameters before you call ifconfig eth0 up and I
believe this is the problem with the default debian configuration.
ifconfig eth0 up means in the WLAN code that the device should
start to associate and this requires the parameters to be set
beforehand.

Kind regards,

Ulrich

-- 
Uli Kunitz

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs


Re: [zd1211-devs] ACKs on zd1211rw-mac80211

2007-08-15 Thread Ulrich Kunitz
Luis Carlos Cobo wrote:

 Hi,
 
 I'm playing with the driver and mac80211 stack to get some ad-hoc-like
 functionality. I am able to do a ping among two non-associated nodes,
 but I get about 9 ping replys (i.e. 8 duplicates) for each ping
 request.
 
 I found out the problem is that the frames are not being acked, so
 they are retransmitted. I haven't found the code for retransmission
 nor for ack generation, so I am not sure what do I need to do to make
 the device generate acks.

We have not implemented ad-hoc before. The ACKs should be
generated if the MAC address is set in the device. There is a
function in zd_chip.c to do it.

 At http://wireless.sipsolutions.net/en/users/Drivers/zd1211rw/mac80211Issues
 I found:
 
 Johannes writes:
 
 In zd1211, we start with hwaddr = dev-wiphy-perm_addr which isn't
 correct either, for a pure monitor mode we want to start with a zero mac
 addr to avoid acking packets. Also, zd1211rw will end up having a NULL
 hwaddr when a monitor interface is added, most likely segfaulting in
 zd_write_mac_addr then.
 
 which leads me to think by default the node would issue acks...
 
 Any help or explanation of how ack generation works for the device
 would be greatly appreciated.
 
 Thanks!
 
 -- 
 Luis Carlos Cobo Rus   GnuPG ID: 44019B60
 cozybit Inc.
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now   http://get.splunk.com/
 ___
 Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
 Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

-- 
Uli Kunitz

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs


Re: [zd1211-devs] ACKs on zd1211rw-mac80211

2007-08-15 Thread Luis Carlos Cobo
On 8/15/07, Ulrich Kunitz [EMAIL PROTECTED] wrote:
 We have not implemented ad-hoc before. The ACKs should be
 generated if the MAC address is set in the device. There is a
 function in zd_chip.c to do it.

Right, zd_write_mac_addr(), that is called from zd_mac_open() which is
the device 'open' operation for mac80211. I am initializing the device
as for STA mode. But I cannot get it to send acks as it does in STA
mode. I wonder if using the STA_RX_FILTER might be part of the problem
and I should be using some specific filter for IBSS that is not
defined in the driver. Is there anywhere to look for more info about
the device?

-- 
Luis Carlos Cobo Rus   GnuPG ID: 44019B60
cozybit Inc.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs


Re: [zd1211-devs] Shuttle PN18G; re-used USB device ID

2007-08-15 Thread Forest Bond
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.
  
   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.

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 can be
  identified)?
 
 I don't want to try it, we had several problems with reloading
 issues.

Got it.

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net


signature.asc
Description: Digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/___
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Re: [zd1211-devs] zd1211rw 2.6.23-rc2 (git)

2007-08-15 Thread Steven
On Wed, 15 Aug 2007 23:34:32 +0200, Ulrich Kunitz wrote:

 For the softmac driver I'm always recommending to set all the necessary
 parameters before you call ifconfig eth0 up and I believe this is the
 problem with the default debian configuration. ifconfig eth0 up means in
 the WLAN code that the device should start to associate and this
 requires the parameters to be set beforehand.

This makes sense.  Before Debian had a wireless infrastructure that's 
exactly what I did.

How long do you expect before mac80211 will fully replace SoftMAC in the 
vanilla kernel tree?  I have the mac80211 kernel tree but haven't been 
able to try it yet.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
Zd1211-devs mailing list - http://zd1211.wiki.sourceforge.net/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs