Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 232522

Summary: mgetty does not collect caller name from modem properly
Product: [Fedora] Fedora Reporter: Don Russell <fedora>
Component: mgettyAssignee: Jiri Skala <jskala>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: aglotov, mbarabas, poelstra, triage
Target Milestone: ---Keywords: Patch
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-05 07:02:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
mgetty log at debug level 6 showing where external program is called too soon.
mgetty log when caller id is unformatted
Patch to cnd.c so unformated (FSK) caller ID data is collected properly
Contains 4 small diff files to fix this and other related issues.
Patch to callback.c (1 of 4)
Patch (diff) for cnd.c (2 of 4)
Patch (diff) for mgetty.h (3 of 4)
Patch (diff) for ring.c (4 of 4)
One patch in unified format equivalent to the four other patches none

Description Don Russell 2007-03-15 22:57:34 UTC
Description of problem:
mgetty calls an external program to check caller id (number, name etc) so a
decision is made as to whether or not to accept (answer) the call. mgetty calls
the external program too soon... it does not collect the name from the modem,
even though 'name' is one of the parameters passed to the external program.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. define cnd-program in metty.config
2. set options and debug level 6 (or higher) in mgetty.config
3. call the modem line from another phone
Actual results:
mgetty calls external program as follows: (phone number obscured)
/home/don/ccid/ ttyS1 'xxxyyy7139' '' 0 ''

Expected results:
mgetty should have included the name instead of a null string:
/home/don/ccid/ ttyS1 'xxxyyy7139' 'RUSSELL DON' 0 ''

Additional info:
See mgetty.log file attached. The beginning of the log file shows the modem is
USRobotics Courier, and all the settings etc. The end of the file shows the
results of caller id information. You can see where mgetty calls the external
program after getting the calling number, but does not wait for the name. You
will see the remainder of the name in the log AFTER the external program has
been called.

Comment 1 Don Russell 2007-03-15 22:57:34 UTC
Created attachment 150181 [details]
mgetty log at debug level 6 showing where external program is called too soon.

Comment 2 Don Russell 2007-03-16 17:04:29 UTC
Created attachment 150250 [details]
mgetty log when caller id is unformatted

Since the mgetty documentation is unclear regarding the use of
formatted/unformatted caller id information, I tried with unformatted and
attached the log results.

mgetty does a great job of collecting the entire unformatted string, but then
passes only *part* of it to the cnd-program.

mgetty parses the the unformatted caller id string and stops at the first
non-numeric (0-9) character. (The unformatted string will *always* have a
non-digit character, it's hexadecimal data)

If mgetty passed the entire string to cnd-program, that would be fine... then I
can easily decode the string myself. And this is probaly an easier fix to
mgetty: Just pass the whole string, unaltered to cnd-program... let cnd-program
worry about it.

I'm going to see if I can find the source code and see what's needed... but
that might be a couple of weeks... I have other things... not as much fun as
this, but more urgent. :-(

Don Russell

PS.. I obscured the phone number in the callerid string replacing digits with
lowercase "n".

Comment 3 Don Russell 2007-04-06 06:17:32 UTC
Is mgetty still being maintained in Fedora? This bug was opened 2007-03-15, and
today when I went in search of source code to see if I could fix this myself I
found there have been two releases since 1.1.33:

1.1.34 - 2005-11-30
1.1.35 - 2006-02-06

So mgetty 1.1.35 has been available for more than a year, but still is not in
Fedora via yum update. I do not know if this bug is fixed in the newer version.

How does the newer version (1.1.35) get into Fedora 6 so I can "yum update mgetty"?

Comment 4 Don Russell 2007-05-22 04:50:08 UTC
Created attachment 155149 [details]
Patch to cnd.c so unformated (FSK) caller  ID data is collected properly

A diff file showing a small change to cnd.c so that unformatted (FSK caller ID
data is collected.

Comment 5 Don Russell 2007-08-10 21:33:30 UTC
Problem still exists in F7: mgetty 1.1.33-10

The patch file supplied 2007-05-22 still applies.

Comment 6 Don Russell 2007-08-10 21:58:16 UTC
BTW - mgetty 1.1.36 is available now. (But from looking at the code, don't
believe  this is fixed in that version either.)

Comment 7 Don Russell 2007-08-14 23:28:18 UTC
Created attachment 161315 [details]
Contains 4 small diff files to fix this and other related issues.

I made a few changes to the 1.1.36 version and am attaching the diff files here
in case anybody else wants/need similar changes. I also sent them upstream to
Gert Doering, so hopefully he will adopt the changes into 1.1.37 :-)

This solves the problem where cnd-program is called too soon when the ring
count is set to 2. A work-around is to set the required rings to 3 in
mgetty.config, but I'm impatient and want the line to be picked up ASAP. :-)

It also solves the problem if the modem (USR/Rockwell) is set to send caller ID
as unformatted (FSK) data...

Comment 8 Martin Nagy 2008-04-07 10:56:44 UTC
Could you please attach your patch again, but in plain text? I can't open your
last attachment. Thanks.

Comment 9 Don Russell 2008-04-07 12:59:22 UTC
Created attachment 301512 [details]
Patch to callback.c (1 of 4)

Comment 10 Don Russell 2008-04-07 13:00:08 UTC
Created attachment 301513 [details]
Patch (diff) for cnd.c (2 of 4)

Comment 11 Don Russell 2008-04-07 13:01:19 UTC
Created attachment 301514 [details]
Patch (diff) for mgetty.h (3 of 4)

Comment 12 Don Russell 2008-04-07 13:05:06 UTC
Created attachment 301515 [details]
Patch (diff) for ring.c (4 of 4)

Comment 13 Martin Nagy 2008-04-07 13:52:30 UTC
Created attachment 301519 [details]
One patch in unified format equivalent to the four other patches

Comment 14 Bug Zapper 2008-05-14 12:10:37 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here:

Comment 15 Don Russell 2008-05-14 13:12:23 UTC
(In reply to comment #14)
> This message is a reminder that Fedora 7 is nearing the end of life... 

Changed Fedora version to 8, as problem still exists in that version.
I have not installed Fedora 9 yet to see if it still applies, but I suspect it does.

Comment 16 Don Russell 2008-09-02 00:41:00 UTC
Updated to Fedora Version 9...
mgetty source 1.1.36 has the same problem.

This should go upstream, but I suspect package maintainers get more attention from Gert than us "mere mortals". :-)


Comment 17 John Poelstra 2008-09-02 14:58:35 UTC

Patch is here. Can it be applied and this bug closed?


Comment 18 Don Russell 2008-09-02 16:14:59 UTC
(In reply to comment #17)

> Patch is here. Can it be applied and this bug closed?

I'm doing some testing with this over the next week or so.... it's been open this long, let's hold off on closing it.

When it is closed, is there a way to get this applied upstream so I don't have to keep fixing each new version. :-)


Comment 19 Don Russell 2008-09-09 22:08:14 UTC
I've been using this patched version for the past week and have not encountered any problems. The code changes are quite straight forward, i.e. not a very complex problem to solve.

HOWEVER, I applied the patches that *I* uploaded, not the "repackaged" set that somebody else created here.

I tried that package, and the patches were not correct.

I applied the individual file patches to version 1.1.36 and am running that now.

Comment 20 Jiri Skala 2009-01-30 13:50:20 UTC
I re-based F-9 to 1.1.36 and applied your patches. The build is

Please, let me know if the build mgetty-1.1.36-1.fc9 is ok. Then I'll apply it to F10 and rawhide and I'll send it to upstream.



Comment 21 Don Russell 2009-01-30 23:24:29 UTC
It will take me a few days (perhaps a week) to get to this. So I expect to be able to give you a definitive answer NLT Mon 9 Feb.

Will this (your rebased version with my patches) be available on F9 via yum, or do I need to d/l the rpm file directly?

I appreciate your work taking my changes forward.

Don Russell

Comment 22 Jiri Skala 2009-01-31 08:21:03 UTC
Please, use rpm file directly.


Comment 23 Don Russell 2009-02-05 02:56:26 UTC
I installed the rpm file from comment #20 and have tested it over a couple of days. It works the way I expect, properly picking up the name or the entire "raw" FSK data depending on the modem setting.

Thank you,
Don Russell

Comment 24 Don Russell 2009-03-27 18:56:47 UTC
I upgraded to Fedora 10 last night and mgetty-1.1.36-2.fc10.i386 was installed, but it does not work properly. It's retrograded back to the original problem. This was unexpected based on comment #20 .

Since this has been closed.... is there a new bug number for the F10 version?

In the mean time, I've gone back to my version of the code.