Topic: Dial out call sequence

[Steve Hiner]

I have been having some strange problems running in Server and Gateway - Dialup mode.  Though I have changed crontab (the template and the "real" file) so that it will call fetchmail every 3 hours outside of business hours I have noticed that the server dials out far more often than that.  Sometimes it will dial out, stay connected for a couple minutes, hang up, then dial out again after 3 or 4 minutes - it does this in between fetchmail calls.

In order to diagnose the problem I added the following to the beginning of the fetchmail script:
        echo fetchmail+ - date >> /var/modem.log
 - and -
        echo fetchmail- - date >> /var/modem.log
to the end of the script.

This worked fine once I found out that fetchmail doesn't have permission to create a file in /var and I created one myself and fixed the permissions.

My confusion arrises because I thought ip-up and ip-down would be called as well so I added similar lines to those scripts.  However, they must not be called since they never add data to the log file.

What scripts or programs should I expect to be called and in what order for the two primary types of dial-out, fetchmail and web browsing?  I just want to be able to track when it is dialing so I can do a little troubleshoot after the fact if there is a problem.  Of course, I realize that Linux logs a lot of activity so maybe the answer is to look in /var/log/foobar.log but I didn't find anything that looked like it was loging the connect and disconnect times.

By the way, I did add a crontab entry to delete the log once a week.  Unfortunately I don't know how to just clear the log without deleting it - if I delete it then fetchmail won't have permision to recreate it.  Sorry that I am so ignorant - I am far more familiar with batch programming in DOS than I am with script programming in Linux.

Thanks for the help,
Steve Hiner

[Joseph Morrison]

Hello Steve,

To track diald going up and down, you need the ip-up and ip-down options in the /etc/diald.conf file. For more details, type "man diald" at the root prompt.

You can also use the command:

tcpdump

to show network activity. It is almost certainly a network request (perhaps DNS?) triggering the diald link. You can adjust the diald rules to filter out activity that shouldn't bring the line up.

Also, you can try:

killall -USR2 diald

which causes diald to dump status information to /var/log/messages. This will show you information about the requests that brought the link up (but you have to run the killall command quickly after the link comes up).

You may also want to explore some of the advanced diald options that let you control the diald schedule. The command:

man diald-examples

will give you lots of information about this. Finally, is your diald line still not staying up when you visit web pages? I'm wondering if you have your web browser configured to use a proxy? Or if perhaps you are visiting web sites at non-standard ports such as:

http://www.e-smith.net:1234/whatever

Those would only bring the line up briefly, since the diald rule looks for outgoing connections to port 80 to hold the line up longer.

Hope this helps. Best regards,
- Joe

[Steve Hiner]

Joe,

Thanks for the typical quick response.  

I tried tcpdump the other day but it puts out so much data and I am not totally sure how to interpret it.  (At first I ran it through telnet so it dumped all the data that I was causing myself - classic example of the Heisenberg Uncertainty Principle, you can't measure something without altering it's properties and invalidating the measurement.)

So far as I know there wasn't any DNS requesting going on at the time the link came up, however, I am running a Win98 system on the network and Windows tends to do things without asking - I wouldn't be surprised if it polls the network every once in a while.  I suppose that would cause the link to come up.

I will try the killall command and let you know if it helps - thanks for the tip.

I have printed out diald-examples but I haven't read all of it yet (I'm setting the server up in my spare time which has been pretty sparse lately).  

Thanks for bringing up the old problem.  My connection still drops right after loading the first page (the first page still requires a refresh because IE and NS both timeout on the initial request).  You are correct about the proxy, I probably should have mentioned that.  I am running through a content filter at my ISP which naturally takes the form of a proxy server.  

I have found a reasonable work-around for the problem.  Though I haven't tested it fully yet I see no reason why it won't work.  What I have done is set the sendmail timeout to 20 minutes in the standard.filter and changed the fetchmail dialout in crontab to every 3 hours outside of business hours.  That way during business hours when it is checking every 15 minutes the link should stay up all the time but it should be down most of the night.

One new question.  On the developer mailing list you said there is a new version of the e-smith RPM.  Does it include all of the changes in the qmail patch that Charlie Brady posted and does it include the new featues that Ip Tak Hong added?  I made the mistake of using Charlie's patch after installing Ip's rpm and I ended up having to reinstall the OS since I'm not knowledgable enough to fix it myself - the patch pretty much blew up since it didn't find the files it expected to.

Thanks again,
Steve

[Joseph Morrison]

Hi Steve,

Aha! The proxy server explains the diald problem you are having (connection not staying up). Do you know what port number your content filtering proxy server uses? The http rule in your diald file reads something like:

accept tcp 1200 tcp.dest=tcp.www
accept tcp 1200 tcp.source=tcp.www

Right after those lines, try adding:

accept tcp 1200 tcp.dest=tcp.1234
accept tcp 1200 tcp.source=tcp.1234

(and replace 1234 with the port number of your content filtering proxy).

The latest version of the e-smith RPM includes Charlie Brady's changes, but not Ip,Tak Hong's. We're still reviewing Ip, Tak Hong's changes (which include new features visible in the user interface) and will probably not release those until e-smith 3.1 comes out (no release date scheduled yet).

Beware that upgrading the e-smith RPM will remove your customizations (although it saves the standard console and web-manager settings). So if you upgrade, save your customized files first!

Good luck!
- Joe

[Steve Hiner]

I'm about to give up at this stage.  Adding the port number didn't seem to do any good.  Now when I try to connect the server will dial out, I can't ping anything even from the server and when I try to open a web page on my Win98 client the server immediately drops the connection.  This really shouldn't be this complicated.

I'm going to try reinstalling everything to find out if the combination of the qmail patch and Ip Tak Hong's changes are messing things up.  I suppose it is time to pay for support (probably past time to pony up the support costs - I am working as a volunteer for my Church and I chose your product to save cost, that is why I have been reluctant to have them pay, still a lot cheaper than MS Exchange and a Web Beetle proxy server).

It is certainly possible that with all of my fighting to get this working I have screwed something up beyond my ability to diagnose and repair it though I really haven't changed much.  

I will update you if I make any progress.

Stressed-out Steve