Hello!

I'm terribly sorry, but it looks like I cannot make the 0.9.4.1 release
before I leave.  I'll be back on August 26.  In the meantime, my time,
connectivity and ability to test anything will be very limited.

The main blocker is ticket 1903 (https://madwifi.org/ticket/1903).
Changing frequency in master mode causes hard lockup if the interface is
up.

I hoped it would be easy to backport a fix, either from the trunk or
from the DFS branch, but it's not so easy.  The code went through
significant changes.  It is also different in the trunk and in the DFS
branch.

Possible solutions are:

1) Back out revisions 2613 and 2614.  They fix ticket 1388
(https://madwifi.org/ticket/1388), so we'll have to reopen and
reschedule it.  It's not an earth-shattering problem, but users could
end up with AP operating on wrong channels because MadWifi would ignore
their requests.

2) Disable channel switch.  Return -EBUSY when trying to change channel
on an active device.  That would be better because we won't mislead
users that we are switching the channel.  However, we would still keep
the code that causes the lockup.  We would just close one way to reach
that code.  I suspect the "doth_chanswitch" ioctl could still be a
problem.

3) Disable channel switch and 802.11h.  That could make us feel better
that the bad code won't be reached.  However, the price is disabling a
feature in the driver (whether useful of not is an open question), and
we are not getting the real piece of mind in exchange.

4) Debug the lockup and fix the channel switch.  That may involve
porting some DFS functionality.  I know too little about DFS to attempt
it.  Besides, the version of HAL used in MadWifi 0.9.4 may be limited
with regard to DFS support.

Ticket #1889 suggests that we may be encountering a node counting bug.
That's something we should fix.  It also makes me hope that the fix is
not in one of those big DFS patches.  Thus, bisecting the bug may be
worth it.

I urge anyone who worked on the DFS code to have a look at the issue and
try to fix it in one way or another.

Another problem is that I was unable to test the 0.9.4 branch
extensively.  But my impression is that we have some bugs sitting
around.  In particular, I was unable to make some cards to communicate
in adhoc mode with WEP.  An AR5006EG card would get garbage instead of
real data (I didn't have a chance to check what was on the air).  But
that's just one little thing I happened to try.  We should check all
modes and all encryption options.

I think the best approach would be that we keep testing and fixing the
code and triaging the bugs for 0.9.4.  Just please try to be
conservative and merge the code that has been tested in the trunk
already.  We could make a release three weeks from now.

If there is any need to make a security release, the 0.9.4 branch is
more suitable for that than the plain 0.9.4 release.  At least it would
support Linux 2.6.26.  If the circumstances dictate it, we should be
able to release 0.9.4.1 quickly.  However, I think we need to do more
work if we don't have a reason to release right now.

-- 
Regards,
Pavel Roskin

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/