FYI, r67-2 is negative also for me. So far I have not had any success in nailing it down from the 2.0->2.4 upgrade diffs. One suspect was (... || 1) in a if condition related to AP selection but it didn't solve the problem.
I forgot to mention earlier: the funniest side-effect this bug has is a jam in POST (Post On Self Test) after reboot. When I remove the stick, the POST continues to whatever it should (e.g., resets after removal if reset button was pressed while the stick was inserted). I still have "We Lose AP for 5 seconds" I will probably try to change back to 2.0.0.0 channel switching while keeping other modification fomr 2.4.0.0, as it had a strange pattern in my tests (remains on the last allowedchannel for a very long period) to see if that's the cause. Besides that, we have another suspect: > Additionally, here's the (relevant) output of dhclient when I tried to > run it with the broken driver: > > DHCPREQUEST on wlan0 to 255.255.255.255 port 67 > DHCPREQUEST on wlan0 to 255.255.255.255 port 67 > ip length 328 disagrees with bytes received 325. This seems interesting. 3 bytes missing, which happens to be exactly the *new* value of the ZD_RX_OFFSET (in 2.4.0.0) 2.0.0.0 had zero offset. Could they have forgotten to change the offset somewhere which corrupts some packets? I just wonder why it works for some folks then... -- i. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
