Re: Setting up linux as an email server

Sun, 16 May 1999 12:17:30 -0700 

Jacob (Mettavihari)

On Fri, 7 May 1999, Ray Olszewski wrote:

Thank you for all your efforts they are much appriciated
Below is some details for you to have a look at.
Comments are welcome.

I have in this first example 
removed the mgetty from inittab on the client.
and to my understanding PPP is working OK

Client side 
-------------
/var/log/messages
May 14 17:56:37 Col7 syslog: ROOT LOGIN ON tty2
May 14 17:56:48 Col7 PAM_pwdb[395]: (login) session opened for user root by
root(uid=0) 
May 14 17:56:48 Col7 syslog: ROOT LOGIN ON tty1
May 14 17:58:18 Col7 kernel: CSLIP: code copyright 1989 Regents of the
University of California
May 14 17:58:18 Col7 kernel: PPP: version 2.2.0 (dynamic channel allocation)
May 14 17:58:18 Col7 kernel: PPP Dynamic channel allocation code copyright
1995 Caldera, Inc.
May 14 17:58:18 Col7 kernel: PPP line discipline registered.
May 14 17:58:18 Col7 kernel: registered device ppp0
May 14 17:58:18 Col7 pppd[668]: pppd 2.2.0 started by root, uid 0
May 14 17:58:19 Col7 chat[669]: timeout set to 3 seconds
May 14 17:58:19 Col7 chat[669]: abort on (\nBUSY\r) 
May 14 17:58:19 Col7 chat[669]: abort on (\nNO ANSWER\r) 
May 14 17:58:19 Col7 chat[669]: abort on (\nRINGING\r\n\r\nRINGING\r) 
May 14 17:58:19 Col7 chat[669]: send (rAT^M) 
May 14 17:58:19 Col7 chat[669]: expect (OK) 
May 14 17:58:19 Col7 chat[669]: rAT^M^M 
May 14 17:58:19 Col7 chat[669]: OK -- got it 
May 14 17:58:19 Col7 chat[669]: send (ATH0^M) 
May 14 17:58:20 Col7 chat[669]: timeout set to 30 seconds
May 14 17:58:20 Col7 chat[669]: expect (OK) 
May 14 17:58:20 Col7 chat[669]: ^M 
May 14 17:58:20 Col7 chat[669]: ATH0^M^M 
May 14 17:58:20 Col7 chat[669]: OK -- got it 
May 14 17:58:20 Col7 chat[669]: send (ATDT300703^M) 
May 14 17:58:20 Col7 chat[669]: expect (CONNECT) 
May 14 17:58:20 Col7 chat[669]: ^M 
May 14 17:58:40 Col7 chat[669]: ATDT300703^M^M 
May 14 17:58:40 Col7 chat[669]: CONNECT -- got it 
May 14 17:58:40 Col7 chat[669]: send (^M) 
May 14 17:58:40 Col7 chat[669]: expect (ogin:) 
May 14 17:58:40 Col7 chat[669]:  38400^M 
May 14 17:58:41 Col7 chat[669]: ^M 
May 14 17:58:41 Col7 chat[669]: ^MDhamma Server  
May 14 17:58:41 Col7 chat[669]: ^MDhammo have rakkhati dhammacarm 
May 14 17:58:41 Col7 chat[669]: ^MDhamma protects the one living the Dhamma 
May 14 17:58:41 Col7 chat[669]: ^MKernel 2.0.30 on an i586 
May 14 17:58:41 Col7 chat[669]: ^M 
May 14 17:58:41 Col7 chat[669]: ^M^M 
May 14 17:58:41 Col7 chat[669]: login: -- got it 
May 14 17:58:41 Col7 chat[669]: send (win^M) 
May 14 17:58:41 Col7 chat[669]: expect (assword:) 
May 14 17:58:42 Col7 chat[669]:  win^M 
May 14 17:58:42 Col7 chat[669]: Password: -- got it 
May 14 17:58:42 Col7 chat[669]: send (windows95^M) 
May 14 17:58:42 Col7 pppd[668]: Serial connection established.
May 14 17:58:43 Col7 pppd[668]: Using interface ppp0
May 14 17:58:43 Col7 pppd[668]: Connect: ppp0 <--> /dev/modem
May 14 17:58:46 Col7 pppd[668]: local  IP address 10.1.1.1
May 14 17:58:46 Col7 pppd[668]: remote IP address 172.16.1.10
May 14 17:58:46 Col7 pppd[668]: Cannot determine ethernet address for proxy ARP

>May 14 17:58:46 Col7 pppd[668]: Cannot determine ethernet address for proxy ARP

I have an ethernet card in the Client which is not yet connected to anything,
perhaps the above message is about this card.


Host side.
/var/log/messages
-----------------
May 14 11:58:08 dhamma mgetty[1505]: data dev=modem, pid=1505, caller=none,
conn='38400', 
name='', cmd='/bin/login', user='win'
May 14 11:58:09 dhamma login: DIALUP ttyS1, win
May 14 11:58:09 dhamma kernel: CSLIP: code copyright 1989 Regents of the
University of California
May 14 11:58:09 dhamma kernel: PPP: version 2.2.0 (dynamic channel allocation)
May 14 11:58:09 dhamma kernel: PPP Dynamic channel allocation code copyright
1995 Caldera, Inc.
May 14 11:58:09 dhamma kernel: PPP line discipline registered.
May 14 11:58:10 dhamma kernel: registered device ppp0
May 14 11:58:10 dhamma pppd[1505]: pppd 2.2.0 started by win, uid 505
May 14 11:58:10 dhamma pppd[1505]: Using interface ppp0
May 14 11:58:10 dhamma pppd[1505]: Connect: ppp0 <--> /dev/ttyS1
May 14 11:58:13 dhamma pppd[1505]: local  IP address 172.16.1.10
May 14 11:58:13 dhamma pppd[1505]: remote IP address 10.1.1.1
May 14 11:58:13 dhamma pppd[1505]: ppp not replacing existing default route
to eth0[204.143.107.33]

after the PPP is up,
I can ping host IP address 172.16.1.10
I can ping host 204.143.107.46

but I cannot ping 204.143.107.33 the gateway of the Host at my ISP.
and I cannot ping out into the net.

>May 14 11:58:13 dhamma pppd[1505]: ppp not replacing existing default route
> to eth0[204.143.107.33]

I do not quite understand this message.

> You also seem to be running both the pppd/chat process AND the mgetty
> process on the client. You don't need to -- you run mgetty ONLY on the
> server end, so it can answer the phone. On the client end, it may be locking
> the serial port, resetting the modem, ordoing something else to interfere
> with an outgoing call. (Not sure about this, but I remember that mixing
> outgoing and incoming processes on the same device is tricky.) 

Yes you are quite right.

I have read in the /usr/info/mgetty.info1
that mgetty should be able to stay resident without interupting outgoing calls 

this is just a small part of the file
I shall be glad to send the whole set if you want it.

------------

   When mgetty is started, it first checks if a valid lock file held by
another process exists. If it does, this means that the port is in use,
and mgetty will wait until the lock file goes away. Invalid lock files,
e.g. for nonexistent processes ("stale" locks), are ignored.

#   Once the port is free, mgetty creates its own lockfile, initializes
#the modem and removes its lock file again. Then it waits for something
#to happen on the port. Note that it does not *read* any characters, it
#just checks if there are any available for reading by using `poll()' or
#`select()'.

   There are two possibilities once characters arrive, either a
different program (e.g.  `uucico') has started dialing out or a `RING'
was sent by the modem.  In the first case, mgetty should leave the port
alone. This is easy *if* the program dialing out has created a valid
lock file: mgetty will find it, wait for it to go away and then exit
(which will cause `init' to start a fresh `mgetty' process, which will
then wait for the next call).

   In the second case, when there is no lock file, mgetty assumes that
the phone is ringing, creates a lock file and reads the characters
available. If it finds a `RING', it picks up the phone by sending `ATA'
and waits for the `CONNECT' message. If the caller is a fax machine, it
saves the fax in the directory `FAX_SPOOL_IN' (usually
`/var/spool/fax/incoming') and exits. If it is a modem, it prints
`/etc/issue' and displays a login prompt. Once it has received a login
string, it calls `/bin/login' and lets it handle things from here.
`login' will read the password and will then start the user's login
shell, `uucico', a dialup SLIP link or whatever, but mgetty doesn't
care about that. The lock file remains so that no other programs will
try to use the modem while somebody is logged in.

   (If the `login.config' configuration file is used, mgetty can also
call other login programs than `/bin/login'. See below for more details)

---------------
 
> The associated log entries sure look like mgetty and pppd/chat are fighting
> over access to the modem. I don't know mgetty well, so I don't know if the
> errors it is reporting on the client indicate a conflict or perhaps just a
> modem that does not recognize those commands.

I will have to have mgetty up on the client 
as you might remember the client is also a "mail-server"  
to "Win95 persons"  who will log in to get their mail.
 
You are quite right in suggesting that mgetty is locking the modem.
below are some files at a time when I have mgetty up on the Client side.

/var/log/log_mg.modem

05/14 18:16:09 dem  waiting for ``RING''
05/14 18:16:19 dem  timeout in chat script, waiting for `RING'
05/14 18:16:19 dem  huh? Junk on the line?
--
05/14 18:16:19 dem  mgetty: experimental test release 1.1.5-Apr16
05/14 18:16:19 dem  check for lockfiles
05/14 18:16:19 dem  locking the line
05/14 18:16:19 dem  lowering DTR to reset Modem
05/14 18:16:20 dem  send: \dATQ0V1H0[0d]
05/14 18:16:20 dem  waiting for ``OK'' ** found **
05/14 18:16:20 dem  send: ATS0=0Q0&D3&C1[0d]
05/14 18:16:20 dem  waiting for ``OK'' ** found **
05/14 18:16:21 dem  mdm_send: 'ATI'
05/14 18:16:21 dem  Generic Rockwell modem (33600) -> OK
05/14 18:16:21 dem  mdm_send: 'AT+FCLASS=2' -> ERROR
05/14 18:16:21 dem  mdm_send: 'AT+FCLASS=2.0' -> ERROR
05/14 18:16:21 dem  mdm_send: 'AT+FCLASS=2' -> ERROR
05/14 18:16:21 dem  waiting...
# mgetty has obviously not removed its lock file
05/14 18:17:26 dem  lock not made: lock file exists (pid=729)
--
05/14 18:18:11 dem  mgetty: experimental test release 1.1.5-Apr16
05/14 18:18:11 dem  check for lockfiles
05/14 18:18:11 dem  locking the line
05/14 18:18:12 dem  lowering DTR to reset Modem
05/14 18:18:12 dem  send: \dATQ0V1H0[0d]
05/14 18:18:13 dem  waiting for ``OK'' ** found **
05/14 18:18:13 dem  send: ATS0=0Q0&D3&C1[0d]
05/14 18:18:13 dem  waiting for ``OK'' ** found **
05/14 18:18:13 dem  mdm_send: 'ATI'
05/14 18:18:13 dem  Generic Rockwell modem (33600) -> OK
05/14 18:18:13 dem  mdm_send: 'AT+FCLASS=2' -> ERROR
05/14 18:18:13 dem  mdm_send: 'AT+FCLASS=2.0' -> ERROR
05/14 18:18:13 dem  mdm_send: 'AT+FCLASS=2' -> ERROR
05/14 18:18:13 dem  waiting...
# mgetty has obviously not removed its lock file
05/14 18:25:27 dem  lock not made: lock file exists (pid=996)
--

#   Once the port is free, mgetty creates its own lockfile, initializes
#the modem and removes its lock file again. 

The above process does obviously not happen,
any suggestions are welcome.

It is possible that the version of mgetty might be a bit old, (Redhat 4.2) 
any idea where I can download a later version ?

I send you my thanks,
with best regards.
Jacob (Mettavihari)

International Buddhist Research & Information Center (IBRIC).
380/9  Sarana Road, Colombo 00700, Sri Lanka.
Telephone - +94 1 68 9388 email - [EMAIL PROTECTED]
WWW URL - http://www.transmillennium.net/IBRIC/

Reply via email to