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.

Dial-on-Demand on TurboVision