Bugzilla – Bug 1781
iwl3945_mac_get_tsf() should not return zero
Last modified: 2008-10-28 18:24:15
You need to log in before you can comment on or make changes to this bug.
I also described this bug in the redhat bugzilla here : https://bugzilla.redhat.com/show_bug.cgi?id=459401 it is related to a behaviour of the NetworkManager with iwl3945, when the wifi card is in ad-hoc mode. The NM flip-flops quite rapidly between two association states. After tracking down a bit the problem, I noticed, that the value '0' returned by the function iwl3945_mac_get_tsf() is accepted as a _valid_ value by the mac80211 layer (mlme.c:1605), whereas an _invalid_ value is set to -1LUU, to be sure that the following coparison (beacon_timestamp > rx_timestamp) wont succeeed. So I think that iwl3945_mac_get_tsf() should stay undefined in the hw_ops struct.
Does undefining the function fix your problem?
Created an attachment (id=1608) [details] undefine iwl3945_mac_get_tsf() yes, undefining the function in the iwl3945_hw_ops struct solves this problem.
On a closer look it does not seem as though undefining this function will solve the real problem. You mention that you are running ad-hoc. From your testing we know rx_timestamp is zero (because it uses iwl3945_mac_get_tsf()), but for the test (beacon_timestamp > rx_timestamp) to fail it thus means that your beacon_timestamp is zero ... that is not right. I suggest you turn on IBSS debugging CONFIG_MAC80211_IBSS_DEBUG to find out what is going on. For the stations in IBSS to synchronize they do need to use the timestamp in the beacon, and if you receive zero timestamps there is another problem.
currently, I think that the test (beacon_timestamp > rx_timestamp) is always true, as the log of comment #3 in the RedHat bugzilla suggests it : https://bugzilla.redhat.com/show_bug.cgi?id=459401#c3
Instead of undefining the function, could you change iwl3945_mac_get_tsf() to return -1LUU? In that case we can still know if the function is being called (for debugging). Please add some comment in the code indicating why such a value is returned. Like: /* mac expects unknown rx_timestamp to be 0xFF... */ Please submit your patch to ipw3945-devel@lists.sourceforge.net - I'll send it upstream from there.
done
Patch sent upstream (see http://marc.info/?l=linux-wireless&m=122483096421981&w=2).
Patch is now in wireless-testing. Propose that this bug should be closed.
ok. thanks!
Mark it as Verified.