linux-kernel - Re: [madwifi-project] [RFC] Closing the project

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 14 Nov 2008 12:26:19 +1300 (NZDT)
From:	Derek Smithies <derek@...ranet.co.nz>
To:	Pavel Roskin <proski@....org>
cc:	"Luis R. Rodriguez" <mcgrof@...il.com>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	madwifi-project@...ts.madwifi-project.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [madwifi-project] [RFC] Closing the project

On Thu, 13 Nov 2008, Pavel Roskin wrote:
> On Thu, 2008-11-13 at 12:54 -0800, Luis R. Rodriguez wrote:
>> On Thu, Nov 13, 2008 at 12:48 PM, Pavel Roskin <proski@....org> wrote:

>>>> Just my advice: let MadWifi die already, stop wasting your time.
Good advise.

> Specifically for me - just three letters.  DFS.
Why are you worried about DFS?
There is only one feature that is important:
  Reliability. It has to work for months, without rebooting.

Consider a very reasonable use of madwifi - in a linux router. It has to
work reliably - without being rebooted by the user.
Consider an AP box that had madwifi in it. Every couple of days, the user
has to reboot it to get the box to work again. The user gets upset and 
returns the box. This is not a commercial product. Yes, the box did DFS, 
but it had to be rebooted regularly.
While the DFS is nice - it is not reliable.

Now - you have noticed the comments about SMP issues in this thread.
Do you know what that implies? There are races races races in the code.
There are contention issues. What is the only reliable fix for SMP?
complete redesign. Pull the code apart - and work out what each tasklet 
and interrupt does. Ensure there is no contention.

Have you noticed the long standing bugs in the bug tracker? Stuck beacon, 
ping ramping in adhoc. Do you know why these bugs are long standing?
Cause noone has the skill/ability/knowledge to fix them. ((Sure, there is 
a purported fix for ping ramping - but this fixes the symptom, not 
cause)). I have a fix for ping ramping - it required a complete redesign 
of the codebase. I can report it, and give you the code, but you cannot 
use it in madwifi cause it breaks wds, scanning, dfs, ap, sta modes.

The options are clear::
  a)Fix stabilise madwifi
or
  b)add features to mac80211

a is a lot of work in a short lived project
b is a lot of work in a project that is going to be around for years.

===================================
Sure, if we abandon development on madwifi - we are breaking our promise.

Given the current rate of development, we will not be able to provide a
stable reliable code base with DFS etc in the promised timescale. thus, if 
we continue developing madwifi, we will fail to meet objective, and end up
breaking our promise in the future.

Conclusion:: break the promise now, or later.

As an end user of madwifi, it is more reasonable to break the promise now.

I end up being forced to agree with Luis:
>>>> Just my advice: let MadWifi die already, stop wasting your time.

Derek.
-- 
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
Email: derek@...ranet.co.nz
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/