Re: [zd1211-devs] anomalous behaviour in handling the WLAN retries
Uli Kunitz wrote: Am 15.01.2007 um 14:59 schrieb Peter Lueg: FrameWLAN Sequence=nRetry bit=0 Retry 1 WLAN Sequence=nRetry bit=1 Retry 2 WLAN Sequence=nRetry bit=1 Retry 3 WLAN Sequence=nRetry bit=1 Retry 4 WLAN Sequence=n+1 Retry bit=0 (Fault) Retry 5 WLAN Sequence=n+1 Retry bit=1 Retry 6 WLAN Sequence=n+2 Retry bit=0 (Fault) Retry 7 WLAN Sequence=n+2 Retry bit=1 Retry 8 WLAN Sequence=n+3 Retry bit=0 (Fault) Retry 9 WLAN Sequence=n+3 Retry bit=1 This behaviour violates the afore mentioned standard. We found the same behaviour under Linux and Windows OS. The ZD1211 retry register is set to 2, which gives 4 retries. (It has four bits so you could ask for 2^15 retries. ;-) Can i increment/decrement the retries? Which register and bit contribute the retry rate? I cannot explain packets 4 to 9 -- this might be firmware behaviour, which we cannot control. However the d80211 developers discussed to implement such behaviour in the new d80211 stack. Does the 802.11 standard really care, what the payload is? What prevents me to send the same UDP packet three times? You can see this behaviour in a bad WLAN environment. The access point saw all 802.11 frames from the client and send an ACK. This Ack will be lost. On more than 3 retries you become an duplicated frame. UDP is not important. The problem is that the IP stack becomes duplicated packets. On the 802.11 layer it is a new packet, because it has a new sequence number. Regards, Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] anomalous behaviour in handling the WLAN retries
On 1/16/07, Peter Lueg [EMAIL PROTECTED] wrote: Uli Kunitz wrote: Am 15.01.2007 um 14:59 schrieb Peter Lueg: FrameWLAN Sequence=nRetry bit=0 Retry 1 WLAN Sequence=nRetry bit=1 Retry 2 WLAN Sequence=nRetry bit=1 Retry 3 WLAN Sequence=nRetry bit=1 Retry 4 WLAN Sequence=n+1 Retry bit=0 (Fault) Retry 5 WLAN Sequence=n+1 Retry bit=1 Retry 6 WLAN Sequence=n+2 Retry bit=0 (Fault) Retry 7 WLAN Sequence=n+2 Retry bit=1 Retry 8 WLAN Sequence=n+3 Retry bit=0 (Fault) Retry 9 WLAN Sequence=n+3 Retry bit=1 This behaviour violates the afore mentioned standard. We found the same behaviour under Linux and Windows OS. The ZD1211 retry register is set to 2, which gives 4 retries. (It has four bits so you could ask for 2^15 retries. ;-) Can i increment/decrement the retries? Which register and bit contribute the retry rate? I cannot explain packets 4 to 9 -- this might be firmware behaviour, which we cannot control. However the d80211 developers discussed to implement such behaviour in the new d80211 stack. Does the 802.11 standard really care, what the payload is? What prevents me to send the same UDP packet three times? You can see this behaviour in a bad WLAN environment. The access point saw all 802.11 frames from the client and send an ACK. This Ack will be lost. On more than 3 retries you become an duplicated frame. I have seen this same behavior on lightly loaded nets where there shouldn't be much interference. It is not clear to me that this isn't the result of a software problem. In my case the AP is receiving every frame without error and the acks are not making it back. It just seems to me that if noise was causing this the AP would have trouble receiving the frames too. For example the firmware could have a bug in it when dealing with the radio. It also has a deadman timer which resets the radio if packets aren't received for a few seconds. When the deadman timer expires it recovers the radio masking the effects of the software bug. I have fixed errors like this in other network drivers multiple times. Developers should not run their systems with the deadman timers enabled. Instead they should figure out why the chip is getting stuck. Of course we don't have the source to the firmware to see what is going on. UDP is not important. The problem is that the IP stack becomes duplicated packets. On the 802.11 layer it is a new packet, because it has a new sequence number. Regards, Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs -- Jon Smirl [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] anomalous behaviour in handling the WLAN retries
Am 16.01.2007 um 09:57 schrieb Peter Lueg: Can i increment/decrement the retries? Which register and bit contribute the retry rate? ZD1211: CR_ZD1211_RETRY_MAX (exponent of two, so 1 will give two retries) ZD1211B: CR_ZD1211B_RETRY_MAX (each byte contains the retries -- there are four queues supporting 802.11e, appear to be also expnents of 2) Uli - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
[zd1211-devs] Forcing b mode?
Hi, is there a way to force the zd1211b to use b mode, even if the access point I'm connecting to also can do g? Couldn't find it on zd1211.ath.cx :( Thanks, Bas. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
Re: [zd1211-devs] Forcing b mode?
On 1/16/07, Bas Schulte [EMAIL PROTECTED] wrote: Hi, is there a way to force the zd1211b to use b mode, even if the access point I'm connecting to also can do g? iwconfig eth1 rate 11M Couldn't find it on zd1211.ath.cx :( Thanks, Bas. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs -- Jon Smirl [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
