your diff got stripped when sending to this list. i did a fix which has now been committed to the tree as src/usr.bin/tftp/tftp.c r1.24.
thanks for the report :) dlg > On 21 Oct 2014, at 10:28, Justin Mayes <jma...@careered.com> wrote: > > I could. My original problem was with cisco rommon tftpdnld command as client > failing talking to tftpd. I just notice the tftp client problem while testing > locally. After this I intend to go back and make tftpd work with whatever > cisco client is doing. Since that’s a two byte field in the rfc there is no > way I know of that tftpd or any other server can get more than 65536 in there > so all they can do is rollover. The only thing I can think is maybe cisco > client starts at 1 rather than 0. A tcpdump will tell me in a little while. > This is more of a learning experience for me. I want to go through motions of > getting source, debugging some issue with gdb, updating the code, build and > all that. I've done that many times in windows world but not in any unix like > Oses. So far the exercise is a success in that I learned a ton and if that > diff was worth anything to anyone, even better. Thanks for the tip tho James, > its good advice. > > J > -----Original Message----- > From: James A. Peltier [mailto:jpelt...@sfu.ca] > Sent: Monday, October 20, 2014 5:34 PM > To: Justin Mayes > Cc: misc@openbsd.org > Subject: Re: Making tftp download large files from tftpd > > ----- Original Message ----- > | I will spare you all the backstory but I found that tftp could not > | download files over 32 mb by default from tftpd. I know you can pass > | blocksize to tftpd to handle much larger files but I was originally > | working with a client where this wasn't possible. Tftp protocol has 2 > | bytes for block number which put a > | 65535 limit on that. tftpd data doesn't care and will just roll that > | over back to 0 and keep sending data. Tftp client fails when there is > | block number roll over because it is tracking all the blocks with an > | int so ends up comparing its block counter which is now at 65536 to > | what comes off the network, 0 and quits. I updated the tftp client > | code to use same data type as the network side structs are using - > | u_int16_t. Now tftp counter rolls along with server and can send file > | of any size with or without a blocksize change. I feel like this is > | mostly pointless but doesn't hurt anything. Will gladly provide the > | actuall diffs. I have to look into that process for openbsd but just > | wanted to check with the group first in case there was a reason an int > | was used that I do not understand. > | > | J > > Or you could chainload iPXE to allow for the downloading of your file over > HTTP which is much faster than TFTP to begin with. This is indeed what we do. > > -- > James A. Peltier > IT Services - Research Computing Group > Simon Fraser University - Burnaby Campus > Phone : 778-782-6573 > Fax : 778-782-3045 > E-Mail : jpelt...@sfu.ca > Website : http://www.sfu.ca/itservices > Twitter : @sfu_rcg > Powering Engagement Through Technology
