Re: [hylafax-users] mis-interpreted senderID?

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Mark wrote:

> Lee Howard <faxguy <at> howardsilvan.com> writes:
>
>  
>
> > Mark wrote:
> >
> >    
> >
> > > Dec 07 13:17:09.10: [ 8675]: <-- [9:AT+FRH=3\r]
> > > Dec 07 13:17:09.37: [ 8675]: --> [7:CONNECT]
> > > Dec 07 13:17:11.08: [ 8675]: --> [2:OK]
> > > Dec 07 13:17:11.08: [ 8675]: REMOTE TSI "0q       +4618343428"
> > >
> > >      
> > Could you reproduce this log for us, but with SessionTracing at 0xFFF.  
> > It would be nice to see the HDLC frame data here.
> Here is a log file with session tracing 0xFFF  you can access online.
>
> http://www.alsike.net/c000000636

Here is the relevant information (the HDLC frame):

Dec 08 17:01:55.71: [16734]: <-- [9:AT+FRH=3\r]
Dec 08 17:01:55.97: [16734]: --> [7:CONNECT]
Dec 08 17:01:57.69: [16734]: --> HDLC<25:FF C0 C2 1C 4C 2C CC 2C CC 1C 8C 6C 2C D4 04 04 04 04 04 04 04 8E 0C 4F 93>
Dec 08 17:01:57.69: [16734]: --> [2:OK]
Dec 08 17:01:57.69: [16734]: REMOTE TSI "0q       +4618343428"


It's very clear that the sender actually is transmitting the "0q" part 
of that.  Notice the "8E 0C" there at the end of the HDLC frame.  
TSI/CSI is encoded backwards, so the last becomes first and the first 
becomes last.  The "4F 93" is the FCS (CRC) bytes, and the fact that 
they're there and the fact that they properly compute-out indicates that 
the entire frame is, indeed, correct as transmitted by the sender.

So I sent a fax to that number given in TSI...

Dec 08 10:24:45.12: [13840]: <-- [18:ATDT0114618343428\r]
Dec 08 10:25:10.58: [13840]: --> [7:CONNECT]
Dec 08 10:25:12.10: [13840]: --> HDLC<25:FF C0 02 04 04 04 04 04 04 04 04 04 1C 4C 2C CC 2C CC 1C 8C 6C 2C D4 96 C4>
Dec 08 10:25:12.10: [13840]: --> [2:OK]
Dec 08 10:25:12.10: [13840]: REMOTE CSI "+4618343428"

Dec 08 10:25:12.10: [13840]: <-- [9:AT+FRH=3\r]
Dec 08 10:25:12.38: [13840]: --> [7:CONNECT]
Dec 08 10:25:12.38: [13840]: --> HDLC<9:FF C8 01 02 76 5F 00 2B 22>
Dec 08 10:25:12.42: [13840]: --> [2:OK]
Dec 08 10:25:12.42: [13840]: REMOTE best rate 14400 bit/s
Dec 08 10:25:12.42: [13840]: REMOTE max A3 page width (303 mm)
Dec 08 10:25:12.42: [13840]: REMOTE max unlimited page length
Dec 08 10:25:12.42: [13840]: REMOTE best vres 7.7 line/mm
Dec 08 10:25:12.42: [13840]: REMOTE format support: MH
Dec 08 10:25:12.42: [13840]: REMOTE best 0 ms/scanline


First thing that I noticed was that there was no NSF signal (most fax 
machines send NSF as a receiver).  Second thing there is that the 
whitespace appears on the other side of the numbers.  In your log it 
shows up in the HDLC frame after the numbers, and in my log it shows up 
before.  The third thing that I notice is that this receiver is rather 
handicapped.  It doesn't support ECM, and it doesn't support 2-D 
compression.  So I can tell right away that it's not a typical fax 
machine - and it's probably fax software running of some kind.

I believe that you've told me that this system (the one you sent from 
and the one I sent to) is using a MultiTech 5634 running in Class 2.  
This seems to make things add up.

I would strongly urge you to use the modem in Class 1 or 1.0 - 
irrespective of your serial setup.  However, Class 2.0 or 2.1 would be 
far better than Class 2 - which is quite buggy.

That said, I think that this excersize has exposed a bug in the Class 2 
firmware that I think can be avoided by padding the LocalIdentifier with 
whitespaces.  Try modifying LocalIdentifier in the modem config file to 
this:

 LocalIdentifier:  "+4618343428         "

That may prevent the bug in the Class 2 firmware from surfacing.

Lee.

____________________ 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*