Re: [hylafax-users] Dropping Faxes -- With Logs

[Todd Patton <todd@xxxxxxxxxxx>]

I apologize for the delay - I have been on a priority project out of
town. I am back working on this and have appended the thread. 

On Tue, 2007-01-16 at 10:06 -0800, Lee Howard wrote:
> Todd Patton wrote:
> 
> >Jan 15 23:09:59.20: [ 1845]: <-- [11:AT+FRM=122\r]
> >Jan 15 23:10:00.42: [ 1845]: --> [7:CONNECT]
> >Jan 15 23:10:00.42: [ 1845]: MODEM input buffering enabled
> >Jan 15 23:10:00.42: [ 1845]: MODEM set XON/XOFF/FLUSH: input ignored,
> >output generated
> >Jan 15 23:10:04.02: [ 1845]: Timeout awaiting synchronization sequence
> >Jan 15 23:10:04.22: [ 1845]: MODEM TIMEOUT: reading line from modem
> >Jan 15 23:10:04.22: [ 1845]: MODEM <Timeout>
> >Jan 15 23:10:04.22: [ 1845]: <-- [11:AT+FRM=122\r]
> >Jan 15 23:10:11.22: [ 1845]: MODEM TIMEOUT: reading line from modem
> >Jan 15 23:10:11.33: [ 1845]: --> [2:]
> >Jan 15 23:10:11.33: [ 1845]: --> [2:OK]
> >Jan 15 23:10:11.33: [ 1845]: <-- [9:AT+FRH=3\r]
> >Jan 15 23:10:11.67: [ 1845]: --> [7:CONNECT]
> >Jan 15 23:10:12.61: [ 1845]: --> [2:10 03]
> >Jan 15 23:10:12.61: [ 1845]: --> [10:NO CARRIER]
> >Jan 15 23:10:12.61: [ 1845]: MODEM No carrier
> >Jan 15 23:10:12.61: [ 1845]: <-- [9:AT+FRS=7\r]
> >Jan 15 23:10:42.61: [ 1845]: MODEM TIMEOUT: reading line from modem
> >Jan 15 23:10:42.61: [ 1845]: MODEM <Timeout>
> >Jan 15 23:10:42.72: [ 1845]: --> [2:]
> >Jan 15 23:10:42.72: [ 1845]: --> [2:OK]
> >
> 
> Although the final demise of the first log that you posted was not 
> precisely the problem you see here (which shows the T.31 protocol demise 
> of the second log), the first log did exhibit several of these same 
> kinds of messy protocol sequences.
> 
> Basically what you see there is HylaFAX's Class 1 driver telling the 
> modem to listen for V.17 12000 bps signalling, and the modem reports 
> CONNECT back indicating that it found it.  The modem then starts 
> delivering demodulated data, which isn't being logged here, but would 
> probably show us a sequence of 1-bits (0xFF bytes).  These are called 
> "flags" and I suspect that they continued uninterrupted for the 3.6 
> seconds until that first timeout occurs.
> 
> Now, one could say that HylaFAX should not timeout at 3.6 seconds, but 
> instead should wait 5 or 10 or 30 seconds here.  However, 3.6 seconds is 
> already very generous per the spec requirements, I believe.  This is 
> twelve times the length of time permitted by T.4 A.3.1.  If the sender 
> needs to use flow control at this point they should be using sync flags 
> (0x7E) instead of 0xFF.  So anyway, HylaFAX then attempts to abort the 
> AT+FRH=122 command.  The first "MODEM TIMEOUT: reading line from modem" 
> apparently is because the modem did not honor the method of aborting 
> that HylaFAX uses by default.  This may have only been a temporary 
> problem, or it's possible that the modem needs to be configured 
> differently for this to work better.  However, as in this case, this 
> abort problem is not usually detrimental to the session.
> 
> Now, at this point we really don't have an option to re-issue the 
> AT+FRM=122 command as you see happening there.  The carrier flags are 
> only sent at the outset of a carrier, and the modem won't be able to 
> train.  So the fact that we see no CONNECT message following it is no 
> surprise.  The subsequent timeout was inevitable.  After aborting an 
> AT+FRM=122 command we only have an option to do AT+FRH=3... which we do 
> after the second "MODEM TIMEOUT: reading line from modem" there.  
> (Notice that the abort seems to have worked the second time - so the 
> abort problem must be limited in its scope.)
> 
> The modem unfortunately reports CONNECT here almost immediately after 
> AT+FRH=3 (listen for V.21 HDLC signalling).  It probably mis-reported 
> the V.17 signalling with the CONNECT.  This is a common shortcoming with 
> many modems in their V.21 HDLC detection.  They seem to report CONNECT 
> at any carrier signal without first checking to see if the demodulation 
> of that carrier results in HDLC.  So the subsequent "NO CARRIER" message 
> from the modem could mean just about anything from a loss of V.17 
> carrier or simply the chance demodulation of a DLE+ETX in the audio 
> (which appears to have been the case).  The modem then begins to listen 
> for silence (before transmitting some signal back to the sender)... but 
> if we believe the modem here it then waits 30 seconds for silence and 
> still never gets it.
> 
> So if we trust the modem as much as it appears to be trustworthy, it 
> would seem that the sender transmitted way too many 0xFF flags in V.17 
> before sending any image data.  There is no guarantee that the sender 
> actually started transmitting any image data at all, either.  However, 
> the rest of the logs seem to indicate that it does... and that would 
> lead me to believe that it's using the 0xFF V.17 flags inappropriately 
> as an extended flow control.
> 
> If my interpretation is closely correct, then you should see this 
> happening only with some senders.  Is that correct?  If so, do you know 
> what kind of sender it is?

This is correct but unfortunately, I haven't been able question the
particular senders and I have not been able to replicate it with
machines that I have access to.

> 
> I think that maybe extending the timeout from 3.6 seconds to maybe 30 
> would be a useful test.  Attached is a patch that does this.  Let me 
> know if a code patch is not useful for you.
> 
> Lee.

Lee, forgive my ignorance but I am not sure on how to apply this patch. 
I thought the procedure was to
 
1. download the tarball
2. extract the tarball
3. copy the patch to the tarball directory
4. issue the command
patch -p1 < hylafax-awaitsynctimeout.patch
5. ./configure;make;make install

Again please forgive the unix101 question. I should of submitted this to
my local SLUG list.

./todd













-- 
Todd Patton <todd@xxxxxxxxxxx>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2 (GNU/Linux)

mQGiBEVPhocRBADnmDhjjxnoVNY3fY6UtkUdQ8dZtMkjOHhZOriP0kliQMJ4e+6M
VzZdJiIH2qAXKzKAvkt6uGFOqwI3haDtBqrgl4yKVZd8YRWRlfCw34Q+jJNlzpRa
Uhbyq8tGSJmI/KHnd4odDwXCC2golBS8/LT1mghkcnio1Qu7g7m0DejaowCg5FM1
aYmKRGalsMReJeTrr2rNQIsEAMgnmYyP3/Dc2QQliCy7U+W2qZkENr3ZOQIhOk7M
H+l+lmSjk0iUk3bvOFdblRsSWUxImo0i3stpZnFEnDQ8akiNR9F8kRnL5rftNTUA
418TFvfvwjvM8iMUka8jMyiuNezh58YD8iqqXMcp7oh5IO0648N9NR3SOVR+QVek
IjwBA/99avAkiH4G5GUsEMXHYNTNi5J+vtlnjCDmUk9Ykfx/siUmvzDPZ3++SZym
JzKkSGKdcb+DLp6bRhCPt+lWCSfZisL1yVFKTJrNQ5NYTwOgq43Ir6LPqKKqL+za
Bm2ZfpXDHZKBBCS0/vcfGRJil/eeps19KvqPbSdYTANoPSVmGbQhVG9kZCBELiBQ
YXR0b24gPFRvZGRAYWNwZGF0YS5jb20+iGYEExECACYFAkVPhocCGwMFCQBPGgAG
CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRASYxowRTGgvUlaAJ9jI5qjELlLHFW7
p7s+ZEYVlXBKEwCfXsEcwXqb3zb+1N0W7Pq8Kia1Hw+5Ag0ERU+GqhAIANlM3lwj
jAdY+AEF4TS2WHfNAuerjQewb8t7s6ZPwJ53P8bcFcD4s6z+JDOxz9WsQV1XTweC
p8htCS7UCBPnaA7vERqzln9sF6vgC0M7CL/Onr/DgiITS+ThJd5HY1Emd8YKDoEc
NAXO04QgPARr2pQxCr47G4YeIfv25sVJGE+8o94Lj9bjRr3w961gO4nzCjIwhusR
wmtwHamFKMLpVPFUCslePGVFmmLJf3z/22hpPKsvHV7RhsCQU+WhXh0b+e99d1M9
QY+6Td4MMjAPbXr9n9FE34GNEfP+2j2VScPCT8lVMiSru5zKt9dLnTkJrR1oIxSx
6JqK/BWQpogG0l8ABREH/3MZVL8uEKANv458kPQ5/DbkbL/ItttbiNN+M5+E2Id5
lPcub1d+rfYWRfpsxCmCYOrM7Vh7QMLLdTyBsq/Jq4TrmA/Ojlf6dF80vAB+HOOF
j97hcFfC/eeXRm9AulvlAxRGUTmQ0Emq1RDSfJNwsFGMip/7kZ8KnVBp6PTM1Rop
Uqhi30bsd1Odm2WFQxZloM3ZGdyqngi8sMlma35QhrRrr6DMqNFjuRhtDhAcb3Nr
0DgaRRAOiT2ybug3bBc9kCbrxRoZy/eLIx3uWln6zcCM9Qi2QbMsPg7F6pKZjtQU
mqaaJSeJIVghMd+xgWWVu28NAZtt8sVVAGEWOMnI1nKITwQYEQIADwUCRU+GqgIb
DAUJAE8aAAAKCRASYxowRTGgvVKJAJ982NV3i/KP3FDoWXCEn62rO81hKwCcCh+2
eZhAEyHGlvtxO1lMm4IiTno=
=Mz/h
-----END PGP PUBLIC KEY BLOCK-----



____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*