Isdn on TurboVision

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.