Faxpoll server with USR Courier V34+

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

Hi,

Gerhard Ahuis wrote:
> > No, this is the problem I have mentioned before. USRs *can't* do fax poll
> > sending, it is just broken. When I tried this, even the first page was
> > received partially corrupt, and then I've seen the same behaviour you see.
> Is there no possibilty that USR have improved their new flashroms (v34+) 
> and faxpoll sending is going better ?

Well, there is, but I severely doubt it. All answer I got on my "why
doesn't it work?" enquiries two or three months ago (well after the
introduction of V34+) were "it's optional, so don't complain". *sigh*

> > There is no carrier to be monitored, the connection is completely
> > half-duplex. The sending fax does not listen to *anything* on the line
> > until the end of the page (when it sends "my page is finished, what do
> > you think about it?").
> > 
> > Then your modem is even more broken than I thought.
> > 
> > During the page transmission (unless using ECM) the modem must *never* hang
> > up, and if it hangs up at the end of a page, it *must* signal this to the
> > host in form of some error message.
> 
> What is ECM exactly ?

Error correction mode. The sending modem sends a block of data, then asks
for confirmation, then going ahead or retransmitting this block.

I'm not sure whether the USR can do it, but mgetty definitely doesn't
enable it.

> > Could you send me a log file of a transmission where the modem starts
> > echoing the page data back to the host? In the meantime, I have a good
> > contact at USR support Germany, maybe he can try to get it fixed.
> Oeps, I think it's the way I dropped the line. I pushed the button in 
> front of the courier which is not the normal way.

No, it is not :)

> But I did notice a difference in behavior..
> 
> With #define FAX_SEND_IGNORE_CARRIER the file is echoed by the modem and 
> sent into the logfile.
> 
> Without #define FAX_SEND_IGNORE_CARRIER there are only I/O error messages 
> logged.

Sure. The carrier drops, and all further activity on the modem fails
(regardless of what the modem is actually doing). With the #define, 
the modem's misbehaviour can be seen, because the carrier drop won't
prevent further access to the line.

I don't really complain about the carrier drop here (this is another
matter), but the modem should really *never* drop back to command
(==echo :) ) mode without sending mgetty an error message.

Please, again, send me a log file so I can see what's going on!

gert

-- 
                                                            //www.muc.de/~gert
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-3545980 <---new!!!              gert.doering@physik.tu-muenchen.de