stern@walnut.cis.ohio-state.edu (jeffrey a stern) (05/03/89)
For anyone who's interested, I noticed a bug(?) in kermit, when trying to upload a binary file from my Apple //e to Suns at school using BSD4.2 UNIX. This file was a HiRes (not Double HiRes) file to be converted to Sun raster format once it got there. Using Kermit's binary file-type option, and without any terminal emulation or any other problems of the sort, I consistently lost 12 bytes from this file each time I tried to upload it. By downloading it back (this time not losing any characters) and writing a simple check program to find the differences, I found that all the bytes missing had the value 13(decimal). By chance, Kermit's End-Of-Packet (Kermit-65 is 'End-Of-Line') character is 13! Wanting to use a different End-Of-Line/End-Of-Packet character to get by this, I went through and checked for any characters under 128(dec) that by chance didn't occur in my file that I could exploit for the purpose. As it turns out, there were no 37's and no 106's. Interestingly enough, my little Apple //e and Kermit-65 let's you change the End-Of-Line character to what ever you want, (both for send and receive) but BSD4.2 doesn't! Forget Apple// vs. Mac-- let's take on the Suns!!! Finally, the only thing to do was actually change every byte of value 13 to value 37, using yet another kludge (pat on my own back, yeah!) upload the file, and then change all 37's back to 13's again. This got the file, intact onto the UNIX system at school, but I found tr and awk didn't work for this file, and sed didn't seem applicable. (Why, I'd like to know... don't they work on binary files?) Anyway, I got around this final prob' by writing a little C program using fgetc and fputc to stream the characters in and out. This problem is not mentioned in the Kermit docs. Can it be added for future use? (I couldn't use xmodem because it currently is down here at Ohio State.) I can probably put all these babies together so they work as one or two automated file editors/stream editors for this problem, and post it.... let me know if there is any interest... Jeff Stern stern@cis.ohio-state.edu --
kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) (05/03/89)
In article <46194@tut.cis.ohio-state.edu> <stern@cis.ohio-state.edu> writes: >For anyone who's interested, I noticed a bug(?) in kermit, when trying >to upload a binary file from my Apple //e to Suns at school using >BSD4.2 UNIX. [Slightly edited...] Using Kermit's >binary file-type option, and without any terminal emulation or any >other problems of the sort, I consistently lost 12 bytes from this >file each time I tried to upload it. >By downloading it back (this time not losing any characters) and >writing a simple check program to find the differences, I found that >all the bytes missing had the value 13(decimal). By chance, Kermit's >End-Of-Packet (Kermit-65 is 'End-Of-Line') character is 13! >[Description of how he wanted to change the End-of-Packet character to >something else that was unused in his file.] >Interestingly enough, my little Apple //e and Kermit-65 let's you >change the End-Of-Line character to what ever you want, (both for send >and receive) but BSD4.2 doesn't! Forget Apple// vs. Mac-- let's take >on the Suns!!! The version available on my BSD Unix system DOES allow you to change the End-of-Packet Character--you should look into getting a newer version for your Sun. This is an interesting problem--I have been downloading many binary files from Unix lately (They are GIF's) and most have downloaded just fine. So, the bug may be in the Sun's Kermit...what version is it? In terms of my downloading, I have one file which just didn't send. It's about 29K long, and the transfer, just like all the others, goes just fine UNTIL THE VERY LAST BLOCK! At that point, I get 10 'Bad Checksum' errors in a row (as in, one program is calculating a bad checksum), and the transfer aborts. I am transferring over a 7-bit line, so 8-th bit prefixing is in effect. About 20 other files, some even longer, downloaded just fine. Anyone know anything about this? If you need more details (I'll work on making it bomb out on a smaller file, and then possibly send that to others to try out). I forget the version of Kermit on the Unix sys, but I am using 3.85 on my Apple. >[Long description of how he fixed it...] >I can probably put all these babies together so they work as one or >two automated file editors/stream editors for this problem, and post >it.... let me know if there is any interest... > >Jeff Stern >stern@cis.ohio-state.edu Even if no one else wants them, I can always use handy-dandy utilities like those to work on debugging odd transfer problems. Kent Dickey kadickey@phoenix.Princeton.Edu kadickey@PUCC
stern@maple.cis.ohio-state.edu (jeffrey a stern) (05/05/89)
In article <8092@phoenix.Princeton.EDU> kadickey@phoenix.Princeton.EDU (Kent Andrew Dickey) writes: >>[Description of how he wanted to change the End-of-Packet character to >>something else that was unused in his file.] >>Interestingly enough, my little Apple //e and Kermit-65 let's you >>change the End-Of-Line character to what ever you want, (both for send >>and receive) but BSD4.2 doesn't! Forget Apple// vs. Mac-- let's take >>on the Suns!!! > >The version available on my BSD Unix system DOES allow you to change >the End-of-Packet Character--you should look into getting a newer >version for your Sun. > Yeah, actually, you're right, it does let you change the end-of-packet character, but what I said was that >Interestingly enough, my little Apple //e and Kermit-65 let's you >change the End-Of-Line character to what ever you want, (both for send >and receive) but BSD4.2 doesn't! Forget Apple// vs. Mac-- let's take >on the Suns!!! The Sun systems won't let you change an End-Of-Packet character to be something OTHER than a control character. Therefore, I can't make it something with an ASCII value of, say, 37, or 106, which is what I was trying. >This is an interesting problem--I have been downloading many binary >files from Unix lately (They are GIF's) and most have downloaded just >fine. So, the bug may be in the Sun's Kermit...what version is it? C-Kermit, 4E(071) 18 Jan 89, 4.2 BSD >[Description of block transfer problem...] I have no idea, Kent. I would try splitting the file into two files: One with all the blocks prior, and one with that last one, and see what happens. Also, I would try Block Warden or one of my utilities I was talking about to count the number of occurences of each ASCII character. If nothing else is out of the ordinary, then I'd say it's maybe hard-ware??? Sorry I can't help much more, though I'd be interested in your sending the faulty piece, as you offered.... >Even if no one else wants them, I can always use handy-dandy utilities like >those to work on debugging odd transfer problems. > > Kent Dickey >kadickey@phoenix.Princeton.Edu >kadickey@PUCC Okay, Kent, I'll try to get those posted. It'll take awhile though, because I am in the middle of doing a bunch of labs for different classes. Thanks for the feedback. Jeff. ____________________________________________________________________________ | | | v | | stern@cis.ohio-state.edu: Internet | | | osu-cis!tut!stern : UUCP |:->{===%| | ` / | | "iggy pop had @ | | no idea" | |____________________________________________________________________________|
lwv@n8emr.UUCP (Larry W. Virden) (05/05/89)
I had a strange problem apparently with kermit 3.85 or ckermit on a VAX this past weekend. I tried to kermit up a GIF file and kermit would just beep at me and terminate. First I discovered that I was in text mode. So I told kermit to use binary. Then kermit complained that the prodos file type was txt so it wouldnt use binary mode. So I exited and changed the mode to a BIN. Then I went back into kermit, reset its mode to binary and tried again. Again, kermit just beeped. When I connected to the destination, I discovered some zero length files and that was all. -- Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET) The world's not inherited from our parents, but borrowed from our children.
stern@teak.cis.ohio-state.edu (jeffrey a stern) (05/06/89)
In article <1062@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >I had a strange problem apparently with kermit 3.85 or ckermit on a VAX >this past weekend. I tried to kermit up a GIF file and kermit would just >beep at me and terminate. First I discovered that I was in text mode. So >I told kermit to use binary. Then kermit complained that the prodos file >type was txt so it wouldnt use binary mode. So I exited and changed the mode >to a BIN. Then I went back into kermit, reset its mode to binary and tried >again. Again, kermit just beeped. When I connected to the destination, >I discovered some zero length files and that was all. > >-- >Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 >75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) >osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET) >The world's not inherited from our parents, but borrowed from our children. Hmm... would you mind mailing me a Binscii'd copy of this GIF to me, Larry? I'd be interested in taking a look at it... Jeff Stern. ____________________________________________________________________________ | | | v | | stern@cis.ohio-state.edu: Internet | | | osu-cis!tut!stern : UUCP |:->{===%| | ` / | | "iggy pop had @ | | no idea" | |____________________________________________________________________________|