On Wednesday 18 March 2009, Johannes Berg wrote: > On Wed, 2009-03-18 at 13:48 +0100, Ivo van Doorn wrote: > > > Excellent thanks. :) > > > > Johannes, my previous assumption is apparently correct, > > The following is happening: > > > > ieee80211_open() > > -> ops->add_interface() > > -> ieee80211_start_mesh() > > -> ieee80211_if_config() > > -> ops->config_interface() > > -> ieee80211_hw_config() > > -> ops->config() > > > > Because config_interface() is called before config() the radio > > is not enabled at the moment config_interface() is called and > > the call to config() will effectively disable beaconing. > > Ah. I thought you were saying ->start() came after ->config_interface(), Yeah that was my first guess :) > ->config() coming after it makes no sense either but we haven't even > tried to avoid that so far... In fact, it is perfectly legal for > ->config() to be called after ->config_interface() when, for example, > you change the channel. Not that I disagree -- we should be setting the > beacon interval before enabling beaconing... True, the problem however is that when enabling the radio it is possible/likely that a lot of settings will be lost. For rt2x00 we must reset almost all registers to make sure everything is set correctly again. > What exactly is the problem here? The fact that we don't enable the > radio until after having configured beaconing? I'm not sure how to solve > this, to be honest. Neither do I, perhaps we should make sure that a call to config() when the enabled_radio field has changed should trigger additional reconfigurations as well. But I don't really like such a solution.. :( Perhaps should check if a beacon was provided while the radio was off, and either request a new beacon or upload the previously provided beacon when the radio is being enabled. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
