Re: [zd1211-devs] zd1211-rw : packet are send tree times
Hi,
PS : the monitor mode return garbage. Is that normal ?
I think this is a bug in ethereal 0.99.0. The older versions work OK for
me.
I check the intel driver and they seem to use radiotap only when
CONFIG_IEEE80211_RADIOTAP is defined.
But it seems CONFIG_IEEE80211_RADIOTAP is never defined in the 2.6.17.
I wrote a small patch that make work monitor mode by removing radiotap.
I also add the 2 sagem ids.
the zd1211 (zd1211 chip 079b:004a v4330 high 00-60-b3 AL2230_RF pa0 g--)
doens't seem to send duplicate frame.
I'll try to get some trace for the zd1211b.
Matthieu
diff -ur zd1211_2006-06-19/zd_mac.c zd1211_2006-06-19.mod/zd_mac.c
--- zd1211_2006-06-19/zd_mac.c 2006-06-11 14:37:31.0 +0200
+++ zd1211_2006-06-19.mod/zd_mac.c 2006-06-22 11:01:16.0
+0200
@@ -412,7 +412,11 @@
mac-netdev-type = ARPHRD_ETHER;
break;
case IW_MODE_MONITOR:
+#ifdef CONFIG_IEEE80211_RADIOTAP
mac-netdev-type = ARPHRD_IEEE80211_RADIOTAP;
+#else
+ mac-netdev-type = ARPHRD_IEEE80211;
+#endif
break;
default:
dev_dbg_f(zd_mac_dev(mac), wrong mode %u\n, mode);
@@ -951,9 +955,11 @@
skb = dev_alloc_skb(sizeof(struct zd_rt_hdr) + length);
if (!skb)
return -ENOMEM;
+#ifdef CONFIG_IEEE80211_RADIOTAP
if (ieee-iw_mode == IW_MODE_MONITOR)
fill_rt_header(skb_put(skb, sizeof(struct zd_rt_hdr)),
mac,
stats, status);
+#endif
memcpy(skb_put(skb, length), buffer, length);
r = ieee80211_rx(ieee, skb, stats);
diff -ur zd1211_2006-06-19/zd_usb.c zd1211_2006-06-19.mod/zd_usb.c
--- zd1211_2006-06-19/zd_usb.c 2006-06-11 14:37:31.0 +0200
+++ zd1211_2006-06-19.mod/zd_usb.c 2006-06-22 10:44:28.0
+0200
@@ -39,9 +39,11 @@
{ USB_DEVICE(0x6891, 0xa727), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x0df6, 0x9071), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x157e, 0x300b), .driver_info = DEVICE_ZD1211 },
+ { USB_DEVICE(0x079b, 0x004a), .driver_info = DEVICE_ZD1211 },
/* ZD1211B */
{ USB_DEVICE(0x0ace, 0x1215), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x157e, 0x300d), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x079b, 0x0062), .driver_info = DEVICE_ZD1211B },
{}
};
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642
___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] zd1211-rw : packet are send tree times
Matthieu CASTET wrote: I check the intel driver and they seem to use radiotap only when CONFIG_IEEE80211_RADIOTAP is defined. But it seems CONFIG_IEEE80211_RADIOTAP is never defined in the 2.6.17. Indeed - it is only the out-of-tree version which enables radiotap by default. I didn't realise it was so easy to turn on in the in-kernel version though. I wrote a small patch that make work monitor mode by removing radiotap. I think first we need to get to the root of the problem, because the old ethereal still works OK. It may just be an ethereal bug? I also add the 2 sagem ids. the zd1211 (zd1211 chip 079b:004a v4330 high 00-60-b3 AL2230_RF pa0 g--) doens't seem to send duplicate frame. Strange. Thanks, I'll apply the patch. By the way, we can rejoice because my ipw3945 doesn't appear to be as blind/deaf as my other devices, I appear to have reliable monitor mode through that :) Daniel Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] zd1211-rw : packet are send tree times
Matthieu CASTET wrote: I manage to associate to an AP, but when I ping the packet are sent tree times : - when I ping from the client to the AP, the AP see 3 ping request on sent 3 ping reply. - when I ping from the AP to the client, the client see 1 ping request. So it seem the packet are duplicated when sending them on the air. I have also noticed this. The driver only transmits them once (as you can see in your client tcpdump), but the hardware seems to duplicate them. I suspect it is possibly timing out after no acknowledgment received and retransmitting -- maybe we aren't writing the correct timing values into the registers or something. Now, some duplication is perfectly reasonable on networks (in this case we are just getting a *lot* of it) and it is up to the protocol to handle this. ICMP doesn't have any error checking or correction so it's not out-of-this-world unreasonable that you are seeing the duplication. Standard protocols like TCP will handle duplicates just fine. Another interesting thing is that you aren't seeing duplicate ping replies received on the client - I see that a lot (or maybe tcpdump is just hiding duplicates?). It's not ultimately clear whether the driver should be weeding out duplicates (I think probably not) so this is again somewhat normal. Anyway, does the driver work OK for normal usage (accessing the network, browsing websites, etc..)? If so, I will add the device ID. PS : the monitor mode return garbage. Is that normal ? I think this is a bug in ethereal 0.99.0. The older versions work OK for me. Waiting for Ulrich's take on this as he wrote that code, but I think it may be ethereal-specific: the out-of-tree intel wireless drivers now use radiotap and we see the same bug there. What is really really really frustrating me is that I can't get monitor mode working reliably. My intel card works for about 20 seconds then goes partially blind and only sees about 50% of the traffic. After I finally figure out that ethereal is the culprit, ZD1211 monitor mode also seems to be missing quite a few frames. I have a new laptop with an ipw3945 which I'll try next. It's just getting really awkward as the ipw3945 driver requires an out-of-tree ieee80211 so I'll have to set up another kernel, etc... If you have a working monitor mode setup it would be interesting to see if you see the same kind of duplication from the ZD1211 vendor driver. Thanks, Daniel ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
