Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > I think you just got very lucky (or unlucky) to have the same dialog > token, because we start from 0 Right, it seems to be the case. > - maybe we should initialize it to a > random value to flush out such issues. The problem I can see is that the dialog_tokens are 8-bit, way too small to eliminate conflicts. > Really what I think probably happened is that one of your stations lost > the connection to the other, and didn't tell it about it in any way - so > the other kept all the status alive. You must have missed my previous mail - I simply rebooted that station, and alternatively rmmoded/modprobed ath9k. But the problem originated in a station going out of and back in range, in fact. > I suspect to make all this work well we need to not only have the fixes > I made recently to actually send and parse deauth frames, but also to > even send an auth and reset the state when we receive that, so if we > move out of range and even the deauth frame is lost, we can still reset > properly. That's one thing. The other is a station trying ADDBA for the first time after boot (while the local station has seen it before that reboot). > In any case, this is not the right approach - we need to handle the > "lost connection" case better I suspect, but since you don't say what > really happened I don't really know that that's what you're seeing. I guess we need to identify "new connection" reliably. Otherwise, the new connections are treated as old ones and it doesn't work. Now how can it be fixed? -- Krzysztof Halasa ŁUKASIEWICZ Research Network Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
