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

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

On 28 Mar 2000 20:33:33 +0400, Dmitry Bely wrote:

Hello Dmitry!

First of all, let me say, that it is VERY delightful, to discuss with you!

I think, I have remarked, that there are so LESS people, which understand the problems, and I am 
sure you are 'sending on the same frequence' as I do :-)

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

Victory!

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

:-) But there is (almost) NO difference between modems :-) In my fax programs, there is (with one 
exception) NO diferrence handling of different brand modem. If somebody has enough experiences, 
than the only result is, that in fax mode, all modems behave (almost) EQUAL. The only difference 
in class 2.0 (some firmware versions of USR Courier) is, that in case of no MCF is reported in 
FPS, the response ERROR must be treated carefully. Some firmware versions of ELSA microlink modem 
(old 28k8 datapump) behave also mysterious. But in common, there is NO neccessety to treat modems 
different or even do a different setup/initialisation.

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

In this case, the AT+FCLASS=2 (or 2.0) command sets flowcontrol accordingly to modems capability. 
This is often XON/XOFF, but it works.

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

Yes, but with AT+FAA=1 the implicit change of FCLASS also selects correct fax flow control.

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

There are some differences in Zyxels modems. 1496 series behave other than Elite 2864 and Omni 
series behaves (slightly) other than ELite and U90 series behaves other than all of them.

The reason why is, that developer have changed and product manager has changed. They have 
different sourcecode for each modem type and I think, nobody understands (even his/her own 
written) code after a few weeks :-))) All firmware code is written in assembler and for each main 
part (fax, voice, data and even different modulations) they have distinct developer teams, who 
put there code into one big bucket, which is merged if linking for the 'real' firmware.

I have (alpha and beta) firmwares which are optimized for fax or for voice or for data, but it is 
VERY HARD, to get (beta) firmware, where all parts are working without misbehaviours.

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

The exception is, that 1496 firmware is 'out of control'. I know a few facts, of the 
implementation of Donald Lin, and I know also, that Donald was an excellent developer, but he was 
'not under control', will say, he has done a lot of experiments and some features may look like 
they work, but they are either pure dummies or they have even other (bad) sideeffects.

Is all NOT compareable with Elite (main fax developement also done by Donald), where no 
experiments took place. Omni and U90 were developed by other people with (almost) no relationship 
to 1496 or Elite.

So please, do not say 'Zyxel' if you only mean a certain modem, please say '1496 series' modem to 
distinguish them well.

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

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

Oh. Yes, I have forgotten, this (hex values in class 2.0) was corrected after Donald had 
withdraw, because some customers had complaint :-) before, both class 2 and 2.0 have decimal 
response...

>So Zyxel modems 

Say better 'all modem on the market' :-)

>a) do *not* comply with the standards -- on the contrary they obviously
>violate them.

No modem manufacturer has the money, to implement all commands and responses. Most of them use a 
workable subset, some of them (like Zyxel) do not hide this fact very well :-)

>b) I cannot ever imagine how these Chinese wrote their programs

I think NOBODY can imagine, how they write their programs. I have listings of PARTS of the fax 
routine in assembler, but (or because) they are in M68000 code, I cannot understand the code 
(sorry, I can only Z80 and 86x assembler).


>-- error checking is the cornerstone of any serious software project :-)

Maybe 'serious', but 'unpayable'. Developers tend to never finish their work, product manager 
tend to say, that work is finished, even if it is not started, and marketing people sell 
products, which are not even concepted :-)

>What may happen?

Would often give ERROR condition, but WITHOUT the 'ERROR' response!!! Is a problem of internal 
interrupt routines (maybe system immanent to M68000 CPU ?) in 1496 series. Was partialy fixed in 
Elite and does even not work well in Omni and U90 series. So in fax mode, better try to use 
SINGLE AT-commands.

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

Yes, all three is possible (really unpredictable :-)

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

You have got it!!!!!!! Nobody else had understand me up do now :-))

FIRST EOL in RTC - which is in fact LAST EOL of picture data - could be padded by zero bits. The 
other five EOLs should never be padded (or byte-aligned or whatever). 

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

Depends on the capability of receiver and if either low (204x98) or high (204x196dpi) resolution 
or if 1-D mod. Huffman or 2-D mod. Read. There is no written rule, how receiver should really 
react. Former european (German, Swiss, France, Austria etc) telecoms have their own tests on fax 
equipment and there exists a virtual ErrorPage-1 and ErrorPage-2 (virtual, because not not the 
picture has errors, only the transmitted DATA of the picture must have errors :-).

ErrorPage-1 is of that kind, that receiver should even accept by MCF and ErrorPage-2 must be 
accepted by RTP. There is NO TEST for RTN at all (is an 'over and out' condition therefore :-)

I have two or three different 'real received' ErrorPage-1 data, but the differ slightly. I would 
say, all till 5 % of single line errors should be accepted by MCF. 

I have no ErrorPage-2 data, but I had received data sometimes ago and the difference (as far as I 
remember) was, that ErrorPage-2 contains one or more consecutive bad lines. Therefore I suggest, 
if any consecutive bad lines exist, RTP is the correct response.

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

keep in mind, that 'real fax machine' tend to have NEVER consecutive bad lines and have (almost) 
never any more than one or two bad scanlines.

All we know about bad scanlines, bad fax pages or so, we know from fax modems !!!


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

fine :-)

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

Correct. The above behaviour is bow to the reality :-)

Phase_D()
...
if (FaxClass == FCLASS2)
	{
	sprintf(tmp,"AT%s=%u\r",fet_str,pend == PPM_EOP ? 2 :
		pend == PPM_EOM ? 1 : 0);
	if (put_modem(tmp,NULL) == FALSE) return(-1); // send AT+FET=
	}
else
	{
	// Phase D actually handled in Phase C by <DLE> and .,;
	if (pend == PPM_EOP) return(3); // go to Phase E

Here you can see, that post page response is totaly ignored if it was last page.

	if (r == 1) // Phase C has ERROR (== no MCF) received
		{
		sprintf(tmp,"AT%s?\r",fpts_str);
		if (put_modem(tmp,NULL) == FALSE) return(-1); // PPRCode erzwingen ...
		}

Sorry for mixing comments in english and german, but 'erzwingen' meens 'force' :-)

	else
		{
		SesV->PPRCode = PPR_MCF; // alles OK
		return(0);    // go to Phase B
		}
This is the result of the above mentioned difference of behaviour of some modems. I need no 
special setup, I decide, that if modem DID NOT response ERROR, than I will assume MCF.

	}
breaktime = systime + phase_D_timeout; // 3 retries each 6 sec

Look at the line above! I also do T.30 timeout checking in Class 2/2.0 !!!!!!

ret = 0;
SesV->PPRCode = HNGCode = -1;
// now wait for +FPTS (or FPS: after page error)
for (;;)
	{
	if (systime > breaktime)   { ret = -1; break; }
	res = get_modem();
	if (res == NULL)
		{
		DosSleep(1);
		continue; // bis Timeout
		}
	Deb(res,0);
	if (strstr(res,ok_str) == res) break;
	if (strstr(res,fpts_str) == res)
        {
		s = strchr(res,':');
        if (s) sscanf(s,": %hd",&SesV->PPRCode);
        continue;
        }

PPRCode at this place does no more influence the behaviour of fax software. Even if RTN is 
received, fax transmission will continue. Why ?

In case of RTP, modem itself will do a retrain (fallback or fallforward), so faxprogram needs not 
to react. And in case of RTN I have decide (after long time of collecting experiences :-) to 
continue also.

If RTN was really sent from receiver, because of an unreadable page, than we will try next page. 
If receiver would signal 'over and out' by RTN, well, than the receiver will cut the line and I 
need not to think about what will go on :-)

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

Yes. That's the 'normal' condition after a RTN, if receiver had not decided to quit.

>training has passed and modem had done a FALLFORWARD to 9600 bps!!!

Yes, maybe the RTN was a signal to do a FALLFORWARD, who knows ? :-)))

>Forgive me, but I MUST SAY: the best modem on world :-)
>[...]
>
>And after that you say "never call this destination after RTN"??? :-)

I have forgotten to mention, that this above statement is only valid for faxsoftware which is NOT 
FREC or FSEND :-)))

>> But if T.4 data is formed correct, than you will never see any RTN more
>> :-)
>
>See *your* logs above :-)

As I said, it will be right for (all?) software, EXCEPT FREC/FSEND :-)

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

VERY GOOD!

>> With FaxWorks (and my own program :-) I have NEVER SEEN any single RTN
>> ...
>
>Look at your logs above again :-)


Should add 'NEVER SEEN any single RTN which causes an error' :-)

Believe me, I do not know my own code :-) Is always surprising for me, what I have done in my 
software :-)

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

Yes, no problem for me (but for readers of mailing list :-)


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