Here's a few common mistakes that people keep repeating. If you see anyone making any of these mistakes please point them at this topic -- I'll try to keep this updated with all the common mistakes.

NOTE: Please read the FAQ for additional Q&A.

#1 STUPID:
"How can I increase the transmit power to extend my range?"

The transmit power on the AP isn't the problem. Increasing the transmit power will give you a stronger signal on the client and make you think you have extra range, but the client itself is still transmitting with the same power, limiting the effective range. Additionally, turning up the transmit power increases the background noise and your signal starts to bleed into the neighbouring channels, decreasing the range and throughput of any other APs in the area. Your best solution is to get a better set of antennas. (see also FAQ)

#2 WRONG:
"You need to convert the bin (eg. openwrt-wrt54g-squashfs.bin) file to a trx file before reflashing"

The openwrt-brcm-squashfs.trx is a generic trx file that will work on any supported broadcom platform. The openwrt-wrt54g-squashfs.bin is just "bin header + openwrt-brcm-squashfs.trx', the bin header just contains the firmware version number and what models the firmware can be loaded on; the bin header is only used for verification before writing the trx data to the flash. The mtd utility writes the given file to flash without verifying it; use one of the openwrt-brcm-squashfs.trx when using mtd. Converting the openwrt-wrt54g-squashfs.bin file back to a trx is just plain ignorant.

#3 WRONG:
"I've setup port forwarding but it doesn't appear to be working"

The port forwarding examples make use of the "-i $WAN", and as noted in the "BIG FAT DISCLAIMER" immediately above the examples, it will only redirect packets that came in the WAN interface, you will not be able to use the redirect from the LAN -- I'll repeat -- don't try to use the redirect from the LAN interface, it will not work from the LAN interface. If you tried to redirect port 80 to 192.168.1.2 without using "-i $WAN" even accessing google.com would be redirected to 192.168.1.2 instead. The alternative to using "-i $WAN" is to use "-d x.x.x.x" and specify the IP address of the WAN interface, unfortunately this requires you to restart the firewall each time the IP address changes and doesn't lend itself well to dhcp or ppp connections where the IP address might change.

#4 STUPID:
"I've set no_root_swap on my squashfs image and now the root partition is readonly"

Obviously. Squashfs is a readonly filesystem. For writable support, OpenWrt creates a jffs2 partition and on bootup swaps to the jffs2 root. The no_root_swap variable prevents OpenWrt from swapping filesystems and you remain on the readonly squashfs partition.

#5 BUG:
"I'm using the squashfs image and it keeps running firstboot every time I reboot"

This is an actual bug; see https://dev.openwrt.org/ticket/97 if you run into this problem.
(fixed in the rc5 release)

The following applies mostly to squashfs users -

#6 WRONG:
"You can save space by deleting packages that came with the (squashfs) firmware"

Squashfs is a readonly filesystem. The packages that came with the squashfs firmware are embeded into the squashfs filesystem and nothing short of reflashing will remove them. The ipkg util will pretend to delete the packages, but really all that's doing is deleting symlinks from jffs2 to squashfs; almost no space is recovered by this. If you don't want all the packages that come with the default install, consider using the "micro" version -- it's the exact same firmware, just with less installed by default.

#7 WRONG:
"You can use 'ipkg upgrade' to upgrade to the latest firmware"

No. If you're using the squashfs firmware, running ipkg upgrade is likely to kill any free space you have left; there will be a copy of the original package on squashfs and a copy of the updated package on jffs2 -- see above. Even if you're running the jffs2 firmware, the ipkg command won't update the kernel -- the kernel itself isn't a package, it's stored directly on the flash immediately followed by the filesystem. This makes it nearly impossible to update the kernel without nuking the filesystem in the process. (Note, there is a kernel package, but it doesn't actually contain the kernel, it's a "meta package" so that ipkg will only install the modules written for that kernel)

http://forum.openwrt.org/viewtopic.php?pid=42572#p42572

#8 STUPID:
"I've reset the nvram to defaults using the mtd command, now my router is all screwed up"

The mtd command will simply erase NVRAM. It will not reset it to defaults. It's up to CFE (the bootloader) to detect that NVRAM is missing and setup some NVRAM variables. As it turns out, most devices are incapable of this, and erasing NVRAM breaks the router until the variables are somehow reset -- in some cases requiring a serial cable.

#9 WRONG:
"I've shorted the pins to get into failsafe, but I don't get any telnet response"

Somehow people have fallen for the myth that shorting the pins on the flash is some magic way to fix any error, or that shorting the pins will somehow force the router into failsafe mode. Wrong; this has absolutely nothing to do with failsafe -- If you want to get into failsafe press the reset button at bootup, instructions are on the troubleshooting page. Shorting the pins is an old trick that was once used to force the device to tftp -- on bootup CFE would do a CRC check of the firmware, shorting the pins of the flash caused an error and the CRC check would fail, causing CFE to wait for a new firmware. This trick was removed from the troubleshooting page after numerous people destroyed their flash chip by doing this incorrectly. It also turns out that you can send a new firmware via tftp even if the device doesn't have the boot_wait variable set -- it's just slightly harder.

#10 STUPID
"I tried to overclock my router..."

Almost every day I hear the story of someone that's been told overclocking will fix stability issues, and so they played with the clkfreq variable and broke things. While it's true that overclocking to 216Mhz can fix some issues, overclocking to any other setting (even less than 216) will result in a broken router -- you'll need a JTAG cable to fix it. See this thread, which was already added to the RC4 release.

#11 CHANGE:
"Why can't I use WPA in client mode on RC4?"

nvram set wl0_mode=wet

#12 STUPID:
"Can I ask a (dumb) question?"

Yes, infact you just did. Try asking questions that have more meaningful answers.

#13 STUPID:
"I'm having a problem with my router, can anyone help?"

Sure, you just .. WAIT! I don't even know what the hell the problem is yet, how am I supposed to know if I can help?

#14 STUPID
The boot_wait / failsafe confusion

There's so many examples of this that I really don't know where to start. When the router is first powered on, it doesn't boot the firmware, instead it boots into what's commonly refered to as a bootloader, a small program responsible for validating and loading the firmware. When the variable boot_wait is set you'll have a chance to tftp a new firmware before the device boots.

Once the device boots into OpenWrt, one of the first things it will do is turn on the DMZ led; this is to signal that OpenWrt is booting. OpenWrt can boot two ways, it can boot normally, using the existing configuration in nvram, or it can boot in what we call "failsafe mode". Failsafe mode mode is something unique to OpenWrt, it won't reset your configuration or reflash the firmware, instead what it does is ignores a number of variables and startup scripts in an attempt to force the device to boot to the point that the configuration can be fixed. Failsafe mode must be activated within a few seconds of OpenWrt booting, which means that you should trigger it as soon as you see the DMZ led. For more information see the troubleshooting page.

#15 STUPID
"My settings are wrong, I should reflash to fix them"

Most of the configuration values are stored in NVRAM; flashing only replaces the kernel and filesystem. While reflashing will reload your filesystem, it will not do anything with NVRAM, and hence will not fix any configuration problems.

The solution? You need to understand how the configuration system works, and verify your settings manually. Don't believe anyone that offers any magic fix; chances are they have no idea what they're talking about and following their advice may only cause you more problems. Make sure you understand what a command does before you try it.

#16
"After installing OpenWrt my WPA nolonger works"

WPA support requires a extra utilies, not included with OpenWrt by default. Install either the "nas" package (broadcom proprietary) or "wpa_supplicant" (opensource, can be very difficult to setup). If you were previously using WPA with another firmware it will probably work automatically after installing nas (and restarting).

(Last edited by mbm on 16 Jan 2006, 03:51)

#17 STUPID
"I'm having a problem with my router -- oh, and I'm not using OpenWrt"

It's rare that people actually admit it directly, there's usually a 20 questions period where you ask them what the problem is and you find out through the questions that the problem has absolutely nothing to do with OpenWrt. Please, don't waste our time with problems caused by other firmwares.

#18 WRONG
"The squashfs install is completely readonly; to install anything extra you need to use the jffs2 version"

False; all of the OpenWrt firmwares include a fully writable root filesystem that will remain intact across a power outage. The confusion is due to the fact that squashfs is a readonly filesystem; all OpenWrt firmwares also include a jffs2 partition -- the squashfs part of the filename refers only to the filesystem included in the firmware image; additional files or changes are stored on jffs2.

- The squashfs partition will always contain all of the files exactly as they came with the firmware; you cannot change these without reflashing. (see #6)
- The jffs2 partition contains only your changes to the filesystem; since squashfs still contains the original version, you can easily revert files back to their original state.

It is possible to remove the squashfs partition by installing the jffs2 version of the firmware, but this isn't recommended -- it uses more space and lacks the above failsafe features.