flexfax: Deduce type of the call via external egetty sctipt

[Dmitry Bely <dbely@mail.ru>]

I need to select type of the incoming call via external program; although
it is not mentioned in the docs, if you look into sources you'll see that
AnswerRotary: "extern" parameter does exactly that thing: faxgetty calls
egetty program (egetty-link in my case as I use debianized Hylafax under
Debian GNU/Linux) and selects answer mode depending on its return
code. Good in theory, but it does not work:

[---cut---]
20:21:21.79: [ 1395]: SESSION BEGIN 00000586 70952343243                            
20:21:21.81: [ 1395]: EXTERN GETTY: START "/etc/hylafax/egetty-link ttyS2", pid 1415 
20:21:21.81: [ 1395]: STATE CHANGE: ANSWERING -> GETTYWAIT                          
20:21:21.81: [ 1395]: MODEM input buffering enabled                                 
20:21:21.85: [ 1395]: EXTERN GETTY: exit status 01000                               
20:21:21.85: [ 1395]: <-- [14:AT+FCLASS=2;A\r]                                      
20:21:21.85: [ 1395]: MODEM WRITE ERROR: errno 5                                    
20:21:21.85: [ 1395]: ANSWER: FAX CONNECTION                                        
20:21:21.85: [ 1395]: STATE CHANGE: GETTYWAIT -> RECEIVING                          
20:21:21.85: [ 1395]: MODEM input buffering enabled                                 
20:21:21.85: [ 1395]: MODEM setInputBuffering::tcgetattr: Input/output error        
20:21:21.85: [ 1395]: MODEM tcsetattr: Input/output error                           
20:21:21.85: [ 1395]: RECV FAX: begin                                               
20:21:21.85: [ 1395]: --> [0:]                                                      
20:21:21.85: [ 1395]: REMOTE HANGUP: Unspecified Receive Phase B error (code 70)    
20:21:21.85: [ 1395]: RECV FAX: Unspecified Receive Phase B error                   
20:21:21.86: [ 1395]: RECV FAX: end                                                 
20:21:21.86: [ 1395]: SESSION END 
[---cut---]

egetty script is as simple as

[---cut---]
#!/bin/sh
exit 2  # CALLTYPE_FAX
[---cut---]

Having such a disapointing result, I tried to find solution in the mailing
list archive, and found a long thread with the following message in the end: 

[---cut---]
To: flexfax@sgi.com, Camden Clarke <cclarke@inconceivable.com> 
Subject: flexfax: Re: egetty 
From: Julio C Spinelli <spine001@gold.tc.umn.edu> 
CC: glotel@protocom.com 
Date: Thu, 13 Nov 1997 12:26:12 +0000 

Sorry that it took so long for me to follow on on this subject, but I 
have been very busy at work.

After thorough investigation I found that the problem in Linux 2.0.29 
is that when Getty:run does a dup2 to duplicate the modem file 
descriptor into the standard output, in the child process, this destroys the file 
descriptor that point to the modem in the parent process. Why does 
this happens, it escapes me totally. I may look into the kernel 
source during my vacations (may be not...)

Whenever the dup2 is executed in the child the parent process can not 
read or write to the modem when the child exits.

The only way I managed to make it work for Linux is to have the 
egetty have uid 0 and open and close the modem itself. By doing this 
the only change needed in Getty.c++ is an additional if statement 
that does not do any dup2 is done when egetty is called.

Matthias, are you interested in this for the pl2?
> 
> You don't actually have to open the modem in your egetty program; HylaFAX
> will leave you with stdin and stdout setup to the modem.  This is intentional,
> so that egetty doesn't have to know where to find the modem, or deal
> with opening it correctly for shared access (e.g. Suns).
>                 -Cam Clarke
>  
> In astatos.flex-fax you write:
>  
> >Julio C Spinelli wrote:
> >
> >    Thanks for the info. egetty is nothing, it does not exist at all. The
> >    only meaning of the string egetty is that if EGettyArgs is defined as
> >    a non nul string and AnswerRotary is set to "extern". Hylafax will
> >    call a program /bin/egetty. If that program does not exist...
> >
> >    It is the user/system developer's responsibility to write that
> >    program. This program's job is to answer the incoming call, determine
> >    its type and then exit with a CALLTYPE_XXX (FAX, DATA, DONE, ERROR,
> >    VOICE) code. Hylafax will then proceed as if it itself would have
> >    determined the type of call.
> >
> >    The issue I have is that when I do this I get a modem write error
> >    after calling the sys::write(fd,......   call and as I don't fully
> >    understand the inheritance rules that Sam applies and neither have I
> >    been able to understand the Dispatch class. I am at a loss in trying
> >    to guess what is going wrong.
> >
> >    This is why I am looking for any working example for simple and bare
> >    bones it is.
> >
> >    Thanks for your help,
> >
> >    Julio
> >
> >    Note: I hope this clarifies what egetty is.
>  
> >Try this small example. It works for me (don't blame me about
> >this C-code, it's not the way I'm writing real code :-))
> >It works for me and faxgetty(1M) receives the fax fine (see the log).
>  
> >   matthias
>  
>  
> >/* change this define to the real device on your system */
> >#define LINE "/dev/ttyFN02"
> >main()
> >{
> >   int fd;
> >   fd = open(LINE, 2);
> >   if(fd < 0)
> >       exit(0);
> >   write(fd, "ATA\r", 4);   /* time to pick up the call */
> >   close(fd);
> >   exit(2);
> >}
[---cut---]
                                       
Two years left since then but the bug is still there -- at least my Hylafax 
4.0pl2 works with latest Linux kernel 2.0.38 just the same way. :-( Is
there anybody who can confim Julio's words that it's really bug in the
Linux Kernel? (I asked Julio but he did not remember what happened 2 years
ago). Maybe someone found the way how to fix it?

Hope to hear from you soon,
Dmitry