Need help with flaky performance

Yes. It helps keep me out of trouble. But it's an awfully large file. Mine is currently 350k, but the most recent version is over 500k.

Yes, but it would be a whole bunch of entries.

Thanks for the confession. :-) As I understand it, the Buffalos are more complicated to flash because the firmware images are supposed to be encrypted. So you can't use the built-in stock flashing option to flash DD-WRT (because it's expecting an encrypted file). And for the same reason, you can't use the built-in DD-WRT flashing option - assuming there is one - to re-flash the stock firmware (because its expecting a non-encrypted file). Hence the need for TPTF, as you say, both ways.

Well, I knew I hadn't imagined all those "brick" reports. There appear to be more of them for Buffalos than for Linksys, and since there are probably far fewer of the former in the population, the difference is even more striking. I've seen somewhere a report that the Buffalo people are seeing too many bricked routers come back from attempted DD-WRT flashings. Well, that's their own fault if you ask me - all that silly encryption. You know, the Buffalo firmware source is available from their site. I guess that's because they use Linux and other open-source components, and have to make it available. But then, why the encryption?

But at this point I have a wired desktop and a wireless laptop, and both can get to the internet, and both can see and sync with each other, all with the stock firmware. So long as that works well, and so long as I don't need VPN or something equally fancy, I'll probably stick with the stock firmware.

It would be nice, though, if someone could break the Buffalo encryption. That should make the flashing a lot more reliable, because then you could make an encrypted version of DD-WRT, and an unencrypted version of the stock. Then all the critical timing issues go away.

Reply to
Peabody
Loading thread data ...

I hate to tell you this, but there are a number of threads on the DD-WRT forum asking the musical question, "Is QOS broken?" or something similar. And not just on Buffalos. You might want to take a look. Apparently a number of people are having problems with QOS.

Particularly if one or more of your eight users is doing file sharing? Maybe so.

Reply to
Peabody

Ahem... Please use SP2, not SP1. See:

V23 SP3 is being worked on,

but I had some stupid problem (forgot what it was) when I tried it, so I went back to SP2. Watch out for the order and sequence of the dates as it follows the European pattern of day-month-year instead of the weird US pattern of month-day-year.

Remind me to add it to the DD-WRT wiki. I keep forgetting.

Sheesh. OK, 4 seconds.

Agreed. I learned to make all my mistakes on the first few WRT54G and GS routers. I think I manged to create a brick about 5 times. I also rescued a few for friends about 4 times. In the early versions, it was very easy to do. When the firmware upload was finished. The display would claim that it was done and to hit the "continue" button. The problem was that if you actually did that immediately after the button appeared, you were guaranteed to have a bricked router when done. Eventually, I learned that it was still doing something internally and to wait a while. I'm sure 1 minute would have been enough, but the rumor mill super-sized it until the official delay time was about 5 minutes. So, I waited 5 minutes and everything was just fine. I suspect that many of the older reports of failures were due to this problem. The new reports seem to be due to user uploading the wrong version or flavour of firmware. That's all too easy to do as the download site organization is really, really, really awful. However, I would prefer Brainslayer work on code instead of organization and don't feel like complaining.

Incidentally, I have about 12 assorted DD-WRT installations (mostly coffee shops), 3 OpenWRT installations, and know of about an equal number used by the local free wireless horde. Except for one hacker infested coffee shop frequented by the local university students, everything is quite stable and functional. However, I have no idea how well these work with P2P file sharing as most don't use or allow it.

Also, I don't think the Buffalo firmware is really encrypted. I think (not sure) that it's just compressed to make the firmware uploads go faster. There's some type of simplistic decompression code in the protected area of the flash NVRAM for TFTP uploads. It shouldn't be a problem reverting DD-WRT to the stock firmware using TFTP. However, I wouldn't try it using the web page firmware update from DD-WRT.

Reply to
Jeff Liebermann

There is not SP2 version of v24 yet. I think you mean V23 SP2.

Sorry. I don't know.

The aformentioned web pages were strictly to show the *AVAILABLE* settings and do not necessarily reflect the correct settings. The default for automatic reboots should be off or users would surely claim their routers were rebooting "spontaneously" once a day.

Good questions, but I don't have any answers without looking at the source code. To preserve time and my sanity, I'll graciously decline to do this, and suggest you ask those that know in the DD-WRT forums.

Reply to
Jeff Liebermann

Everyone has problems with QoS. That's because there's no single optimum setup. Every system and user has different usage patterns which will affect QoS setup. It also depends on what you're trying to prioritize. You can optimize by application, by IP address, or by reserved bandwidth. It doesn't help that different P2P BitTorrent mutations use different protocols and ports. See:

for clues.

Hint: Every time you turn on a service, feature, filter, or protocol on a small router, it eats RAM and CPU cycles.

This is my office WRT54G v3 with DD-WRT v23 SP2. I'll run the Buffalo numbers when I have a chance. Compare the buffers (and others) with yours and see if turning things on and off has an effect. You can also see the numbers at:

# cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 14516224 13619200 897024 0 1650688 4321280 Swap: 0 0 0 MemTotal: 14176 kB MemFree: 876 kB MemShared: 0 kB Buffers: 1612 kB Cached: 4220 kB SwapCached: 0 kB Active: 3956 kB Inactive: 1908 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 14176 kB LowFree: 876 kB SwapTotal: 0 kB SwapFree: 0 kB

Incidentally... # uptime 21:05:15 up 47 days, 5:37, load average: 1.05, 1.07, 1.02

Reply to
Jeff Liebermann

Well, just like peabody, my problem has disappeared. I turned of QOS and set it to reboot daily at 4am. Not scientific to change two things, but there you are, it's better. If I'm following what you are saying, I figure it leaves more overhead and cleans it out the buffers. Seems that most computers like a good reboot every so often.

Steve

Reply to
seaweedsteve

I too was concerned about TFTP flashing the Buffalos. I'm over it. I have now done two, a regular and an HP. Both were easy. I've just did a linksys v2.2 yesterday also. That was just a tad easier, but not much. I think that the Linksys later versions, that require a prep file etc are truly the hardest and I imagine cause the most trouble. The Buffalo is easy!!

As far as hearing about more bricked Buffalos. I think that it's just that it's rare enough that there is no tutorial on debricking like with the linksys. And Jeff is not saying that he's had more on the Buffalo either. I believe what everyone says, just don't rush the reboot and you are fine. To me, NOT doing something is easy. I would be more worried if they were getting bricked due to a typo or timing problem in TFTP.

As far as TFTP, it is a breeze. I opened command, found my directory (C:) for the bin file and then pasted the exact command line into the window from the DD-WRT wiki, adjusting the file name.

At this point, I had read enough to know there was a delay, so I plugged in the router, waited for the indication (flashing LAN ports to stop, IIRC) and hit enter.

On the first one, I got the timing wrong and it was not a problem, just tried again a couple times until it caught it. On the second router (HP) I got it right the first time. It tells you. At that point, with any of these, including the easier of the Linksys you just need to wait. Go get a snack, then come back and reboot as instructed.

Once you have DD-WRT you will appreciate the increased stability, control and monitoring. Sooner or later.

Steve

Reply to
seaweedsteve

On 7 Feb 2007 10:02:27 -0800, "seaweedsteve" wrote in :

If so, then the code is badly written.

Reply to
John Navas

If you have time, would you mind looking at this site:

formatting link
It looks like it may be a free-for-personal-use commercial network analysis program. It also appears to have a substitute "promiscuous" driver that specifically supports my wireless client (Atheros AR5005G):

formatting link
And it runs on Windows. Actually, reading through the PDFs, it looks like it might provide more information than is particularly useful, but it might be helpful to run now and then.

Reply to
Peabody

Peabody hath wroth:

Yep, you found it. Nice research. The WildPackets driver for Windoze does support promiscuous mode.

There's also:

which is a driver built around a USB wi-fi radio.

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.