Re: Bug fix (not sure how to submit)

Brian Postow wrote:
> We had a problem dealing with a buggy FOIP box that would get the T30 frame, checked the CRC, found that it was correct, and then turned it into T38 packets and sent them to our computer. However there were two problems: 1) the FOIP box lost packets. and 2) T38 doesn't pass the CRC, it just says "yup, the CRC was correct on this end" and so, Hylafax got a short frame, which ends up with a broken TIFF file.
>
> We fixed this problem in faxd/Class1Recv.c++ by in additon to checking the CRC, checking the frame length:
>
> In faxd/Class1Recv.c++, in recvPageECMData line 1373
> 	if (frame.checkCRC()) 
>     becomes
>         if (frame.checkCRC()  && frame.getLength() == frameSize+6) 
>
> This is in the 6.0.4 version... 
>
> Is there an official way I'm supposed to submit this?

The only way that frame.checkCRC() will return true is if the frame data 
passes the data-check provided by the two last bytes in the frame.  In 
other words the modem *did* pass two CRC bytes to HylaFAX.  So I don't 
know the relevance behind the statement that T.38 doesn't pass the CRC, 
because frame.checkCRC() would fail if the last two bytes weren't valid 
CRC.  What I think you're probably saying is that CRC bytes are not 
communicated in the T.38 stream and that the receiving gateway is 
recreating CRC.  (The correctness of that behavior against the T.38 
specification I can't currently confirm.)  This understanding would mesh 
with what you've done in the code and your experience that it resolves 
the problems for you.

Nevertheless, the only conclusion I can reach by your experience and by 
your code changes is that either the T.38 gateway or the T.38 modem is 
regenerating valid CRC on a corrupt set of frame data.  And your 
approach to a solution on that is as good as any.  It costs an operation 
and a comparison looped for each frame in the block, but I think that's 
probably negligible CPU usage for a good cause.  ;-)

Please understand, however, that if the frame with a reconstructed CRC 
is corrupt but yet contains the correct number of bytes that you're 
still doomed.  However, I think the fact that the T.38 stream is in 
bytes rather than bits saves you here... unless a byte gets changed and 
not dropped (which I think is unlikely).

Furthermore, also understand that there is a statistically improbable 
chance that a corrupt frame passes CRC checking even if the CRC bytes 
were not reconstructed.  Even though this is statistically improbable it 
*DOES* happen on rare occasion when ECM is being performed on a line 
that is quite noisy.

Anyway, I've committed your suggested change to the HylaFAX+ repository 
for inclusion in the next release there.

Thanks,

Lee.


____________________ HylaFAX(tm) Developers Mailing List ____________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe [email protected] < /dev/null