Router on TurboVision

Home Router in 2003: Debian Woody, iptables and the Stuff Which Runs

Sun, 02 Mar 2003 00:00:00 +0000

Now the router is in a phase where I trust it.

This is a good feeling. It is not the first excitement feeling from the early SuSE days, and it is also not the hack-pride feeling from the D-channel/syslog trick. It is something else. The machine is simply there. It routes. It resolves. It gives leases. It proxies web. It zaps ads. It survives reboot. It is part of the flat now like the switch or the shelf.

The disk swap from the 486 into the Cyrix box worked. Debian Potato was first on that disk, but by now I moved the system further to Debian Woody. That means kernel 2.4, and now finally iptables instead of ipchains.

The move from Potato to Woody

This is not a dramatic migration like the first Debian step. This one is more calm.

The big practical reason is netfilter and iptables. I want the 2.4 generation now. I want the more modern firewall and NAT setup, and I also want to stay on a current stable Debian instead of freezing forever on Potato.

So now the stack looks like this:

Debian Woody
kernel 2.4
iptables
bind9
dhcpd
Squid
Adzapper
PPPoE on DSL

This is already much more modern feeling than the original SuSE 5.3 plus ISDN phase.

The box itself

The hardware is still the same Cyrix Cx133 box. Beige, boring, a bit dusty, absolutely fine.

With 32 MB RAM it is much happier than in the 8 MB starting phase. This is one of the reasons I am glad I did not keep the 486 as the final router. The 486 was okay for proving the install and services, but the Cyrix with more memory is simply the better place for Squid and general peace.

The Teles card is still physically there for some time after DSL. Then it becomes more and more irrelevant. I keep the old configs around for a while because deleting old working things always feels dangerous. Only much later do I stop caring about the old ISDN remains.

Local services: the boring ones and the useful ones

The router is not only a router anymore. It is the small local infrastructure box.

DHCP

dhcpd does what it should do and I mostly do not think about it anymore. Which is good.

Clients come, they get an address, gateway, DNS, and that is it. If DHCP is broken, everyone notices fast. If it works, nobody says anything. This is one of the purest sysadmin services in the world.

DNS

Now I use bind9, not the old bind8 from the Potato phase. Still forwarding, still simple. I am not suddenly becoming an authority server wizard. I still want a local cache and one place for clients to ask.

What I like is that DNS problems are easier to see now because the line is always on. In the ISDN phase one could confuse line-down issues and DNS issues very easily. With DSL that whole category of confusion is much smaller.

Squid + Adzapper

Squid remains important. Maybe less dramatic than on ISDN, because the DSL line is already much nicer. But the proxy still gives me cache, central control, and with Adzapper it still gives me a better web.

Adzapper is honestly one of my favourite small pieces in the whole setup. It is so unnecessary and so useful at the same time. Web pages are getting heavier and more stupid. Banners everywhere. Counters. Tracking garbage. The proxy says no and shows a small zapped replacement. Perfect.

iptables: finally a nicer firewall world

With Woody and kernel 2.4 I finally move to iptables.

The logic is not new. I already know what I want the firewall to do:

default deny where sensible
allow established traffic back in
let the internal network out
do masquerading on the DSL side
only open specific ports intentionally

But the framework feels cleaner now.

My base script is still very normal:

iptables -F
iptables -t nat -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

This is not a firewall masterpiece. It is just a decent honest firewall for a home router.

And this is enough for me.

Things that changed since DSL

The biggest change after DSL is not only speed. It is mentality.

On ISDN I was always thinking in sessions:

line up
line down
should I bring it up now
did the first request trigger it
will this cost something stupid

On DSL this is gone. The connection is just there. That means I can think much more about service quality and less about connection state.

That is maybe why the router in 2003 feels more complete. The old uplink logic noise is gone, so the rest of the machine can come into focus.

Things that still annoy me

Not all is paradise of course.

Sometimes PPPoE feels a bit ugly. Sometimes package upgrades want a bit too much trust. Sometimes Squid config debugging is still a way to lose an evening. And sometimes I make one firewall typo and then of course I only notice it when I am on the wrong side of the router.

But these are good problems. They are now normal Linux administration problems, not existential connection problems.

Also I still keep too many old notes and backup files. The system is half clean and half archaeology. This is maybe standard student-admin style.

What I use this machine for now

The funny thing is that the router is no longer just about internet access. It is a little confidence machine.

When I want to test something network related, I have a real place for it. When I want to understand a service, I can run it there. When I want to make some small infrastructure experiment, I do not need to imagine it, I can really do it.

This maybe sounds bigger than a home router deserves, but I think many people who did such boxes know exactly this feeling. A machine at the edge of the network teaches a lot because it sits exactly where things become real.

What comes next

I do not think this box is finished. It is only stable enough that now I can be a bit more calm.

Maybe next I write more detailed notes about:

iptables rules I actually keep
Squid and Adzapper config
what I changed from Potato to Woody
maybe some monitoring because right now I still trust too much and measure too little

For now I mostly enjoy that the DSL LED is stable, Debian is on the box, the Cyrix is still alive, and all the little services come up after reboot without drama.

That alone is already very good.

Debian Potato on a 486 Before the Real Router Swap

Sat, 08 Sep 2001 00:00:00 +0000

Now the DSL line is finally really there.

The modem LED is not blinking anymore. It is stable. This alone already changes the whole feeling in the room. For years that modem was almost decoration with hope inside. Now it is actually the uplink.

The speed is T-DSL 768/128. For me after ISDN it feels very fast. Web pages are suddenly there. Bigger downloads are no longer some project planning. The line is just there all the time. No dial on demand. No waiting for the first click. No listening if the ISDN side comes up. It is honestly a little bit fantastic.

And exactly because now the line is stable, I make the next big move: I prepare the router migration to Debian.

Why I want Debian on this machine

SuSE was important for me to start. Without SuSE 5.3 maybe I would not have started at that point. YaST helped, the docs were okay, and for the first ISDN phase it was practical.

But after some time I notice that what I really like is the direct config file side. I want less distribution magic, more plain files, more package control in a way that feels simple and honest. Also many people around me speak good things about Debian, and I like the whole idea that I can install a very small base and then only add what I really need.

So I decide: the router should move to Debian. But I do not touch the production router first. I am maybe stubborn, but not that stupid.

Three floppies and a network

The install is very nice in a nerd way. No CD install. No glossy thing. Just floppies and network.

For Potato I use three 1.44 MB floppies:

rescue
root
driver

I use the compact boot flavor because it already has the common network cards I need. That means I can boot the machine, get network on it, and pull the rest directly from a Debian mirror through the internet.

This is one of these moments where the technology itself already feels good. The install method is small and direct. It matches what I want the router to be.

The target machine for the first Debian install is not the Cyrix router. It is a spare 486 I have lying around. Slow, but enough for testing. I want the whole new system ready somewhere else before I touch the real edge machine.

The 486 boots from floppy, asks the normal questions, then I configure the network and point it to a mirror. The packages come over DSL. This is maybe the first time where I really feel the DSL in a practical admin task: network installation is not painful anymore. It is still not super fast, but it is completely realistic.

First priority: does DSL work on the 486?

Before I care about LAN services, before DNS, before any comfort stuff, I want one proof: can this new Debian box take the DSL cable, boot, and come back with internet?

So after the base install and the PPPoE setup I take the DSL cable and put it into the 486 test machine. Then reboot.

This reboot test is important for me. A lot of things work once when you configured them half by hand in a hurry. I want to know if it survives a cold start and comes back alone.

It does.

The 486 boots, PPPoE comes up, the route is there, internet works. I reboot one more time because I do not trust success if I only saw it once. Same result. At that moment I know the migration is realistic.

The Potato package set I use

I keep it simple. This is a router, not a kitchen sink.

For the local infrastructure I install these important things:

bind8 (BIND 8.2.3)
dhcpd from ISC DHCP 2.0
Squid 2.2
the PPPoE package/tools
normal network admin tools

For the firewall I stay with ipchains because Potato is still kernel 2.2 land for me. iptables is not the topic here yet.

This is okay. The line is DSL now, but the firewall story is still 2.2 generation. I do not mind. First I want a stable router. The newer firewall framework can wait.

The detailed LAN-service part became its own small project already, so I write that separately: DHCP, bind8, Squid, Adzapper, and the annoying testing while the old router is still alive on the same LAN. That part is not hard in one big dramatic way. It is hard in fifteen little annoying ways.

So for this note I keep the focus on the migration shape itself:

Debian install by floppy and network
DSL check on the 486
package set ready
disk prepared for the real box

Why I am doing the disk swap instead of just swapping machines

The final plan is simple: when all is done on the 486, I take that disk and put it into the real router box, the Cyrix Cx133.

The reason is practical. The Cyrix box is the better final hardware. More RAM. Better fit for Squid and general comfort. The 486 is only the preparation table.

So the 486 is not the new router. It is the place where the new router disk is born.

I like this method because it keeps the dangerous experimentation away from the live edge machine. The production router can keep running until the new disk is ready. Only then do I touch the real box.

I think this is maybe the first time I do a migration in a way that feels half-professional.

The part which still decides everything is whether the LAN services are really boring enough. DSL on the 486 is only the first proof. The second proof is whether clients get addresses, names resolve, and the proxy does not behave stupidly. If that part is still shaky, then the disk stays in the 486 for more testing.

Next step is then the real swap. If all goes well, Debian boots in the Cyrix box and nobody in the LAN notices more than one short outage.

Getting the LAN Services Right: dhcpd, bind8, Squid and Adzapper

Mon, 20 Aug 2001 00:00:00 +0000

The DSL line is there now and the Debian box on the 486 can already boot and go online. That was the first important check. But that alone does not make it a real router replacement.

The real pain is not only getting one machine online. The real pain is making one machine useful for the whole LAN.

This is the part where a lot of nice migration ideas die. One machine can route, yes, but does it really replace the old box? That means:

clients must get addresses
clients must resolve names
web must go through a proxy if I want the same traffic saving as before
and all this must survive reboot

Only then it is serious.

So this is what I do now on the Debian Potato install on the 486. The disk is still in the 486. The Cyrix Cx133 is still the production router. The old machine is still serving the flat. This is good because it gives me space to break things on the 486 without immediately making everybody angry.

First I want the boring things

I noticed already some time ago that good router work is mostly boring work.

The exciting things are:

first successful dial
first firewall rules
the syslog hack
the DynDNS update

But the part which decides if people trust the router is boring:

DHCP must just work
DNS must just work
Squid must just work

If these things fail, then nobody cares how clever the rest is.

So my goal with the 486 is not elegance. The goal is: one by one make the LAN services boring.

dhcpd: the service which becomes annoying because the old router is still alive

I install dhcpd from the Potato package set, which means ISC DHCP 2.0 generation. The config itself is not very exotic. One subnet, one range, one gateway, one resolver.

Something small like this:

default-lease-time 600;
max-lease-time 7200;

subnet 192.168.42.0 netmask 255.255.255.0 {
  range 192.168.42.100 192.168.42.140;
  option routers 192.168.42.254;
  option domain-name-servers 192.168.42.254;
  option domain-name "home.lan";
}

Nothing special. The problem is not the syntax. The problem is that there is already another dhcpd on the network: the one on the current production router.

So now I have the classic transition-phase nonsense:

the new router should answer
the old router must keep serving the LAN
but if both answer, testing becomes stupid

At first I try to be clever. I think maybe I can just test with one client and time it right. That is not nice. Sometimes the old one answers first, sometimes the new one, and then the result is unclear and I get angry at the wrong machine.

After that I stop pretending and just do it properly. For a test window I disable dhcpd on the old router, then I bring up dhcpd on the 486 and check one client cleanly. That is much better. The client gets:

address
gateway
resolver

and then I know at least that the DHCP part itself is correct.

This was a little more hassle than I expected, but it also showed me again that migration work is very often not about software difficulty. It is about two valid systems existing at the same time.

bind8: keep it boring and forwarding

For DNS I use bind8, which in Potato is BIND 8.2.3. I do not want to make anything fancy from it.

No authoritative zones.
No big internal DNS kingdom.
No strange split-horizon ideas.

I only want:

clients ask the router
the router forwards to upstream resolvers
answers get cached

That is enough.

The config is small and I like that. A router which serves the LAN should do small things very reliably before it does big things very impressively.

The practical effect is immediately visible. When I move a test client to the 486 as resolver and start doing repeated lookups, the difference is small but nice. The first lookup goes out, the later ones are local and faster. More important than the speed is the centralization: now the router is the one place where I can see DNS behavior.

And debugging becomes simpler when one machine owns one concern.

That is maybe the general theme of this whole router story now. I keep moving functions into the router not because I want one giant monster box, but because I want one place where the edge behavior is visible and manageable.

Squid comes back, but cleaner

Squid was already a good idea in the ISDN phase. On ISDN it was almost impossible to dislike the idea of caching. If one image or one stupid page element comes a second time through the line, then I want it local.

On DSL the pressure is smaller, but I still want the proxy. Partly for cache, partly for control, partly because I just like the idea that the router can shape traffic a little bit instead of only forwarding it.

Potato gives me Squid 2.2 and that is fine.

The basic proxy setup is not the hard part. The hard part is always the tiny things:

browser config on test clients
access rules
cache directory init
making sure the daemon really starts on boot and not only when I am standing next to it

After some tries it works. Pages load through the proxy and repeated fetches feel good. Then the funny extra comes back.

Adzapper is still one of my favourite things

I know Adzapper is not some deep engineering masterpiece, but I still like it a lot.

It does exactly the kind of practical thing I enjoy:

one small tool
put in the right place
removes a lot of stupid traffic and ugly banners

When it works, the browser gets the page, but where there used to be a banner or other useless graphic, there is now a placeholder image saying “This ad zapped”.

Perfect.

This is useful in three ways at the same time:

less traffic
cleaner pages
a visible sign that the proxy is really doing something

And honestly the third point is maybe the one I enjoy most. A cache is invisible most of the time. Adzapper is visible. It says: yes, the router is not only passing traffic, it is protecting me from some nonsense too.

I install it and immediately like the result again. On ISDN it directly saved connection time and almost directly money. On DSL it still saves bandwidth and makes browsing less ugly.

The web is not getting better by itself, so I do not feel guilty doing this at all.

Testing order matters

At some point I write a checklist because without one I start jumping between services and then I lose the clear state.

My testing order becomes:

DSL up after reboot
local interface up
dhcpd lease works
DNS forward/cache works
Squid proxy works
Adzapper visibly works
second reboot
test again

The second reboot is important. Too many things work once because the admin is standing there. I want it to work when nobody is standing there.

That is maybe the difference between “nice evening success” and “router success”.

The 486 as preparation table

By now I am completely convinced that the 486 is the right preparation machine for this migration.

If I had tried to do all this directly on the production router, I would already hate myself by now.

Because then every DHCP mistake means:

no client gets a lease
DNS becomes unclear
web breaks
and the whole flat knows about my learning curve

On the 486 it is different. The mistakes are still annoying, but they are private mistakes first. That is much better.

Also, it gives me the nice psychological effect that the new router already exists before the swap. The disk already has a personality. The services already exist. The machine already behaves like the new router. The final swap is then more hardware logistics than system creation.

What is still missing before the swap

Even now I do not want to rush it.

Before I move the disk to the Cyrix box, I still want:

one more cold boot test
one clean DHCP test with the old router quiet
one browser test with Squid and Adzapper on more than one client
one simple long-running check that nothing stupid dies after two hours

Only then I will trust it enough.

The migration itself is actually the smaller dramatic action. The bigger question is whether all these little LAN services are really boring enough.

And I think that is where the real router quality lives.

The syslog hack was more exciting.
The first ISDN dial was more exciting.
The first stable DSL sync was more exciting.

But this part is maybe more important.

Because when the disk finally goes from the 486 into the Cyrix box, I do not want a nice Debian install. I want a real replacement for the old router.

That is now very close.

My D-Channel Syslog Hack and DynDNS Update for the Home Router

Sun, 09 Apr 2000 00:00:00 +0000

Now I have one of my favourite hacks on this router.

The problem was simple: when I am not at home and the line is down, I still want a way to make the box go online. I do not want to call home, let somebody pick up, log in somewhere, and then maybe start the connection. I want a stupid simple trick. If I call the home number, the box should see that and bring the line up.

But I do not want the caller to pay for the call. That was important for me. The whole trick should work before the call is really answered.

What the D-channel gives me

With ISDN the D-channel signal comes before the B-channel is really used for the actual call. isdn4linux logs things about incoming calls into syslog. When I noticed that, I got the idea that maybe I do not need some big elegant callback solution. Maybe I can just watch the logs.

This is exactly what I do.

I write a small bash script. I am not some shell master. My bash is honestly very small. But for this I only need a few things:

tail -f
grep
a loop
isdnctrl dial ippp0
also one wget call

That is enough.

The very small ugly core

The script watches /var/log/messages all the time. When an incoming-call line from i4l appears, the script checks if the caller number is one of my allowed numbers. If yes, it triggers the internet connection.

Something like this:

#!/bin/bash
ALLOWED="0301234567 01701234567"

tail -f /var/log/messages | while read line; do
  echo "$line" | grep -q "i4l.*incoming\|isdn.*INCOMING" || continue
  caller=$(echo "$line" | grep -o '[0-9]\{6,11\}' | head -1)
  ok=0
  for a in $ALLOWED; do
    [ "$caller" = "$a" ] && ok=1
  done
  [ $ok -eq 0 ] && continue
  /usr/sbin/isdnctrl dial ippp0
  sleep 8
  /usr/bin/wget -q -O - "http://example-dyns.invalid/update?host=myrouter&pass=secret"
done

This is not art. This is not software engineering beauty. But it works.

When I call the home number from my mobile or from somewhere else, the phone rings, but nobody answers. So the caller does not get charged. The router already sees enough from the D-channel and starts the dial. Then after a few seconds it uses wget to push the fresh public IP to a small web server and to a dyns provider. The dyns name now points to the current address.

For me this is so good because it is made from almost nothing. Just log file watching and a few commands.

Why the dyns update matters

The line does not have a permanent public IP. So it is not enough to only bring the connection up. I also need to know what the new address is or have some name that points to it.

The second part of the hack is therefore the wget update.

I push the address to two places:

one tiny helper page on a web server I have access to
one dyns provider with a made-up service name and simple update URL

The dyns side is the practical one. If it updates correctly, then I can use the hostname from outside and I do not care what IP I got this time.

The helper page is more for me. I can look there and check if the update happened and which address was sent.

Small problems with this solution

Of course it is not all perfect.

First, the exact i4l log format is not always the same. One version writes a line slightly different than another one. So I try a few grep patterns until it catches the right thing and not random noise.

Second, if the syslog watcher dies, then the trick is dead. So I put it in a small restart loop. Primitive, but enough.

Third, timing is a bit ugly. If I call and hang up too fast, sometimes the script catches it, sometimes not. If I let it ring a bit longer, it is more reliable. So I learn how long I need to let it ring.

Fourth, wget should not run too early. First the line must be really up. So I just sleep some seconds before the update call. This is exactly the kind of ugly timing thing which I do not love, but it is still better than no solution.

Why I like this hack so much

I think the reason is: this is one of the first times I make the machine do something clever only with things I already have.

No new hardware. No expensive software. No giant daemon. No telephony box.

Only:

Linux
syslog
bash
i4l log messages
one wget

This is the style of solution I really enjoy. It feels a bit improvised, yes, but it is also very direct. The machine says what happens in the log, I listen to it, and I react.

Also it makes the router suddenly feel more “alive”. It is not only a passive box anymore. It reacts to the outside world in a small smart way.

Other changes around this time

I also moved the router from SuSE 5.3 to SuSE 6.4 by now. That means kernel 2.2 and ipchains instead of ipfwadm. This is good for the LAN side because helpers like ip_masq_ftp are there and some ugly protocol stuff becomes less ugly.

So the box now looks already more grown-up than in the first phase:

SuSE 6.4
kernel 2.2
ipchains
ISDN dial on demand
syslog trigger hack
dyns update with wget

And still the DSL modem LED is blinking.

I think this is the most absurd thing: the software side gets more and more finished while the modem still sits there and says “not yet”.

Next things I want

The next obvious step is more local services.

I want:

local DNS caching
maybe DHCP from the router
maybe a web proxy because the line is still not exactly fast
some ad filtering because web pages are getting more annoying and bigger

Especially the proxy idea is attractive. If the same stupid banner loads ten times, then I pay for the same stupidity ten times. This is not acceptable.

So probably the next article is about making the LAN side more comfortable and maybe a bit less wasteful.

Making ISDN Dial-On-Demand Work with SuSE and ipfwadm

Sun, 14 Feb 1999 00:00:00 +0000

Now the box is not only booting, it is doing useful work.

I still have the DSL hardware connected, but the modem LED is still blinking and not stable. So this means: the real life is still ISDN. But because of the T-Online/DSL package I can already use ISDN for internet without this old fear of counting every minute too hard. That makes it much more realistic to really use the Linux router every day and not only as some weekend test setup.

The main thing I wanted was dial on demand. I do not want the machine online all the time if nobody uses it. Also I do not want manual dial each time. The right thing is: local machine sends packet, router notices it, line goes up, internet works. Later, when no traffic is there anymore, the line goes down again.

In theory this sounds very logical. In practice it takes me enough evenings.

ipppd and the general direction

The important parts for me are isdn4linux and ipppd. isdn4linux does the low-level ISDN side and ipppd does the PPP part. After reading enough HOWTO text and trying enough wrong settings I end up with a setup that is at least understandable.

The main config is not beautiful, but it is mine:

# /etc/ppp/options.ippp0
asyncmap 0
noauth
crtscts
modem
lock
proxyarp
defaultroute
noipdefault
usepeerdns
persist
idle 300
holdoff 5
maxfail 3

The important line for me here is idle 300. Five minutes. That means if there is no traffic for five minutes, the line goes down again. This feels practical. Long enough that browsing is not annoying. Short enough that the box is not just hanging online forever.

The actual dial and hangup I bind to isdnctrl:

`1`	`/usr/sbin/ipppd file /etc/ppp/options.ippp0 connect '/usr/sbin/isdnctrl dial ippp0' disconnect '/usr/sbin/isdnctrl hangup ippp0' ippp0`

When it works the result is nice. First request is a bit slow. The line comes up. Then surfing feels normal enough for that time. Mail works. IRC works. FTP works if it behaves.

The first-click effect

One thing is always there and I think everybody who does this knows it: the first click is special.

If the line is down and a browser tries to fetch a page, sometimes the first request times out before the line is really ready. Then the user clicks reload and now it works because the link is already up. So I keep telling people in the flat: if the page does not come on first try, just click again, the router is maybe still dialing.

This sounds stupid, but after a week everybody knows it and then it is just normal life.

Kernel 2.0 means ipfwadm. I already heard about ipchains and I would like to try it, but on this box I am still on SuSE 5.3 with the 2.0 kernel, so for now it is ipfwadm. The syntax is not exactly poetry, but it works.

I use masquerading so the local machines can share the one connection. Internal side is private addresses, router has the public side via ISDN, and packets get masked on the way out.

Minimal direction looks like this:

1
2
3

echo 1 > /proc/sys/net/ipv4/ip_forward
ipfwadm -F -p deny
ipfwadm -F -a m -S 192.168.42.0/24 -D 0.0.0.0/0

That is not the full ruleset, only the basic idea. I keep the real script in /etc/rc.d/ and comment it because otherwise I forget the arguments in one week.

I like that with Linux 2.0 one can still see the whole moving pieces without too much abstraction. On the other hand, things like FTP quickly show where the limits are.

FTP and the small pain of old protocols

Passive FTP is mostly okay. Active FTP is not so nice. With ipfwadm and this generation there is no good helper for it. So active FTP can fail in stupid ways and then you start thinking maybe you broke the router, but in fact the protocol is just doing protocol things.

After some evenings I decide the simple rule is this: use passive FTP when possible and do not lose time with trying to make old protocol design look smart.

That is maybe the first moment where running a router teaches me something bigger than command syntax. Many network problems are not Linux problems. They are protocol problems, software expectations problems, or user expectation problems.

T-Online and general line feeling

The provider side is okay most of the time. Sometimes the line drops for no reason I can see. Sometimes authentication fails once and works on the next try. I keep notes because otherwise every error starts to feel mystical.

I think this is one important habit I get from this box: write down what happened. Time, symptom, what I changed, what worked. Without this, three evenings of problem solving become one big confused memory.

The machine itself

The Cyrix Cx133 is doing fine. I already moved it to 16 MB and this helps a lot. 8 MB was really not much. Right now the box is still in the lean stage. No big extra services. Just enough to route and share the line.

The Teles card still needs respect. If something goes weird, I first check cable and card state before I start blaming PPP. This saves me time.

What already feels good

Even now, before DSL is really there, the setup already feels worth it.

one box for the internet edge
shared connection for local machines
line comes up only when needed
config files which I can read and change
no dependency on one desktop machine being on

This is already much more “real systems” feeling than just installing Linux on a PC for trying around.

I still want more from the box. I want DNS cache. I want maybe a proxy. I want some cleaner way to wake the line from outside. Right now if I am not at home and the line is down, then it is down. That is the next problem I want to solve.

Also the DSL modem is still blinking. It is almost becoming decoration.

My First Linux Router: SuSE 5.3, Teles ISDN and the Blinking DSL Modem

Sat, 03 Oct 1998 00:00:00 +0000

I wanted to start with Linux already earlier, but I did not. One reason was VFAT. I had too much DOS and Windows stuff on the disk and I did not want to make a big break just for trying Linux. Now SuSE 5.3 comes with kernel 2.0.35 and VFAT support is there in a way that feels usable for me, so now I finally do it.

Also I have enough curiosity to break my evenings with this, and enough little money to make bad hardware decisions and then keep them running because there is no budget for the nice version.

The machine for the router is a Cyrix Cx133. Not a fancy box. Right now it has 8 MB RAM and a 1.2 GB IDE disk. The case looks like every beige case looks. For a router it is enough. It boots. It stays on. It has one job. If I find cheap RAM later I will put it in, but first I want the basic thing working.

For ISDN I do not buy AVM because I simply cannot. Everybody says AVM is the good stuff and the drivers are nice and all is more easy. Fine. I buy a cheap Teles 16.3 PnP card. It is not the card of dreams, but it is my card and I can pay it. So the project now is not “what is best”, it is “what can be made to work with Teles and a bit stubbornness”.

At the same time there is already the whole T-DSL story from Telekom. This is maybe the funny part: I already subscribe to the DSL package together with T-Online, but the line is not switched yet. They give us the hardware. The DSL modem is there. The splitter is there. Everything is there. I can look at the modem and I can connect it and the LED is blinking and blinking and blinking. But there is no real DSL sync yet. It is like the future is already on the desk, only the exchange in the street does not care.

The good thing in this package is: I can already use ISDN with the same flatrate model through T-Online until DSL is finally active. That changes everything. If I had to pay every minute like in the older ISDN situation, I would maybe not do such experiments so relaxed. But with this package I can prepare the whole router now, use it now, put the DSL hardware already in place, and then just wait until someday the blinking LED becomes stable.

This is maybe a bit absurd, but also very german somehow: contract ready, hardware ready, paperwork ready, technology almost ready, and then the actual line activation takes forever.

Why I want a real router box

I do not want one Windows machine doing the internet and all other machines depending on that. I also do not want manual dial each time. I want a separate machine which is just there and does the gateway work. If it works good, nobody sees it. If it breaks, everybody sees it. This is exactly the kind of thing I like.

Also I want to learn Linux not only as desktop. Desktop is nice, but for me the interesting thing is always when one machine does a service for other machines. Then it gets serious. Then configuration is not decoration anymore.

The first setup is simple:

Cyrix Cx133 as the router
Teles 16.3 for ISDN
one NE2000 compatible network card for local LAN
SuSE 5.3
T-Online account
DSL hardware already connected, but DSL itself still sleeping somewhere in Telekom land

The LAN side is eth0. The ISDN side I will configure through the i4l tools once the login part is really clean.

Installing SuSE 5.3

SuSE installation feels big for a student machine because there are so many packages and YaST wants to help everywhere. But I must say, for this use case it is really practical. I do not want to compile every tiny thing right now. I want the machine up and then I want to start reading config files.

The nice thing is that SuSE 5.3 already has what I need for this direction:

kernel 2.0.35
VFAT support, finally good enough for me to jump in
isdn4linux pieces
YaST for basic setup
normal network tools and PPP stuff

The first days are not so elegant. I reinstall once because I partition stupidly. Then I configure the network wrong and wonder why nothing routes. Then I realize that reading the docs before midnight is much more productive than changing random options after midnight.

Still, the feeling is strong: this is possible. The machine is not powerful. The card is not luxury. But Linux is not laughing about the hardware. It takes the hardware seriously and tries to use it.

The Teles card and the small pain around it

The Teles 16.3 works, but not like a nice toy. It works like something you need to deserve first.

PnP is not really my friend here. Auto-detection is sometimes correct and sometimes not. I get into the usual dance with IRQ and I/O settings, and because the NE2000 clone is also not exactly a model citizen, I must be careful there are no collisions. When it finally stabilizes, I write down the values because I know I will forget them if I do not.

The card sits on S0 bus with a passive NT. That setup is physically very small. Short cable is important. At first I use a longer cable because it is just the cable I have on the desk. Then I get strange effects. D-channel sync comes, then some weird instability. I shorten the cable and suddenly the whole thing becomes much less dramatic. From this I learn again the old rule: with communication stuff, physical layer problems are always more stupid than the software problems.

When the ISDN side starts to work the feeling is really good. No modem noise. No analog nonsense. Digital and clean. I know 64 kbit/s is not much in the abstract, but compared to normal modem life it feels fast enough that one can do real things.

The strange situation with the DSL modem

The modem is already on the desk and it is maybe the best symbol for this whole phase. I already have the new thing. I can touch it. I can cable it. I can power it. But it is not mine yet in the practical sense, because the line in the exchange is not enabled.

So what happens is: I install the splitter, I connect the modem, I look at the LED, and it blinks. Every day it blinks. It is almost funny. It is like the house has a small promise lamp.

Because we already have the package, I can connect with ISDN under the same general tariff model and prepare everything. This is really useful. It means the whole router is not a waiting project. It is a live project from day one. The DSL modem is there as a future device, but the machine is already useful now through ISDN.

This also changes my mood when building it. I am not making a theoretical future router. I am making a real working box. If Telekom ever finishes the outside part, then maybe the uplink can change without rebuilding the whole idea from zero.

What I have running now

At this moment I keep it simple. I am still mostly happy that Linux is on the box and the basic line can come up. The stack is not fancy yet. It is more like this:

SuSE 5.3
isdn4linux
T-Online login
local Ethernet
a lot of notes on paper

I already know I want these things later:

dial on demand
IP masquerading for the LAN
maybe DNS cache
maybe Squid if memory allows it
and if DSL finally comes, then PPPoE and the same box continues

I do not know yet which part will be the most annoying. Right now I guess the Teles card. Maybe later I will say PPP is worse. Maybe both.

For now I am just happy that Linux finally starts for me with a version where VFAT is not a blocker anymore, the cheap ISDN hardware is usable, and the blinking DSL modem already stands on the desk like a small challenge.

Maybe next I write more when the dial-on-demand part is not so ugly anymore.