On 1/16/07, Peter Lueg <[EMAIL PROTECTED]> wrote: > Uli Kunitz wrote: > > Am 15.01.2007 um 14:59 schrieb Peter Lueg: > > > >> Frame WLAN Sequence=n Retry bit=0 > >> Retry 1 WLAN Sequence=n Retry bit=1 > >> Retry 2 WLAN Sequence=n Retry bit=1 > >> Retry 3 WLAN Sequence=n Retry 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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=DEVDEV _______________________________________________ Zd1211-devs mailing list - http://zd1211.ath.cx/ Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
