Some more observations:

1) Just in case anyone who is looking at my NVRAM contents is wondering, no, I'm not insane; boot_wait is set to off not because I want it that way, but because PMON in this unit automatically changes it BACK every time I set it to on.  Yes, it is VERY annoying.  I probably won't be able to do anything about it until I get a JTAG header soldered on or something and can put on a bootloader that won't do that.

2) Just to bring this slightly back on-topic, I ran some more experiments today.  I wondered if what was causing my particular unit to crash was the binary driver for the Prism card.  So I removed it and ran just with Ethernet connectivity.  Then I set up a local computer on my network with Apache and a CGI script that piped out data from /dev/urandom and then used wget on the WRT54AG to stream this data and output it to /dev/null; that way I could have a constant stream of random whatever being sent to the WRT54AG.  Even only doing this, with no wireless being used at all, the unit managed to crash several minutes later.  It doesn't seem to be the wireless driver.  And as I pointed out in the other thread, I've already ruled out the ethernet driver by trying out three different revisions of it (one of which was supposedly the fix to the problem).  Others have already reported that the various gcc 3.4 builds of experimental haven't fixed the problem for them, either.

I'm about to tear my hair out!  I was going to put the "old" official Linksys firmware back on, but I put it off hoping that someone would stumble upon the answer, but it doesn't look like that has happened yet and I certainly haven't gotten any closer to the answer myself, so I will most likely try 1.07 out again in the next day or two.  Linksys has, unfortunately, still been eearily silent about my requests to have them release the sources to 1.08 or even just a binary.  Grrr.

-- Nathan

TX is no problem, but only RX:

On my WL-500G I have same problems, like NathanA. I have done some tests with netio (freshmeat.net/projects/netio/) and found out that the box only crashes when revieving data blocks larger then 1KB, TX is no problem and works with about 2Mbit/s stable.

This problem not only appear with th propritary et (in any version), but also when I'm using the open source driver b44. So I think the "large file transfer reboot bug" problem on WL-500g (BCM4710 125MHz ...) is not the driver, but may by an buffer overflow in an other part of the kernel network implementation ( ip layer?).

fwiw, clkfreq=216 does not work on my older wrt54g v2.0.  its too fast for the device.  it was still salvagable either as described here using boot_wait and another firmware as well as just holding the reset button to restore minimal defaults into nvram.

gps, I think that the 216MHz clock rate was only ever meant to help out with v2.2 and above devices...

As far as my WRT54AG saga goes, get this: I rolled back to the official Linksys firmware for my device (much to my chagrin...I still only have the very b0rken v1.07 in my possession...it sucks), and it is SOLID AS A ROCK stable.  I've been sitting here now for over 30 minutes, conducting the same constant speedtest that I used previously to repeatedly and demonstratably crash OpenWRT as well as listening to a 128kbit/s MP3 stream at the same time, and nary a hiccup can be observed.  With OpenWRT, I was never able to get more than 5 minutes out of it without it giving up its lunch.

So there is SOMETHING about OpenWRT that does not agree with this piece of hardware.  I'm guessing it's an issue with the kernel or with the compiler used to build the kernel.  Perhaps I'll try to "backport" the Linksys kernel to the latest OpenWRT snapshot and see what happens...

-- Nathan

Don't suppose anyone has managed to solve this for the WRT54g v1.1? Mine reboots after a few hundred meg of data is transferred over the wifi interface and needs to be power-cycled to use wifi again. Tried overclocking to 150mhz but that just made it worse.

Everything was fine on the old build of openwrt I was using! Very tempted to go back to it or at least the latest non-experimental build I can find.

The same problem exists on ASUS 500g (125 MHz).
Original ASUS firmware works fine.
It is the only obstruction why (otherwise perfect) OpenWRT is unusable on the device :(

Hm... I think it's really stupid to sell routers that cannot transfer large files over the network

What router dont have this behavior? Which device should I buy when I want a stable thing?

Are there any routers that can run OpenWRT really stable?

Going off topic slightly, are all the Asus routers 125mhz or are newer ones 200mhz?

This is not the fault of the hardware, it is openwrt experimental.  Old "stable" versions of OpenWRT (the ones with the 2.4.20 kernel) and the linksys supplied firmware both work flawlessly on my g v2.0 and gs v1.0.

It's not the fault of openwrt. It's the fault of the new ethernet/switch driver which has been integrated into experimental. The reason this driver is used, is because it supports both V2.0 and V2.2 hardware.

hahaha.  I can't be the only one who finds that statement amusing.