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.
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. :-( Thanks, Don Russell PS.. I obscured the phone number in the callerid string replacing digits with lowercase "n".
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: http://docs.fedoraproject.org/release-notes/ 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". :-) Cheers
Jiri, Patch is here. Can it be applied and this bug closed? Thanks, John
(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
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.
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
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
Please, use rpm file directly. Jiri
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
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