Path: utzoo!attcan!uunet!husc6!mailrus!uwmcsd1!ig!agate!ucbvax!TERMINUS.UMD.EDU!dzoey From: dzoey@TERMINUS.UMD.EDU Newsgroups: comp.protocols.tcp-ip Subject: Re: TFTP mode strings Message-ID: <8807120106.AA00497@terminus.UMD.EDU> Date: 12 Jul 88 01:06:21 GMT References: <6549@dcatla.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 32 > From: dcatla!dnwcv@gatech.edu (William C. VerSteeg) > Subject: TFTP mode strings > There appears to be some discrepancy between the TFTP document (IEN > 133) and the packages that I have seen in use. Um, try reading RFC783 (June 1981) for the definitive (ugh) tftp treatment. > Basically, the IEN calls for three type of files- netascii, binary, and mail. TFTP encodes "netascii", "octet" or "mail" into the request packet. I've never seen "mail" implemented. Image, binary & test were never encoded in the packet and were just used for user-interface/debugging purposes. The thing to watch out for are retransmit wars. You can get into a mode where you are transmitting two packets for each packet you really want to send if you blindly ack all the packets that are retransmitted. I wound up just relying on a timer and ignoring the retransmits. Be careful of some older TFTP implementations. There was a bug in the 4.2 TFTP that made it confused when it received retransmitted packets. Since 4.2 begat such a large amount of derivitives, some implementations may still exhibit this problem. The problem was fixed in 4.3. There are lots of implementations existing to test against. Have fun. Joe Herman PC/IP @ Maryland dzoey@terminus.umd.edu