On Thu, 2006-01-05 at 23:15 -0500, Dan Williams wrote:
NM does try to set the bitrate to 0 in infrastructure mode.
to the WEXT spec, a bitrate of 0 means "default" or "unset", which
means the card needs to clear any previously set bitrate and switch to
its default bitrate.
OK, then as soon as we fix the driver to automatically fall back to a
working bitrate, rather than _staying_ at its default bitrate even
though it can't associate with the AP, we should be fine with NM.
NM works OK for me with it anyway, since I can actually use 54M rate
(although it's a lot better if I back down to 11M. I think we also have
a txpower problem with higher rates).
What exactly are the issues that the driver has with NM?
I don't think any of them are NM's fault at this point. NM just pokes at
it in a manner which is different to most of its testing, and undoes our
workarounds like the 'rate 11M' trick.
One thing I did notice was that while the module lacked a module table
entry for hotplug, NM complained of not knowing its driver name. Then it
repeatedly triggered an assertion about a mutex being NULL. Remove the
entries matching your card from /lib/modules/`uname -r`/modules.pcimap
I've now added the appropriate table to the bcm43xx driver -- but I'm
not sure I should have done; I'm not entirely sure I _want_ it being
autoloaded just yet. NM ought to have coped, surely?