Dmitry Bely schrieb:
> Andreas Grimmel <grimmel@additive-net.de> writes:
>
> > I set up a HylaFAX Server quite successful some time ago, and it seemed
> > to work REALLY fine. Then I went in vacation and when I came back, I got
> > lots of people queueing in front of my office door, all of them telling
> > me the same thing: Some Faxes just can't be delivered, and in the logs
> > it says everytime the same thing: "DTE to DCE Data Underflow" etc etc
> > etc. This does not happen all of the time, most faxes are delivered very
> > well. For me it seems this is a problem with older Fax machines, I tried
> > this in our office with one 5-year-old-machine and one 6-months-old-one.
> > With the old one faxing crashes everytime, with the new one never.
> > I'm using a SUSE 6.3 Box with a 2.2.14 Kernel running on a
> > PentiumIII/550 SCSI Machine with 256 Megs of RAM, an Elsa Microlink 56K
> > Pro Modem in Class 2.0 Mode and HylaFAX 4.1beta2.
>
> Strange enough, but your logs was collected in Class 2 mode (not Class
> 2.0), and there was no "DTE to DCE Data Underflow" ...
>
Sorry, but I do really believe it's Class 2.0, as you can see in c00000008.log
for example, it says
Aug 02 18:08:06.48: [16923]: <-- [14:AT+FCLASS=2.0\r]
and the DTE to DCE data underflow is in line 329 for example:
Aug 02 18:11:34.64: [16923]: REMOTE HANGUP: DTE to DCE data underflow (code 43)
Aug 02 18:11:34.64: [16923]: SEND FAILED: DTE to DCE data underflow; too many
attempts to send
I am not sure if the logs i postet got corrupted while transferring them from
the server to my WinNT workstation...
I guess I'm about to growing old and helpless ;-))
I re-posted my message with the logs pastet directly into the mail body on
4:56pm CET, hope this one works better...
>
> > Could that be that the older Fax machines don't understand my Modem's
> > talking in Class 2.0 mode ?
>
> If the firmware is buggy, that's possible. Try Class1 -- if we find a fax
> protocol-related bug in Class1 driver, we can understand what really
> happens and fix the bug ourselves. I consider this as a significant
> advantage :-)
>
Thanks for the hint, I will try that next!
>
> > I don't have too much knowledge about fax
> > protocols and phone lines and that stuff, so please excuse me if that is
> > a totally dumb question where reactions normally are "damn can't you see
> > this has REALLY NOTHING to do with each other???" ;-)
>
> Jay has already explained that Class1, Class2, Class2.0 have nothing to do
> with the fax protocol itself (and so fax machines compatibility). I can't
> do this better anyway :-)
>
> > I would be very happy if you could help me outta this, because ignoring
> > the above problem it's just wonderful seeing the HylaFAX server work (we
> > had an NT Machine before, and it crashed twice a week, hehe).
>
> Now about your logs. I'd bet that these "Unspecified Transmit Phase B
> error" were caused by incorrect Postscript, supplied to the server
> (e.g. your Windows client used HP printer driver, which appends PJL
> commands to the Postscript file). Under such circumstances hfaxd don't
> identify the data as a Postscript, fails to invoke Ghostscript rasterizer,
> but anyway queue the empty job (if my preliminary analysis was
> right). faxsend realizes this too late, and terminates connection,
> producing that silly "Unspecified Transmit Phase B error". I know about
> this bug for about a month, but still going to fix it :-))
>
I used the Apple LaserWriter 600 driver for it should _not_ contain these
additional commands, I think if that was the reason, the other faxes (to the
newer machine) would also crash... please tell me if I'm wrong.
>
> > Thanks to the HylaFAX devel team for just a GREAT piece of work.
>
> Hope to hear from you soon,
> Dmitry
OK, I'll be trying that thing with Class1 as the first thing tomorrow, going
home now (YES !!!) ;-)))
Thank you very much for your advice.
Andreas