BUG in pageSendApp.c++

[Matthias.Apitz@SOFTCON.de]

I looked a little bit deeper into the TIMEOUT Problem and
there *is* a small problem which only shows up using UCP.

As you can see the ACK from the SMSC comes *directly* after the
TIMEOUT log line:

Feb  14 16:51:32.90: [28753]: SEND message block: [.........]
Feb  14 16:51:32.90: [28753]: <-- <97:...........>
Feb  14 16:51:47.90: [28753]: MODEM TIMEOUT: reading line from modem
Feb  14 16:51:47.90: [28753]: --> <46:.............>
Feb  14 16:51:47.90: [28753]: RECV ACK (message block accepted)

This problem is caused by the method getResponse() in pageSendApp.c++
which is waiting for a '\r' (or for TIMEOUT of ixoXmitTimeout value
in this stage of the protocol handshake) but in the UCP the PDU from
the SMSC isn't terminated by '\r', it's terminated by ETX.

Attached below is a small fix for that. I also checked the TAP
spec and ETX isn't used in the response PDU's of TAP/IXO and
the patch should not break the TAP/IXO hopefully. With this patch
the session looks like:

Feb  18 00:23:42.80: [ 4954]: SEND message block: [...........]
Feb  18 00:23:42.80: [ 4954]: <-- <115:...........>
Feb  18 00:23:54.67: [ 4954]: --> <46:............>
Feb  18 00:23:54.67: [ 4954]: RECV ACK (message block accepted)

The delay of now ~12 secs is really caused in the SMSC (here the D2
mobil phone provider in Germany).

Please run a test before I release the patch to the public.

	matthias


*** pageSendApp.c++	Wed Feb 18 22:02:41 1998
--- pageSendApp.c++.orig	Sat Feb 14 11:49:44 1998
***************
*** 414,423 ****
      if (secs) startTimeout(secs*1000);
      for (;;) {
  	int c = getModemChar(0);
- 	if (c == ETX) {
- 	    buf.put(c);
- 	    break;				// ETX ends UCP response
- 	}
  	if (c == EOF)
  	    break;
  	if (c == '\r') {
--- 414,419 ----