Recently an issue over the vBulletin license arose over an animation site that an agent of Jelsoft Enterprises Ltd. (the company that owns the vBulletin forum software) reportedly found distasteful. According to the email text, a man named Howard G. Spinks of Pirate Reports, a company that investigates unlicensed software use for Jelsoft, told the animation site’s administrator, “having seen the content of your forum and some of the depraved comments that obviously it is time for you to moderate the forum to avoid a likely revocation of license.” At that, the site’s actual content became a background issue — the real question in the minds of many forum administrators was, “Can Jelsoft demand editorial control or censorship of my site just because I use its software?”

The advantages of vBulletin

Why use vBulletin when there are so many competing free software or at least less restrictively licensed Web forum packages out there? Rather than try to get an outside expert to answer this question, I’m going to choose to answer it myself, as someone who has maintained Web forums for several years, using a variety of packages including vBulletin:

• Scalability: vBulletin scales up perfectly in terms of users, posts, and overall traffic. Adding more of any of these does not choke any part of vBulletin. None of the other packages I’ve used (SimpleBoard, MamboBoard, phpBB, SMF) can scale as well — they lose the ability to search when the database gets too big, or after a few thousand posts they become slow.
• Efficiency: It’s fast — no long page load times, no unnecessary database calls (that I can detect), and uses very little bandwidth (about 104k per monthly unique visitor on The Jem Report Forum).
• Good search functionality: If you search for something using the search function, you will find it quickly and easily. Try saying that about virtually any other forum software.
• Search engine friendliness: URIs generated by vBulletin can be configured for search engine friendliness (no dynamic URIs). You can also generate barebones thread summary pages and a sitemap to make your forum even more attractive for search engine spiders.
• Heavily featured: No matter what you want to do in terms of messages, users, and usergroups, you can do it with vBulletin. It has features that I’ve wished for for a long time, like automatic thread creation via RSS feeds and banning users by IP ranges.
• Secure: According to Secunia, vBulletin 3.x has had only 12 security vulnerabilities with 0 left unpatched as of this writing. Of those 12, most were not serious flaws — only one was listed as “highly critical,” which is a severity rank of 4 of 5. Aside from knowing that your forum won’t be easily erased or hijacked by script kiddies, this fact means that there are infrequent patches and updates, so you can spend more time posting to the forum and less time trying to keep it secure. There is also a patch warning push feature in the admin control panel in vBulletin. This checks your version number against the most recent release, and informs you of patches and upgrades when they become available, along with an explanation of what has been fixed or addressed in the patch or upgrade.
• Import from anything: Jelsoft provides free database import tools from virtually any other forum package to vBulletin. It’s not always perfect from some of the tier 2 or tier 3 forum packages, but it gets all of the important data (and most people use tier 1 bulletin board packages anyway, so it may not be a concern at all). Jelsoft even has staff members that can assist you with particularly troublesome migrations.
• A predictable back button: One of the biggest user gripes I’ve seen about forum software is that you never really know what your browser’s “back” button will do. Will it go back to the message you just posted? Will it erase the text you typed in the previous page? Will it update thread and post information, or will it revert to the outdated information? Well, vBulletin always does the most desirable thing in all these situations — at least from my frame of reference as a frequent and long-time forum participant.
• Easy to install and configure: Some forum packages can be a real nightmare to install and configure. vBulletin can be installed over FTP (no SSH access required), and the installation process is heavily documented. If you still can’t do it, you’ve got commercial support options available to you, including professional installation.

I’m sure some people will disagree with my assessments, but they may not be in the same position as I am with my forum. If you aren’t making money from your forum or if it is not part of a network that you have a financial interest in, then you may not need many of the above-listed features. I don’t want to mess with the software, I just want it to work correctly right now with as few hassles as possible, and I want it to stay that way well into the future. vBulletin is among the few software packages on my server that was easy to set up and is simple to manage in the long term.

Open but not free

For years the Free Software Foundation has insisted that the terms “free software” and “open source” are not the same. Having access to the source code and having some ability to modify it for your own purposes does not imply any other rights. vBulletin is a perfect case in point: You purchase or lease a vBulletin license and are allowed to modify the source code, but you may not distribute it, use it on more than one site (without further license payments), or use it for illegal purposes (it is not clear as to which countries’ laws this refers to). To many, these are acceptable terms to abide by, especially since the software is not prohibitively expensive and Jelsoft seems particularly responsive to customer needs through email and through its vBulletin support forum.

The entire license text is online for those who would like to see its exact wording. The part that applies to the situation discussed in this article — referred to as the Acceptable Use Policy or AUP — is not there, though, and I was unable to find it anywhere in my own vBulletin materials or through the vBulletin Web site. Since the license clearly states that it “constitutes the complete statement of the agreement between you and Jelsoft,” one may assume that there is no separate valid AUP.

Statement from vBulletin

Concerned that Howard Spinks’ comments portended site censorship and forced editorial control over the sites run by Jelsoft’s customers, I attempted to contact Mr. Spinks and Jelsoft to ask them what their intentions are in this arena. Spinks refused to reply to messages sent to the contact address listed on the Pirate Reports Web site, but Jelsoft responded immediately with a canned response copy-and-pasted from at least one vBulletin support forum thread topic on the matter:

Please note that we are not going to discuss the hongfire.com situation at this time. There is much more to this than you know and what hongfire.com is claiming and this issue is not open for public discussion at this time. When and if we have a public response we’ll will post it publicly on our forums. Thank you for your understanding.

The issue, however, was not with a specific site or its content, but with the possibility that vBulletin customers might have to edit or censor their Web sites in accordance with the whims of Pirate Reports and Jelsoft employees, their friends and family members, business associates, etc. If it is acceptable to revoke a vBulletin license for one site because of its content, then it becomes much easier to turn this one exception into a regular practice. What starts out as a license revocation for sexually suggestive cartoons may become license revocations for atheists, civil libertarians, gay people, abortion supporters, black people, women, or any individual whom Jelsoft’s extended family might disagree with, dislike, or would otherwise silence. In the interest of clarifying Jelsoft’s licensing policies regarding site censorship, I pressed further and got in touch with business manager Ashley Busby.

If a vBulletin customer prints or publishes information that you, a Jelsoft employee or owner, or a Pirate Reports agent finds objectionable or offensive, is cancelling this customer’s vBulletin license a standard response? If not, is it a valid response from your frame of reference?

Ashley Busby: I am sure that you are aware that there are many vBulletin forums with varied content; indeed you have your own vBulletin forum. We do not police content.

Have customers complained about vBulletin licensing terms in the past? If so, what seems to upset them most? Could the vBulletin license, as currently worded, give Jelsoft the ability or the right to censor its customers’ forums or Web sites?

AB:Our license agreement has not been a cause for complaint and it clearly points out that we are not responsible for the content of any messages posted on a vBulletin forum. We deal with many queries and in all cases, we aim to maintain our high standard of customer service. It would be misleading to suggest that these levels are met in every instance, but the intention is always for the best and your concerns about your license should be laid to rest.

Living on a thin line

It is possible that when Howard Spinks reportedly said, “having seen the content of your forum and some of the depraved comments that obviously it is time for you to moderate the forum to avoid a likely revocation of license,” he was referring to something else. Perhaps an illegal copy of vBulletin was being distributed as an attachment in a forum post. This could be one of the background issues that the initial Jelsoft representative alluded to. That does not match up with this Digg comment from someone named “PirateReports” that speaks in the first person about dealing with this situation. The post claims the issue is primarily about removing content that has been judged “not normal” per an Acceptable Use Policy that does not appear to exist. Whether the content is illegal or not is not for Howard Spinks or his company to determine, and it is certainly not for him to enforce. By what right does he act as an Internet cop in this instance, if a so-called “pirated” version of vBulletin is not the root of the problem?

So Jelsoft does not in fact police customer content according to a manager at the company. That suggests that Howard Spinks, if the quoted email text and the Digg comment post were indeed authored and sent by him, was either badly mistaken or grossly out of line. Not long after Ashley Busby replied to my questions, I noticed that the supposedly objectionable site had come back online with a message stating that Jelsoft had decided not to revoke that customer’s license. There may well have been other, less visible issues relating to license violations that were amicably resolved behind the scenes, but since no one will talk about it, there’s no way to know. One wonders, however, what would have happened if there had not been a post about this on Digg, and so many people had not questioned Jelsoft’s licensing and customer service policies. Would the outcome have been the same? After all, other companies do police customer content according to their own puritanical beliefs, so the issue is not new or unusual. If you do a Google search on “acceptable use policy” you’ll find a lot of ridiculously restrictive rules for a wide variety of services.

In any case, the software options for top-tier forum packages are limited and for the time being vBulletin is the king of the hill. Hopefully this was a grievous error that will never be repeated, and not the start of a horrid licensing problem that will come back to bite all vBulletin customers in the future.

Discuss this article or get technical support on our forum.

Copyright 2006 Jem Matzan.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.

The problem

If you have not had any trouble with network drivers recently, you probably aren’t aware of the problem that this article addresses, so here’s a quick overview: The increasing need for higher network chip performance and lower cost of manufacturing has encouraged companies that create computer network chips to abstract software that was previously permanently stored on the chip. When this software is integrated with the hardware, you don’t have to think about it — it works without any extra effort, and all you need is a driver so that your operating system can interact with it. If hardware specifications are not provided, the device can be reverse-engineered to create a driver from scratch. Programmers generally do this by playing with the hardware registers until they figure out how to interact with it.

When the software is abstracted from the hardware, it changes from an invisible program stored on a memory chip into a file that must be loaded into the network chip’s memory through the driver. Generally this software (no matter where it resides) is called firmware. In this case the driver does not interface with the hardware directly; it only does so through the firmware. In this scenario it is impossible to reverse-engineer the hardware because it is essentially brain-dead without its firmware — all it knows how to do is load the firmware. Once the file is loaded into the network chip, then the hardware knows how to be a network device. Essentially the firmware is its own device-specific operating system. Programmers are unable to reverse-engineer this kind of hardware because the only registers they can play with are the ones that load the firmware; they can, however, reverse-engineer the firmware interface once it is loaded. That’s still not an easy thing to do, but even if it weren’t so complicated, many operating system developers don’t want to write their own device firmware — all they want to do is write a driver that can load and interface with it.

The first challenge for operating system developers is obtaining the right to distribute the firmware file, which some manufacturers will not allow without significant restriction. Firmware is not operating system-specific, so the same firmware file can be used with any OS, provided it has a driver that can interface with it. So the second challenge is creating such a driver, which requires firmware interface documentation. Not surprisingly, many of the same manufacturers that prohibit or restrict firmware distribution also won’t provide interface documentation.

This problem is most prevalent with wireless network chips, but it’s also creeping into the wired variety as well. Most notably, Broadcom has developed a new PCI Express 10/100/1000 LAN card that uses several discrete MIPS processors, all of which require proprietary firmware to be loaded. According to a network driver programmer I spoke with, they are employed as such: One of the processors is responsible for loading the firmware onto the other chips; one sends network packets; one receives packets; one tracks packet state to perform TCP offload assistance and various other things; one handles negotiating with the host CPU as it puts/removes packets in/out of the descriptor rings. In this case, all of the firmware fits into an 87k file, but firmware files can be considerably larger: Intel’s firmware files are just under half a megabyte, and the firmware for the Alteon Networks Tigon II network controller is in the vicinity of 2MB.

Unrestricted redistribution of firmware files is satisfactory for some open source operating system projects like OpenBSD, FreeBSD, and many varieties of GNU/Linux, but others like Fedora Core and Debian demand an entirely free software environment, so redistribution of the firmware without the ability to modify and distribute the source code is prohibited. The standard response to this from the Free Software Foundation is to reverse-engineer the device and provide free firmware. So even though it is very difficult — almost impossible — to do it in the absence of documentation, could such firmware eventually be reverse-engineered? The development team that works on the OpenBSD operating system has a lot of experience with reverse-engineering, but both project leader Theo de Raadt and OpenBSD network driver programmer Jonathan Gray agree that such work would be impractical. Of reverse-engineering firmware and the hardware that it runs on, de Raadt told me, “We can sometimes reverse-engineer how to talk to a device… some are worse than others… but imagine reverse engineering the firmware of 300-400 devices on the market today! Behind their little ARM/MIPS buses, they are a no man’s land of undocumented-ness and bugs; hundreds and hundreds of bugs created almost all by the realities of ‘time-to-market pressures.’” The issue, in other words, is made worse by hastily-designed hardware that doesn’t work as it should, and requires specific workarounds in the firmware and/or driver. Sometimes manufacturers provide patches or documentation for driver programmers; sometimes they don’t.

So instead of lobbying for documentation to write open source firmware, de Raadt would prefer to simply have the right to freely distribute necessary proprietary firmware files with his operating system, along with correct firmware interface documentation so that a driver can be created, and information from the manufacturer regarding bug workarounds. Many network chip manufacturers stubbornly refuse to grant these requests, however. Theo de Raadt told me in an email, “Our efforts to do more wireless involves a few approaches. We reverse-engineer what we can. We borrow from other people’s reverse-engineering lessons where we can, for instance, prism54.org is a Linux team, but their reverse-engineer work has resulted in knowledge which we can obviously use to write a BSD driver. And finally, we dialogue directly with vendors to get more free access to documentation, early access to hardware, or firmware distribution rights (sometimes there is just no other way). Some vendors (in particular Ralink or Realtek) will even give us hardware before it goes on sale. Some give us documentation, some give us code. But largely a lot of American vendors are still stupidly resisting giving anything. In any case, all these efforts together now mean that we have more wireless support in OpenBSD than all the Linux distributions. Maybe even combined!”

According to Jonathan Gray, the drivers that OpenBSD currently has that require firmware that vendors won’t let the OpenBSD Project distribute are:

• acx (4) – TI ACX100/ACX111 IEEE 802.11a/b/g wireless network device
• ipw (4) – Intel PRO/Wireless 2100 IEEE 802.11b wireless network device
• iwi (4) – Intel PRO/Wireless 2200BG/2225BG/2915ABG IEEE 802.11a/b/g wireless network device
• malo (4) – Marvell Libertas IEEE 802.11b/g
• bcw (4) – Broadcom IEEE 802.11b/g (this driver is still under development and does not currently work)
• wpi (4) – Intel PRO/Wireless 3945ABG IEEE 802.11a/b/g
• pgt (4) – Connexant/Intersil Prism GT Full-MAC IEEE 802.11a/b/g wireless network device
• uath (4) – Atheros USB IEEE 802.11a/b/g
• wpi (4) – Intel PRO/Wireless 3945ABG IEEE 802.11a/b/g wireless network device

And the wireless devices that either do not require firmware, or that have runtime firmware that OpenBSD is allowed to distribute:

• atu (4) – Atmel AT76C50x USB IEEE 802.11b wireless network device
• ral (4) – Ralink Technology IEEE 802.11a/b/g wireless network device (2nd gen 802.11 Ralink)
• rum (4) – Ralink Technology USB IEEE 802.11a/b/g wireless network device
• zyd (4) – Zydas ZD1211 USB IEEE 802.11b/g wireless network device

Intel requires that people who use its Centrino wireless firmware submit to a lengthy license agreement before downloading and using it. While the majority of end-users may just scroll down and click the “I Agree” link to get past it, the process is not quite so simple for free software operating systems, which would have to provide the same license hurdle for every one of their users, and agree not to modify any of the driver header code that Intel provides. Commercial desktop GNU/Linux distributions like SUSE, Mandriva, and Linspire already do this, or have independent distribution agreements with Intel.

When reverse-engineering works

Reyk Floeter and various other OpenBSD programmers managed to write a free replacement for the proprietary Atheros hardware abstraction layer (HAL) called ar5k or “OpenHAL.” The HAL isn’t firmware; it is a form of abstracted device driver that actually loads into the operating system kernel through a small amount of driver code. The big difference between a HAL and a firmware is where the code resides; if it’s on the device, it’s firmware, and if it is loaded into the operating system’s kernel, it’s HAL.

ar5k works with many Atheros-based wireless cards and has been examined and recently given a clean bill of copyright health from the Software Freedom Law Center. Mysteriously, it has virtually no support from the Madwifi Project, which is the development team responsible for creating Atheros drivers for Linux-based operating systems. Madwifi continues to primarily support the proprietary Atheros HAL, though there is an old and uninformative page in the Madwifi Wiki about it. The email addresses listed for the Madwifi developers either bounce or elicit no response to requests for comments on why there is no apparent effort to use the open source HAL in Madwifi. So if it exists, it’s free-as-in-rights, and it works, then why doesn’t Madwifi use ar5k instead of the proprietary HAL? It may very well be pressure from Atheros that keeps ar5k out of Madwifi, but no one at Madwifi or Atheros would talk to me about it.

The manufacturers speak — or don’t

In order to find out why network chip manufacturers are so polarized in their support of free software operating systems, I made contact with company representatives at Atheros, Intel, Marvell, Atmel, Ralink, Texas Instruments, Broadcom, and Realtek. Not surprisingly, the manufacturers who shun operating system programmers also seem to be reluctant to talk to the press.

Atheros

After weeks of repeated requests and pleas for any kind of response just to verify that the PR email address works, an Atheros representative told me that she was unable to find anyone at the company who was qualified and willing to comment for this article.

Intel

Intel punted me to different people a few times, then after a short delay and a bizarre inquisition into my professional background and “intentions” in writing this article, told me that the company had nothing to say on the matter of wireless firmware distribution rights and interface documentation. Considering Intel’s outstanding PR record and its general willingness to provide hardware documentation for the PCI chipsets and drive controllers that it makes, this behavior is unusual. One of the questions I asked Intel was if it felt its uncooperativeness with free software developers was in direct conflict with this presentation about the importance of participating in and supporting open source software development that Intel engineer James Ketrenos gave last summer. In it, Ketrenos says several things in favor of corporate cooperation with open source software developers, including these points:

• Enable the community to do as much as possible
• Only keep internal those things that the community can not contribute to (Example: Certification testing)
• If you need to keep IP closed source (for example some whiz-bang algorithm), document the hardware sufficiently that the community can provide their own.
• Treat the community as if they were a member of your internal team

Broadcom

The Broadcom press relations person I spoke with very much wanted to help me, but could not find anyone at Broadcom who felt qualified to comment.

Marvell

I have already written about the substandard responsiveness of Marvell’s outsourced PR agency (see the bottom of the linked article).

Texas Instruments

An internal Texas Instruments press relations person was very responsive to my requests for comment at first, then punted me to an outsourced PR agency which, in turn, ignored several emails asking for information. After more than two weeks of repeated inquiries, a representative of the PR agency informed me that she was unable to find anyone at Texas Instruments who was qualified to comment on TI’s policies on providing hardware documentation and firmware redistribution agreements.

Ralink Technologies

I had no trouble getting through to Ralink, where I spoke with company representative Lillian Chiu.

Ralink has been responsive to requests for hardware documentation without requiring an NDA. Why can Ralink do this when competing manufacturers such as Intel and Marvell require non-disclosure agreements?

Lillian Chiu: It’s our philosophy to spread the technology without border, along with high performance and low cost.

Because of Ralink’s cooperativeness with projects like OpenBSD and Linux kernel developers, Ralink’s products tend to be very well supported in so-called “alternative” operating systems. Do you see this as a competitive advantage? Does Ralink sell more network products as a result?

LC: Our customers have often provided positive feedback for our best-in-class device support. We see it as a win-win situation where advanced users get more flexibility while we sell more products.

If a programmer needs to access Ralink hardware documentation, whom at Ralink should they contact?

LC: Please visit Ralink Web site at www.ralinktech.com for details under /support/forums.

Atmel Inc.

Richard Bisset, product marketing director of the multimedia and communications group, offered several minutes of his time to answer some questions about wireless drivers and firmware.

Atmel has been responsive to requests for hardware documentation without requiring an NDA. Why can Atmel do this when competing manufacturers such as Intel and Marvell require non-disclosure agreements?

Richard Bisset: For some things we do require non-disclosure agreements, but we are generally able to provide the API documentation and the firmware driver interface specifications for our hardware. As to why others may not be able to do this… well, our software is developed in-house, but others might out outsource their driver development to third-party companies, so they may not even have the documentation that a programmer requests.

As to why Intel might be so secretive with this information if they do have it, I can’t say. Perhaps because more and more features are actually being moved from the firmware to the driver, some companies are being more guarded than others. Additionally, as the Centrino laptop processor includes wireless, it may be they don’t want to give up any potential IP that could help their competition — I don’t really know for sure.

Because of Atmel’s cooperativeness with projects like OpenBSD and Linux kernel developers, Atmel’s products tend to be very well supported in so-called “alternative” operating systems. Do you see this as a competitive advantage? Does Atmel sell more network products as a result?

RB: Well, if you look at the success of Intel, Marvell, Broadcom, etc. — the big players in the wireless industry — they are successful with the OEM and peripheral markets. As the embedded markets generally require more technical support, they probably don’t care much about getting another 50,000 or 100,000 units sold and can be tight with their APIs. We were late to market with our 802.11g products, so we missed the OEM opportunities, and with wireless, you’ve only got three real chances for success: you can be first to market with a technology, or you can have valuable and unique features that no one else has and the market wants, or you can have the lowest price. Atmel wasn’t first, didn’t have any new unique features, and wasn’t the cheapest, either. With the PC and OEM markets being somewhat locked out, we repositioned to focus on the embedded space where the market was experiencing and predicting large growth. In the embedded market, if you don’t get documentation to developers, then you both fail.

What’s the big secret with device firmware, then?

RB: Firmware is generally running on the chip itself, as opposed to the host. The code is written tightly coupled to the chip it is running on and implements/enables functions that the hardware supports. Therefore, there generally is a lot of IP within the firmware. Our firmware is loaded from an external flash into internal SRAM, but more and more semiconductor manufacturers are moving firmware functions to the driver.

We usually provide driver source code, and we try to put it under the GPL if possible, so that’s usually good enough if you want to write your own driver. If you want to see more than that, we generally require an NDA, or if you’re an embedded customer, we provide reference platforms.

So the firmware is so secret that you have to sign an NDA to see it, but not secret enough that some stranger who works on an obscure operating system can see it with merely a signature?

RB: It is kind of a strange situation, yes, and sometimes we run into people who are reluctant to sign NDAs. It really depends on the customer and target application. We don’t require an NDA to see hardware APIs, and I think that’s what you’re talking about with regard to documentation.

If a programmer needs to access Atmel hardware documentation, whom at Atmel should they contact?

RB: We have contact forms through our Web site where you can make requests, and they are directed to the proper person at Atmel.

Realtek Semiconductor

After a few emails, I made contact with Tracy Ho, a Taiwan-based representative for Realtek.

Realtek has reportedly been responsive to requests for hardware documentation without requiring a non-disclosure agreement (NDA). Why can Realtek do this when competing manufacturers such as Intel and Marvell require NDAs?

Tracy Ho: For some years Realtek has been one of the largest NIC/LOM solution providers. One of the major reasons for this is that Realtek takes customer service as one of its top priorities. We aim to work with our customers as partners in a mutually cooperative environment. Our product sales and technical support teams are well-recognized by our customers and we strive to provide them with the convenience of flexibility and real-time support. One of the ways we do this is by releasing general hardware documents without requiring a NDA.

Because of Realtek’s cooperativeness with projects like OpenBSD and Linux kernel developers, Realtek’s products tend to be very well supported in so-called “alternative” operating systems. Do you see this as a competitive advantage? Does Realtek sell more network products as a result?

TH: Realtek has been working very closely with various operating system providers pretty much since the company was first started, and we do consider this to be one of our competitive advantages. Over the last decade, the great expansion of networked devices throughout the home and work environment, and the use of open-source operating systems in many such devices, has definitely helped us expand market share.

If a programmer needs to access Realtek hardware documentation, whom at Realtek should they contact?

TH: For most hardware documentation, programmers can access Realtek’s website. Any other questions can be directed to our technical support teams (contact information available from the “Contact Us” link on our website).

All we need to do is make sure we keep talking

Some of the non-responsiveness of manufacturers may just be bad PR work, but the same companies that wouldn’t talk to me have also refused to reply to free software programmers who have requested the same information. The impression I got from most of these companies (excepting Intel) was that they were not at all prepared to deal with the issues of firmware redistribution rights and hardware API documentation requests. That they have ignored free software programmers’ requests is not necessarily a sign of unwillingness to participate, but perhaps a general sense of confusion as to how they are able to help. No one seems to know whom to talk to at the company, and in some cases the proper documentation may not exist — or it may belong to yet another company that the hardware manufacturer outsourced the firmware development to.

On the other hand, it was just as difficult to contact and get comments from the Madwifi developers, and it seems that each individual wireless driver in the Linux kernel has different people working on it. Even if one of the above companies wanted to provide the appropriate materials to create free drivers and firmware, how would they know whom to contact? The irony in this story is that the heart of the problem lies in a lack of communication, but not between operating systems and network devices — between hardware manufacturers and the software developers who are trying to support their devices.

Discuss this article or get technical support on our forum.

Copyright 2006 Jem Matzan.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.

Writing analysis

“DerEngel” is the author’s handle; his real name is not given in the book, though there is a photograph of him on one of the last few pages. Apparently he lives in Taiwan, where he messes with cable modem hardware, firmware, and utilities, and was the original author of the first few cable modem hacking articles on the Web.

Hacking the Cable Modem is at times very interesting, at other times too heavy with technical details, and in the latter chapters often covers information that applies only to specific devices. The first several chapters, which deal with the history of cable modem hacking, an explanation of cable modem service and networks, and an overview of some popular cable modems, is very interesting. After that it takes a dramatic downhill turn. I thought the author’s individual reviews of cable modems were terrible — he seemed more interested in the cosmetics of cable modems (the color and design of the plastic case, how many LEDs it has and what they do, etc.) than the functionality they were capable of. I was also pretty disappointed in the lack of information on the modems that were covered. Considering how hackable routers are, I found it extremely disappointing that modern cable modems only had a few sporadic hacks available for them.

The book’s discussion of software is limited to Microsoft Windows which, along with the author’s bio in the back of the book in which he extols the virtues of Visual Basic and Microsoft’s .NET platform, dramatically reduces DerEngel’s credibility as a hacker, from my frame of reference. Microsoft Windows is the training wheels of desktop computing; if you’re still riding around on it in this day and age, I question your ability to tell me how to me to do something technical with a PC. The same goes for Visual Basic — it is not the preferred language of any credible computer hacker I have ever met.

Putting the book to the test

I did not put Hacking the Cable Modem to the test for several reasons. First of all, my cable modem (or anything remotely like it) is not mentioned in the book and none of the hacks listed were likely to work. Secondly, I’ve no problem paying extra money for more bandwidth and all of the ports that I need opened are open, so I don’t have any inclination to hack my modem. Third, if I were to get caught hacking my cable modem and changing its settings for my benefit, I would certainly lose my Internet service, which means that my Web sites would be taken offline. Why would I want to risk that? The author tells a story in Hacking the Cable Modem in which someone he once knew uncapped his modem and subsequently had all of his computer equipment seized by the police. After a lengthy court battle, the man was out $1000 for a fine and more for whatever it cost him to hire a lawyer. Again I ask: Why would I want to risk that?

If you do decide to put these hacks into practice, you will be limited in your choice of modems and will likely have to do some soldering and/or some disassembly of the modem to modify its hardware. This is not a book for people who lack a history of disassembling electronic devices (or rather, successfully re-assembling them).

Conclusions

There is virtually nothing useful in this book that you can put into practice without risking some sort of punishment. DerEngel himself makes that very clear. There are many book ideas that sound like they encourage illegal activity but could be used for good purposes. For instance a book on how to break into a home would be very useful for improving home security. A book on how to cheat on your taxes would be a helpful tool for IRS auditors and ethically-minded accountants. But what about a book on hacking a cable modem? If you can’t legally use the hacks in such a book, then to whom is it useful? People who design cable modems, perhaps, but who else? I can’t really think of anyone, myself, so I can’t really recommend this book to anyone. It is interesting from a technical standpoint, but the information it contains is practically useless to the majority of PC users.

Title	Hacking the Cable Modem
Publisher	No Starch Press
Author	DerEngel
ISBN	1593271018
Pages	Paperback, 290 pages
Rating	4 out of 10
Tag line	What cable companies don’t want you to know.
Price (retail)	U.S. $20. (Buy it from Amazon.com)

Discuss this article or get technical support on our forum.

Copyright 2006 Jem Matzan.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.

Search our articles and reviews

| Contact Us | About Us | RSS FAQ |
Copyright 2008. All content items belong to their respective authors.