My SOHO network layer model

In my eyes, it makes sense to divide the elements that are part of a SOHO (small office/home office) network into one of two layers:

Basic network and productive services
Basic network and productive services

In this model, if I were to speak about “the network” I’d mean what I call the basic network: all components that in their togetherness constitute an independent, foundational layer cornered around connectivity and, by comparison, low complexity (ie. no full-blown operating system on each device). This includes the physical LAN cabling (if present), network switches, print servers (usually integrated into the printers), WLAN access points and routers.

Because nowadays it is often essential for system administrators to have Internet access, be it for googling on problems that pop up or for bootstrapping installations that download software directly from the ‘Net (eg. in disaster recovery scenarios when no local mirror is present any more), I consider DNS and DHCP services to be essential enough to be part of the basic network as well.

With the advent of flash-based embedded devices such as WLAN access points and routers, the availability of OpenWrt as a standardized Linux distribution for these and the low resource consumption of DNS/DHCP, migration of these services from hard disk-based servers onto access points/routers became feasible. After all, an access point running on flash memory is much less likely to fail than a full-blown server with hard disks as storage. The only part I’ve seen failing over years with these devices is the $0.05 power supply.

The basic network is foundational in two ways: for one thing, it is independent, ie. can stand on its own. And the productive services layer, that encompasses more value-creating (to the end user) services such as File, Print and E-Mail services, is stacked upon it. No basic network, no productive services. And at the same time: no productive services, no real value in the basic network.

Formulating such a model helps in making up your own mind and communicating with others, eg. about the question where a service such as NTP should be placed. What do you think?

The shortcomings of the Linux LEDs API

In a recent post I mentioned that the Linux kernel has a dedicated API for LEDs. This API is composed of the drivers/leds/ directory and the additional <linux/leds.h> include file, Documentation exists in form of the Documentation/leds-class.txt file. To quote:

“The underlying design philosophy is simplicity. LEDs are simple devices and the aim is to keep a small amount of code giving as much functionality as possible.  Please keep this in mind when suggesting enhancements.”

While this goal appears supportable, the result leaves room for discussion. Continue reading “The shortcomings of the Linux LEDs API”

Hacking the Netgear WG102 Access Point

This article describes my experiences while conducting some reverse engineering of the Netgear WG102 firmware. For one thing, you might learn something about the approaches and methods useful when you want to find out “how they did that” (they = the device’s manufacturer) in general, on the other hand there is also a lot of WG102 resp. Netgear-specific information in here, of course.

This article describes my experiences while conducting some reverse engineering of the Netgear WG102 firmware. For one thing, you might learn something about the approaches and methods useful when you want to find out “how they did that” (they = the device’s manufacturer) in general, on the other hand there is also a lot of WG102 resp. Netgear-specific information in here, of course.

Continue reading “Hacking the Netgear WG102 Access Point”