Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Oct 1995 12:52:11 +0100
From:      Hinrich Eilts <>
Cc: (Brian Litzinger)
Subject:   Re: hylafax unable to spawn getty
Message-ID:  <199510141152.MAA00431@odin>

Next in thread | Raw E-Mail | Index | Archive | Help
> I'm running hylafax on a 2.1 SNAP 951005 with a generic
> ROCKWELL modem and it mostly works.  However, when
> I make a data call into the system, the log shows
> that it spawns getty on the port, put no login
> ever shows up.  I can see (via ps)  getty on the right port
> just sitting there.  It sits there until I kill the getty
> at which point I get hung up upon and the hylafax system
> takes over again.

If a data-call happens, a Rockwell based modems (ELSA Microlink 28.8 TQV in my case)
picks up line, recognize the data-call and sends +FDM while it negotiate speed,
compression etc with remote modem. Because HylaFax spawns getty on receiving +FDM,
getty got /dev/cuaa* before the connection is enabled (modem is still negotating).
To solve this problem, getty should wait for the CONNECT message and not for +FDM,
there is an option in HylaFax conf named ModemWaitForConnect for this. In my case,
because this option does not work (for me), I installed a little hacked version of
getty named fgetty waiting for CONNECT for HylaFax (only HylaFax uses it, of course):

  fd_set readset;
  struct timeval connectwait;

  if (argc <= 2 || strcmp(argv[2], "-") == 0) {
    strcpy(ttyn, ttyname(0));
    FD_SET(STDIN_FILENO, &readset);
    connectwait.tv_sec = MAXCONNECTWAIT;
    connectwait.tv_usec = 0;
    n = select(STDIN_FILENO +1,&readset,NULL,NULL,&connectwait);
    if (n == 0) {
      syslog(LOG_ERR, "%s: timeout on waiting for CONNECT", ttyn);
    else if (n < 0) {
      syslog(LOG_ERR, "%s: select: %m");

You must tell the fgetty at config-time to HylaFax.
Because I used an old getty for this, I cannot provide an actual patch, but I think
it is easy for you.


Want to link to this message? Use this URL: <>