1998-08-20 08:19:55 +00:00
|
|
|
/* $NetBSD: tftp.c,v 1.4 1997/09/17 16:57:07 drochner Exp $ */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copyright (c) 1996
|
|
|
|
* Matthias Drochner. All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
* This product includes software developed for the NetBSD Project
|
|
|
|
* by Matthias Drochner.
|
|
|
|
* 4. The name of the author may not be used to endorse or promote products
|
|
|
|
* derived from this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Simple TFTP implementation for libsa.
|
|
|
|
* Assumes:
|
2021-09-24 15:04:31 +00:00
|
|
|
* - socket descriptor (int) at dev->d_opendata, dev stored at
|
|
|
|
* open_file->f_devdata
|
2021-08-02 12:27:38 +00:00
|
|
|
* - server host IP in global rootip
|
1998-08-20 08:19:55 +00:00
|
|
|
* Restrictions:
|
|
|
|
* - read only
|
|
|
|
* - lseek only with SEEK_SET or SEEK_CUR
|
|
|
|
* - no big time differences between transfers (<tftp timeout)
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
#include <netinet/in.h>
|
|
|
|
#include <netinet/udp.h>
|
|
|
|
#include <netinet/in_systm.h>
|
|
|
|
#include <arpa/tftp.h>
|
|
|
|
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include "stand.h"
|
|
|
|
#include "net.h"
|
|
|
|
#include "netif.h"
|
|
|
|
|
|
|
|
#include "tftp.h"
|
|
|
|
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
struct tftp_handle;
|
2018-02-15 19:49:15 +00:00
|
|
|
struct tftprecv_extra;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
static ssize_t recvtftp(struct iodesc *, void **, void **, time_t, void *);
|
|
|
|
static int tftp_open(const char *, struct open_file *);
|
|
|
|
static int tftp_close(struct open_file *);
|
|
|
|
static int tftp_parse_oack(struct tftp_handle *, char *, size_t);
|
|
|
|
static int tftp_read(struct open_file *, void *, size_t, size_t *);
|
|
|
|
static off_t tftp_seek(struct open_file *, off_t, int);
|
|
|
|
static int tftp_set_blksize(struct tftp_handle *, const char *);
|
|
|
|
static int tftp_stat(struct open_file *, struct stat *);
|
2021-12-10 09:37:01 +00:00
|
|
|
static int tftp_preload(struct open_file *);
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
struct fs_ops tftp_fsops = {
|
2018-11-01 22:13:18 +00:00
|
|
|
.fs_name = "tftp",
|
|
|
|
.fo_open = tftp_open,
|
|
|
|
.fo_close = tftp_close,
|
|
|
|
.fo_read = tftp_read,
|
|
|
|
.fo_write = null_write,
|
|
|
|
.fo_seek = tftp_seek,
|
|
|
|
.fo_stat = tftp_stat,
|
2021-12-10 09:37:01 +00:00
|
|
|
.fo_preload = tftp_preload,
|
2018-11-01 22:13:18 +00:00
|
|
|
.fo_readdir = null_readdir
|
1998-08-20 08:19:55 +00:00
|
|
|
};
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
static int tftpport = 2000;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
static int is_open = 0;
|
|
|
|
|
|
|
|
/*
|
2011-06-24 03:50:54 +00:00
|
|
|
* The legacy TFTP_BLKSIZE value was SEGSIZE(512).
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
* TFTP_REQUESTED_BLKSIZE of 1428 is (Ethernet MTU, less the TFTP, UDP and
|
|
|
|
* IP header lengths).
|
|
|
|
*/
|
2018-11-01 22:13:18 +00:00
|
|
|
#define TFTP_REQUESTED_BLKSIZE 1428
|
1998-08-20 08:19:55 +00:00
|
|
|
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
/*
|
|
|
|
* Choose a blksize big enough so we can test with Ethernet
|
|
|
|
* Jumbo frames in the future.
|
2011-06-24 03:50:54 +00:00
|
|
|
*/
|
2018-11-01 22:13:18 +00:00
|
|
|
#define TFTP_MAX_BLKSIZE 9008
|
2020-04-07 16:56:34 +00:00
|
|
|
#define TFTP_TRIES 2
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
struct tftp_handle {
|
|
|
|
struct iodesc *iodesc;
|
2018-11-01 22:13:18 +00:00
|
|
|
int currblock; /* contents of lastdata */
|
2023-04-17 16:15:57 +00:00
|
|
|
unsigned int islastblock:1; /* flag */
|
|
|
|
unsigned int tries:4; /* number of read attempts */
|
2018-11-01 22:13:18 +00:00
|
|
|
int validsize;
|
|
|
|
int off;
|
|
|
|
char *path; /* saved for re-requests */
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
unsigned int tftp_blksize;
|
2011-06-24 03:50:54 +00:00
|
|
|
unsigned long tftp_tsize;
|
2017-05-06 20:32:27 +00:00
|
|
|
void *pkt;
|
|
|
|
struct tftphdr *tftp_hdr;
|
2021-12-13 09:35:23 +00:00
|
|
|
char *tftp_cache;
|
|
|
|
bool lastacksent;
|
1998-08-20 08:19:55 +00:00
|
|
|
};
|
|
|
|
|
2018-02-15 19:49:15 +00:00
|
|
|
struct tftprecv_extra {
|
|
|
|
struct tftp_handle *tftp_handle;
|
2018-11-01 22:13:18 +00:00
|
|
|
unsigned short rtype; /* Received type */
|
2018-02-15 19:49:15 +00:00
|
|
|
};
|
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
#define TFTP_MAX_ERRCODE EOPTNEG
|
|
|
|
static const int tftperrors[TFTP_MAX_ERRCODE + 1] = {
|
2021-12-08 15:18:49 +00:00
|
|
|
0, /* NAK */
|
1998-08-20 08:19:55 +00:00
|
|
|
ENOENT,
|
|
|
|
EPERM,
|
|
|
|
ENOSPC,
|
|
|
|
EINVAL, /* ??? */
|
|
|
|
EINVAL, /* ??? */
|
|
|
|
EEXIST,
|
2011-06-24 03:50:54 +00:00
|
|
|
EINVAL, /* ??? */
|
|
|
|
EINVAL, /* Option negotiation failed. */
|
1998-08-20 08:19:55 +00:00
|
|
|
};
|
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
static int tftp_getnextblock(struct tftp_handle *h);
|
|
|
|
|
|
|
|
/* send error message back. */
|
|
|
|
static void
|
|
|
|
tftp_senderr(struct tftp_handle *h, u_short errcode, const char *msg)
|
|
|
|
{
|
|
|
|
struct {
|
|
|
|
u_char header[HEADER_SIZE];
|
2018-11-01 22:13:18 +00:00
|
|
|
struct tftphdr t;
|
2011-06-24 03:50:54 +00:00
|
|
|
u_char space[63]; /* +1 from t */
|
|
|
|
} __packed __aligned(4) wbuf;
|
2018-11-01 22:13:18 +00:00
|
|
|
char *wtail;
|
|
|
|
int len;
|
2011-06-24 03:50:54 +00:00
|
|
|
|
|
|
|
len = strlen(msg);
|
|
|
|
if (len > sizeof(wbuf.space))
|
|
|
|
len = sizeof(wbuf.space);
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
wbuf.t.th_opcode = htons((u_short)ERROR);
|
|
|
|
wbuf.t.th_code = htons(errcode);
|
2011-06-24 03:50:54 +00:00
|
|
|
|
|
|
|
wtail = wbuf.t.th_msg;
|
|
|
|
bcopy(msg, wtail, len);
|
|
|
|
wtail[len] = '\0';
|
|
|
|
wtail += len + 1;
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
sendudp(h->iodesc, &wbuf.t, wtail - (char *)&wbuf.t);
|
2011-06-24 03:50:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2018-10-23 13:38:39 +00:00
|
|
|
tftp_sendack(struct tftp_handle *h, u_short block)
|
2011-06-24 03:50:54 +00:00
|
|
|
{
|
|
|
|
struct {
|
|
|
|
u_char header[HEADER_SIZE];
|
|
|
|
struct tftphdr t;
|
|
|
|
} __packed __aligned(4) wbuf;
|
2018-11-01 22:13:18 +00:00
|
|
|
char *wtail;
|
2011-06-24 03:50:54 +00:00
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
wbuf.t.th_opcode = htons((u_short)ACK);
|
|
|
|
wtail = (char *)&wbuf.t.th_block;
|
2018-10-23 13:38:39 +00:00
|
|
|
wbuf.t.th_block = htons(block);
|
2011-06-24 03:50:54 +00:00
|
|
|
wtail += 2;
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
sendudp(h->iodesc, &wbuf.t, wtail - (char *)&wbuf.t);
|
2011-06-24 03:50:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t
|
2018-02-15 19:49:15 +00:00
|
|
|
recvtftp(struct iodesc *d, void **pkt, void **payload, time_t tleft,
|
|
|
|
void *recv_extra)
|
1998-08-20 08:19:55 +00:00
|
|
|
{
|
2018-02-15 19:49:15 +00:00
|
|
|
struct tftprecv_extra *extra;
|
|
|
|
struct tftp_handle *h;
|
1998-08-20 08:19:55 +00:00
|
|
|
struct tftphdr *t;
|
2017-05-06 20:32:27 +00:00
|
|
|
void *ptr = NULL;
|
|
|
|
ssize_t len;
|
2021-12-08 15:18:49 +00:00
|
|
|
int tftp_error;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2001-06-30 21:39:09 +00:00
|
|
|
errno = 0;
|
2018-11-01 22:13:18 +00:00
|
|
|
extra = recv_extra;
|
2018-02-15 19:49:15 +00:00
|
|
|
h = extra->tftp_handle;
|
2001-06-30 21:39:09 +00:00
|
|
|
|
2017-05-06 20:32:27 +00:00
|
|
|
len = readudp(d, &ptr, (void **)&t, tleft);
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2017-05-06 20:32:27 +00:00
|
|
|
if (len < 4) {
|
|
|
|
free(ptr);
|
1998-08-20 08:19:55 +00:00
|
|
|
return (-1);
|
2017-05-06 20:32:27 +00:00
|
|
|
}
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2018-02-15 19:49:15 +00:00
|
|
|
extra->rtype = ntohs(t->th_opcode);
|
1998-08-20 08:19:55 +00:00
|
|
|
switch (ntohs(t->th_opcode)) {
|
|
|
|
case DATA: {
|
|
|
|
int got;
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
if (htons(t->th_block) < (u_short)d->xid) {
|
2018-10-23 13:38:39 +00:00
|
|
|
/*
|
|
|
|
* Apparently our ACK was missed, re-send.
|
|
|
|
*/
|
|
|
|
tftp_sendack(h, htons(t->th_block));
|
|
|
|
free(ptr);
|
|
|
|
return (-1);
|
|
|
|
}
|
2018-11-01 22:13:18 +00:00
|
|
|
if (htons(t->th_block) != (u_short)d->xid) {
|
1998-08-20 08:19:55 +00:00
|
|
|
/*
|
2018-10-23 13:38:39 +00:00
|
|
|
* Packet from the future, drop this.
|
1998-08-20 08:19:55 +00:00
|
|
|
*/
|
2017-05-06 20:32:27 +00:00
|
|
|
free(ptr);
|
1998-08-20 08:19:55 +00:00
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
if (d->xid == 1) {
|
|
|
|
/*
|
|
|
|
* First data packet from new port.
|
|
|
|
*/
|
2002-03-21 23:39:28 +00:00
|
|
|
struct udphdr *uh;
|
2018-11-01 22:13:18 +00:00
|
|
|
uh = (struct udphdr *)t - 1;
|
1998-08-20 08:19:55 +00:00
|
|
|
d->destport = uh->uh_sport;
|
2018-10-23 13:38:39 +00:00
|
|
|
}
|
2017-05-06 20:32:27 +00:00
|
|
|
got = len - (t->th_data - (char *)t);
|
|
|
|
*pkt = ptr;
|
|
|
|
*payload = t;
|
|
|
|
return (got);
|
1998-08-20 08:19:55 +00:00
|
|
|
}
|
|
|
|
case ERROR:
|
2021-12-08 15:18:49 +00:00
|
|
|
tftp_error = ntohs(t->th_code);
|
|
|
|
if ((unsigned)tftp_error > TFTP_MAX_ERRCODE) {
|
|
|
|
printf("illegal tftp error %d\n", tftp_error);
|
1998-08-20 08:19:55 +00:00
|
|
|
errno = EIO;
|
|
|
|
} else {
|
2011-05-03 07:46:02 +00:00
|
|
|
#ifdef TFTP_DEBUG
|
2021-12-08 15:18:49 +00:00
|
|
|
printf("tftp-error %d\n", tftp_error);
|
1998-08-20 08:19:55 +00:00
|
|
|
#endif
|
2021-12-08 15:18:49 +00:00
|
|
|
errno = tftperrors[tftp_error];
|
1998-08-20 08:19:55 +00:00
|
|
|
}
|
2017-05-06 20:32:27 +00:00
|
|
|
free(ptr);
|
2021-12-08 15:18:49 +00:00
|
|
|
/* If we got a NAK return 0, it's usually a directory */
|
|
|
|
if (tftp_error == 0)
|
|
|
|
return (0);
|
1998-08-20 08:19:55 +00:00
|
|
|
return (-1);
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
case OACK: {
|
|
|
|
struct udphdr *uh;
|
2011-06-24 03:50:54 +00:00
|
|
|
int tftp_oack_len;
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
/*
|
|
|
|
* Unexpected OACK. TFTP transfer already in progress.
|
2011-06-24 03:50:54 +00:00
|
|
|
* Drop the pkt.
|
|
|
|
*/
|
|
|
|
if (d->xid != 1) {
|
2017-05-06 20:32:27 +00:00
|
|
|
free(ptr);
|
2011-06-24 03:50:54 +00:00
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
/*
|
2011-06-24 03:50:54 +00:00
|
|
|
* Remember which port this OACK came from, because we need
|
|
|
|
* to send the ACK or errors back to it.
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
*/
|
2018-11-01 22:13:18 +00:00
|
|
|
uh = (struct udphdr *)t - 1;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
d->destport = uh->uh_sport;
|
2018-11-01 22:13:18 +00:00
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
/* Parse options ACK-ed by the server. */
|
|
|
|
tftp_oack_len = len - sizeof(t->th_opcode);
|
|
|
|
if (tftp_parse_oack(h, t->th_u.tu_stuff, tftp_oack_len) != 0) {
|
|
|
|
tftp_senderr(h, EOPTNEG, "Malformed OACK");
|
|
|
|
errno = EIO;
|
2017-05-06 20:32:27 +00:00
|
|
|
free(ptr);
|
2011-06-24 03:50:54 +00:00
|
|
|
return (-1);
|
|
|
|
}
|
2017-05-06 20:32:27 +00:00
|
|
|
*pkt = ptr;
|
|
|
|
*payload = t;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
return (0);
|
|
|
|
}
|
1998-08-20 08:19:55 +00:00
|
|
|
default:
|
2011-05-03 07:46:02 +00:00
|
|
|
#ifdef TFTP_DEBUG
|
1998-08-20 08:19:55 +00:00
|
|
|
printf("tftp type %d not handled\n", ntohs(t->th_opcode));
|
|
|
|
#endif
|
2017-05-06 20:32:27 +00:00
|
|
|
free(ptr);
|
1998-08-20 08:19:55 +00:00
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* send request, expect first block (or error) */
|
2011-06-24 03:50:54 +00:00
|
|
|
static int
|
2011-05-03 04:44:50 +00:00
|
|
|
tftp_makereq(struct tftp_handle *h)
|
1998-08-20 08:19:55 +00:00
|
|
|
{
|
|
|
|
struct {
|
|
|
|
u_char header[HEADER_SIZE];
|
|
|
|
struct tftphdr t;
|
|
|
|
u_char space[FNAME_SIZE + 6];
|
2011-06-15 23:22:35 +00:00
|
|
|
} __packed __aligned(4) wbuf;
|
2018-02-15 19:49:15 +00:00
|
|
|
struct tftprecv_extra recv_extra;
|
2018-11-01 22:13:18 +00:00
|
|
|
char *wtail;
|
|
|
|
int l;
|
|
|
|
ssize_t res;
|
2017-05-06 20:32:27 +00:00
|
|
|
void *pkt;
|
1998-08-20 08:19:55 +00:00
|
|
|
struct tftphdr *t;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
char *tftp_blksize = NULL;
|
|
|
|
int blksize_l;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allow overriding default TFTP block size by setting
|
|
|
|
* a tftp.blksize environment variable.
|
|
|
|
*/
|
|
|
|
if ((tftp_blksize = getenv("tftp.blksize")) != NULL) {
|
|
|
|
tftp_set_blksize(h, tftp_blksize);
|
|
|
|
}
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
wbuf.t.th_opcode = htons((u_short)RRQ);
|
1998-08-20 08:19:55 +00:00
|
|
|
wtail = wbuf.t.th_stuff;
|
|
|
|
l = strlen(h->path);
|
2011-12-22 09:36:37 +00:00
|
|
|
#ifdef TFTP_PREPEND_PATH
|
|
|
|
if (l > FNAME_SIZE - (sizeof(TFTP_PREPEND_PATH) - 1))
|
|
|
|
return (ENAMETOOLONG);
|
|
|
|
bcopy(TFTP_PREPEND_PATH, wtail, sizeof(TFTP_PREPEND_PATH) - 1);
|
|
|
|
wtail += sizeof(TFTP_PREPEND_PATH) - 1;
|
|
|
|
#else
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
if (l > FNAME_SIZE)
|
|
|
|
return (ENAMETOOLONG);
|
2011-12-22 09:36:37 +00:00
|
|
|
#endif
|
1998-08-20 08:19:55 +00:00
|
|
|
bcopy(h->path, wtail, l + 1);
|
|
|
|
wtail += l + 1;
|
|
|
|
bcopy("octet", wtail, 6);
|
|
|
|
wtail += 6;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
bcopy("blksize", wtail, 8);
|
|
|
|
wtail += 8;
|
|
|
|
blksize_l = sprintf(wtail, "%d", h->tftp_blksize);
|
|
|
|
wtail += blksize_l + 1;
|
|
|
|
bcopy("tsize", wtail, 6);
|
|
|
|
wtail += 6;
|
|
|
|
bcopy("0", wtail, 2);
|
|
|
|
wtail += 2;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
h->iodesc->myport = htons(tftpport + (getsecs() & 0x3ff));
|
|
|
|
h->iodesc->destport = htons(IPPORT_TFTP);
|
|
|
|
h->iodesc->xid = 1; /* expected block */
|
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
h->currblock = 0;
|
|
|
|
h->islastblock = 0;
|
|
|
|
h->validsize = 0;
|
|
|
|
|
2017-05-06 20:32:27 +00:00
|
|
|
pkt = NULL;
|
2018-02-15 19:49:15 +00:00
|
|
|
recv_extra.tftp_handle = h;
|
2018-11-01 22:13:18 +00:00
|
|
|
res = sendrecv(h->iodesc, &sendudp, &wbuf.t, wtail - (char *)&wbuf.t,
|
|
|
|
&recvtftp, &pkt, (void **)&t, &recv_extra);
|
2017-05-06 20:32:27 +00:00
|
|
|
if (res == -1) {
|
|
|
|
free(pkt);
|
|
|
|
return (errno);
|
|
|
|
}
|
|
|
|
|
|
|
|
free(h->pkt);
|
|
|
|
h->pkt = pkt;
|
|
|
|
h->tftp_hdr = t;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
|
2018-02-15 19:49:15 +00:00
|
|
|
if (recv_extra.rtype == OACK)
|
2011-06-24 03:50:54 +00:00
|
|
|
return (tftp_getnextblock(h));
|
|
|
|
|
|
|
|
/* Server ignored our blksize request, revert to TFTP default. */
|
|
|
|
h->tftp_blksize = SEGSIZE;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2018-02-15 19:49:15 +00:00
|
|
|
switch (recv_extra.rtype) {
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
case DATA: {
|
|
|
|
h->currblock = 1;
|
|
|
|
h->validsize = res;
|
|
|
|
h->islastblock = 0;
|
2011-06-24 03:50:54 +00:00
|
|
|
if (res < h->tftp_blksize) {
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
h->islastblock = 1; /* very short file */
|
2018-10-23 13:38:39 +00:00
|
|
|
tftp_sendack(h, h->currblock);
|
2021-12-13 09:35:23 +00:00
|
|
|
h->lastacksent = true;
|
2011-06-24 03:50:54 +00:00
|
|
|
}
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
case ERROR:
|
|
|
|
default:
|
|
|
|
return (errno);
|
|
|
|
}
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ack block, expect next */
|
2018-11-01 22:13:18 +00:00
|
|
|
static int
|
2011-05-03 04:44:50 +00:00
|
|
|
tftp_getnextblock(struct tftp_handle *h)
|
1998-08-20 08:19:55 +00:00
|
|
|
{
|
|
|
|
struct {
|
|
|
|
u_char header[HEADER_SIZE];
|
|
|
|
struct tftphdr t;
|
2011-06-15 23:22:35 +00:00
|
|
|
} __packed __aligned(4) wbuf;
|
2018-02-15 19:49:15 +00:00
|
|
|
struct tftprecv_extra recv_extra;
|
2018-11-01 22:13:18 +00:00
|
|
|
char *wtail;
|
|
|
|
int res;
|
2017-05-06 20:32:27 +00:00
|
|
|
void *pkt;
|
1998-08-20 08:19:55 +00:00
|
|
|
struct tftphdr *t;
|
2018-11-01 22:13:18 +00:00
|
|
|
|
|
|
|
wbuf.t.th_opcode = htons((u_short)ACK);
|
|
|
|
wtail = (char *)&wbuf.t.th_block;
|
|
|
|
wbuf.t.th_block = htons((u_short)h->currblock);
|
1998-08-20 08:19:55 +00:00
|
|
|
wtail += 2;
|
|
|
|
|
|
|
|
h->iodesc->xid = h->currblock + 1; /* expected block */
|
|
|
|
|
2017-05-06 20:32:27 +00:00
|
|
|
pkt = NULL;
|
2018-02-15 19:49:15 +00:00
|
|
|
recv_extra.tftp_handle = h;
|
2018-11-01 22:13:18 +00:00
|
|
|
res = sendrecv(h->iodesc, &sendudp, &wbuf.t, wtail - (char *)&wbuf.t,
|
|
|
|
&recvtftp, &pkt, (void **)&t, &recv_extra);
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2017-05-06 20:32:27 +00:00
|
|
|
if (res == -1) { /* 0 is OK! */
|
|
|
|
free(pkt);
|
1998-08-20 08:19:55 +00:00
|
|
|
return (errno);
|
2017-05-06 20:32:27 +00:00
|
|
|
}
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2017-05-06 20:32:27 +00:00
|
|
|
free(h->pkt);
|
|
|
|
h->pkt = pkt;
|
|
|
|
h->tftp_hdr = t;
|
1998-08-20 08:19:55 +00:00
|
|
|
h->currblock++;
|
|
|
|
h->validsize = res;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
if (res < h->tftp_blksize)
|
1998-08-20 08:19:55 +00:00
|
|
|
h->islastblock = 1; /* EOF */
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
|
|
|
|
if (h->islastblock == 1) {
|
2018-11-01 22:13:18 +00:00
|
|
|
/* Send an ACK for the last block */
|
|
|
|
wbuf.t.th_block = htons((u_short)h->currblock);
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
sendudp(h->iodesc, &wbuf.t, wtail - (char *)&wbuf.t);
|
|
|
|
}
|
|
|
|
|
1998-08-20 08:19:55 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
static int
|
2011-05-03 04:44:50 +00:00
|
|
|
tftp_open(const char *path, struct open_file *f)
|
1998-08-20 08:19:55 +00:00
|
|
|
{
|
2021-09-24 15:04:31 +00:00
|
|
|
struct devdesc *dev;
|
1998-08-20 08:19:55 +00:00
|
|
|
struct tftp_handle *tftpfile;
|
2018-11-01 22:13:18 +00:00
|
|
|
struct iodesc *io;
|
|
|
|
int res;
|
|
|
|
size_t pathsize;
|
|
|
|
const char *extraslash;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2016-08-31 13:16:40 +00:00
|
|
|
if (netproto != NET_TFTP)
|
|
|
|
return (EINVAL);
|
|
|
|
|
2017-05-06 20:32:27 +00:00
|
|
|
if (f->f_dev->dv_type != DEVT_NET)
|
2002-07-07 23:01:36 +00:00
|
|
|
return (EINVAL);
|
2003-03-03 00:58:47 +00:00
|
|
|
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
if (is_open)
|
|
|
|
return (EBUSY);
|
|
|
|
|
2018-11-01 13:29:55 +00:00
|
|
|
tftpfile = calloc(1, sizeof(*tftpfile));
|
1998-08-20 08:19:55 +00:00
|
|
|
if (!tftpfile)
|
|
|
|
return (ENOMEM);
|
|
|
|
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
tftpfile->tftp_blksize = TFTP_REQUESTED_BLKSIZE;
|
2021-09-24 15:04:31 +00:00
|
|
|
dev = f->f_devdata;
|
|
|
|
tftpfile->iodesc = io = socktodesc(*(int *)(dev->d_opendata));
|
2018-09-08 19:17:22 +00:00
|
|
|
if (io == NULL) {
|
|
|
|
free(tftpfile);
|
2000-12-08 05:02:12 +00:00
|
|
|
return (EINVAL);
|
2018-09-08 19:17:22 +00:00
|
|
|
}
|
2000-12-08 05:02:12 +00:00
|
|
|
|
2021-08-02 12:27:38 +00:00
|
|
|
io->destip = rootip;
|
1998-08-20 08:19:55 +00:00
|
|
|
tftpfile->off = 0;
|
2015-12-16 17:13:09 +00:00
|
|
|
pathsize = (strlen(rootpath) + 1 + strlen(path) + 1) * sizeof(char);
|
|
|
|
tftpfile->path = malloc(pathsize);
|
1998-09-18 22:58:01 +00:00
|
|
|
if (tftpfile->path == NULL) {
|
2015-12-16 17:13:09 +00:00
|
|
|
free(tftpfile);
|
2018-11-01 22:13:18 +00:00
|
|
|
return (ENOMEM);
|
2015-12-16 17:13:09 +00:00
|
|
|
}
|
|
|
|
if (rootpath[strlen(rootpath) - 1] == '/' || path[0] == '/')
|
|
|
|
extraslash = "";
|
|
|
|
else
|
|
|
|
extraslash = "/";
|
|
|
|
res = snprintf(tftpfile->path, pathsize, "%s%s%s",
|
|
|
|
rootpath, extraslash, path);
|
|
|
|
if (res < 0 || res > pathsize) {
|
|
|
|
free(tftpfile->path);
|
|
|
|
free(tftpfile);
|
2018-11-01 22:13:18 +00:00
|
|
|
return (ENOMEM);
|
1998-09-18 22:58:01 +00:00
|
|
|
}
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2009-05-31 21:29:07 +00:00
|
|
|
res = tftp_makereq(tftpfile);
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
if (res) {
|
1998-09-18 22:58:01 +00:00
|
|
|
free(tftpfile->path);
|
2017-09-12 13:51:18 +00:00
|
|
|
free(tftpfile->pkt);
|
1998-08-20 08:19:55 +00:00
|
|
|
free(tftpfile);
|
|
|
|
return (res);
|
|
|
|
}
|
2018-11-01 22:13:18 +00:00
|
|
|
f->f_fsdata = tftpfile;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
is_open = 1;
|
1998-08-20 08:19:55 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
static int
|
2011-05-03 04:44:50 +00:00
|
|
|
tftp_read(struct open_file *f, void *addr, size_t size,
|
|
|
|
size_t *resid /* out */)
|
1998-08-20 08:19:55 +00:00
|
|
|
{
|
|
|
|
struct tftp_handle *tftpfile;
|
2018-11-01 13:12:05 +00:00
|
|
|
size_t res;
|
2018-09-09 06:30:15 +00:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = 0;
|
2018-11-01 13:12:05 +00:00
|
|
|
res = size;
|
2018-11-01 22:13:18 +00:00
|
|
|
tftpfile = f->f_fsdata;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2018-11-01 13:12:05 +00:00
|
|
|
/* Make sure we will not read past file end */
|
|
|
|
if (tftpfile->tftp_tsize > 0 &&
|
|
|
|
tftpfile->off + size > tftpfile->tftp_tsize) {
|
|
|
|
size = tftpfile->tftp_tsize - tftpfile->off;
|
|
|
|
}
|
|
|
|
|
2021-12-10 09:37:01 +00:00
|
|
|
if (tftpfile->tftp_cache != NULL) {
|
|
|
|
bcopy(tftpfile->tftp_cache + tftpfile->off,
|
|
|
|
addr, size);
|
|
|
|
|
|
|
|
addr = (char *)addr + size;
|
|
|
|
tftpfile->off += size;
|
|
|
|
res -= size;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
1998-08-20 08:19:55 +00:00
|
|
|
while (size > 0) {
|
|
|
|
int needblock, count;
|
|
|
|
|
2014-12-22 20:42:36 +00:00
|
|
|
twiddle(32);
|
1998-08-20 08:19:55 +00:00
|
|
|
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
needblock = tftpfile->off / tftpfile->tftp_blksize + 1;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
if (tftpfile->currblock > needblock) { /* seek backwards */
|
|
|
|
tftp_senderr(tftpfile, 0, "No error: read aborted");
|
2018-09-09 06:30:15 +00:00
|
|
|
rc = tftp_makereq(tftpfile);
|
|
|
|
if (rc != 0)
|
|
|
|
break;
|
2011-06-24 03:50:54 +00:00
|
|
|
}
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
while (tftpfile->currblock < needblock) {
|
|
|
|
|
2018-09-09 06:30:15 +00:00
|
|
|
rc = tftp_getnextblock(tftpfile);
|
|
|
|
if (rc) { /* no answer */
|
2011-05-03 07:46:02 +00:00
|
|
|
#ifdef TFTP_DEBUG
|
1998-08-20 08:19:55 +00:00
|
|
|
printf("tftp: read error\n");
|
|
|
|
#endif
|
2020-04-07 16:56:34 +00:00
|
|
|
if (tftpfile->tries > TFTP_TRIES) {
|
|
|
|
return (rc);
|
|
|
|
} else {
|
|
|
|
tftpfile->tries++;
|
|
|
|
tftp_makereq(tftpfile);
|
|
|
|
}
|
1998-08-20 08:19:55 +00:00
|
|
|
}
|
|
|
|
if (tftpfile->islastblock)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tftpfile->currblock == needblock) {
|
|
|
|
int offinblock, inbuffer;
|
|
|
|
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
offinblock = tftpfile->off % tftpfile->tftp_blksize;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
inbuffer = tftpfile->validsize - offinblock;
|
|
|
|
if (inbuffer < 0) {
|
2011-05-03 07:46:02 +00:00
|
|
|
#ifdef TFTP_DEBUG
|
1998-08-20 08:19:55 +00:00
|
|
|
printf("tftp: invalid offset %d\n",
|
|
|
|
tftpfile->off);
|
|
|
|
#endif
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
count = (size < inbuffer ? size : inbuffer);
|
2017-05-06 20:32:27 +00:00
|
|
|
bcopy(tftpfile->tftp_hdr->th_data + offinblock,
|
1998-08-20 08:19:55 +00:00
|
|
|
addr, count);
|
|
|
|
|
2004-10-03 15:58:20 +00:00
|
|
|
addr = (char *)addr + count;
|
1998-08-20 08:19:55 +00:00
|
|
|
tftpfile->off += count;
|
|
|
|
size -= count;
|
2018-11-01 13:12:05 +00:00
|
|
|
res -= count;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
if ((tftpfile->islastblock) && (count == inbuffer))
|
|
|
|
break; /* EOF */
|
|
|
|
} else {
|
2011-05-03 07:46:02 +00:00
|
|
|
#ifdef TFTP_DEBUG
|
1998-08-20 08:19:55 +00:00
|
|
|
printf("tftp: block %d not found\n", needblock);
|
|
|
|
#endif
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2021-12-10 09:37:01 +00:00
|
|
|
out:
|
2018-11-01 13:12:05 +00:00
|
|
|
if (resid != NULL)
|
|
|
|
*resid = res;
|
2018-09-09 06:30:15 +00:00
|
|
|
return (rc);
|
1998-08-20 08:19:55 +00:00
|
|
|
}
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
static int
|
2011-05-03 04:44:50 +00:00
|
|
|
tftp_close(struct open_file *f)
|
1998-08-20 08:19:55 +00:00
|
|
|
{
|
|
|
|
struct tftp_handle *tftpfile;
|
2018-11-01 22:13:18 +00:00
|
|
|
tftpfile = f->f_fsdata;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2021-12-13 09:35:23 +00:00
|
|
|
if (tftpfile->lastacksent == false)
|
|
|
|
tftp_senderr(tftpfile, 0, "No error: file closed");
|
1998-08-20 08:19:55 +00:00
|
|
|
|
1998-09-18 22:58:01 +00:00
|
|
|
if (tftpfile) {
|
|
|
|
free(tftpfile->path);
|
2017-05-06 20:32:27 +00:00
|
|
|
free(tftpfile->pkt);
|
2021-12-10 09:37:01 +00:00
|
|
|
free(tftpfile->tftp_cache);
|
1998-08-20 08:19:55 +00:00
|
|
|
free(tftpfile);
|
1998-09-18 22:58:01 +00:00
|
|
|
}
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
is_open = 0;
|
1998-08-20 08:19:55 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
static int
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
tftp_stat(struct open_file *f, struct stat *sb)
|
1998-08-20 08:19:55 +00:00
|
|
|
{
|
|
|
|
struct tftp_handle *tftpfile;
|
2018-11-01 22:13:18 +00:00
|
|
|
tftpfile = f->f_fsdata;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
2000-04-08 01:18:04 +00:00
|
|
|
sb->st_mode = 0444 | S_IFREG;
|
1998-08-20 08:19:55 +00:00
|
|
|
sb->st_nlink = 1;
|
|
|
|
sb->st_uid = 0;
|
|
|
|
sb->st_gid = 0;
|
2018-11-01 22:13:18 +00:00
|
|
|
sb->st_size = tftpfile->tftp_tsize;
|
1998-08-20 08:19:55 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
static off_t
|
2011-05-03 04:44:50 +00:00
|
|
|
tftp_seek(struct open_file *f, off_t offset, int where)
|
1998-08-20 08:19:55 +00:00
|
|
|
{
|
|
|
|
struct tftp_handle *tftpfile;
|
2018-11-01 22:13:18 +00:00
|
|
|
tftpfile = f->f_fsdata;
|
1998-08-20 08:19:55 +00:00
|
|
|
|
|
|
|
switch (where) {
|
|
|
|
case SEEK_SET:
|
|
|
|
tftpfile->off = offset;
|
|
|
|
break;
|
|
|
|
case SEEK_CUR:
|
|
|
|
tftpfile->off += offset;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
errno = EOFFSET;
|
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
return (tftpfile->off);
|
|
|
|
}
|
2011-06-15 22:04:14 +00:00
|
|
|
|
2021-12-10 09:37:01 +00:00
|
|
|
static int
|
|
|
|
tftp_preload(struct open_file *f)
|
|
|
|
{
|
|
|
|
struct tftp_handle *tftpfile;
|
|
|
|
char *cache;
|
|
|
|
int rc;
|
|
|
|
#ifdef TFTP_DEBUG
|
|
|
|
time_t start, end;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
tftpfile = f->f_fsdata;
|
|
|
|
cache = malloc(sizeof(char) * tftpfile->tftp_tsize);
|
|
|
|
if (cache == NULL) {
|
|
|
|
printf("Couldn't allocate %ju bytes for preload caching"
|
|
|
|
", disabling caching\n",
|
|
|
|
(uintmax_t)sizeof(char) * tftpfile->tftp_tsize);
|
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef TFTP_DEBUG
|
|
|
|
start = getsecs();
|
|
|
|
printf("Preloading %s ", tftpfile->path);
|
|
|
|
#endif
|
2021-12-30 08:47:06 +00:00
|
|
|
if (tftpfile->currblock == 1)
|
|
|
|
bcopy(tftpfile->tftp_hdr->th_data,
|
|
|
|
cache,
|
|
|
|
tftpfile->validsize);
|
|
|
|
else
|
|
|
|
tftpfile->currblock = 0;
|
|
|
|
|
2021-12-10 09:37:01 +00:00
|
|
|
while (tftpfile->islastblock == 0) {
|
|
|
|
twiddle(32);
|
|
|
|
rc = tftp_getnextblock(tftpfile);
|
|
|
|
if (rc) {
|
|
|
|
free(cache);
|
|
|
|
printf("Got TFTP error %d, disabling caching\n", rc);
|
|
|
|
return (rc);
|
|
|
|
}
|
|
|
|
bcopy(tftpfile->tftp_hdr->th_data,
|
|
|
|
cache + (tftpfile->tftp_blksize * (tftpfile->currblock - 1)),
|
|
|
|
tftpfile->validsize);
|
|
|
|
}
|
|
|
|
#ifdef TFTP_DEBUG
|
|
|
|
end = getsecs();
|
|
|
|
printf("\nPreloaded %s (%ju bytes) during %jd seconds\n",
|
|
|
|
tftpfile->path, (intmax_t)tftpfile->tftp_tsize,
|
|
|
|
(intmax_t)end - start);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
tftpfile->tftp_cache = cache;
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
static int
|
|
|
|
tftp_set_blksize(struct tftp_handle *h, const char *str)
|
|
|
|
{
|
2018-11-01 22:13:18 +00:00
|
|
|
char *endptr;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
int new_blksize;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (h == NULL || str == NULL)
|
|
|
|
return (ret);
|
|
|
|
|
|
|
|
new_blksize =
|
|
|
|
(unsigned int)strtol(str, &endptr, 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Only accept blksize value if it is numeric.
|
2011-06-24 03:50:54 +00:00
|
|
|
* RFC2348 specifies that acceptable values are 8-65464.
|
|
|
|
* Let's choose a limit less than MAXRSPACE.
|
|
|
|
*/
|
2018-11-01 22:13:18 +00:00
|
|
|
if (*endptr == '\0' && new_blksize >= 8 &&
|
|
|
|
new_blksize <= TFTP_MAX_BLKSIZE) {
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
h->tftp_blksize = new_blksize;
|
|
|
|
ret = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In RFC2347, the TFTP Option Acknowledgement package (OACK)
|
|
|
|
* is used to acknowledge a client's option negotiation request.
|
|
|
|
* The format of an OACK packet is:
|
|
|
|
* +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
|
|
|
* | opc | opt1 | 0 | value1 | 0 | optN | 0 | valueN | 0 |
|
|
|
|
* +-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
|
|
|
|
*
|
|
|
|
* opc
|
|
|
|
* The opcode field contains a 6, for Option Acknowledgment.
|
|
|
|
*
|
|
|
|
* opt1
|
|
|
|
* The first option acknowledgment, copied from the original
|
|
|
|
* request.
|
|
|
|
*
|
|
|
|
* value1
|
|
|
|
* The acknowledged value associated with the first option. If
|
|
|
|
* and how this value may differ from the original request is
|
|
|
|
* detailed in the specification for the option.
|
|
|
|
*
|
|
|
|
* optN, valueN
|
|
|
|
* The final option/value acknowledgment pair.
|
|
|
|
*/
|
2018-11-01 22:13:18 +00:00
|
|
|
static int
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
tftp_parse_oack(struct tftp_handle *h, char *buf, size_t len)
|
|
|
|
{
|
2018-11-01 22:13:18 +00:00
|
|
|
/*
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
* We parse the OACK strings into an array
|
|
|
|
* of name-value pairs.
|
|
|
|
*/
|
|
|
|
char *tftp_options[128] = { 0 };
|
|
|
|
char *val = buf;
|
|
|
|
int i = 0;
|
|
|
|
int option_idx = 0;
|
|
|
|
int blksize_is_set = 0;
|
|
|
|
int tsize = 0;
|
2018-11-01 22:13:18 +00:00
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
unsigned int orig_blksize;
|
|
|
|
|
|
|
|
while (option_idx < 128 && i < len) {
|
|
|
|
if (buf[i] == '\0') {
|
|
|
|
if (&buf[i] > val) {
|
|
|
|
tftp_options[option_idx] = val;
|
|
|
|
val = &buf[i] + 1;
|
|
|
|
++option_idx;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
++i;
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
}
|
|
|
|
|
2011-06-24 03:50:54 +00:00
|
|
|
/* Save the block size we requested for sanity check later. */
|
|
|
|
orig_blksize = h->tftp_blksize;
|
|
|
|
|
2018-11-01 22:13:18 +00:00
|
|
|
/*
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
* Parse individual TFTP options.
|
|
|
|
* * "blksize" is specified in RFC2348.
|
|
|
|
* * "tsize" is specified in RFC2349.
|
2018-11-01 22:13:18 +00:00
|
|
|
*/
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
for (i = 0; i < option_idx; i += 2) {
|
2018-11-01 22:13:18 +00:00
|
|
|
if (strcasecmp(tftp_options[i], "blksize") == 0) {
|
|
|
|
if (i + 1 < option_idx)
|
|
|
|
blksize_is_set =
|
|
|
|
tftp_set_blksize(h, tftp_options[i + 1]);
|
|
|
|
} else if (strcasecmp(tftp_options[i], "tsize") == 0) {
|
|
|
|
if (i + 1 < option_idx)
|
|
|
|
tsize = strtol(tftp_options[i + 1], NULL, 10);
|
|
|
|
if (tsize != 0)
|
|
|
|
h->tftp_tsize = tsize;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Do not allow any options we did not expect to be
|
|
|
|
* ACKed.
|
|
|
|
*/
|
|
|
|
printf("unexpected tftp option '%s'\n",
|
|
|
|
tftp_options[i]);
|
|
|
|
return (-1);
|
|
|
|
}
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!blksize_is_set) {
|
|
|
|
/*
|
|
|
|
* If TFTP blksize was not set, try defaulting
|
2011-06-24 03:50:54 +00:00
|
|
|
* to the legacy TFTP blksize of SEGSIZE(512)
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
*/
|
2011-06-24 03:50:54 +00:00
|
|
|
h->tftp_blksize = SEGSIZE;
|
|
|
|
} else if (h->tftp_blksize > orig_blksize) {
|
|
|
|
/*
|
|
|
|
* Server should not be proposing block sizes that
|
|
|
|
* exceed what we said we can handle.
|
|
|
|
*/
|
|
|
|
printf("unexpected blksize %u\n", h->tftp_blksize);
|
|
|
|
return (-1);
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef TFTP_DEBUG
|
|
|
|
printf("tftp_blksize: %u\n", h->tftp_blksize);
|
|
|
|
printf("tftp_tsize: %lu\n", h->tftp_tsize);
|
|
|
|
#endif
|
2018-11-01 22:13:18 +00:00
|
|
|
return (0);
|
(1) When sending the TFTP RRQ packet to read a file,
send along the "blksize" option specified in RFC2348,
and the "tsize" option specified in RFC2349.
Add code to parse the TFTP Option Acknowledgement (OACK) packet as
specified in RFC2347.
For TFTP servers which support the "blksize" option, we can
specify a TFTP Data block size larger than the default 512 bytes
specified in RFC1350. This offers greater read performance when
downloading files.
We request an initial size of 1428 bytes, which is less than the
Ethernet MTU of 1500 bytes. If the TFTP server sends back an OACK
packet, then use the block size specified in the OACK packet.
Most times it is usually the same value as what we request.
If the TFTP server supports RFC2348, we will see performance improvements
by transferring files over TFTP with larger block sizes.
If we do not get back an OACK packet, then we most likely we
are interoperating with a legacy TFTP server that does not
support TFTP extension options, so default to the block size of
512 bytes.
(2) If the "tftp.blksize" environment variable is set, then
take that value and use it when sending the TFTP RRQ packet,
instead of 1428. This allows us to set different values of
"tftp.blksize" in the loader, so that we can test out different
TFTP block sizes at run time.
Obtained from: Juniper Networks
Fixed by: rodrigc
2011-06-15 22:13:22 +00:00
|
|
|
}
|