Here is my input for madwifi status on kamikaze:

I am using kamikaze trunk 6303 for couple of broadcom BCM4710 boxes since that is the latest functional kamikaze for those devices, you may check ticket #3141 and this thread, and syncing to the latest openwrt madwifi trunk on the package directory.

The result is that the openwrt madwifi trunk is unable to get proper scan results or associate to the remote AP.  Latest trunk from madwifi works like a charm.

it would be nice, easier and more beneficial to merge the important openwrt madwifi patches to the main madwifi tree and just stick to the latest madwifi trunk since maintaining an openwrt madwifi branch is quite a task while stays out of sync from the latest madwifi development --> madwifi is at trunk 3595 while openwrt madwifi is at madwifi trunk 3394

the latest broadcom #6303 branch that I maintain is here

my 0.00000001 euros

(Last edited by acoul on 5 May 2008, 09:46)

I created a ticket (https://dev.openwrt.org/ticket/3394) but there is no reponse.

Personally I also don't like the OpenWrt MadWifi version. It's to havily patched

trying to compile madwifi trunk 3603 for rb532 I bumped into this bug.  I guess this may be a good reason that openwrt madwifi branch is still @ 3314 madwifi trunk.

(Last edited by acoul on 6 May 2008, 12:09)

ok, here is some more feedback on madwifi & openwrt status on kamikaze trunk 6303 for broadcom BCM4710.  today I switched from madwifi trunk 3595 back to openwrt madwifi 11054 trunk.  The link, a 10km outdoor link @5.62GHz using a cm9 and 28dbi grid antennas, was able to associate with the same level of signal strength.  The noise level indication was higher but the link was working much better and the openwrt madwifi drivers do seem to use less CPU.  The problem that remains with openwrt madwifi branch is that they do not produce scan results.

here you may find latency and bandwidth statistics for this link.

(Last edited by acoul on 6 May 2008, 12:22)