Bug 232522 - mgetty does not collect caller name from modem properly
mgetty does not collect caller name from modem properly
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: mgetty (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jiri Skala
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-15 18:57 EDT by Don Russell
Modified: 2014-11-09 17:30 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-05 02:02:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
mgetty log at debug level 6 showing where external program is called too soon. (9.16 KB, text/plain)
2007-03-15 18:57 EDT, Don Russell
no flags Details
mgetty log when caller id is unformatted (1.43 KB, text/plain)
2007-03-16 13:04 EDT, Don Russell
no flags Details
Patch to cnd.c so unformated (FSK) caller ID data is collected properly (250 bytes, text/plain)
2007-05-22 00:50 EDT, Don Russell
no flags Details
Contains 4 small diff files to fix this and other related issues. (990 bytes, application/x-gzip)
2007-08-14 19:28 EDT, Don Russell
no flags Details
Patch to callback.c (1 of 4) (115 bytes, text/plain)
2008-04-07 08:59 EDT, Don Russell
no flags Details
Patch (diff) for cnd.c (2 of 4) (1.02 KB, text/plain)
2008-04-07 09:00 EDT, Don Russell
no flags Details
Patch (diff) for mgetty.h (3 of 4) (83 bytes, text/plain)
2008-04-07 09:01 EDT, Don Russell
no flags Details
Patch (diff) for ring.c (4 of 4) (496 bytes, text/plain)
2008-04-07 09:05 EDT, Don Russell
no flags Details
One patch in unified format equivalent to the four other patches (4.44 KB, patch)
2008-04-07 09:52 EDT, Martin Nagy
no flags Details | Diff

  None (edit)
Description Don Russell 2007-03-15 18:57:34 EDT
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):
1.1.33-9

How reproducible:
Always

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/cidmgetty.pl ttyS1 'xxxyyy7139' '' 0 ''


Expected results:
mgetty should have included the name instead of a null string:
/home/don/ccid/cidmgetty.pl 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 18:57:34 EDT
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 13:04:29 EDT
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. :-(

Thanks,
Don Russell

PS.. I obscured the phone number in the callerid string replacing digits with
lowercase "n".
Comment 3 Don Russell 2007-04-06 02:17:32 EDT
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 00:50:08 EDT
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 17:33:30 EDT
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 17:58:16 EDT
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 19:28:18 EDT
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 06:56:44 EDT
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 08:59:22 EDT
Created attachment 301512 [details]
Patch to callback.c (1 of 4)
Comment 10 Don Russell 2008-04-07 09:00:08 EDT
Created attachment 301513 [details]
Patch (diff) for cnd.c (2 of 4)
Comment 11 Don Russell 2008-04-07 09:01:19 EDT
Created attachment 301514 [details]
Patch (diff) for mgetty.h (3 of 4)
Comment 12 Don Russell 2008-04-07 09:05:06 EDT
Created attachment 301515 [details]
Patch (diff) for ring.c (4 of 4)
Comment 13 Martin Nagy 2008-04-07 09:52:30 EDT
Created attachment 301519 [details]
One patch in unified format equivalent to the four other patches
Comment 14 Bug Zapper 2008-05-14 08:10:37 EDT
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:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Don Russell 2008-05-14 09:12:23 EDT
(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-01 20:41:00 EDT
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". :-)

Cheers
Comment 17 John Poelstra 2008-09-02 10:58:35 EDT
Jiri,

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

Thanks,
John
Comment 18 Don Russell 2008-09-02 12:14:59 EDT
(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. :-)

Cheers,
Don
Comment 19 Don Russell 2008-09-09 18:08:14 EDT
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 08:50:20 EST
Hi,
I re-based F-9 to 1.1.36 and applied your patches. The build is

http://koji.fedoraproject.org/koji/buildinfo?buildID=80916

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.

Cheers,

Jiri
Comment 21 Don Russell 2009-01-30 18:24:29 EST
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?

Thanks,
I appreciate your work taking my changes forward.

Don Russell
Comment 22 Jiri Skala 2009-01-31 03:21:03 EST
Please, use rpm file directly.

Jiri
Comment 23 Don Russell 2009-02-04 21:56:26 EST
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 14:56:47 EDT
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.

Thanks,
Don

Note You need to log in before you can comment on or make changes to this bug.