lenny@quincy.UUCP (Lenny Tropiano) (12/22/87)
Has anyone else experienced problems with HoneyDanBer UUCP running on an AT&T 3B2/310, Version 3.0 of the operating system? I have noticed the following quite frequently: 1. Sending compressed binaries (16-bit compression) with Penril modem 8216 from an AT&T 3B2 to another AT&T 3B2 long distance, I receive the imfamous: CONVERSATION FAILED IN SEND/SLAVE MODE INPUT FAILURE 2. Uncompress binary, send either full size or use the "pack" utility sends fine. It is always the same program that bombs. We had to remove our compress-batched news feed because of this problem. I have heard this is a problem with noise on the line, but I seriously doubt it. I watched the UUCP in -x9 debug mode, and it bombs at one particular point (same point) each time. Is there a "sequence of characters" that is bombing my modem to command mode? (ie. like the "+++" sequence on a Hayes compatible modem?) NOTE: I have the command feature turned off on these modems. When this happens the modem sends-receives-sends fine, but at the "critical" point, it stops... pauses for about 1 minute, then bursts of SEND and RECEIVE data at the same time, soon after leading to the failure. Any ideas? I don't like sending 300K binaries, when I can send 150K compressed ones! Especially LONG DISTANCE! Thanks, Lenny -- Lenny Tropiano UUCP: ...uunet!godfre!quincy!lenny -or- American LP Systems, Inc. ...cmcl2!phri!bc-cis!icus!quincy!lenny -or- 1777-18 Veterans Memorial Hwy. ...mtune!quincy!lenny -or Islandia, New York 11722 +1 516-582-5525 ...ihnp4!icus!quincy!lenny
heff@flnexus.ATT.COM (Paul K Heffner) (12/22/87)
in article <75@quincy.UUCP>, lenny@quincy.UUCP (Lenny Tropiano) says: > Has anyone else experienced problems with HoneyDanBer UUCP running on > an AT&T 3B2/310, Version 3.0 of the operating system? I have noticed > the following quite frequently: > 1. Sending compressed binaries (16-bit compression) with > Penril modem 8216 from an AT&T 3B2 to another AT&T 3B2 > long distance, I receive the imfamous: > CONVERSATION FAILED > IN SEND/SLAVE MODE INPUT FAILURE I only have seen this litle goodie pop up on our 3b2's when the size of the file being sent exceeds the ulimit of that allowed for the login 'nuucp' or whatever is being sent. Obviously this is a problem for the receiving machine as if you already have the file on your machine you have no problems there. If this is your problem, there is a tunable parameter in Release 3 to bump up the ulimit globally. Other hacks are available to set ulimits on a by-user basis. Paul Heffner ATT-Orlando
dhp@ihlpa.ATT.COM (Douglas H. Price) (12/24/87)
Occasionally, some modems have a "pattern sensitivity" to a certain string of characters. I seem to remember somewhere in the misty past, someone telling me that there are modems that will revert to local loop-back if they see long strings of zero bytes. Clearly this is a bug, but is related to the brand of the modem. -- Douglas H. Price Analysts International Corp. @ AT&T Bell Laboratories ..!ihnp4!ihlpa!dhp
allbery@ncoast.UUCP (Phil Smith) (12/28/87)
As quoted from <139@flnexus.ATT.COM> by heff@flnexus.ATT.COM (Paul K Heffner): +--------------- | in article <75@quincy.UUCP>, lenny@quincy.UUCP (Lenny Tropiano) says: | > 1. Sending compressed binaries (16-bit compression) with | > Penril modem 8216 from an AT&T 3B2 to another AT&T 3B2 | > long distance, I receive the imfamous: | > CONVERSATION FAILED | > IN SEND/SLAVE MODE INPUT FAILURE | | I only have seen this litle goodie pop up on our 3b2's when the | size of the file being sent exceeds the ulimit of that allowed +--------------- Ah, but Lenny goes on to say that the UNcompressed files transfer with no errors. Assuming that the files in question didn't reverse-compress, they should be even MORE likely to fail if it were a ulimit problem. -- Brandon S. Allbery, Moderator of comp.sources.misc {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery [This space reserved for future quotes and similar brain twisters.]
ford@crash.cts.com (Michael Ditto) (12/28/87)
In article <75@quincy.UUCP> lenny@quincy.UUCP (Lenny Tropiano) writes: > 1. Sending compressed binaries (16-bit compression) with > Penril modem 8216 from an AT&T 3B2 to another AT&T 3B2 > long distance, I receive the imfamous: > > CONVERSATION FAILED > IN SEND/SLAVE MODE INPUT FAILURE This sounds like something I've seen happen with "normal" (non-HDB) uucp. I had a large (almost 1 Meg) compressed tar archive that I tried to send to another system. The transfer was attempted five different times, to two different systems, and never worked. I don't remember if the transfer always stopped at a certain point (the only way to tell would be from the call duration). The logfile showed the above "SEND/SLAVE MODE INPUT FAILURE" message every time. All three systems were Unix PCs running the normal uucp. I split the large file into four pieces and they all went through on the first try. I was suspecting that there might be some sequence of bytes that interferes with the "G" uucp protocol, but I doubt that spliting the file would have fixed that. (I split the file with dd(1), so the smaller files contain the exact same bytes as the original, just split up). I have transfered files larger than this before without problems. Does anyone know if the uucp protocol is at all data-dependent? I thought it basically just packetized the file into 64-byte chunks with a header, or something like that. -- Mike Ditto -=] Ford [=- P.O. Box 1721 ford%kenobi@crash.CTS.COM Bonita, CA 92002 ford@crash.CTS.COM
sl@van-bc.UUCP (Stuart Lynne) (12/30/87)
In article <2211@crash.cts.com> ford%kenobi@crash.CTS.COM (Michael Ditto) writes: >> CONVERSATION FAILED >> IN SEND/SLAVE MODE INPUT FAILURE >This sounds like something I've seen happen with "normal" (non-HDB) uucp. >I had a large (almost 1 Meg) compressed tar archive that I tried to send >to another system. The transfer was attempted five different times, to >two different systems, and never worked. I don't remember if the transfer >always stopped at a certain point (the only way to tell would be from the >call duration). The logfile showed the above "SEND/SLAVE MODE INPUT >FAILURE" message every time. All three systems were Unix PCs running the >normal uucp. >I split the large file into four pieces and they all went through on the >first try. I was suspecting that there might be some sequence of bytes >that interferes with the "G" uucp protocol, but I doubt that spliting >the file would have fixed that. (I split the file with dd(1), so the >smaller files contain the exact same bytes as the original, just split >up). >Does anyone know if the uucp protocol is at all data-dependent? I thought >it basically just packetized the file into 64-byte chunks with a header, >or something like that. This happened here a year or so back before our news feed converted to a sendbatch which limited the size of batch files to 50k. I came home one day to find that my system had been dutifully trying to download the same larger than 1MB news file for the better part of 24 hours. Each time it would stop at some point between 500 and 600 kb. In this case a simple change in modem and the file came through first time. What (seems) to be happening in these cases is that you are experiencing a noisy communications channel. Uucico will only try upto 5 times to receive a packet. If there are five bad tries it will abort For a specific error rate it is not to hard to compute how long you can run before you will get a packet which has five errors in a row. The solution is to get better/different lines (or modems); or split the file into chunks that are smaller than the expected value for failure. This can be empirically done simply by averaging the size of the temporary (TM.) files which are (usually) left after the failure. -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
cmv@ihlpm.ATT.COM (C M Votava) (01/29/88)
>In article <2211@crash.cts.com> ford%kenobi@crash.CTS.COM (Michael Ditto) writes: >> In article <75@quincy.UUCP> lenny@quincy.UUCP (Lenny Tropiano) writes: >> > 1. Sending compressed binaries (16-bit compression) with >> > Penril modem 8216 from an AT&T 3B2 to another AT&T 3B2 >> > long distance, I receive the imfamous: >> > >> > CONVERSATION FAILED >> > IN SEND/SLAVE MODE INPUT FAILURE >> >> This sounds like something I've seen happen with "normal" (non-HDB) uucp. >> I had a large (almost 1 Meg) compressed tar archive that I tried to send >> to another system. The transfer was attempted five different times, to >> two different systems, and never worked. I don't remember if the transfer >> always stopped at a certain point (the only way to tell would be from the >> call duration). The logfile showed the above "SEND/SLAVE MODE INPUT >> FAILURE" message every time. All three systems were Unix PCs running the >> normal uucp. I've just encountered a problem exactly like this, here's what I did to fix it: A file of considerable size was being routed thru my machine to another machine via uucp. The connection would start up as normal, and after about 20 minutes the 'ol CONVERSATION FAILED IN SEND/SLAVE MODE INPUT FAILURE message kicked out and it died. So, I started up a uucico myself with Uutry -r -x7 mach, and watched what happened. It started up normally, started reading data into the temp file, but once the temp file reached 2048 blocks (512 byte blocks on my system) I saw a "failure to write to file" message kick out before the uucico died. I puzzled over this for a minute (I was running ksh), then typed "ulimit" and lo and behold, the ulimit size was 2048! To test out my theory, I became super-user and typed "ulimit 4096; Uutry -r -x7 mach" and after 20 minutes, the file was 2059 blocks and still growing! So, my first guess is that the ulimit on the machine you're sending to is preventing the temp file from growing and causing the error you described. The second problem that I ran into (which may or may not effect you) that caused this problem is as follows: I reset the attention sequence on my 2-way datakit lines to be ctrl-\ instead of 2 breaks. I did this for 5620/630 users, so when they called out from a window (thus disabling breaks) they could still get the datakit's attention. Anyway, soon after I did this, I started seeing this problem happening and found out that this ascii sequence sometimes, by chance, appears in binary files, so when you try to send the sequence across, datakit interceps it and throws you into datakit attention mode (thus halting the connection). The fix was easy, in the dialers script, I added a sequence to the chat script that would reset the datakit attention sequence to NONE. The moral of this second story is be careful of your LAN and make sure it's set to ignore all ascii characters for attention. Hope this helps! -Craig "looking-for-a-new-job" Votava [ihnp4!]looney!cmv [ihnp4!]ihlpm!cmv