23. dod: Unwanted dialout on demand

23.1 What can cause a charge unit disaster?

There are several possibilities.

1. "Bridging" was compiled into the kernel (see the appropriate question below).

2. Broadcasts from the interfaces ware being forwarded by ISDN (see the appropriate question below).

3. 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... (see the appropriate question below).

23.2 Ever since I installed a new kernel, my computer constantly open ISDN connections without transferring any data (expensive!).

Maybe the kernel option "bridging" was mistakenly activated?

23.3 My router wants to constantly dial out (and does it too) but NO data is transferred, neither ipfwadm -A! nor tcpdump -i isdn0 showanything.

Michael Pieper michael@nexus1.tng.oche.de wrote on 10 Nov 1996:

ARP requests or broadcasts? You should run ifconfig with the options -arp and -broadcast to keep from opening connections in this way.

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

Gernot Zander hifi@scorpio.in-berlin.de wrote on 18 Jan 1997:

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.

23.5 How can I safely turn off dialout on demand?

Gernot Zander hifi@scorpio.in-berlin.de wrote on 10 Jan 1997:

I delete the telephone number of the interface (or set an invalid one - Ed.) Then I can see right away from the complaints in the syslog whether a process wants to send packets out to the world.

Sascha Ottolski sascha@alzhimer.isdn.cs.tu-berlin.de added on 28 Oct 1996:

For me, what is happening is what you want: the ISDN system is "down", Netscape immediately shows an error message a la: "the Server doesn't have a DNS entry" or something similar. You probably have to delete the route so that this will happen. I do it like this:

/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

23.6 How else can I prevent the charge unit disaster?

In the next version of isdnlog (2.52) it will be able to work as a watchdog and prevent such dialouts (with a reboot, if necessary).

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

Karsten Keil keil@temic-ech.spacenet.de wrote on 11 Feb 1997: I'm guessing, that with the status enquiry (in Switzerland - Ed.) you simply want to make sure that when the user side has crashed, the connection is broken. This is in addition to the Layer 2 monitoring and is not totally senseless, since with many cards/end devices the ISAC is run in auto mode and therefore a crash would keep the connection open.

However, i4l runs the ISAC in nonauto mode, meaning that when interrupts are no longer being process, the connection is broken after a maximum of about 1/2 a minute. This is not the reason for using nonauto mode, but this is a safety feature ;-), but doesn't mean that the charge unit disaster is impossible.

23.8 How can I track down unexplainable dialouts?

Dirk Lutzebaeck lutzeb@wadk-berlin.de wrote on 5 Nov 1996:

Unfortunately, I don't know of any syncPPP encapsulation patch for tcpdump. If you use ipppd, then your only chance is to turn off one daemon after the other and see if things have finally quieted down. Likely candidates are named, sendmail, and also smbd (Samba) that are likely to open connections.

I too was only able to find this out by killing suspicious processes. More information on the search for these processes and how to make them quit can be found at: http://www.fzi.de/sim/people/trautw/i4l/index.html

Try to find out which lookup triggers the connection with "isdnctrl verbose 3". Then a message should appear in the kernel message queue (visible with "dmesg") a'la: OPEN: 141.76.60.54 - 193.171.67.253 TCP, port: 1686 - 540 In this example, our computer is trying to pick up mail on port 540 (UUCP over TCP/IP over ISDN).

Stefan Luethje luethje@sl-gw.lake.de wrote further on 27 Nov 1996:

Another tip. There are a lot of daemons on the Linux side that broadcasts on all interfaces. This leads to frequent autodials. In this case you can redirected the broadcast address to the dummy0 interface. It's not clean, but it works.

23.9 Can it be that the Win95 machine on my LAN is causing automatic dialouts?

Stefan Luethje luethje@sl-gw.lake.de wrote on 27 Nov 1996:

If in Wintel the name server of your provider is given, and Windows 3.11/95 is started, then it has to talk to the name server (only Bill Gates knows why).

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

Jens Ey jens@jeyhh.shnet.org wrote on 29 Nov 1996:

Turn on debug level 1 in named and look at the logfile in /var/tmp.

In my case, I found regular DNS requests from Windows machines. The problem was that names like WORKGROUP.domain.de were requested, i.e. names that the DNS could not know. I'm assuming that the Windows machine was looking for its master browser or a domain controller.

This was causing me so many problems for my Internet connection with Linux in a LAN that I installed an external terminal adapter, set up a proxy server, and set up diald that only DNS requests from the Linux machine were allowed to be carried out. Then the connections are established only when they are actually needed. The (caching) local DNS is only used after the connection has been established.

23.11 How can I turn off the DNS requests for WORKGROUP.xxx from my Win95 machine?

Eike Stepper isdn@esc-net.de wrote on 30 Nov 1996:

Why not simply set the "Use DNS for Windows Names Resolution" (or similar) to No? Then it should be quiet, at least it is for me.

23.12 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".

23.13 The samba package always triggers dialouts for me. How can I prevent this?

Andreas Glahn andreas@tao.westfalen.de wrote on 31 Jan 1997: I had this problems too. Then when starting the samba daemon I gave it the internal IP address I use here at home. Since then a samba request is no longer sent to default, but stays here.

Take a look at the configuration with netstat and tcpdump. With tcpdump you can quickly find out to which IP address samba is trying to connect.

My internal Linux computer has, e.g.: 192.168.99.99

My Win95 computer: n 192.168.99.88

On the Linux computer I started samba with:

nmdb -S -B 192.168.99.255 -I 192.168.99.99

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

A proxy should not cause a dial out, even when the complete name is entered. Only when a new proxy is given does Netscape do a DNS lookup (and in this special case cause a dialout. However, on 17 Mar 97 Steffan Henke henker@Informatik.Uni-Bremen.DE wrote:

Unfortunately reality has caught up with us. I've heard that Netscape now in version.4.02 really does establish a connection...

23.15 trouble_tcpdump: Why does my tcpdump not work for ip packets going over ISDN? How can I get a tcpdump patched for ISDN?

Michael Stiller michael@toyland.ping.de wrote on 23 Oct 1996:

Tip for ftp:

ftp://ftp.gwdg.de/pub/misc/isdn/linux/isdn4linux-gwdg

There is the patch: "tcpdump-3.0.4-1-isdn.dif.gz"

and the rest is at:

/pub/linux/mirrors/funet/PEOPLE/Linus/net-source/tools/tcpdump-3.0.4-1.tar.gz

You might need to hack some, depending on the name of your ISDN interface (mine is bri0). By default, it recognizes only isdn* and isdnY* as interface names.

Henning Schmiedehausen henning@pong.iconsult.com further wrote on 30 Oct 1996:

After finding the patch from Eberhard Moenkeberg at ftp.gwdg.de cannot dump cisco HDLC, I made my own patch for tcpdump-3.0.4 that asks the interface which encapsulation it used and sets itself accordingly. The patch is against a tcpdump-3.0.4-1.tar.gz distribution, for example at

This patch recognizes rawIP, ISDN-IP and CISCO-HDLC and can dump these packets.

Sascha Ottolski sascha@alzhimer.isdn.cs.tu-berlin.de gave the following tip on 5 Nov 1996:

This is a isdn4k-utils-2.0/tcpdump-3.0.3-isdn.diff ! It work, if one makes some changes: In the file tcpdump-3.0.3-isdn/libpcap-0.0/pcap-linux.c after patching you find the following: else if (strncmp("ppp", device, 3) == 0) Either you name your ppp devices pppX instead of ipppX, or change this line, e.g. else if (strncmp("ippp", device, 4) == 0) ^^^^ ^^ Then tcpdump will also recognize syncPPP. At least it does for me.