Next Previous Contents

22. dod: Unwanted dialout on demand

22.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 config_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.

22.2 dod_causes: What can cause a charge unit disaster?

There are many possibilities.

  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-Revoking patch, which has found its way into the 2.0.x kernels, but not into 2.1/2.2/2.3 (see the appropriate question below).

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

  1. Set your dialmode properly (see question config_dialmode). For example, set dialmode to manual in ip-down. Alternatively you can use the dialmode feature (see question config_dialmode.
  2. 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.
  3. Switch the system off.
  4. 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.

22.4 dod_strategy: How can I track down unexplainable dialouts?

If you are using ipppd: get a tcpdump which can show data with the syncPPP encapsulation (may require a patch - see question trouble_tcpdump). Otherwise your only chance is to turn off one daemon after the other and see if things have finally quieted down. named, sendmail, and also smbd (Samba) are likely candidates to open connections (see the following questions).

Christoph Trautwein trautw@fzi.de added on 5 Nov 1996:

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 quite can be found at: http://www.fzi.de/sim/people/trautw/i4l/index.html
Herbert Rosmanith herp@wildsau.idv.uni-linz.ac.at added on 24 Nov 1996:
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).
Please note: only the triggering packet will be logged.

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.
See all the last question in this section.

22.5 dod_win95: 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).

22.6 dod_localdns: 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.

22.7 dod_win95b: 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.

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

22.9 dod_samba: 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

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

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

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

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

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.

22.12 dod_openlineoncrash: 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.


Next Previous Contents