Blog

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. ... continue

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. ... continue

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. ... continue

ipfwadm is what many Linux operators run right now when they need packet filtering and masquerading on modest hardware.

In small offices, clubs, and lab networks, ipfwadm plus IP masquerading is often the first serious edge-policy toolkit that is practical to deploy without expensive dedicated appliances. It is direct, predictable, and strong enough for real production work when used with discipline.

This article stays in that working context: current deployments, current pressure, and current operational lessons from real traffic.

What problem ipfwadm solved in practice

At small scale, the business problem looked simple:

Technically, that meant: ... continue

The room is quiet except for fan noise and the occasional hard-disk click. On the desk: one Linux box, one CRT, one notebook with IP plans and modem notes, and one person who has to make the network work before everyone comes in.

That is the normal operating picture right now in many small labs, clubs, schools, and offices.

Linux networking is not abstract in this setup. You touch cables, watch link LEDs, type commands directly, and verify packet flow with tools that tell the truth as plainly as they can.

When the network is healthy, nobody notices.
When it drifts, everyone notices.

This article is written as a practical guide for that exact working mode: ... continue

Most Linux networking work right now is TCP/IP-first, but many live environments still carry IPX dependencies that cannot be ignored yet.

If you operate mixed networks, this is the practical question:

This mini article answers that question with command-oriented practice.

What matters operationally about IPX

You do not need full protocol history to run IPX coexistence safely. You need four practical facts:

The biggest risk is undocumented assumptions.

Typical Linux toolset for IPX work

... continue