The Linksys BEFW11S4 Router
Note: these pages have not been updated in quite some time. I recently migrated them to my content management system. The BEFW11S4 is pretty much obsolete. Over the course of its lifespan, four versons of the router were released. You can find firmware for all versions on the Linksys Website. At the time of the migration of these pages the current version is 1.44 or 1.45 depending on the version of hardware. I do not know what these versions have added to the router. This page was created when 1.40.3 was the cutting edge version. The information is still probably useful to users of newer firmware and possibly even other router models. I’ve taken some time and tried to reconnect some of the older dead links.
- Linksys Knowledge Base
Also, you might want to check out the WRT54G as an alternative to the BEFW11S4. You can install Linux-based firmware such as DD-WRT, and extend it with hardware modifications like an SD card slot. With modified firmware, you can SSH into your router remotely, serve web pages, or even setup your own managed hotspot.
The LinkSys BEFW11S4
The LinkSys BEFW11S4 is a router/wireless gateway designed for home use on broadband connections. It has an 802.11b interface and a 4-port switch. The firmware includes features such as DHCP, port forwarding, filtering, static and dynamic routing, and logging.LinkSys has released a new firmware revision (1.39.2). This firmware includes new features such as Stateful Packet Inspection, Port Triggering, and MTU settings.
This is a collection of information I’ve found on the web and in the newsgroups about the BEFW11S4. A good place to look for information is alt.internet.wireless
If you have any information on thie BEFW11S4, or find any errors or omissions here, feel free to write me.
New Features in 1.40.3
I have not installed 1.40.2. I’m quite happy with 1.39.2. This info is all second hand.There are two versions of 1.40.3 floating around. One dated 12/4/2001 and one dated 11/30/2001. The earlier one is reportedly a beta version. However the “final version” supposedly breaks support for Orinoco Wavelan card. Many users are using the beta version.
1.40.3 basically fixes a few bugs, adds a few bugs (see above) and adds the ZoneAlarm support. As far as I know, the ZoneAlarm support is a gimmick. When active, it requires users to have ZoneAlarm Pro
installed on there PC before it allows them out onto the internet. This is good if you want to force all your users to be running ZoneAlarm. This is also good if you’re ZoneAlarm and want to sell lots of copies.
1.40.3 does NOT have support for uPnP yet, as far as I can tell. Usually features for the BEFW11S4 come several months after they get them working in the SR41′s. You can expect to not see uPnP for a while yet… but thats just my opinion.
Features in 1.39.2
I learned quite a bit of information on a BEFSR41 news site at http://www.hansenonline.net/Networking/LinksysNews.html by a Mr. Lars M. Hansen. The BEFSR41 is similar to the BEFW11S4 but without the wireless features. The description of the new features below is from this site. Thanks to Halfton on alt.internet.wireless for pointing this out. I originally mistook this information for BEFW11S4 info but it is not. The features are similar, but the firmware and firmware versions are not.
This sets the maximum packet size that can be sent over the router. The maximum value is 1492. A smaller MTU forces more packets to be sent. More packets means more acknowledgment messages, and more packet header information. So, setting a smaller MTU value basically increases network overhead. However, if you have a network with high packet losses, it might be better to have a lower MTU size. (Resending a lost smaller packet is not so bad as having to resend a larger one.)
You’ll want to make sure that your host has the same MTU size,
or smaller. If you try to send a packet with a larger MTU size than the router supports, the router should respond with
a ICMP ‘Fragmentation required – DF set’ message.1
This is bad, more network overhead, and your host is going to have to split up the packet anyway. A program that will let you tweak your PC network settings, such as MTU size is called DrTCP and can be found at DSLReports.com.
Update: This router setting inforces the outgoing connection’s MTU. Incoming (server) connections are not affected by this setting.1.5
This is pretty slick (in my opinion). Basically, its standard port forwarding with a twist. When the router detects an outgoing connection on a specific port range, it will set up an incoming port forwarding rule (temporarily) on the ports you specify.
The BEFSR41 news site mentioned earlier has a good example of this involving SMTP. Another example is IRC. When you connect to an IRC server, often the IRC server connects back on 113 for an Ident lookup. However, often your router blocks these requests from getting back to your PC. If you were to set up a port trigger on ports 6000-7000 (a wide swath of ports, yes, but IRC servers usually are within this range) to forward the incoming port range 113-113, then the router will pass Ident requests.
Update: SPI doesn’t seem to prevent port triggering from working, however, it seems like port forwarding doesn’t work well when you duplicate port ranges. See know issues section for more info.
Stateful Packet Inspection (SPI)
Basically this is a Good Thingâ„¢. However, according to our friends at the BEFSR41 news site, you cannot use SPI with port forwarding. Update: port triggering still seems to work with SPI enabled! Hopefully this will change in future firmware revisions. Basically, if you set up the router for any servers at all, you can’t use SPI.
SPI looks at each packet a little more in depth than just normal routing.2 It checks where the packet is going and where it is from and remembers this info for the future. If a packet comes to your door that has the right routing information, a normal NAT might just pass the packet on regardless. However, an SPI firewall might say, ‘Hey, wait a minute, this packet is from somewhere that I haven’t visited lately, its unsolicited, so I’m just going to ignore it.’
This has the effect of blocking unwanted bad stuff like trojan connection attempts and port scans. If a packet arrives that doesn’t match one of your outgoing connections, it is simply ignored.
New antenna settings were added for this release. A Mr. Dennis Rex has posted some information on alt.internet.wireless regarding this new setting.3 These new settings are:
- Default – apparently a ‘dipole’ setting. “Rabbit ears” is how Mr. Rex describes it. He suggests moving the antennas in small increments to find the optimal coverage.
- Left/Right – uses only one antenna port on the access point. Good for an external antenna, says Mr. Rex, or if you want to cut off half of the effective area. (Maybe to stop freeloading neighbors? hehe)
- Diversity Spread – should select the element with the strongest signal, however Mr. Rex had some issues getting it to lock in. He suggests that it might be good for a moving client.
Other Features and Changes
There are a few other features listed as improvements to the BEFSR41 firmware, which one might assume have been added to the BEFW11S4 firmware. However, a few other features and changes have been noted as well:
- The DHCP table now includes the ability to delete entries.
- The ‘Keep Alive’ and ‘Conenct on Demand’ options are now mutually exclusive.
Esoteric Wireless Options
Even in firmware previous to 1.39.2, there have been options under advanced/wireless that haven’t really been well explained. I did some research and here’s what I found. (Disclaimer: I may have all of this completely wrong.)
The beacon is kind of the 802.11 ‘heartbeat’. The beacon occurs at a known time interval. The beacon is used to synchronize timing, and inform clients of waiting data (see DTIM Interval). I don’t see a real reason to play with this.
This setting is useful for networks with many clients. With many clients, and a high network load,
there will be many more collisions.6 By lowering the RTS threshold, there may be fewer collisions, and performance should improve. Basically, with a faster RTS threshold, the system can recover from problems faster. RTS packets consume valuable bandwidth, however, so setting this value too low will limit performance.
If you find that your corrupted packets, or asymmetric packet reception (all send packets, for example) you may want to try lowering your fragmentation threshold. This will cause packets to be broken into smaller fragments. These small fragments, if corrupted, can be resent faster than a larger fragment. Fragmentation increases overhead, so you’ll want to keep this value as close to the maximum value of 2432 as possible.
A long preamble basically gives the decoder more time to process the preamble. All 802.11 devices support a long preamble. The short preamble is designed to improve efficiency (for example, for VoIP systems).
The difference between the two is in the Synchronization field. The long preamble is 128 bits, and the short is 56 bits.
100kbps in 10 sec. 500kbps in 10 sec. Trial Long Short Long Short 1 99.492 100.161 332.591 342.122 2 99.76 100.04 346.178 356.674 3 99.84 100.04 356.356 358.047 4 99.452 99.91 355.659 356.452 5 99.84 100 356.388 356.293 6 99.73 100.01 347.079 339.22 7 99.75 99.87 357.375 344.835 8 99.71 99.71 354.682 356.325 9 99.72 99.97 357.759 354.933 10 99.661 99.82 349.811 356.483 Average 99.6955 99.9531 351.387 352.1384 StdDev 0.13029 0.128938 7.86505 7.118965 95% Conf 0.08075 0.079915 4.87472 4.412297 Average - 99.6147 99.87318 346.513 347.7261 Average + 99.7762 100.033 356.262 356.5507 Improvement 0.26% 0.21%
I did the test twice, once with a 100kbps transfer and once with a 500kbps transfer. You’ll notice that the latter only came back with ~350kbps actual values. Hence, I’m calling the network “saturated” for the 500kbps test.
As you can see there seems to be a .2% improvement when using the short preamble. (And the crowd rejoiced…) With such a small improvement, I was wondering if the results were just due to chance. So I did a 95% confidence interval. For the 100kbps case, the intervals did not overlap, indicating that there might be an actual improvement. In fact, the intervals don’t overlap even at a 99% confidence level, so I’d say there is some sort of improvement here, however small. In the network saturation case (500kbps), the intervals do overlap, so no conclusion can be drawn really. Its possible that acutal performance could be the same for both long and short preambles.
DTIM has to do with power management. With every beacon comes a TIM (traffic indication map). Basically, a power-managed card wakes up and waits for a TIM. A TIM tells the client card that there’s data waiting for it at the access point. When there’s data waiting, the access point indicates this with at DTIM message.
A shorter DTIM will cause the card to wake up more often to download waiting data. A longer DTIM will keep the card in power-save mode longer, however, since more data will be waiting, the card will have to stay on longer to collect the waiting information.
- Cannot connect to internet after upgrade. This is one that I’ve experienced myself.
Apparently, this firmware upgrade doesn’t wipe the settings on the router. This might seem like a
good thing at first, but it can leave the settings in an inconsistent state. For example,
the new firmware has changed ‘Keep Alive’ and ‘Connect on Demand’ to mutually exclusive radio
buttons rather than check boxes. Also, their parameters have new ranges as well.
After installing the new firmware, do a hard reset on the router (the factory defaults
option on the password page works fine).
- Random hard resets and loss of settings. Some have complained that the router
resets settings randomly. I’ve found that turning on and off the logging function tends to
cause this problem. This has been apparently been experienced by others on alt.internet.wireless. I’ve found that other features can cause the settings to be lost as well, including changing the DMZ host, and the hidden logging features.
- Bad DMZ + Portscan = Reboot. I’ve noticed that a portscan will cause the router to reboot if you have a bad DMZ host specified in the DMZ settings. The “Dummy DMZ” is a known method for stealthing Linksys routers, but apparently doesn’t work due to this problem. This problem has been confirmed on the DSLReports discussion board as a problem thats been around for a while, not just in 1.39.2. I’ve found that even with a valid DMZ host, a portscan will sill hose the router. If you turn on the “daignostic logging” (see hidden features section), you can see log entries that say [HH:MM:SS] Free=xxx, where xxx is getting smaller and smaller until it resets. (Note: this happened with default filtering settings, no spi, block wan, etc)
- UDP Traffic Can Cause Reboot. In much the same way as the DMZ problem, sending large amounts of UDP traffic can hose the wireless interface. I used QCheck to send 1mBit of information in 10 seconds from a desktop (wired) to a laptop (wireless). You can see the [HH:MM:SS] Free=xxx decline. When it gets to 0, the wireless interface activity light goes solid and the router locks. This bug hasn’t been confirmed yet on any message board or newsgroup. (Note: this happened with default filtering settings, no spi, block wan, etc)
- Port Triggering & Duplicate Port Ranges Accodring to posts on the DSLReports discussion board, having duplicated outgoing port ranges does not work (only the first trigger entry is actually honored). I have discovered that the problem exists for both incoming and outgoing ports. For example, if you have both IRC and POP3 set up to forward port 113, only the one that’s first in the port triggering list actually works.
Jake’s BEFW11S4 Knowledge Base
- Adding a WAP11 to a network with a BEFW11S4 from Linksys.
- “Channel value is out of range error” occurs on the BEFW11S4 from Linksys. Can’t find this article anymore.
- Routers and Multiple IPSec connections from Linksys.
- Practically Networked’s BEFW guide Pages
- Practically Networked’s Review: Linksys EtherFast Wireless AP + Cable/DSL Router – Including bandwidth tests and statistics
- Dennis’ Linksys v. Orinoco Shootout! A comparison of a Linksys client card and an Orinoco Silver client card connecting to a BEFW11S4 router.
- EvansC’s BEFW11S4 Firmware Page With links to old firmware versions and information on open firmware beta tests. This page is no longer on the web, but you can find it on archive.org
Here are some software packages that have been recommended as good for use with
LinkSys routers.9 I have personally tried WallWatcher and Link Logger. As for
the others, I don’t know if they’ll even work with the BEFW11S4.
- Router Rooter
- Kiwi Syslog Daemon
- SNMP Trap Watcher
- Linksys Logviewer
- Link Logger
Since I have a PC running Windows, this isn’t a problem… but some of you running alternate OS’s (MacOS and Linux specifically) will need a TFTP client to upgrade the firmware of your router. You can also use the upgrade applet, though I’ve never tried that either. Check the Knowledge Base section for Practically Networked’s BEFW pages for more information on upgrading the firmware on other platforms.
- MacTechnologies’ MacTFTP Client
- A patch for tftp-0.16-5.src.rpm (the default TFTP for unix will work, but you have to disable the admin password)
- MaxGate’s MAC Updater for the Macintosh reportedly works.
Extending the BEFW11S4
If you’re looking to exend the range of the BEFW11S4 by changing the antenna, you’ll need an antenna system that has RP-TNC connectors. 10 TechsPlanet was discussed on usenet as a good vendor for antennas and cables.
The BEFW11S4 uses SNMPTrap as the protocol for sending the connection log information to a client PC running a log viewer application. You can write your own log viewer pretty quickly and easily. In fact, I wrote one in about 5 minutes in a language I never used before (REBOL). On top of that, it was only 14 lines. Since then, I’ve shrunk it even further to 5 lines, and simplified the parser to be more general. Here is the source to TinyLogger.
REBOL  udp: open udp://:162 forever [wait udp print trim/lines skip copy udp 73] close udp
Pretty much, all you need to do to write your own log viewer is this:
- Open UDP port 162 for listening.
- When a UDP packet comes in, throw away the first 73 bytes.
- If you have a packet that starts with an ‘@’ (after skipping the first 73 bytes). You’ll find lines like this:
out [from IP] [from port] [to ip] [to port] in [from IP] [from port] [to ip] [to port]
- Do what you will with the information. I personally am working on a REBOL script that grabs the information from the BEFW11S4 DHCP table, and matches it up with the IP’s coming in from the log. I also plan to make an app that tracks when IP’s show up that are not in the DHCP table. (in case some crafty guy is freeloading on my DSL line, but he doesn’t show in the DHCP table because he’s entered his information statically.)
Hidden Features in the 1.39.2 Firmware
IMPORTANT! For reasons we can probably guess,
these features have been intentonally hidden by the firmware coders. It stands to reason that they don’t work, or that they’re extremely buggy. I do not advocate trying these hidden features. If you opt to play with these features, you do so AT YOUR OWN RISK.
I’m going to assume you’re router is at 192.168.1.1 and has the default password of ‘admin’. If it does not, you’ll need to modify these links to get them to point to your router. Also, I’ve intentionally not made them real links because you really shouldn’t be trying this at home.
Enhanced Logging Functions (aka Diagnostic Logging)
There are some hidden logging functions available in this firmware. This log information is sent to a client PC in the same way that the traffic logs are, via SNMPTrap. According to “mole2″ this used to be known as “diagnostic logging” in previous firmware versions.11
Thanks to Glen for this: The extending logging exists in the BEFSR41 as well. You can easily access this feature by clicking the “Log” tab, then click around the top of the “Log” tab near the blue bar. I couldn’t find it at first because the mouse cursor didn’t change into the “finger” pointer for some reason.
As far as I can tell, you can check off which SNMP messages you’d like your router to send out. However, most logging clients for the BEFW11S4 don’t really know about these new logging functions.
Update: SNMP Trap Watcher does receive all of the SNMP Messages that the router sends, apparently. You won’t need to use my fucked up TinyLogger, unless you want to. Tiny Logger’s source code is available above (its 5 lines). You’ll need to swing by the REBOL site and download the freeware copy of REBOL/View (the REBOL interpreter). Its really small, and installs in about 20 seconds. Then you should be ready to run the TinyLogger for yourself, and modify it to suit your needs.
I really wouldn’t play with this, because I’m not quite sure exactly what it does.You can find these settings at:
WECA is the Wireless Ethernet Compatibility Alliance. I assume there are slightly different 802.11 standards whether you’re here in the US, or over in Japan. (Probably different FCC guidelines here as opposed to whatever spectrum oversight organization they have in Japan, I assume.) I’m not sure what the TX/RX setting is all about. If you figure out what these do, let me know and I’ll post the information here.