[hylafax-devel] Re: RTN: Zyxel firmware bug?

[Dmitry Bely <dbely@mail.ru>]

"Dr. Harald Pollack" <Harald.Pollack@Datanews.at> writes:

Hello, Harald!

> >There is a fax machine, which always responds with RTN to my
> >Hylafax
> 
> May I guess ? It's a Canon machine ?
> 
> >+Zyxel l496e firmware 6.20.
> 
> Do not complain the modem :-) I have a 1496 modem too, and there is (almost) no fax (Canon) 
> machine, which will refuse my faxes :-)
> 
> >I've send there the very simple page
> 
> Please send me the page (+43-1-XXXXX-XXXX), my fax receiver (a Zyxel modem in Class 1 and FREC) 
> will accept almost each fax (also such, whichwere coming from Hylafax and normaly give RTN with 
> Canon).
> 
> >(no tagline, no any black pixel -- just a white space), which is proven to
> >conform to T.4 specs (I checked that)

I had written my original message before I read your comment on
the "byte-aligned" first EOL. So T.4 data was *not* correct -- possibly the
reason for RTN was here. I will fix this bug and then try again. Thank you
very very much!

> Can you save the rawdata, which is sent to modem and send it to my by attach ?
> 
> >and still have the 100% reproductable RTN error
> 
> RTN points to a T.4 error, maybe there is something else I did know before ?
> 
> >(other destinations work fine). What do you think, can it be the
> >Zyxel's firmware bug?
> 
> Sure, maybe they deliver also no correct T.4 data :-) I think I have an old 6.20 firmware too, 
> will try (if I find the EPROMs)

I replaced my 6.21 EPROMs with 6.20 ones, because Zyxel Russia tech
support people said it better detected BUSY. I had not encountered any
difference though...

> >Here is the log:
> 
> That's NOT quite a log, thats only the stuff, which is sent by software and will be called 
> (senseless) initialisation :-)
> 
> >
> >[---cut---]
> >Mar 22 13:55:10.86: [30588]: SESSION BEGIN 00004526 710496211780969
> >Mar 22 13:55:10.86: [30588]: SEND FAX: JOB 1033 DEST 810496211780969 COMMID 00004526
> >Mar 22 13:55:10.86: [30588]: MODEM set DTR OFF
> >Mar 22 13:55:10.86: [30588]: DELAY 2600 ms
> >Mar 22 13:55:13.47: [30588]: MODEM set DTR ON
> >Mar 22 13:55:13.47: [30588]: MODEM set baud rate: 38400 baud, input flow RTS/CTS, output flow 
> RTS/CTS
> 
> Should also try XON/XOFF ...
> 
> >Mar 22 13:55:13.47: [30588]: MODEM flush i/o
> >Mar 22 13:55:13.47: [30588]: <-- [26:ATZ*P7S38.3=1E0V1Q0S0=0H0\r]
> 
> 
> Here you can see, what I mean by 'senseless'! first 'ATZ' and last ATH0 !!!!!! After ATZ the 
> modem IS on hook !!!!!

ATZ*P7S38.3=1 is my initialization sequence, E0V1Q0S0=0H0 was appended by
Hylafax. Yes, it's useless, but I think non-destructive :-). Other
initialization commands below are also Hylafax defaults for Class2.0
(Except +FCQ and +FRQ)

> >*P for russian local settings (country code 230) _affects_ TX level in the
> >fax mode. *P9 is the AT&F default.
> 
> Yes, I know, but I know also, that this (russian firmware) is NOT fully compareable with the 
> common international firmware (keep this please in mind and try also international firmware for 
> fax!)

I don't know how to change the country code "on the fly"!

> >Mar 22 13:55:13.77: [30588]: --> [2:OK]
> >Mar 22 13:55:13.77: [30588]: <-- [21:ATS8=2S7=60&H3&D2&C1\r]
> >Mar 22 13:55:13.79: [30588]: --> [2:OK]
> 
> Why S8 ???

It sets comma pause (Hylafax does not believe to the default value). 

> And why &H3 (will be resetted by AT+FCLASS=2/2.0 and must be
> set by AT+FLO !!!

Hylafax is written to correctly work even with those buggy modems which do
not have explicit flow control command. Yes, for Zyxel it's useless, but
again, non-destructive :-)

> >Mar 22 13:55:13.79: [30588]: <-- [14:AT+FCLASS=2.0\r]
> >Mar 22 13:55:13.89: [30588]: --> [2:OK]
> >Mar 22 13:55:13.89: [30588]: <-- [9:AT+FLO=2\r]
> >Mar 22 13:55:13.90: [30588]: --> [2:OK]
> 
> here you can see that handshake is set by AT+FLO, former &H3 is senseless :-)
> 
> >Mar 22 13:55:13.90: [30588]: <-- [9:AT+FPP=0\r]
> >Mar 22 13:55:13.91: [30588]: --> [2:OK]
> 
> DO NOT USE THIS (and do not ask why :-)

It's not me but Hylafax :-) Even if Packet Protocol is not implemented in
the modem (although it has to be implemented according to T.Class2) AT+FPP=0
should be safe.

> >Mar 22 13:55:13.91: [30588]: <-- [9:AT+FBO=0\r]
> >Mar 22 13:55:13.92: [30588]: --> [2:OK]
> 
> DO NOT USE THIS (and do not ask why :-)

You mean Zyxel does not correctly implement Data Bit Order command???

> >Mar 22 13:55:13.92: [30588]: <-- [10:AT+FCT=30\r]
> >Mar 22 13:55:13.93: [30588]: --> [2:OK]
> 
> NEVER (I repeat N_E_V_E_R) use this command (and also do not ask why :-)

and DTE Phase C Response timeout?

> >Mar 22 13:55:13.93: [30588]: <-- [21:AT+FCQ=2,1;+FRQ=4F,A\r]
> >Mar 22 13:55:13.95: [30588]: --> [2:OK]
> 
> N_E_V_E_R (I repeat N__E__V__E__R) use these commands (and also do not
> ask why :-) 

Why??? I remember you told that Transmit Copy Quality Checking does not
work in 1496, but Receive Copy Quality Checking *does*. e.g.

[...]
<-- [7:AT+FDR\r]
--> [20:+FCS:0,5,0,2,1,0,0,3]
REMOTE wants 14400 bit/s
REMOTE wants page width 1728 pixels in 215 mm
REMOTE wants unlimited page length
REMOTE wants 3.85 line/mm
REMOTE wants 2-D MR
--> [7:CONNECT]
RECV: begin page
RECV: send trigger 022
<-- data [1]
RECV/CQ: Bad 2D pixel count, row 15, got 1729, expected 1728
RECV/CQ: Bad 2D pixel count, row 850, got 2978, expected 1728
RECV/CQ: Bad 1D pixel count, row 1070, got 0, expected 1728
RECV/CQ: Bad 1D pixel count, row 1071, got 0, expected 1728
RECV/CQ: Bad 1D pixel count, row 1072, got 0, expected 1728
RECV/CQ: Bad 1D pixel count, row 1073, got 0, expected 1728
RECV/CQ: Bad 1D pixel count, row 1074, got 0, expected 1728
RECV: 25392 bytes of data, 1075 total lines
--> [16:+FPS:1,43C,E,4,0]
--> [6:+FET:0]
RECV recv MPS (more pages, same document)
--> [2:OK]
[...]

Hylafax uses the same config for both sending and receiving.

BTW, why Zyxel does not disable the commands which actually do not work?
(AT+FBS? even hangs the modem :-)) According to T.class2

[---cut---]
6.1.4.3	Set Parameter Syntax
	+F<parameter_name>=<value>	or
	+F<parameter_name>=<compound value string>
If +F<parameter_name> is supported, and if the <value> or <compound value
string> is supported, the DCE shall set the parameter to the specified
value.  Otherwise, it shall report an ERROR result code, and the previous
value or values shall be unaffected. 
[---cut---]

> >Mar 22 13:55:13.95: [30588]: <-- [15:AT+FNR=1,1,1,1\r]
> >Mar 22 13:55:13.96: [30588]: --> [2:OK]
> 
> Ok, THIS is the ONLY (beside ATZ) command, which is NECCESSARY !!!
> 
> >Mar 22 13:55:13.96: [30588]: <-- [9:AT+FIE=0\r]
> >Mar 22 13:55:13.97: [30588]: --> [2:OK]
> >Mar 22 13:55:13.97: [30588]: <-- [9:AT+FBU=1\r]
> >Mar 22 13:55:13.98: [30588]: --> [2:OK]
> 
> DO NOT USE THESE COMMANDS (I ommit further warning :-)
> 
> >Mar 22 13:55:13.98: [30588]: <-- [23:AT+FCC=1,5,2,2,1,0,0,0\r]
> >Mar 22 13:55:14.00: [30588]: --> [2:OK]
> 
> Ok, correct, but better try AT+FCC=1,5,0,2,0,0,0,0
> 
> >Mar 22 13:55:14.00: [30588]: <-- [7:ATM1L5\r]
> >Mar 22 13:55:14.01: [30588]: --> [2:OK]
> 
> Ok
> 
> >Mar 22 13:55:14.01: [30588]: STATE CHANGE: RUNNING -> SENDING
> >Mar 22 13:55:14.01: [30588]: MODEM input buffering enabled
> >Mar 22 13:55:14.01: [30588]: <-- [14:AT+FCLASS=2.0\r]
> >Mar 22 13:55:14.21: [30588]: --> [2:OK]
> >Mar 22 13:55:14.21: [30588]: <-- [9:AT+FLO=2\r]
> >Mar 22 13:55:14.32: [30588]: --> [2:OK]
> >Mar 22 13:55:14.32: [30588]: <-- [9:AT+FPP=0\r]
> >Mar 22 13:55:14.43: [30588]: --> [2:OK]
> >Mar 22 13:55:14.43: [30588]: <-- [9:AT+FBO=0\r]
> >Mar 22 13:55:14.54: [30588]: --> [2:OK]
> >Mar 22 13:55:14.54: [30588]: <-- [10:AT+FCT=30\r]
> >Mar 22 13:55:14.65: [30588]: --> [2:OK]
> >Mar 22 13:55:14.65: [30588]: <-- [21:AT+FCQ=2,1;+FRQ=4F,A\r]
> >Mar 22 13:55:14.77: [30588]: --> [2:OK]
> >Mar 22 13:55:14.77: [30588]: <-- [15:AT+FNR=1,1,1,1\r]
> >Mar 22 13:55:14.88: [30588]: --> [2:OK]
> >Mar 22 13:55:14.88: [30588]: <-- [9:AT+FIE=0\r]
> >Mar 22 13:55:14.99: [30588]: --> [2:OK]
> >Mar 22 13:55:14.99: [30588]: <-- [9:AT+FBU=1\r]
> >Mar 22 13:55:15.10: [30588]: --> [2:OK]
> >Mar 22 13:55:15.10: [30588]: <-- [23:AT+FCC=1,5,2,2,1,0,0,0\r]
> >Mar 22 13:55:15.22: [30588]: --> [2:OK]
> 
> Why repeating all these (partialy senseless) commands ?

Sam's code is not quite correct. Maybe I will fix this later.

> >Mar 22 13:55:15.22: [30588]: <-- [11:AT+FLI=" "\r]
> >Mar 22 13:55:15.33: [30588]: --> [2:OK]
> >Mar 22 13:55:15.35: [30588]: DIAL S7=60S8=15DT84w64496211780969,
> 
> DO NOT USE other than dialcommands in dialstring.
> 
> >Mar 22 13:55:15.35: [30588]: <-- [33:ATS7=60S8=15DT84w64496211780969,\r]

Why? I need them (because international calls take more time to connect, and 
Zyxel detects BUSY very bad) and they are safe. Also take into account that 
they were generated automatically according to my dialing rules.

> >Actual number is +49 6211780969 (Germany)
> >
> >Mar 22 13:55:56.75: [30588]: --> [4:+FCO]
> >Mar 22 13:55:56.89: [30588]: --> [132:+FNF:00 00 11 80 00 80 48 00 5B 00 80 80 C0 07 02 01 00 01 
> 01 01 01 00 00 11 80 00 80 48 00 5B 00 80 80 C0 07 02 01 00 01 01 01 01  ]
> >Mar 22 13:55:56.89: [30588]: REMOTE NSF "00 00 11 80 00 80 48 00 5B 00 80 80 C0 07 02 01 00 01 
> 01 01 01 00 00 11 80 00 80 48 00 5B 00 80 80 C0 07 02 01 00 01 01 01 01"
> >
> >Seems to be an inkjet Canon machine (country/provider code 00 00 11). Not
> >present in your NSF list yet.
> 
> Are you sure ? I have tried:
> 
> 07:58:07.80 Send:     ATDT0W00496211780969<CR>
> 07:58:57.07 Receive:  <CR><LF>
> 07:58:57.07 Receive:  CONNECT<CR><LF>
> 07:58:58.57 Receive:  <ff><ETX> 
> <NUL><NUL><DC1><80><NUL><80>H<NUL>[<NUL><80><80><c0><BEL><STX><SOH><NUL><SOH><SOH><SOH><SOH>
> 07:58:58.57 Receive:  NSF, obviously Canon, but no station ID

The NSF list you mailed me before, contained only the following Canon record:

NSFTYPE nsftype[] = {
[...]
	{"Canon",
	"\xFF\x03\x20\x00\x00\x11\x90\x00\x85\x5D\x10                "
	"\x01\x0E\x01\x0F\x00\x84\x00\x82\x04\x00\x00\x00\x00\x80\x00",
	"\xff\x03\x23\x00\x00\x11\x80\x00\x80\x5B\x10                "
	"\x01\x00\x00\x84\x00\x00",
	42,33,11,16,FALSE,Type_Canon},

> This IS a Canon, but (as you say) no station ID 
> 
> 07:58:58.57 Receive:  OK<CR><LF>
> 07:58:58.57 Send:     AT+FRH=3<CR>
> 07:58:58.63 Receive:  <CR><LF>
> 07:58:58.63 Receive:  CONNECT<CR><LF>
> 07:58:59.28 Receive:  <ff><ETX>@94276611260         
> 07:58:59.28 Receive:  CSI          06211667249
> 
> It IS the correct station :-)
> 
> 07:58:59.28 Receive:  OK<CR><LF>
> 07:58:59.28 Send:     AT+FRH=3<CR>
> 07:58:59.35 Receive:  <CR><LF>
> 07:58:59.35 Receive:  CONNECT<CR><LF>
> 07:58:59.60 Receive:  <ff><DC3><80><NUL><ce><88>D
> 07:58:59.60 Receive:  DIS 1,3,0,2,3,1,0,5,0[,0]
> 07:58:59.60 Receive:  OK<CR><LF>
> 
> Seems to be an inexpensive machine (no V.17). so retry with AT+FCC=1,3,0,2,0,0,0,0 ...
> 
> >
> >Mar 22 13:55:56.89: [30588]: --> [26:+FCI:         06211667249 ]
> >Mar 22 13:55:56.89: [30588]: REMOTE CSI "06211667249"
> >Mar 22 13:55:56.89: [30588]: --> [20:+FIS:1,3,0,2,1,1,0,5]
> >Mar 22 13:55:56.89: [30588]: --> [2:OK]
> 
> Here you see also ...
> 
> >Mar 22 13:55:56.92: [30588]: REMOTE best rate 9600 bit/s
> >Mar 22 13:55:56.92: [30588]: REMOTE max page width 1728 pixels in 215 mm
> >Mar 22 13:55:56.92: [30588]: REMOTE max unlimited page length 
> >Mar 22 13:55:56.92: [30588]: REMOTE best vres 7.7 line/mm
> 
> Ok
> 
> >Mar 22 13:55:56.92: [30588]: REMOTE best format 2-D MR
> >Mar 22 13:55:56.92: [30588]: REMOTE supports T.30 Annex A, ECM
> 
> Yes, but DO NOT USE in class 2.0 with 1496 modem!
> 
> >Mar 22 13:55:56.92: [30588]: REMOTE best 20 ms/scanline
> >Mar 22 13:55:56.92: [30588]: USE 9600 bit/s
> >Mar 22 13:55:56.92: [30588]: USE 20 ms/scanline
> >Mar 22 13:55:56.92: [30588]: SEND file "docq/doc619.ps;70"
> >Mar 22 13:55:56.93: [30588]: USE page width 1728 pixels in 215 mm
> >Mar 22 13:55:56.93: [30588]: USE unlimited page length 
> >Mar 22 13:55:56.93: [30588]: USE 3.85 line/mm
> >Mar 22 13:55:56.93: [30588]: USE 2-D MR
> 
> There you have the reason for RTN !!!!

Why? Just pretty normal T.4 2-D Modified Read (*not* T.6 2-D Modified
Modified Read)

> >Mar 22 13:55:56.93: [30588]: <-- [23:AT+FIS=0,3,0,2,1,0,0,5\r]
> >Mar 22 13:55:57.04: [30588]: --> [2:OK]
> >Mar 22 13:55:57.04: [30588]: <-- [7:AT+FDT\r]
> >Mar 22 13:56:03.22: [30588]: --> [20:+FCS:0,3,0,2,1,0,0,5]
> 
> Ok, also the reason for RTN

What specifically? Unlimited page length? 

> >Mar 22 13:56:03.22: [30588]: --> [7:CONNECT]
> >Mar 22 13:56:03.22: [30588]: SEND begin page
> >Mar 22 13:56:03.34: [30588]: <-- data [299]
> >
> >There is no RTC in the end. Other data is also valid (leading EOL etc.) --
> 
> maybe, but receiver expects 2D mod. Read data and I think, you have not submitted correct 2D 
> data...
> 
> >I have checked the generated TIFF (as you know, Hylafax is just a TIFF ->
> 
> Please send me this TIFF ...

Damn "byte-aligned" first EOL :-(

> >Mar 22 13:56:03.34: [30588]: SENT 299 bytes of data
> >Mar 22 13:56:03.34: [30588]: SEND 2D RTC
> 
> Hylafax send RTC !!!!!! Why ? Look into your class 2.0 standard to the chapter "End Page 
> Transmission", in my edition, there I can read:
> 
> "The DTE indicates the end of page by appending a Post Page Message <DLE><ppm> Transparent Data 
> Command to the DCE. This will cause the DCE to append an RTC (6 EOL) pattern as needed, and enter 
> Phase D by sending the selected T.30 Post Page message ..."
> 
> I can read here ".. will cause the DCE to append an RTC ...". No reason for DTE to do this!
> 
> And as you know (in the meantime :-), 1496 is also according the class 2.0 standard!!!

Oh, God! I have (and possibly Sam had) the draft Recommendation T.class2 (30
June 1994) which says:

[---cut---]
8.3.3.5	Phase C Data Format
[...]
Note 2: The DTE shall include a final RTC, since the DCE will not append an
RTC in response to <DLE><ppm> commands.
[...]
8.3.3.7	End Page Transmission
The DTE indicates the end of page by appending a Post Page Message
<DLE><ppm> Transparent Data Command to the DCE.  This will cause the DCE to
enter Phase D by sending the selected T.30 Post Page message.
[---cut---]

Did you quoted the final revision of T.class2? Which revision Zyxel follows 
to?

> >Mar 22 13:56:03.34: [30588]: <-- data [10]
> >Mar 22 13:56:03.34: [30588]: SEND end page
> >Mar 22 13:56:03.34: [30588]: SEND send EOP (no more pages or documents)
> >Mar 22 13:56:03.35: [30588]: <-- data [2]
> >Mar 22 13:56:09.46: [30588]: --> [5:ERROR]
> >Mar 22 13:56:09.46: [30588]: <-- [8:AT+FPS?\r]
> >Mar 22 13:56:09.57: [30588]: --> [1:2]
> >Mar 22 13:56:09.57: [30588]: --> [2:OK]
> >Mar 22 13:56:09.57: [30588]: SEND recv RTN (retrain negative)
> 
> Yes, and it seems this will be CORRECT ! Page is rejected, NEVER MORE call this fax machine with 
> your fax program, you will get EVERYTIMES this RTN!

It's hard to believe, but RTN sometimes indicates the real noise on the
line :-) So decision not to call some destination after RTN is too radical
:-)

> >Mar 22 13:56:09.57: [30588]: <-- [23:AT+FIS=0,1,0,2,1,0,0,5\r]
> >Mar 22 13:56:09.69: [30588]: --> [2:OK]
> >
> >Limit max speed at 4800 and try again.
> 
> Do not waste time !

Yes! It's better to fix the bug before :-)

> best advice: take an old 486DX33 machine, install OS/2 Warp 3 and faxworks (from bonus pack) and 
> forget all other...

Maybe I'll do so :-)

Hope to hear from you soon,
Dmitry