This Time Self-Hosted
dark mode light mode Search

First startup of the router

Tonight I tried for the first time the router in its official capacity as my main home gateway. It wasn’t really a good start to be honest.

The first problem has been the noise: my mother complained that the fans were too loud, so I wanted to go with my backup plan (replacing the main CPU fan with a fanless heatsink. Unfortunately it didn’t work out at all: there’s a capacitor in the way where the heatsink should go. Minus my intervention in form of a powerdrill over the (quite expensive) copper heatsink, it will never fit; my intervention is scheduled for tomorrow.

Sidestepped that for a moment (“Sure mom, I’ll fix it, just give me tonight to test it out!”), the next problem waiting in line was with the startup: I made a mistake in the hurry of fixing up the init scripts to actually start, and I had to take the nullmodem cable again and fix up the boot with the serial console; unfortunately I wanted to do that with my newly fixed MacBook Pro running the newly updated Snow Leopard, but the nullmodem cable had the WCH314 serial converter rather than the PL2303 (the only one I have at home that works with OS X – note to self: order some more PL2303 converters), so I had to pick up the right one again.

Queued up to fix tomorrow I got: a very custom init script to convert the ethers file into a dhcpd-compatible list of known clients, and a fix to the pdnsd init script so that it will create the cache directory if it doesn’t exist (otherwise, the daemon will silently fail to work which is definitely not what you want!).

The final problem is with the DHCP protocol and the modem itself. The modem is actually a so-called modem/router, running Linux itself, as well. Unfortunately, it seems like the way it handles the DHCP requests is not fully compatible with either dhcpcd or dhclient; the former will try to validate the provided address and then times out (failing back to ipv4ll addresses, zeroconf), and the latter tries to renew the lease every 30 seconds, without actually setting up the routes for the Internet connections.

On the other hand, hostapd seems to work fine and seems to handle multiple clients just fine; thanks to the fact that I finally can handle this stuff just like I want it to, I created a single, open, wireless network (I live in the middle of nowhere, whoever comes near my wifi enough to connect would be in my garden!), where the authorized clients will sit in one subnet, and are allowed to talk to each other, and the unauthorized clients are left in a different subnet, able to talk between them but not to the authorized ones, and can still connect to the internet (but only passively). The latter is quite helpful so that I don’t have to register all the laptops I get to fix, or all the PSPs that connect at my home.

For all those who thought that the whole idea was moot and that using Gentoo in such a system is too difficult: the only ebuild I had to locally overlay was file, which is now fixed in Portage and even in the stable systems; the rest worked fine with some tweaks; of course there are a few more issues (for instance a lot of packages install Perl-based scripts that are absolutely not mandatory, and I’d like for those to have a perl USE flag in the future), but the whole idea is not bogus and it woks fine. Using simply emerge --configroot and some custom configuration files, the resulting system is 164MB big, and with the due fixes to device.map even setting up grub was quite painless.

I guess the absolute final step would be to create a Rails application to manage the router, akin to the web interface of most commercial solutions. Yes I know that dd-wrt and other opensource firmware for “classic” routers have interfaces already, but if I have to write something, I’m most certainly going for implementing it in Ruby, as silly as that might sound. And to make stuff worse, if I do, I’ll be using sudo to launch the commands, getting the password via net… okay I’m definitely overthinking something I’m most likely never going to do.

And for those of you who know me and my mania with Star Trek names (even my cellphones are called Danube and Delta Flyer), this one got a quite famous name: Deep Space 9. After all, it is somewhat of a base station to another quadrant of the net!

P.S.: Here I might as well ask some help to the lazyweb; I am planning on two things that I haven’t started even implementing yet: IPv6 support for my network and QoS for the VoIP connections (I got two in this network usually, my cellphone and the DECT phone). For the former, I did request registration with SIXXS but I missed the “no free mail providers” bit and registered with the GMail address, and was thus rejected, now waiting in the queue to see if the staff can rescue my request or not; in the mean time I have no idea how to set up IPv6 properly to avoid making myself open to the world; ideas?

For what concern QoS does anybody have some easy link that explains how to set it up? All the stuff I found skimming through seem to be trying to explain how it work more than how to make it work; and I really don’t care how it works as much as making sure that all the VoIP traffic can trump the P2P and HTTP traffic (so that if I’m downloading a new ISO of FreeBSD I can still make calls properly). Ideas?

Comments 8
  1. Much of the noise comes from the grill on PSU.If there is no danger of some small kid or cat sticking body part in the vent, you can take it down.Also using bigger vents at smaller speeds helps big time.And, of course, good, big CPU cooler with heatpipes is kind of central thing…Although it is not exactly recommended procedure, you could power all vents with less than 12V…

  2. Hey,use Hurricane as tunnel provider – you only need to issue a https request if your puplic ipv4 address changes and afterwards set up the tunnel as usual.http://tunnelbroker.net/It’s very stable as far as I can see.SIXXS banned me for lifetime because one e-mail bounced _once_ – oh, and ask rbu what he thinks about them 😉 He got banned for lifetime too – the reason? Fixing a bug in their software and providing a patch…

  3. If you go with SixxS you should be aware that they reach no 5 nines of uptime. You can expect to have no IPv6 for at least 2 days a year and flaky connection otherwise (e.g. the first connection after creating the tunnel usually fails for no good reason).Of course it might just be that the deham PoPs are particularly unstable, a friend of mine seems to have less issue with the dedus one.

  4. You didn’t say what dhcpcd version you’re running. Have you tried dhcpcd-5 as it’s much better regarding timeouts for this.

  5. Hung up for months with this time-out dhcpcd problem on a new D-Link DSL2640B router; only gets an address 1 out of 2-6 tries… dhcpcd-5.0.6 fixes the problem; now gets an address first time, every time!

  6. Thanks for the comments about Sixxs; I’ve now registered with Hurricane, and I’ll make sure to work out the tunnelling next week so I can have IPv6 on the network here, might actually be a very good thing to me.Roy, Stan, indeed I’ve been using the stable version of dhcpcd (4.0) rather than the latest available; I’ve solved, for now, with a static route, and it works quite fine, but I’ll try 5 and see if that solves it for good, would be quite nice.Branko, indeed taking the grill off the PSU’s fan helped (the cover of the chassis already had a ventilation grill so that one was superfluous indeed. Unfortunately it’s still not quiet, I’ll see to get a different cooler (if I can get the passive heatsink to fit, with some DIY, then it would be good as well). Maybe a ThermalTake, the two TTs I have on Yamato are quite inaudible.I’ll write some note later about the changes I had to do yesterday to get all this to work, hopefully with some graphic as well; but for now I have work to go back to 🙁

  7. Four quick notes/tips on QoS:* Downstream traffic (your BSD ISO) is rarely a problem on A(symmetric)DSL. It’s the upstream that’s the bottleneck and the more connections are made (BitTorrent) the worse the situation gets.* You can only really throttle outbound traffic. Sure, you can drop incoming packets, but what’s the point in that? They’ve already travelled down the link by then. Dropping packets may trigger upstream’s congestion algorithm, though, but that’s not something to rely on.* In my experience, if you’re P2P-ing, you need to limit that traffic allotment to about 60% upload speed. Yes, HTB QoS is supposed to be able to throttle it down ‘on demand’, such as when VOIP calls are being made, but the throttling down takes long enough to be noticable. You want to have set aside for VOIP _all the time_. Maybe switching from HTB to HFSC will help me with this.* I uses Shorewall to implement QoS. You might want to look into “its traffic shaping approach”:http://www.shorewall.net/tr… .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.