I've been using madwifi-driver 0.1_pre20050420 since well 20050420 and it works
well as long as I don't transfer data at maximum speed for more then 10 seconds.
After that the connection drops and keeps on dropping after a second or two of
This problem didn't exist with the previous version, so maybe a new snapshot is
a good idea?
Steps to Reproduce:
scp a large file (600mb for example) from a remote host. be sure to be able to
max out the wireless link (e.g. have a 100mbit backend that can supply 100mbit
Connection drops/reconnects/drops etc etc
Connection remains stable and the transfer of the file is possible without a
We did not write the software but rather are the packagers.
Please check with upstream.
Closing as UPSTREAM.
which is why i'm saying the current cvs snapshot package doesn't work properly
under load. We need to either go back one version, or go up one if possible.
This clearly goes under gentoo packaging.
Are you saying that this is fixed in upstream CVS?
I don't know. I do know that the current version has this problem and it should
be masked or similar. My proposal therefore is go back one version.
I don't know if it is fixed in the current CVS. But since nobody can even
confirm this issue ...
What card are you powering with madwifi?
It has already been explained in the mailing list (see the archive).
The result is that development in madwifi head cvs has stopped and
only moves on in madwifi-bsd. The old developers of madwifi-head are
not active in madwifi project (workin on bsd atheros driver version)
anymore and now we have chosen to take over the responsibility for that.
Furthermore, anyone who thinks he is able to contribute (coding,
documentation, howtos, bug reports) to madwifi is welcome.
I think it's update time.
I have a:
0000:02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg
NIC (rev 01)
which came with my IBM T42 thinkpad.
Please do this.
emerge unmerge madwifi-driver madwifi-tools
ACCEPT_KEYWORDS="~x86" emerge -v madwifi-bsd
Using madwifi-bsd should correct your problem.
We are currently working on updating madwifi*
I think this answer is sufficent enough to close this bug.