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

[Dmitry Bely <dbely@mail.ru>]

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

Hello, Harald!

> >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 have already made the fix and the problem seems to be solved finally --
Canon machines work!!!

[...]

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

The flow control command are specified in per-device config files and
can be configured separately for any modem.

Because some modems do not have a separate command for the fax flow control
(I have such Class2 modem, based on the AT&T chipset), Hylafax sets flow
control in the data mode, then in the fax mode. Also take into account,
that Hylafax can *work* in data mode -- it supports adaptive answer
feature.

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

Disabled :-)

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

I think it's true for Class2, but *not* for Class2.0. In Class 2.0 Zyxel
expects LSB2MSB bit order both for sending and receiving while in Class 2
it expects MSB2LSB for receiving (infamous Rockwell bug).

> and you will get unpredictable 
> results, if using this command in conjunction with other 'non implented'
> commands.

I also do not see why +FBO=0 is dangerous (BTW, it's AT&F
default). According to the standard: 

+FBO=0 selects direct bit order for both Phase C data and for Phase B/D
data: the first bit transferred of each octet on the DTE-DCE link is
the first bit transferred on the GSTN data carrier.

You tell that it's not implemented. Then why AT+FBO=? reports 0,1 ???

OK, that's possibly strange Chinese mentality. Disabled in the off-chance
:-) 

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

Disabled :-)

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

The software also checked received data, but the +FPS statistics was
produced by the modem.

> >--> [16:+FPS:1,43C,E,4,0]
> 
> Are you sure, this is a response of 1496 modem ?

Yes, I'm quite sure. BTW, in Class2 mode +FPS values are decimal.

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

My U-1496 6.20R never crashes with Hylafax. But if you enter any terminal
program and issue AT+FBS? it will :-)

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

So Zyxel modems 
a) do *not* comply with the standards -- on the contrary they obviously
violate them.
b) I cannot ever imagine how these Chinese wrote their programs -- error
checking is the cornerstone of any serious software project :-)

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

What may happen? It will dial the wrong number? Some commands will be ignored?
Something totally unpredictable will happen? :-)

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

Yes, I had just misarranged fields in your structure :-)

> >Damn "byte-aligned" first EOL :-(
> 
> :-)
> 
> It might be also 'byte-aligned' EOLs in RTC !!!

But I think first EOL in the RTC sequence can be zero-padded
("byte-aligned")? Or it's also prohibited?

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

RTP means that page has *acceptable* quality (page good). How the remote
should react if it has encountered, say, 20 consecutive bad lines (due to
the real noise), or, say, 50% bad single lines (and very correct first EOL
and trailing RTC)? Send RTP? But the page is *unreadable*, and should be
retransmitted.

BTW, the following is from *your* logs
(http://www.hylafax.org/archive/1998-03/msg00207.html):

[...]
09:49:42.06 {01 200} Action:   Phase C 2.0 Message transmission 1.07s
09:49:42.06 {01 200} Action:   Parameter: Fine 7200 V.29/V.17 2-D mod.
Read 10 ms/line (pad=0) 1.13s

... all data was sent ...

09:49:58.75 {01 200} Info:      199 bytes faxdata [timeout 48 sec]
09:49:58.75 {01 200} Send:     <DLE>, 0.16s
09:49:58.75 {01 200} Debug:    12650 bytes sent (74 DLE inserted)
0.19s
09:50:13.66 {01 200} Receive:  <CR><LF>
09:50:13.66 {01 200} Receive:  ERROR<CR><LF> 0.03s
09:50:13.66 {01 200} Action:   Phase D 2.0 Post-message procedure
0.15s
09:50:13.66 {01 200} Send:     AT+FPS?<CR> 0.19s
09:50:13.69 {01 200} Receive:  <CR><LF> 0.19s
09:50:13.69 {01 200} Receive:  2,96E,5,1,0<CR><LF> 0.22s
09:50:13.69 {01 200} Receive:  OK<CR><LF> 0.25s

The above (first) value of '2' means RTN ! Faxmodem can NOT decide,
what to do, so fax software starts to send NEXT page (faxsoftware
should NEVER RETRANSMIT a page).

09:50:13.69 {01 200} Action:   Phase B 2.0 Pre-message procedure 0.41s
09:50:13.69 {01 200} Send:     AT+FDT<CR>
09:50:28.00 {01 200} Receive:  <CR><LF>
09:50:28.00 {01 200} Receive:  +FCS:1,3,0,2,1,0,0,3<CR><LF>
09:50:28.53 {01 200} Receive:  <CR><LF>
09:50:28.56 {01 200} Receive:  CONNECT<CR><LF> 0.04s

And this decision was ACCEPTED from remote receiver! training has
passed and modem had done a FALLFORWARD to 9600 bps!!!

Forgive me, but I MUST SAY: the best modem on world :-)
[...]

And after that you say "never call this destination after RTN"??? :-)

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

See *your* logs above :-)

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

Some people besides me are already testing the fixes now :-)

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

Look at your logs above again :-)

BTW, Harald, may I publish our correspondence in the Hylafax mailing list?
I think it may be interesting for many people there :-)

Hope to hear from you soon,
Dmitry




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