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

[Dr. Harald Pollack <Harald.Pollack@Datanews.at>]

On 24 Mar 2000 13:31:40 +0300, Dmitry Bely wrote:

Hello Dmitry!

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

:-) I hope, the big Hylafax - Zyxel - problem will by solved your work !

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

BUSY problem is always existent (either in data mode or in voice mode) and I know no 
firmware version, where BUSY is ok in all modes :-)

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

There is only ONE initialisation: ATZ :-) all other (except your level setting *P) is 
redundant.

>(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, and this I have never complaint :-)

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

It is a problem, I know, you must accept limitations of russian firmware, I think.

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

I know, what S8 means, but why Hylafax set it to this 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 :-)

But AT&H3 is no standard command for hardware flow control (I think USR courier has other 
value than 3)

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

It is a very bad thing, to send commands to the modem, which will not be implemented or not 
neccessary!

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

There is no real 'right' implementation of this command, because one of the first Rockwell 
fax data pumps had a firmware bug and because of some major fax software, this bug was 
continued in other modems too. Zyxel has copied the 'bug' and you will get unpredictable 
results, if using this command in conjunction with other 'non implented' commands.

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

Does NOT exist !!! Only T.30 is valid, not this AT+FCT !!! If other end is a real fax 
machine, it does not know anything about this !$%&*+#! command (based on the 'wish' of a 
well known softwarehouse in ITU commite).

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

It was partially implemented by Donald Lin but it never worked (but works now in Elite).

>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

??? obviously, faxsoftware had check copy quality ?

>--> [16:+FPS:1,43C,E,4,0]

Are you sure, this is a response of 1496 modem ?

>Hylafax uses the same config for both sending and receiving.

There are so LESS neccessary additional intitialisation command. Hylafax overconfigurizes 
the modem and maybe modem crashes therfore ?

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

Zyxel modem is made by chinese men. And chinese men are very polite. They never will say to 
you, that YOU have done a fault. It is a totaly other culture. They will never correct a 
fault of your, if they must assume, this would be inpolite. So a lot of commands is not yet 
implemented, but modem answer - very polite - with OK.

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

Chinese people will not do so :-)

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

In fax mode, the 1496 series modems are VERY SENSITIVE to 'multiple commands'. Best way is, 
to use for each single command an leading AT and a trailing carriage-return. Believe me!

>The NSF list you mailed me before, contained only the following Canon record:
>
>NSFTYPE nsftype[] = {
>[...]
>	{"Canon",

This is NSC/NSS..

>	"\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",
This is NSF...
>	"\xff\x03\x23\x00\x00\x11\x80\x00\x80\x5B\x10                "
>	"\x01\x00\x00\x84\x00\x00",

>Damn "byte-aligned" first EOL :-(

:-)

It might be also 'byte-aligned' EOLs in RTC !!!


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

No, the final ITU-T.32 is exactly the above text, but ...

>Which revision Zyxel follows to?

TIA/EIA-592 which is in fact the Class 2.0 standard. ITU T.32 (or T.Class2) was corrected 
to Class 2.1 ...

But nevertheless, DTE can submit RTC to DCE before sending <DLE><ppm>, but THIS RTC MUST BE 
correct (no padding bits in EOL, last bit of 6th EOL must be the last byte), than the 
additional RTC from modem (DCE) will not harm (are than 12 EOLs). But normally, fax 
software send also byte-aligned EOLs in RTC and send some additional zero bytes to DCE. 
THIS IS THE FAULT.

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

Not in reality :-)

It is a 'nonwritten' rule, that RTN means 'over and out'. No sense to repeat with same 
equipment.

Even if you send pure nonsense to a faxmachine (but correct first EOL and correct RTC) it 
will response with RTP :-)

> So decision not to call some destination after RTN is too radical :-)
>
It is the ONLY result from an RTN !!! Sorry, but you can try and try and try, if you 
repeat, you will yield RTN again and again (I have tested a countles number of real fax 
machines, all will behave in this manner).

But if T.4 data is formed correct, than you will never see any RTN more :-)

or, if you see RTN, than T.4 is  not correct. So simple :-)

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

Yes, and I hope you will 'publish' your correction to all Hylafax users (because there are 
soooooooooooo many complaints at Zyxel support :-)

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

With FaxWorks (and my own program :-) I have NEVER SEEN any single RTN ...




Mit herzlichen Gruessen / Yours sincerely

Dr. Harald Pollack

Harald.Pollack@DATAnews.at






____________________ HylaFAX(tm) Developers Mailing List ____________________
 To unsub: mail -s unsubscribe hylafax-devel-request@hylafax.org < /dev/null