Luc Pauwels

SMC Barricade
Firmware Bugs

[ Main | Bugs in 1.95 | Bugs in 1.95n | Bugs in 1.96h3 ]

Bugs in version 1.95

None. Or to be more accurate: So far, I haven't been able to find any major problems in firmware 1.95. I did notice, however, that the router slows down and eventually hangs when it has been up for several days in a row. I suspect this is due to some memory-leak condition, but there is no real way to verify this. A simple reboot fixes the problem.

The main disadvantage of running 1.95 is that it lacks some interesting features that were introducted later, such as SNMP and Dynamic DNS. That was the main reason why I decided to upgrade my router, and ultimately why this web page exists. You can find a copy of the 1.95 firmware here.

Here's already some advice for the impatient:

If you are using firmware 1.95, don't bother upgrading your router. It is the most stable firmware I've worked with so far. Don't feel bad about missing out on the new features introduced in more recent firmware versions, they don't work anyway.

The following sections contain a description of the bugs I found in firmware 1.95n and 1.96h3. So if you are still thinking about upgrading your router to a newer firmware version, read on and then decide for yourself...

Bugs in version 1.95n

My router came with firmware 1.95, which worked very well for me. Unfortunately, the lack of an SNMP agent prevented me from using MRTG to collect WAN traffic statistics.

The good news is that the newer firmware versions for the Barricade routers (starting with version 1.95n) include an SNMP agent and some other nifty stuff. Sounds too good to be true? You're right, it is!

But first, let me give you a little warning:

Warning: Before installing any new firmware, first check the Part/Model number located on the bottom of your router to make sure you have the correct firmware version for your unit! To the best of my knowledge, there are at least three different Part/Model numbers for the 7004AWBR broadband router: 750.5312, 750.5435, and 750.5345. You can find the latest version of the 7004AWBR firmware on the SMC support website.

As I already mentioned, my router did a great job when it was still running version 1.95, and I was very happy with it. However, things started to change quickly when I upgraded the firmware. I realized that by doing this, I would be violating one of the most fundamental software laws: "If it isn't broken, don't fix it". But the additional features in the new firmware made me decide to go for it anyway. This is what happened...

Warning: If you decide to upgrade your firmware, make sure you also have an installer for your current firmware version! If things start to go terribly wrong after the upgrade, at least you will be able to revert your router to the current (hopefully working) firmware. I'm not paranoid, you'll understand what I mean in a couple of minutes.

The first thing I noticed was that I could no longer connect to the unit with my wireless LAN PC card. I tried several configurations (enabling/disabling MAC access control, enabling/disabling WEP security, forcing fixed wireless speed), but to no success. As a last resort, I did a complete reset of the device to its default values. And behold: the wireless link was up again! Next, I started to manually configure the unit: PPPoE account, MAC addresses, DHCP settings,... All went well upto the moment I entered my Virtual Server settings: after rebooting the unit, the wireless link went dead. To be absolutely sure, I cleared all Virtual Server settings again and rebooted the device, and yes: the wireless link came up again.

SMC firmware 1.95n --- BUG #1
If you use Virtual Server Mapping to make services on your LAN available to the Internet, the wireless LAN functionality stops working.

Some people have reported that their router with 1.95n sometimes dies for several seconds or even locks up completely. I have observed the same behavior: if my router contains any virtual server settings and a wireless client tries to associate to the wireless LAN, then my router sometime dies. If I eject the wireless LAN PC card from my laptop, the router comes back up.

SMC firmware 1.95n --- BUG #2
If you use Virtual Server Mapping to make services on your LAN available to the Internet, and a wireless client tries to associate to the wireless LAN, the router sometimes dies.

So, now I was left with a crippled Barricade router that forced me to choose between wireless LAN and Virtual Server functionality. Maybe the unit's System Log could provide me with some clues as to what was going wrong with the Virtual Server Mapping? Well, if I tried to use any Virtual Server settings, this is what my system log looked like:

WAN Type: PPP over Ethernet (R1.95n)
Display time: Saturday, November 23, 2002 20:05:19

*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16
*00 07 64 65 66 61 75 6C 74 01 04 82 84 0B 16

Not very helpful, is it?

SMC firmware 1.95n --- BUG #3
Using the Virtual Server feature of your Barricade messes up your System Log.

But hey, at least I had an SNMP agent, which was the whole point of upgrading the firmware in the first place, right? Wrong! I tried to interrogate the unit with various SNMP tools, but most of them were unable to get any response from the device. I submitted this problem to the developers of the net-snmp package, and their conclusion was that the SMC Barricade contains a broken SNMP agent. They suspect the SNMP agent of not being able to handle requests with "high" requestIDs.

SMC firmware 1.95n --- BUG #4
The SNMP agent is broken. The SNMP reply sent by the agent contains a requestID which does not always match the requestID of the original packet and thus it is ignored by the SNMP client application.

To verify the conjecture that the router's SNMP agent only handles "low" requestIDs, I hacked the net-snmp source code to use a requestID in the range from 1 to 216. Using the modified version of the net-snmp tools, I was able to get SNMP querying to work. It was disappointing to see that the device only reports information on the WAN port. There is no information on the individual LAN ports of the built-in switch.

The print server feature in the new firmware appears to be unreliable too. My DeskJet printer is capable of two-sided printing. Before starting to print on the back side of the paper, the printer pauses for a few seconds so the ink on the front side of the paper can dry. This behavior seems to confuse the print server: it concludes that the printer is no longer responding, and thus it aborts the print job.

SMC firmware 1.95n --- BUG #5
The print server aborts certain print jobs. If you send a large document (e.g. a PDF document containing complex images) to the print server, your print job may get aborted.

To complicate matters: When printing from Windows 2000, the print job gets sent over and over again by the Window 2000 print spooler. So I end up with several copies of the same partially printed document.

By the way, did I mention that the other new functionality in firmware 1.95n, Dynamic DNS, also has a serious problem?

SMC firmware 1.95n --- BUG #6
The Dynamic DNS password is included in clear text in the HTML source.

You may think that your password is safe because the web interface uses a password box (i.e. your password appears as asterisks), but this is only cosmetics. If you look at the HTML source of the web page, you will see your password in clear text!

I reported all these bugs to SMC support, and they promised me to investigate them. Sadly, with the release of firmware 1.96h3, it seems that things haven't improved much...

Bugs in version 1.96h3

In May, SMC released version 1.96h3 of the Barricade 7004AWBR firmware. I was hoping that all issues in 1.95n would be fixed, but this is clearly not the case.

In all fairness, SMC seems to have solved the interference between the Virtual Server and the Wireless LAN features. But I still can't print, the SNMP agent remains broken, and your DDNS configuration page still includes the password in clear text.

So version 1.96h3 will not give you reliable SNMP nor DDNS, it will only fix your Virtual Servers and Wireless LAN problems. In other words, you end up with basically the same functionality as in version 1.95. So why would you upgrade to 1.96h3? I honestly don't know!

These are my test results for firmware 1.96h3:

SMC firmware 1.96h3 --- BUG #1
(identical to BUG #5 in firmware 1.95n)
The print server still aborts certain print jobs. If you send a large document (e.g. a PDF document containing complex images) to the print server, your print job may get aborted

If either the sending device or the printer stop responding for a short time, the print job gets aborted. Thus far, I have encountered the following situations:

This is what I see via my router's Extended log facility:

PC1 sent a job to printer
$lp:dp=FFEC
job was killed
PC1 sent a job to printer
$lp:dp=FFEC
job was killed
PC1 sent a job to printer
$lp:dp=FFEC
job was killed
PC1 sent a job to printer
job was killed

If anybody knows what "$lp:dp=FFEC" means, please let me know. Note also that each time the print server abort the job, the Windows 2000 print spooler automatically resends the job. So I end up with several copies of the same partially printed document. There goes the rain forest...

I think this problem should be pretty easy to fix: just increase some timeout values here and there.

The SNMP agent in version 1.96h3 has the same problem as the one in version 1.95n:

SMC firmware 1.96h3 --- BUG #2
(Identical to BUG #4 in firmware 1.95n)
The SNMP agent still doesn't work because it only recognizes SNMP packets with a "low" requestID, i.e. 0 < reqID < 216.

To test the behavior of the SNMP agent, I have used the net-snmp tools to query the agent and the Ethereal Network Analyzer to analyze the results.

Here is a typical example, including debugging info, generated with the snmpget command on a Unix box:

unix$ snmpget -r 0 -d -c xxxxxxxxxx 192.168.200.1 sysDescr.0

Sending 47 bytes to 192.168.200.1:161
0000: 30 2D 02 01  00 04 0A xx  xx xx xx xx  xx xx xx xx    0-.....xxxxxxxxx
0016: xx A0 1C 02  04 77 8A 97  C4 02 01 00  02 01 00 30    x....w.........0
0032: 0E 30 0C 06  08 2B 06 01  02 01 01 01  00 05 00       .0...+.........


Received 69 bytes from 192.168.200.1:161
0000: 30 43 02 01  00 04 0A xx  xx xx xx xx  xx xx xx xx    0C.....xxxxxxxxx
0016: xx A2 32 02  03 00 97 C4  02 01 00 02  01 00 30 25    x.2...........0%
0032: 30 23 06 08  2B 06 01 02  01 01 01 00  04 17 49 6E    0#..+.........In
0048: 74 65 72 6E  65 74 20 47  61 74 65 77  61 79 20 44    ternet Gateway D
0064: 65 76 69 63  65                                       evice

Timeout: No Response from 192.168.200.1.
unix$

The different requestIDs in both packets are underlined: The Barricade SNMP agent has truncated the high bit part of the requestID! By the way, I have hidden my SNMP community name, hence the 'xx'.

When I hack the net-snmp code to use only requestIDs in the range 1...216-1, the device responds correctly. To do this, I have modified file ucd-snmp-4.2.6/snmplib/snmp_api.c as follows:

unix$ diff snmp_api.c-ORIG snmp_api.c
372a373
>     retVal = retVal % 65536;  /* Use modulo 2^16 requestIDs */
unix$

It is probably far more efficient to do bit-shifting rather than arithmetic, but for testing the above it will do. Using the modified version of the snmpget command, I was able to get the following response from my router:

unix$ ./apps/snmpget -r 0 -d -c xxxxxxxxxx 192.168.200.1 sysDescr.0

Sending 45 bytes to 192.168.200.1:161
0000: 30 2B 02 01  00 04 0A xx  xx xx xx xx  xx xx xx xx    0+.....xxxxxxxxx
0016: xx A0 1A 02  02 38 C7 02  01 00 02 01  00 30 0E 30    x....8.......0.0
0032: 0C 06 08 2B  06 01 02 01  01 01 00 05  00             ...+.........


Received 68 bytes from 192.168.200.1:161
0000: 30 42 02 01  00 04 0A xx  xx xx xx xx  xx xx xx xx    0B.....xxxxxxxxx
0016: xx A2 31 02  02 38 C7 02  01 00 02 01  00 30 25 30    x.1..8.......0%0
0032: 23 06 08 2B  06 01 02 01  01 01 00 04  17 49 6E 74    #..+.........Int
0048: 65 72 6E 65  74 20 47 61  74 65 77 61  79 20 44 65    ernet Gateway De
0064: 76 69 63 65                                           vice

system.sysDescr.0 = Internet Gateway Device
unix$

This proves conclusively that the Barricade SNMP agent will not work with the majority of SNMP tools available today. I also noticed that no statistics are collected for any of the LAN ports.

Moving on to the DDNS feature...

SMC firmware 1.96h3 --- BUG #3
(Identical to BUG #6 in firmware 1.95n)
The DDNS password is included in clear text in the HTML source!

Using an input box of type 'password' is just cosmetics. The DDNS password should be treated in the same way as e.g. the PPPoE password. The latter is stored somewhere in the device (obviously!), but it is never included on the Primary Setup page.

Incidently, here's a little fact on the security features of the Barricade:

The Barricade uses a trivial TCP sequence algorithm on the LAN side.

I have only verified this for firmware 1.96h3, but I suspect that previous releases may be affected as well.

Although this could be considered a design flaw rather than an actual bug, it may compromise the firewall functionality of the device, so it is worth mentioning.

A port scan using the nmap tool reveals the following information:

TCP Sequence Prediction: Class=trivial time dependency
                         Difficulty=1 (Trivial joke)
TCP ISN Seq. Numbers: 82136A 8213CE 821464 8214C8 82152C 8215C2
IPID Sequence Generation: Broken little-endian incremental

In other words: the implementation uses easy-to-guess sequential TCP ISN Sequence Numbers. This could be exploited, making the unit vulnerable to all sorts of advanced attacks from the LAN side, such as exploitation of trust relationships, spoofing,...

Just to provide a little comparison, this is the result for an OpenBSD system, which is generally acknowledged as a secure operating system:

TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
TCP ISN Seq. Numbers: 66195090 7ADC7271 7445257F 24B67835 588305E1 7BD362EE
IPID Sequence Generation: Randomized

Now before you start panicking: this only applies to the LAN side of your Barricade. On the WAN side, i.e. the port that connects to your DSL or Cable router, everything is OK! So unless you have a twisted mind and start hacking into you own router, you should be safe.

And finally, one last remark about the SNMP functionality. Even if you get it to work with your SNMP client software, the results are far from reliable:

SMC firmware 1.96h3 --- BUG #4 [New!]
The results returned by the SNMP agent are incorrect. It seems that the SNMP agent counts every packet twice!

First, a little comment on querying the SNMP agent: as of version 5.0.8, the net-snmp package now includes a "16bitIDs" directive which forces the tools to use 16-bit request IDs. This allows you to query your SMC router.

Having said that, I've noticed that the results are incorrect. When comparing the network statistics of my PC and my SMC router, it seems that the router counts every packet twice. You'll notice that the value for the router is roughly twice the value for the PC.