WRT54GL impossible AA fw & Backfire problems.

[y_not]

Hello forum members.
1st time posting here, so I'll briefly introduce myself.
IT guy & uber nerd by trade, been in the business.. approaching 20 yrs now. I have been happily setting up routers /w OpenWRT for going on 5yrs now and I LOVE IT!! Stock FW is *barf*.

I'll say upfront, I know a fair amount about Linux, but it's not my strong point, only from a lack of dedicating myself to it more. So I'm by no means a Linux expert and I'm not a programmer, but I can manipulate existing code and hack together some things when I have to.

So with that said, I'll get down to business.
I'll say, this post is a bit long, but it's not a book or anything. I'm really detailing 2 separate, but related things with some background at the start.

I have an WRT54GL v1.1 router that was running WhiteRussian for about 2/2.5yrs. Quite happily I might add. Until, one day, it just wouldn't communicate on the WAN port anymore. The rest of it was fine, SSH BusyBox worked, don't recall if the X-WRT GUI did, pretty sure it was fine. I backed it all up, then wiped it back to factory Linksys FW. Worked just fine. Wiped NVRAM from term. before the switch.
Tried CoovaAP 2.x beta.. actually more like alpha, HAHA. Big FAIL!! Slow, nearly unusable and in general I became extremely frustrated with the lack of community support, documentation and a major glaring bug preventing a functional Captive Portal. So I scrapped it.
Did a TFTP of the latest Gargoyle v1.5.7 Attitude Adjustment.
WOW!! Another HUGE FAIL!!!
Took it about 3min to boot to the point it'd respond to pings, intermittently, the WAN light to stop blinking and the SES light to come on. Then it'd take at least another 2-3 minutes before I could even load the GUI. It wasn't quite this bad @ 1st login, but as soon as I set the root PW and rebooted, it went down the tubes. Quite often it wouldn't even boot all the way, sometimes no ping, sometimes ping, but no GUI. SSH I didn't consistently try. When I did get into the GUI, it was an absolute CRAWL!! Unusable.
Even tried 30-30-30 reset, no go, then back to factory FW which boots in about 20sec. Then TFTPd in AA ver. once more and still, same result.

It's possible the router is bonkers, I haven't ruled that out yet. I'd need to test it on factory FW, or find a functioning WR .trx/.bin image, as X-WRT went bye-bye... at least as of now there are no functioning builds at their new GoogleCode home. I suppose I could restore the image backups I made, but something tells me they'll still have a dead WAN iface.
I'd test Garg out on my other, identical router, but it's my production router. I don't want to do that. Bad, bad!! LOL

BTW, on WhiteRussian it booted in less than 20sec, at least as fast as factory, if not actually faster.

So I TFTPd the latest stable release from the Backfire builds.
This was muuuuch better. Still takes about 1.5min before I get GUI access, but that's not the end of the universe or anything, so long as it works right. GUI's fast, internet seems faster than WR, but no formal testing, just "feel". Using less ram than AA & WR IIRC.
Here's where the problems come in, I downloaded, using BT, the latest Quantal-Quetzal 12.10 i386 LUBUNTU release. No other torrents were running, it took about 15min to download on my 12Mb DSL conn. Total active torrent time, about 20min. I shut down uTorrent then went over to the Win7 lappy that I was going to be tossing it on. WiFi now disconnected, it sees the network SSID, just fails to connect, quite quickly I might add. Tried my Android phone too, no go.
So I did an IF UP/DOWN for wifi0 using the command "wifi" from the shell. This solved it.

Well, later on that same day, I found after doing another torrent, different distro, no other torrents running. That the internet connection went down about 90% in, modem still up. BTW, It's in PPoE bridged mode, the only way to fly. So the modem is just a TA "Terminal Adapter".
Couldn't DNS resolve, let alone ping out to WAN/Inet. After about a minute or so, it came back online. This whole time the router wasn't responding to pings and I couldn't access it even when it was. I don't believe it rebooted, as it takes it much longer than that to do so. But i didn't go into the wire closet to check it.

I have known about the stability bug in the Broadcom open source b43 driver running on the bcm47xx (kernel 2.6) platform for a while. Where in it will cause a lock-up situation due to a ring-buffer overflow, a fix has been slow to progress as it has been rather difficult to track down the bug. Well, it looks like much progress has been made, at least it has been partially fixed as of the beginning of this week and has been sent upstream of the latest AA & BF OpenWRT builds.
They still have some memory DMA management to build in, but the main issue is fixed, at the expense of about 512K memory increase. Which is a fair trade off for the time being until the memory issues are resolved further down the road.

Obviously this wasn't an issue in WR because it used the older 2.4.x kernel /w the proprietary Broadcom driver.

Here are the relevant links.
Upstream b43 Driver Patch
Bug Ticket Tracker Thread - Status: Closed/Fixed
Rather Extensive Discussion With Gory Details on Code, Debugging, etc..


Do understand that I'm testing this in the exact same environment, on the exact same connection /w the exact same equipment as I have been running my WR router @ the shop for years. Wherein I have had ZERO issues with lock-ups, stability, performance bottlenecks, etc... I can totally hose my connection for hours on end /w torrents and it runs just peachy fine. VPNs are great, RDP, LMI, TOR, whatever. It all works fine on WR on this network.

I really want to like Garg, I want to stay with it, this being my 1st foray into Garg. Another massively glaring problem is it behaves like a pesky Netgear box.... *shudders*. In that every time you change anything, even sneeze at it, it has to reboot itself. Something so simple as changing the encryption key for the WiFi interface and it has to reboot. Seeing as I can SSH into it, edit '/etc/config/wireless' and change it there, very swiftly and easily /w VI, save, then issue the 'wifi' command to bring down the iface and bring it back up, taking all of 30sec, tops and all without a full system reboot. It just seems SILLY! for Garg to reboot it every time you change even something minor. Is this a problem /w Backfire? I have yet to run a vanilla build of BF on a router. All my WR routers have been working so beautifully that I have just let them be.

To recap, my questions are as follows.
1. Can the upstream fix for the b43 proprietary driver be brought in from the aforementioned link? Is this something that can be done without re-compiling the whole she-bang? It's a whoppin' 1 line change of a 2 digit number to a 3 digit number. IE. Can't just edit it into the existing build? I couldn't find it anywhere in the JFFS, so I suspect not, unless I'm missing it's location. Which is highly possible.

2. Do you have any 2.6x builds /w the proprietary BRCM driver? As apparently that's possible, according to an entry in this FAQ. Reference URL linked 2nd.
2.6 Kernel /w Proprietary Broadcom Drivers
Thread Referencing Source of Edit

3. Why won't AA run on this router? It uses about as much memory as WR, which is more than BF. CPU usage is much lower than WR, as far as I can tell. I know it's an old, slow, pokey router by today's standards. But not really and besides, it works fantastically for some pretty high load environments. So long as one is using OpenWRT WR.

Sorry for the long post, but I felt all, or most of that information was necessary to make an informed assessment and thus a direction to go in. Whichever of #1/#2 will fix this glaring BRCM issue would be super!!

Thanks everyone.

[pbix]

First, I must confess that I did not read a lick of your post other than the questions. I will do my best to answer what you asked but please be brief and concise for the benefit of the rest of us.

1) This is really a mute point because you cannot run any version of Gargoyle later than v1.5.6 on your router. It simply does not have enough RAM. Please load Gargoyle v1.5.6 on your router if you want to try our project out. V1.5.6 is based on Backfire and can work although it can be tight at times. Hopefully you know how to load firmware at boot time using TFTP because this is often the only way that works due to limit RAM. The other thing to do is go back to Gargoyle v1.4.7, that version is preferred by some for your router. 30/30/30 resets is DDWRT speak, we do not do that. We have failsafe mode which you should read about over at Openwrt.org. You may be able to run a stripped down version of AA on your router and patch it with the trunk patch you identified.

2) Gargoyle is open source and you can download sources for v1.5.6 and then rebuild them using the proprietary driver yourself. I cannot say what effects that might have because it is not a tested configuration. I suggest that is you want to try this you start with OpenWRT and do the same thing with the last Backfire release. Once you get that working your can download the Gargoyle v1.5.6 sources and try that.

3) AA is simply requiring more RAM to run than Backfire did. And Backfire required more than Kamakazi before it. It is well know fact written about often in this forum that you cannot run AA versions of Gargoyle with only 16MB of RAM.

My best advice to you is to spend $40 and get a modern router with sufficient RAM and FLASH to make your life better. The time of the WRT54G series has past.

[y_not]

I'm sorry you didn't have time to read my post. However, I know full well that if I didn't take the time to put it there, someone would invariably come along, saying: "why didn't you say so?", or: "you didn't give enough info for us to help you."
I have been around the block enough to know that.

Yeah, forget all that noise. I'll just load the latest Backfire brcm2.4 build from the OpenWRT official builds, then load your modules from the Garg repo.
However, I did see it noted, by you in one of your posts, that anything past v1.3.9 requires kernel v2.6.
Do you mean your FW builds, or even the packages themselves? IE. Kernel functions in some or many/all of your modules are used that v2.4 does not contain?
I'm confused, so which be it masta'?
Thanks.

BTW. No cheapo' here, just keeping still useful HW alive. Recycling is a joke & landfills are such a waste. Better to be placed in the hands of poor friends that need better kit than what they have.
It's not like this is an external servo, 5-1/4" Seagate 80MB drive. HAHA

MicroTik router boards, Ubiquity radios & possibly Ruckus are in my near future. Can't WAIT!! Kinda scared too. LOL

[pbix]

I do not use Gargoyle packages on top of Openwrt. I only build, test and use the binaries on this site. So I cannot help you with any questions about questions about loading packages on OpenWRT.

V1.3.9 Gargoyle uses the proprietary wireless driver you are looking for as you noted. If that is your main goal then just download that Gargoyle binary from this site and install it onto your router.

I myself have several WRT routers but have not used the proprietary driver in many years. I found the opensource one good for my needs.

[y_not]

Yes, I have been reading posts.. had to use Google to search, since the site is oddly coded to ignore key words it deems "common". Thus making it worthless for finding anything specifically related to Broadcom or Linksys or WRT54GL, etc..

In your posts, you do repeatedly say that your WRT54GL running the b43 driver works just fine. However, you did state in one post that you only have a 3Mb/ish conn.
That'd be exactly why yours works just fine, as this is not even remotely a load test of high bandwidth connections. Neither is my 12Mb connection compared to some parts of the country, but it's 4x the number of pps as yours. Thus it makes it poop out on WiFi.
So I don't really see it as a "very good test" of the stability of the driver, in fact it's not a test at all. It just shows that in rural broadband connections that the router can handle it just peachy keen. IE. Under low bandwidth conditions where it doesn't tax the buffer, causing an overflow and thus crashing the driver or causing a hang condition.

Not to say it doesn't work for your needs and what the bandwidth gods have graced you with, which is great. Your lucky to have access to something other than dial-up or *shudders* satellite. Many don't, I have heard numbers as consistently high as around 40-48% of the nation is still dial-up only.

I'm betting if you setup a computer on the wan interface, static to static. Or maybe a NAS /w a DHCP server, or even a PC running one. Then transferred GB's of information to a PC on the LAN side, you'd see it take a dump on you.

I know this router will go up to about 20Mb on the WAN side and do just fine /w the proprietary driver.
So yeah, what I'm going to do is go back to an older Garg that uses the brcm-2.4 driver. Go torture it to be sure it's fine. Then I'll look at how I can compile the ring buffer modified b43 driver, info I linked above, from upstream trunk.

I'm assuming I'll have to go over to the OpenWRT forums and ask that, that is unless someone here knows how. If you do, I'm all ears!! Or, circuits.
I don't want to re-compile the whole stinkin' FW, just the driver. I know drivers can be compiled into the monolithic kernel, or loaded as modules, either way. Which method OpenWRT Backfire uses, I don't know. I'm hoping I can just patch the module, then replace the one in the kernel v2.6 based Gargoyle builds and load that instead. Problem solved!! Maybe wishful thinking on my part... but I can dream.

[pbix]

You will have difficulty exceeding 10Mbps through the WAN port of the WRT54GL and this has nothing to do with your wireless driver. Perhaps other firmwares can go faster but this is pretty much the limit for OpenWRT.

Keep an eye on your CPU utilization. When it hits 100% many problems and invalid measurements will result.

[y_not]

On OpenWRT, she does 12Mb+ beautifully /w both: DSL via PPPoE on router, modem in bridged mode, as well as on cable inet. /w bursts well into the 15-16Mb range. I found a forum post that says it (running OpenWRT Backfire) does 20Mb, but 24Mb is only doable if you oc' the CPU to 200MHz < 250MHz.
In fact, 250MHz is in the design spec for the BCM3302 CPU. As listed in its datasheet. So it's technically 100% safe for GL models. Older ones, not necessarily.

Toastman over on the Tomato forums, he's a dev and has his own build, is running one in an apartment complex with 200/240+ users on a 16Mb conn /w QOS rules of course. No problems there. He runs his OC'd, many in enclosures and outdoors in direct sunlight in a very warm climate. 100's of them in svc this way, with no issues.
But clearly, as noted above by my own experiences, at stock it'll run 16Mb just peachy.

Yeah, I agree, heat is your enemy as well as 24/7 max load = BAAADDD JUJU!! LOL

This model still has a lot more juice than people give it credit. It doesn't take much CPU power to run a bunch of WiFi conn. and decently fast DSL/Cable conn. It's pretty trivial for a CPU even this old.
Who knows, the CPU may likely be able to handle a 40Mb conn. Some have theorized this based on WAN>LAN tests using a std. TCP load.
I have never tried it, but I wouldn't much see the point, unless you weren't using the WiFi interface and only needed it as a wired router for routing chores. Because you'd be crippled by the max 24Mb real world throughput of 802.11g.

Needless to say, I'll be testing it anyway, before long.