mgetty locks the port
PullnOutHair
but I am hoping that since mgetty is what answers the modem to start
AutoPPP I will get lucky. My linux boxes have been performing
beautifully over the past 3 months. Now all of a sudden they don't
answer when I call in and the ppp dial on demand won't dial out
either. I have tracked it down and mgetty is locking the port and not
releasing it. But the problem is, shouldn't mgetty answer since it
has the port locked? Well it doesn't answer the call, and ppp can't
call out because it's port is locked by mgetty. From the little bit
that I understand, mgetty will lock the port, initialize the modem,
and release the port. Then it monitors the port and lock file to see
if there is a RING on the port. Once it gets the ring, it locks the
port and transfers to PPP. But this is not what I have happening. If
you need any debug files or setup files let me know. I can drive to a
site and get them, but it takes a while because these servers are
located all over the place and utilize a cellular modem for
connections.
Bill Unruh
]I am running into a problem with mgetty. I know this is a ppp board,
]but I am hoping that since mgetty is what answers the modem to start
]AutoPPP I will get lucky. My linux boxes have been performing
]beautifully over the past 3 months. Now all of a sudden they don't
]answer when I call in and the ppp dial on demand won't dial out
]either. I have tracked it down and mgetty is locking the port and not
]releasing it. But the problem is, shouldn't mgetty answer since it
If mgetty sees activity on the port it will grab it if there is no lock
file. Not just Ring. (Ie grabs the output of the port and looks for Ring,
but it has already grabbed the output.)
Look in /var/log/mgetty-* to see what mgetty thinks it is doing. Up the
debug level for mgetty (eg -x5 on the inittab line for mgetty and debug 5
in the mgetty.config file.)
]has the port locked? Well it doesn't answer the call, and ppp can't
]call out because it's port is locked by mgetty. From the little bit
]that I understand, mgetty will lock the port, initialize the modem,
]and release the port. Then it monitors the port and lock file to see
]if there is a RING on the port. Once it gets the ring, it locks the
No it monitors it for any activity. If it sees activity it checks for the
lock file. If none, it grabs the port.
]port and transfers to PPP. But this is not what I have happening. If
]you need any debug files or setup files let me know. I can drive to a
]site and get them, but it takes a while because these servers are
]located all over the place and utilize a cellular modem for
]connections.
I would suspect the cellular modems rather than ppp or mgetty.
PullnOutHair
That is always what I suspect. It can never be anything that I do or
setup.:)
Actually, I got some of this working. The problem I am encountering
now is that mgetty finds an unlocked port with activity on it. So it
locks the port and waits for a RING. Problem is that the modem is
cellular so it sometimes does weird things dependent upon the cellular
signal it recieves. So sometimes mgetty is locking a port when there
will be no RING. Is there a way to setup a timeout on how long mgetty
waits to find the RING? If not would it be possible to check using a
script run by cron for an mgetty port lock and release it if the lock
and PID remain constant for mgetty?
Bill Unruh
]> I would suspect the cellular modems rather than ppp or mgetty.
]That is always what I suspect. It can never be anything that I do or
]setup.:)
]Actually, I got some of this working. The problem I am encountering
]now is that mgetty finds an unlocked port with activity on it. So it
Yes, If it sees any activity, it will first check for a lock file. If it
finds one, it does nothing. If not it grabs the port.
]locks the port and waits for a RING. Problem is that the modem is
]cellular so it sometimes does weird things dependent upon the cellular
]signal it recieves. So sometimes mgetty is locking a port when there
]will be no RING. Is there a way to setup a timeout on how long mgetty
]waits to find the RING? If not would it be possible to check using a
]script run by cron for an mgetty port lock and release it if the lock
]and PID remain constant for mgetty?
Yes, there is a timeout on mgetty. Up the log level on mgetty and see if
you get the Junk on line? error. (up the error level to say 8 to make sure
you get everything.)
(mgetty -x 8 in inittab and debug 8 in mgetty.config)
PullnOutHair
checking to make sure the modem exists. Mgetty locks the port, and
then issues an AT command. If the modem does not respond or responds
with something other that AT. ie RING then the port gets locked by
mgetty looking for an OK from the modem. This doesn't appear to
timeout in anyway. Is there an adjustment in the mgetty config that
will adjust this. I don't even really care for it to check for the
modem since I know it is there.
Bill Unruh
]Alright, so what I can see is that the lock only occurs when mgetty is
Uh, no you do not know it is there. Someone can pull the plug. a chip can
burn out. A serial cable can fall out. Many things can happen to it.
But, mgetty does not freeze-- it does timeout-- since I have often had a
dead modem which mgetty then tries to get at time and time again.
That may be your problem-- the modem stops responding-- ie is not there.
Again, up the debug level and look at the debug logs to see what is
happening. Don't guess.
PullnOutHair
I apologize, the guess is what the debug log is showing. Mgetty
doesn't timeout waiting on the modem to respond. Mgetty locks the
port, and then while waiting for the OK from the AT command a RING
comes to mgetty. At this point the AT has been lost so mgetty is just
sitting there waiting for OK. No matter how long I wait, and I have
waited days because some of these computers are located in the middle
of nowwhere. And no someone can't pull the plug. These computers are
inside a nema 3R enclosure to which only I have a key. I chip can
burn out and the cable break due to alien invasion, but honestly I
don't care if the modem is there or not. No matter what mgetty should
be looking for activity on the port. But the debug log on these
computers that get locked for days just shows, mgetty locks the port,
sends the AT command and starts to wait for OK, then it gets tons of
RING messages because I try and try to get back into the machine
without having to drive for hours to get there to unlock mgetty. My
debug level is at 9 so there are tons of garbage in the log, but this
is where it locks. Can I just increase the time between mgetty
checking for the modem? Seems like it should know to timeout and
reset if the OK isn't received in a certail amount of time, but it
just sits there.
Thank you
Tim Warnock
news:caad9b27.04063...@posting.google.com...
ok you might be receiving, but are you sending? can you turn off mgetty and
minicom to the port and do an AT and get an OK?
if you are then:
1) grab the mgetty source and patch it to make it be happy with an OK or
RING
so that:
first ring will be treated as the "OK" its looking for, the rest will be
treated as "RING"
Bill Unruh
]un...@string.physics.ubc.ca (Bill Unruh) wrote in message news:<cbs7tk$r6i$1...@string.physics.ubc.ca>...
OK, I see nowhere where mgetty just sends AT. What I see is it doing
"init-chat" Ie sending the init chat string which you defined in
/etc/mgetty*/mgetty.config.
(I assume it starts with AT-- try starting it with AT&F (or AT&F1 if a
Sportster modem) instead of just AT.
What is your init chat string?
Note that there is an init_chat_timeout of 20 sec.
Note also that the next action after the init chat is
/* maybe the modem init failed, because the modem was switched
* off. So, we check now that there is a DSR or a CTS signal
* coming from the modem - and if not, we sleep until it comes back.
* WARNING: this can fail on systems not allowing to read out the
* RS232 status lines, thus it is optional, and off by default!
*/
So you may well be in this sleep state when the modem did not come back
with the OK, because you have the "need_dsr" flag set in mgetty.config
However the line
"No DSR/CTS signals, assuming modem is switched off, waiting..."
should be in your logs if you have the error level set high enough.
(You HAVE to have the -x8 set in /etc/inittab file on the mgetty line)
Alternatively, in do_chat.c
/* set alarm timer. for the first string, the timer is only
set if the flag "timeout_first" is true */
but from my reading of the text, it is true. So it should timeout.
But by this point the branching tree is getting too large. You need to post
the output of the mgetty log.