Faxpoll server with USR Courier V34+

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

On Sat, 20 Jan 1996, Gert Doering wrote:

> Hi,
>=20
> Gerhard Ahuis wrote:
> > > > 01/17 16:50:46 yS1  fax_wait_for: string '+IS:1,3,0,2,0,0,0,4'
> > > This seems as if your host has lost an "F" somewhere.
> > After I recompiled mgetty the 'F' was not lost anymore. (Can you explai=
n?,=20
> > I can't)
>=20
> I think this was an unique byte loss -- bad serial cable, whatever ;)

I found the same error three times in the logfile, maybee this unique=20
byte loss occurs three times ??? .....forget about it, it doesn't matter..

>=20
> > > > 01/17 16:50:56 yS1  fax_get_page_data: wait for EOL, got: [0a]P=E2!=
[ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff=
][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][ff][f=
f][ff][ff][ff][ff][ff][ff][ff][ff][ff][f
> > > Seems the leading EOL required on each page is missing -- bad timing =
in
> > > the USR?
> > This is also happening when normal receiving a fax (no poll). The=20
> > received facsimiles look good to me. Could it be that the first line al=
ways=20
> > is lost??
>=20
> Yup. Timing at the start of the page is fairly critical. Some modems do
> this very well (Multitech, ZyXEL), some worse (USR).
>=20
> > > This is the next ugly thing: the standard demands hexadecimal respons=
es,
> > > the courier sends decimal numbers. *sigh*.
> > Is it not possible to implement decimal responses and select between he=
x=20
> > and dec in the policy.h file ?
>=20
> Mgetty *does* distinguish between dec and hex responses (because in class
> 2, the responses are decimal), but I do *not* implement workarounds for=
=20
> modems firmware flaws, unless it's critical for operation (which this is
> not).
>=20
> > Or doesn't USR want to give you the decimal responses ?
>=20
> They apparently read the standard differently than I do.
>=20
> > > > 01/17 16:51:29 ##### failed: polling failed, +FHS:-5, time=3D60s
> > >=20
> > > -- the USR lowers the DCD line between pages, and this will lead to
> > > "strange" errors.
> > >=20
> > > I'm not sure, though, whether this will be sufficient to get poll
> > > receiving to work.
> >=20
> > When using #define FAX_SEND_IGNORE_CARRIER poll receiving is going fine=
.=20
>=20
> poll receiving or poll sending?

poll receiving with sendfax is going fine. (when using FAX_SEND_IGNORE=20
CARRIER).
poll sending with mgetty is going fine for only one page. The second is=20
sent into the logfile (echoed by the modem which dropped the line, maybee=
=20
it's the same problem as receiving a fax poll ????).=20

> > However this option has one big disadvantage. When the connection is=20
> > broken (lost carrier), MGETTY doesn't detect it. The faxfile which is=
=20
>                          ^^^^^ mgetty doesn't do "poll receiving"?!?
I'm sorry, I meant sendfax ofcourse.

> > sent, is echoed by the modem and written in the logfile..
>=20
> FAX_SEND_IGNORE_CARRIER isn't used in mgetty. This is a bug of the USR
> modem, it doesn't always give proper error responses upon hangup.
>=20
> (BTW: in fax mode the connection can never be "broken" in the middle of a
> page [unless you're using ECM which mgetty doesn't do] because fax is
> half-duplex, the modem won't notice until the end of the page that the

Is the carrier not monitored ?

> receiver has gone away. And *if* it notices, it *MUST* send a proper
> +FHS:xx status code).
>=20
> > Is it not possible to discard the carrier only when a page is completel=
y=20
> > sent ??
What I mean is the following: When sending a fax with sendfax, sendfax=20
monitors the carrier. When it's lost, sendfax stops sending. When using=20
FAX_SEND_IGNORE_CARRIER sendfax doesn't stop sending when the carrier is=20
lost. The fax sent, is echoed by the modem and written in the logfile.

Isn't it better then to discard only the carrier when a page is completely=
=20
sent?

Gerhard.