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
the dialmodes) then the interface will automatically trigger a dialout when it
receives ip packages. (This means that any user can trigger a
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.
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.
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:
-broadcastto keep from opening connections in this way. You can recognize this one when you have a dialout, but no data is transferred.
route add/del defaultin ip-up/ip-down with it.
manual(see question dialout_dialmode). Then use
isdnctrl dial <device>to dial out, and
isdnctrl hangup <device>to hangup.
ip-down. Then dialouts will only be possible once after setting dialmode to
/sbin/route del default /sbin/isdnctrl system off /sbin/ifconfig ippp0 down
/sbin/isdnctrl system on /sbin/ifconfig ippp0 up /sbin/route add $GATE-IP dev ippp0 /sbin/route add default ippp0
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:
OPEN: 220.127.116.11 - 18.104.22.168 TCP, port: 1686 - 540In this example, our computer is trying to pick up mail on port 540 (UUCP over TCP/IP over ISDN) - the port number can be looked up in
/etc/services. Please note: only the triggering packet will be logged.
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:
Use DNS for Windows Names Resolutionon all Windows computers on your LAN.
Turn on debug level 1 in named and look at the logfile in
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.
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).
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".
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
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).
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.
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
netstat -ntthat 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
/etc/ppp/ip-up. This firewall rule drops all tcp packets
which are not in SYNSENT state. Add this in
a 2.2.x kernel:
ipchains -A output -j DENY -p tcp -i <interface> ! -y
ipchains -A output -j DENY -p tcp -i <interface> ! -y
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.