Next Previous Contents

16. dod: Unwanted dialout on demand

16.1 dod_how: How does dialout on demand work?

After you habe set up a network interface, and defined a route to it, then all ip packages will be routed to this interface. If the autodial mode has been enabled (see question dialout_dialmode on the dialmodes) then the interface will automatically trigger a dialout when it receives ip packages. (This means that any user can trigger a dialout.)

Example: You open a browser with no or a local homepage. Nothing happens. You enter some url to connect to, this will send ip packages to the network interface - thereby triggering a dialout.

Using dial on demand is a potentially dangerous (means expensive) feature: see question dod_disaster.

16.2 dod_disaster: What is a charge unit disaster?

The charge unit disaster can happen for many reasons (see question dod_causes for more details). However the results are identical: your computer dials out to your Internet Provider more often than you want, thereby increasing your telephone bill by a large amount (especially when you are not only charged for time online, but also a minimum amount/charge unit for every dialin). The term 'large amount' is rather flexible. Anything is possible:

This is no joke, and all these things have actually happened, even to real isdn4linux experts! See question dod_off on how to avoid any risk of this happening to you.

16.3 dod_causes: What can cause a charge unit disaster?

There are many possibilities. See question dod_strategy on how to track down what is happening to you. See question dod_disaster on how expensive that could be. Here a non-comprehensive list of causes:

  1. You compiled your kernel with the option Bridging by mistake.
  2. ARP requests or broadcasts? You should run ifconfig with the options -arp and -broadcast to keep from opening connections in this way. You can recognize this one when you have a dialout, but no data is transferred.
  3. Other Broadcasts from the interfaces were being forwarded by ISDN.
  4. If IP connections are still open with the line is disconnected and IP addresses are dynamically assigned, then the disaster is inevitable. Then a new connection is started to bring down the open IP connections, which fails because the IP address is now different. The line is hung up, but the IP connections are still open, the line is dialed again, and so on... This can only be avoided with the RST-provoking mode (see question dod_rstprovoking. A patch for it may be needed if it is not included in your distribution. The patch had found its way into the 2.0.x kernels, but not into 2.1/2.2/2.3. However, you can get an adjusted patch for 2.2.x kernels and some background information about it from: http://www.another.de/linux/router/. See also question syncppp_1stpacket. Also make sure to use ipppd's "defaultroute" option rather than route add/del default in ip-up/ip-down with it.
  5. TCP retries trigger dialout: when the kernel tries to send tcp packets and does not receive any answer, then it will retry to send them (usually every 120 seconds). Check out whether you want to adjust the following parameters: Documentation can be found in /usr/src/linux/Documentation/proc.txt.
  6. Requests from your local DNS trigger a dialout: see question dod_localdns.
  7. Sendmail triggers the dialout: see question dod_sendmail.
  8. Windows 95 clients trigger the dialout: see questions dod_win95, dod_localdns, and dod_win95b.
  9. Samba triggers the dialout: see question dod_samba.
  10. Netscape triggers a dialout when started: see question dod_netscape.
  11. dhcpd triggers dialouts: switch it off, and verify your configuration...
  12. Manually close IP connections which are still open when the line goes down: see question dod_closeipconnect.
  13. Your computer is crashed, but still processes interrupts: see question dod_onlineoncrash.

16.4 dod_off: How can I safely turn off dialout on demand?

  1. To always dial out manually, set your dialmode to manual (see question dialout_dialmode). Then use isdnctrl dial <device> to dial out, and isdnctrl hangup <device> to hangup.
  2. Set your dialmode properly (see question dialout_dialmode). For example, set dialmode to manual in ip-down. Then dialouts will only be possible once after setting dialmode to auto.
  3. Delete the telephone number of the interface, or set an invalid one. Then you can see from the complaints in the syslog whether a process wants to send packets out to the world.
  4. Switch the system off.
  5. Delete your route to the ISDN device. For example, to disable any automatic dialouts:
    /sbin/route del default
    /sbin/isdnctrl system off
    /sbin/ifconfig ippp0 down
    

    To get things running again:
    /sbin/isdnctrl system on
    /sbin/ifconfig ippp0 up
    /sbin/route add $GATE-IP dev ippp0
    /sbin/route add default ippp0
    

    The latter method has the disadvantage that dialin is then no longer possible.

16.5 dod_strategy: How can I track down unexplainable dialouts?

Finding the reason of unexpected dialouts is the first step to stopping it. However, finding is usually more difficult than fixing the problem. This is what you can do to track it down:

16.6 dod_winclient: Can it be that the Win95 machine on my LAN is causing automatic dialouts?

Yes. When Windows 3.11/95 is started, then it tries to talks to the name server of your provider (if known), trying to look up some domains (e.g. WORKGROUP.xxx). To avoid this, these are your options:

16.7 dod_localdns: I have set up a local DNS name server. Why does it cause unwanted dialouts? How can I find the cause?

Turn on debug level 1 in named and look at the logfile in /var/tmp. Often, you can find regular DNS requests from Windows machines. The problem is that names like "WORKGROUP.domain.de" are requested, i.e. names that the DNS could not know. Windows seems to be looking for its master browser or a domain controller (if you are fluent in German, see ct 12/99, page 224: "Schnitzeljagd - Netzwerkumgebung und Browserdienst im Windows-Netzwerk" for more details). To work around this problem, you can set up your domain name server with cname = "WORKGROUP.domain.de" (other domain names are also possible). Or set up a Primary Domain Controller within your LAN. You can also use diald to control dialouts for DNS request.

16.8 dod_forwarddns: I have set up my name server in 'forward' mode, with one forward address. Now it dials out about every minute?

From time to time, the name server will query its forwarder, which will trigger a dialout. Since your ISP uses dynamic ip addresses, the request is sent out with the wrong ip address at startup of the dial-in connection. Therefore, no answer will be received. Bind waits for one minute before resubmitting. If your line has come down in the mean time, this will trigger a new dialout, resulting in a different ip address, and so on...

For a workaround to this problem you can shorten the retransmission time as described in question dialout_bind.

Alternatively, you can set the option "dialup yes;" in the options block of named.conf. This will cause named to do only one interaction with a forwarder (triggering a dod) at startup. After that it will wait for some very long interval (24h?) before another query with the forwarder. Only during actual lookup it will do negotiations with the forwarder (this is usually when you have already dialed out anyway).

16.9 dod_sendmail: How can I get sendmail to not initiate any connections without local mail being left undelivered?

First you have to get sendmail to no long open any DNS connections. You need to activate the following features: "nodns", "nocanonify".

If you have a smarthost, you need to make sure that this name does not call the name server. You can either set it directly as an IP address, or add the name to /etc/hosts (/etc/host.conf should then contain "order hosts bind")

You should set all non-local mailers as "expensive" ("define(SMTP_MAILER_FLAGS, e)"), and then forbid sendmail with "define(`confCON_EXPENSIVE', `True')" from automatically connection to expensive mailers. The call to sendmail should no longer include a time for the "-q" option (e.g. only "-bd -os -q"). "-os" means that all mail will be queued (which won't prevent local mail from being delivered immediately). The only catch is that when booting, mail that might still be in the queue will be sent by sendmail, even though the network is not yet up. Therefore, when booting you should remove all mail from /var/mqueue before starting sendmail, and then return it once sendmail has been started.

Mail to expensive mailers will now only be send with the explicit call "sendmail -q".

16.10 dod_samba: The samba package always triggers dialouts for me. How can I prevent this?

When nmbd starts up it tries to bind to 0.0.0.0 or all interfaces, which is what triggers the ISDN dialup. The best way to solve this is to set "bind interfaces only = yes" and "interfaces = eth0" in smb.conf (in case you want to use Samba only in your LAN). Alternatively, you can give the samba daemon an internal ip address upon startup. First find out which ip address samba is trying to connect to (e.g. with netstat or tcpdump). Then start samba with:


nmdb -S -B 192.168.99.255 -I 192.168.99.99

if your Linux computer has 192.168.99.99 as ip address, and all users are in the same subnet (192.168.99.255).

See also the above question: set -broadcast and possibly -arp when defining the interfaces!

Check out the help pages for the Samba configuration file for further possibilities on preventing dialout (I was told there should be some explicit dialup parameter which prevents it to cause many dialouts).

16.11 dod_netscape: How can I get Netscape to quit initiating dialouts when starting?

Most likely in the preferences a non-local home page has been listed. Only a home page that Netscape is able to load immediately (e.g. "file://localhost/xxx") won't cause an immediate dialout. Alternatively you can also set up a cache daemon that saves pages that are often needed.

Second check your proxy settings. When giving a complete name instead of an ip address, Netscape may try to do a DNS lookup to resolve the name to an ip address on startup. In this case provide Netscape with an ip address.

Another thing is that Netscape tries to contact its news server. If you don't want to use this feature then you can enter the name Netscape uses for lookup (probably 'news') in your local DNS or in your /etc/hosts, and let it point to localhost.

16.12 dod_rstprovoking: Why should I use the RST-provoking mode/patch?

If on every dialup (in auto dialout mode) you get a different ip address (dynamic ip), and the dialup connection gets terminated (e.g due to inactivity) while some ip connections have not yet been closed, then the following problem will occur: when the program tries to close the connection this will trigger a new dialout. Since this will yield in a new ip address, the closing attempt will fail. After the timeout period another dialout will be attempted, with the same result, leading to a dial on demand disaster. To prevent this problem the RST-provoking mode has been invented. If on the closing attempt a new dialout is opened and the ip address changes, then the kernel will send a ip packet with the reset flag on. This will close down the open connection, preventing the dial on demand disaster. To activate the RST-provoking mode use the command


echo 7 > /proc/sys/net/ipv4/ip_dynaddr

Use 5 instead of 7 to prevent syslog warnings. Check the current status with:
cat /proc/sys/net/ipv4/ip_dynaddr

Your distribution may or may not have the patch for this rst-provoking mode included, it was not liked in the kernel code for kernels newer than 2.0.x.

16.13 dod_closeipconnect: After closing the line, I discover with netstat -nt that IP connections are still open. How can I close these manually?

This may only work with the RST-provoking mode (mentioned in question dod_causes): You can bring the interface "down" then back "up". When you do this, it will try to dial out. But if you have removed the outgoing telephone number, then "no outgoing number..." appears in the syslog, and as soon as the interface is "up", all connections will be closed.

You can prevent those open IP connections to trigger new dialouts if you add a special firewall rule in /etc/ppp/ip-down, and remove it in /etc/ppp/ip-up. This firewall rule drops all tcp packets which are not in SYNSENT state. Add this in /etc/ppp/ip-down for a 2.2.x kernel:


ipchains -A output -j DENY -p tcp -i <interface> ! -y

Add this in /etc/ppp/ip-up:
ipchains -A output -j DENY -p tcp -i <interface> ! -y

(As is the case for all firewall rules: it is best to put this into a separate script which is called with either a start or a stop parameter.) Please note that this firewall rule only matches whole packets, no fragments. A fragment will always bypass the firewall and trigger a dialout.

16.14 dod_onlineoncrash: Is it possible that even with a crashed computer a ISDN connection remains open (and the charge units accumulate)?

The ISAC chipset, which is in use on many ISDN cards, can be run in either auto mode, or in non-auto mode. When run in auto mode, the connection could be up when the computer is crashed (the card keeps it up and running). Since the HiSax driver uses nonauto mode, this should not happen with ISDN4LINUX. Once no interrupt is processed on your machine, the connection will stop at maximum half a minute later. Only in the unlikely event that your machine is crashed, while interrupts are still processed normally, this could happen.


Next Previous Contents