[9fans] FAX

[lucio@proxima.alt.za]

I have a ZyXEL U-1496E (Plus) that seems to jam solid when sending
faxes using telco/sendfax, but operates reasonably (I can't check the
receiving end) if I send the same G3 images using mgetty+sendfax under
NetBSD.

It seems to freeze waiting for the OK at the end of the first page,
whereas mgetty+sendfax has no such problem with the first or the
second/last page (that's as much as I felt I needed to try).

Thing is, I can't see a significant difference between the two
operations, other that mgetty shuts down carrier detection in the tty
driver (CLOCAL mode, I think) once it gets going.  From the modem
lights, this shouldn't matter, as the CD indicator remains on while
the failure occurs, while, perhaps very relevant, CTS goes off.

The actual conversation with the modem is slightly different between
the two utilities, but I could not detect a significant deviation.
These are my ZyXEL settings, in telco.c:

	 {	"ZyXEL",	"ATI0",	"1496",	0,
		"AT&K4",	/* error correction */
		"AT&N0",	/* autonegotiate */
		"AT&H3",	/* CTS/RTS flow control */
		"AT&B1",	/* don't change port baud rate */
	 	"AT+FCLASS=2\rAT+FBOR=0\rAT+FCR=1",	// AT+FDIS=1??
		"AT+FCLASS=0",
	 },

I have also taken the liberty to replace a meaningless ATZH0 in
telco.c:/ATZ to the more reasonable ATZ, but this is purely esthetic.
Interestingly, attention() fails, once the modem has been jammed by a
fax sending session and telco seems to hang after two attention()
attempts, but I can't seem to find where in the code this happens.
Don't assign too much value to this, I have not investigated it in any
real detail.

In /sys/src/cmd/fax/fax2send.c:/FDT, I removed the geometry arguments
and sent a bare AT+FDT as is done in mgetty in an attempt to change
the outcome, but it made no difference.  It seems to me that the major
problem lies with hardware control (the CTS line remaining off, so
that it looks like the end-of-page command does not reach the modem at
all).  This is borne out by the fact that the session hangs and does
not recover until I drop the link from the modem front panel (or
whatever would trigger a modem reset, I suppose).

I was under the impression that hardware flow control wasn't
implemented on the async ports, I'm pleased to learn otherwise, but
now I wonder how to deal with it, I suppose.

I will send recent logs from both Plan 9 and Unix if anybody wants to
inspect them.

++L