Tux, Please Pass The Packets.

khess 0 262 Views

Yesterday, NetGear released the long-awaited open source wireless router WGR614L--a high-performance, full-featured, wireless router with 4-port switch running, you guessed it, Linux. The router currently supports the free open source Linux-based Tomato and firmware and will soon support OpenWRT.

From a hardware perspective, the WGR614L sports a 240 MHz MIPS32® CPU core with 16 KB of instruction cache, 16 KB of data cache, 1 KB of pre-fetch cache, and incorporates 4 MB of flash memory and 16 MB of RAM. In addition to an external 2 dBi antenna, the WGR614L integrates a second internal diversity antenna to provide enhanced performance and range according to their press release.

NetGear is attempting to gather a new breed of customer for its products: Open source enthusiasts.

From the myopenrouter.comwebsite:

“The launch of the WGR614L is significant to the open source community as there has been a growing demand for more powerful platforms to support a rapidly growing segment of open source enthusiasts that are seeking to create more robust, commercial-grade applications for their wireless routers,” stated Som Pal Choudhury, senior product line manager for advanced wireless at NETGEAR.

This new product should start a cascade of competing products for the open source community to test and develop. I would like to see an open source load balancer for large networks. Maybe, at some point, there will be a standard open source router OS so that it doesn't take an expensive certification to program one.

Dani AI

Generated

Good catch, . A few practical, non-hype notes for anyone experimenting with community firmware or thinking about turning small consumer boxes into production kit.

A short pre‑flight checklist: make a full backup of the stock image and export the current configuration; record the exact hardware revision shown on the case and match images to that revision; read the project recovery/unbrick instructions before flashing; keep a USB‑TTL serial adapter and TFTP/console recovery plan at hand so boot messages can be inspected if something goes wrong. Because many consumer boards have tight flash/RAM budgets, prefer minimal builds for day‑to‑day use and offload optional services to an external box or VM.

Expect practical limits: NAT, VPN and large numbers of concurrent connections are usually CPU‑bound on small embedded routers. Some vendor firmwares expose hardware offload; third‑party builds sometimes lack that support and throughput can fall as a result. Benchmark with realistic workloads (iperf with many simultaneous flows, varied packet sizes) and monitor CPU, conntrack table usage and memory while testing.

For multi‑WAN/load balancing at scale, treat the router as one element in an architecture: policy‑based routing plus connection marking gives session stickiness, health probes should check application‑level reachability (not just ICMP), and failover logic needs hysteresis to avoid flapping. For production, centralize routing, DHCP and firewalling on a platform with more CPU/RAM and add HA (VRRP/keepalived) and configuration management for predictable rollbacks.

If the goal is an open‑source load balancer or a de‑facto router OS, useful community work includes reproducible builds, smaller base images, standardized package feeds, and clearer hardware‑revision tagging. A final caution: modifying factory firmware can affect warranty and regional radio compliance. When reporting issues, model plus hardware revision and the exact firmware image name are the single most useful pieces of information.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview