Re: Bug fix (not sure how to submit)

On Jun 25, 2010, at 2:22 AM, Lee Howard wrote:

> 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.  ;-)
> 

Yeah, the problem is that T38 doesn't pass the CRC. Instead it sends an additional packet that says "the CRC that I received was OK" This means that if the FOIP box has a bug, and gets a valid CRC, but then loses some data, it sends on bogus data, but still says "The CRC that I received was OK". It's a flaw in the T38 Spec, IMHO, but there isn't much that I can do about that... 

> 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).
> 

yeah, the problem seems to be entire packets being dropped, so I think that having the correct number of bytes, but the data being munged seems unlikely from my experience. 

> 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.
> 

True, but in all of those cases, we're doomed in the previous version just as much as in the new version so, no loss... 

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

Thanks.

Brian Postow
Senior Software Engineer
Acordex Imaging Systems


____________________ 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