Red Hat Bugzilla – Bug 232522
mgetty does not collect caller name from modem properly
Last modified: 2014-11-09 17:30:39 EST
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):
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
mgetty calls external program as follows: (phone number obscured)
/home/don/ccid/cidmgetty.pl ttyS1 'xxxyyy7139' '' 0 ''
mgetty should have included the name instead of a null string:
/home/don/ccid/cidmgetty.pl ttyS1 'xxxyyy7139' 'RUSSELL DON' 0 ''
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
Created attachment 150181 [details]
mgetty log at debug level 6 showing where external program is called too soon.
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. :-(
PS.. I obscured the phone number in the callerid string replacing digits with
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"?
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.
Problem still exists in F7: mgetty 1.1.33-10
The patch file supplied 2007-05-22 still applies.
BTW - mgetty 1.1.36 is available now. (But from looking at the code, don't
believe this is fixed in that version either.)
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...
Could you please attach your patch again, but in plain text? I can't open your
last attachment. Thanks.
Created attachment 301512 [details]
Patch to callback.c (1 of 4)
Created attachment 301513 [details]
Patch (diff) for cnd.c (2 of 4)
Created attachment 301514 [details]
Patch (diff) for mgetty.h (3 of 4)
Created attachment 301515 [details]
Patch (diff) for ring.c (4 of 4)
Created attachment 301519 [details]
One patch in unified format equivalent to the four other patches
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(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.
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". :-)
Patch is here. Can it be applied and this bug closed?
(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. :-)
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.
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.
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.
Please, use rpm file directly.
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.
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.