Date: Sat, 1 Mar 97 22:20:46 PST From: Snuffles@kew.com Subject: UUPC-Info-Request Digest 1997 #6 To: uupc-info-digest@kew.com Message-ID: Reply-To: UUPC-Info-Request@kew.com UUPC-Info-Request Digest Sat, 1 Mar 97 Volume 1997: Issue 6 Today's Topics: Lines starting with ~ Spirit Viper modem problems Tapi UUCICO FTP (3 msgs) To subscribe to UUPC-Info-Digest, send the command in the body of a message to listserv@kew.com: subscribe uupc-info-Digest To signoff from UUPC-Info-Digest, use "signoff" instead of "subscribe". You can also send an "index" to the listserv to get an index of back issues and other files available for retrieval. Note: Questions on UUPC/extended itself which are not of general interest should be sent to help@kew.com, not to the mailing list. Nor questions should be posted on Usenet, we don't read it. (Much.) ---------------------------------------------------------------------- Date: 13 Feb 97 22:35:13 +0100 From: jpk@itc.or.at Subject: Lines starting with ~ To: UUPC/Extended mailing list Hi Drew! 18 Jan 97 uupcinfo@kew.com: >> I'm not able to send Mails which contain lines starting with '~' >> using uucico 1.12r under OS/2; is this considered a bug or a known >> limitation? u> Read the MAIL manual page for what tilde (~) does, including the use u> of double tilde (~~). Ehr... I'm NOT using mail.exe, I experience these problems while _sending_ mails using uucico 1.12r under OS/2 (see above). I've just tested it again with '-x 20' - the first time a line within the mail started with '~~~' (which causes a problem), the other time with ' ~~~' (note: the first character is a blank here) (everything works fine). Try 1 (~~~): [...] (4) process: Machine state is = h (5) send packet type 0, yyy=1, xxx=2, len=512, buf = 512 (10) * send 2 < W < 3, receive 1 < W < 7, error 0, packet 2 (8) **got EMPTY (5) send packet type 0, yyy=1, xxx=3, len=157, buf = 256 (14) process: Machine state is = h (4) process: Machine state is = i (10) * send 2 < W < 4, receive 1 < W < 7, error 0, packet 2 (10) prpkt 09 99 aa 11 2b .. 00 (5) receive packet type 2, yyy=1, xxx=0, len=0 (5) **got NAK 1 (5) send packet type 0, yyy=1, xxx=2, len=512, buf = 512 (5) *** resent 2 (5) send packet type 0, yyy=1, xxx=3, len=157, buf = 256 (5) *** resent 3 (10) * send 2 < W < 4, receive 1 < W < 7, error 1, packet 2 (8) **got EMPTY (5) send packet type 0, yyy=1, xxx=4, len=0, buf = 32 (10) * send 2 < W < 5, receive 1 < W < 7, error 1, packet 2 (10) prpkt 09 99 aa 11 2b .. 00 (5) receive packet type 2, yyy=1, xxx=0, len=0 (5) **got NAK 1 (5) send packet type 0, yyy=1, xxx=2, len=512, buf = 512 (5) *** resent 2 (5) send packet type 0, yyy=1, xxx=3, len=157, buf = 256 (5) *** resent 3 (5) send packet type 0, yyy=1, xxx=4, len=0, buf = 32 (5) *** resent 4 (10) * send 2 < W < 5, receive 1 < W < 7, error 2, packet 2 (10) prpkt 09 99 aa 11 2b .. 00 (5) receive packet type 2, yyy=1, xxx=0, len=0 (5) **got NAK 1 (5) send packet type 0, yyy=1, xxx=2, len=512, buf = 512 (5) *** resent 2 (5) send packet type 0, yyy=1, xxx=3, len=157, buf = 256 (5) *** resent 3 (5) send packet type 0, yyy=1, xxx=4, len=0, buf = 32 (5) *** resent 4 (10) * send 2 < W < 5, receive 1 < W < 7, error 3, packet 2 [and so on, until] (0) gmachine: Consecutive error limit of 10 exceeded, 10 total errors (0) 0 time outs, 0 port reinits, 0 out of seq pkts, 10 NAKs rec, 0 NAKs sent (0) 0 invalid pkt types, 0 re-syncs, 0 bad pkt hdrs, 29 pkts resent (5) send packet type 1, yyy=0, xxx=0, len=0, buf = 0 (4) process: Machine state is = t (0) process: Connection lost to babylon, previous system state = i (4) M state = N (4) ==> ^pOOOOOO [...] Try 2 ( ~~~): (4) process: Machine state is = h (5) send packet type 0, yyy=1, xxx=2, len=512, buf = 512 (10) * send 2 < W < 3, receive 1 < W < 7, error 0, packet 2 (8) **got EMPTY (5) send packet type 0, yyy=1, xxx=3, len=182, buf = 256 (14) process: Machine state is = h (4) process: Machine state is = i (10) * send 2 < W < 4, receive 1 < W < 7, error 0, packet 2 (10) prpkt 09 88 aa 22 09 .. 00 (5) receive packet type 4, yyy=2, xxx=0, len=0 (5) **got ACK 2 (5) *** ACK 2 (5) send packet type 0, yyy=1, xxx=4, len=0, buf = 32 (10) * send 3 < W < 5, receive 1 < W < 7, error 0, packet 3 (10) prpkt 09 87 aa 23 07 .. 00 (5) receive packet type 4, yyy=3, xxx=0, len=0 (5) **got ACK 3 (5) *** ACK 3 (10) * send 4 < W < 5, receive 1 < W < 7, error 0, packet 4 (10) prpkt 09 86 aa 24 01 .. 00 (5) receive packet type 4, yyy=4, xxx=0, len=0 (5) **got ACK 4 (5) *** ACK 4 (10) * send 5 < W < 5, receive 1 < W < 7, error 0, packet 5 (10) prpkt 01 b7 69 94 4b .. 00 (5) receive packet type 0, yyy=4, xxx=2, len=32 (5) **got DATA 4 2 (5) *** ACK d 2 (5) send packet type 4, yyy=2, xxx=0, len=0, buf = 0 (2) <<< CY (4) ImportPath: Mapped D.mailer00eJ2 to babylon/D/#k9f#_m (4) seof: Deleted file D.mailer00eJ2 (babylon/D/#k9f#_m) (2) Transfer completed, 410 chars/sec (4) process: Machine state is = c (4) process: Machine state is = e (3) newrequest: got command from C:/Gate/spool/babylon/C/-x6zs% [...] by(e), Philipp -- Johannes Philipp Krone e-mail: jpk@itc.or.at (private) Moedling, Austria - EU a9400665@unet.univie.ac.at (university) fax: +43-(0)2236-29297 436763004575@sms.maxmobil.at (sms) ------------------------------ Date: Wed, 12 Feb 1997 10:09:26 GMT-10 From: peter@jehoshua.DIALix.oz.au Subject: Spirit Viper modem problems To: UUPC/Extended mailing list Hi, Can anyone help with a modem problem please ? When the modem connects, a few seconds later, the modem starts dialling the number again. Although the following UUCICO.LOG doesn't reflect the actual problem (because the UUPC connect was running under WINdoooze and a GPF occurs, hence no close of UUCICO.LOG), it hopefully will help. Here's UUCICO.LOG 02/11-17:31 UUCICO: UUPC/extended 1.12b (Oct 04 1993 12:43:32) (3) loadhost: local domain defined as "dialix.oz.au" (2) calling "sydney", debug=4 (4) M state = A (4) M state = B (2) remote=sydney, when=Any, device=modem, phone=0299486918, protocol=g (4) M state = C (3) checkone: call window "Any" open (4) M state = D (3) getmodem: loading modem configuration file c:/etc/modem.MDM (0) Unknown keyword "version" in system configuration file ignored (4) M state = E (1) callup: Calling sydney via modem at 14400 on Tue, 11 Feb 1997 17:31:29 GMT (0) ShowModem: 0x30 Data Set Ready Clear to Send (2) wanted "" (2) sending "" (2) wanted "" (2) sending "\pATZ" (2) wanted "OK" (2) got that (2) sending "\pATE0X1S0=0" (2) wanted "OK" (2) got that (2) sending "\p\c" (2) sending "ATD0299486918" (2) wanted "CONNECT" (0) ShowModem: 0xf0 Carrier Detect Ring Indicator Data Set Ready Clear to Send (1) got ??? "" (4) M state = N (3) nhangup: complete. (2) wanted "" (2) sending "\pATH" (0) ShowModem: 0x30 Data Set Ready Clear to Send (2) wanted "OK" (2) got that (2) sending "\pATZ" (2) wanted "OK" (2) got that (3) Buffer overflows: 0 (3) Receive overruns: 0 (3) Break characters: 4 (3) Framing errors: 4 (3) Parity errors: 0 (3) Transmit errors: 0 (3) DSR errors: 0 (3) CTS errors: 0 (4) M state = B (0) Could not connect to remote system. --------------------------------------------------- Here's MODEM.MDM CharDelay=0 ModemTimeout=3 Device=COM2 Initialize="" "" "" \pATZ OK \pATE0X1S0=0 OK \p\c Hangup="" \pATH OK \pATZ OK NoConnect="NO DIALTONE" "BUSY" "NO CARRIER" "VOICE" options=carrierdetect DialPrefix=ATD DialTimeout=40 Connect=CONNECT ScriptTimeout=30 InSpeed=14400 Ring=RING Answer="" \pATA CONNECT AnswerTimeout=30 ------------------------------------------------------ and last, but by no means least, SYSTEMS sydney Any modem 14400 0299486918 g ogin:--ogin: tblouucp word: password ------------------------------------------------------ Peter ----------------------------------------------------------------- ( (|) ) | Peter & Kathy Richards | | Jehoshua Computing /^\ | 79 Bee Farm Rd Phone: (047) 517220 Christ to | Springwood NSW 2777 Fax: (047) 517220 the World | Australia By Radio | Email: Peter@jehoshua.dialix.oz.au FEBC | WWW : http://www.febc.org ----------------------------------------------------------------- ------------------------------ Date: Mon, 17 Feb 1997 20:20:25 -0800 From: nfahmi@abdulla.pc.my Subject: Tapi UUCICO FTP To: UUPC/Extended mailing list In article <3300D178.41C6@ssti.mipnet.fr>, jacques.rebiscoul@ssti.mipnet.fr wrote: >drew@cgo.dec.com wrote: >> >> I currently do not have access to put this anywhere ftp'able. Is there >> someone I could sent it to, that could do this, or any other sugguestions? >> >> Thanks, >> Steve. >If you send it to me, it will be put in : > ftp://ftp.mipnet.fr/pub/tapi Say .... do we have a ftp site for this already?? .... Just curious and anxiously waiting to download it ;-). -- Nik Ahmad Fahmi e-mail: nfahmi@abdulla.pc.my 74744.1202@compuserve.com ------------------------------ Date: Mon, 17 Feb 1997 15:37:00 +0100 From: jacques.rebiscoul@ssti.mipnet.fr Subject: Tapi UUCICO FTP To: UUPC/Extended mailing list nfahmi@abdulla.pc.my wrote: > > In article <3300D178.41C6@ssti.mipnet.fr>, > jacques.rebiscoul@ssti.mipnet.fr wrote: > >drew@cgo.dec.com wrote: > >> > >> I currently do not have access to put this anywhere ftp'able. Is there > >> someone I could sent it to, that could do this, or any other sugguestions? > >> > >> Thanks, > >> Steve. > >If you send it to me, it will be put in : > > ftp://ftp.mipnet.fr/pub/tapi > > Say .... > > do we have a ftp site for this already?? .... Just curious and anxiously > waiting to download it ;-). > > -- > Nik Ahmad Fahmi e-mail: nfahmi@abdulla.pc.my > 74744.1202@compuserve.com Yes, it should work already. :-) -- Jacques REBISCOUL S. S. T. I. Tel:(33) 05 61 43 65 65 Fax:(33) 05 61 40 52 02 mailto:Jacques.Rebiscoul@ssti.mipnet.fr 31,Av. Champollion 31100 TOULOUSE FRANCE ------------------------------ Date: Mon, 17 Feb 1997 18:04:06 -0500 From: mwills@ge-harris.com Subject: Tapi UUCICO FTP To: UUPC/Extended mailing list This is a multi-part message in MIME format. --------------75571A0A3E5D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I wonder if others have had this problem. I'm guessing Steve is pretty busy these days, as I haven't heard back from him on it: As I mentioned once, I use two entries in my systems file to have uucico try direct dialing a G protocol connection first, then failing that to have it try a TCP connection (in case the failure was because I'm already connected via PPP). The (extremely nice) TAPI version of uucico Steve has done does not execute the second (TCP) attempt. I can think of several explanations: 1. maybe Steve didn't need TCP, so he didn't include it in his version, 2. maybe it exits when it gets a failed connection instead of going on to the next system entry, or 3. I've done something else wrong. Any input is appreciated. Thanks again Steve... I'd love to see the source. ---------------------------------------------------------------------------- M. Scott Wills, mwills@ge-harris.com, Voice: 407-242-5494, Fax: 407-242-4223 --------------75571A0A3E5D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from Zephyr by Zephyr.ge-harris.com (SMI-8.6/SMI-SVR4) id RAA08437; Mon, 17 Feb 1997 17:58:52 -0500 Sender: mwills@ge-harris.com Message-ID: <3308E2AC.695E@ge-harris.com> Date: Mon, 17 Feb 1997 17:58:52 -0500 From: "M. Scott Wills" X-Mailer: Mozilla 3.01Gold (X11; U; SunOS 5.5 sun4m) MIME-Version: 1.0 To: mwills@ge-harris.com Subject: Re: Tapi UUCICO FTP References: <9702111700.AA31474@cgou29.cgo.dec.com> <33086D0C.167E@ssti.mipnet.fr> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I wonder if others have had this problem. I'm guessing Steve is pretty busy these days, as I haven't heard back from him on it: As I mentioned once, I use two entries in my systems file to have uucico try direct dialing a G protocol connection first, then failing that to have it try a TCP connection (in case the failure was because I'm already connected via PPP). The (extremely nice) TAPI version of uucico Steve has done does not execute the second (TCP) attempt. I can think of several explanations: 1. maybe Steve didn't need TCP, so he didn't include it in his version, 2. maybe it exits when it gets a failed connection instead of going on to the next system entry, or 3. I've done something else wrong. Any input is appreciated. Thanks again Steve... I'd love to see the source. Scott ---------------------------------------------------------------------------- M. Scott Wills, mwills@ge-harris.com, Voice: 407-242-5494, Fax: 407-242-4223 --------------75571A0A3E5D-- ------------------------------ End of UUPC-Info-Request Digest ******************************